08.04.2024 23:29Конфигурация платёжных аппаратных модулей безопасности
SPB HSM PS относится к классу платежных HSM (Hardware Security Module) и предназначен для применения в банковских и платежных системах. Он обеспечивает защиту данных держателей карт и обеспечивает безопасность транзакций в различных процессах, таких как инициализация платежных карт, эмиссия платежных карт, токенизация карт в мобильные приложения, авторизация платежных транзакций, обработка транзакций от платежных устройств, 3D-Secure и другие https://systempb.ru/company/our-articles/rossiyskie-platyezhnye-hsm-moduli/.
Платежный HSM представляет собой аппаратно-программный комплекс, который обеспечивает высокий уровень физической и логической защиты. Он состоит из двух блоков — блока управления и криптоблока, которые взаимодействуют через защищенный интерфейс.
Блок управления осуществляет ввод-вывод команд, взаимодействие с криптоблоком, выполнение критических криптографических операций и удаленное управление устройством через защищенный TLS канал. К блоку управления подключаются внешние интерфейсы с HOST системой, а также интерфейсы для локального и удаленного управления.
Криптоблок отвечает за генерацию, защищенное хранение и экспорт локальных мастер ключей, а также шифрование и расшифрование персональных данных владельцев карт. Он также взаимодействует с ридером смарт-карт для экспорта/импорта локальных мастер ключей на смарт-карты.
Платежный HSM работает в двух основных режимах — режиме Хост команд, который обрабатывает команды от HOST системы, и режиме Управления, который отвечает за управление устройством и параметрами, включая управление ключами.
В режиме Хост команд платежный HSM поддерживает различные функции, такие как поддержка EMV, расчет карточных величин, работа с PIN-блоками и экспорт/импорт ключей с использованием контейнеров ACS X9 TR-31 2018, PKCS#1 v1.5 и других.
В целом, SPB HSM PS предоставляет надежную защиту данных и обеспечивает безопасность платежных систем, выполняя широкий спектр функций.
Для обеспечения доступа к изделию в режиме Хост-команд, используется специальное API, которое позволяет обмениваться данными с HOST системой через протоколы TCP/UDP. При этом HOST система не получает прямого доступа к ключам или другим чувствительным данным — только к шифрограммам, которые защищены локальными мастер ключами (LMK), или другими ключами (ZMK, ZPK, TMK, TPK и т.д.).
Доступ к платежному HSM в режиме Управления осуществляется двумя способами:
- Локальный доступ: осуществляется через выделенный ETH-интерфейс и доступен только из локальной подсети.
- Удаленный доступ: осуществляется через выделенный HOST-интерфейс и доступен из других подсетей. При этом, в качестве IP адреса шлюза по умолчанию используется адрес, указанный в строке «адрес шлюза (WEB консоль)».
Для создания безопасного удаленного подключения к платежному HSM, аутентификации администраторов безопасности и администраторов управления используется специализированный браузер и их идентификаторы (USB токены), которые записываются при инициализации платежного HSM.
Управление и настройка изделия в процессе его эксплуатации осуществляется администраторами безопасности и/или администраторами управления согласно их полномочиям.
Возникает вопрос о том, какие HSM модули можно использовать в банковских или платежных системах: платежные HSM или HSM общего назначения. Основное отличие в логической архитектуре заключается в следующем:
1. Платежные HSM (например, Thales PayShield или SPB HSM ₽S): позволяют реализовать платежные механизмы безопасности (например, вычисление PVV, CVV, ARQS/ARPC, SM, EMV сертификатов, TR-31, DUKPT и т.д.) и используют соответствующие криптопримитивы (например, TDES, AES, RSA, MAC). Все промежуточные результаты криптопреобразований остаются в HSM, что обеспечивает высокую защиту данных держателей карт. Коммуникация с таким модулем осуществляется через запись и анализ сокетов UDP или TCP датаграмм.
2. HSM общего назначения (например, SafeNet Luna или ViPNet HSM): реализуют только криптопримитивы соответствующих криптоалгоритмов (например, TDES, AES, RSA, MAC). Промежуточные результаты криптопреобразований покидают HSM и обрабатываются в программно-аппаратной среде системы платежных карт (например, на сервере системы). Вся логика безопасности данных должна быть выполнена в платежном приложении, которое также должно быть защищено от компьютерных атак. API к такому модулю использует стандартные крипто-API, такие как PKCS#11, Java, JCPROV, CSP и KSP.
Таким образом, для обеспечения защиты данных держателей карт предпочтительно использование платежных HSM в платежной индустрии, а HSM общего назначения хорошо подходят для новых механизмов безопасности, требующих дополнительных исследований и интеграции в HOST систему через стандартные крипто-API.
Условия работы PCI PTS HSM
Требования для PCI PTS HSM представляют список всех требований безопасности, которым должны соответствовать аппаратные модули HSM, чтобы получить сертификацию от индустрии платежных карт (PCI) по безопасности транзакций PIN (PTS).
Устройства HSM могут использоваться для обработки PIN-кодов, 3D-Secure, верификации карт, производства и персонализации карт, удаленного управления данными чипа карты, безопасного взаимодействия с банкоматами и устройствами электронных платежей в магазинах, обеспечения целостности данных транзакций, авторизации транзакций с использованием чиповых карт, генерации и ввода ключей.
Требования PTS HSM не применимы к стандартным устройствам HSM общего назначения и обязательны только для использования в платежных приложениях.
Требования PCI PTS HSM разработаны с целью снижения рисков и являются минимально необходимыми для индустрии платежных карт (PCI). Хотя они не могут исключить возможность кражи, они снижают ее вероятность и ограничивают ее последствия. Требования к безопасности HSM, объявленные PCI, производные от существующих стандартов ISO, ANSI, NIST и лучших практик в финансовой индустрии.
Требования к СКЗИ (средствам криптографической защиты информации) распространяются на различные типы СКЗИ, включая программные, аппаратные и программно-аппаратные реализации в различных областях применения. Они разработаны с целью нейтрализации потенциальных атак нарушителей на всех этапах жизненного цикла СКЗИ.
Требования к СКЗИ определяются их классом и используемыми криптографическими функциями. Существуют пять классов, определяемых по списку защищаемых объектов информационных систем и возможностей, используемых для атак на эти объекты. Реализуемые в СКЗИ криптографические функции могут включать генерацию псевдослучайных последовательностей, шифрование, имитозащиту, электронную подпись и создание ключевых документов.