Журнал "Information Security/ Информационная безопасность" #2, 2019

Ключи отличаются от других данных только одним: компрометация ключей заметно более критична. Это значит, что принципиально никаких специфич- ных приемов для защиты именно клю- чей не требуется, просто меры защиты должны обеспечиваться несколько более тщательно, чем в отношении любых других данных. К сожалению, здравый смысл не всегда детермини- рует безопасное поведение, потому более жесткие требования по защите ключей (хотя вернее было бы сказать "систем с ключом") предъявляются и регуляторами. В свете требований к средствам элек- тронной подписи (СЭП), в которых взаи- моувязаны все три состояния ключа, это становится особенно наглядно: мы можем руководствоваться самыми разными соображениями, выбирая тип желатель- ной для нас в тех или иных обстоятель- ствах электронной подписи (ЭП), выбирая подходящее для нас СЭП, но как только мы выбрали усиленную ЭП (т.е. ЭП с ключом), мы попадаем в зону действия существенно более высоких требований. Таким образом, с точки зрения без- опасного существования криптографи- ческих ключей в автоматизированной системе (АС) принципиальное значение имеют два фактора: l защищенное хранение ключа (и, соот- ветственно, носитель ключа); l условия доступа к ключу и работы с ним (т.е. среда функционирования криптографии – СФК). Однако очевидно то, что криптогра- фия, как правило, является вспомога- тельным механизмом, а не основной целевой функцией системы, поэтому условно выделяемым третьим фактором можно считать степень влияния на информационную инфраструктуру. Есте- ственно, что удорожание и усложнение системы обычно желательно минимизи- ровать. Эта статья посвящена средству хра- нения ключей (токену 1 ), которое позво- ляет решить несколько большее число задач, чем обычно применяемые в этом качестве устройства, не требуя серьез- ных инфраструктурных изменений АС. Поэтому оно называется "идеальный токен". Сложившаяся практика Сложившаяся практика применения ключей такова, что в качестве их носи- телей используются универсальные накопители (дискеты, флешки), иденти- фикаторы пользователей, если они пред- ставляют собой устройства с доступной для записи/чтения памятью (ТМ-иден- тифкаторы) или специализированные устройства (смарт-карты, USB-токены). Токены предоставляют возможность использования хранимых на них ключей и сертификатов после предъявления ПИН-кода (авторизации пользователя). Казалось бы, таким образом блокируют- ся все уязвимости, связанные как с хра- нением, так и с доступом к ключу. Однако очевидно, что ограничение доступа к ключу только использованием ПИН-кода недостаточно. Ключ должен использоваться только в той системе, в которой обеспечена защита от несанк- ционированного доступа (а именно обес- печена доверенная СФК), а ПИН-код можно правильно ввести в любой среде. Токен не может определить, в какой системе производится попытка работы с ним, у него нет для этого никаких механизмов. Невозможность расшире- ния функций токена проистекает не из лени программистов, а из ограниченно- сти его архитектуры. Токен не идеален. Чем же опасна невозможность контро- лировать внешнюю среду? Например, в ней могут быть программные закладки, предназначенные для перехвата крипто- графической информации или перехвата управления компьютером. При правильно введенном ПИН-коде (а в некоторых слу- чаях и до введения ПИН-кода) все это вредоносное программное обеспечение получит доступ к ключам. В части доступа к ключу очевидна необходимость учитывать как условия доступа пользователя (человека), так и условия доступа СКЗИ и другого систем- ного и функционального программного обеспечения. Отсюда вытекают требования к защи- щенному ключевому носителю. Защи- щенный носитель ключа в идеальном случае должен быть способен контро- лировать: l доступ к ключу через любые интерфейсы, в том числе и путем применения разрушаю- щего программного воздействия (РПВ); l среду, в которой производится попыт- ка доступа к ключу. Естественно, задача "контроля" среды, из которой осуществляется доступ к ключу, сводится для токена к тому, чтобы доступ к ключу предоставлялся не просто исключительно легальному пользовате- лю, но и исключительно на заданных рабочих местах (наличие "правильной" среды на которых обеспечивается в уста- новленном в организации порядке). В случае реализации такой защитной меры при случайном или преднамерен- ном подключении токена к неразрешен- ному (а значит, недоверенному) ком- пьютеру устройство не будет примонти- ровано, значит ключи не будут доступны ни пользователю (даже легальному), ни системе (с потенциально функционирую- щими в ней вирусами и закладками). При этом будет исключено несанк- ционированное использование ключей легальным пользователем токена вне рамок его служебных задач. Это важно, так как само по себе СКЗИ не может определить правомерность формирова- ния данного документа на данном ком- пьютере и подписание его с помощью того или иного ключа. Такой токен – идеальный. Мы его сде- лали [1] и запатентовали [2]. Литература 1. Идеальный токен [электронный ресурс]. URL: http://prosecret.ru/idealto- ken.html (дата обращения 02.04.2019). 2. Батраков А. Ю., Конявская С. В., Счастный Д. Ю. Съемный носитель ключевой и конфиденциальной инфор- мации. Патент на полезную модель № 147529. 10.11.2014, бюл. № 31. l • 37 КРИПТОГРАФИЯ www.itsec.ru Идеальный токен лючи, как и любые данные, существуют в трех процессах: хранятся, обрабатываются (в том числе создаются и уничто- жаются) и передаются. Никаких других состояний у данных, и ключей в частности (как явлений этой сущности), не бывает. К АДРЕСА И ТЕЛЕФОНЫ ОКБ САПР см. стр. 48 NM Светлана Конявская, заместитель генерального директора ЗАО “ОКБ САПР”, к.ф.н. 1 Это слово используется в разных значениях, но в рамках данного текста условимся понимать токен только в одном из них: как защищенное тем или иным способом хранилище ключей в виде объектов PKCS. Реклама