Czy są jakieś opublikowane rozszerzenia do PKCS # 12?

PKCS#12 to wygodny sposób na scalenie klucza prywatnego z odpowiednim certyfikatem X.509 w znormalizowanym formacie pojedynczego pliku. Jednak specyfikacja została opublikowana przez RSALabs w 1999 roku i używa tylko RC4, RC2 i TripleDES do symetrycznego szyfrowania. Czy są jakieś wspólne, pół-standardowe rozszerzenia schematu, które dodają więcej algorytmów szyfrowania lub innych funkcji pochodnych klucza? OpenSSL jest udokumentowane w celu implementacji obsługi AES i Camellia, ale wyszukiwanie odpowiedniego standardu jest puste, więc wydaje się, że jest to implementacja specyficzna dla OpenSSL. Czy ktoś udokumentował moduł ASN.1 i pseudo kod dla tych rozszerzeń?Czy są jakieś opublikowane rozszerzenia do PKCS # 12?

Źródło

2012-03-09 Henrick Hellström

PKCS # 12 wykorzystuje bloki konstrukcyjne z innych standardów.

Zalecany tryb szyfrowania oparty jest na szyfrowaniu opartym na hasłach z PKCS # 5 (PBES2). Zostało to rozszerzone dzięki obsłudze SHA-2 i AES w PKCS#5 v.2.1.

Kiedy OpenSSL używa AES robi to tak:

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 
      :         } 
      :         } 
      :        }

O ile mogę czytać źródła, OpenSSL koduje hasło jako ASCII zamiast zera zakończone UTF-16 podczas korzystania z PKCS # 5 PBES2 .

Źródło

2012-03-09 12:31:08

No, nie do końca. PKCS # 12 wykorzystuje PBKDF, który jest określony w dodatku B.2 i różni się od PBKDF1 PBKDF2 PKCS # 5 pod kilkoma względami. Na przykład, w przeciwieństwie do PKCS # 5 PBKDF1, ma on funkcję wyciągania kluczy, w przeciwieństwie do PKCS # 5 PBKDF2 używa iterowanego skrótu zamiast sumy xor z wyjściami HMAC i w przeciwieństwie do obu formatuje sól i hasło w nietypowy sposób. –

Aby być bardziej szczegółowym: Dodatek B.1 PKCS # 12 określa, że hasła powinny być postrzegane jako BMPStrings zamiast zwykłych Oktetowych. Oznacza to, że gdyby w polu identyfikatora algorytmu szyfrowania pliku PKCS # 12 napotkano identyfikator algorytmu PKCS # 5, nie zostałoby ustalone, czy hasło powinno być traktowane jako BMPString czy nie. W związku z tym zasady przetwarzania nadal musiałyby być określone zewnętrznie, aby były jednoznaczne. –

@Henrick Hellström: O ile pamiętam, PBKDF w dodatku B.2 służy jedynie do wstecznej kompatybilności ze starym formatem Microsoft. Jeśli przeczytasz notatkę na stronie 13, zauważysz, że zalecane jest użycie mechanizmów PKCS # 5. –

Czy są jakieś opublikowane rozszerzenia do PKCS # 12?

Odpowiedz

Powiązane problemy