¿Puedo usar un KEK para proteger los datos también?

1

Mi cliente desea que mi organización desarrolle su sistema de manera tal que las claves que se usan actualmente para proteger la confidencialidad de otras claves durante el transporte también se usen para proteger la confidencialidad de los datos en el mismo mensaje. Sospecho que esto podría ser una mala idea, pero ¿es eso generalmente cierto en todos los casos, y si es así, por qué?

Más detalles

Las KEK están protegiendo las claves que se envían al destinatario en el mensaje actual. Es un modelo clave en capas; No importa para qué se usan las claves transmitidas. El mismo mensaje se envía a múltiples destinatarios, pero solo un subconjunto tiene permiso para acceder a las claves que contiene. Se solicita a mi organización que use la misma clave para proteger también ciertos datos en el mensaje. En cuanto a las claves, solo un subconjunto de destinatarios tiene permiso para acceder a esos datos. El punto de la pregunta es si la protección de los datos debe ser una preocupación separada de la protección de las claves.

Más formalmente (según lo solicitado):

  • A publica el mensaje M en un lugar público donde los destinatarios B, C y D pueden recuperarlo.
  • El mensaje M contiene sub-mensajes Mb, Mc y Md destinados solo para el destinatario correspondiente, B, C o D respectivamente.
  • Las claves de cifrado de clave Kb, Kc y Kd se han emitido previamente a B, C y D a través de un medio sin conexión.
  • Cada mensaje secundario Mn contiene una clave cifrada destinada al destinatario N, K'n, protegido por el KEK emitido anteriormente: E (K'n, Kn).
  • Cada mensaje secundario Mn también contiene datos de texto sin formato, Di, destinados al destinatario I pero actualmente legibles para los demás destinatarios. Bajo esta evolución, esto será reemplazado por E (Dn, Kn).

Entonces: A - > B, C, D: M

donde (hoy):

M = E (K'b, Kb) + E (K'c, Kc) + E (K'd, Kd) + Db + Dc + Dd

y después de la evolución:

M = E (K'b, Kb) + E (K'c, Kc) + E (K'd, Kd) + E (Db, Kb) + E (Dc, Kc) + E (Dd, Kd)

    
pregunta D.H. 17.04.2016 - 10:07
fuente

1 respuesta

2

Parece estar bien.

La clave de cifrado de clave (KEK) es un nombre bastante confuso. Pone énfasis en el hecho de que una clave en particular se usa para cifrar otra clave (que a su vez encripta los datos), como si este hecho simple aumentara la seguridad de alguna manera. No lo hace La seguridad adicional proviene de otra cosa, y (por mi parte) el nombre de este esquema debería ser clave encriptada por separado para reflejar lo que realmente es importante aquí.

La seguridad adicional proviene del hecho de que los módulos de software o personas o dispositivos que pueden ver claves o datos (encriptados o simples) se pueden dividir. Usted separa algún entorno interno y deja el resto en el perímetro de seguridad exterior. El exterior:

  • no conoce el secreto más importante (también conocido como KEK)
  • pero es más accesible para personas externas, ya que proporciona muchas funciones y necesita aceptar varias entradas de datos

El interior debe estar separado de esto; Necesita tener características exactamente opuestas. Por lo general, el interior es solo el cifrador clave (un módulo de software), el descifrador de claves (ídem), el almacenamiento que contiene el KEK (un módulo de software o dispositivo de hardware) y las personas que pueden acceder a ellos.

En su situación, entiendo las solicitudes de los clientes para agregar algunos NewData (para cifrar con KEK). Creo que es seguro si y solo si no está exponiendo el Inside a cualquier riesgo adicional que sea:

  • obtener los NewData no implica ningún riesgo adicional; Es decir, NewData no proviene del perímetro externo de la aplicación, por lo que no tiene inyecciones ni desbordamientos.
  • la entrega de NewData a destino no implica ningún riesgo adicional; no es necesario ponerse en contacto con ninguna parte del perímetro exterior
  • (obviamente) el cifrado y descifrado de NewData se realiza con los mismos componentes que ya conocen KEK: el KEK no se pone en riesgo adicional al filtrarlo a otros componentes,
  • (obviamente) utiliza un cifrado normal, como AES, que es inmune a los ataques de texto plano conocido. Las claves que usaste para cifrar eran pseudoaleatorias, pero el atacante podría conocer NewData,
  • (obviamente) el NewData no requiere que personas adicionales tengan acceso al Interior.

Si todo esto no se cumple, ya tiene algunos puntos de partida para analizar y comunicar los riesgos involucrados.

    
respondido por el kubanczyk 17.04.2016 - 19:30
fuente

Lea otras preguntas en las etiquetas