Конявская Текхнология доверенного сеанса связи ДСС и средство 2015
.pdf1.3. Технология ДСС на базе СОДС «МАРШ!»
При начале доверенного сеанса связи пользователь загружается с «МАРШ!» (из защищенного от записи раздела памяти), обеспечивая тем самым доверенную среду, жесткий диск компьютера не используется. Далее стартует браузер и все сопутствующее программное обеспечение, необходимое для работы. В браузере во время доверенного сеанса обеспечивается защищенный обмен информацией с соблюдением всех требований Федерального закона «Об электронной подписи» 63-ФЗ.
После загрузки ОС на компьютер клиента и старта браузера устанавливается доверенный сеанс связи с сервером (VPNшлюзом) центральной ИС (например, в случае с ДБО – сервером банка). Сервер ИС выполняет авторизацию пользователя на доступ к сервисам ИС и соединение с требуемым сервисом ИС.
Суть концепции доверенного сеанса связи с точки зрения безопасности заключается в следующем: раз компьютер практически всегда используется в незащищенных сетях и только иногда – в защищенных, значит, нужно добиваться не «тотальной» защиты,
что дорого и неудобно, а защиты, при которой защищенные и
«опасные» ресурсы разделяются и не могут использоваться совместно.
При этом очевидно, что целесообразность применения «постоянной» защиты или средства обеспечения доверенного сеанса связи прямо пропорциональна тому, сколько данный конкретный компьютер должен использоваться в режиме доверенной среды. Если постоянно или большую часть времени – то его необходимо полноценно, хоть и дорого, защищать, создавая ИПС, защищая каналы связи и т. д., и т. п. Если же это короткие сеансы в течение дня – то логично использование СОДС.
Успешность атаки определяется, в числе прочих факторов, временем, в течение которого злоумышленник имеет возможность ее осуществлять.
Это математически доказуемое и доказанное положение давно стало общим местом, в результате чего, к сожалению, дало почву для злоупотреблений, когда несанкционированное использование злоумышленниками ключей, хранящихся в токенах, объяснялось в дальнейшем тем, что пользователи слишком надолго оставляли токены подключенными.
31
Ошибочность этого объяснения настолько очевидна, что его сложно считать именно ошибочным. Однако предпосылки понятны
–любая атака требует подготовки, создания условий для ее успешного проведения.
Подготовить условия для проведения атаки в постоянной среде
–удобнее, чем в среде, создающейся на ограниченное время. Поэтому постоянная вычислительная среда должна быть более устойчивой к воздействиям на нее.
Альтернатива повышению устойчивости среды к воздействию – уменьшение периодов времени ее существования. Вспомним распространенный мотив из детективов и боевиков: для того чтобы «засечь» место, из которого производится телефонный звонок, специалистам необходимо 40 секунд. Поэтому тот, кому звонят, старается продержать абонента на трубке нужное время, а звонящий – прервать сеанс на 38-й секунде. После этого можно перезванивать снова – специалистам опять понадобится 40 секунд.
Примерна такова и логика ДСС.
Рис. 2. Доверенная среда (t – время, t0 - время, в течение которого защитные механизмы работают корректно, Т – время непрерывной работы компьютера в защищенном режиме)
Доверенная вычислительная среда создается комплексом средств единожды и на постоянное время и стоит дорого. Доверенный сеанс связи создается многократно по мере необходимости в нем, на непродолжительный промежуток времени (сеанс), и стоят средства его обеспечения ощутимо меньше.
Почему же тогда неверна логика кратковременности подключения токенов? Почему ключи успевают попасть в руки злоумыш-
32
ленников даже в тех случаях, когда токены подключаются только для подписания платежки, и даже в тех случаях, если ключи в них – неизвлекаемые?
ВНИМАНИЕ:
Необходимо дать возможность ответить слушателям.
Принципиальное требование безопасности к сеансу, детерминирующее безопасность применения этой технологии, – это «обнуление» среды при разрыве сеанса, возвращение ее в исходное состояние. Именно это не дает возможности злоумышленнику накопить результаты воздействий на среду, подготовить условия для проведения атаки. В случае с СОДС это обеспечивается тем, что доверенная среда взаимодействия загружается из раздела памяти ReadOnly и модифицировать ее можно только во время сеанса связи. В случае же с токенами среда компьютера постоянна, все необходимые манипуляции с ней злоумышленник может произвести в любое удобное время, вне зависимости от того, подключен ли токен. И потом даже предельно кратковременного подключения будет достаточно для того, чтобы доступ к ключам был получен.
Атаки, безусловно, возможны, и на «МАРШ!» (например, атакой через сеть, так как остальные ресурсы компьютера средой, загружаемой с «МАРШ!», не поддерживаются). Даже если такая атака состоялась, например, в доверенную среду попал вирус или была осуществлена попытка «инъекции кода», то после отключения «МАРШ!» от компьютера среда вернется в исходное состояние, так как вирус не сможет записаться в память RO.
Однако фиксированность среды – это еще не все. После того как мы обнародовали концепцию доверенного сеанса, стали популярны предложения решений, в которых фиксация среды обеспечивается загрузкой ОС и исполняемой задачи с носителя, на котором неизменность записанных программ обеспечивается технологически (CD-диски, специальные загрузочные флешки, работающие в режиме ReadOnly). Это отчасти надежные и дешевые решения, но совершенно неудобные и некомплексные. Для каждого компьютера такой носитель нужно изготавливать отдельно, ведь его невозможно настроить, во всяком случае, невозможно сохранить настройки. Отдельно нужно хранить ключи подписи и другую важную информацию.
Далее рассмотрим, почему этих недостатков лишен «МАРШ!».
33
1.4. «МАРШ!» как устройство
Итак, «МАРШ!» – это персональное устройство, являющееся носителем персональной доверенной среды для работы с доверенной информационной системой.
Как устройство «МАРШ!» может быть охарактеризован с точки зрения его архитектуры, возможностей, обеспечиваемых этой архитектурой, набора функций, реализуемых устройством.
1.4.1.Архитектура («МАРШ!» как память с управляемым доступом)
Сточки зрения аппаратных ресурсов «МАРШ!» выглядит так:
Рис. 3. Аппаратные ресурсы «МАРШ!»
СОДС «МАРШ!» с точки зрения аппаратных ресурсов представляет собой управляющий микроконтроллер, память загрузки ПО микроконтроллера, двухплечевой датчик случайных чисел с физическими источниками шума и память с управляемым доступом (это абсолютно принципиальное отличие от токенов, совмещенных с флешками, и ниже будет показано почему). За счет этого в «МАРШ!» аппаратно реализованы управление памятью, генерация и контроль случайных последовательностей, резидентная
34
криптография, которая используется для критичных вычислений (например, для управления обновлениями ПО). Резидентное СКЗИ «МАРШ!» не используется для потоковой криптографии, для этого используется встроенный в ОС «МАРШ!» VPN-клиент, ключи которого хранятся в выделенном разделе памяти Hidden. Такая логика позволяет интегрировать в «МАРШ!» любые сертифицированные СКЗИ, без изменения систем ключевого менеджмента, что очень важно, так как весьма существенно снижает опасность негативного влияния интеграции на стабильность работы СКЗИ, не требует изменения в функциональной части информационной системы, спроектированной для работы с тем или иным СКЗИ, а также снижает нагрузку, связанную с переучиванием управляющего персонала.
Сама флешка – память «МАРШ!» разбита на блоки с разными атрибутами доступа. Разбивается она на стадии производства, пользователь (или злоумышленник) повлиять на это не может.
Рис. 4. «МАРШ!» как память, разбитая на разделы
Как правило, это не менее одного раздела ReadOnly (RO), не менее одного раздела ReadWriteHidden (RWH), используются также разделы AddOnly (AO) и разделы с общим доступом RW.
Обычно в RO-разделе размещается операционная система и другое ПО, которое является неизменяемым достаточно длительное время, обновления и дополнения функционального программного обеспечения (ФПО) размещаются в одном из разделов RWH, в другом размещается ключевая информация VPN, а раздел AO используется для ведения аппаратных журналов событий безопасности.
35
1.4.2. Возможности («МАРШ!» как РКБ)
Итак, аппаратная архитектура «МАРШ!» позволяет создавать на стадии производства необходимое для каждой конкретной системы количество разделов памяти с теми атрибутами доступа, которые нужны именно в ней.
За счет наличия разделов с разными атрибутами доступа достигается возможность выпуска серии унифицированных устройств, настраиваемых и, что важно, перенастраиваемых в дальнейшем. Настраиваемость достигается путем разделения ресурсов на те, что должны оставаться неизменяемыми и обновляться только в специальном защищенном или технологическом (в зависимости от опций) режиме, и те, что должны адаптироваться к условиям применения. Первые хранятся в разделе RO, вторые – в RWH. Нет необходимости заводить дополнительные носители ключей VPN – они хранятся в специальном разделе этого же устройства, на этом же устройстве хранятся неудаляемые журналы, есть раздел для обновляемого ПО и резидентное СКЗИ для обеспечения режима защищенного обновления.
Важно понимать, что в «МАРШ!» реализуются два разных контура криптографии: резидентная криптография, предназначенная для критичных вычислений, например, при обеспечении защищенных удаленных обновлений ОС, для выработки ЭП – это то, что выполняется строго аппаратно, ключи не покидают устройства и не попадают в ОС, и потоковая криптография – VPN-клиент, который исполняется программно в ОС, загруженной с «МАРШ!», и ключи для которого хранятся в Hidden-разделе.
Способ управления памятью является совершенно принципиальным с точки зрения ключевых (во всех смыслах) возможностей устройства. На перемещении акцента с этого важнейшего аспекта построены попытки использования вместо СОДС так называемых «аналогов», представляющих собой «токен с памятью». Идея совмещения флешки и токена, исключающая, казалось бы, самое главное ограничение фиксации среды – невозможность корректной работы с ключами, стала естественным продолжением идеи «удешевления» СОДС путем использования CD-дисков или загрузочных RO-флешек.
Рассмотрим «МАРШ!» в сравнении с получившими сегодня некоторое распространение устройствами, совмещающими в едином конструктиве токен и флешку.
36
Рис. 5. СОДС (слева) и «токен с памятью» (справа). Архитектура аппаратных средств (Д – датчик случайных чисел, m – память кода, М – универсальный микроконтроллер, м – память; HUB – USBхаб, М – специализированный микроконтроллер, м – память, Т – токен)
На рис. 5 затенена зона компьютера, а красной линией показано движение критичных для безопасности данных. Видно, что во втором случае критичные данные проходят через память компьютера. Это не опасно, если среда доверенная, но доверенной ее можно считать в том случае, если контрольные процедуры выполнены ДО ЗАГРУЗКИ, и это возможно для архитектуры, показанной в левой части рисунка, и невозможно для альтернативной архитектуры.
«Токен с флешкой» – это два разных устройства, объединенных hub’ом в единый конструктив. В этом, казалось бы, нет ничего плохого, потому что с флешки, входящей в состав устройства, загружается фиксированная среда, которую признаем доверенной, стало быть, совершенно допустимо и нормально получить ключи из токена через посредство этой самой доверенной среды.
Это не совсем так. Принципиальная ущербность описанной архитектуры в том, что для передачи данных между двумя совмещенными устройствами (токеном и памятью) необходима их передача наружу, во внешнюю среду. Это означает, что контрольные процедуры не могут быть выполнены независимо от внешней недоверенной среды. Как бы ни была логически построена процедура
37
доступа, физически устройство построено так, что взаимодействие между его компонентами требует «участия» в этом процессе внешней ОС. Данные для управления доступом к каждому «защищенному» хранилищу поступают снаружи, значит, не могут считаться доверенными.
Именно эта особенность привела к необходимости использовать универсальный микроконтроллер, а не смарт-карточный кристалл, как в токене. Все взаимодействие между компонентами «МАРШ!» осуществляется внутренними ресурсами микроконтроллера, что дает возможность на стадии контрольных процедур быть полностью независимым от внешней среды и загружать гарантированно доверенную среду.
Если подключить «МАРШ!» к ПК с уже загруженной ОС, он будет виден как диск. В зависимости от наличия/отсутствия драйверов, видимые (!) разделы диска можно/нельзя открыть. Запустить ОС на исполнение, конечно, нельзя, и обратиться к скрытым разделам – допустим, что злоумышленнику о них точно известно (просто увидеть их нельзя – они скрытые), – нельзя, доступом к своей памяти управляют аппаратные ресурсы «МАРШ!», именно поэтому «МАРШ!» – это память с управляемым доступом.
Поскольку «МАРШ!» – это инструмент создания сеанса, а не хранилище пользовательских данных, то доступность диска из системы не делает возможными какие-либо осмысленные атаки.
Действительно, на «МАРШ!», по настоянию отдельных заказчиков, может быть выделен раздел памяти RW для хранения пользователем (именно человеком) своих личных данных.
Доступ к нему будет возможен из любой ОС, поддерживающей его файловую систему (она может быть разной – если FAT, то будет доступ, в том числе и из Windows, либо же только из различных Linux и из ОС самого «МАРШ!»).
Других защитных механизмов ограничения доступа к этому разделу, кроме чисто архитектурных (файловая система того или иного типа), при этом не предусмотрено, и мы не рекомендуем без явной необходимости прибегать к этой возможности.
Однако для решения задачи хранения пользовательских данных при использовании «МАРШ!» действительно ЗАЩИЩЕННО мы можем предложить интеграцию «МАРШ!» и «Секрета» (защи-
38
щенной флешки, также разработки и производства ОКБ САПР, которая монтируется только на тех компьютерах, что заранее в ней зарегистрированы, а на остальных не определяется как устройство типа mass-storage). Интеграция подразумевает в данном случае не объединение двух устройств в одно, а поддержку «МАРШ!» «Секрета» как одного из внешних (подключаемых) устройств (наряду, например, с принтером).
В этом случае «Секрет» будет монтироваться в ОС «МАРШ!» как на одном из разрешенных компьютеров, и пользователь сможет обращаться к данным, записанным в его памяти, или, наоборот, писать в нее что-либо.
Именно «МАРШ!» – это «серебряная пуля» для хакера по следующим причинам:
1.Состояние критичных компонентов зафиксировано;
2.Вирусы блокированы;
3.Ключи неизвлекаемы;
4.Перехват управления невозможен;
5.Управление отчуждено от клиента.
1.4.3. Обязательный и опциональный функционал («МАРШ!» как конструктор)
Уже не один раз прозвучало, что СОДС «МАРШ!» изготавливается для конкретных систем, в общем случае нельзя (возможно, в дальнейшем такие проекты появятся) купить в ОКБ САПР один «МАРШ!», прийти в какую-то организацию, применяющую «МАРШ!», и сказать: «Зарегистрируйте мой “МАРШ!” в вашей системе». Нет, «МАРШ!» выпускается по требованиям конкретного заказчика – под него формируются разделы памяти, для него формируется ОС, соответствующая именно его потребностям, включающая те компоненты, которые нужны именно ему.
Это позволяет добиться того, что при ограниченном объеме ресурсов устройство все же содержит минимально необходимые компоненты для работы клиентского рабочего места.
39
Следует различать обязательную и опциональную функциональность СОДС «МАРШ!». Так, память «МАРШ!» обязательно будет разбита на разделы, один из которых обязательно будет RO. В этот раздел RO обязательно будет записана ОС Linux (возможно формирование устройств с другими ОС, но в рамках отдельных проектов), поддерживающая какой-то из видов сетевого соединения (например, 3G-модем или Wi-Fi), содержащая браузер FireFox.
По сути дела, это все, что будет в «МАРШ!» в любом случае. Но и тут нужно хорошо понимать, что определить, какие понадобятся разделы памяти, какой вид сетевого соединения нужен обязательно, а какой, напротив, нужно запретить, необходимо заказчику или интегратору (разумеется, при участии разработчиков – ОКБ САПР и КБПМ (соразработчики решения) обязательно проводят подробные консультации при оформлении заказов на состав
«МАРШ!»).
Все остальные возможности СОДС «МАРШ!» – наличие резидентного СКЗИ, наличие VPN-клиента (и какой именно VPNклиент), межсетевой экран, поддержка подключаемых устройств и каких именно (принтер, сканер, сканер штрих-кода, рентгеновский аппарат), Библиотека ЭП (ПО, позволяющее с использованием резидентного СКЗИ подписывать электронной подписью данные в xml-формате), возможность защищенного удаленного обновления – все это выбирается или не выбирается на усмотрение заказчика (с учетом консультаций с ОКБ САПР или КБПМ).
Для этого необходимо заполнить анкету в разделе «Заказать» на сайте www.sodsmarsh.ru. Эта анкета учитывает зависимости, так что не может получиться, что заказчик попытается заказать, например, Библиотеку ЭП, не отметив резидентное СКЗИ.
Необходимо только иметь в виду, что от выбранных опций зависит цена изделия.
ВНИМАНИЕ: По возможности нужно продемонстрировать анкету на www.sodsmarsh.ru и прокомментировать каждый пункт. Если возможности выхода в Интернет нет, желательно иметь слайд или распечатку.
40