Файловое хранилище p12 что это

Файл формата P12 открывается специальными программами. Чтобы открыть данный формат, скачайте одну из предложенных программ.

Чем открыть файл в формате P12

Расширение P12 повсеместно используется в качестве основного формата для передачи персональных ключей электронной цифровой подписи (ЭЦП) и других персональных данных высокой категории значимости.

Реализован P12 файл в виде цифрового сертификата, закодированного в PKCS#12 (алгоритм шифрования Public Key Cryptography Standard #12).

Расширение P12 содержит в себе все зашифрованную информацию о персональном ключе владельца ЭЦП. Декодировать такие данные возможно только после интеграции подходящего открытого ключа. Взаимосвязь открытого и персонального ключа ЭЦП способствует верификации источника транслируемых данных.

Данная взаимосвязь актуальна и в обратном порядке: зашифрованная информация открытого ключа станет доступной только после интеграции персонального ключа владельца ЭЦП.

Расширение P12 является аналогом форматов WLMP и XMCD за исключением того, что кодирование данных в P12 производится с помощью другого алгоритма шифрования.

Плагины для открытия P12 файлов

Для открытия и воспроизведения P12 расширения на базе платформы ОС Windows можно воспользоваться одной из следующих программных утилит:

Формат P12 также адаптирован для других ОС, например, в Mac ОС расширение может быть открыто с помощью плагина Apple Keychain Access.

Если при попытке загрузить расширение ОС выдает ошибку: производится открытие P12 файла с использованием некорректного приложения.

Конвертация P12 в другие форматы

Конвертация или какие-либо другие преобразования формата P12 по определению невозможны.

Каждый сертификат, созданный на основе алгоритма шифрования PKCS#12, уникален и должен обеспечивать поддержку ключей ЭЦП.

Попытки трансляции сертификата P12 могут привести к необратимым последствиям. Зачастую может быть нарушена целостность передаваемых сообщений или корректная валидация открытого и персонального ключа владельца ЭЦП.

Почему именно P12 и в чем его достоинства?

Главное практическое назначение расширения P12 – обеспечение целостности (определения неизменности) транслируемых цифровых данных, и точное установления источника отправления.

Без интегрированных сертификатов ставится под угрозу безопасность сетевых ресурсов, серверов и доменов, электронной почты, конфиденциальность логинов и паролей пользователей.

Файл, содержащий цифровой сертификат, использующий шифрование PKCS#12 (Public Key Cryptography Standard #12). Применяется в качестве портативного формата для передачи личных ключей и другой важной информации.

Ключи P12 хранят персональный ключ, способный шифровать информацию, которую можно расшифровать только после ввода соответствующего открытого ключа. Это помогает ратифицировать источник передаваемой информации. Таким же образом, зашифрованные с помощью открытого ключа данные можно расшифровать только после ввода персонального ключа.

Чем открыть файл в формате P12 (Personal Information Exchange File)

Источник

Решено: Как установить ЭЦП в хранилище сертификатов Windows (для браузеров Internet Explorer, Google Chrome, Opera)

[nx_heading style=»underlined» heading_tag=»h2″ size=»32″]Как установить ЭЦП вручную[/nx_heading]

Инструкция позволяющая установить ЭЦП в браузеры Internet Explorer, Google Chrome, Opera — вручную.

Данные браузеры, а так же различные «поделки» от Mail.ru (браузер «Амиго», «Интернет») и Yandex («Яндекс.Браузер») основанные на Google Chrome, не имеют своего хранилища сертификатов, поэтому в работе используют хранилище сертификатов Windows. Процедура установки сертификатов ЭЦП для всех этих браузеров будет одинакова.

[nx_row][nx_column size=»1/6″]
ВНИМАНИЕ:
[/nx_column]

Если вам нужно установить ЭЦП в браузер Mozilla Firefox, воспользуйтесь этой инструкцией.[/nx_column][/nx_row]

Пример показан на ОС Windows 8 x64, но действия одинаковы на всех версиях Windows.

Дата обновления статьи: 17.10.2016

Для начала установки нам понадобится папка с ключами Электронно-цифровой подписи полученной в ЦОН.

Если вы Физическое Лицо (ФЛ) или Индивидуальный Предприниматель (ИП) в вашей папке с ключами будут лежать два файла вида:

Если вы представляете Юридическое Лицо (ЮЛ) в вашей папке с ключами будут лежать два файла вида:

Если же вы устанавливаете налоговый ключ (полученный в Налоговом Комитете), у вас имеется всего один ключ вида РНН_БИН.p12, устанавливаете именно его.

По этому единственному ключу выполняется и вход, и отправка форм налоговой отчетности.

[nx_heading style=»underlined» heading_tag=»h3″ size=»28″]Процесс ручной установки ЭЦП[/nx_heading]

Открываем папку с ЭЦП, щелкаем по файлу AUTH_RSA_ два раза левой клавишей мыши

Изображение 1. Файлы ЭЦП полученные в ЦОН

Выбираем Текущий пользователь и нажимаем Далее

Изображение 2. Начало процедуры установки ключей

В данном окне тоже нажимаем Далее

Изображение 3. Установка ключей ЭЦП

В строке ввода Пароль, вводим пароль на ключ, по-умолчанию пароль на ЭЦП устанавливаемый ЦОН: 123456

В данном окне нажимаем кнопку Обзор, чтобы вручную указать в какое хранилище ключей поместить новый ключ.

Изображение 5. Указываем хранилище сертификатов вручную

Устанавливаем галочку Показать физические хранилища

Изображение 6. Указываем хранилище сертификатов вручную

В нашем случае выбираем Реестр и нажимаем ОК.

Изображение 7. Указываем хранилище сертификатов вручную

Видим, что хранилище сертификатов стало Личное/Реестр и нажимаем Далее

Изображение 8. Указываем хранилище сертификатов вручную

Нажимаем Готово

Изображение 9. Окно завершения установки сертификатов

Данное окно подтверждает, что сертификаты ЭЦП успешно установлены в хранилище Windows.

Изображение 9. Окно успешной установки сертификатов

Теперь браузеры будут видеть установленный сертификат аутентификации и можно осуществлять процедуру входа на гос.порталы РК.

[nx_heading style=»centerlined» heading_tag=»h3″ size=»24″ align=»center»]Видеоурок: Установка ЭЦП для: Кабинет налогоплательщика РК, Комитет Статистики РК и др.[/nx_heading]

[nx_youtube_advanced url=»https://youtu.be/1N5uCJBKU5c» playlist=»https://www.youtube.com/playlist?list=PLK8Nq6FJOC4ftoGCntMYCYRXj245nGiu6″ width=»960″ height=»560″ https=»yes»]

[nx_heading style=»coloredline» heading_tag=»h4″ size=»24″ align=»left»]От автора:[/nx_heading]

Если проблема решена, один из способов сказать «Спасибо» автору, указан — здесь.

Если же проблему разрешить не удалось или появились дополнительные вопросы, задать их можно на нашем форуме, в нашей группе Whatsapp.

Или же, воспользуйтесь нашей услугой «Удаленная помощь» доверив решение проблемы специалисту.

Источник

PKCS12

PKCS #12 v1.0 / 1999-06-24 ; 4913 days ago
Technical Corrigendum 1 / 2000-02-25 ; 4667 days ago

X.509 public key certificates, X.509 private keys, X.509 CRLs, generic data

Microsoft PFX формат файла

Содержание

В этом стандарте описывается синтаксис передачи персональной идентификационной информации, включающей закрытые ключи, сертификаты, различные секреты и много другое. Этот стандарт поддерживает прямую передачу данных между платформой отправителем и платформой получателем. Стандарт поддерживает передачу данных как с высоким уровнем защиты (с помощью пары открытого/закрытого ключа), используемого для цифровой подписи и шифрования, так и с более низким уровнем защиты (с помощью авторизации по паролю), в том случае, если использование открытого/закрытого ключа недоступно.

Этот стандарт может быть рассмотрен как надстройка над стандартом PKCS8. Включена дополнительная идентификационная информация включающая закрытые ключи. Введен режим высокой безопасности с помощью сокрытия открытого ключа.

В руководстве по openssl этот формат охарактеризован, как один большой баг 🙂

Введение

Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в правительственных организациях, спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности все большее количество людей. В настоящее время все озабочены безопасностью передаваемых по сети данных. В результате чего появилось множество различных сертификатов, методов шифрования. В данной статье будет рассмотрен формат хранения ключей PKCS#12 и некоторые проблемы связанные с безопасным хранением закрытых ключей сертификатов.

Эти изменения выдвинули на первый план необходимость упрощения, безопасности и совместимости форматов хранения закрытых ключей. Задачи разработчиков для этого формата заключалась в следующем:

Связь с форматом PFX

PKCS # 12 является преемником «PFX» от Microsoft. Термины «PKCS # 12 файл» и «PFX файл» иногда используются как синонимы.

PFX получил тяжелую критику является одной из самых сложных криптографических протоколов, но тем не менее остается единственным стандартным способом сегодня для хранения закрытых ключей и сертификатов в одном зашифрованном файле.

Netscape использовал формат PFX, а не PKCS#12 в версиях 4.03 и ниже, потому что формат PKCS#12 просто не существовал. Из за необходимости обратной совместимости Netscape 4.04 и более новые версии, а также все версии MSIE поддерживали только импорт в формат PFX. Приведенная ниже таблица объединяет вышесказанное.

Режимы обмена информацией

Любые комбинации режимов конфиденциальности и честности допускаются в это стандарте. Конечно хорошая политика безопасности предполагает избежание определенных практик. Например, было бы глупо передавить закрытый ключ без какой-либо физической защиты.

Для обоих режимов (конфиденциальности и честности) предпочтительнее использование открытого ключа, а не пароля. Однако не всегда предоставляется возможность пользоваться режимом с использование открытого ключа. Например, если во время отправки мы не знаем достаточно сведений о платформе получателе. В этом случае режим с использованием открытого ключа будет только мешать.

Режим конфиденциальности

Режим честности

Формат контейнера ключей

Пара закрытого/открытого ключа состоит из двух наборов параметров. Открытые параметры с дополнительной идентификационной информацией, такой как имена пользователей и e-mail адреса, хранятся не зашифрованными. Закрытые параметры в основном хранятся с использованием некоторого механизма защиты, такого как шифрование.

Формат контейнера был определен на основе формата, реализованного в PKCS#7 и S/MIME. Следующий идентификатор объекта идентифицирует безопасный тип хранения содержимого закрытого ключа.

Безопасный тип хранения содержимого закрытого ключа должен иметь ASN.1 SecuredPrivateKey тип:

Поля типа SecuredPrivateKey имеют следующие значения:

Компоненты открытого ключа

Компоненты открытого ключа хранится в не зашифрованной форме. Сделано так, потому что нет достаточно веских причин для шифрования этих данных. Так как шифрование этих данных любым поточным шифром предоставляет атакующему значительно количество известного зашифрованного текста и, потому что должна быть возможность для пользователя получить доступ к его открытому ключу без запроса пароля. Информация о открытом ключе представлена в типе PublicKeyInfo:

В этой простейшей форме открытый ключ хранится как SubjectPublicKeyInfo. Однажды, когда был сгенерирован запрос сертификации, ‘сырая’ информация о открытом ключе может быть заменена в соответствии с требованием и, когда ключ сертифицирован, или сертификат или, полный шифр сертификата может быть сохранен.

Компоненты закрытого ключа

Причины, по которым хранятся только поля закрытого ключа заключаются в следующем: во-первых, для того чтобы избежать избыточности (все остальное уже содержится в PublicKeyInfo); во-вторых, для того чтобы устранить возможность тривиального восстановления значимой суммы потока ключей, использую известные открытые поля в начале ключа.

Поддерживаемые алгоритмы шифрования

PKCS#12 поддерживает следующие алгоритмы шифрования:

Кроме того также поддерживается режим PKCS#5 v1.5. Это позволяет пользоваться следующими алгоритмами:

Использование PKCS#5 v2.0 позволит использовать произвольный алгоритм шифрования.

OpenSSL может обрабатывать PKCS#5 v1.5 и v2.0 в файлах PKCS#12, однако другие реализации не поддерживаются.

В следующей таблице собраны данные о поддержки различного шифрования:

По умолчанию сильнейшее шифрование поддерживается всеми реализациями приложений, использующих PKCS#12: 3DES для закрытых ключей и RC2-40 для сертификатов. Также дополнительный опции позволяют шифровать сертификат с помощью 3DES.

Следует отметить, что в то время как множественные версии Netscape будут импортировать файлы с помощью разных алгоритмов, тогда как MSIE, кажется, поддерживает только RC2 и 3DES.

Обработка пароля пользователя

Существует несколько механизмов, позволяющий трансформировать пароль пользователя в ключ шифрования. Спецификация PKCS#5 ограничивается итерациями MD2 и MD5 для использования с ключами DES.

Для того, чтобы создать или преобразовать сертификат, вам необходимо программное обеспечение OpenSSL. SSL v3 функция, определена следующим образом:

страдает от того, что вход используемый для шага SHA-1 варьируется только несколькими битами входа, используемого на предыдущем шаге и от того, что это требует использования двух различных и фиксированных функций для преобразования пароля в ключ. В дополнение, определенная таким образом функция не позволяет итерируемую обработку необходимую для предотвращения перебора по словарю.

TLS функция расширяет SSL v3 функцию и определяется следующим образом:

Функция получения ключа X.9-42 определена специально в терминах SHA-1:

Это, наверное, худшая из всех функция получения ключа, использующая фиксированную хэш-функцию, изменяющая только единственный входной бит для каждого блока ключа, вводящая крошечное количество измененных дынных после установления пароля, а не до этого и не итерируемый.

Эти предположения выдвигают следующие требования для обработки пароля пользователя:

Другая полезная цель разработки заключается в том, чтобы сделать выход зависимым от алгоритма шифрования; ключ генерируется так, для того чтобы сделать key-recovery attack невозможными. Если тот же самый ключ используется для нескольких алгоритмов, то атакующий, который может получить ключ для одного алгоритма, может воспользоваться этой атакой во время использования других алгоритмов ( например, получение ключа DES позволяет получить примерно половину ключа IDEA). Сделав результат шага обработки ключа зависимым от алгоритма шифрования, режима и конфигурации, значит, что ключ, получаемый из того же самого пароля при помощи использования другого алгоритма режима или конфигурации не просто будет получить.

Эти требования предлагают следующий основной дизайн:

Параметры обработки пароля

Входные параметры для хэш-функции, используемые для генерации переменных состояния:

Поля типа StateHashData имеют следующие значения:

Входные параметры хэш-функции, используемой для получения ключа:

Идентификатор алгоритма обработки пароля

Когда используется тип EncryptedData, тогда содержимое contentEncryptionAlgorithm идентифицируется следующим образом:

id-passwordBasedEncryption OBJECT IDENTIFIER ::=

Поля типа PBEParameters имеют следующие значения:

Уязвимости

Однако, это не верно и в отношении объектов сертификата. Причина этого в том, что обеспечение целостности PKCS#12-файлов не является обязательной, как показано здесь:

Так как этот контроль опционален, то он может быть отключен и тогда содержимое файла может быть изменино без обнаружения или предупреждения. Таким образом контроль доступа не требуется для добавления объектов сертификата. В этом случае сертификаты используются в SSL PKI как Trust Anchor и это дает возможность злоумышленнику вставить Trust Anchor своего центра сертификации в эти файлы без необходимости какой-либо авторизации.

С того момента, как Trust Anchor злоумышленника вставлен в атакуемую систему она будет доверять и признавать любой сертификат, выпущенный центром сертификации атакующего.

Атака может быть произведена по схеме человек посередине, который перехватывает файлы в время транспортировки, вставляет вражеский Trust Anchor. В этом случае атака может так же работать против систем, не использующих PKCS#12-файлы, как хранилище ключей, но эта атака имеет недостаток, что фальшивый сертификат может быть обнаружен после выявления факта атаки.

Создание и преобразование сертификата

Расширение файла: «.p12» или «.pem». Эти файлы могут быть созданы с помощью OpenSSL.

Создание сертификатов PKCS#12

Подготовка окружения

Создайте каталог (например, cert) и перейдите в него. Создайте в нем пустой файл certindex.txt Выполните команды:

В этом каталоге создаем файл конфигурации openssl.conf следующего содержимого:

Создание сертификата сертифицирующей организации

При запросе пароля указывайте пароль не менее 4 символов. На все остальные запросы можно нажать Enter.

Создание пользовательского сертификата

Сначала зададим имя для файлов сертификата пользователя. Так как их может быть много, задание через переменную среды окружения позволит повторять этот шаг очень быстро для каждого пользователя.

Теперь для каждого пользователя создаем сертификат PKCS12. Выполняйте по одной команде:

При запросе пароля указывайте пароль, заданный при создании сертификата CA. На все остальные запросы можно нажать Enter.

Готовый файл: user-cert.p12

Этот файл можно импортировать в Firefox или Thunderbird, а потом использовать в OpenOffice.org.

Преобразование сертификата в формат PKCS#12

Предположим, что нам необходимо создать файл cert.p12. Допустим, что у нас имеются файлы с закрытым ключом prkey.pem и файл с сертификатом cert.pem. Выполнить это можно с помощью команды openssl pkcs12:

Создание списка недействительных сертификатов

По истечении определенного срока сертификат становится недействительным. Если это сертификат сотрудника, то, например, после его увольнения сертификат необходимо считать недействительным. Если секретный ключ сертификата стал достоянием общественности по каким-либо причинам, то его тоже необходимо внести в список недействительных сертификатов (CRL). Для управления CRL можно воспользоваться командой openssl ca.

Добавление ненужных сертификатов осуществляется с помощью команды:

После каждого применения revoke необходимо обновлять CRL командой

Больше информации можно узнать в мануале, использовав в терминале Linux команду man pkcs12 или по ссылке pkcs12(1).

Библиотека JSSE

Провайдер SunJSSE предоставляет полную реализацию java.security.KeyStore формата PKCS#12 для чтения и записи файлов pkcs12. Этот формат также поддерживается другими инструментами и приложениями для импорта и экспорта ключей и сертификатов, такими как Netscape/Mozilla, Microsoft Internet Explorer и OpenSSL. Например, эти реализации могут экспортировать сертификаты и ключи клиента в файл с расширением «.p12».

На всякий случай, нужно иметь в виду, что в 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.

Схема работы агентства по выдачи персональных сертификатов

Использование

Такие сертификаты используются в качестве ключей на защищенных веб-страницах и в электронной подписи OpenOffice.org.

Также PKCS#12-файлы используются в многих браузерах и почтовых агентах, таких как Netscape Navigator, MSIE, MS Outlook.

Также PKCS#12 используется в MatrixSSL, начиная с версии 3.3.2.

Источник