Let’s encrypt: получение сертификата по шагам
Содержание:
- Введение
- Введение
- Устранение неполадок при открытии файлов PEM
- PFX File Summary
- Поддерживаемые алгоритмы шифрования
- Уязвимости
- How to Convert a PEM File
- Режимы обмена информацией[править | править код]
- Поддерживаемые алгоритмы шифрования
- Типы файлов PFX
- Библиотека JSSE
- Формат контейнера ключей[править | править код]
- Формат контейнера ключей
- Настройка агента HPD для работы с сервером клиентской верификации
- Режимы обмена информацией
- Форматы SSL-сертификаты
- BUGS
Введение
Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в правительственных организациях, спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности все большее количество людей. В настоящее время все озабочены безопасностью передаваемых по сети данных. В результате чего появилось множество различных сертификатов, методов шифрования. В данной статье будет рассмотрен формат хранения ключей PKCS#12 и некоторые проблемы, связанные с безопасным хранением закрытых ключей сертификатов.
В течение многих лет большое количество форматов хранения создавалось в дополнение оригинальным форматам PKCS5 и PKCS8, которые были ограничены в использовании DES и MD5. Это привело к распространению несовместимых и зачастую небезопасных форматов хранения закрытого ключа. Вершиной этого стал чрезвычайно сложный формат PKCS12 с его смешением несовместимых идентификаторов объектов, алгоритмов, содержания данных и требований к обработке. В результате этого смешения реализация была и небезопасна и несовместима со старыми версиями. Так как требования не обеспечивали достаточно информации, для реализации совместимых версий. Другая проблема этого формата — раздутие данных, что делало его бесполезным для использования в устройствах с ограниченным количеством памяти, таких как смарт карты.
Эти изменения выдвинули на первый план необходимость упрощения, безопасности и совместимости форматов хранения закрытых ключей. Задачи разработчиков для этого формата заключались в следующем:
- Хранить закрытые ключи в безопасности.
- Использовать как можно меньше новых, не протестированных алгоритмов и методов.
- Убедиться, что относительно легко производить совместимые реализации и относительно сложно изготовить небезопасную реализацию.
- Открыть для компактного кодирования. Для появления возможности использования в носителях ключа, с ограниченным пространством, таких как смарт карты.
- Пусть он будет простым. Формат должен быть разработан для хранения одного закрытого ключа безопасности, чтобы успешная атака на ключевой контейнер не ставила под угрозу целый ряд других данных. С другой стороны успешная атака на PKCS#12 ставит под угрозу более или менее уязвимые куски информации, хранимой пользователем, потому что вся она хранится в одном файле.
Введение
Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в правительственных организациях, спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности все большее количество людей. В настоящее время все озабочены безопасностью передаваемых по сети данных. В результате чего появилось множество различных сертификатов, методов шифрования. В данной статье будет рассмотрен формат хранения ключей PKCS#12 и некоторые проблемы, связанные с безопасным хранением закрытых ключей сертификатов.
В течение многих лет большое количество форматов хранения создавалось в дополнение оригинальным форматам PKCS5 и PKCS8, которые были ограничены в использовании DES и MD5. Это привело к распространению несовместимых и зачастую небезопасных форматов хранения закрытого ключа. Вершиной этого стал чрезвычайно сложный формат PKCS12 с его смешением несовместимых идентификаторов объектов, алгоритмов, содержания данных и требований к обработке. В результате этого смешения реализация была и небезопасна и несовместима со старыми версиями. Так как требования не обеспечивали достаточно информации, для реализации совместимых версий. Другая проблема этого формата — раздутие данных, что делало его бесполезным для использования в устройствах с ограниченным количеством памяти, таких как смарт карты.
Эти изменения выдвинули на первый план необходимость упрощения, безопасности и совместимости форматов хранения закрытых ключей. Задачи разработчиков для этого формата заключались в следующем:
- Хранить закрытые ключи в безопасности.
- Использовать как можно меньше новых, не протестированных алгоритмов и методов.
- Убедиться, что относительно легко производить совместимые реализации и относительно сложно изготовить небезопасную реализацию.
- Открыть для компактного кодирования. Для появления возможности использования в носителях ключа, с ограниченным пространством, таких как смарт карты.
- Пусть он будет простым. Формат должен быть разработан для хранения одного закрытого ключа безопасности, чтобы успешная атака на ключевой контейнер не ставила под угрозу целый ряд других данных. С другой стороны успешная атака на PKCS#12 ставит под угрозу более или менее уязвимые куски информации, хранимой пользователем, потому что вся она хранится в одном файле.
Устранение неполадок при открытии файлов PEM
Общие проблемы с открытием файлов PEM
Microsoft IIS не установлен
Дважды щелкнув по файлу PEM вы можете увидеть системное диалоговое окно, в котором сообщается «Не удается открыть этот тип файла». В этом случае обычно это связано с тем, что на вашем компьютере не установлено Microsoft IIS для %%os%%. Так как ваша операционная система не знает, что делать с этим файлом, вы не сможете открыть его дважды щелкнув на него.
Совет: Если вам извстна другая программа, которая может открыть файл PEM, вы можете попробовать открыть данный файл, выбрав это приложение из списка возможных программ.
Установлена неправильная версия Microsoft IIS
В некоторых случаях у вас может быть более новая (или более старая) версия файла Privacy Enhanced Mail Certificate, не поддерживаемая установленной версией приложения. При отсутствии правильной версии ПО Microsoft IIS (или любой из других программ, перечисленных выше), может потребоваться загрузить другую версию ПО или одного из других прикладных программных средств, перечисленных выше. Такая проблема чаще всего возникает при работе в более старой версии прикладного программного средства с файлом, созданным в более новой версии, который старая версия не может распознать.
Совет: Иногда вы можете получить общее представление о версии файла PEM, щелкнув правой кнопкой мыши на файл, а затем выбрав «Свойства» (Windows) или «Получить информацию» (Mac OSX).
Резюме: В любом случае, большинство проблем, возникающих во время открытия файлов PEM, связаны с отсутствием на вашем компьютере установленного правильного прикладного программного средства.
Даже если на вашем компьютере уже установлено Microsoft IIS или другое программное обеспечение, связанное с PEM, вы все равно можете столкнуться с проблемами во время открытия файлов Privacy Enhanced Mail Certificate. Если проблемы открытия файлов PEM до сих пор не устранены, возможно, причина кроется в других проблемах, не позволяющих открыть эти файлы. Такие проблемы включают (представлены в порядке от наиболее до наименее распространенных):
PFX File Summary
There are two file types associated with the PFX File Extension, with the most widely-observed being the PKCS #12 Certificate File format. According to our database, three distinct software programs (conventionally, Adobe Acrobat DC developed by Adobe Systems Incorporated) will enable you to view these files.
These files can be categorized as System Files or Text Files. In the majority of cases, these files will be System Files.
PFX files are found on both mobile and desktop platforms and can be opened using Windows, Mac, and Linux operating systems.
These files have a Popularity Rating of «Low», meaning they are
not very commonly observed on your average hard disk.
Поддерживаемые алгоритмы шифрования
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, однако другие реализации не поддерживаются.
В следующей таблице собраны данные о поддержки различного шифрования:
| Программное обеспечение и режим. | Шифрование сертификата | Шифрование закрытого ключа |
|---|---|---|
| MSIE4 (domestic and export versions) PKCS#12 экспорт. | 40 битный RC2. | 40 битный RC2. |
| MSIE4, 5 (domestic and export versions) PKCS#12 импорт. | 40 битный RC2, 3 ключевой 3DES. | 40 битный RC2, 3 ключевой3DES. |
| MSIE5 PKCS#12 экспорт. | 40 битный RC2 | 3 ключевой 3DES с SHA1 (168 бит) |
| Netscape Communicator (domestic and export versions) PKCS#12 экспорт | 40 битный RC2 | 3 ключевой 3DES с SHA1 (168 бит) |
| Netscape Communicator (export version) PKCS#12 импорт. | Только 40 битный шифр. | Все. |
| Netscape Communicator (domestic or fortified version) PKCS#12 импорт. | Все. | Все. |
| OpenSSL PKCS#12 код. | Все. | Все. |
По умолчанию сильнейшее шифрование поддерживается всеми реализациями приложений, использующих PKCS#12: 3DES для закрытых ключей и RC2-40 для сертификатов. Также дополнительный опции позволяют шифровать сертификат с помощью 3DES.
Следует отметить, что в то время как множественные версии Netscape будут импортировать файлы с помощью разных алгоритмов, тогда как MSIE, кажется, поддерживает только RC2 и 3DES.
Уязвимости
- При транспортировке контейнеров PKCS#12 защита данных реализована на основе пароля.
Однако, это не верно и в отношении объектов сертификата. Причина этого в том, что обеспечение целостности PKCS#12-файлов не является обязательной, как показано здесь:
PFX ::= SEQUENCE { version INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData OPTIONAL }
Так как этот контроль опционален, то он может быть отключен и тогда содержимое файла может быть изменено без обнаружения или предупреждения. Таким образом контроль доступа не требуется для добавления объектов сертификата. В этом случае сертификаты используются в SSL PKI как Trust Anchor и это дает возможность злоумышленнику вставить Trust Anchor своего центра сертификации в эти файлы без необходимости какой-либо авторизации.
С того момента, как Trust Anchor злоумышленника вставлен в атакуемую систему она будет доверять и признавать любой сертификат, выпущенный центром сертификации атакующего.
Атака может быть произведена по схеме человек посередине, который перехватывает файлы во время транспортировки, вставляет вражеский Trust Anchor. В этом случае атака может так же работать против систем, не использующих PKCS#12-файлы, как хранилище ключей, но эта атака имеет недостаток, что фальшивый сертификат может быть обнаружен после выявления факта атаки.
How to Convert a PEM File
Unlike most file formats that can be converted with a file conversion tool or website, you need to enter special commands against a particular program in order to convert the PEM file format to most other formats.
With OpenSSL (get the Windows version here), you can convert the PEM file to PFX with the following command:
openssl pkcs12 -inkey yourfile.pem -in yourfile.cert -export -out yourfile.pfx
If you have a PEM file that needs to be converted to CRT, like is the case with Ubuntu, use this command with OpenSSL:
openssl x509 -in yourfile.pem -inform PEM -out yourfile.crt
OpenSSL also supports converting .PEM to .P12 (PKCS#12, or Public Key Cryptography Standard #12), but append the «.TXT» file extension at the end of the file before running this command:
openssl pkcs12 -export -inkey yourfile.pem.txt -in yourfile.pem.txt -out yourfile.p12
See the Stack Overflow link above about using the PEM file with Java KeyStore if you want to convert the file to JKS, or this tutorial from Oracle to import the file into the Java truststore.
Режимы обмена информацией[править | править код]
Любые комбинации режимов конфиденциальности и честности допускаются в этом стандарте. Конечно, хорошая политика безопасности предполагает избежание определенных практик. Например, было бы глупо передавать закрытый ключ без какой-либо физической защиты.
Для обоих режимов (конфиденциальности и честности) предпочтительнее использовать открытый ключ, а не пароль. Однако не всегда предоставляется возможность пользоваться режимом с использованием открытого ключа. Например, если во время отправки мы не знаем достаточно сведений о платформе получателе. В этом случае режим с использованием открытого ключа будет только мешать.
Режим конфиденциальностиправить | править код
- С использованием открытого ключаИнформация шифруется с помощью открытого ключа платформы получателя, шифр открыт вместе с соответствующим ключом. Закрытый ключ находится на платформе получателя и используется для просмотра конфиденциальных данных, содержащихся в сообщении. Пересылка открытого ключа при этом называется TPDestEncK.
- С использованием пароляИнформация шифруется симметричным ключом, получаемым из имени пользователя и его пароля, так же как и в стандарте PKCS5.
Режим честностиправить | править код
- С использованием открытого ключаЧестность обеспечивается с помощью ЭЦП, получаемой использованием закрытого ключа платформы источника. Проверка производится путём использования на платформе получателе открытого ключа. Закрытый ключ находится на платформе источнике и используется до подписи персональной информации. Пересылка открытого ключа при этом называется TPSrcSigK.
- С использованием пароляЧестность гарантируется с помощью имитовставки, получаемой из пароля. При использовании обоих: режима честности с паролем и режима конфиденциальности с паролем, пароли могут как совпадать, так и не совпадать.
Поддерживаемые алгоритмы шифрования
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, однако другие реализации не поддерживаются.
В следующей таблице собраны данные о поддержки различного шифрования:
| Программное обеспечение и режим. | Шифрование сертификата | Шифрование закрытого ключа |
|---|---|---|
| MSIE4 (domestic and export versions) PKCS#12 экспорт. | 40 битный RC2. | 40 битный RC2. |
| MSIE4, 5 (domestic and export versions) PKCS#12 импорт. | 40 битный RC2, 3 ключевой 3DES. | 40 битный RC2, 3 ключевой3DES. |
| MSIE5 PKCS#12 экспорт. | 40 битный RC2 | 3 ключевой 3DES с SHA1 (168 бит) |
| Netscape Communicator (domestic and export versions) PKCS#12 экспорт | 40 битный RC2 | 3 ключевой 3DES с SHA1 (168 бит) |
| Netscape Communicator (export version) PKCS#12 импорт. | Только 40 битный шифр. | Все. |
| Netscape Communicator (domestic or fortified version) PKCS#12 импорт. | Все. | Все. |
| OpenSSL PKCS#12 код. | Все. | Все. |
По умолчанию сильнейшее шифрование поддерживается всеми реализациями приложений, использующих PKCS#12: 3DES для закрытых ключей и RC2-40 для сертификатов. Также дополнительный опции позволяют шифровать сертификат с помощью 3DES.
Следует отметить, что в то время как множественные версии Netscape будут импортировать файлы с помощью разных алгоритмов, тогда как MSIE, кажется, поддерживает только RC2 и 3DES.
Типы файлов PFX
Ассоциация основного файла PFX
.PFX
| Формат файла: | .pfx |
| Тип файла: | PKCS #12 Certificate File |
PKCS # 12 Сертификат Файл представляет собой зашифрованный файл безопасности, который позволяет хранить сертификаты безопасности, которые используются для аутентификации человека или устройства.
| Создатель: | Various Developers |
| Категория файла: | Системные файлы |
| Ключ реестра: | HKEY_CLASSES_ROOT\.pfx |
Программные обеспечения, открывающие PKCS #12 Certificate File:
Adobe Acrobat DC, разработчик — Adobe Systems Incorporated
Совместимый с:
| Windows |
| Mac |
| Linux |
Certificate Manager Tool, разработчик — Microsoft Corporation
Совместимый с:
| Windows |
Ассоциации других файлов PFX
.PFX
| Формат файла: | .pfx |
| Тип файла: | First Choice Word Processing Document |
First Choice Обработка текстов документов представляет собой текстовый документ, созданный в текстовом процессоре First Choice. Это может быть преобразовано в другие форматы.
| Создатель: | SoftKey |
| Категория файла: | Текстовые файлы |
Программы, открывающие файлы First Choice Word Processing Document :
SoftKey PFS First Choice, разработчик — SoftKey
Совместимый с:
| Windows |
Библиотека JSSE
Провайдер SunJSSE предоставляет полную реализацию java.security.KeyStore формата PKCS#12 для чтения и записи файлов pkcs12. Этот формат также поддерживается другими инструментами и приложениями для импорта и экспорта ключей и сертификатов, такими как Netscape/Mozilla, Microsoft Internet Explorer и OpenSSL. Например, эти реализации могут экспортировать сертификаты и ключи клиента в файл с расширением «.p12».
С провайдером LirJSSE, вы можете получить ключи PKCS#12 через KeyStore API с типом хранилища «pkcs12». Кроме того, вы можете просмотреть список установленных ключей и соответствующих сертификатов с помощью команды keytool с опцией -storetype установленной в pkcs12.
На всякий случай, нужно иметь в виду, что в Java 6 JDK одни и те же классы поддержки хранилища PKCS#12 содержатся не только внутри JSSE, но и отдельно в пакете sun.security.pkcs12.
Реализация хранилища PKCS#12 в LirJSSE дополнительно поддерживает алгоритмы ГОСТ. Далее описываются особенности этой реализации.
Особенности реализации PKCS#12 в LirJSSE
При загрузке хранилища проверяется его целостность по дайджесту, после чего расшифровываются все цепочки сертификатов. Секретный ключ расшифровывается только по запросу с указанием конкретного алиаса, но в открытом хранилище продолжает находиться в зашифрованном состоянии. Шифрование всех цепочек сертификатов и вычисление дайджеста хранилища производятся только при сохранении хранилища в файле.
Цепочки сертификатов связываются с секретными ключами внутри хранилища по локальным идентификаторам. Локальный идентификатор – это массив байтов в формате UTF-8, образованный при добавлении нового ключа из строки “Time “, за которой следует текстовое представление даты и времени добавления элемента. При добавлении нового ключа всегда задаются также соответствующая цепочка сертификатов и пароль.
Новый секретный ключ может быть представлен для добавления в хранилище в открытой форме, либо в уже зашифрованном виде. В последнем случае пароль ключа не указывается.
В хранилище не могут одновременно содержаться ключи ГОСТ и не ГОСТ. Соответствующий внутренний тип хранилища устанавливается либо при его загрузке, либо при добавлении первого ключа. Если хранилище пустое, то тип его в этом смысле не определен.
Алиас ключевого элемента, вообще говоря, не обязателен. Если в хранилище оказался элемент без алиаса, то алиас ему назначается принудительно в виде внутреннего порядкового номера. Дело в том, что LirJSSE, как и Sun JSSE, работает с элементами хранилищ только по алиасам.
При создании элементов хранилища различными программами может несколько отличаться внутренняя структура хранения зашифрованных элементов. Из-за этого, например, одна и та же цепочка сертификатов может упаковаться в файле хранилища средствами LirSSL и LirJSSE в структуры разного размера. Стандарт это допускает, и на функциональность хранилища это не влияет.
При работе с JSSE не нужно забывать, что пароли ключевых элементов должны совпадать с паролем хранилища. Стандарт PKCS#12, вообще говоря, допускает использование различных паролей в одном хранилище, но SunJSSE и LirJSSE не поддерживают данную возможность.
По договоренности с фирмой Топ Кросс, пароль всего хранилища перед применением преобразуется в программе LirJSSE в формат UTF-16 (последние два байта – нулевые). А отдельные элементы хранилища защищаются тем же паролем, но в формате UTF-8.
Формат контейнера ключей[править | править код]
Формат контейнера был определен на основе формата, реализованного в 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 EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req. certificate EXPLICIT Certificate, -- X.509 certificate certChain EXPLICIT PKCS7CertChain—PKCS #7 cert.chain }
В этой простейшей форме открытый ключ хранится как SubjectPublicKeyInfo. Однажды, когда был сгенерирован запрос сертификации, ‘сырая’ информация о открытом ключе может быть заменена в соответствии с требованием и, когда ключ сертифицирован, или сертификат или, полный шифр сертификата может быть сохранен.
Компоненты закрытого ключаправить | править код
Компоненты закрытого ключа могут храниться как в зашифрованной так и не в зашифрованной форме. Зашифрованная форма рекомендуется пока данные не защищены другими средствами. Если данные хранятся в не зашифрованной форме, используется тип содержимого Data. Если же данные хранятся в зашифрованной форме, то используется тип EncryptedData с contentEncryptionAlgoritm — алгоритм шифрования, режим и дополнительные параметры, которые используются при генерации ключа. Содержимое или зашифрованное содержимое полей закрытого ключа (без соответствующих полей открытого ключа), который соответствуют полям открытого ключа, приведенным в 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#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 EXPLICIT PKCS10CertRequest, -- PKCS #10 cert.req.
certificate EXPLICIT Certificate, -- X.509 certificate
certChain EXPLICIT PKCS7CertChain—PKCS #7 cert.chain
}
В этой простейшей форме открытый ключ хранится как SubjectPublicKeyInfo. Однажды, когда был сгенерирован запрос сертификации, ‘сырая’ информация о открытом ключе может быть заменена в соответствии с требованием и, когда ключ сертифицирован, или сертификат или, полный шифр сертификата может быть сохранен.
Компоненты закрытого ключа
Компоненты закрытого ключа могут храниться как в зашифрованной так и не в зашифрованной форме. Зашифрованная форма рекомендуется пока данные не защищены другими средствами. Если данные хранятся в не зашифрованной форме, используется тип содержимого Data. Если же данные хранятся в зашифрованной форме, то используется тип EncryptedData с contentEncryptionAlgoritm — алгоритм шифрования, режим и дополнительные параметры, которые используются при генерации ключа. Содержимое или зашифрованное содержимое полей закрытого ключа (без соответствующих полей открытого ключа), который соответствуют полям открытого ключа, приведенным в 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); во-вторых, для того чтобы устранить возможность тривиального восстановления значимой суммы потока ключей, использую известные открытые поля в начале ключа.
Настройка агента HPD для работы с сервером клиентской верификации
На основании секретного ключа RSA и самозаверенного сертификата (Self-signed public certificate) создается PEM-файл, который пропасывается в hpd.conf в секцию настройки HTTPS-сервера с клиентской верификацией.
Команда:
user@server:~$ cat <Public Certificate Filename> <Key Filename> > <PEM File>
где:
- <Public Certificate Filename> — файл самозаверенного сертификата (Self-signed public certificate) в PEM-формате;
- <Private Key Filename> — файл секретного ключа RSA;
- <PEM File> — PEM-файл
Пример:
user@server:~$ cat pub_cert.crt private_key.key > cv-ssl.pem
PEM-файл нужно переместить в директорию /etc/hpd/cert (/etc/hydra/hpd/cert), и указать путь к нему в конфигурацинном файле hpd.conf, в секции настройки HTTPS-сервера с клиентской верификацией.
Пример:
... cv-ssl server status = on cv-ssl server ip = 0.0.0.0 cv-ssl server port = 9444 # Путь до PEM-файла сертификата HTTPS-сервера с клиентской верификацией cv-ssl server pem path = /etc/hpd/cert/cv-ssl.pem cv-ssl server plugins list = osmp ...
Режимы обмена информацией
Любые комбинации режимов конфиденциальности и честности допускаются в этом стандарте. Конечно, хорошая политика безопасности предполагает избежание определенных практик. Например, было бы глупо передавать закрытый ключ без какой-либо физической защиты.
Для обоих режимов (конфиденциальности и честности) предпочтительнее использовать открытый ключ, а не пароль. Однако не всегда предоставляется возможность пользоваться режимом с использованием открытого ключа. Например, если во время отправки мы не знаем достаточно сведений о платформе получателе. В этом случае режим с использованием открытого ключа будет только мешать.
Режим конфиденциальности
- С использованием открытого ключаИнформация шифруется с помощью открытого ключа платформы получателя, шифр открыт вместе с соответствующим ключом. Закрытый ключ находится на платформе получателя и используется для просмотра конфиденциальных данных, содержащихся в сообщении. Пересылка открытого ключа при этом называется TPDestEncK.
- С использованием пароляИнформация шифруется симметричным ключом, получаемым из имени пользователя и его пароля, так же как и в стандарте PKCS5.
Режим честности
- С использованием открытого ключаЧестность обеспечивается с помощью ЭЦП, получаемой использованием закрытого ключа платформы источника. Проверка производится путём использования на платформе получателе открытого ключа. Закрытый ключ находится на платформе источнике и используется до подписи персональной информации. Пересылка открытого ключа при этом называется TPSrcSigK.
- С использованием пароляЧестность гарантируется с помощью имитовставки, получаемой из пароля. При использовании обоих: режима честности с паролем и режима конфиденциальности с паролем, пароли могут как совпадать, так и не совпадать.
Форматы SSL-сертификаты
Таблица 1 содержит описание часто используемых форматов SSL-сертификатов.
Таблица 1. Форматы SSL-сертификаты
| Формат | Описание |
|---|---|
| PEM |
Самый распространенный формат сертификата. Файлы в таком формате имеют расширение .pem, .crt, .cer и .key (файл приватного ключа). Сами по себе файлы являются обычными ASCII-файлами, закодированными в формате Base64. При открытии такого сертификата в текстовом редакторе вы видите строку —BEGIN CERTIFICATE—, после чего следует закодированный сертификат, а после – строка —END CERTIFICATE—. Веб-сервер Apache использует формат PEM. В одном файле может содержаться несколько SSL-сертификатов и даже приватный ключ. В этом случае каждый сертификат отделяется от остальных тегами BEGIN и END. Однако Apache требует, чтобы сертификаты и приватный ключ должны быть в разных файлах. |
| DER | Бинарный тип сертификата – в отличие от PEM, где сертификат хранится в ASCII-файле. Файлы сертификатов в этом формате часто имеют расширение .cer, но можно встретить и расширение .der. Если перед вами файл с расширением .cer, то для вычисления его формата нужно открыть его в текстовом редакторе. Если вы увидите теги начала и окончания сертификата (BEGIN/END), то это формат PEM. Формат DER используется, как правило, на Java-платформах. |
| PKCS # 7 / P7B | Файл сертификата в этом формате хранятся в формате Base64 ASCII и имеют расширение файла .p7b или .p7c. В файлах находятся теги начала и окончания сертификата – «—— BEGIN PKCS7 ——» и ««—— END PKCS7 ——». Данный формат поддерживается Windows и Java Tomcat. |
| PFX | Бинарный формат, при использовании этого формата в зашифрованном файле хранятся ваш личный сертификат сервера, промежуточные сертификаты центра сертификации, а также закрытый ключ. PFX файлы, как правило, имеют расширение .pfx или .p12. Обычно используется в Windows для импорта и экспорта файлов SSL сертификатов и приватного ключа. |
Если облака для вас
не просто теория
Широкий спектр услуг
по выделенным северам
и мультиклауд-решениям
Конфигурация VPS и бесплатный тест уже через 2 минуты
Сконфигурировать VPS
Организация вашей IT-инфраструктуры на основе мультиклауд-решения
Запросить КП
BUGS
Some would argue that the PKCS#12 standard is one big bug 🙂
Versions of OpenSSL before 0.9.6a had a bug in the PKCS#12 key generation
routines. Under rare circumstances this could produce a PKCS#12 file encrypted
with an invalid key. As a result some PKCS#12 files which triggered this bug
from other implementations (MSIE or Netscape) could not be decrypted
by OpenSSL and similarly OpenSSL could produce PKCS#12 files which could
not be decrypted by other implementations. The chances of producing such
a file are relatively small: less than 1 in 256.
A side effect of fixing this bug is that any old invalidly encrypted PKCS#12
files cannot no longer be parsed by the fixed version. Under such circumstances
the pkcs12 utility will report that the MAC is OK but
fail with a decryption error when extracting private keys.
This problem can be resolved by extracting the private keys and certificates
from the PKCS#12 file using an older version of OpenSSL and recreating
the PKCS#12 file from the keys and certificates using a newer version
of OpenSSL. For example:
