2012-03-09 32 views
5

PKCS#12 es una forma conveniente de agrupar juntas una clave privada con su correspondiente certificado X.509 en un formato de archivo único estandarizado. Sin embargo, la especificación fue publicada por RSALabs en 1999 y utiliza solo RC4, RC2 y TripleDES para encriptación simétrica. ¿Hay alguna extensión común semi estándar para el esquema que agregue más algoritmos de cifrado u otras funciones de derivación de claves? OpenSSL está documentado para implementar soporte para AES y Camellia, pero la búsqueda de un estándar correspondiente aparece en blanco, por lo que parece ser una implementación específica de OpenSSL. ¿Alguien ha documentado el módulo ASN.1 y el pseudo código para estas extensiones?¿Hay alguna extensión publicada de PKCS # 12?

Respuesta

3

PKCS # 12 utiliza bloques de construcción de otros estándares.

El modo de encriptación recomendado se basa en el cifrado basado en contraseña de PKCS # 5 (PBES2). Esto se ha ampliado con soporte para SHA-2 y AES en PKCS#5 v.2.1.

Cuando OpenSSL utiliza AES lo hace así:

684 30 806:      SEQUENCE { 
688 30 802:      SEQUENCE { 
692 06 11:       OBJECT IDENTIFIER 
      :       pkcs-12-pkcs-8ShroudedKeyBag (1 2 840 113549 1 12 10 1 2) 
705 A0 723:       [0] { 
709 30 719:       SEQUENCE { 
713 30 73:        SEQUENCE { 
715 06 9:        OBJECT IDENTIFIER 
      :         pkcs5PBES2 (1 2 840 113549 1 5 13) 
726 30 60:        SEQUENCE { 
728 30 27:         SEQUENCE { 
730 06 9:         OBJECT IDENTIFIER 
      :          pkcs5PBKDF2 (1 2 840 113549 1 
5 12) 
741 30 14:         SEQUENCE { 
743 04 8:          OCTET STRING 
      :     BA 6B 5B B3 47 27 C9 73 
753 02 2:          INTEGER 2048 
      :          } 
      :         } 
757 30 29:         SEQUENCE { 
759 06 9:         OBJECT IDENTIFIER 
      :          aes128-CBC (2 16 840 1 101 3 4 1 2) 
770 04 16:         OCTET STRING 
      :     0F 79 79 0A D3 EC C0 3E 20 B8 51 85 2F 2B 6C 29 
      :         } 
      :         } 
      :        } 

Por lo que yo puedo leer la fuente, OpenSSL codifica la contraseña como ASCII en lugar de UTF-16 cero terminado cuando se utiliza PKCS # 5 PBES2 .

+0

Bueno, no exactamente. PKCS # 12 usa un PBKDF que se especifica en el apéndice B.2 y es diferente de ambos PBKDF1 de PBKDF2 de PKCS # 5 en varios aspectos. Por ejemplo, a diferencia de PKCS # 5 PBKDF1, presenta un estiramiento de tecla, a diferencia de PKCS # 5 PBKDF2 usa un hash iterado en lugar de una xor suma de salidas HMAC, y a diferencia de ambos formatea la sal y la contraseña de una manera inusual. –

+0

Para ser más específicos: PKCS # 12 apéndice B.1 especifica que las contraseñas deben verse como BMPStrings en lugar de simples OctetStrings. Esto significa que si se encuentra un identificador de algoritmo PKCS # 5 en el campo identificador del algoritmo de cifrado de un archivo PKCS # 12, no se determinará si la contraseña debe tratarse como una cadena BMPS o no. Por lo tanto, las reglas de procesamiento aún tendrían que especificarse externamente para ser inequívocas. –

+1

@Henrick Hellström: Por lo que recuerdo, el PBKDF en el apéndice B.2 es solo por retrocompatibilidad con el antiguo formato de Microsoft. Si lee la nota en la página 13, notará que se recomienda utilizar los mecanismos PKCS # 5. –

Cuestiones relacionadas