Как было написано выше, требование отсутствия комиссий касается только торговых операций и не касается выдачи наличных.
Тут уже и Visa и MasterCard абсолютно спокойно относятся к комиссиям со стороны банка эквайера и тут все уже зависит от жадности конкретного эквайера: от отсутствия какой либо дополнительной (которая добавляется к сумме авторизации в суммее запроса на списания), до вполне ощутимых сумм. Раньше (лет 6 назад) это, действительно было запрещено, но потом такие комиссии разрешили сначала Visa, а, через полгода, и MasterCard. Более того, были специальные доработки для их протоколов, чтобы позволить эмитенту выделять непосредственно сумму запроса клиента и сумму комиссии, которую накручивает банк эквайер.
1. Что остается у магазина.
Тут стоит принципиально выделить 2 типа магазинов: физические, т.е. магазины, где присутствуют физические терминалы (говоря именно о терминалах, а не о картах, я подразумеваю, что возможна ситуация, при которой на физическом терминале будет проведена операция без физического чтения данных карты с магнитной полосы или чипа карты, независимо от того, присутствует сама карта или нет).
В этом случае у магазина, как правило, остается только чек, на котором остается (из интересующих нас данных) номер карты в формате 6x4 (6 первых и 4 последних цифры) или x4, дополнительно там может присутствовать имя владельца карты (если оно присутствует в данных чипа или магнитной полосы и его печать на чеке заложена в ПО терминала). Исключение — когда терминал интегрирована с каким-либо кассовым оборудованием магазина, в этом случае у магазина, теоретически, могут остаться любые данные, которые он смог прочитать с карты.
Второй тип магазина — интернет магазины. Здесь ничего, однозначно, сказать нельзя, т.к. все зависит от способа работы этого магазина. В минимальном варианте у магазина не остается вообще ничего, в предельном — номер карты, срок ее действия, код CVV2/CVC2 (хотя это и запрещено), фамилия имя владельца, как их ввел покупатель при оплате.
2. Что приходит в банк.
— Страна, где зарегистрирован магазин.
— Адрес (для банкомата) или наименование (для магазина). В наименование магазина, иногда, включается часть адреса.
— Идентификатор банка/участника платежной системы, который обслуживает терминал, где была проведена операция. Т.н. эквайерский БИН.
— Категория торговой организации (далее мерчанта), в англоязычных текстах этот термин обозначается как merchant category code (он же MCC, введен в стандарте ISO 8583 версии 87 года) или card acceptor business code (заменил термин MCC в ISO 8583 версии 93 года). По нему можно, косвенно, определить, что это был за магазин. Например, магазин электроники, оплата телекоммуникационных услуг, отеля, ресторана и пр. Некоторые отели и авиакомпании имеют свои собственные уникальные идентификаторы категорий, которые позволяют не просто сказать, что это была оплата в авиакомпании, а указать конкретную авиакомпанию.
— Идентификатор терминала и/или мерчанта.
— Информация о том, был ли PIN, каким образом была прочитана карта (магнитная полоса, чип, бесконтактный ввод, ручной ввод и пр.)
Из основных — это все.
При этом, у платежной сети — все то же, что пришло эмитенту.
Про упомнятуый «offset» — попробуйте набросать схему смены PIN по магнитным картам, при которой в БД не хранится ни PIN, ни старый, ни новый PVV для нового PIN. Ответом (рекомендуемым платежными системами) будет хранение некоторой функции-разности «offset», позволяющей посчитать новый PVV на стороне эмитента из хранящегося offset, входящего PVV с трека и входящего PIN-блока.
Понял, спасибо. Просто никогда раньше про такую схему не слышал, хотя схема вполне логичная.
Вынужден не согласиться с некоторыми вашими утверждениями:
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 года) лучше проконсультироваться с сотрудниками банков, но, в любом случае могу сказать, что информация о том, сколько и где снималось/покупалось храниться определенное время.
В каждом HSM свой уникальный набор ключей? Ключ 8 байт?
Ключ PVK, в случае алгоритма Visa PVV строго 112 бит (16 байт).
Относительно HSM, тут все зависит от того, какой способ хранения ключей используется. Если это хранение ключа внтури HSM, то используемый HSM должен содержать в себе требуемый ключ. Если это хранение ключа под Мастер ключом, то используемый HSM должен содержать тот же самый Мастер ключ.
Тут стоит добавить, что реальные HSM (т.е. те, которые используются в промышленной версии системы, а не тестовые, которые, обычно, напоминают проходной двор и используют стандартный набор тестовых ключей производителя), обычно, достаточно жестко ограничиваются в доступе:
1. Строгий регламент по заведению ключей в HSM, при котором один человек не знает всех необходимых данных для введения ключа, Мастер ключа и прочего (обычно, для заведения ключей используют 3 компоненты, т.е. разных человека).
2. Строгий регламент на ограничение доступа к HSM, как физический, так и на сетевом уровне (строго, физически отдельная подсеть) с контролем соблюдения этого доступа.
И что, потом блокируется и хоть выкидывай? Или есть кнопочка reset?
Насколько я помню, там некоторое время после определения попытки подбора то ли возвращался специальный код ответа на операцию проверки PIN, то ли банился IP, с которого шел подбор. Никаких летальных последствий для HSM.
Не соглашусь с утверждением про один IIN на один банк в платежной сети. Как минимум, в случае MasterCard м.б. 2 IIN — один с 5xxxxx для MasterCard и один с 6xxxxx для Maestro (сеть в обоих случаях — MasterCard).
Лет 6 назад точно была ситуация, когда банку выдавали новый IIN под новый карточный продукт (Visa или MasterCard, уже не помню).
Относительно разделения по коду Visa/MasterCard на основании первой цифры. На самом деле, первая цифра не всегда однозначно определяет то, кому принадлежит карта. Где-то 5 лет назад натолкнулись на диапазон, выделенный для карт Visa в 5xxxxx диапазоне.
Теперь относительно карточных продуктов. Тут, насколько я знаю, следует разделять карточные продукты с т.з. банка и сточки зрения платежной сети. По Visa, таких продуктов, принципиально, 2 — Visa и Visa Electron, по MasterCard — 3: Debit MasterCard, Credit MasterCard, Maestro.
При этом, если в случае с Visa и Debit MasterCard/Credit MasterCard я не могу сказать, обязательно ли различаются IIN для разных продуктов, то для Maestro, в т.ч. может выделяться другой IIN, хотя может и не выделяться (в случае, когда идет кобрендинговая карта Maestro + Debit MasterCard).
P.S. Сейчас посмотрел свои карты Visa одного банка, у них IIN в 6 цифре различается на 1. Одна карта с кредитным лимтом, другая — без. Для карт MasterCard того же банка в аналогичной ситуации IIN совпадает.
Не совсем так.
Из HSM никуда не выходит открытое значение ключа (хотя это тоже не совсем корректное утверждение, но будем его придерживаться). Как я указал в habrahabr.ru/post/229527/, HSM отдает наружу либо ключ, зашифрованный под Мастер ключом, либо идентификатор ключа во внутреннем хранилище. Какой именно из этих методов будет применен, зависит от нескольких факторов, в т.ч. типа HSM, типа ключа, запрошенной команды на генерацию ключа.
Соответственно, в HSM в командах на выполнение операции, передается либо идентификатор ключа, либо его зашифрованное значение.
Тут еще дело в том, что алгоритм Visa PVV не дает взаимно однозначного соответствия, т.е. возможно ситуация, когда для одного и того же значения PVV будет 2 и более значений PIN кодов. Это связано с особенностями работы функции преобразования криптограммы в PVV.
Тут сразу хочу добавить, что в теоретической криптографии не силен. Максимум, могу попробовать на досуге собрать статистику по уникальности PIN относительно PVV.
Относительно 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.
Согласен, но полным перебором можно подобрать достаточно много вещей.
Только тут возникает вопрос, как перед этим получить:
1. доступ к HSM, чтобы это сделать
2. зашифрованный PIN блок для всех 10000 значений
Тут важно то, что в случае перебора используется та же самая прямая функция преобразования PIN в PVV, а обратной функции нет, что для метода IBM 3624 PIN offset не верно.
К тому же HSM может иметь защиту от полного перебора. Тот же Thales такую опцию в некоторых прошивках поддерживает (или поддерживал ранее, точно сказать не могу).
Без HSM банк не сможет расшифровать трафик от банкоматов. Соответственно, пока не поменяют в банкоматах ключи, «кина не будет». Не уверен, что везде так, но обычно pin-коды (и cvv) никуда не уходят и нигде не светятся в открытом виде — их сразу после ввода в систему шифруют, и только HSM может расшифровать, сравнить и сказать свое «одобрям-с».
На самом деле, шифрование трафика, в общем случае, никак с HSM не связано. В общем случае, здесь, обозначает, что сам протокол банкомата никакого шифрования трафика не предполагает. Обычно, для этого используются какие-либо аппаратные сетевые железки, например, какая-нибудь Cisco.
С помощью HSM шифруется только сам PIN блок.
Значение CVV передается в рамках данных трека (образа магнитной полосы) в открытом виде как от банкомата, так и далее по всем системам. Другое дело, что этот трек (и все другие данные) не передаются по открытой сети (интернет), что призвано минимизировать утечку этих данных.
Тут уже и Visa и MasterCard абсолютно спокойно относятся к комиссиям со стороны банка эквайера и тут все уже зависит от жадности конкретного эквайера: от отсутствия какой либо дополнительной (которая добавляется к сумме авторизации в суммее запроса на списания), до вполне ощутимых сумм. Раньше (лет 6 назад) это, действительно было запрещено, но потом такие комиссии разрешили сначала Visa, а, через полгода, и MasterCard. Более того, были специальные доработки для их протоколов, чтобы позволить эмитенту выделять непосредственно сумму запроса клиента и сумму комиссии, которую накручивает банк эквайер.
1. Что остается у магазина.
Тут стоит принципиально выделить 2 типа магазинов: физические, т.е. магазины, где присутствуют физические терминалы (говоря именно о терминалах, а не о картах, я подразумеваю, что возможна ситуация, при которой на физическом терминале будет проведена операция без физического чтения данных карты с магнитной полосы или чипа карты, независимо от того, присутствует сама карта или нет).
В этом случае у магазина, как правило, остается только чек, на котором остается (из интересующих нас данных) номер карты в формате 6x4 (6 первых и 4 последних цифры) или x4, дополнительно там может присутствовать имя владельца карты (если оно присутствует в данных чипа или магнитной полосы и его печать на чеке заложена в ПО терминала). Исключение — когда терминал интегрирована с каким-либо кассовым оборудованием магазина, в этом случае у магазина, теоретически, могут остаться любые данные, которые он смог прочитать с карты.
Второй тип магазина — интернет магазины. Здесь ничего, однозначно, сказать нельзя, т.к. все зависит от способа работы этого магазина. В минимальном варианте у магазина не остается вообще ничего, в предельном — номер карты, срок ее действия, код CVV2/CVC2 (хотя это и запрещено), фамилия имя владельца, как их ввел покупатель при оплате.
2. Что приходит в банк.
— Страна, где зарегистрирован магазин.
— Адрес (для банкомата) или наименование (для магазина). В наименование магазина, иногда, включается часть адреса.
— Идентификатор банка/участника платежной системы, который обслуживает терминал, где была проведена операция. Т.н. эквайерский БИН.
— Категория торговой организации (далее мерчанта), в англоязычных текстах этот термин обозначается как merchant category code (он же MCC, введен в стандарте ISO 8583 версии 87 года) или card acceptor business code (заменил термин MCC в ISO 8583 версии 93 года). По нему можно, косвенно, определить, что это был за магазин. Например, магазин электроники, оплата телекоммуникационных услуг, отеля, ресторана и пр. Некоторые отели и авиакомпании имеют свои собственные уникальные идентификаторы категорий, которые позволяют не просто сказать, что это была оплата в авиакомпании, а указать конкретную авиакомпанию.
— Идентификатор терминала и/или мерчанта.
— Информация о том, был ли 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 года) лучше проконсультироваться с сотрудниками банков, но, в любом случае могу сказать, что информация о том, сколько и где снималось/покупалось храниться определенное время.
Ключ PVK, в случае алгоритма Visa PVV строго 112 бит (16 байт).
Относительно HSM, тут все зависит от того, какой способ хранения ключей используется. Если это хранение ключа внтури HSM, то используемый HSM должен содержать в себе требуемый ключ. Если это хранение ключа под Мастер ключом, то используемый HSM должен содержать тот же самый Мастер ключ.
Тут стоит добавить, что реальные HSM (т.е. те, которые используются в промышленной версии системы, а не тестовые, которые, обычно, напоминают проходной двор и используют стандартный набор тестовых ключей производителя), обычно, достаточно жестко ограничиваются в доступе:
1. Строгий регламент по заведению ключей в HSM, при котором один человек не знает всех необходимых данных для введения ключа, Мастер ключа и прочего (обычно, для заведения ключей используют 3 компоненты, т.е. разных человека).
2. Строгий регламент на ограничение доступа к HSM, как физический, так и на сетевом уровне (строго, физически отдельная подсеть) с контролем соблюдения этого доступа.
Насколько я помню, там некоторое время после определения попытки подбора то ли возвращался специальный код ответа на операцию проверки PIN, то ли банился IP, с которого шел подбор. Никаких летальных последствий для HSM.
Лет 6 назад точно была ситуация, когда банку выдавали новый IIN под новый карточный продукт (Visa или MasterCard, уже не помню).
Относительно разделения по коду Visa/MasterCard на основании первой цифры. На самом деле, первая цифра не всегда однозначно определяет то, кому принадлежит карта. Где-то 5 лет назад натолкнулись на диапазон, выделенный для карт Visa в 5xxxxx диапазоне.
Теперь относительно карточных продуктов. Тут, насколько я знаю, следует разделять карточные продукты с т.з. банка и сточки зрения платежной сети. По Visa, таких продуктов, принципиально, 2 — Visa и Visa Electron, по MasterCard — 3: Debit MasterCard, Credit MasterCard, Maestro.
При этом, если в случае с Visa и Debit MasterCard/Credit MasterCard я не могу сказать, обязательно ли различаются IIN для разных продуктов, то для Maestro, в т.ч. может выделяться другой IIN, хотя может и не выделяться (в случае, когда идет кобрендинговая карта Maestro + Debit MasterCard).
P.S. Сейчас посмотрел свои карты Visa одного банка, у них IIN в 6 цифре различается на 1. Одна карта с кредитным лимтом, другая — без. Для карт MasterCard того же банка в аналогичной ситуации IIN совпадает.
Из HSM никуда не выходит открытое значение ключа (хотя это тоже не совсем корректное утверждение, но будем его придерживаться). Как я указал в habrahabr.ru/post/229527/, HSM отдает наружу либо ключ, зашифрованный под Мастер ключом, либо идентификатор ключа во внутреннем хранилище. Какой именно из этих методов будет применен, зависит от нескольких факторов, в т.ч. типа HSM, типа ключа, запрошенной команды на генерацию ключа.
Соответственно, в HSM в командах на выполнение операции, передается либо идентификатор ключа, либо его зашифрованное значение.
Тут сразу хочу добавить, что в теоретической криптографии не силен. Максимум, могу попробовать на досуге собрать статистику по уникальности PIN относительно PVV.
Относительно PCI DSS все вообще очень интересно. Самим стандартом допускается использование только «Strong Cryptography», который тоже явно не определен. В PCI DSS Glossary есть некоторое «определение», которое сводится к тому, что AES можно, 3DES с ключом двойной или тройной длины можно. Аналогично есть требования к использованию 3DES со стороны платежных сетей. Но все эти требования касаются только шифрования данных (в нашем случае — шифрования PIN блока) и не касаются всех остальных действий — проверки карты (CVV), EMV данных и прочего. Там сейчас используется алгоритм DES, точнее, его производная в виде алгоритма рассчета MAC ANSI X9.19 (к сожалению, не помню, с каким стандартом ISO он соотносится). Именно этот момент я и имел ввиду, когда писал, что основным алгоритмом шифрования для всех действия с банковскими картами является алгоритм DES.
Только тут возникает вопрос, как перед этим получить:
1. доступ к HSM, чтобы это сделать
2. зашифрованный PIN блок для всех 10000 значений
Тут важно то, что в случае перебора используется та же самая прямая функция преобразования PIN в PVV, а обратной функции нет, что для метода IBM 3624 PIN offset не верно.
К тому же HSM может иметь защиту от полного перебора. Тот же Thales такую опцию в некоторых прошивках поддерживает (или поддерживал ранее, точно сказать не могу).
Правильная ссылка — habrahabr.ru/post/166181/.
На самом деле, шифрование трафика, в общем случае, никак с HSM не связано. В общем случае, здесь, обозначает, что сам протокол банкомата никакого шифрования трафика не предполагает. Обычно, для этого используются какие-либо аппаратные сетевые железки, например, какая-нибудь Cisco.
С помощью HSM шифруется только сам PIN блок.
Значение CVV передается в рамках данных трека (образа магнитной полосы) в открытом виде как от банкомата, так и далее по всем системам. Другое дело, что этот трек (и все другие данные) не передаются по открытой сети (интернет), что призвано минимизировать утечку этих данных.
PVV, обычно, заново не рассчитывается, а просто отдается HSM для проверки, а он уже сам проверяет.