Невозможно открыть хранилище ключей файл хранилища поврежден

Обновлено: 06.07.2024

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

Во многих случаях секретные ключи — личные удостоверения ваших сотрудников (и, следовательно, часть персональных данных организации), так что их защита приравнивается к защите отпечатков пальцев при использовании биометрических учётных данных. Вы же не позволите хакеру добыть отпечаток своего пальца? То же самое и с секретными ключами.

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

Примеры: хранилище сертификатов Windows, связка ключей Mac OS

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

Ещё один плюс такого варианта — его довольно легко настраивать. Вы можете включить/отключить экспорт закрытого ключа, включить для него надёжную защиту (ввод пароля при каждом использовании сертификата), и можно создать резервные копии, если закрытый ключ экспортируется. Кроме того, при включении роуминга профилей в Windows сертификат привязывается к профилю и становится доступным при входе на другой компьютер с этим профилем.

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

И последнее: Chrome и IE используют хранилище сертификатов Windows, в то время как у Firefox собственное хранилище сертификатов (от Mozilla). Это значит, что если вы импортируете сертификат в хранилище Windows, то Chrome и IE автоматически найдут его, а Firefox нет.

Типичные приложения:

Приложения для цифровой подписи (например, Adobe Acrobat, Microsoft Outlook и Office будут обращаться в хранилище сертификатов Windows [пользовательское]).
Сервер Microsoft IIS тоже ищет SSL-сертификаты в хранилище сертификатов Windows [общем для компьютера].
Аутентификация клиента (пользователя или компьютера), в зависимости от настроек, чаще всего обращается к хранилищу сертификатов Windows.
Подпись кода в Windows (приложения и драйверы).

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

Если вы не можете использовать криптографическое оборудование или хранилище ключей Windows (описано выше), но всё же хотите повысить безопасность (вместо того, чтобы просто разместить файл хранилища ключей на компьютере), то можно записать этот файл на флэшку, которая будет лежать в безопасном месте. Конечно, здесь теряется некоторое удобство, так что если нужно часто использовать подпись, то вы скорее захотите хранить файл локально для облегчения доступа.

Типичные приложения:

Подписание кода Windows или Java. и IRS IDES используют .pfx для безопасной связи с американскими госслужбами.
Некоторые веб-серверы (например, Apache Tomcat или Jboss).

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

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

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

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

Типичные приложения:

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

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

Обязательно для подписания кода расширенной проверки (EV) в соответствии с рекомендациями форума CA/Browser.
Рекомендуется для стандартной подписи кода в соответствии с минимальными требованиями CA Security Council. Центры сертификации обязаны рекомендовать криптографическое оборудование в качестве основного варианта выдачи сертификатов. Если криптографическое оборудование не выдаётся, клиент должен подписать соглашение, что будет хранить закрытый ключ на каком-то съёмном оборудовании (которое вынимается после подписания).
Требуется для цифровой подписи и получения доверенного статуса в программах Adobe, в соответствии с требованиями Adobe Approved Trust List (AATL).
Отраслевые правила, такие как CFR 21 часть 11 от FDA и требования к цифровой подписи в отдельных странах часто говорят о секретном ключе, который находится в единоличном владении собственника. Хранение на криптографическом оборудовании отвечает этим требованиям.

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

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

Примером может служить знакомый многим сервис Key Vault в облаке Microsoft Azure, которое хранит криптографические ключи в облачном HSM от Microsoft. Если у вас небольшая организация, которая не позволит себе покупку и управление собственным HSM, то это отличное решение, которое интегрируется с публичными центрами сертификации, включая GlobalSign.

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

Типичные приложения:

Подпись документов или кода в большом количестве.
SSL (в зависимости от конфигурации сервера).
Инфраструктура ЦС для работы собственного ЦС (корневого ЦС, подчинённого ЦС, сервера меток времени RFC 3161) в офлайне или онлайне (корневой ЦС, как правило, работает в офлайне).

Мы рассмотрели основные варианты, которые использовались в течение многих лет. Но кажется, что ничто в мире информационной безопасности, в том числе и хранение ключей, не застраховано от влияния IoT, так что разрабатываются новые варианты.

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

Доверенный платформенный модуль (TPM)

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

При производстве генерируется пара из закрытого и открытого ключей. Открытый ключ отправляется в центр сертификации для подписания и выдачи цифрового сертификата. Закрытый ключ никогда не покидает устройство. Он хранится на чипе и не может быть экспортирован/скопирован/уничтожен. Теперь сертификат — это паспорт устройства, а защищённый закрытый ключ формирует аппаратный корень доверия.

Мы тесно сотрудничаем с Infineon для разработки решений Интернета вещей, сочетающих идентификацию устройств на основе PKI с корнями доверия на основе TPM. Для получения дополнительной информации ознакомьтесь с подтверждением концепции: «Безопасная аутентификация и управление оборудованием с помощью облачных служб сертификатов GlobalSign и OPTIGA TPM от Infineon.»

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

Технология PUF в сочетании с доверенной средой исполнения (TEE) — привлекательное решение, если требуется недорогая, простая в интеграции и ультра-безопасная защита ключа. PUF вместе с PKI составляют исчерпывающее решение для идентификации.

Наш партнёр Intrinsic ID разработал такую систему подготовки ключа на основе SRAM PUF, которая производит уникальные, защищённые от подделки и копирования идентификаторы устройств на аппаратном уровне. Используя наши службы сертификации, мы переводим эти идентификаторы в цифровые удостоверения, добавляя возможности PKI. Таким образом, каждому устройству присваивается уникальная, защищённая от клонирования пара ключей, которая не хранится на устройстве в выключенном состоянии, но устройство способно воссоздать этот ключ по запросу. Это защищает от атаки на выключенное устройство.

Дополнительно о нашем совместном решении для идентификации
устройств Интернета вещей см. недавний вебинар: «Стойкие идентификаторы устройств с сертификатами на основе SRAM PUF».

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

_______________________________________________________

АКЦИЯ GLOBALSIGN: Wildcard SSL + 1 ГОД В ПОДАРОК
Защитите все субдомены одним сертификатом!

Экономьте до 30 тысяч рублей при покупке сертификата Wildcard SSL на 2 года!
Промо-код: WC001HRFR

Акция действует для подписчиков блога GlobalSign до 15 июня 2018 г.

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

Что может послужить причиной такой ошибки

установка сертификата впервые;
экспортирование данных на внешний носитель;
попытка просмотра ключей в контейнерах ключей;
загрузка информации на компьютер извне.

В целях устранения ошибки обычно бывает достаточно произвести корректную ручную переустановку сертификата.

Решение ошибки: отсутствие электронного сертификата в контейнере закрытого ключа

Для начала запускаем «КриптоПро» нажатием кнопки «Пуск». Затем выбираем «Настройку», в возникающем на мониторе окне заходим в опцию панели управления, далее «сервис – установить личный сертификат».

Далее, через кнопку «обзор» указываем путь, где сохранен открытый ключ – файл с расширением *.cert или *.crt

Жмём «Далее», в мастере установки сертификата мы увидим путь, который указывали до нашего сертификата.

Нам отображается информация, содержащаяся в открытом ключе на пользователя, жмём «далее»

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

«найти контейнер автоматически
вручную через «обзор»

В первом случае КриптоПро на основе данных из открытого ключа подберет закрытый, в случае с ручным поиском нужно будет знать название закрытого ключа, чтобы выбрать его для установки

Самый простой вариант выбрать автоматический поиск, затем после «обнаружения» необходимого контейнера, мы увидим заполненную строчку с его именем и после жмём «Далее»

Личный сертификат пользователя всегда устанавливается в хранилище «Личное», можно выбрать как вручную, так и КриптоПро может сделать это за вас по умолчанию, затем подтверждаем установку цепочки сертификатов и жмём «Далее»

В случае успешной установки КриптоПро выдаст окно с информацией об окончании процедуры и жмём «Готово»

Затем появится окно с подтверждением данной операции, жмём «ДА»

В следующем окне увидим информацию о том, что процесс окончен успешно. Сертификат установлен в контейнер закрытого ключа.

Особенности версий КриптоПро

С января 2019 года квалифицированные сертификаты могут выпускаться только по ГОСТ 2012, выпуск по другому ГОСТу прекращен. Мы об этом писали ранее в статье. Важно помнить, что версии криптопро на ГОСТ 2012 работают только с версии 4.0 и выше. Все старые версии КриптоПро, для нормальной работы, потребуется обновить или заменить на актуальную. Сделать это нужно не позднее 31 декабря 2019 года.

В статье освещены основные проблемы при работе с сертификатами (ключами) ЭЦП НУЦ РК:

-невозможно зайти в кабинет налогоплательщика, в egov.kz и др. сервисы еПравительства РК.

В основе правильной работы большинства сервисов электронного правительства РК лежит установка утилиты NCA Layer, которая также содержит корневые сертификаты удостоверяющего центра. Поэтому, даже если какой-либо портал (например ЭСФ или кабинет налогоплательщика) не использует в работе данную утилиту, мы все же рекомендуем установить (обновить) ее.

ШАГ 1. Проверьте утилиту NCA Layer.

Необходимо проверить обновление утилиты, а также запущена ли она.

Значок этой уттилиты отображается в области уведомлений системы (возле значка переключения языков).

Значок выглядит так:

Если область уведомлений свернута то так:

В ДОПОЛНЕНИЕ ВАЖНО!

Если Вы используете Кабинет Налогоплательщика, то также в NCA Layer необходимо установить Модуль knpplugin.

Если Вы используете сайт Электронные счет-фактуры, то Вам необходимо установить модуль ЭСФ в NCA Layer

ШАГ 2. Проверяем настройки сертификатов и браузера
Выберите вариант браузера, с которым Вы работаете.

Если Вы используете Google Chrome, то дополнительные настройки не требуются.

Откройте браузер Mozilla Firefox

Зайдите на официальный сайт >>> НУЦ РК <<<, чтобы установить корневые сертификаты.

Прокрутите вниз страницы и скачайте корневые сертификаты.

Закрываем браузер Firefox , открываем заново и пробуем воспользоваться сервисом электронного правительства.

Вы можете также посмотреть короткое видео, как быстро проверить все настройки ЭЦП в компьютере (данное видео устарело, но в целом верно отражает настройки).

Не удалось решить проблему? Обращайтесь к нам через форму обратной связи.

Иногда во время установки сертификатов электронной цифровой подписи через КриптоПро после выбора ключевого контейнера возникает ошибка: «В контейнере закрытого ключа отсутствует открытый ключ шифрования». Ее устранение в большинстве случаев не требует обращения в службу поддержки пользователей: достаточно лишь следовать пошаговой инструкции установки в контейнер закрытого ключа подписи.

Причины возникновения ошибки

Ошибка «В контейнере закрытого ключа отсутствует сертификат открытого ключа» может возникать во время установки нового личного сертификата, а также при попытке просмотра закрытых ключей через контейнеры или при экспорте данных с компьютера на флешку или с электронного носителя на ПК.

Пошаговая инструкция установки личного сертификата

Чтобы установить личный сертификат, не записанный на ключевой носитель, нужно:

Запустить программу КриптоПро: «Пуск»/«Настройка»/«Панель управления»/«КриптоПро CSP».
Перейти через раздел «Сервис» во вкладку «Установить личный сертификат».

Нажать «Далее».
Указать путь к закрытому ключу электронной цифровой подписи через кнопку «Обзор». Пользователь в открывшейся папке выбирает файл, заканчивающийся расширением .cer.
После этого пользователю предстоит нажать «Открыть».

Следующий шаг — это выбор ключевого контейнера. Пользователь должен:

В рабочем окне «Контейнер закрытого ключа» нажать «Обзор» и выбрать контейнер, соответствующий названию ЭЦП.

Нажать «Далее» после того, как в графе «Имя ключевого контейнера» появится название контейнера.
При необходимости ввести пин-код ключевого носителя.

Затем нужно выбрать хранилище. Делает это так:

Пользователь нажимает «Обзор» и выбирает «Личное хранилище».

После того как название хранилища отразится в соответствующей графе пользователь нажимает «Далее».

После выбора контейнера для подтверждения установки нужно нажать «Готово».

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

Установка в КриптоПРО версии 3.62 R2

Установка личного сертификата в КриптоПро версии 3.62 R2 и выше происходит иначе. В окне программы следует выбрать пункт «Установить» и подтвердить замену (если требуется). Если запроса на замену не вышло, нужно открыть вкладку «Сертификат для просмотра» и выбрать «Свойства».

В новом окне выбрать пункт «Установить».

После этого запустится «Мастер установки», в котором нужно нажать кнопку «Далее». После этого следует выбрать пункт «Поместить все сертификаты в хранилище». Для выбора хранилища нужно нажать «Обзор».

Для дальнейшей установки нужно выбрать «Личное хранилище».

Ошибка отсутствия ключа электронной цифровой подписи в контейнера возникает обычно из-за отсутствия соответствующего сертификата. Решить проблему просто: установить личный сертификат и перезагрузить ПК. Способ установки зависит от версии используемого программного обеспечения КриптоПро и занимает всего несколько минут. Если после замены или установки открытого ключа проблема не исчезла, лучше обратиться в сервисный центр для перевыпуска электронной подписи.

Читайте также: