Доклады, выступления, видео и электронные публикации

Смысл и безопасность

Яркой приметой времени являются дискуссии по мобильным решениям. Рассмотрим одно типичное выступление, представленное журналом «Информационная безопасность банков» в разделе «Энциклопедия безопасности». Возможно, эта «энциклопедическая» статья основана на неумелой стенограмме выступления. Устная речь отличается от литературной, это понятно, но нельзя же публиковать под рубрикой «Энциклопедия» совершенно сырой непричесанный материал! Это дело журнала, конечно, но впечатление от сумбурного выступления остается очень тяжелое, портящее мнение и о выступающем, и о журнале, позволяющем себе такие публикации.

Но оставим форму, обратимся к содержанию. Попытаемся найти смысл.

Бессмысленность в безопасности

Статья (? Доклад? стенограмма?) В. Иванова «Электронная подпись на мобильных устройствах и облачные решения: секреты должны оставаться секретами», о новом решении компании «Актив» для электронной и облачной подписи.

В чем актуальность научного поиска? В. Иванов постулирует[1]: «сейчас стоит задача отделить ключи подписи от устройства, но при этом не прибегать к контактным интерфейсам, сделать это по разумной цене и при этом с хорошей криптографией. И решением является их новое устройство – дуальная смарт-карта Рутокен ЭЦП 3.0 с интерфейсом NFC».

«Отделить ключи подписи от устройства» – зачем? От какого устройства? От любого? А как их потом использовать? И как вообще они туда попали? Может, чтобы не отделять – не стоило туда их помещать?

«Не прибегать к контактным интерфейсам» – почему? Чем они провинились? Тем, что не используют уязвимые радиоканалы?

«Сделать это с хорошей криптографией» –- что сделать? «Отделить ключи подписи от устройства»? И что означает «хорошая криптография»? Вспоминается М. А. Булгаков с отрицанием осетрины второй свежести.

Ну что же, задачи поставлены, хотя и невнятно.

Но, может быть, они уже решены с использованием других средств? Нет, утверждает автор, у других решений много недостатков. Автор отмечает, что мобильное приложение, мобильное устройство, токены и SIM-карты в качестве носителей имеют слишком много недостатков, и, следовательно, подразумевается, что новое решение таких недостатков лишено. Напомним, что в качестве такового предлагается рассмотреть смарт-карту «Рутокен ЭЦП 3.0» с интерфейсом NFC.

О каких же недостатках идет речь? Автор рассматривает несколько вариантов – СКЗИ как приложение, СКЗИ на базе SIM-карты, токены и облачная подпись. Автор критикует эти подходы (мы с ним в его пафосе солидарны, но критика должна быть объективной и предметной, в профессиональном дискурсе). Вслед за автором рассмотрим и мы.

«Мобильная подпись непосредственно в мобильном приложении»

СКЗИ в целом, и подпись в частности, реализованные в виде приложения  – это программное СКЗИ. Значит, оно должно использоваться в доверенной среде функционирования криптографии – то есть как минимум на доверенном устройстве. Использовать недоверенное устройство нельзя – и вопрос тут не в мобильности терминала или мобильности подписи (кстати – что это?), а в отсутствии возможности поддержки доверенной среды функционирования криптографии (СФК). Если мысль в журнальном изложении нам удалось уловить правильно – то нельзя не согласиться с автором.  Только повторим еще раз – дело тут не в мобильности, а в незащищенности среды, в невозможности обеспечить нужные условия. Приложение в незащищенной среде не может быть приемлемым решением для СКЗИ. Этот факт общеизвестен и понятен всем, и вряд ли требуется это пояснять. Классификация внутренних нарушителей начинается с Н2, и поэтому рассматривать класс защищенности КС1 для защиты от внутренних нарушителей – по меньшей мере непрофессионально. Автор прав.

Но чем мотивирует автор?

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

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

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

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

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

«Мобильные устройства не поддерживают по умолчанию российскую криптографию» – вот эта мысль мне не понятна. А стационарные устройства поддерживают? А как это – «по умолчанию»? Не любую программу могут выполнить смартфоны? А думалось, что они вполне соответствуют модели Тьюринга и тезису Черча-Тьюринга о том, что машина Тьюринга способна выполнить любой вычислимый алгоритм.

Итак – использовать приложение в качестве СКЗИ – плохая идея.

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

SIM-карты

Недостатки, которые В. Иванов нашел у sim-карт, сводятся к следующему:

  • нужно производить специальные SIM-карты, а это стоит денег
  • возникает проблема с идентификацией пользователей – мобильный оператор не является УЦ
  • доступ к sim-карте возможен только из sim-приложения
  • и вообще, sim-карты – это уже прошлое.

Рассмотрим первые два пункта – этого достаточно. Доступ программируется, а sim-карты есть. Переход на виртуальные  sim -карты  давно обещан, но пока не реализован. А сразу после реализации виртуальные sim-карты будут наверняка атакованы хакерами, и, видимо, это даст новый виток противостояния, который завершится внесением изменений в аппаратную структуру смартфона.

Таким образом, именно это и есть смысл рассматривать – иначе изменения аппаратуры могут оказаться бесполезными с точки зрения технической защиты информации. А использовать такой шанс очень заманчиво.

Специальные sim-карты стоят денег. Справедливо. Но означает ли указание на этот недостаток то, что предлагаемые автором решения не стоят денег? Интересненько. Раньше мне казалось, что в аппаратном смысле смарт-карты и сим-карты не сильно отличаются. Почему же решение «Актива» ничего не стоит? Странный способ маркетинга.

Идентификация и УЦ. Это серьезная проблема, и ее стоит обсудить. Причем с самого начала – от ФЗ 1 до нынешних времен. Дело в том, что в общественном сознании укрепился миф (фейк? заблуждение? – как минимум, заблуждение), что УЦ призван изготавливать ключ подписи. Но это не так. Это лишь одна из услуг, которую УЦ может (может!) оказать, но окажет только в том случае, если гражданин внезапно проникнется огромным и ничем необъяснимым доверием к УЦ и его персоналу.

А главная, основная функция УЦ – изготовление сертификата ключа проверки подписи. Вот и все. И ничего другого.

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

  1. Пользователь устанавливает СКЗИ, в состав функций которого обязательно входят функции генерации ключевой пары.
  2. С использованием СКЗИ генерируется ключ подписи и вычисляется ключ проверки подписи.
  3. Ключ подписи записывается на выбранные пользователем носители, один или несколько – здесь пользователь ничем не ограничен, кроме собственных представлений о безопасности.
  4. Ключ проверки подписи также записывается на носитель, но уже другой. Этот носитель понадобиться для визита в УЦ.
  5. Пользователь обращается в УЦ за услугой изготовления сертификата ключа подписи, передавая в УЦ в качестве исходных данных ключ проверки подписи – этого для УЦ вполне достаточно (кроме, естественно, обычных документов).
  6. УЦ изготавливает сертификат ключа подписи и записывает его на носитель, который удобен для пользователя.

Как мы видим, этот процесс никак не связан с тем, является ли оператор связи заодно и удостоверяющим центром. Оператор связи продает оборудование, а УЦ изготавливает СКП. И совершенно необязательно объединять эти две разные услуги. А функцию записи ключа на носитель должен реализовать вендор СКЗИ. Очевидно, что УЦ излишне настойчиво предлагают пользователю услугу, которая заключается в полном цикле – от генерации ключа подписи до изготовления СКП. Наверное, можно и так – хотя в результате безопасность информационного взаимодействия выглядит сомнительно. Такой подход аналогичен тому, что при визите в паспортный стол мы просили бы паспортистку не зафиксировать нашу подпись, а придумать ее и самостоятельно внести в паспорт и учетную карточку. Согласитесь – похоже на бред. И почему же мы не видим аналогии в просьбе к УЦ изготовить ключ подписи за нас?

Проблема очевидна. Разрешается она, с одной стороны, созданием правильных СКЗИ, позволяющих пользователю реализовать описанную выше процедуру, и повышением грамотности пользователей, которые сейчас бредут по извилистой тропинке, навязываемой УЦ. И уж совсем ни при чем тут мнимые недостатки sim-карты.

Токены

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

Но почему нужно делать токен, который снабжен всеми типами разъемов – Иванов нам не сообщает. Давайте делать токены с разными типами разъемов – что этому мешает? Только не говорите, что ключ подписи обязательно неразрывно связан со своим носителем – это техническая бессмыслица. Нужно аккуратно решать несложную инженерную задачу, и все будет хорошо.

Ну и о ненадежности Bluetooth – я бы не стал так огульно оценивать один из весьма удачных протоколов. Если есть уязвимости, существенные с точки зрения безопасности – то они должны быть названы, а потом блокированы известными механизмами.

Облачная подпись

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

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

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

Смарт-карта

Вот это главное. Вот это Владимир Иванов и предлагает. Что же, рассмотрим.

Вот как описывается предложение в журнале – прошу прощения за длинную цитату.

« … «Мы сегодня представляем наше новое устройство – это дуальная смарт-карта Рутокен ЭЦП 3.0 с интерфейсом NFC. … И у нас получается, что неизвлекаемые ключи подписи лежат на смарт-карте. Мы можем подписывать на этой карте данные и от приложений, и от браузера, и на мобильном приложении – фактически, где угодно. И плюс к тому, если мы работаем в облачной среде, мы эту смарт-карту можем использовать для аутентификации пользователя на облачном сервисе. Таким образом, ключи подписи продолжают лежать в облачном сервисе, а доступ к ним осуществляется по защищённым протоколам, с хорошей мощной аутентификацией на аппараты криптографии», – пояснил Владимир Иванов».

Оставим на совести автора странный для профессионала дискурс (типа «мощная аутентификация на аппараты криптографии»), рассмотрим суть предложения.

Итак:

  1. Пользователь работает на недоверенном терминале (смартфоне, компьютере, планшете и др.), у которого есть NFC.
  2. Рядом кладется смарт-карта с NFC, на которой реализовано СКЗИ с неизвлекаемым ключем подписи.
  3. По NFC из терминала на смарт-карту направляется документ.
  4. Документ подписывается за счет СКЗИ на смарт-карте.
  5. И отправляется по NFC снова на недоверенный компьютер.

    Вот как это выглядит графически.

    1.png

    Рис.1. Взаимодействие при использовании «облачных» ключей.
    Зеленым – доверенные элементы, красным – недоверенные.

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

    1. На недоверенном устройстве формируется платежное поручение, в котором фиксируется Ваше волеизъявление перечислить 100 рублей.
    2. Естественно, на экране вы видите цифру 100, и инициируете отправку этого документа на сервис СКЗИ.
    3. Вредоносное ПО (ВрПО), которое точно есть на недоверенном смартфоне, добавляет к указанной Вами сумме три нуля, и посылает на сервис 100 000.
    4. Доверенный сервис немедленно подписывает подлинной Вашей подписью модифицированную сумму и отправляет документ обратно.
    5. ВрПО получает этот документ, убирает лишние три нуля и посылает на отображение.
    6. Вы видите «правильный» подписанный документ, и инициируете передачу его в банк.
    7. Передается, конечно, не то, что Вы видите, а то, что подписано – то есть 100 000 с подлинной Вашей подписью.

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

Странно, что до сих пор приходится это объяснять. Мне казалось, что достаточно прочесть ФЗ об электронной подписи, и стараться потом в своей деятельности его не нарушать.

Итак:

Никакая сервисная схема не обеспечит безопасности, если используются недоверенные устройства, даже если сервис предоставляет доверенная «дуальная смарт-карта Рутокен ЭЦП 3.0 с интерфейсом NFC». Все дело в том, что карта – это просто вычислитель, маленькая машина Тьюринга, которая вычисляет все, что угодно, а вовсе не то, что мы от нее ожидаем. Целое – это единство формы и содержания, а машина Тьюринга ничего не знает о содержании, она оперирует с формой, с числами, а не с тем, о чем эти числа. Мы разорвали единство, и получили проблемы.

Смысл и безопасность

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

Обычно атака развивается следующим образом:

  • S1 - внедряется вредоносное ПО (ВрПО), например, подменяется обработчик прерываний
  • S2 - организовывается скрытый канал связи
  • S3 - инициируется событие, вызывающее внедренное прерывание
  • S4 - подмененный обработчик реализует атаку.

Каждому из этих вредоносных шагов есть меры противодействия, реализуемые известными в технической защите информации средствами. Каждому, кроме одного – а именно, – S3. Покажем это.

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

Из этого примера ясно, что семантическая определенность данных способна резко, на порядки сократить количество успешных атак.

Как это сделать – в одной из следующих статей.  

Заключение

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

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

[1] Цитируется по тексту журнала с сохранением особенностей изложения

Автор: Конявский В. А.

Дата публикации: 03.12.2020

Библиографическая ссылка: Конявский В. А. Смысл и безопасность // Information Security/Информационная безопасность. М., 2020. № 5. С. 54–56.


Scientia potestas est
Кнопка связи