Хранилища для криптографических ключей и сертификатов

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

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

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

Хранение приватных ключей и сертификатов в операционной системе и в браузере

Пример: хранение ключей и сертификатов в Windows

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

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

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

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

Хранение приватных ключей и сертификатов в операционной системе и в браузере обычно используется для:

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

.pfx и .jks файлы ( Keystores )

PKCS # 12 (.pfx или .p12) и .jks * (созданные Java keytool) - это файлы, содержащие вашу общедоступную / закрытую пару ключей. В отличие от локально хранимой ОС и веб-хранилищ браузера, эти файлы можно хранить практически в любом месте, включая удаленные серверы, и всегда защищены паролем (что означает, что в любое время вы хотите использовать свой закрытый ключ, вам нужно ввести пароль). Еще одна апелляция заключается в том, что, поскольку в конечном итоге это просто файлы, вы можете легко распространять копии, если у вас есть несколько человек, которым необходимо использовать сертификат.

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

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

.pfx и .jks файлы ( Keystores ) обычно используется для:

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

*Note: Похоже, что Java планирует перейти от JKS к PKCS # 12 по типу хранилища по умолчанию, но дата запуска не объявлена.

Криптографические токены и смарт карты

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

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

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

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

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

Криптографические токены и смарт карты обычно используется для:

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

Аппаратные модули безопасности (HSM)

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

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

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

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

Аппаратные модули безопасности обычно используется для:

• Высокий объем документов или подписание кода.
• SSL (в зависимости от конфигурации сервера).
• Инфраструктура CA для запуска собственного ЦС (корневой ЦС, суб-ЦС, сервер RFID 3161 Timestamping) - один может быть автономным, один онлайн (корневой ЦС обычно отключен).

Методы и способы хранения ключей следующего поколения

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

• Сертифицированны можули платформ (TPM)
  TPM сами по себе не новы, но использование их для защиты секретных ключей набирает все большее значение. TPM можно использовать для хранения (или обертывания) корневого ключа и защиты дополнительных ключей, созданных приложением. Ключи приложения не могут использоваться без TPM, что делает этот метод очень полезной аутентификации для конечных точек, таких как ноутбуки, серверы и производители устройств IoT. Хотя сегодня многие ноутбуки поставляются с TPM, мы не видим значительного принятия на корпоративном пространстве. Мы действительно много видим их в пространстве IoT, однако, когда они используются в качестве корневого сервера для надежного идентификатора устройства. IoT создал проблему, когда так много устройств, анонимно анонимно, облегчают хакерам перехватывание сообщений или представление их в качестве этих устройств. Поскольку чип можно ввести уже в процессе производства, он может быть использован для защиты криптографического ключа устройства и, следовательно, от идентификации устройства. Во время производства устройство генерирует пару частных и открытых ключей. Открытый ключ отправляется в ЦС для подписания и выдачи цифрового сертификата. Закрытый ключ никогда не покидает устройство и надежно хранится на чипе и не может быть экспортирован / скопирован / уничтожен. Сертификат теперь является идентификатором устройства, а защищенный закрытый ключ формирует основанный на аппаратном обеспечении корень доверия.
• Физически незакрепленные функции (PUF)
  Технология Physical Unclonable Function (PUF) представляет собой сдвиг парадигмы в защите ключа. Вместо ключей, которые хранятся (где они подвержены физической атаке), ключи вместо этого получают из уникальных физических свойств памяти SRAM чипа и существуют только при включении. То есть вместо надежного хранения закрытого ключа один и тот же ключ может быть повторно и снова (при жизни устройства) по требованию. Используя PUF на основе SRAM, они гарантированно будут уникальными, поскольку они используют присущую случайность в битовых структурах кремния. Технология PUF в сочетании с надежной средой выполнения (TEE) представляет собой привлекательное решение для потребностей рынка в требовании недорогой, простой в интеграции защиты от ультрабезопасных ключей. PUF совместно с PKI представляет собой комплексное решение для идентификации. Наш партнер, Intrinsic ID, создал такую ​​ключевую систему обеспечения, основанную на SRAM PUF, которая создает уникальные, не подлежащие выкупу, недобросовестные идентификаторы отпечатков пальцев устройства, внедренные в аппаратное обеспечение. Используя наши сертификационные службы, мы можем загружать эти отпечатки пальцев в цифровые идентификаторы и добавлять возможности PKI. Таким образом, каждое устройство заканчивается уникальной неподходящей ключевой парой, которая не сохраняется на устройстве при выключенном питании, но один и тот же ключ может быть восстановлен по требованию. Это защищает от атак, пока устройство (и его безопасность) отключено.