Поддержка криптопро фкн нет что это значит

Функциональный ключевой носитель (ФКН) – это новая технология, позволяющая существенно повысить безопасность систем, использующих электронную цифровую подпись.

Функциональный ключевой носитель — архитектура программно — аппаратных продуктов со смарткартой или USB ключом, аппаратно реализующих российские криптоалгоритмы ЭП и шифрования (ГОСТ Р 34.10-2001/ГОСТ Р 34.11-94, ГОСТ 28147-89), позволяющая безопасно хранить и использовать закрытые ключи в защищённой памяти смарткарты или USB ключа.

В последнее время все большее внимание уделяется вопросам безопасности хранения закрытых ключей. Ключевые контейнеры на небезопасных носителях (таких как дискеты) уходят в прошлое. Но и к получившим широкое распространение ключевым контейнерам на защищенных носителях — USB ключам и смарткартам предъявляются все более жесткие требования в области защиты ключа.

Частично таким новым требованиям удовлетворяют USB ключи и смарткарты с аппаратной реализацией подписи, получившие широкое распространение в зарубежной практике. Например, USB ключи и смарткарты, удовлетворяющие стандартам PKCS#11. Но данные стандарты были разработаны достаточно давно и не учитывают возникновение новых угроз, таких как уязвимость к атакам подмены подписи или хэш-значения в канале связи между микропроцессором карты (ключа) и программным обеспечением на компьютере.

Архитектура Функционального ключевого носителя, предлагаемая компанией КРИПТО-ПРО, реализует принципиально новый подход к обеспечению безопасного использования ключа на смарткарте или usb-токене, который кроме аппаратной генерации ключей и формирования ЭП в микропроцессоре ключевого носителя, позволяет эффективно противостоять атакам, связанным с подменой хэш-значения или подписи в канале связи между программной и аппаратной частью CSP .

Основными преимуществами ФКН являются:

повышенная конфиденциальность ключа пользователя;
генерация ключей ЭП, ключей согласования, а также создание ЭП, происходит внутри ФКН;
выполнение криптографических операций на эллиптических кривых непосредственно ключевым носителем, поддержка российской ЭП;
усиленная защита данных при передаче по открытому каналу, благодаря использованию взаимной аутентификации ключевого носителя и программной составляющей при помощи оригинального протокола КРИПТО-ПРО на основе процедуры EKE (encrypted key exchange). При этом передается не PIN-код, а точка на эллиптической кривой;
передача хэш-значения по защищенному каналу, исключающему возможность подмены;
ни в какой момент, кроме создания контейнера, ключ пользователя не хранится ни в ключевом контейнере, ни в памяти криптопровайдера и не используются в явном виде в криптографических преобразованиях. Соответственно, даже удачная аппаратная атака на ключевой носитель не поможет узнать ключ;
исключена возможность подмены подписи в протоколе обмена, ЭП вырабатывается по частям — сначала в ключевом носителе, потом окончательно в CSP;
ключ может быть сгенерирован ФКН или загружаться извне.

Источник

Поддержка криптопро фкн нет что это значит

В предыдущей статье мы описали виды ключевых носителей, которые представлены на российском рынке, и указали на их достоинства и недостатки. В ней был сделан вывод, что наиболее безопасным видом ключевых носителей является ФКН — «функциональный ключевой носитель». В настоящей статье мы развиваем эту тему рассказом об использовании устройств контроля подписи.

В отличие от обычных активных носителей, где аутентификация производится простым явным предъявлением ПИН-кода по открытому каналу, ФКН для аутентификации и установления защищенного канала используют протокол SESPAKE (см. «Рекомендации по стандартизации Р-50.1.115–2016» и RFC 8133).

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

Устройство контроля подписи

Однако есть атака, от которой не застрахованы даже ФКН: подмена подписываемых данных до передачи их криптопровайдеру. В этом случае нарушитель находится между пользователем и криптопровайдером, в адресном пространстве пользовательского процесса, и имеет возможность незаметно изменить данные, которые пользователь хочет подписать.

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

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

Криптопровайдер, получив данные для хэширования, которые потом надо будет подписать, не только сам хэширует их, но и посылает в устройство контроля подписи. В результате хэширования в криптопровайдере получается значение, названное на рисунке ХЭШ_CP.

УКП имеет экран, на который оно выводит значимую часть подписываемого документа. После отображения документа на экране устройство запрашивает у пользователя разрешение на подпись. Если тот согласился, считается значение хэша документа, которое сохраняется в кэше устройства. На рисунке оно названо ХЭШ_V.

Когда криптопровайдер посылает носителю, вставленному в УКП, APDU-команду подписи, устройство контроля подписи перехватывает ее, выделяет из нее переданный хэш, и последовательно сравнивает со всеми значениями из своего кэша, то есть с теми, на которые получено разрешение пользователя. Если в кэше находится такое же значение, команда подписи пропускается к носителю, в противном случае отвергается. Таким образом, отвергаются все команды подписи, кроме содержащих хэши от данных, явно одобренных пользователем.

Если нарушитель попытается прямо в канал между криптопровайдером и носителем записать APDU-команду, содержащую некоторый ХЭШ_X, она будет отвергнута. Точно так же будет отвергнута команда, содержащая хэш от данных, которые не передавались криптопровайдером устройству контроля подписи, или от данных, не получивших разрешения пользователя (на рисунке — ХЭШ₀₎.

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

Фактически, устройство контроля подписи является легальным MitM-нарушителем, фильтрующим обмен сообщениями между носителем и криптопровайдером.

Контроль подписи и ФКН

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

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

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

Криптопровайдер работает с устройством контроля подписи и с ФКН точно так же, как было описано ранее. Функциональный носитель получает все APDU-команды подписи по защищенному каналу. Но у носителя есть две специальных APDU-команды, разрешенных и по открытому каналу:

команда, переводящая ФКН в режим работы по «белому списку»;
команда, передающая в ФКН одно из значений из «белого списка».

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

Эти две команды формирует и посылает носителю устройство контроля подписи. Также УКП следит, чтобы носителю не были переданы эти команды со стороны криптопровайдера, из канала, в котором может быть нарушитель (это возможно, если защищенный канал еще не был установлен). А так как между носителем и устройством контроля подписи нарушителя нет (ведь токен или смарт-карта напрямую вставляется в корпус устройства или встроен в УКП), то гарантируется, что кэш носителя будет наполнен только хэшами, переданными устройством контроля подписи.

Первую команду устройство контроля подписи посылает носителю, когда перехватывает APDU-команду аутентификации по SESPAKE (она означает, что криптопровайдер собирается установить защищенный канал с носителем, в котором, возможно, будут проходить команды подписи). Следом УКП посылает носителю все значения хэшей, разрешенных пользователем в тот момент, а после этого уже пересылает перехваченную команду аутентификации. Также устройство контроля подписи посылает очередной хэш носителю в тот момент, когда пользователь разрешает его подпись.

Работающий по такой схеме носитель может быть вставлен и использоваться как с обычным считывателем, так и с УКП.
Устройство контроля подписи не встраивается в защищенный канал, а обменивается данными с криптопровайдером и носителем по открытому каналу.
Криптопровайдер взаимодействует с ФКН, вставленным в УКП, точно так же, как если бы он был вставлен в обычный считыватель.
Достигается основная цель: подписи хэшей данных, отвергнутых пользователем, или не передававшихся в устройство контроля подписи, будут отвергнуты носителем (см. на рисунке ситуацию для ХЭШ₀).
ХЭШ_X, как было сказано выше, будет отфильтрован, потому что команда подписи в ФКН может быть передана только по защищенному каналу.

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

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

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

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

зам. начальника отдела разработки ФКН,

Источник

Извлечение ключа из токена с неизвлекаемым ключом

Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…

Конфигурация тестового стенда

Методика тестирования

Смоделируем типовой процесс подготовки Администратором информационной безопасности ключевых документов для организации ЭДО:

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

В нашем случае мы не будем пользоваться услугами центров сертификации, а сгенерируем ключевой контейнер с самоподписанным сертификатом и разместим его в реестре компьютера (АРМа генерации ключевой информации), это и будет исходный ключевой документ. Затем скопируем ключевую информацию на Рутокен ЭЦП и JaCarta ГОСТ, изготовив рабочие ключевые документы. После этого уничтожим исходный ключевой документ, удалив из реестра ключевой контейнер. И, наконец, попробуем скопировать ключевую информацию с рабочих ключевых документов обратно в реестр.

Проведение тестирования

Как мы видим, ключевая информация успешно скопирована или, другим языком, извлечена из токенов с неизвлекаемым ключом. Получается, что производители токенов и СКЗИ врут? На самом деле нет, и ситуация сложнее, чем кажется на первый взгляд. Исследуем матчасть по токенам.

Матчасть

То, что на рынке принято называть токеном с неизвлекаемым ключом, правильно называется функциональным ключевым носителем (ФКН) (доп. инфо).

Главным отличием ФКН от обычных токенов (Рутокен 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. Это и позволит использовать токен как ФКН.

Источник