Jony Lexx
RIPPER
- Messages
- 106
- Reaction score
- 8
- Points
- 18
ПИН-код наиболее надёжный способ защиты.
Наиболее надежным способом аутентификации ЛСО в соответствии с фактором 2 является проверка ПИН-кода. Это связано с тем, что значение ПИН-кода является самой труднодоступной для преступников секретной информацией среди всех реквизитов карты с магнитной полосой, поскольку он не хранится на карте. Потому применение ПИН-кода – наиболее надежное средство обеспечения безопасности операций, выполняемых с использованием карт с магнитной полосой. В общем случае ПИН-код представляет собой последовательность десятичных цифр, вводимых ЛСО во время совершения операции по карте.
Длина ПИН-кода варьируется от 4 до 12 цифр (на практике в большинстве случаев – 4 цифры). ПИН-код вводится с помощью специального криптографического модуля, входящего в состав терминального устройства (автоматизированного как банковского, так и небанковского терминала самообслуживания, POSтерминала и т. п.) – ПИН-пада, или PIN Entry Device (PED), после чего информация о его значении передается на хост эмитента, где она проверяется, обеспечивая таким образом верификацию ЛСО (подтверждая владение ЛСО секретной информацией, которая может быть известна только законному держателю карты, по которой производится транзакция). При этом маршрут ПИН-кода до хоста эмитента пролегает через аппаратно-программные комплексы банка-эквайера и, возможно, целого ряда промежуточных процессинговых центров (ПЦ).
О PED, HSM, ПИН-блоках и требованиях к ним
Главное требование к процессу доставки ПИН-кода – ПИН-код нигде не должен появляться в открытом, незашифрованном виде за исключением специальных криптографических устройств. ПИН-код шифруется на разных этапах его передачи выполняется с использованием различных ключей и производится в специальных криптографических модулях, в которых ПИН-код на короткое время появляется в открытом виде. Однако в этом случае значение ПИН-кода недоступно для наблюдения извне.
До момента полной миграции на микропроцессорные карты пройдет ещё не менее десятилетия. Сегодня во всем мире только порядка 15% карт, 20% POS-терминалов и 12,5% банкоматов являются EMV-совместимыми. А это значит, что те угрозы, о которых рассказывается в настоящей статье, являются по-прежнему актуальными, и к ним нужно относится более чем серьезно. С точки зрения практики это сводится, конечно же, к соблюдению требований к безопасности генерации, хранения и передачи ПИН-кодов
Очевидно, что к уровню защищенности криптографических модулей предъявляются специальные требования как с точки зрения их физической безопасности (экранирование электромагнитного излучения, уничтожение хранимых в модулях секретных данных при обнаружении попытки проникновения внутрь модуля и т.п., подробнее см. ISO 9564-1), так и с точки зрения их логической безопасности (ограничение доступа к модулю, аутентификация офицеров безопасности, выполнение требований к датчикам случайных чисел, к поддерживаемым алгоритмам шифрования и документированию обращений к криптографическому модулю и т. п.).
Теперь стоит сделать короткое отступление и сообщить о том, что ПИН-код "путешествует" к хосту эмитента в специальной "лодке", называемой ПИН-блоком, и все криптографические операции, связанные с доставкой ПИН-кода эмитенту, производятся именно над ПИН-блоком. ПИН-блок может иметь один из приведенных ниже форматов, поддерживаемых всеми криптографическими модулями. Прежде чем приступить к описанию возможных форматов ПИН-блока, введем следующие обозначения:
P – двоичное представление одной из десятичных цифр ПИН-кода в виде 4 битов;
L – двоичное представление числа цифр ПИН-кода в виде 4 битов; может принимать значение от 4 до 12;
'x'h – двоичное представление цифры шестнадцатеричной системы исчисления в виде 4 битов;
Z – двоичное представление '0'h в виде 4 битов (т.е. последовательность из 4 двоичных нулей);
F – двоичное представление 'F'h в виде 4 битов (т.е. последовательность из 4 двоичных единиц);
R – двоичное представление из 4 битов шестнадцатеричной цифры, являющейся цифрой некоторого случайного числа;
f – двоичное представление из 4 битов либо цифры ПИН-кода, либо цифры 'F'h;
A – двоичное представление из 4 битов цифры номера карты;
S – двоичное представление из 4 битов одной из шестнадцатеричных цифр от 'A'h до 'F'h.
Формат ISO-0 (или, что то же самое, формат ANSI X9.8, VISA-1, ECI-1). Пусть P1=Z|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|A|A|A|A|A|A|A|A|A|A|A|A, где последние 12 цифр Р2 представляют собой последние цифры номера карты, из которого исключена последняя цифра (Luhn Check Parity Digit).
Тогда ПИН-блок формата ISO-0 есть PBL-0=P1 P2, где – операция побитового сложения по модулю 2 двух двоичных последовательностей одинаковой длины (см. табл. 1).
Формат ISO-1.Пусть P1='1'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|R|R|R|R|R|R|R|R|R|R|R|R. Тогда ПИН-блок формата ISO-1 есть PBL-1=P1⊕P2 (см. табл. 2).
Формат ISO-2. Пусть P1='2'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|F|F|F|F|F|F|F|F|F|F|F|F. Тогда ПИН-блок формата ISO-2 есть PBL-2=P1⊕P2 (см. табл. 3).
Формат ISO-3. Пусть P1='3'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|S|S|S|S|S|S|S|S|S|S|S|S. Тогда ПИН-блок формата ISO-3 есть PBL-3=P1⊕P2 (см. табл. 4).
Компрометация ПИН-кода
Все криптографические модули, используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули (tamper-responsive), и взломообнаруживающие, или ВО-модули (tamper-evident). ВС-модуль при обнаружении несанкционированного физического проникновения внутрь модуля (сверление, лазерное воздействие, травление кислотой, нарушение целостности кожуха модуля и т.п.) мгновенно уничтожает всю секретную информацию (ПИН-блоки, ключи и т.п.), хранящуюся в момент обнаружения взлома в криптографическом модуле.
ВО-модуль при обнаружении попытки проникновения в криптографический модуль подает четкий, очевидный сигнал, извещающий о попытке взлома и предназначенный для держателя карты (видео- и/или аудиосигнал). Тем самым ВОмодуль не может защитить ПИН-код или ключ, находящиеся в памяти модуля в момент атаки, но при этом препятствует компрометации новых ПИН-кодов и ключей.
Очевидно, что ВО-модули обеспечивают более низкий уровень защиты в сравнении с ВС-модулями, являясь при этом более дешевыми криптографическими модулями. Как следствие – ВО-модули могут использоваться только для шифрования ПИН-блоков и ключей (в схемах управления ключами).
Минимальное требование к PED состоит в том, что PED должен быть ВО-модулем. Это объясняется тем, что единственная задача PED заключается в шифровании ПИН-блоков. Поэтому проникновение в PED может привести только к компрометации обрабатываемого в нем на момент атаки ПИН-блока. При этом криптографические модули, используемые для решения более широкого класса задач (например, верификации/генерации ПИНР1 Z 4 Р Р Р Р F F F F F F F F F F Р2 Z Z Z Z A A A A A A A A A A A A PBL-0 Z 4 P P X X X X X X X X X X X X
Все криптографические модули , используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули(tamper-responsive),и взлообнаруживающие,или ВО-модули(tamper-evident)
Табл. 1. Формат ПИН-блока ISO-0 при 4-цифровом ПИН-коде PBL-1 1 4 P P P P R R R R R R R R R R
Табл. 2. Формат ПИН-блока ISO-1 при 4-цифровом ПИН-коде PBL-2 2 4 P P P P F F F F F F F F F F
Табл. 3. Формат ПИН-блока ISO-2 при 4-цифровом ПИН-коде Р1 3 4 Р Р Р Р G G G G G G G G G G Р2 Z Z Z Z A A A A A A A A A A A A PBL-3 3 4 P P X X X X X X X X X X X X
Табл. 4. Формат ПИН-блока ISO-3 при 4-цифровом ПИН-коде Все криптографические модули, используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули (tamper-responsive), и взломообнаруживающие, или ВО-модули (tamper-evident) кодов), должны относиться к ВС-модулям.
Проникновение в модуль, хранящий ключ генерации ПИН-кодов, влечет за собой компрометацию всех ПИН-кодов, когдалибо сгенерированных с помощью этого ключа. Поэтому в качестве криптографических модулей хоста эмитента (Host Security Module, или HSM) используются исключительно ВС-модули.
Следует отметить, что в терминалах, поддерживающих обслуживание микропроцессорных карт, PED и картридер зачастую интегрируются в одном ВО-модуле. Это сделано для того, чтобы при передаче ПИН-кода от PED непосредственно карте можно было бы не шифровать ПИН-блок, если этого не требует метод верификации держателя карты (т.е. если используется метод Offline plaintext PIN). В случае, когда PED и картридер – отдельные неинтегрированные устройства, и используется метод верификации Offline plaintext PIN, при передаче ПИН-блока карте обязательно его шифрование в PED и расшифрование картридером перед передачей ПИН-блока карте.
Об атаках извлекающих ПИН-код
Не успели стихнуть дебаты вокруг без преувеличения сенсационных результатов данного исследования, как в 2006г. была обнародована новая работа, подтвердившая сформулированный выше тезис о "слабых звеньях" интерфейса Standard Financial API и описывающая целый ряд неизвестных ранее возможных атак, направленных на извлечение ПИН-кода. Авторы этого исследования обнаружили новые возможности использования уже известных "дыр" в защите интерфейса Standard Financial API. Характерно, что, несмотря на соблазн рассказать на страницах настоящей статьи о новых типах атак, описанных в работе, мы решили отказаться от этой затеи, не желая пропагандировать мошеннические атаки в открытой печати.
Заметим лишь, что все атаки, приведенные в данной работе, основаны на следующих предположениях:
1) у мошенника имеется возможность логического доступа к HSM процессингового центра для обращения к HSM с командами Standard Financial API;
2) мошенник имеет возможность извлечь зашифрованное значение ПИН-блока и соответствующие ему значения ПИН-кода и номера карты. Чтобы получить триплет "зашифрованный ПИН-блок, ПИН-код, номер карты", мошенник изготавливает карту с известным ему номером и ПИНкодом, отправляется к банкомату, подключенному к процессинговому центру, делает попытку совершения операции и, наконец, потом находит "следы" этой попытки в приложении ПЦ (предполагается, что "следы" содержат все интересующие злоумышленника данные).
Для осуществления некоторых типов атак (например, изменение значения ПИН-кода) преступнику иногда требуется доступ к БД карт банка-эмитента. Следует отметить, что в целом предположения "1" и "2" являются трудно реализуемыми на практике. Обычно банки/ПЦ уделяют самое серьезное внимание ограничению физического и логического доступа к HSM. Так, например, широко распространена практика, когда доступ к HSM ПЦ возможен только из прикладного программного обеспечения ПЦ, либо он предоставляется офицерам безопасности исключительно для загрузки новых ключей. При этом офицеры безопасности используют для загрузки ключей специальное терминальное оборудование, доступ к которому в соответствии с PCI PIN Requirements находится под двойным контролем. Если HSM подключен к локальной сети банка, то сетевой доступ к HSM также ограничен настройками межсетевого экрана только возможностью работы с хостом ПЦ.
Что касается извлечения триплета "зашифрованный ПИН-блок, ПИН-код, номер карты" из ПЦ, то и здесь все обстоит непросто, поскольку в соответствии с PCI PIN Requirements ПИН-блоки даже в зашифрованном виде не должны храниться в ПЦ. Злоумышленнику необходимо не только сгенерировать зашифрованный ПИН-блок с известным значением ПИНкода, например, обратившись к банкомату, подключенному к ПЦ, для выполнения какой-либо операции, но и успеть обнаружить значение ПИН-блока средствами приложения ПЦ за короткое время обработки транзакции в ПЦ.
Однако, несмотря на трудность выполнения приведенных выше условий, данные задачи все же реализуемы. И здесь главная проблема состоит в том, что банкэмитент не может повлиять на защищенность ПИН-кода его клиента, поскольку большинство атак, описанных в работе[2], может успешно выполняться на промежуточных хостах, к которым эмитент не имеет никакого отношения.
Следует отметить, что в основе всех приведенных атак лежат следующие известные "дыры" в Standard Financial API:
– возможность конверсии ПИН-блока из одного формата в другой;
– возможность изменения ПИН-кода держателя карты без одновременной проверки криптографическим модулем прежнего значения ПИН-кода с его привязкой к номеру карты (такая проверка выполняется, но приложением ПЦ).
Отметим, что возможность конверсии ПИН-блока из безопасных форматов ISO-0 и ISO-3 в небезопасные форматы ISO-1 и тем более ISO-2 лежит в основе большинства атак на ПИНкод, описанных в работе [2]. На практике часто нет необходимости в использовании форматов ISO-1 и ISO-2 на хосте банка/ПЦ (формат ISO-2 применяется для передачи зашифрованного ПИН-блока от картридера карте). Поэтому с точки зрения безопасности очень разумно на уровне приложения ПЦ запретить (просто не поддерживать) выполнение конверсии ПИН-блоков в эти форматы. Что касается прямого доступа злоумышленника к HSM, то его необходимо исключить, ограничив доступ к HSM офицерам безопасности только с целью загрузки ключей при соблюдении принципа двойного контроля.
Борьбы с компрометацией ПИН-кода
Таким образом, с точки зрения криптоанализа передача ПИН-кода в зашифрованном и открытом виде в этом случае… равноценны. С точки зрения практики, разумеется, требуется сделать невозможным для мошенника получение в его распоряжение случайного числа карты и/или случайной последовательности терминала. Эффективным способом борьбы с компрометацией ПИН-кода является формирование случайной последовательности терминала криптографическим модулем терминала. Однако "родные" криптографические модули, используемые в терминалах известных мировых производителей, вообще не реализуют функцию шифрования ПИН-блока в соответствии со стандартом EMV. Обычно алгоритм шифрования ПИН-блока реализуется в модулях SAM (Security Application Module), устанавливаемых в POS-терминалах.
В этом случае, как правило, терминал сам подготавливает случайную последовательность и передает ее в SAM для шифрования ПИН-блока с помощью алгоритма RSA. Как можно сделать вывод из сказанного выше, очевидно, что такой способ шифрования ПИН-блока уязвим. Поскольку случайное число карты и случайная последовательность терминала открыты для потенциального мошенника, то он, зная значение зашифрованного ПИН-блока и открытый ключ карты, легко восстанавливает значение ПИН-кода. Многие модули SAM содержат датчики случайных чисел. Поэтому при соответствующем программировании модуля SAM можно добиться того, чтобы случайная последовательность терминала генерировалась в этом модуле.
Итак, генерация случайной последовательности терминала в криптографическом модуле – единственно правильный подход к шифрованию ПИН-блока. Процедура генерации случайного числа модулем SAM не занимает много времени. Например, если датчик случайных чисел модуля SAM генерирует случайное число размером 8 байтов за 10 миллисекунд (в действительности – в разы быстрее), то для генерации последовательности терминала может потребоваться генерация порядка 15 таких случайных чисел, на что уйдет 150 миллисекунд. Этот показатель не окажет заметного влияния на время выполнения операции в терминале. Ввод значения ПИН-кода держателем карты займет значительно больше времени.
Конфиденциальность ПИН-кода важна в условиях гибридной сети приема карт, в рамках которой обслуживаются как карты с магнитной полосой, так и микропроцессорные карты. Как уже отмечалось, в случае исключительно "микропроцессорной" среды приема карт (т. е. когда прием карт с магнитной полосой исключен) знание значения ПИН-кода мошеннику ничего не дает. Для совершения успешной мошеннической операции помимо знания значения ПИН-кода необходимо иметь саму микропроцессорную карту. Поэтому в условиях приема только микропроцессорных карт держатель карты, уверенный в том, что он карту не потеряет и ее у него не украдут, может особенно и не скрывать вводимое им на терминале значение ПИН-кода.
Международные платежные системы активно рекомендуют эмитентам использовать офлайновую проверку ПИН-кода в качестве основного метода верификации держателя карты. В частности, и MasterCard, и Visa постепенно, по регионам, начинают вводить перенос ответственности, называемый Chip&PIN Liability Shift. Чтобы сформулировать сущность Chip&PIN Liability Shift, введем следующие определения. Будем называть микропроцессорную карту Chip&PIN-картой, если метод проверки ПИН-кода Offline PIN (независимо от способа передачи ПИН-кода – в защищенном или незащищенном виде) является самым приоритетным в списке CVM List в условиях выполнения данной операции. По-прежнему будем говорить, что терминал поддерживает метод Offline PIN, если он поддерживает защищенную и открытую передачу ПИН-кода на карту. Тогда перенос ответственности Chip&PIN Liability Shift формулируется следующим образом: если Chip&PIN-карта используется в терминале, не поддерживающем Offline PIN, то вся ответственность за потерянные/похищенные (Lost/Stolen) карты, а также неполученные карты (NRI) переносится на банк-эквайер.
В результате рекомендуемая платежными системами приоритетность правил верификации держателя карты в CVM List при выполнении операции с использованием DDA/CDA-карты в POS-терминале имеет следующий вид:
1)Enciphered Offline PIN;
2)Plaintext Offline PIN;
3)Online PIN;
4)Signature;
5)No CVM.
Такая приоритетность правил верификации ЛСО рекомендуется для всех карточных продуктов Visa. Для кредитных продуктов MasterCard платежная система рекомендует поменять местами правила 3 и 4, а для карт Maestro требует исключить из списка правило 5.
Одной из серьезных "дыр" в модели обеспечения безопасности операций, выполняемых с использованием микропроцессорных карт, является практическая возможность заведения мошенником ложного открытого ключа системы в POS-терминал. Изготовив под ложным ключом системы сертификаты ключа эмитента, далее можно выпустить поддельные карты, которые будут успешно работать в терминалах с загруженным ложным ключом.
Естественным способом борьбы с такого рода мошенничеством является создание подписи вводимых в терминал ключей системы на ключе обслуживающего банка. Такая подпись проверяется криптографическим модулем терминала при выполнении каждой транзакции, тем самым обеспечивая целостность ключевой информации на терминале. В этом случае, не обладая ключом обслуживающего банка, невозможно успешно завести/использовать ложный открытый ключ системы. К сожалению, для того чтобы обойти упомянутую защиту открытых ключей системы, преступник может выбрать иной путь, нежели компрометация секретного ключа обслуживающего банка. Для совершения мошеннической операции ему достаточно загрузить на терминал фальшивый исполняемый модуль, который в отличие от приложения обслуживающего банка не станет проверять подпись используемого ключа. В этом случае описанная выше защита не работает.
Чтобы лишить мошенника возможности замены приложения терминала, требуется подключить ресурсы операционной системы (загрузчика ОС) и криптографического процессора терминала. Все команды загрузки/удаления программных модулей должны подписываться обслуживающим банком (или его авторизованным представителем), а подпись должна проверяться криптографическим модулем терминала (например, модулем SAM или специализированной микропроцессорной картой). В то же время отметим, что проблема обеспечения целостности приложения терминала не является надуманной.
По мнению экспертов в области безопасности карточных операций, по мере повышения защищенности карт внимание мошенников все чаще будет обращаться на среду их обслуживания. Терминал является близким окружением карты и потому, несомненно, станет мишенью для атак. Поскольку терминал сегодня фактически представляет собой персональный компьютер, то для атак будут использоваться те же методы, что и в случае атак на PC. В частности, применение специальных вредоносных программ (аналог программ spyware, Trojan horse, keyboard/ screen logger или иных вирусов) позволит мошеннику получать интересующую его информацию о карте (например, содержимое второй дорожки магнитной полосы карты, значение случайной последовательности терминала и случайного числа карты, используемых для шифрования ПИН-блока, значение зашифрованного ПИН-блока и т. п.).
Важна также и проблема подмены настоящего POS-терминала банка терминалом, установленным мошенниками. В отличие от стоимости банкомата стоимость POS-терминала невелика – 400–600 долл. США. Поэтому подобная подмена является весьма правдоподобной при сговоре мошенника с кассиром торгового предприятия (как уже упоминалось, известны случаи установки даже "фальшивых" банкоматов!). Возможны также ситуации, когда недобросовестное торговое предприятие будет использовать POS-терминал только с целью сбора информации о картах.
В случае применения "фальшивого" терминала может компрометироваться не только содержимое магнитной дорожки карты, но и значение ПИН-кода держателя карты. С учетом использования на практике гибридных карт, имеющих как чип, так и магнитную полосу, получив информацию о магнитной дорожке карты и значение ее ПИН-кода, мошенник может изготовить "белые" карты для их последующего использования в банкомате для снятия наличных.
Для решения проблемы возможной установки преступниками "фальшивого" POS-терминала при обработке карточных операций в онлайновом режиме необходимо повсеместно внедрять коды MAC для сообщений, циркулирующих между терминалом и хостом обслуживающего банка. Это обеспечит целостность информационного обмена и аутентификацию POS-терминала. Между тем использование кодов MAC позволяет эффективно решить проблему только для онлайновых операций. Информация об офлайновых транзакциях, выполненных на терминале, также может подписываться для передачи в обслуживающий банк. Однако мошеннический терминал может и не передавать эту информацию в банк достаточно долго или вообще никогда. К сожалению, в случае, когда терминал действует в офлайновом режиме, кроме стандартных организационных мер для борьбы с подобного рода мошенничествами участникам рынка предложить пока нечего.
Достаточно эффективным способом борьбы с подменой POS-терминалов могло бы стать введение в рамках стандарта EMV процедуры взаимной аутентификации карты и терминала. Заведение на терминал пары секретного и открытого асимметричных ключей обслуживающего банка и сертификата этого ключа на ключе системы, а также поддержка картой процедуры аутентификации терминала и хранение на карте хэш-функций открытых ключей системы позволит исключить подмену терминала. Хранение на карте хэшфункций открытых ключей системы необходимо для того, чтобы избежать ситуации, когда мошенник сам придумывает ложный ключ системы и генерирует пару ключей для их заведения в терминал обслуживающего банка с сертификатом, вычисленным на ложном ключе системы.
Разумеется, хранение хэш-функций ключей системы (очевидно, что придется хранить информацию о ключах, сгенерированных "впрок", чтобы избежать ситуации, когда во время жизненного цикла карты на терминалах появятся ключи системы, неизвестные карте) накладывает ограничения на размер памяти EEPROM карты. Терминал должен хранить до 6 ключей одной системы. Поэтому с учетом ключей, заводимых в терминал "впрок", и длины значения хэш-функции SHA-1, равной 20 байтам, потребуется зарезервировать около 200 байтов памяти карты EEPROM для одной платежной системы.
Заключение
Не следует считать, что современная ситуация с компрометацией ПИН-кодов является катастрофической или хотя бы достигла просто угрожающего для индустрии платежных карт уровня. Возможно, автор настоящей статьи слишком сгустил краски вокруг этой проблемы. Кроме того, повсеместный переход на технологию микропроцессорных карт, свидетелями начала которого мы все являемся, заметно снизит актуальность проблемы. В случае повсеместного внедрения микропроцессорных карт компрометация ПИН-кода уже ничего не даст злоумышленнику, поскольку для выполнения мошеннической операции ему потребуется и сама карта законного держателя, которой в большинстве случаев злоумышленник не располагает.
Однако до момента полной миграции на микропроцессорные карты пройдет еще не менее десятилетия. Сегодня во всем мире только порядка 15% карт, 20% POS-терминалов и 12,5% банкоматов являются EMV-совместимыми. А это значит, что те угрозы, о которых было рассказано в настоящей статье, являются по-прежнему актуальными, и к ним нужно относиться более чем серьезно.
С точки зрения практики это сводится в первую очередь, конечно же, к соблюдению требований к безопасности генерации, хранения и передачи значений ПИН-кодов, опубликованных в документе PCI PIN Security Requirements. В соответствии с этими требованиями необходимо уделять самое пристальное внимание ограничению прямого доступа (не из приложения ПЦ) к HSM. Доступ к HSM должен выполняться под двойным контролем и желательно только с целью загрузки новых ключей (автор статьи, имеющий опыт работы в крупнейшем в России ПЦ, может утверждать, что на практике такое ограничение прямого доступа к HSM вполне возможно). Все остальные функции HSM (генерация/верификация ПИН-кода, PIN Offset Calculation, PVV Calculation, PIN translation и т. п.) должны реализовываться только по запросам из приложения ПЦ.
Отметим также, что в приложении ПЦ необходимо предусмотреть запрет конверсии ПИН-блоков из безопасных форматов в форматы ISO-1 и ISO-2. Это позволит избежать всех атак.
копирайт - копипаст - статья собрана с просторов интернета.
Наиболее надежным способом аутентификации ЛСО в соответствии с фактором 2 является проверка ПИН-кода. Это связано с тем, что значение ПИН-кода является самой труднодоступной для преступников секретной информацией среди всех реквизитов карты с магнитной полосой, поскольку он не хранится на карте. Потому применение ПИН-кода – наиболее надежное средство обеспечения безопасности операций, выполняемых с использованием карт с магнитной полосой. В общем случае ПИН-код представляет собой последовательность десятичных цифр, вводимых ЛСО во время совершения операции по карте.
Длина ПИН-кода варьируется от 4 до 12 цифр (на практике в большинстве случаев – 4 цифры). ПИН-код вводится с помощью специального криптографического модуля, входящего в состав терминального устройства (автоматизированного как банковского, так и небанковского терминала самообслуживания, POSтерминала и т. п.) – ПИН-пада, или PIN Entry Device (PED), после чего информация о его значении передается на хост эмитента, где она проверяется, обеспечивая таким образом верификацию ЛСО (подтверждая владение ЛСО секретной информацией, которая может быть известна только законному держателю карты, по которой производится транзакция). При этом маршрут ПИН-кода до хоста эмитента пролегает через аппаратно-программные комплексы банка-эквайера и, возможно, целого ряда промежуточных процессинговых центров (ПЦ).
О PED, HSM, ПИН-блоках и требованиях к ним
Главное требование к процессу доставки ПИН-кода – ПИН-код нигде не должен появляться в открытом, незашифрованном виде за исключением специальных криптографических устройств. ПИН-код шифруется на разных этапах его передачи выполняется с использованием различных ключей и производится в специальных криптографических модулях, в которых ПИН-код на короткое время появляется в открытом виде. Однако в этом случае значение ПИН-кода недоступно для наблюдения извне.
До момента полной миграции на микропроцессорные карты пройдет ещё не менее десятилетия. Сегодня во всем мире только порядка 15% карт, 20% POS-терминалов и 12,5% банкоматов являются EMV-совместимыми. А это значит, что те угрозы, о которых рассказывается в настоящей статье, являются по-прежнему актуальными, и к ним нужно относится более чем серьезно. С точки зрения практики это сводится, конечно же, к соблюдению требований к безопасности генерации, хранения и передачи ПИН-кодов
Очевидно, что к уровню защищенности криптографических модулей предъявляются специальные требования как с точки зрения их физической безопасности (экранирование электромагнитного излучения, уничтожение хранимых в модулях секретных данных при обнаружении попытки проникновения внутрь модуля и т.п., подробнее см. ISO 9564-1), так и с точки зрения их логической безопасности (ограничение доступа к модулю, аутентификация офицеров безопасности, выполнение требований к датчикам случайных чисел, к поддерживаемым алгоритмам шифрования и документированию обращений к криптографическому модулю и т. п.).
Теперь стоит сделать короткое отступление и сообщить о том, что ПИН-код "путешествует" к хосту эмитента в специальной "лодке", называемой ПИН-блоком, и все криптографические операции, связанные с доставкой ПИН-кода эмитенту, производятся именно над ПИН-блоком. ПИН-блок может иметь один из приведенных ниже форматов, поддерживаемых всеми криптографическими модулями. Прежде чем приступить к описанию возможных форматов ПИН-блока, введем следующие обозначения:
P – двоичное представление одной из десятичных цифр ПИН-кода в виде 4 битов;
L – двоичное представление числа цифр ПИН-кода в виде 4 битов; может принимать значение от 4 до 12;
'x'h – двоичное представление цифры шестнадцатеричной системы исчисления в виде 4 битов;
Z – двоичное представление '0'h в виде 4 битов (т.е. последовательность из 4 двоичных нулей);
F – двоичное представление 'F'h в виде 4 битов (т.е. последовательность из 4 двоичных единиц);
R – двоичное представление из 4 битов шестнадцатеричной цифры, являющейся цифрой некоторого случайного числа;
f – двоичное представление из 4 битов либо цифры ПИН-кода, либо цифры 'F'h;
A – двоичное представление из 4 битов цифры номера карты;
S – двоичное представление из 4 битов одной из шестнадцатеричных цифр от 'A'h до 'F'h.
Формат ISO-0 (или, что то же самое, формат ANSI X9.8, VISA-1, ECI-1). Пусть P1=Z|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|A|A|A|A|A|A|A|A|A|A|A|A, где последние 12 цифр Р2 представляют собой последние цифры номера карты, из которого исключена последняя цифра (Luhn Check Parity Digit).
Тогда ПИН-блок формата ISO-0 есть PBL-0=P1 P2, где – операция побитового сложения по модулю 2 двух двоичных последовательностей одинаковой длины (см. табл. 1).
Формат ISO-1.Пусть P1='1'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|R|R|R|R|R|R|R|R|R|R|R|R. Тогда ПИН-блок формата ISO-1 есть PBL-1=P1⊕P2 (см. табл. 2).
Формат ISO-2. Пусть P1='2'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|F|F|F|F|F|F|F|F|F|F|F|F. Тогда ПИН-блок формата ISO-2 есть PBL-2=P1⊕P2 (см. табл. 3).
Формат ISO-3. Пусть P1='3'h|L|P|P|P|P|f|f|f|f|f|f|f|f|F|F, P2=Z|Z|Z|Z|S|S|S|S|S|S|S|S|S|S|S|S. Тогда ПИН-блок формата ISO-3 есть PBL-3=P1⊕P2 (см. табл. 4).
Компрометация ПИН-кода
Все криптографические модули, используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули (tamper-responsive), и взломообнаруживающие, или ВО-модули (tamper-evident). ВС-модуль при обнаружении несанкционированного физического проникновения внутрь модуля (сверление, лазерное воздействие, травление кислотой, нарушение целостности кожуха модуля и т.п.) мгновенно уничтожает всю секретную информацию (ПИН-блоки, ключи и т.п.), хранящуюся в момент обнаружения взлома в криптографическом модуле.
ВО-модуль при обнаружении попытки проникновения в криптографический модуль подает четкий, очевидный сигнал, извещающий о попытке взлома и предназначенный для держателя карты (видео- и/или аудиосигнал). Тем самым ВОмодуль не может защитить ПИН-код или ключ, находящиеся в памяти модуля в момент атаки, но при этом препятствует компрометации новых ПИН-кодов и ключей.
Очевидно, что ВО-модули обеспечивают более низкий уровень защиты в сравнении с ВС-модулями, являясь при этом более дешевыми криптографическими модулями. Как следствие – ВО-модули могут использоваться только для шифрования ПИН-блоков и ключей (в схемах управления ключами).
Минимальное требование к PED состоит в том, что PED должен быть ВО-модулем. Это объясняется тем, что единственная задача PED заключается в шифровании ПИН-блоков. Поэтому проникновение в PED может привести только к компрометации обрабатываемого в нем на момент атаки ПИН-блока. При этом криптографические модули, используемые для решения более широкого класса задач (например, верификации/генерации ПИНР1 Z 4 Р Р Р Р F F F F F F F F F F Р2 Z Z Z Z A A A A A A A A A A A A PBL-0 Z 4 P P X X X X X X X X X X X X
Все криптографические модули , используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули(tamper-responsive),и взлообнаруживающие,или ВО-модули(tamper-evident)
Табл. 1. Формат ПИН-блока ISO-0 при 4-цифровом ПИН-коде PBL-1 1 4 P P P P R R R R R R R R R R
Табл. 2. Формат ПИН-блока ISO-1 при 4-цифровом ПИН-коде PBL-2 2 4 P P P P F F F F F F F F F F
Табл. 3. Формат ПИН-блока ISO-2 при 4-цифровом ПИН-коде Р1 3 4 Р Р Р Р G G G G G G G G G G Р2 Z Z Z Z A A A A A A A A A A A A PBL-3 3 4 P P X X X X X X X X X X X X
Табл. 4. Формат ПИН-блока ISO-3 при 4-цифровом ПИН-коде Все криптографические модули, используемые в платежной индустрии, делятся на взломостойкие, или ВС-модули (tamper-responsive), и взломообнаруживающие, или ВО-модули (tamper-evident) кодов), должны относиться к ВС-модулям.
Проникновение в модуль, хранящий ключ генерации ПИН-кодов, влечет за собой компрометацию всех ПИН-кодов, когдалибо сгенерированных с помощью этого ключа. Поэтому в качестве криптографических модулей хоста эмитента (Host Security Module, или HSM) используются исключительно ВС-модули.
Следует отметить, что в терминалах, поддерживающих обслуживание микропроцессорных карт, PED и картридер зачастую интегрируются в одном ВО-модуле. Это сделано для того, чтобы при передаче ПИН-кода от PED непосредственно карте можно было бы не шифровать ПИН-блок, если этого не требует метод верификации держателя карты (т.е. если используется метод Offline plaintext PIN). В случае, когда PED и картридер – отдельные неинтегрированные устройства, и используется метод верификации Offline plaintext PIN, при передаче ПИН-блока карте обязательно его шифрование в PED и расшифрование картридером перед передачей ПИН-блока карте.
Об атаках извлекающих ПИН-код
Не успели стихнуть дебаты вокруг без преувеличения сенсационных результатов данного исследования, как в 2006г. была обнародована новая работа, подтвердившая сформулированный выше тезис о "слабых звеньях" интерфейса Standard Financial API и описывающая целый ряд неизвестных ранее возможных атак, направленных на извлечение ПИН-кода. Авторы этого исследования обнаружили новые возможности использования уже известных "дыр" в защите интерфейса Standard Financial API. Характерно, что, несмотря на соблазн рассказать на страницах настоящей статьи о новых типах атак, описанных в работе, мы решили отказаться от этой затеи, не желая пропагандировать мошеннические атаки в открытой печати.
Заметим лишь, что все атаки, приведенные в данной работе, основаны на следующих предположениях:
1) у мошенника имеется возможность логического доступа к HSM процессингового центра для обращения к HSM с командами Standard Financial API;
2) мошенник имеет возможность извлечь зашифрованное значение ПИН-блока и соответствующие ему значения ПИН-кода и номера карты. Чтобы получить триплет "зашифрованный ПИН-блок, ПИН-код, номер карты", мошенник изготавливает карту с известным ему номером и ПИНкодом, отправляется к банкомату, подключенному к процессинговому центру, делает попытку совершения операции и, наконец, потом находит "следы" этой попытки в приложении ПЦ (предполагается, что "следы" содержат все интересующие злоумышленника данные).
Для осуществления некоторых типов атак (например, изменение значения ПИН-кода) преступнику иногда требуется доступ к БД карт банка-эмитента. Следует отметить, что в целом предположения "1" и "2" являются трудно реализуемыми на практике. Обычно банки/ПЦ уделяют самое серьезное внимание ограничению физического и логического доступа к HSM. Так, например, широко распространена практика, когда доступ к HSM ПЦ возможен только из прикладного программного обеспечения ПЦ, либо он предоставляется офицерам безопасности исключительно для загрузки новых ключей. При этом офицеры безопасности используют для загрузки ключей специальное терминальное оборудование, доступ к которому в соответствии с PCI PIN Requirements находится под двойным контролем. Если HSM подключен к локальной сети банка, то сетевой доступ к HSM также ограничен настройками межсетевого экрана только возможностью работы с хостом ПЦ.
Что касается извлечения триплета "зашифрованный ПИН-блок, ПИН-код, номер карты" из ПЦ, то и здесь все обстоит непросто, поскольку в соответствии с PCI PIN Requirements ПИН-блоки даже в зашифрованном виде не должны храниться в ПЦ. Злоумышленнику необходимо не только сгенерировать зашифрованный ПИН-блок с известным значением ПИНкода, например, обратившись к банкомату, подключенному к ПЦ, для выполнения какой-либо операции, но и успеть обнаружить значение ПИН-блока средствами приложения ПЦ за короткое время обработки транзакции в ПЦ.
Однако, несмотря на трудность выполнения приведенных выше условий, данные задачи все же реализуемы. И здесь главная проблема состоит в том, что банкэмитент не может повлиять на защищенность ПИН-кода его клиента, поскольку большинство атак, описанных в работе[2], может успешно выполняться на промежуточных хостах, к которым эмитент не имеет никакого отношения.
Следует отметить, что в основе всех приведенных атак лежат следующие известные "дыры" в Standard Financial API:
– возможность конверсии ПИН-блока из одного формата в другой;
– возможность изменения ПИН-кода держателя карты без одновременной проверки криптографическим модулем прежнего значения ПИН-кода с его привязкой к номеру карты (такая проверка выполняется, но приложением ПЦ).
Отметим, что возможность конверсии ПИН-блока из безопасных форматов ISO-0 и ISO-3 в небезопасные форматы ISO-1 и тем более ISO-2 лежит в основе большинства атак на ПИНкод, описанных в работе [2]. На практике часто нет необходимости в использовании форматов ISO-1 и ISO-2 на хосте банка/ПЦ (формат ISO-2 применяется для передачи зашифрованного ПИН-блока от картридера карте). Поэтому с точки зрения безопасности очень разумно на уровне приложения ПЦ запретить (просто не поддерживать) выполнение конверсии ПИН-блоков в эти форматы. Что касается прямого доступа злоумышленника к HSM, то его необходимо исключить, ограничив доступ к HSM офицерам безопасности только с целью загрузки ключей при соблюдении принципа двойного контроля.
Борьбы с компрометацией ПИН-кода
Таким образом, с точки зрения криптоанализа передача ПИН-кода в зашифрованном и открытом виде в этом случае… равноценны. С точки зрения практики, разумеется, требуется сделать невозможным для мошенника получение в его распоряжение случайного числа карты и/или случайной последовательности терминала. Эффективным способом борьбы с компрометацией ПИН-кода является формирование случайной последовательности терминала криптографическим модулем терминала. Однако "родные" криптографические модули, используемые в терминалах известных мировых производителей, вообще не реализуют функцию шифрования ПИН-блока в соответствии со стандартом EMV. Обычно алгоритм шифрования ПИН-блока реализуется в модулях SAM (Security Application Module), устанавливаемых в POS-терминалах.
В этом случае, как правило, терминал сам подготавливает случайную последовательность и передает ее в SAM для шифрования ПИН-блока с помощью алгоритма RSA. Как можно сделать вывод из сказанного выше, очевидно, что такой способ шифрования ПИН-блока уязвим. Поскольку случайное число карты и случайная последовательность терминала открыты для потенциального мошенника, то он, зная значение зашифрованного ПИН-блока и открытый ключ карты, легко восстанавливает значение ПИН-кода. Многие модули SAM содержат датчики случайных чисел. Поэтому при соответствующем программировании модуля SAM можно добиться того, чтобы случайная последовательность терминала генерировалась в этом модуле.
Итак, генерация случайной последовательности терминала в криптографическом модуле – единственно правильный подход к шифрованию ПИН-блока. Процедура генерации случайного числа модулем SAM не занимает много времени. Например, если датчик случайных чисел модуля SAM генерирует случайное число размером 8 байтов за 10 миллисекунд (в действительности – в разы быстрее), то для генерации последовательности терминала может потребоваться генерация порядка 15 таких случайных чисел, на что уйдет 150 миллисекунд. Этот показатель не окажет заметного влияния на время выполнения операции в терминале. Ввод значения ПИН-кода держателем карты займет значительно больше времени.
Конфиденциальность ПИН-кода важна в условиях гибридной сети приема карт, в рамках которой обслуживаются как карты с магнитной полосой, так и микропроцессорные карты. Как уже отмечалось, в случае исключительно "микропроцессорной" среды приема карт (т. е. когда прием карт с магнитной полосой исключен) знание значения ПИН-кода мошеннику ничего не дает. Для совершения успешной мошеннической операции помимо знания значения ПИН-кода необходимо иметь саму микропроцессорную карту. Поэтому в условиях приема только микропроцессорных карт держатель карты, уверенный в том, что он карту не потеряет и ее у него не украдут, может особенно и не скрывать вводимое им на терминале значение ПИН-кода.
Международные платежные системы активно рекомендуют эмитентам использовать офлайновую проверку ПИН-кода в качестве основного метода верификации держателя карты. В частности, и MasterCard, и Visa постепенно, по регионам, начинают вводить перенос ответственности, называемый Chip&PIN Liability Shift. Чтобы сформулировать сущность Chip&PIN Liability Shift, введем следующие определения. Будем называть микропроцессорную карту Chip&PIN-картой, если метод проверки ПИН-кода Offline PIN (независимо от способа передачи ПИН-кода – в защищенном или незащищенном виде) является самым приоритетным в списке CVM List в условиях выполнения данной операции. По-прежнему будем говорить, что терминал поддерживает метод Offline PIN, если он поддерживает защищенную и открытую передачу ПИН-кода на карту. Тогда перенос ответственности Chip&PIN Liability Shift формулируется следующим образом: если Chip&PIN-карта используется в терминале, не поддерживающем Offline PIN, то вся ответственность за потерянные/похищенные (Lost/Stolen) карты, а также неполученные карты (NRI) переносится на банк-эквайер.
В результате рекомендуемая платежными системами приоритетность правил верификации держателя карты в CVM List при выполнении операции с использованием DDA/CDA-карты в POS-терминале имеет следующий вид:
1)Enciphered Offline PIN;
2)Plaintext Offline PIN;
3)Online PIN;
4)Signature;
5)No CVM.
Такая приоритетность правил верификации ЛСО рекомендуется для всех карточных продуктов Visa. Для кредитных продуктов MasterCard платежная система рекомендует поменять местами правила 3 и 4, а для карт Maestro требует исключить из списка правило 5.
Одной из серьезных "дыр" в модели обеспечения безопасности операций, выполняемых с использованием микропроцессорных карт, является практическая возможность заведения мошенником ложного открытого ключа системы в POS-терминал. Изготовив под ложным ключом системы сертификаты ключа эмитента, далее можно выпустить поддельные карты, которые будут успешно работать в терминалах с загруженным ложным ключом.
Естественным способом борьбы с такого рода мошенничеством является создание подписи вводимых в терминал ключей системы на ключе обслуживающего банка. Такая подпись проверяется криптографическим модулем терминала при выполнении каждой транзакции, тем самым обеспечивая целостность ключевой информации на терминале. В этом случае, не обладая ключом обслуживающего банка, невозможно успешно завести/использовать ложный открытый ключ системы. К сожалению, для того чтобы обойти упомянутую защиту открытых ключей системы, преступник может выбрать иной путь, нежели компрометация секретного ключа обслуживающего банка. Для совершения мошеннической операции ему достаточно загрузить на терминал фальшивый исполняемый модуль, который в отличие от приложения обслуживающего банка не станет проверять подпись используемого ключа. В этом случае описанная выше защита не работает.
Чтобы лишить мошенника возможности замены приложения терминала, требуется подключить ресурсы операционной системы (загрузчика ОС) и криптографического процессора терминала. Все команды загрузки/удаления программных модулей должны подписываться обслуживающим банком (или его авторизованным представителем), а подпись должна проверяться криптографическим модулем терминала (например, модулем SAM или специализированной микропроцессорной картой). В то же время отметим, что проблема обеспечения целостности приложения терминала не является надуманной.
По мнению экспертов в области безопасности карточных операций, по мере повышения защищенности карт внимание мошенников все чаще будет обращаться на среду их обслуживания. Терминал является близким окружением карты и потому, несомненно, станет мишенью для атак. Поскольку терминал сегодня фактически представляет собой персональный компьютер, то для атак будут использоваться те же методы, что и в случае атак на PC. В частности, применение специальных вредоносных программ (аналог программ spyware, Trojan horse, keyboard/ screen logger или иных вирусов) позволит мошеннику получать интересующую его информацию о карте (например, содержимое второй дорожки магнитной полосы карты, значение случайной последовательности терминала и случайного числа карты, используемых для шифрования ПИН-блока, значение зашифрованного ПИН-блока и т. п.).
Важна также и проблема подмены настоящего POS-терминала банка терминалом, установленным мошенниками. В отличие от стоимости банкомата стоимость POS-терминала невелика – 400–600 долл. США. Поэтому подобная подмена является весьма правдоподобной при сговоре мошенника с кассиром торгового предприятия (как уже упоминалось, известны случаи установки даже "фальшивых" банкоматов!). Возможны также ситуации, когда недобросовестное торговое предприятие будет использовать POS-терминал только с целью сбора информации о картах.
В случае применения "фальшивого" терминала может компрометироваться не только содержимое магнитной дорожки карты, но и значение ПИН-кода держателя карты. С учетом использования на практике гибридных карт, имеющих как чип, так и магнитную полосу, получив информацию о магнитной дорожке карты и значение ее ПИН-кода, мошенник может изготовить "белые" карты для их последующего использования в банкомате для снятия наличных.
Для решения проблемы возможной установки преступниками "фальшивого" POS-терминала при обработке карточных операций в онлайновом режиме необходимо повсеместно внедрять коды MAC для сообщений, циркулирующих между терминалом и хостом обслуживающего банка. Это обеспечит целостность информационного обмена и аутентификацию POS-терминала. Между тем использование кодов MAC позволяет эффективно решить проблему только для онлайновых операций. Информация об офлайновых транзакциях, выполненных на терминале, также может подписываться для передачи в обслуживающий банк. Однако мошеннический терминал может и не передавать эту информацию в банк достаточно долго или вообще никогда. К сожалению, в случае, когда терминал действует в офлайновом режиме, кроме стандартных организационных мер для борьбы с подобного рода мошенничествами участникам рынка предложить пока нечего.
Достаточно эффективным способом борьбы с подменой POS-терминалов могло бы стать введение в рамках стандарта EMV процедуры взаимной аутентификации карты и терминала. Заведение на терминал пары секретного и открытого асимметричных ключей обслуживающего банка и сертификата этого ключа на ключе системы, а также поддержка картой процедуры аутентификации терминала и хранение на карте хэш-функций открытых ключей системы позволит исключить подмену терминала. Хранение на карте хэшфункций открытых ключей системы необходимо для того, чтобы избежать ситуации, когда мошенник сам придумывает ложный ключ системы и генерирует пару ключей для их заведения в терминал обслуживающего банка с сертификатом, вычисленным на ложном ключе системы.
Разумеется, хранение хэш-функций ключей системы (очевидно, что придется хранить информацию о ключах, сгенерированных "впрок", чтобы избежать ситуации, когда во время жизненного цикла карты на терминалах появятся ключи системы, неизвестные карте) накладывает ограничения на размер памяти EEPROM карты. Терминал должен хранить до 6 ключей одной системы. Поэтому с учетом ключей, заводимых в терминал "впрок", и длины значения хэш-функции SHA-1, равной 20 байтам, потребуется зарезервировать около 200 байтов памяти карты EEPROM для одной платежной системы.
Заключение
Не следует считать, что современная ситуация с компрометацией ПИН-кодов является катастрофической или хотя бы достигла просто угрожающего для индустрии платежных карт уровня. Возможно, автор настоящей статьи слишком сгустил краски вокруг этой проблемы. Кроме того, повсеместный переход на технологию микропроцессорных карт, свидетелями начала которого мы все являемся, заметно снизит актуальность проблемы. В случае повсеместного внедрения микропроцессорных карт компрометация ПИН-кода уже ничего не даст злоумышленнику, поскольку для выполнения мошеннической операции ему потребуется и сама карта законного держателя, которой в большинстве случаев злоумышленник не располагает.
Однако до момента полной миграции на микропроцессорные карты пройдет еще не менее десятилетия. Сегодня во всем мире только порядка 15% карт, 20% POS-терминалов и 12,5% банкоматов являются EMV-совместимыми. А это значит, что те угрозы, о которых было рассказано в настоящей статье, являются по-прежнему актуальными, и к ним нужно относиться более чем серьезно.
С точки зрения практики это сводится в первую очередь, конечно же, к соблюдению требований к безопасности генерации, хранения и передачи значений ПИН-кодов, опубликованных в документе PCI PIN Security Requirements. В соответствии с этими требованиями необходимо уделять самое пристальное внимание ограничению прямого доступа (не из приложения ПЦ) к HSM. Доступ к HSM должен выполняться под двойным контролем и желательно только с целью загрузки новых ключей (автор статьи, имеющий опыт работы в крупнейшем в России ПЦ, может утверждать, что на практике такое ограничение прямого доступа к HSM вполне возможно). Все остальные функции HSM (генерация/верификация ПИН-кода, PIN Offset Calculation, PVV Calculation, PIN translation и т. п.) должны реализовываться только по запросам из приложения ПЦ.
Отметим также, что в приложении ПЦ необходимо предусмотреть запрет конверсии ПИН-блоков из безопасных форматов в форматы ISO-1 и ISO-2. Это позволит избежать всех атак.
копирайт - копипаст - статья собрана с просторов интернета.
