В предыдущей статье мы описали виды ключевых носителей, которые представлены на российском рынке, и указали на их достоинства и недостатки. В ней был сделан вывод, что наиболее безопасным видом ключевых носителей является ФКН — «функциональный ключевой носитель». В настоящей статье мы развиваем эту тему рассказом об использовании устройств контроля подписи.
В отличие от обычных активных носителей, где аутентификация производится простым явным предъявлением ПИН-кода по открытому каналу, ФКН для аутентификации и установления защищенного канала используют протокол SESPAKE (см. "Рекомендации по стандартизации Р-50.1.115–2016" и RFC 8133).
После выполнения протокола между токеном и криптопровайдером устанавливается защищенное соединение, а все данные, которыми они обмениваются, проходят в зашифрованном виде. Нарушитель, прослушивающий канал, не только не может узнать, какие данные подписываются на носителе, но даже понять, команда какого типа посылается криптопровайдером. Более подробно о протоколе можно прочитать в статье на Хабрахабре.
Устройство контроля подписи
Однако есть атака, от которой не застрахованы даже ФКН: подмена подписываемых данных до передачи их криптопровайдеру. В этом случае нарушитель находится между пользователем и криптопровайдером, в адресном пространстве пользовательского процесса, и имеет возможность незаметно изменить данные, которые пользователь хочет подписать.
Так как криптопровайдер не показывает пользователю, какие именно данные он отправляет на подпись, подмененная информация успешно подписывается. Поскольку в данном случае речь идет о нарушителе в адресном пространстве процесса, никакими программными способами, добавленными в криптопровайдер, защититься от него нельзя.
Тут на помощь приходят устройства контроля подписи (УКП), которые отображают на экране подписываемые данные, запрашивающие у пользователя разрешение на подпись. Принцип их действия показан на рисунке ниже. Как правило, они либо представляют собой считыватель, в который может быть вставлен активный носитель, либо сами являются активными носителями с экраном. В любом случае предполагается, что между таким устройством и носителем нарушителя нет. А вот между ним и криптопровайдером, или в одном адресном пространстве с криптопровайдером, нарушитель может быть.
Криптопровайдер, получив данные для хэширования, которые потом надо будет подписать, не только сам хэширует их, но и посылает в устройство контроля подписи. В результате хэширования в криптопровайдере получается значение, названное на рисунке ХЭШCP.
УКП имеет экран, на который оно выводит значимую часть подписываемого документа. После отображения документа на экране устройство запрашивает у пользователя разрешение на подпись. Если тот согласился, считается значение хэша документа, которое сохраняется в кэше устройства. На рисунке оно названо ХЭШV.
Когда криптопровайдер посылает носителю, вставленному в УКП, APDU-команду подписи, устройство контроля подписи перехватывает ее, выделяет из нее переданный хэш, и последовательно сравнивает со всеми значениями из своего кэша, то есть с теми, на которые получено разрешение пользователя. Если в кэше находится такое же значение, команда подписи пропускается к носителю, в противном случае отвергается. Таким образом, отвергаются все команды подписи, кроме содержащих хэши от данных, явно одобренных пользователем.
Если нарушитель попытается прямо в канал между криптопровайдером и носителем записать APDU-команду, содержащую некоторый ХЭШX, она будет отвергнута. Точно так же будет отвергнута команда, содержащая хэш от данных, которые не передавались криптопровайдером устройству контроля подписи, или от данных, не получивших разрешения пользователя (на рисунке — ХЭШ0).
Большим плюсом такого подхода является возможность работы с активным носителем как с помощью обычных считывателей, так и через УКП. Носитель, использовавшийся с устройством контроля подписи, в любой момент времени можно вставить в обычный считыватель и выполнить подпись на том же закрытом ключе.
Фактически, устройство контроля подписи является легальным MitM-нарушителем, фильтрующим обмен сообщениями между носителем и криптопровайдером.
Контроль подписи и ФКН
Кажется, что данная логика входит в противоречие с идеологией ФКН, в рамках которой невозможны даже «легальные нарушители». Защищенный канал, устанавливаемый между криптопровайдером и носителем, скрывает команды подписи, поэтому УКП не может отфильтровать неразрешенные пользователем хэши. И хотя ФКН защищен от формирования злоумышленником собственной команды в канале между криптопровайдером и носителем, он беззащитен от передачи в криптопровайдер подмененных данных. Это могло бы ограничить возможности использования функциональных носителей, но у данной проблемы есть решение и мы его здесь представим.
В случае если устройство контроля подписи совмещено с носителем (то есть фактически они — единое целое), то систему фильтра переданных хэшей можно разместить уже после расшифрования команд внутри устройства, так что никакой проблемы нет.
Но если устройство контроля подписи представляет собой только считыватель, в который может быть вставлен один из множества функциональных носителей, решение несколько сложнее, и заключается в переносе кэша разрешенных хэшей в носитель. Принцип действия в этом случае изображен на рисунке ниже.
Криптопровайдер работает с устройством контроля подписи и с ФКН точно так же, как было описано ранее. Функциональный носитель получает все APDU-команды подписи по защищенному каналу. Но у носителя есть две специальных APDU-команды, разрешенных и по открытому каналу:
- команда, переводящая ФКН в режим работы по «белому списку»;
- команда, передающая в ФКН одно из значений из «белого списка».
«Белый список» — это, по сути, тот же кэш хэшей, только хранящийся в носителе. После получения первой команды носитель, получив команду подписи, проверяет, есть ли подписываемый хэш в его кэше, и подписывает только те хэши, которые нашел. Вторая команда передает носителю значения хэша, которые тот сохраняет в свой кэш. Не получив первую команду, ФКН подписывает любой переданный ему хэш.
Эти две команды формирует и посылает носителю устройство контроля подписи. Также УКП следит, чтобы носителю не были переданы эти команды со стороны криптопровайдера, из канала, в котором может быть нарушитель (это возможно, если защищенный канал еще не был установлен). А так как между носителем и устройством контроля подписи нарушителя нет (ведь токен или смарт-карта напрямую вставляется в корпус устройства или встроен в УКП), то гарантируется, что кэш носителя будет наполнен только хэшами, переданными устройством контроля подписи.
Первую команду устройство контроля подписи посылает носителю, когда перехватывает APDU-команду аутентификации по SESPAKE (она означает, что криптопровайдер собирается установить защищенный канал с носителем, в котором, возможно, будут проходить команды подписи). Следом УКП посылает носителю все значения хэшей, разрешенных пользователем в тот момент, а после этого уже пересылает перехваченную команду аутентификации. Также устройство контроля подписи посылает очередной хэш носителю в тот момент, когда пользователь разрешает его подпись.
В итоге:
- Работающий по такой схеме носитель может быть вставлен и использоваться как с обычным считывателем, так и с УКП.
- Устройство контроля подписи не встраивается в защищенный канал, а обменивается данными с криптопровайдером и носителем по открытому каналу.
- Криптопровайдер взаимодействует с ФКН, вставленным в УКП, точно так же, как если бы он был вставлен в обычный считыватель.
- Достигается основная цель: подписи хэшей данных, отвергнутых пользователем, или не передававшихся в устройство контроля подписи, будут отвергнуты носителем (см. на рисунке ситуацию для ХЭШ0).
- ХЭШX, как было сказано выше, будет отфильтрован, потому что команда подписи в ФКН может быть передана только по защищенному каналу.
Основная опасность данного способа в том, что носителю будет передана команда, записывающая хэш нарушителя в «белый список». Но так как, как отмечено выше, нарушителя между устройством контроля подписи и носителем нет, а все команды записи хэша в «белый список», полученные УКП снаружи, отфильтровываются, нарушитель не может записать в кэш носителя свой хэш.
Использование же этих команд без устройства контроля подписи не сможет снизить защищенности ФКН: максимум, можно перевести носитель в режим работы по «белому списку», после чего он откажется принимать от криптопровайдера любые команды подписи до ближайшей команды сброса состояния, но это не заставит его ни подписывать хэши, переданные по открытому каналу, ни каким-то образом раскрыть хранимую на нем закрытую информацию.
Основным недостатком метода является то, что работать с УКП могут не любые ФКН, а только те, которые поддерживают «белые списки». Но поддержка не требует больших затрат ресурсов от носителей: чаще всего между выработкой хэша и его подписью проходит минимальное количество времени, и поэтому можно использовать один кэш для всего ФКН, размером порядка десяти значений, с вытеснением старых хэшей новыми. А операция нахождения в кэше значения, совпадающего с переданным в команде подписи, не является сложной для микропроцессора носителя.
Таким образом, предложенная схема позволяет использовать функциональные ключевые носители вместе с устройствами контроля подписи, что делает их защищенными от атаки с подменой данных, сохраняя все прочие положительные качества ФКН.
Бородин Г.О.,
ведущий инженер-программист,
компания КриптоПро
Агафьин С.С.,
зам. начальника отдела разработки ФКН,
компания КриптоПро
Смышляев С.В., к.ф.-м.н.,
руководитель департамента информационной безопасности,
компания КриптоПро