Неизвлекаемые ключи в облаке - путь через криптопровайдер

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

Программные и программно-аппаратные хранилища

Исторически первым распространенным методом хранения ключей в компьютерных системах прикладной криптографии стало использование обычной файловой системы. Этот подход имел много достоинств. Прежде всего, чтобы поместить ключевой контейнер (ключевую пару с дополнительной идентифицирующей информацией) в файловую систему не нужны дополнительные устройства. Разграничение доступа к контейнерам осуществляется исключительно штатными механизмами операционной системы. Модификацией данного подхода является использование съемных дисковых накопителей: раньше – дискет, сейчас – USB-флешек и смартфонов.

Основными криптографическими системами, использующими данный подход с самого начала своего существования, являются криптографические провайдеры – модули, реализующие интерфейс Microsoft CryptoAPI. Данный интерфейс оказался настолько удобным для использования в прикладных приложениях Windows, что до сих пор значительное количество приложений полагаются именно на него, а сам интерфейс даже портирован компанией КриптоПро на Unix-платформы. В России первой системой, которая на него полагалась, являлся криптографический провайдер «КриптоПро CSP», появившийся в 2001 году.

Со временем стало ясно, что хранение ключей в постоянной памяти компьютера или на дискете хоть и является удобным подходом, но имеет ряд недостатков с точки зрения устойчивости к моделям нарушителя, предполагающим возможность кратковременной компрометации системы. Таким образом, следующим шагом стало использование в качестве хранилища ключей пассивных смарт-карт и USB-токенов. В отличие от дискет (напомним, что речь всё еще идет о начале 2000-х), смарт-карты предоставили возможность хранения ключевого контейнера в защищенной памяти, доступ к которой разграничивался микроконтроллером самого устройства. Тем не менее, данные устройства всё еще не умели самостоятельно выполнять криптоалгоритмы, так что основным путем их использования стало подключение к программным криптопровайдерам, которые использовали токены только для одной задачи: считать ключ из их памяти в оперативную память компьютера. Наиболее распространенными представителями данного семейства носителей являются такие токены и смарт-карты как Safenet eToken, Актив Рутокен Лайт, Gemalto Optelio, Alioth SCOne, и т.п.

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

Несмотря на то, что данные устройства могут встраиваться в автоматизиованные системы через независимые библиотеки, бесшовный переход на их использование возможен только через соответствующие криптопровайдеры. Одним из них стал, например, «КриптоПро Рутокен ФКН», который в связке с «Актив Рутокен ЭЦП» мог легко заменить связку «КриптоПро CSP» с «Актив Рутокен Лайт», если пользователи хотели начать использовать неизвлекаемые ключи.

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

Повышение уровня безопасности при использовании данных токенов также является достаточно спорным: если раньше нарушитель мог «встать посередине» между токеном и криптопровайдером и украсть ключ, то теперь его задачей стала просто кража ПИН-кода, который в большинстве случаев предъявляется либо в открытом виде, либо с использованием тривиального алгоритма, который легко может быть восстановлен опытным злоумышленником. Конечно, есть защищенные протоколы аутентификации на токенах, например, протокол SESPAKE (рекомендация по стандартизации Р 50.1.115-2016), но они начали распространяться только недавно, а реализующие их носители еще не доступны для продажи.

Удаленные и облачные хранилища

Еще одним распространенным видом ключевых хранилищ являются HSM (Hardware Security Module) – защищенные программно-аппаратные комплексы. По сути они представляют собой полноценные защищенные ЭВМ (уровень безопасности вплоть до KB2), доступ к которым осуществляется по защищенным сетевым протоколам. Несмотря на то, что они обеспечивают практически предельную степень безопасности ключей, их удобство использования оставляет желать лучшего: размещение HSM возможно только в защищенных помещениях внутри компании, а для доступа используются специальные утилиты.

Развитием идеи HSM стало появление удобных удаленных сервисов электронной подписи (Digital Signature Service - DSS). Подход DSS заключается в том, что все ключи пользователей хранятся в защищенном хранилище HSM, который может принадлежать как компании-работодателю, так и независимой доверенной организации, например, удостоверяющему центру, а доступ к ключам осуществляется через Web-интерфейс. Одним из таких комплексов является, например, «КриптоПро DSS», на который было получено положительное заключение на соответствие уровню КС3.

Данный подход позволил расширить использование HSM с одной небольшой выделенной локальной сети до крупной сети компании и даже сети Интернет. При использовании DSS пользователи могут подписывать документы с любой точки земного шара, будучи полностью уверенными, что их ключи находятся в безопасности, а доступ к ним может быть осуществлен любым удобным защищенным способом. Переход на удаленное использование ключей также позволяет перевести систему из разряда дорогих программно-аппаратных комплексов в дешевую массовую услугу.

Разумеется, у DSS остается существенный недостаток – сложность встраивания в существующие системы. Web-интерфейс – это хорошо, но что делать компаниям, которые хотят повысить безопасность своей автоматизированной системы без серьезных затрат в разработку нового прикладного ПО взамен существующего, которое уже много лет использует CryptoAPI?

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

Рисунок 1. Принципиальная схема системы использования «облачного токена»

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

Кратко содержание нашей статьи можно представить в виде следующей сравнительной таблицы:      

  Способ хранения Высокая скорость Низкая цена Использование пользовательского ключа на удаленном рабочем месте
  Встраивание в существующие системы через CryptoAPI Защита ключа от кражи или утери Защищенный канал доступа к ключам CSP + HDD + + - + + + CSP и пассивный токен + - + + - - Активный токен - - + - - - CSP + активный токен - - + + - - HSM + - - + + + HSM + DSS + + + - + + «Облачный токен»: HSM + DSS + CSP + + + + + +