несколько самых явных сценариев.
Начнем с добросовестного бухгалтера (а их все-таки, мы уверены, большинство). Из лучших побуждений – выполнять часть работы сверхурочно – он может организовать себе дополнительное рабочее место дома. При этом он может разделить работы по критичности и для «домашнего» выполнения выделить не платежи, а только подготовку и отправку в налоговую инспекцию отчетов в электронном виде. Это делается с помощью одной из специальных программ, например «Фельдъегерь» («Доклайнер», «Контур-Экстерн»), и бухгалтеру на его домашнем компьютере даже не потребуется «Клиент-Банк».
Скорее всего, из средств защиты от НСД на этом «дополнительном рабочем месте» будет в лучшем случае только антивирус. Эта ситуация создаст предпосылки для компрометации ключа с помощью широко распространенных вредоносных программ. В случае направленной атаки это позволит злоумышленнику в дальнейшем использовать украденный ключ в своих целях. Если же компьютер используется и для проведения платежей, а не только для подготовки и отправки отчетов, то задача злоумышленника и вовсе упрощается.
Все еще хуже, если злоумышленником является сам бухгалтер (надеемся, что не доведем никого до греха).
Итак, если бухгалтер задумал провести нелегальный платеж, что его может остановить? Теоретически его должна сдержать неотказуемость от ЭП на его ключе.
Однако в действительности при наличии технической возможности передачи ключевого носителя другому лицу и одновременно возможности применения ключа на произвольном СВТ неотказуемость от ЭП – это уже вопрос алиби, а не криптографии.
Представим себе такой «детективный сюжет»: злоумышленник организует рабочее место с необходимым для проведения платежа программным обеспечением. На собственном рабочем месте он подготавливает накануне несколько платежных поручений, подписанных его ЭП, но не отправляет их.
Вечером бухгалтер передает сообщнику токен с ключом ЭП и договаривается о времени проведения незаконного платежа таким образом, чтобы сам владелец ключа в это время был на рабочем месте, на глазах у свидетелей.
В результате в условленное время злоумышленник находится на виду у будущих свидетелей и отправляет заранее подготовленные платежки со своей легальной ЭП (токен ему для этого не нужен, ведь документы подписаны заранее). В это же время в другом месте с другого компьютера другое физическое лицо (сообщник) подписывает ключом нашего героя другое платежное поручение, используя токен.
При разборе инцидента владелец ключа имеет все шансы отказаться от своей ЭП, так как находился в это время на собственном рабочем месте и даже отправлял другой документ с подписью на том же ключе, а никаких следов отправки нелегального платежа на его рабочем СВТ нет. Очевидно, что он совершенно ни при чем.
Чтобы избежать обвинений в предвзятости к бухгалтерам, приведем пример, никак не связанный с платежами.
Предположим, что злоумышленником движет желание осуществить атаку на корпоративную информационную систему, обрабатывающую информацию ограниченного доступа.
Предположим также, что система распределенная централизованная (допустим, система терминального доступа или веб-система). Документы обрабатываются на сервере, сервер надлежащим образом защищен, клиентские СВТ не содержат средств обработки информации («тонкие клиенты»), загружаются с обеспечением доверенности клиентской ОС, и каналы между клиентами и сервером тоже защищены.
Ключи СКЗИ, защищающего канал, хранятся в токене.
Наиболее очевидная атака – это подключение в качестве терминального клиента произвольного СВТ злоумышленника, оснащенного программами для осуществления какой-либо атаки на систему.
Если атаку осуществляет легальный пользователь системы – он обладает идентификатором к СЗИ НСД на сервере и токеном с ключами СКЗИ, защищающего канал (зачастую это одно и то же устройство).
Именно таких случаев касается п. 31 Требований к средствам электронной подписи [31]: «В состав средств ЭП классов КС3 должны входить компоненты, обеспечивающие:…управление доступом субъектов к различным компонентам и (или) целевым функциям средства ЭП и СФ на основе параметров, заданных администратором или производителем средства ЭП…». Предотвратить эту атаку может только применение комплексной системы защиты, включающей взаимную аутентификацию клиентского СВТ и сервера. Это не рядовая функция, зачастую относительно сервера аутентифицируется только пользователь.
Все эти леденящие кровь сценарии невозможны, если токен просто различает СВТ, к которым его подключают.
Итак, защищенный ключевой носитель должен:
1) быть персональным отчуждаемым устройством;
2) быть специализированным именно для хранения ключей устройством (т. е. обеспечивать возможность защищенного хранения криптографических ключей с применением интерфейсов работы со смарт-картой (CCID или PKCS#11));
3) предоставлять доступ к ключам только легальному пользователю после успешной аутентификации в устройстве;
4) предоставлять легальному пользователю доступ к ключам только на тех СВТ, на которых данному пользователю разрешено работать с данным ключевым носителем.
«Идеальный токен»
Функции токена с функцией ограничения числа разрешенных компьютеров объединяет в себе «Идеальный токен» – токен с несколько измененной архитектурой: она включает в себя блок идентификации компьютера, до прохождения проверки которым недоступен в том числе и блок идентификации/аутентификации пользователя (рис. 69).
Рис. 69. «Идеальный токен»
В «Идеальном токене» есть две роли пользователей: «Администратор» и собственно «Пользователь». Список компьютеров, на которых разрешена работа с «Идеальным токеном», определяется пользователем с ролью «Администратор», который с точки зрения информационной системы должен быть администратором информационной безопасности или лицом, которому делегированы соответствующие функции.
Для того чтобы добавить компьютер в список разрешенных, администратор подключает к нему «Идеальный токен», программное обеспечение токена определяет, а внутреннее программное обеспечение запоминает внутри устройства ряд параметров этого рабочего места. При каждом последующем подключении «Идеальный токен» определяет параметры текущего компьютера и сравнивает их с теми данными, которые соответствуют разрешенным рабочим местам. Если данные совпадают, разрешается доступ к токену со стороны внешнего ПО – то есть, собственно, со стороны СКЗИ (СКЗИ – это внешнее по отношению к «Идеальному токену» ПО), в противном случае в доступе отказывается.
Очевидно, что ни одно иное устройство, применяемое для защищенного хранения ключей, не выполняет более трех требований к защищенным ключевым носителям одновременно (см. табл. 3). При этом важнейшее требование, касающееся СФК, не выполняется ни одним из таких устройств.
«Идеальный токен» является специализированным устройством, предназначенным именно для хранения ключей СКЗИ и поддерживающим все необходимые для этого интерфейсы.
Использование «Идеального токена» возможно только после успешного завершения взаимной аутентификации токена и компьютера, к которому его подключили, а затем успешной аутентификации пользователя в токене и СКЗИ.
Таким образом, при корректной настройке системы управляющим персоналом исключена возможность сознательной или случайной компрометации ключей из-за подключения к незащищенному компьютеру, на котором могут быть предустановлены программные закладки, предназначенные для перехвата ключей или перехвата управления компьютером. А также, что не менее важно, исключено несанкционированное использование ключей легальным пользователем токена – вне рамок его служебных задач, что невозможно предотвратить при использовании обычных токенов, не различающих служебные и любые другие ПК.
В то же время «Идеальный токен» лишен каких бы то ни было избыточных функций, негативно влияющих на цену изделия.
Технология «Идеального токена» запатентована [70].
Обзор ключевых хранилищ
Смарт-карты
Смарт-карты обычно обладают весьма скромным объемом памяти данных (десятки килобайт), однако этого достаточно для хранения ключей или сертификатов. Для доступа к данным необходим ввод PIN-кода. Устройство
