PKCS#12 — это удобный способ объединить закрытый ключ с соответствующим сертификатом X.509. в стандартизированный формат одного файла. Однако спецификация была опубликована RSALabs в 1999 году и использует только RC4, RC2 и TripleDES для симметричного шифрования. Существуют ли какие-либо общие полустандартные расширения схемы, которые добавляют дополнительные алгоритмы шифрования или другие функции получения ключей? OpenSSL задокументирован для реализации поддержки AES и Camellia, но поиск соответствующего стандарта не дает результатов, так что это похоже на реализацию, специфичную для OpenSSL. Кто-нибудь задокументировал модуль ASN.1 и псевдокод для этих расширений?
Есть ли опубликованные расширения для PKCS#12?
Ответы (1)
PKCS#12 использует строительные блоки из других стандартов.
Рекомендуемый режим шифрования основан на шифровании на основе пароля из PKCS#5 (PBES2). Это было расширено поддержкой SHA-2 и AES в PKCS#5 v .2.1.
Когда OpenSSL использует AES, он делает это следующим образом:
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
: }
: }
: }
Насколько я могу прочитать источник, OpenSSL кодирует пароль как ASCII, а не UTF-16 с нулевым завершением при использовании PKCS # 5 PBES2.
person
Rasmus Faber
schedule
09.03.2012
Ну, не совсем так. PKCS#12 использует PBKDF, указанный в приложении B.2, и отличается от PBKDF1, PBKDF2 и PKCS#5 в нескольких отношениях. Например, в отличие от PKCS#5 PBKDF1, он имеет растяжку ключей, в отличие от PKCS#5 PBKDF2, он использует повторяющийся хэш вместо суммы xor выходных данных HMAC, и, в отличие от обоих, он форматирует соль и пароль необычным способом.
- person Henrick Hellström; 09.03.2012
Чтобы быть более конкретным: PKCS # 12, приложение B.1, указывает, что пароли должны рассматриваться как BMPStrings вместо простых OctetStrings. Это означает, что если идентификатор алгоритма PKCS#5 встретится в поле идентификатора алгоритма шифрования файла PKCS#12, будет неопределенно, следует ли обрабатывать пароль как BMPString или нет. Следовательно, правила обработки по-прежнему должны быть определены извне, чтобы быть однозначными.
- person Henrick Hellström; 09.03.2012
@ Хенрик Хеллстрем: Насколько я помню, PBKDF в приложении B.2 предназначен только для обратной совместимости со старым форматом Microsoft. Если вы прочтете примечание на стр. 13, то заметите, что рекомендуется использовать механизмы PKCS#5.
- person Rasmus Faber; 09.03.2012
@ Хенрик Хеллстрем: Приложение B.1 применяется ко всем PBKDF. Итак, насколько я читал стандарт, было бы ясно, что пароль следует рассматривать как BMPString.
- person Rasmus Faber; 09.03.2012
Спасибо, это полезно! Однако я думаю, что разглагольствования Питера Гутмана cs.auckland.ac.nz/ ~pgut001/pubs/pfx.html относится и к этой сноске, поскольку в ней не сказано, как следует кодировать пароли, если используются алгоритмы PKCS#5 v2. BMPString или ASCII?
- person Henrick Hellström; 09.03.2012
Я думаю, что это неопределенно. В сноске говорится, что приложение B применяется только к алгоритмам, определенным в PKCS#12, но, с другой стороны, PKCS#5 ничего не говорит о том, как строка символов пароля преобразуется в строку октетов, а PKCS#12 B.1 это единственный текст, который что-то говорит об этом.
- person Henrick Hellström; 09.03.2012
@ Хенрик Хеллстрем: я думаю, вы правы в том, что приложение B.1. не должны применяться к PKCS#5. Так что OpenSSL, вероятно, правильно использует ASCII для PBES2.
- person Rasmus Faber; 09.03.2012
