Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
>Принципиальная невозможность восстановления PIN из значения PVV
Да ладно, банк-то может перебрать 10000 вариантов PIN, чтобы получить тот же PVV за разумный срок :)
Да ладно, банк-то может перебрать 10000 вариантов PIN, чтобы получить тот же PVV за разумный срок :)
Согласен, но полным перебором можно подобрать достаточно много вещей.
Только тут возникает вопрос, как перед этим получить:
1. доступ к HSM, чтобы это сделать
2. зашифрованный PIN блок для всех 10000 значений
Тут важно то, что в случае перебора используется та же самая прямая функция преобразования PIN в PVV, а обратной функции нет, что для метода IBM 3624 PIN offset не верно.
К тому же HSM может иметь защиту от полного перебора. Тот же Thales такую опцию в некоторых прошивках поддерживает (или поддерживал ранее, точно сказать не могу).
Только тут возникает вопрос, как перед этим получить:
1. доступ к HSM, чтобы это сделать
2. зашифрованный PIN блок для всех 10000 значений
Тут важно то, что в случае перебора используется та же самая прямая функция преобразования PIN в PVV, а обратной функции нет, что для метода IBM 3624 PIN offset не верно.
К тому же HSM может иметь защиту от полного перебора. Тот же Thales такую опцию в некоторых прошивках поддерживает (или поддерживал ранее, точно сказать не могу).
1. доступ к HSM, чтобы это сделать
В каждом HSM свой уникальный набор ключей? Ключ 8 байт?
К тому же HSM может иметь защиту от полного перебора. Тот же Thales такую опцию в некоторых прошивках поддерживает (или поддерживал ранее, точно сказать не могу).
И что, потом блокируется и хоть выкидывай? Или есть кнопочка reset?
Превращается в тыкву.
1. доступ к HSM, чтобы это сделатьВ каждом HSM свой уникальный набор ключей? Ключ 8 байт?
Ключ PVK, в случае алгоритма Visa PVV строго 112 бит (16 байт).
Относительно HSM, тут все зависит от того, какой способ хранения ключей используется. Если это хранение ключа внтури HSM, то используемый HSM должен содержать в себе требуемый ключ. Если это хранение ключа под Мастер ключом, то используемый HSM должен содержать тот же самый Мастер ключ.
Тут стоит добавить, что реальные HSM (т.е. те, которые используются в промышленной версии системы, а не тестовые, которые, обычно, напоминают проходной двор и используют стандартный набор тестовых ключей производителя), обычно, достаточно жестко ограничиваются в доступе:
1. Строгий регламент по заведению ключей в HSM, при котором один человек не знает всех необходимых данных для введения ключа, Мастер ключа и прочего (обычно, для заведения ключей используют 3 компоненты, т.е. разных человека).
2. Строгий регламент на ограничение доступа к HSM, как физический, так и на сетевом уровне (строго, физически отдельная подсеть) с контролем соблюдения этого доступа.
И что, потом блокируется и хоть выкидывай? Или есть кнопочка reset?
Насколько я помню, там некоторое время после определения попытки подбора то ли возвращался специальный код ответа на операцию проверки PIN, то ли банился IP, с которого шел подбор. Никаких летальных последствий для HSM.
> перебрать 10000 вариантов PIN
Чуть меньше, т.к. www.gae.ucm.es/~padilla/extrawork/visapvv.html «on average, each card has two valid PINs: the customer PIN and the expected false positive»
Чуть меньше, т.к. www.gae.ucm.es/~padilla/extrawork/visapvv.html «on average, each card has two valid PINs: the customer PIN and the expected false positive»
ну и для перебора 10000 значений, в среднем, нужно все ж около 5000 попыток. Как повезет :)
Тут еще дело в том, что алгоритм Visa PVV не дает взаимно однозначного соответствия, т.е. возможно ситуация, когда для одного и того же значения PVV будет 2 и более значений PIN кодов. Это связано с особенностями работы функции преобразования криптограммы в PVV.
Тут сразу хочу добавить, что в теоретической криптографии не силен. Максимум, могу попробовать на досуге собрать статистику по уникальности PIN относительно PVV.
Тут сразу хочу добавить, что в теоретической криптографии не силен. Максимум, могу попробовать на досуге собрать статистику по уникальности PIN относительно PVV.
Какие алгоритмы сейчас разрешены к использованию стандартом ISO 9564? Нет ли требований PCI на использование 3DES вместо DES?
Относительно ISO 9564 ничего сказать не могу, т.к., кроме формата PIN блоков, с ним не сталкивался. Если речь идет про алгоритмы проверки PIN, то и Visa, и MasterCard допускают использование обоих алгоритмов.
Относительно PCI DSS все вообще очень интересно. Самим стандартом допускается использование только «Strong Cryptography», который тоже явно не определен. В PCI DSS Glossary есть некоторое «определение», которое сводится к тому, что AES можно, 3DES с ключом двойной или тройной длины можно. Аналогично есть требования к использованию 3DES со стороны платежных сетей. Но все эти требования касаются только шифрования данных (в нашем случае — шифрования PIN блока) и не касаются всех остальных действий — проверки карты (CVV), EMV данных и прочего. Там сейчас используется алгоритм DES, точнее, его производная в виде алгоритма рассчета MAC ANSI X9.19 (к сожалению, не помню, с каким стандартом ISO он соотносится). Именно этот момент я и имел ввиду, когда писал, что основным алгоритмом шифрования для всех действия с банковскими картами является алгоритм DES.
Относительно PCI DSS все вообще очень интересно. Самим стандартом допускается использование только «Strong Cryptography», который тоже явно не определен. В PCI DSS Glossary есть некоторое «определение», которое сводится к тому, что AES можно, 3DES с ключом двойной или тройной длины можно. Аналогично есть требования к использованию 3DES со стороны платежных сетей. Но все эти требования касаются только шифрования данных (в нашем случае — шифрования PIN блока) и не касаются всех остальных действий — проверки карты (CVV), EMV данных и прочего. Там сейчас используется алгоритм DES, точнее, его производная в виде алгоритма рассчета MAC ANSI X9.19 (к сожалению, не помню, с каким стандартом ISO он соотносится). Именно этот момент я и имел ввиду, когда писал, что основным алгоритмом шифрования для всех действия с банковскими картами является алгоритм DES.
Забавный факт №1: правила MasterCard для мерчантов и разработчиков пинпадов постулируют, что в Европе любой пинпад должен быть способен принять пин из 4-6 цифр, а в Северной Америке — из 4-16 алфавитных символов и/или цифр. Что именно является причиной этого мне совершенно не ясно, особенно учитывая известную консервативность американских банков. (речь об online транзакциях с верификацией PIN в чипе, если что)
Забавный факт №2: единственная страна Европы, в которой банки выдают карточки с PIN из шести цифр по-умолчанию — Швейцария.
Забавный факт №3: изобретатель банкоматов предполагал, что все PINы будут из шести цифр, но его жена настояла, что четыре будут удобнее.
Забавный факт №2: единственная страна Европы, в которой банки выдают карточки с PIN из шести цифр по-умолчанию — Швейцария.
Забавный факт №3: изобретатель банкоматов предполагал, что все PINы будут из шести цифр, но его жена настояла, что четыре будут удобнее.
- Проверка PIN для эмитента карты — это один из методов проверки держателя карты (Cardholder Verification Method).
- Для магнитных карт PIN всегда проверяет хост (процессинговое ПО на стороне эмитента).
- Магнитные карты имеют на треке PVV — ключевой хэш от комбинации PAN и PIN на DES-ключе. 3-DES тут просто не нужен из-за длины PIN, длины PVV и ограничения на число ввода неверного PIN.
- Передаваемый от терминала до эмитента карты PIN летит в виде зашифрованного (уже скорее под 3-DES, чем под DES) значения PIN Block (функция от PAN и PIN), коих встречается несколько форматов (от чистого PIN до PIN xor PAN и т.д.).
- Эмитент, получив PIN Block, при помощи черного ящика HSM и зашифрованных данных в своей БД может сделать что-либо из:
- посчитать по нему PVV и сравнить его с прилетевшим рядом либо хранящимся в БД значением PVV с трека;
- сравнить его с тем PIN Block, что хранится в БД (или посчитать PIN Block по хранящемуся в БД PIN и сравнить с прилетевшим);
- из него и прилетевшего рядом PVV с трека, и хранящегося в БД PIN Offset (не путать с IBM PIN Offset) проверить прилетевший PIN Block (по PAN и PIN Offset восстановить PIN нельзя, это некоторая разность);
- Помимо этого, чиповые карты могут еще и проверять PIN сами, т.к. в защищенной памяти на чипе может быть записано много чего интересного.
- Для этого чиповая карта запрашивает у терминала (проверяет то, что получила, а при случае или сразу сообщает об этом хосту эмитента):
- или сам PIN в чистом виде;
- или он же, но зашифрованный на её открытом ключе;
- Роль эмитента при авторизации может брать на себя платежная система (если эмитент недоступен или не умеет проверять определенные данные), естественно, за деньги. Этот сервис называется STIP (STand-In Processing).
- Процес смены PIN — это отдельная песня, упомянем только то, что по понятным причинам магнитный трек и PVV на нем никто не трогает, а у чиповых карт есть два потенциально разных PIN, онлайновый (проверяет эмитент при наличии связи с ним) и оффлайновый (проверяет сама карта)
Вынужден не согласиться с некоторыми вашими утверждениями:
2. И Visa, и MasterCard уже давно предоставляют сервисы по проверки PIN на своей стороне.
Т.к. за последние лет 5 этот сервис несколько раз улучшался, могу предположить, что им кто-то пользуется. Как минимум, в опросниках при подключении нового банка к платежной сети есть пункт, хочет ли банк использовать данный сервис. К STIP данный сервис никакого отношения не имеет, хотя, технически, там выполняется такая же процедура проверки PIN.
3.
Должны иметь на треке в соответствии с стандартами платежных сетей. На практике, это требование выполняется не всегда. Встречал очень много раз, когда у банка стояла какая-либо старая процессинговая система.
Только в случае метода Visa PVV, для IBM 3624 PIN offset это утверждение, в общем случае, не верно. На практике, встречал ситуацию, когда данное утверждение было неверно — качестве части validation data бралась какая-то производная от имени владельца карты, но это был единственный такой случай.
В теории, верно для IBM 3624 PIN offset, хотя сейчас уже и в нем, иногда, используют 3DES. Верно для алгоритма Visa CVV (к проверке PIN не имеет никакого отношения). Для Visa PVV неверно, там чистый 3DES с ключом двойной длины.
5.
Чисто теоретически — да, это возможно, практически, не все HSM позволяют это свободно делать. HSM, гарантированно, предоставляет только операцию, при которой он сам (HSM) внутри себя производит вычисление PVV и сравнение его с эталоном.
Как уже писалось выше, ни PIN блок, даже зашифрованный, ни, уж тем более, PIN хранить нельзя, т.е. данный вариант полностью исключается для нормальной (полноценно сертифицированной и соответствующей требованиям безопасности платежных систем) карточной системы.
Извините, не понял, что в данном случае называется «хранящимся в БД PIN Offset» и при чем тут «не путать с IBM PIN Offset».
Если речь идет про метод IBM 3624 PIN Offset, то можно. В случае метода Visa PVV никакого PIN offset нет, т.ч. тоже не понял, что здесь имеется ввиду.
8
Не совсем так. STIP — это именно сервис, в рамках которого платежная сеть полностью авторизует операцию вместо эмитента. А проверка каких-либо данных идет отдельным сервисом, который к самому STIP не привязан. Т.е. эмитент просто может отдать на откуп платежной сети проверку PIN, CVV, EMV данных, но за само разрешение авторизации, при этом, по прежнему будет отвечать сам эмитент. Эта ситуация не считается STIP. STIP'ом будет ситуация, при которой платежная сеть сама авторизует (разрешит или отклонит) запрос от эквайера, а уже по результатам этого действия пошлет уведомление эмитенту, о том, что такая операция имела место и по ней (в случае разрешения) надо списать деньги.
2. И Visa, и MasterCard уже давно предоставляют сервисы по проверки PIN на своей стороне.
Т.к. за последние лет 5 этот сервис несколько раз улучшался, могу предположить, что им кто-то пользуется. Как минимум, в опросниках при подключении нового банка к платежной сети есть пункт, хочет ли банк использовать данный сервис. К STIP данный сервис никакого отношения не имеет, хотя, технически, там выполняется такая же процедура проверки PIN.
3.
Магнитные карты имеют на треке PVV
Должны иметь на треке в соответствии с стандартами платежных сетей. На практике, это требование выполняется не всегда. Встречал очень много раз, когда у банка стояла какая-либо старая процессинговая система.
PVV — ключевой хэш от комбинации PAN и PIN
Только в случае метода Visa PVV, для IBM 3624 PIN offset это утверждение, в общем случае, не верно. На практике, встречал ситуацию, когда данное утверждение было неверно — качестве части validation data бралась какая-то производная от имени владельца карты, но это был единственный такой случай.
комбинации PAN и PIN на DES-ключе
В теории, верно для IBM 3624 PIN offset, хотя сейчас уже и в нем, иногда, используют 3DES. Верно для алгоритма Visa CVV (к проверке PIN не имеет никакого отношения). Для Visa PVV неверно, там чистый 3DES с ключом двойной длины.
5.
посчитать по нему PVV и сравнить его с прилетевшим рядом либо хранящимся в БД значением PVV с трека;
Чисто теоретически — да, это возможно, практически, не все HSM позволяют это свободно делать. HSM, гарантированно, предоставляет только операцию, при которой он сам (HSM) внутри себя производит вычисление PVV и сравнение его с эталоном.
сравнить его с тем PIN Block, что хранится в БД (или посчитать PIN Block по хранящемуся в БД PIN и сравнить с прилетевшим);
Как уже писалось выше, ни PIN блок, даже зашифрованный, ни, уж тем более, PIN хранить нельзя, т.е. данный вариант полностью исключается для нормальной (полноценно сертифицированной и соответствующей требованиям безопасности платежных систем) карточной системы.
из него и прилетевшего рядом PVV с трека, и хранящегося в БД PIN Offset (не путать с IBM PIN Offset) проверить прилетевший PIN Block (по PAN и PIN Offset восстановить PIN нельзя, это некоторая разность);
Извините, не понял, что в данном случае называется «хранящимся в БД PIN Offset» и при чем тут «не путать с IBM PIN Offset».
(по PAN и PIN Offset восстановить PIN нельзя, это некоторая разность)
Если речь идет про метод IBM 3624 PIN Offset, то можно. В случае метода Visa PVV никакого PIN offset нет, т.ч. тоже не понял, что здесь имеется ввиду.
8
Не совсем так. STIP — это именно сервис, в рамках которого платежная сеть полностью авторизует операцию вместо эмитента. А проверка каких-либо данных идет отдельным сервисом, который к самому STIP не привязан. Т.е. эмитент просто может отдать на откуп платежной сети проверку PIN, CVV, EMV данных, но за само разрешение авторизации, при этом, по прежнему будет отвечать сам эмитент. Эта ситуация не считается STIP. STIP'ом будет ситуация, при которой платежная сеть сама авторизует (разрешит или отклонит) запрос от эквайера, а уже по результатам этого действия пошлет уведомление эмитенту, о том, что такая операция имела место и по ней (в случае разрешения) надо списать деньги.
Я просто сделал выжимку, а если мы с Вами будем дальше уточнять из нее каждый пункт, то ветка утонет в обсуждениях :)
2) см п.8. МПС может проверить криптовеличины или вообще авторизовать транзакцию. Подробности сервисов МПС едва ли кому-то интересны.
3) да, сплошные упрощения, а то можно еще вспомнить про TSP (Transformed Security Parameter) и найти какую-нибудь реализацию, в которой TSP всегда равен PIN-блоку, например.
5) эмитенту при определенных условиях, strong business needs и наличии адекватных compensating controls можно многое. При использовании HSM корректно зашированные значения почти любых данных на стороне эмитента можно смело печатать на столбах, и PCI SSC это прекрасно понимает.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
8) да, упростил.
2) см п.8. МПС может проверить криптовеличины или вообще авторизовать транзакцию. Подробности сервисов МПС едва ли кому-то интересны.
3) да, сплошные упрощения, а то можно еще вспомнить про TSP (Transformed Security Parameter) и найти какую-нибудь реализацию, в которой TSP всегда равен PIN-блоку, например.
5) эмитенту при определенных условиях, strong business needs и наличии адекватных compensating controls можно многое. При использовании HSM корректно зашированные значения почти любых данных на стороне эмитента можно смело печатать на столбах, и PCI SSC это прекрасно понимает.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
8) да, упростил.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
Понял, спасибо. Просто никогда раньше про такую схему не слышал, хотя схема вполне логичная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проверка PIN кода банковских карт