Cifrar + Datos de firma: ¿PKCS # 7 / CMS o hágalo usted mismo?

Question

Cifrar + Datos de firma: ¿PKCS # 7 / CMS o hágalo usted mismo?

#1 de Thomas Pornin (5 votos)
#2 de SquareRootOfTwentyThree (0 votos)

2

Actualmente estoy guardando una matriz de claves AES en un llavero como JSON, guardado como un archivo de texto / columna de texto SQL:

{    
    [
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:0,
       },
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:1,
       }
    ]
    signature:HashAboveKeychainThenRsaSignatureBytesBase64==
}

Solo el titular de la clave privada (por ejemplo, Alice) puede descifrar las claves AES. Alice también tiene su propia clave pública, por lo que puede verificar la firma antes de usarla. Esto la protege contra Chuck, que podría interrumpir el descifrado AES de los datos ya cifrados al crear una clave AES aleatoria, cifrarla con la clave pública de Alice y escribir donde se guarda el JSON. Pero Chuck no puede firmar, por lo que Alice no usará datos erróneos accidentalmente.

Lo anterior ha estado funcionando durante muchos meses, pero CMS / PKCS # 7 parece atractivo ya que ya está diseñado para la seguridad e integridad de los datos al definir sobres de datos (cifrado) y firmas de datos (firma).

Pregunta: Aparte de la interoperabilidad, ¿qué beneficios adicionales tendría uno al ir por la ruta CMS / PKCS # 7?

key-management

pregunta DeepSpace101 04.02.2013 - 23:35

fuente

2 respuestas

0

La interoperabilidad no parece ser una prioridad en su lista de requisitos. A menos que tenga una biblioteca que admita CMS con una calidad que coincida con sus expectativas, CMS / PKCS # 7 puede resultar fácilmente una exageración dada su complejidad.

Si su aplicación tiene una forma segura de almacenar los secretos de raíz junto a la base de datos SQL, es probable que esté mejor codificando todas sus claves en un blob, y use un modo de cifrado autenticado como AES GCM ( NIST 800-38D ) o AES CCM ( NIST 800-38C ). La clave de la raíz de AES se guarda en el almacén seguro. No utilizará ninguna clave pública, pero, según su descripción, no parece que realmente la necesite (una aplicación que acceda a sus propios datos).

respondido por el SquareRootOfTwentyThree 10.02.2013 - 21:17

fuente

Lea otras preguntas en las etiquetas key-management

¿Cuán efectivos han sido los métodos estadísticos para romper el cifrado? El impacto de los ataques de Sony en la industria de la seguridad [cerrado]

score 5 · Accepted Answer

No enrolle su propio criptográfico . Si decides inventar tu propio formato, entonces estás por tu cuenta. La historia de la criptografía está llena de personas que inventaron su propio formato y fallaron horriblemente; y, más concretamente, la historia de la criptografía está no llena o las personas que inventaron su propio formato y se salieron con la suya. Estas cosas son difíciles de hacer correctamente y no puede probar si tuvo éxito o no (puede probar la funcionalidad, no la seguridad).

CMS (el nuevo nombre para PKCS # 7) tiene los dobles beneficios de:

Haber sido estandarizado y desplegado en el campo durante mucho tiempo, por lo que sus riesgos potenciales ya deberían haberse entendido bien;
ya se está implementando en varios marcos y bibliotecas. Como de costumbre, el software que es más fácil de implementar correctamente es el software que ya está implementado correctamente.

Entonces, hazte un favor, usa CMS.