В криптографии PKCS#12 — один из стандартов семейства Public-Key Cryptography Standards (PKCS), опубликованных RSA Laboratories. Он определяет формат файла, используемый для хранения и/или транспортировки секретного ключа (:en:Private key), цепочки доверия от сертификата пользователя до корневого сертификата удостоверяющего центра и списка отзыва сертификатов (CRL). Защита файла осуществляется одним из двух способов: безопасным, с использованием доверенной ключевой пары (открытый/закрытый ключи, подходящие для цифровой подписи и шифрования) или менее безопасным, с использованием симметричного ключа, основанного на пароле. Второй подходит для случаев, когда использование доверенных пар открытый/закрытый ключей недоступны. Формат PKCS#12 — это формат, предназначенный для хранения ключевой пары (закрытый ключ и сертификат), который распознаётся и используется многими браузерами и почтовыми агентами. В файлах PKCS#12 хранятся одновременно и сертификат, и закрытый ключ (разумеется в зашифрованном виде). Примерная организация PKCS#12 файла показана на рисунке справа.
В этом стандарте описывается синтаксис передачи персональной идентификационной информации, включающей закрытые ключи, сертификаты, различные секреты и многое другое. Этот стандарт поддерживает прямую передачу данных между платформой отправителем и платформой получателем. Стандарт поддерживает передачу данных как с высоким уровнем защиты (с помощью пары открытого/закрытого ключа, используемого для цифровой подписи и шифрования), так и с более низким уровнем защиты (с помощью авторизации по паролю), в том случае, если использование открытого/закрытого ключа недоступно.
Стандарт реализован как аппаратно, так и программно. Пример аппаратной реализации — защищённые опознавательные знаки, такие как Смарт-карта и PC Card.
Этот стандарт может быть рассмотрен как надстройка над стандартом PKCS8. Включена дополнительная идентификационная информация, включающая закрытые ключи. Введён режим высокой безопасности с помощью сокрытия открытого ключа.
Введение Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в правительственных организациях, спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности всё большее количество людей. В настоящее время все озабочены безопасностью передаваемых по сети данных. В результате чего появилось множество различных сертификатов, методов шифрования. В данной статье будет рассмотрен формат хранения ключей PKCS#12 и некоторые проблемы, связанные с безопасным хранением закрытых ключей сертификатов.
В течение многих лет большое количество форматов хранения создавалось в дополнение оригинальным форматам PKCS5 и PKCS8, которые были ограничены в использовании DES и MD5. Это привело к распространению несовместимых и зачастую небезопасных форматов хранения закрытого ключа. Вершиной этого стал чрезвычайно сложный формат PKCS12 с его смешением несовместимых идентификаторов объектов, алгоритмов, содержания данных и требований к обработке. В результате этого смешения реализация была и небезопасна и несовместима со старыми версиями. Так как требования не обеспечивали достаточно информации, для реализации совместимых версий. Другая проблема этого формата — раздутие данных, что делало его бесполезным для использования в устройствах с ограниченным количеством памяти, таких как смарт карты.
Эти изменения выдвинули на первый план необходимость упрощения, безопасности и совместимости форматов хранения закрытых ключей. Задачи разработчиков для этого формата заключались в следующем:
Хранить закрытые ключи в безопасности. Использовать как можно меньше новых, не протестированных алгоритмов и методов. Убедиться, что относительно легко производить совместимые реализации и относительно сложно изготовить небезопасную реализацию. Открыть для компактного кодирования. Для появления возможности использования в носителях ключа, с ограниченным пространством, таких как смарт карты. Пусть он будет простым. Формат должен быть разработан для хранения одного закрытого ключа безопасности, чтобы успешная атака на ключевой контейнер не ставила под угрозу целый ряд других данных. С другой стороны успешная атака на PKCS#12 ставит под угрозу более или менее уязвимые куски информации, хранимой пользователем, потому что вся она хранится в одном файле.
Связь с форматом PFX PKCS # 12 является преемником «PFX» от Microsoft. Термины «PKCS # 12 файл» и «PFX файл» иногда используются как синонимы.
PFX получил тяжёлую критику, является одним из самых сложных криптографических протоколов, но тем не менее остаётся единственным стандартным способом сегодня для хранения закрытых ключей и сертификатов в одном зашифрованном файле.
Netscape использовал формат PFX, а не PKCS#12 в версиях 4.03 и ниже, потому что формат PKCS#12 просто не существовал. Из-за необходимости обратной совместимости Netscape 4.04 и более новые версии, а также все версии MSIE поддерживали только импорт в формат PFX. Приведённая ниже таблица объединяет вышесказанное.
Программное обеспечение PKCS#12 импорт PKCS#12 экспорт PFX импорт PFX экспорт Netscape 4.03 и более ранние версии Да. Да. Да. Да. Netscape 4.04 и более поздние версии Да. Да. Да. Да. MSIE 4.0 и более поздние версии Да. Да. Да. Да. SD
Режимы обмена информацией Любые комбинации режимов конфиденциальности и честности допускаются в этом стандарте. Конечно, хорошая политика безопасности предполагает избежание определённых практик. Например, было бы глупо передавать закрытый ключ без какой-либо физической защиты.
Для обоих режимов (конфиденциальности и честности) предпочтительнее использовать открытый ключ, а не пароль. Однако не всегда предоставляется возможность пользоваться режимом с использованием открытого ключа. Например, если во время отправки мы не знаем достаточно сведений о платформе получателе. В этом случае режим с использованием открытого ключа будет только мешать.
Режим конфиденциальности С использованием открытого ключаИнформация шифруется с помощью открытого ключа платформы получателя, шифр открыт вместе с соответствующим ключом. Закрытый ключ находится на платформе получателя и используется для просмотра конфиденциальных данных, содержащихся в сообщении. Пересылка открытого ключа при этом называется TPDestEncK. С использованием пароляИнформация шифруется симметричным ключом, получаемым из имени пользователя и его пароля, так же как и в стандарте PKCS5.
Режим честности С использованием открытого ключаЧестность обеспечивается с помощью ЭЦП, получаемой использованием закрытого ключа платформы источника. Проверка производится путём использования на платформе получателе открытого ключа. Закрытый ключ находится на платформе источнике и используется до подписи персональной информации. Пересылка открытого ключа при этом называется TPSrcSigK. С использованием пароляЧестность гарантируется с помощью имитовставки, получаемой из пароля. При использовании обоих: режима честности с паролем и режима конфиденциальности с паролем, пароли могут как совпадать, так и не совпадать.
Формат контейнера ключей Пара закрытого/открытого ключа состоит из двух наборов параметров. Открытые параметры с дополнительной идентификационной информацией, такой как имена пользователей и e-mail адреса, хранятся не зашифрованными. Закрытые параметры в основном хранятся с использованием некоторого механизма защиты, такого как шифрование.
Формат контейнера был определён на основе формата, реализованного в PKCS#7 и S/MIME. Следующий идентификатор объекта идентифицирует безопасный тип хранения содержимого закрытого ключа.
id-securedPrivateKey OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) cryptlib(32) 42 }
Безопасный тип хранения содержимого закрытого ключа должен иметь ASN.1 SecuredPrivateKey тип:
SecuredPrivateKey ::= SEQUENCE { version Version, publicKey PublicKeyInfo, privateKey ContentInfo
Поля типа SecuredPrivateKey имеют следующие значения:
version — номер версии синтаксиса, должен быть равен 0.
publicKey — открытая компонента ключа и дополнительная идентификационная информация о владельце ключа.
privateKey — защищённый закрытый ключ, состоящий из идентификатора типа содержимого и самого содержимого.
Компоненты открытого ключа Компоненты открытого ключа хранятся в незашифрованной форме. Сделано так, потому что нет достаточно веских причин для шифрования этих данных. Так как шифрование этих данных любым поточным шифром предоставляет атакующему значительно количество известного зашифрованного текста и, потому что должна быть возможность для пользователя получить доступ к его открытому ключу без запроса пароля. Информация об открытом ключе представлена в типе PublicKeyInfo:
PublicKeyInfo ::= CHOICE { publicKeyInfo SubjectPublicKeyInfo, -- Raw public key info certRequest [ 0 ] EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req. certificate [ 1 ] EXPLICIT Certificate, -- X.509 certificate certChain [ 2 ] EXPLICIT PKCS7CertChain—PKCS #7 cert.chain
В этой простейшей форме открытый ключ хранится как SubjectPublicKeyInfo. Однажды, когда был сгенерирован запрос сертификации, 'сырая' информация о открытом ключе может быть заменена в соответствии с требованием и, когда ключ сертифицирован, или сертификат или, полный шифр сертификата может быть сохранён.
Компоненты закрытого ключа Компоненты закрытого ключа могут храниться как в зашифрованной так и не в зашифрованной форме. Зашифрованная форма рекомендуется пока данные не защищены другими средствами. Если данные хранятся в не зашифрованной форме, используется тип содержимого Data. Если же данные хранятся в зашифрованной форме, то используется тип EncryptedData с contentEncryptionAlgorithm — алгоритм шифрования, режим и дополнительные параметры, которые используются при генерации ключа. Содержимое или зашифрованное содержимое полей закрытого ключа (без соответствующих полей открытого ключа), который соответствуют полям открытого ключа, приведённым в PublicKeyInfo.
Например, для RSA:
RSAPrivateKey ::= SEQUENCE { privateExponent INTEGER, -- Private exponent d prime1 INTEGER, -- Prime factor p of n prime2 INTEGER, -- Prime factor q of n exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER—CRT coefficient (q^-1) mod p
Для DSA и схемы Эль-Гамаля:
DSAPrivateKey ::= SEQUENCE { x INTEGER—Private random integer
Причины, по которым хранятся только поля закрытого ключа заключаются в следующем: во-первых, для того чтобы избежать избыточности (всё остальное уже содержится в PublicKeyInfo); во-вторых, для того чтобы устранить возможность тривиального восстановления значимой суммы потока ключей, использую известные открытые поля в начале ключа.
Поддерживаемые алгоритмы шифрования PKCS#12 поддерживает следующие алгоритмы шифрования:
128 битный RC4 с SHA1 40 битный RC4 с SHA1 3 ключевой 3DES с SHA1 (168 бит) 2 ключевой 3DES с SHA1 (112 бит) 128 битный RC2 с SHA1 40 битный RC2 с SHA1
Кроме того также поддерживается режим PKCS#5 v1.5. Это позволяет пользоваться следующими алгоритмами:
DES с MD5 (56 бит) DES с MD2 (56 бит)
Использование PKCS#5 v2.0 позволит использовать произвольный алгоритм шифрования.
OpenSSL может обрабатывать PKCS#5 v1.5 и v2.0 в файлах PKCS#12, однако другие реализации не поддерживаются.
В следующей таблице собраны данные о поддержки различного шифрования: