Идеальный токен

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

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

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

Таким образом, с точки зрения безопасного существования криптографических ключей в автоматизированной системе (АС) принципиальное значение имеют два фактора:

• защищенное хранение ключа (и, соответственно, носитель ключа);
• условия доступа к ключу и работы с ним (т.е. среда функционирования криптографии (СФК)).

Очевидно и не нуждается в детализации, что второй фактор (условия доступа к ключу) касается и обработки, и передачи ключей как части технологии, реализуемой СКЗИ (СЭП) при выполнении своих функций.

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

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

Сложившаяся практика

Сложившаяся практика применения ключей такова, что в качестве их носителей используются универсальные накопители (дискеты, флешки), идентификаторы пользователей, если они представляют собой устройства с доступной для записи/чтения памятью (ТМ-идентифкаторы) или специализированные устройства (смарт-карты, USB-токены).

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

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

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

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

В части доступа к ключу очевидна необходимость учитывать как условия доступа пользователя (человека), так и условия доступа СКЗИ и другого системного и функционального программного обеспечения.

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

• доступ к ключу через любые интерфейсы, в том числе и путем применения разрушающего программного воздействия (РПВ);
• среду, в которой производится попытка доступа к ключу.

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

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

Такой токен – идеальный. Мы его сделали [1] и запатентовали [2].

Литература

1. Идеальный токен [электронный ресурс]. URL: http://prosecret.ru/idealtoken.html (дата обращения 02.04.2019).
2. Батраков А. Ю., Конявская С. В., Счастный Д. Ю. Съемный носитель ключевой и конфиденциальной информации. Патент на полезную модель № 147529. 10.11.2014, бюл. № 31.