поиск по сайту
Электронная подпись при работе в режиме терминального доступа

Электронная подпись при работе в режиме терминального доступа

 Иванов А. В.

Московский физико-технический институт (ГУ), Москва, Россия.

 

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

Ключевые слова: электронная подпись, электронный документооборот, ДБО, облачная инфраструктура, удалённая инфраструктура, микрокомпьютер, доверенная среда, доверенная загрузка, МКTrusT.

Digital signature during the work in the terminal access mode

  1. V. Ivanov

Moscow Institute of Physics and Technology (SU), Moscow, Russia

This article provides the features of safe work in the mode of terminal access, the requirement (including legislations) shown to the digital signature (DS) are considered the DS model and its practical realization is offered.

Keywords: digital signature, electronic document management, remote bank service, RBS, cloudy infrastructure, remote infrastructure, microcomputer, the entrusted environment, the entrusted loading, MKTrusT.

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

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

Требования

Работа с удаленным ресурсом можно выделить четыре составляющие: терминальный сервер (ТС), терминальный клиент (ТК), канал связи и пользователь. Принципиально важно не отождествлять терминального клиента и пользователя [1]. К примеру, ключи, хранящиеся на ТК, строго говоря, не хранятся у пользователя и не являются ключами пользователя. Для легитимного хранения ключей на ТК последний должен обладать всеми признаками отчуждаемого носителя.

 

Рисунок 1. Составляющие терминального взаимодействия

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

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

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

  • Ключ ЭП должен располагаться на ТК;
  • Информационные наборы данных должны создаваться на ТК;
  • Выработка подписи и шифрование данных должны производиться на ТК;
  • Должно быть исключено несанкционированное использование ключа ЭП в период его применения или хранения на ТК;
  • При любом завершении работы СЭП или выключения ТК ключ ЭП не должен оставаться в оперативной памяти [2].

Требования законодательства

Существует два нормативных документа, непосредственно относящиеся к электронной подписи: Федеральный Закон № 63 «Об электронной подписи» и Приказ ФСБ № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра».

Согласно им, средства ЭП должны:

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

При проверке ЭП средства ЭП должны:

  • показывать содержание электронного документа, подписанного ЭП;
  • показывать информацию о внесении изменений в подписанный ЭП электронный документ;
  • указывать на лицо, с использованием ключа ЭП которого подписаны электронные документы [3].

Принципиально важные из требований, содержащихся в приказе ФСБ:

  • использовать криптографические алгоритмы, утверждённые в качестве ГОСТа или имеющее положительное заключение ФСБ по результатам криптографических исследований [4];
  • не иметь возможности, позволяющие модифицировать или искажать алгоритм работы средства ЭП в процессе его использования;
  • проводить аутентификацию субъектов доступа (лиц, процессов) к этому средству, причём до начала выполнения ЭП;
  • проводить аутентификацию лиц, осуществляющих локальный доступ к средству ЭП;
  • реализовать механизм контроля целостности средства ЭП и среды функционирования средств ЭП;

Общие требования к при работе в терминальных системах

Для того чтобы обеспечить защиту клиента и канала необходимо обеспечить доверенную среду[1].

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

Доверенная загрузка рабочих станций и серверов является обязательным условием построения защищенных систем обработки информации. Только при условии правильного защищенного старта операционной системы  можно говорить о надежной системе защиты в целом. Для реализации доверенной загрузки применяется комплекс организационно-технических мер, который в совокупности и обеспечивает старт нужного набора программного обеспечения в нужной конфигурации. Важно отметить, что это именно комплекс организационно-технических мер. И средства доверенной загрузки являются обязательным элементом этих мер как техническая составляющая [6].

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

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

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

Такой подход тоже не лишён недостатков. Хотя бы потому, что это внесение целого ряда новых элементов в уже устоявшуюся систему, введение ряда организационно-технических мер.

Есть и третий подход: использование специализированного устройства — защищённого терминала. Речь идёт об отечественных микрокомпьютерах MKT-card long [7-13]. Данный форм-фактор (док-станция и присоединяемый микрокомпьютер (МК)) видится наиболее удобным для стационарно расположенных рабочих мест: к док-станции присоединяется вся необходимая периферия, пользователь же подключает микрокомпьютер на время работы. В случае МК для обеспечения доверенной загрузки микросхема банка памяти, в которой размещается ОС, переводится в режим «только чтение» (RO). Этот режим обеспечит неизменность ОС. Если неизменность ОС обеспечивается аппаратным, физическим способом, то никакие программные действия злоумышленников не смогут изменить целостность, а, следовательно, доверенность программной среды.

При первоначальной подготовке такого компьютера к работе, операционная система записывается в банк памяти, то есть в этот момент память доступна не только не чтение, но и на запись (Read Write — RW). По требованиям безопасности перевод из режима RO в режим RW должен осуществляться физическими, а не программными методами. Так и происходит — используется физический переключатель внутри корпуса микрокомпьютера, доступа к которому у пользователя нет.

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

Наилучшее разрешение этого противоречия — наличие еще одной ОС, незащищенной, без ограничений по доступу. Носителем этой ОС является еще один банк памяти с полным доступом, физически изолированным от другого банка. Это модификация TrusT (MKTrusT-card long), в которой введён дополнительный физический переключатель для выбора ОС пользователем, в одном положении которого запускается защищённая ОС, а в другом — незащищённая. В общем случае MKTrusT имеет две ОС, ориентированные на работу в разных  контурах защищённости.

Модель электронной подписи

В случае использования MKT-card long, опираясь на требования, озвученные выше, процедура электронной подписи может выглядеть следующим образом:

  1. Документ хранится на терминальном сервере.
  2. Пользователь подключается к ТС, выбирает документ на подпись, и тот передаётся на терминальный клиент.
  3. При передаче по каналу перед отправкой документ подписывается СКЗИ на ключе сервера в автоматическом режиме.
  4. На терминале подпись проверяется резидентным СКЗИ терминала.
  5. В случае подтверждения целостности, документ визуализируется.
  6. Пользователь изучает документ и в случае корректности подтверждает продолжение процедуры подписи.
  7. Вычисляется хеш-функция от документа резидентным СКЗИ МК, далее тем же СКЗИ  или отчуждаемым персональным СКЗИ вычисляется ЭП.
  8. После подписания документ вновь визуализируется на ТК.

Далее подписанный документ отправляется на сервер.

В качестве идентификатора и защищённого ключевого носителя могут выступать как сам микрокомпьютер, обладающий всеми признаками персонального аппаратного идентификатора, так и внешний токен (например «Идеальный токен»). В MKT-card long реализована поддержка наиболее распространенных типов идентификаторов, к тому же, в силу формирования образа ОС для каждой конкретной задачи отдельно, список расширяемый.

Выбор СКЗИ основывается на предпочтениях, сложившихся в системе, куда встраивается С. П. Имеется положительный опыт встраивания наиболее распространённых отечественных СКЗИ. 

Кроме того, MKT-card long поддерживает систему защищённой сетевой загрузки ПО терминальных станций  «Центр-Т.

Итоги

Были рассмотрены особенности  работы в терминальных системах и требования  к электронной подписи, на основе которых выработана модель процедуры ЭП.

Защищённый микрокомпьютер MKT-card long является именно тем решением, которое позволяет привносить электронную подпись в уже существующую инфраструктуру без внесения в неё серьёзных изменений. Область применения защищённых микрокомпьютеров крайне обширна, и они могут быть тем ядром, вокруг которого будут создаваться новые системы.

Список литературы:

  1. Каннер (Борисова) Т. М., Романенко Н. В.Аккорд-АМДЗ: Next Generation. // Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15–18 мая 2012 года, Суздаль (Россия). 2012. С. 57-58.
  2. Конявская С. В., Счастный Д. Ю., Каннер (Борисова) Т. М. Аппаратная криптография. Особенности «тонкой» настройки. // Защита информации. INSIDE. 2010. N 5. С. 40-44.
  3. Приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении требований к средствам электронной подписи и требований к средствам удостоверяющего центра».
  4. ITU-T Recommendation Х.509. Information technology — Open systems interconnection — The Directory: Public-key and attribute certificate frameworks.
  5. Конявский В. А., Гадасин В. А. Основы понимания феномена электронного обмена информацией. Серия «Библиотека журнала «УЗИ». Минск. 2004. — С. 247-254.
  6. Счастный Д. Ю., Конявская С. В. Облако ЦОДов, или Сон разума: о том, почему необходимо мыть руки перед едой, даже если они «чистые». // Защита информации, Inside. 2014. № 5. С. 57–61.
  7. Конявский В.А., Степанов В. Б. Компьютер типа «тонкий клиент» с аппаратной защитой данных: Патент на полезную модель № 118773. 27.07.12. Бюл. № 21.
  8. Конявский В. А. Компьютер с аппаратной защитой данных от несанкционированного изменения: Патент на полезную модель № 137626. 20.02.2014. Бюл. № 5.
  9. Конявский В. А. Мобильный компьютер с аппаратной защитой доверенной операционной системы: Патент на полезную модель № 138562. 20.03.2014. Бюл. № 8.
  10. Конявский В. А. Мобильный компьютер с аппаратной защитой доверенной операционной системы от несанкционированных изменений: Патент на полезную модель № 139532. 20.04.2014. Бюл. № 11.
  11. Конявский В. А. Мобильный компьютер с аппаратной защитой доверенной операционной системы: Патент на полезную модель № 147527. 10.11.2014. Бюл. № 31.
  12. Конявский В.А., Акаткин Ю. М. Мобильный компьютер с аппаратной защитой доверенной операционной системы от несанкционированных изменений: Патент на полезную модель № 151264. 27.03.2015. Бюл. № 9.
  13. Конявский В. А. Рабочая станция с аппаратной защитой данных для компьютерных сетей с клиент-серверной или терминальной архитектурой: Патент на полезную модель № 153044. 27.06.2015. Бюл. № 18.

References:

  1. Kanner (Borisov) T.M., Romanenko N.V., Accord TSHM: Next Generation. // Complete protection information. Safety of Information Technology. Proceedings of the XVII International conference on May 15-18, 2012, Suzdal (Russia). 2012. pp 57-58.
  2. Konyavska S.V., Schastny D.Y., Kanner (Borisov) TM hardware cryptography. Features of the «fine» setting. // Data protection. INSIDE. 2010. N 5. C. 40-44.
  3. Order of the RF Federal Security Service of December 27, 2011 № 796 «On Approval of the requirements to the means of electronic signature and to the means of the requirements of the certification center.»
  4. ITU-T Recommendation X.509. Information technology — Open systems interconnection — The Directory: Public-key and attribute certificate frameworks. 2008.
  5. Konyavska V.A., Gadasin V.A., Basic understanding of the phenomenon of electronic information exchange. »» US Library Journal «series. Minsk. 2004. — S.247-254.
  6. Schastny D.Y., Konyavska S.V., Cloud data center, or sleep of reason: that is why it is necessary to wash hands before eating, even if they are «clean». // Data Protection, Inside. 2014. № 5. C. 57-61.
  7. Konyavska V.A., Stepanov V.B., Computer type «thin client» with hardware data protection: The patent for utility model № 118773. 27.07.12. Bull. Number 21.
  8. Konyavska V.A., Computer hardware data protection from unauthorized changes: The patent for utility model № 137626. 20.02.2014. Bull. Number 5.
  9. Konyavska V.A., Mobile Computer with hardware protection of trusted operating system: The patent for utility model № 138562. 20.03.2014. Bull. Number 8.
  10. Konyavska V.A., Mobile Computer with hardware protection of trusted operating system from unauthorized changes: The patent for utility model № 139532. 20.04.2014. Bull. Number 11.
  11. Konyavska V.A., Mobile Computer with hardware protection of trusted operating system: The patent for utility model № 147527. 10.11.2014. Bull. Number 31.
  12. Konyavska V.A., Akatkin Y.M., Mobile computer with hardware protection of trusted operating system from unauthorized changes: The patent for utility model № 151264. 27.03.2015. Bull. Number 9.
  13. Konyavska V.A., Цorkstation with hardware data protection for computer networks with client-server architecture or terminal: The patent for utility model № 153044. 27.06.2015. Bull. Number 18.

[1] Фрагмент среды электронного взаимодействия, для которого установлена и поддерживается в течение заданного интервала времени целостность объектов и целостность взаимосвязей между ними, называется доверенной вычислительной средой (ДВС) [5];