Варианты хранения криптографических ключей

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

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

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

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

Некоторые веб-серверы (например, Apache Tomcat или Jboss).
Примечание: Java недавно перешла с JKS на PKCS#12 в качестве типа хранилища ключей по умолчанию.

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

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

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

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

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

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

Обязательно для подписания кода расширенной проверки (EV)
в соответствии с рекомендациями форума CA/Browser.
Рекомендуется для стандартной подписи кода в соответствии с минимальными
требованиями CA Security Council. Центры сертификации обязаны рекомендовать криптографическое
оборудование в качестве основного варианта выдачи сертификатов.
Если криптографическое оборудование не выдаётся, клиент должен подписать соглашение,
что будет хранить закрытый ключ на каком-то съёмном оборудовании (которое вынимается после подписания).

Требуется для цифровой подписи и получения доверенного статуса
в программах Adobe, в соответствии с требованиями Adobe Approved Trust List (AATL).
Отраслевые правила, такие как CFR 21 часть 11 от FDA и требования к цифровой подписи
в отдельных странах часто говорят о секретном ключе, который находится
в единоличном владении собственника. Хранение на криптографическом оборудовании отвечает этим требованиям.

Аппаратные криптографические модули (HSM)

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
они часто применяются для безопасной индентификации устройств как аппаратный корень доверия.

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

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

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

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

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

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

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

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

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