Ключевые носители

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

Никаких других состояний у данных — и ключей как явлений этой сущности — не бывает.

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

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

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

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

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

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

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

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

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

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

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

Обзор этих видов «хранилищ ключей» (невозможно использовать данную формулировку без кавычек, так как далеко не все эти объекты хотя бы минимально приспособлены к хранению именно ключей) приведен ниже. Из обзора исключены дискеты, так как побочным эффектом развития вычислительной техники, все реже имеющей дисководы для дискет, явилось и постепенное отмирание применения этого носителя и в этой конкретной функции.

Здесь невозможно не вспомнить снова аксиому о том, что для специальных целей логично применять специализированные средства.

Однако и специализированные средства — токены113 — не идеальны.

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

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

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

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

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

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

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

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

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

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

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

Однако на самом деле представить себе сценарий как случайной, так и злонамеренной компрометации ключа и документа — несложно.

Предположим несколько самых явных.

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

Скорее всего, из средств защиты от НСД на этом «дополнительном рабочем месте» будет в лучшем случае только антивирус. Эта ситуация создаст предпосылки для компрометации ключа с помощью широко распространенных вредоносных программ. В случае направленной атаки это позволит злоумышленнику в дальнейшем использовать украденный ключ в своих целях. Если же компьютер используется и для проведения платежей, а не только для подготовки и отправки отчетов, то задача злоумышленника и вовсе упрощается.

Все еще хуже, если злоумышленником является сам бухгалтер (надеемся, что не доведем никого до греха).

Итак, если бухгалтер задумал провести нелегальный платеж, что его может остановить? Теоретически, его должна сдержать неотказуемость от ЭП на его ключе.

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

Нарисуем такой «детектив»: злоумышленник организует рабочее место с необходимым для проведения платежа ПО. На собственном рабочем месте он подготавливает накануне несколько платежных поручений, подписанных его ЭП, но не отправляет их.

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

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

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

Чтобы избежать обвинений в предвзятости к бухгалтерам, приведем пример, никак не связанный с платежами.

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

Предположим, что система — распределенная централизованная (допустим, система терминального доступа, или web-система).

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

Ключи СКЗИ, защищающего канал, хранятся в токене.

Наиболее очевидная атака — это подключение в качестве терминального клиента произвольного СВТ злоумышленника, оснащенного программами для осуществления какой-либо атаки на систему.

Если атаку осуществляет легальный пользователь системы — он обладает идентификатором к СЗИ НСД на сервере и токеном с ключами СКЗИ, защищающего канал (зачастую это одно и то же устройство).

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

Все эти леденящие кровь сценарии невозможны, если токен просто различает СВТ, к которым его подключают.

Итак, защищенный ключевой носитель должен:

  • быть персональным отчуждаемым устройством;
  • быть специализированным именно для хранения ключей устройством (то есть обеспечивать возможность защищенного хранения криптографических ключей с применением интерфейсов работы со смарт-картой (CCID или PKCS#11));

  • предоставлять доступ к ключам только легальному пользователю после успешной аутентификации в устройстве;
  • предоставлять легальному пользователю доступ к ключам только на тех СВТ, на которых данному пользователю разрешено работать с данным ключевым носителем;
  • удовлетворять требованию патентной чистоты.

Функции токена с функцией ограничения числа разрешенных компьютеров объединяет в себе «Идеальный токен» — токен с несколько измененной архитектурой: она включает в себя блок идентификации компьютера, до прохождения проверки которым недоступен в том числе и блок идентификации/аутентификации пользователя.

В «Идеальном токене» есть две роли пользователей — «Администратор» и собственно «Пользователь». Список компьютеров, на которых разрешена работа с «Идеальным токеном», определяется пользователем с ролью «Администратор», который с точки зрения информационной системы должен быть администратором ИБ или лицом, которому делегированы соответствующие функции.

Для того чтобы добавить компьютер в список разрешенных, Администратор подключает к нему «Идеальный токен», его СПО определяет, а ВсПО запоминает внутри устройства ряд параметров этого рабочего места. При каждом последующем подключении «Идеальный токен» определяет параметры текущего компьютера и сравнивает с теми данными, которые соответствуют разрешенным рабочим местам. Если они совпадают, разрешается доступ к токену со стороны внешнего ПО — то есть, собственно, со стороны СКЗИ (СКЗИ — это внешнее по отношению к «Идеальному токену» ПО), иначе в доступе отказывается.

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

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

Использование «Идеального токена» возможно только после успешного завершения взаимной аутентификации токена и компьютера, к которому его подключили, а затем — успешной аутентификации пользователя в токене и СКЗИ.

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

В то же время «Идеальный токен» лишен каких бы то ни было избыточных функций, негативно влияющих на цену изделия.

Технология «Идеального токена» запатентована.

Обзор ключевых хранилищ

Смарт-карты

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

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

Разумеется, хранение ключей — это не единственная функция смарт-карты, но одна из основных.

Токены

Токены могут иметь более широкие возможности по сравнению со смарт-картами. Например, устройство может содержать свою собственную клавиатуру для ввода PIN-кода, что значительно усложняет перехват. Обычно для работы с токеном необходима установка драйверов.

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

Хранение ключей — это не единственная и не основная функция токенов, их основное назначение — двухфакторная аутентификация.

Флеш-накопители

Обычные флеш-накопители не обладают никакой защитой. Могут быть украдены или утеряны, в этом случае любой человек сможет получить доступ к данным. Зато флеш-накопители обладают значительным объемом памяти, совместимы практически со всеми устройствами, имеющими USB-порты. Флеш-накопитель может быть использован на любом АРМ в любых условиях.

Было бы нелепо даже рассматривать вопрос о том, является ли хранение ключей сколь-нибудь специальной функцией флеш-накопителей.

ТМ-идентификаторы

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

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

Основное предназначение ТМ-идентификаторов, как и токенов, — двухфакторная аутентификация. Если аутентифицирующей информацией являются не непосредственно хранящиеся в ТМ-идентификаторе данные, а результат преобразования, которое производится резидентным компонентом безопасности с данными, полученными по разным каналам, то копируемость памяти ТМ-идентификатора не является критичным фактором. В отличие от считывания хранящихся в «таблетке» в открытом виде ключей.