Данная страница перенесена в архив. Актуальную информацию можно узнать в разделе по ссылке.
КриптоПро ФКН CSP 3.9 — средство криптографической защиты информации (СКЗИ), которое позволяет вывести защиту секретного ключа пользователя на качественно новый уровень и увеличить срок его действия до 3-х лет.
СКЗИ КриптоПро ФКН CSP 3.9 реализовано с использованием архитектуры ФКН и дополнительно содержит набор ограничительных счётчиков, позволяющих существенно ограничивать возможности реализации атак, связанных с опробованием значений пароля (PIN-кода).
Аппаратные средства
КриптоПро ФКН CSP 3.9 используется со смарт-картой или USB-ключом JaCarta CryptoPro российской компании «Аладдин Р.Д.». Устройства содержат в своём составе смарт-карточный микроконтроллер, имеющий защиту от клонирования, взлома, физических, логических, статистических, переборных и стрессовых атак, атак с использованием специальных зондов и т.д. Высокие защитные качества микроконтроллера и операционной системы подтверждаются сертификатом соответствия профилю защиты Security IC Platform Protection Profile, версия 1.0. Оценка соответствия выполнена по методике Common Criteria (версия 3.1, ревизия 3). Достигнутый уровень доверия — EAL 5+.
Области применения
СКЗИ КриптоПро ФКН CSP 3.9 предназначено для использования в российских системах PKI, в системах юридически значимого электронного документооборота и в других информационных системах, использующих технологии электронной подписи, например:
Функциональный ключевой носитель на базе устройств JaCarta
Средство криптографической защиты информации, предназначенное для формирования электронной подписи в системах юридически значимого электронного документооборота и других информационных системах, где требуются технологии ЭП:
Продукт разработан лидерами рынка информационной безопасности России – компаниями «КРИПТО-ПРО» и «Аладдин Р.Д.».
Решаемые задачи
Особенности
Главной особенностью «КриптоПро ФКН CSP» версии 3.9 (ранее продукт назывался «КриптоПро eToken CSP») является использование технологии функционального ключевого носителя (ФКН).
Благодаря наличию защищённого канала связи между токеном и криптопровайдером часть криптографических преобразований, включая хранение закрытых ключей и ключей ЭП в неизвлекаемом виде, выносится на смарт-карту или USB-токен.
Кроме аппаратной генерации ключей, их безопасного хранения и формирования ЭП в микропроцессоре ключевого носителя, архитектура ФКН позволяет эффективно противостоять атакам, связанным с подменой хэш-значения или подписи в канале связи между программной и аппаратной частью CSP.
В «КриптоПро ФКН CSP» версии 3.9 в качестве ключевого носителя выступает специально разработанный токен JaCarta CryptoPro, представленный в форм-факторах смарт-карты и USB-токена.
В состав СКЗИ «КриптоПро ФКН CSP» версии 3.9 входит специально разработанный токен JaCarta CryptoPro с возможностью вычисления ЭП по технологии ФКН компании «КРИПТО-ПРО» и выпускаемый в форм-факторах USB-токена (в корпусе Nano или XL) или смарт-карты.
JaCarta CryptoPro осуществляет безопасное хранение и использование закрытых ключей ЭП, выполняет взаимную аутентификацию CSP и токена, а также строгую двухфакторную аутентификацию пользователя-владельца токена.
Ключевые преимущества JaCarta CryptoPro
Состав
«КриптоПро ФКН CSP» версии 3.9 состоит из двух ключевых компонент:
Архитектура «КриптоПро ФКН CSP» версии 3.9
Технические характеристики токена JaCarta CryptoPro
Самым безопасным вариантом хранения контейнера с сертификатом и ключом электронной подписи (ЭП) является ключевой носитель, защищенном PIN-кодом. Такие носители существуют в двух более распространенных форм-факторах: USB-токен и смарт-карта.
Для носителей Рутокен существуют следующие режимы работы с КриптоПро CSP:
Активный (Активный токен без защиты канала). Контейнер генерируется при помощи внутреннего криптоядра Рутокена семейства ЭЦП, с использованием библиотеки PKCS#11. В таком режиме контейнер тоже хранится на токене или смарт-карте. Отличие в том, что пользователь может получить от этого носителя результат выполнения криптографических операций с использованием хранимого на устройстве закрытого ключа, поэтому такие ключи нельзя украсть или скопировать. В данном случае ключ является неизвлекаемым. Активные носители имеют возможность хранить контейнеры в пассивном режиме, что снижает безопасность ключа.
Ключевые носители Рутокен и поддерживаемые ими режимы работы
Каждый Рутокен работает в одном, двух или трех режимах.
В таблице указаны носители, продемонстрировавшие работоспособность с соответствующими версиями КриптоПро CSP.
На пересечении строки с названием модели Рутокена и строки с версией КриптоПро CSP указаны режимы работы носителя.
В предыдущей статье мы описали виды ключевых носителей, которые представлены на российском рынке, и указали на их достоинства и недостатки. В ней был сделан вывод, что наиболее безопасным видом ключевых носителей является ФКН — «функциональный ключевой носитель». В настоящей статье мы развиваем эту тему рассказом об использовании устройств контроля подписи.
В отличие от обычных активных носителей, где аутентификация производится простым явным предъявлением ПИН-кода по открытому каналу, ФКН для аутентификации и установления защищенного канала используют протокол SESPAKE (см. «Рекомендации по стандартизации Р-50.1.115–2016» и RFC 8133).
После выполнения протокола между токеном и криптопровайдером устанавливается защищенное соединение, а все данные, которыми они обмениваются, проходят в зашифрованном виде. Нарушитель, прослушивающий канал, не только не может узнать, какие данные подписываются на носителе, но даже понять, команда какого типа посылается криптопровайдером. Более подробно о протоколе можно прочитать в статье на Хабрахабре.
Устройство контроля подписи
Однако есть атака, от которой не застрахованы даже ФКН: подмена подписываемых данных до передачи их криптопровайдеру. В этом случае нарушитель находится между пользователем и криптопровайдером, в адресном пространстве пользовательского процесса, и имеет возможность незаметно изменить данные, которые пользователь хочет подписать.
Так как криптопровайдер не показывает пользователю, какие именно данные он отправляет на подпись, подмененная информация успешно подписывается. Поскольку в данном случае речь идет о нарушителе в адресном пространстве процесса, никакими программными способами, добавленными в криптопровайдер, защититься от него нельзя.
Тут на помощь приходят устройства контроля подписи (УКП), которые отображают на экране подписываемые данные, запрашивающие у пользователя разрешение на подпись. Принцип их действия показан на рисунке ниже. Как правило, они либо представляют собой считыватель, в который может быть вставлен активный носитель, либо сами являются активными носителями с экраном. В любом случае предполагается, что между таким устройством и носителем нарушителя нет. А вот между ним и криптопровайдером, или в одном адресном пространстве с криптопровайдером, нарушитель может быть.
Криптопровайдер, получив данные для хэширования, которые потом надо будет подписать, не только сам хэширует их, но и посылает в устройство контроля подписи. В результате хэширования в криптопровайдере получается значение, названное на рисунке ХЭШCP.
УКП имеет экран, на который оно выводит значимую часть подписываемого документа. После отображения документа на экране устройство запрашивает у пользователя разрешение на подпись. Если тот согласился, считается значение хэша документа, которое сохраняется в кэше устройства. На рисунке оно названо ХЭШV.
Когда криптопровайдер посылает носителю, вставленному в УКП, APDU-команду подписи, устройство контроля подписи перехватывает ее, выделяет из нее переданный хэш, и последовательно сравнивает со всеми значениями из своего кэша, то есть с теми, на которые получено разрешение пользователя. Если в кэше находится такое же значение, команда подписи пропускается к носителю, в противном случае отвергается. Таким образом, отвергаются все команды подписи, кроме содержащих хэши от данных, явно одобренных пользователем.
Если нарушитель попытается прямо в канал между криптопровайдером и носителем записать APDU-команду, содержащую некоторый ХЭШX, она будет отвергнута. Точно так же будет отвергнута команда, содержащая хэш от данных, которые не передавались криптопровайдером устройству контроля подписи, или от данных, не получивших разрешения пользователя (на рисунке — ХЭШ0).
Большим плюсом такого подхода является возможность работы с активным носителем как с помощью обычных считывателей, так и через УКП. Носитель, использовавшийся с устройством контроля подписи, в любой момент времени можно вставить в обычный считыватель и выполнить подпись на том же закрытом ключе.
Фактически, устройство контроля подписи является легальным MitM-нарушителем, фильтрующим обмен сообщениями между носителем и криптопровайдером.
Контроль подписи и ФКН
Кажется, что данная логика входит в противоречие с идеологией ФКН, в рамках которой невозможны даже «легальные нарушители». Защищенный канал, устанавливаемый между криптопровайдером и носителем, скрывает команды подписи, поэтому УКП не может отфильтровать неразрешенные пользователем хэши. И хотя ФКН защищен от формирования злоумышленником собственной команды в канале между криптопровайдером и носителем, он беззащитен от передачи в криптопровайдер подмененных данных. Это могло бы ограничить возможности использования функциональных носителей, но у данной проблемы есть решение и мы его здесь представим.
В случае если устройство контроля подписи совмещено с носителем (то есть фактически они — единое целое), то систему фильтра переданных хэшей можно разместить уже после расшифрования команд внутри устройства, так что никакой проблемы нет.
Но если устройство контроля подписи представляет собой только считыватель, в который может быть вставлен один из множества функциональных носителей, решение несколько сложнее, и заключается в переносе кэша разрешенных хэшей в носитель. Принцип действия в этом случае изображен на рисунке ниже.
Криптопровайдер работает с устройством контроля подписи и с ФКН точно так же, как было описано ранее. Функциональный носитель получает все APDU-команды подписи по защищенному каналу. Но у носителя есть две специальных APDU-команды, разрешенных и по открытому каналу:
«Белый список» — это, по сути, тот же кэш хэшей, только хранящийся в носителе. После получения первой команды носитель, получив команду подписи, проверяет, есть ли подписываемый хэш в его кэше, и подписывает только те хэши, которые нашел. Вторая команда передает носителю значения хэша, которые тот сохраняет в свой кэш. Не получив первую команду, ФКН подписывает любой переданный ему хэш.
Эти две команды формирует и посылает носителю устройство контроля подписи. Также УКП следит, чтобы носителю не были переданы эти команды со стороны криптопровайдера, из канала, в котором может быть нарушитель (это возможно, если защищенный канал еще не был установлен). А так как между носителем и устройством контроля подписи нарушителя нет (ведь токен или смарт-карта напрямую вставляется в корпус устройства или встроен в УКП), то гарантируется, что кэш носителя будет наполнен только хэшами, переданными устройством контроля подписи.
Первую команду устройство контроля подписи посылает носителю, когда перехватывает APDU-команду аутентификации по SESPAKE (она означает, что криптопровайдер собирается установить защищенный канал с носителем, в котором, возможно, будут проходить команды подписи). Следом УКП посылает носителю все значения хэшей, разрешенных пользователем в тот момент, а после этого уже пересылает перехваченную команду аутентификации. Также устройство контроля подписи посылает очередной хэш носителю в тот момент, когда пользователь разрешает его подпись.
Основная опасность данного способа в том, что носителю будет передана команда, записывающая хэш нарушителя в «белый список». Но так как, как отмечено выше, нарушителя между устройством контроля подписи и носителем нет, а все команды записи хэша в «белый список», полученные УКП снаружи, отфильтровываются, нарушитель не может записать в кэш носителя свой хэш.
Использование же этих команд без устройства контроля подписи не сможет снизить защищенности ФКН: максимум, можно перевести носитель в режим работы по «белому списку», после чего он откажется принимать от криптопровайдера любые команды подписи до ближайшей команды сброса состояния, но это не заставит его ни подписывать хэши, переданные по открытому каналу, ни каким-то образом раскрыть хранимую на нем закрытую информацию.
Основным недостатком метода является то, что работать с УКП могут не любые ФКН, а только те, которые поддерживают «белые списки». Но поддержка не требует больших затрат ресурсов от носителей: чаще всего между выработкой хэша и его подписью проходит минимальное количество времени, и поэтому можно использовать один кэш для всего ФКН, размером порядка десяти значений, с вытеснением старых хэшей новыми. А операция нахождения в кэше значения, совпадающего с переданным в команде подписи, не является сложной для микропроцессора носителя.
Таким образом, предложенная схема позволяет использовать функциональные ключевые носители вместе с устройствами контроля подписи, что делает их защищенными от атаки с подменой данных, сохраняя все прочие положительные качества ФКН.
Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…
Конфигурация тестового стенда
Методика тестирования
Проведение тестирования
Как мы видим, ключевая информация успешно скопирована или, другим языком, извлечена из токенов с неизвлекаемым ключом. Получается, что производители токенов и СКЗИ врут? На самом деле нет, и ситуация сложнее, чем кажется на первый взгляд. Исследуем матчасть по токенам.
Матчасть
То, что на рынке принято называть токеном с неизвлекаемым ключом, правильно называется функциональным ключевым носителем (ФКН) (доп. инфо).
Главным отличием ФКН от обычных токенов (Рутокен S, JaCarta PKI, …) в том, что при выполнении криптографических преобразований (например, формирование электронной подписи) закрытый ключ не покидает устройство. В то время как при использовании обычных токенов закрытый ключ копируется с токена в память комптьютера.
Использование ФКН требует особой организации взаимодействия между прикладным криптографическим ПО и библиотекой СКЗИ (криптопровайдером или, по-другому, CSP).
Здесь важно увидеть, что программная часть библиотеки СКЗИ должна знать о существовании на токене апплета, реализующего криптографический функционал (например, генерация ключа, подпись данных и т.д.) и уметь с ним работать.
По-новому взглянем на наш тестовый стенд
В качестве одного из ключевых носителей использовался Рутокен ЭЦП. Через «Панель управления Рутокен» о нем можно получить следующую информацию:
В последней строке указана фраза «Поддержка КриптоПРО ФКН: Нет», а это значит, что на токене нет апплета, с которым умеет работать СКЗИ КриптоПРО CSP. Таким образом, реализация технологии ФКН с использованием СКЗИ и токенов, описанных в конфигурации тестового стенда, невозможна.
Аналогичная ситуация и с JaCarta ГОСТ. Более того, СКЗИ КриптоПРО CSP, по крайней мере та версия, которая использовалась в тестовом стенде, использует данные ключевые носители как «обычные токены», которые, в свою очередь, являются просто носителями ключа.
Это утверждение очень просто подтвердить. Для этого надо поставить СКЗИ КриптоПРО CSP на чистую машину без драйверов от токенов и подключить токен JaCarta ГОСТ. ОС Windows 7 обнаружит токен JaCarta ГОСТ как «Устройство чтения смарт-карт Microsoft Usbccid (WUDF)». теперь можно попробовать создать ключ на токене и скопировать его в реестр компьютера. Весь функционал СКЗИ успешно отработает.
Как сделать, чтобы все было хорошо?
Чтобы с помощью продуктов ООО “КРИПТО-ПРО” реализовать технологию ФКН, необходимо:
1. Купить специальную версию библиотеки СКЗИ: — для Рутокен ЭЦП — СКЗИ КриптоПРО Рутокен CSP. — для JaCarta ГОСТ – СКЗИ КриптоПро ФКН CSP.
2. Одновременно с библиотекой СКЗИ необходимо приобрести специально подготовленные токены, содержащие в себе программные части (апплеты), с которыми умеет работать КриптоПРО Рутокен CSP или КриптоПро ФКН CSP соответственно.
Получается, что Рутокен ЭЦП и JaCarta ГОСТ не являются токенами с неизвлекаемым ключом?
Опять нет. Данные устройства могут реализовывать функционал ФКН (но, возможно, в меньшем объеме, чем при использовании их совместно с СКЗИ КриптоПРО), но для этого нужен софт, который умеет работать с апплетами размещенными на токенах. Таким софтом может быть КриптоАРМ Стандарт 5 Плюс. Он это умеет. При генерации ключевой пары в мастере КриптоАРМ можно выбрать криптопровайдер, который будет использоваться, например, Rutoken ECP или eToken GOST. Это и позволит использовать токен как ФКН.
В предыдущей статье мы описали виды ключевых носителей, которые представлены на российском рынке, и указали на их достоинства и недостатки. В ней был сделан вывод, что наиболее безопасным видом ключевых носителей является ФКН — «функциональный ключевой носитель». В настоящей статье мы развиваем эту тему рассказом об использовании устройств контроля подписи.
