Журнал "Information Security/ Информационная безопасность" #5, 2020

любую программу могут выполнить смартфоны? А думалось, что они вполне соответствуют модели Тьюринга и тезису Черча-Тьюринга о том, что машина Тью- ринга способна выполнить любой вычис- лимый алгоритм. Итак, использовать приложение в качестве СКЗИ – плохая идея. Это правильный вывод, хотя и не сформулированный в статье, а вот аргу- ментация беспомощная, поэтому дове- рия и не возникает. Сим-карты Недостатки, которые Владимир Ива- нов нашел у сим-карт, сводятся к сле- дующему: l нужно производить специальные сим- карты, а это стоит денег; l возникает проблема с идентификаци- ей пользователей: мобильный оператор не является УЦ; l доступ к сим-карте возможен только из сим-приложения; l и вообще, сим-карты – это уже про- шлое. Рассмотрим первые два пункта, этого достаточно. Доступ программируется, а сим-карты есть. Переход на виртуальные сим-карты давно обещан, но пока не реализован. А сразу после реализации виртуальные сим-карты наверняка будут атакованы хакерами, и, видимо, это даст новый виток противостояния, кото- рый завершится внесением изменений в аппаратную структуру смартфона. Таким образом, именно этот вариант и стоит рассматривать, иначе изменения аппаратуры могут оказаться бесполез- ными с точки зрения технической защи- ты информации. А использовать такой шанс очень заманчиво. "Специальные сим-карты стоят денег" Справедливо. Но означает ли указание на этот недостаток то, что предлагаемые автором решения не стоят денег? Инте- ресненько. Раньше нам казалось, что в аппаратном смысле смарт-карты и сим-карты не сильно отличаются. Почему же решение "Актива" ничего не стоит? Странный способ маркетинга. "Идентификация и УЦ" Это серьезная проблема, и ее стоит обсудить. Причем с самого начала, от 1-ФЗ до нынешних времен. Дело в том, что в общественном сознании укрепился миф (как минимум, заблуждение, а может, и фейк), что УЦ призван изго- тавливать ключ подписи. Но это не так! Это лишь одна из услуг, которую УЦ может (может!) оказать, но окажет толь- ко в том случае, если гражданин вне- запно проникнется огромным и ничем необъяснимым доверием к УЦ и его персоналу. А главная, основная функция УЦ – изготовление сертификата ключа проверки подписи. Вот и все. И ничего другого. Правильный, безопасный процесс получения сертификата ключа подписи и, соответственно, возможности исполь- зовать электронную подпись в процессе информационного взаимодействия заключается в следующем: 1. Пользователь устанавливает СКЗИ, в состав функций которого обязательно входят функции генерации ключевой пары. 2. С использованием СКЗИ генериру- ется ключ подписи и вычисляется ключ проверки подписи. 3. Ключ подписи записывается на выбранные пользователем носители, один или несколько – здесь пользова- тель ничем не ограничен, кроме собст- венных представлений о безопасности. 4. Ключ проверки подписи также запи- сывается на носитель, но уже другой. Этот носитель понадобиться для визита в УЦ. 5. Пользователь обращается в УЦ за услугой изготовления сертификата ключа подписи, передавая в УЦ в каче- стве исходных данных ключ проверки подписи – этого для УЦ вполне доста- точно (кроме, естественно, обычных документов). 6. УЦ изготавливает сертификат ключа подписи и записывает его на носитель, который удобен для пользователя. Как мы видим, этот процесс никак не связан с тем, является ли оператор связи заодно и удостоверяющим цент- ром. Оператор связи продает оборудо- вание, а УЦ изготавливает СКП. И совер- шенно необязательно объединять эти две разные услуги. А функцию записи ключа на носитель должен реализовать вендор СКЗИ. Очевидно, что УЦ излиш- не настойчиво предлагают пользователю услугу, которая заключается в полном цикле, от генерации ключа подписи до изготовления СКП. Наверное, можно и так, хотя в результате безопасность информационного взаимодействия выглядит сомнительной. Такой подход аналогичен тому, что при визите в пас- портный стол мы просили бы паспор- тистку не зафиксировать нашу подпись, а придумать ее и самостоятельно внести в паспорт и учетную карточку. Согласи- тесь, похоже на бред. И почему же мы не видим аналогии в просьбе к УЦ изго- товить ключ подписи за нас? Проблема очевидна. Разрешается она, с одной стороны, созданием правильных СКЗИ, позволяющих пользователю реа- лизовать описанную выше процедуру, и повышением грамотности пользовате- лей, которые сейчас бредут по извили- стой тропинке, навязываемой УЦ. И уж совсем ни при чем тут мнимые недо- статки сим-карты. Токены Токен всем хорош, только нельзя его недорого сделать таким, чтобы его кон- такты позволяли подключить его к любо- му смартфону. А из радиоканалов на смартфонах есть только Bluetooth, и он ненадежен – вот краткое изложение мнения Владимира Иванова. Но почему нужно делать токен, кото- рый снабжен всеми типами разъемов? Автор нам не сообщает. Давайте делать токены с разными типами разъемов, что этому мешает? Только не говорите, что ключ подписи обязательно нераз- рывно связан со своим носителем, это техническая бессмыслица. Нужно акку- ратно решать несложную инженерную задачу, и все будет хорошо. Ну и о ненадежности Bluetooth: не стоит так огульно оценивать один из весьма удачных протоколов. Если есть уязвимости, существенные с точки зре- ния безопасности, то они должны быть названы, а потом блокированы извест- ными механизмами. Облачная подпись Обычно под облачной подписью пони- мают механизм, при котором ключи под- писи отчуждены от их владельца и хра- нятся где-то далеко и надежно, но поль- зователь может все же воспользоваться ими и подписать документ. Все так, но, по меткому замечанию Владимира Ива- нова, задача доверенного хранения и использования ключей подписи заме- щается при этом нерешаемой задачей доверенной идентификации пользова- теля с помощью недоверенного устрой- ства. В применении облачных решений Ива- нов видит проблему в сложности интег- рации (правда, не говорит, что и с чем нужно интегрировать), а не в том, что нельзя доверять идентификации на недо- веренном устройстве, даже если недо- веренной является только одна сторона из двух. Здесь отметим лишь то, что уже есть идеи, позволяющие решить проблему идентификации с помощью недоверен- ного устройства. Это интерактивная рефлекторная биометрическая иденти- фикация. О ней уже достаточно напи- сано, что можно было бы заметить, если занимаешься этим вопросом. Решения скоро появятся на рынке, и тогда применение облачных техноло- гий в цифровых сервисах окажется воз- можным, несмотря на мифические труд- ности интеграции. Смарт-карта Вот это главное. Вот это Владимир Иванов и предлагает. Что ж, давайте рассмотрим. Вот как описывается предложение в журнале (прошу прощения за длинную цитату). " … Мы сегодня представляем наше новое устройство – это дуальная смарт- карта Рутокен ЭЦП 3.0 с интерфейсом NFC. …И у нас получается, что неизвлекаемые ключи подписи лежат на смарт-карте. Мы можем подписы- вать на этой карте данные и от прило- • 55 КРИПТОГРАФИЯ www.itsec.ru