Российские платёжные HSM модули

Автор:
Елена Владимировна Мареева, заместитель Генерального директора по научно-техническим разработкам

Немного истории

Первая попытка импортозамещения платёжных HSM была предпринята ещё в 2003 году, когда появились РМБ (российские модули безопасности), которые являлись функциональными аналогами HSM 7000 фирмы Racal. Первые опытные образцы имели поддержку криптографических механизмов только для карт международных платёжных систем с магнитной полосой. По мере выполнения плана миграции на чиповые карты и появления криптографических механизмов и стандартов EMVco, функциональность в этой части добавлялась и в РМБ. РМБ достаточно долго эксплуатировались в Сбербанке на участках печати пин-конвертов, использовались в контуре управления ключевой информацией для терминальных устройств, а также в тестовом контуре системы. В этот же период начали формироваться и требования PCI к модулям безопасности для платёжных систем, а точнее для систем платёжных карт (далее — платёжный HSM), как к отдельному классу устройств, обеспечивающих защиту данных держателей карт. Широкого внедрения РМБ не получили, так как не было законодательного регулирования об их применении в составе платёжных систем. Динамичная смена и совершенствование требований EMV, вызванная миграцией на чиповые карты и внедрением этой технологии в платёжную индустрию, обеспечивали преимущество по реализации данных требований у зарубежных вендоров за счёт оперативного доступа к драфтам и контрольным примерам новых криптографических механизмов.

Вторая попытка импортозамещения платёжных HSM была предпринята, а точнее начата в 2014 году, как ответ на санкции, введённые МПС Visa и MasterCard в отношении ряда российских банков и всех банков, работающих в Крыму. В это же время, был сформулирован перечень потенциальных угроз и их последствий в отношении платёжных HSM, который определил в качестве наиболее уязвимого звена, с точки зрения оценки последствий и силы атак потенциальных нарушителей, платёжные HSM модули, которые применяются в ядре банковских и платёжных систем.

В качестве целевых атак и их последствий, в отношении платёжных HSM, были определены следующие:

1. Управление ключевой информацией по зарубежным технологиям и стандартам, в том числе, из-за пределов РФ, и, как следствие, возможность несанкционированного управления ключами, отзыв сертификатов МПС, работа на договорных ключах.
2. Риск введения санкций против российской платежной системы, например, прекращение поставок оборудования и, как следствие, нарушение функционирования российской платежной системы даже внутри РФ.
3. Наличие скрытых функциональных возможностей (программные и/или аппаратные закладки) в импортном оборудовании и, как следствие, несанкционированный доступ к информационным активам системы платёжных карт и управляемый отказ в предоставлении услуг.
4. Технологическая зависимость от импортного оборудования, которая ставит развитие национальной системы платёжных карт и применяемого в ней оборудования в зависимость от планов, задаваемых иностранными технологиями и темпами развития.
5. Известные уязвимости и «back door» зарубежной криптографии и, как следствие, несанкционированный доступ к информационным активам национальной системы платёжных карт, нарушение работоспособности системы.
6. Замкнутость системы, невозможность парирования угроз, актуальных для национальной платёжной системы.

В период с 2015 по 2018 год был разработан и сертифицирован как СКЗИ класса КВ платёжный HSM — ViPNet HSM PS, который архитектурно был построен на базе аппаратной платформы ViPNet HSM c дополнительно реализованным платёжным приложением в составе среды изолированного токена. Внедрения устройства не получили, так как по-прежнему не было законодательного регулирования об их использовании в составе банковских и платёжных систем, а в качестве основной причины невозможности применения было обозначено отсутствие сертификата PCI PTS HSM.

Надо отметить, что в период с 2015 по 2021 год под руководством ЦБ РФ как раз активно формировались документы законодательного регулирования, функционально-технические требования к устройствам данного типа, а также требования к платёжным HSM как СКЗИ в информационной инфраструктуре платёжных систем.

Итоговым документом в части законодательного регулирования стало ПОЛОЖЕНИЕ ЦБ РФ от 4 июня 2020 г. N 719-п «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств…», которое определило новые требования о применении СКЗИ в системах платёжных карт:

• для платёжных HSM, являющихся российскими аналогами, требование вступает в силу с 01.01.2024. Оператор значимой платежной системы в соответствии с правилами платежной системы должен обеспечить использование в аппаратных модулях безопасности информационной инфраструктуры платежной системы СКЗИ, реализующих криптографические алгоритмы, не определенные национальными стандартами РФ, имеющих подтверждение соответствия требованиям, установленным ФОИВ в области обеспечения безопасности (5.5. абз.2);
• для платёжных HSM, являющихся российскими аналогами и с российскими криптографическими алгоритмами, требование вступает в силу с 01.01.2031. Оператор значимой платежной системы в соответствии с правилами платежной системы должен обеспечить в аппаратных модулях безопасности информационной инфраструктуры платежной системы СКЗИ, реализующих иностранные криптографические алгоритмы и криптографические алгоритмы, определенные национальными стандартами Российской Федерации, имеющих подтверждение соответствия требованиям, установленным ФОИВ в области обеспечения безопасности (5.5. абз.3).

Третья попытка импортозамещения платёжных HSM началась ранее запланированного 2024 года. К сожалению, часть ранее сформулированных гипотетических целевых атак стали нашей сегодняшней реальностью.

Предлагаю Вашему вниманию новое решение, которое вобрало в себя опыт построения и опыт внедрения предыдущих решений по импортозамещению платёжных HSM — SPB HSM PS.

Архитектурные особенности построения платёжных HSM

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

• инициализация платёжных карт при их производстве;
• эмиссия платёжных карт, включая генерацию секретных величин, электрическую персонализацию и печать пин-конвертов;
• токенизация карт в мобильные приложения платежных систем;
• авторизация платёжных транзакций;
• эквайринг, обработка транзакций от платёжных устройств;
• 3D-Secure;
• поддержка режима работы операционно-платёжного клирингового центра системы платёжных карт;
• управление ключами, а именно — генерация, смена, резервирование, экспорт локальных, зональных, терминальных, транспортных мастер ключей, которые используются в вышеперечисленных процессах.

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

Блок управления обеспечивает ввод-вывод и разбор формата команд, поступающих от прикладной HOST системы, взаимодействие с криптоблоком для выполнения критичных криптографических преобразований, а также предоставляет функции для удалённого управления устройством через защищённый TLS канал.

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

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

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

Криптоблок имеет более высокую степень физической и логической защиты относительно блока управления.

Работа платёжного HSM заключается в выполнении двух основных режимов:

• обработка команд, поступающих от HOST системы — режим Хост команд,
• управление устройством и его параметрами, включая управление ключами — режим Управления, аналогом которого является режим консольных команд.

Платёжный HSM именно в режиме Хост-команд выполняет основные функции, обеспечивающие поддержку необходимых криптографических операций в инфраструктуре платёжных систем, таких как:

• поддержка EMV,
• расчёт карточных величин (CVV/CVC/CVP, PVV),
• работа с PIN-блоками,
• поддержка экспорта/импорта ключей с использованием контейнеров ACS X9 TR-31 2018, PKCS#1 v1.5 и т.д.

Доступ к изделию в режиме Хост-команд реализован через специальное API, формализующее обмен данными с HOST системой по протоколам TCP/UDP. При этом HOST система никогда не получает доступ к ключам или иным чувствительным данным в чистом виде — только в виде шифрограмм, защищённых на локальных мастер ключах (LMK) или других ключах (ZMK, ZPK, TMK, TPK и т.п.).

Доступ к платёжному HSM в режиме Управления осуществляется двумя способами:

• локально, по выделенному ETH-интерфейсу, доступ к которому возможен только из локальной подсети;
• удаленно, по выделенному HOST-интерфейсу, доступ к которому возможен из других подсетей, при этом в качестве IP адреса шлюза по умолчанию используется заданный в строке «адрес шлюза (WEB консоль)».

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

Управление и настройка изделия в процессе его эксплуатации выполняется администраторами безопасности и/или администраторами управления в соответствии с их полномочиями.

Достаточно часто возникают вопросы о том, какие HSM модули можно использовать в составе банковских или платёжных систем: платёжные HSM или HSM общего назначения. Разница в логической архитектуре платёжного HSM и HSM общего назначения заключается в следующем.

В случае платёжного HSM (типа Thales PayShield или SPB HSM PS) — это реализация непосредственно в HSM поддержки именно платёжных механизмов безопасности (например, вычисление PVV, CVV, ARQS/ARPC, SM, EMV сертификатов, TR-31, DUKPT и т.д.), которые в свою очередь используют различные криптопримитивы соответствующих криптоалгоритмов (например, TDES, AES, RSA, MAC и т.д.). При этом, все промежуточные результаты криптопреобразований HSM не покидают и именно это обеспечивает максимальную степень защиты данных держателей карт. API к такому модулю де факто введён ещё фирмой Racal — это запись в сокет UDP или TCP датаграмм, называемых командами и, соответственно, аналогичное чтение и анализ ответов.

В случае HSM общего назначения (типа SafeNet Luna или ViPNet HSM) — это реализация непосредственно в HSM только криптопримитивов соответствующих криптоалгоритмов (TDES, AES, RSA, MAC). При этом, все промежуточные результаты криптопреобразований HSM как раз покидают, обрабатываются в программно-аппаратной среде системы платёжных карт (например, в платёжном приложении на сервере системы), для реализации одного механизма может потребоваться несколько десятков обращений к HSM. Таким образом, вся логика, реализующая механизмы безопасности данных держателей карт должна быть выполнена в платёжном приложении, также должна быть обеспечена безопасность данного приложения от компьютерных атак на него, а это потребует большого объёма тематических исследований и выполнения правил встраивания в программное обеспечение HOST системы. API к такому модулю — это стандартные крипто-API, такие как PKCS#11, Java, JCPROV, CSP, и KSP.

Таким образом, применение платёжных HSM в платёжной индустрии и реализация защиты данных держателей карт на уровне механизмов безопасности является предпочтительной с позиции уровня обеспечения защиты, а применение HSM общего назначения является хорошим решением для новых, ещё не специфицированных механизмов безопасности, и такие HSM могут быть за счёт стандартных крипто-API достаточно быстро интегрированы в HOST систему.

Требования PCI PTS HSM и требования к СКЗИ

Требования PCI PTS HSM предоставляют производителям аппаратных модулей HSM список всех требований безопасности, на соответствие которым производится оценка для получения сертификации от индустрии платежных карт (PCI) по PIN Transaction Security (PTS) для аппаратных модулей безопасности (HSM).

Устройства HSM могут поддерживать различные приложения и процессы обработки платежей и аутентификации держателя карты:

• обработка PIN-кода,
• 3D-Secure,
• верификация карт,
• производство и персонализация карт,
• удаленное управление данными чиповой карты,
• безопасное взаимодействие с банкоматами (ATM) и устройствами электронных платежей в пункте продажи (EFTPOS система),
• обеспечение целостности данных транзакций,
• авторизация транзакций с использованием чиповых карт,
• генерация ключей,
• ввод ключей.

Требования PCI PTS HSM не являются требованиями для стандартных устройств HSM общего назначения и не обязательны для использования вне перечисленных выше платежных приложений, т.е. определяют требования именно к платёжным HSM.

Требования, содержащиеся в PCI PTS HSM, построены по методике снижения рисков и являются минимально приемлемыми для индустрии платежных карт (PCI). Таким образом, задачей требований не является исключить возможность кражи, но снизить её вероятность и ограничить её последствия. PCI декларирует требования к безопасности HSM, как производные от существующих стандартов ISO, ANSI, и NIST и лучших практик, принятых индустрией финансовых платежей.

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

Совокупность предъявляемых требований к СКЗИ определяются классом СКЗИ и составом реализуемых данным СКЗИ криптографических функций. Все СКЗИ делятся на пять классов (от старшего к младшим: КА, КВ, КС3, КС2, КС1). Класс СКЗИ определяется путём формирования перечня подлежащих защите объектов информационных систем и совокупности возможностей, которые могут быть использованы при создании способов, подготовке и проведении атак на указанные объекты, с учётом применяемых в информационных системах информационных технологий, сред функционирования и аппаратных средств. Состав реализуемых в СКЗИ криптографических функций может включать:

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

В 2020 году были согласованы Банком России и утверждены НТС ФСБ России «Требования к СКЗИ в платёжных устройствах с терминальным ядром, серверных компонентах платёжных систем (HSM модулях), платёжных картах и иных технических средствах информационной инфраструктуры платёжной системы, используемых при осуществлении переводов денежных средств, указанных в п. 2.20 положения БР от 09.06.12 г. №382-П (719-П)» и опубликованы на сайте Банка России.

Появлению данных требований предшествовала работа по гармонизации требований PCI PTS HSM (PCI PTS POI в части терминального оборудования) и «Требований к средствам криптографической защиты информации, предназначенным для защиты информации, не содержащей сведений, составляющих государственную тайну». Для формирования требований к СКЗИ (HSM-модулям), которые могут поддерживать процессы обработки PIN-кода, 3D Secure, верификации карт, производства и персонализации карт, удаленного управления данными чиповой карты, безопасного взаимодействия с банкоматами и устройствами электронных платежей в пункте продажи, обеспечения целостности данных транзакций, авторизации транзакций с использованием чиповых карт, генерации и ввода ключей, за основу были взяты «Требования к средствам криптографической защиты информации..» для класса КВ и дополнены требованиями или уточнениями, которые необходимы для обеспечения безопасности специфических процессов платёжной индустрии, заданных в PCI PTS HSM.

Особенности миграции на новое оборудование

Очень много вопросов задают именно на эту тему, очень много опасений существует у представителей организаций платёжной индустрии, которые используют платёжные HSM в своих системах.

Хотелось бы эти опасения развеять. Процедура миграции будет аналогична той, которую уже проходили, когда мигрировали, например, с Thales РayShield 9000 на PayShield 10K и будет включать:

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

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

Миграцию конфигурации безопасности и локальных мастер ключей наиболее оптимально проводить с одновременной сменой метода локальных мастер ключей (вариантного метода на KeyBlock) или просто с переходом со старых локальных ключей на новые (смена в соответствии со сроком действия). Реализованные в платёжном HSM методы миграции LMК обеспечивают поддержку нескольких массивов, в том числе и различных типов, что позволяет, не прекращая обработки транзакций, обеспечить миграцию локальных мастер ключей даже на высоконагруженных участках обработки транзакций.

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

SPB HSM PS

Платежные технологии. Выпуск 14.pdf