Еще раз уточню. Не в общем абстрактном случае, а именно в случае on-line авторизации
При выполнении авторизации транзакции на хосте эмитента, не важно с точки зрения скорости обслуживания клиента, какой вариант проверки PIN используется.
Мне было бы очень интересно услышать Ваше представление об порядке выполнении платежной транзакции в режиме on-line в POS терминале для EMV карты, включая запросы к хосту и действия хоста на запросы.
Порядок выполнения по шагам + оценка времени каждого шага.
В двух вариантах: c off-line PIN и on-line PIN.
Ну очень интересно, где по вашему мнению возникает «гораздо быстрее нежели онлайн».
Если уж высказали так уверено свое мнение, то его нужно обосновывать…
После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы.
Хм… по секрету скажу (не тыкая пальцем в конкретных...), что TC off-line транзакции обычно мало кто проверяет.
второй провел офлайн операцию по такой карте.
Не так все просто.
Карта с SDA… или карта DDA/CDA
В TVR нет ни одного бита позволяющего различить эти два варианта.
Terminal Action Code — по это все что обычно конфигурируется (можно сконфигурировать) в стандартном EMV терминале (*).
(*) — остальные параметры: Лимиты, публичные ключи и пр. к этой теме отношения не имеют.
И только этим эквайрер может повлиять на принятие решение терминалом.
Все остальное — не стандарт и частные/опциональные кастомизации ПО терминала.
Все же в EMV все очень четко прописано.
Так что эквайрер тогда становится (равная ответственность) невинной жертвой, действующей по правилам!
А насчет равной ответственности… Ссылку на правила Visa/MC, если можно.
И если знаете вендора ПО EMV терминала, где можно указать что SDA только on-line, то пожалуйста поделитесь.
В данном случае, разницы практически никакой (всего одно «действующее» правило связанное с фактической cardholder аутентификацией).
и если CVM по правилу "_203" будет failed, то бит 40 влияет только на то какой будет CVM бит в TVR,
и какая разница, если все одно транзакция по этой карте без on-line PIN запрещена?
может быть даже лучше, если терминал сразу откажет (по маске в TVR) чем пойдет на хост за отказом.
Впрочем, если хочется фиксировать все попытки провести операцию… то почему бы и нет.
в общем не однозначно. и то и то имеет право на жизнь.
главное для всех комбинаций в CVM тщательно расписать все сценарии и настойки хоста, что бы случайно не осталось «дырок» и нежелательных вариантов.
Хотя для такой карты сценарий хоста по CVM прост: нет успешной проверки PIN блока — нет транзакции.
эквайрер… chargeback? после проверки криптограммы? (крипторамму может только эмитент проверить)
И не совсем понял… зачем это эквайреру. Товар отдан. Транзакция по EMV карте по всем правилам ПС. Ничего у эквайрера не нарушено.
Не магнитка. никаких «смещений отвественности». Эмитент обязан ему возместить…
А дальше: TC транзакции проверяет (а чаще всего никто не проверяет) эмитент. И он что? «автоматически» компенсирует потери клиенту? слабо верится.
Все проблемы по подаче заявления и т.п. ложатся на клиента. Это я имею в виду «замучаешься».
Именно «замучаешься», а не «невозможно»
В сущности вопрос, лично у меня остается открытым, как такие диспуты решаются в ПС. По идее, это же эмитент выпустил карту с таким профилем и дырой в безопасности.
CVM входит в подпись. Хотя бы и SDA…
Т.е. если в исходной карте не предусмотрен off-line PIN в CVM, то и в дубле его не будет.
Ну и терминал его никогда у карты не спросит. и остается только on-line PIN.
даже подпись клиента на чеке в CVM не так плохо как off-line PIN в CVM на клоне карты.
А вот если есть…
Терминал с off-line транзакцией и без PIN — ну это… например оплата туалета жд. вокзале (в Осло кажется с таким курьезом столкнулся) или… платная дорога.
А вот off-line операцию с off-line PIN вполне могу себе представить как разрешенную в каком ни будь супермаркете на сумму до 50Euro.
И мне было бы обидно кормит на 50Euro «несчастного беженца» которому местная диспора продала клон моей карты, сделанный по украденным в банке данным.
И это не магнитка… с EMV транзакцией замучишься доказывать что «не я там был».
Приложение карты без DDA|CDA не должна поддерживать off-line PIN вообще. Иначе она легко клонируется.
Банк, выпускающий такие карты сознательно подставляет клиентов. Клиент даже доказать ничего не сможет если что.
Т.е. Вы хотите сказать, что у Сбера выдаются карты без DDA(CDA) и off-line PIN в CVM??!!! Да еще с нулевыми XY
Если это так, то у меня нет слов! Такие «дыры» в безопасности дискредитирую саму технологию. Хотя она не причем.
Явно у Сбера сознательный выбор, подставляющий невинных клиентов.
Если кто такую карту втихушку продублирует — это даже не магнитку скопировать. Это хуже!
Операции без PIN по магнитке хотя бы весьма ограничены без знания PIN. А тут клон, который «выглядит» гораздо защищенней чем магнитка, а по сути…
И что бы выпустить клон достаточно сосем не много
Любого низкуровнего лога (DGI данных персонализации, лога транзакции на уровне APDU или уже разобранных данных и т.д.) или 2 сек доступа к карте (засунуть в ридер)
Вы точно уверенны, что такие карты есть?
Постараюсь найти такую карту по знакомым с картами Сбер, что бы иметь доказательство…
Все же ссылаться на «слышал» для таких серьезных обвинений это мало.
Поскольку к Сберу отношения не имею, то смотрел (ради любопытства когда то) только свою личную Сберовскую карту. Был и есть честный MChip select c CDA…
Я говорил про POS терминалы.
В масштабах большей инфраструктуры, 2-20 Euro на загрузку POS терминала — это не мало
(по разным оценкам и по разным технологиями и разных странах… в сумму входят и зарплаты сотрудникам… чел./часы и пр.)
А накладные расходы на загрузку ключей в криптомодуль клавиатуры банкомата это малая часть расходов по установке и настройке банкоматов.
Разница, на общем фоне затрат на установку железки, между классической загрузкой компонент симметричных ключей с бумажек и более продвинутыми вариантами не столь принципиальна по стоимости.
Да и банкомат по определению (требования ПС) с on-line PIN. вариантов нет.
Ну и сети банкоматов обычно на порядок меньше чем POS (в общем случае)
Ситуация когда «карта» а точнее прокси чип, имплантированный в украденную карту, выдал SW:9000 (ok) на проверку off-line PIN, а хост эмитента почему то проигнорировал значение в CVR и подтвердил транзакцию, наверное это проблема разработчиков ПО эмитентского хоста… Ну и банка эмитента заодно.
При этом эквайрер все сделал честно!
Функция (кнопка/пункт меню в интерфейсе банкомата) смены PIN доступна обычно только для «своего» банкомата (банкомат знает про эмитента карты и знает что ему разрешена эта операция).
Если Вы говорите про установку PIN через IVR (телефон) или интернет банк… то новый off-line PIN придет в рамках первой же успешной on-line авторизации по чипу в ЛЮБОМ терминале любого типа.
Ну должен по крайней мере. (были прецеденты, когда промежуточные хосты «резали» скрипт эмитента)
Судя по нашумевшей в узких кругах ситуации с перехватом команды проверки PIN (дополнительный чип на карте).
Ошибки бывают и на ПО хоста.
Интересно, кому в таких случаях идет претензия.
Банку эмитенту который разрешил операцию или вендору ПО через суд…
Как то даже не задумывался, содержит ли лицензия на банковский софт типичную фразу насчет отказа от ответственности при использовании ПО.
офлайн-пин больше предназначен для офлайн-транзакций
Очень много инфраструктур POS, где POS терминалы вообще без on-line PIN (Франция… Германия...)
И используется off-line PIN с on-line авторизацией.
Особенно там, где традиционно работали с чиповыми картами (местные не EMV платежные системы а чиповых картах).
Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…
При выполнении авторизации транзакции на хосте эмитента, не важно с точки зрения скорости обслуживания клиента, какой вариант проверки PIN используется.
Порядок выполнения по шагам + оценка времени каждого шага.
В двух вариантах: c off-line PIN и on-line PIN.
Ну очень интересно, где по вашему мнению возникает «гораздо быстрее нежели онлайн».
Если уж высказали так уверено свое мнение, то его нужно обосновывать…
Хм… по секрету скажу (не тыкая пальцем в конкретных...), что TC off-line транзакции обычно мало кто проверяет.
Не так все просто.
Карта с SDA… или карта DDA/CDA
В TVR нет ни одного бита позволяющего различить эти два варианта.
Terminal Action Code — по это все что обычно конфигурируется (можно сконфигурировать) в стандартном EMV терминале (*).
(*) — остальные параметры: Лимиты, публичные ключи и пр. к этой теме отношения не имеют.
И только этим эквайрер может повлиять на принятие решение терминалом.
Все остальное — не стандарт и частные/опциональные кастомизации ПО терминала.
Все же в EMV все очень четко прописано.
Так что эквайрер тогда становится (равная ответственность) невинной жертвой, действующей по правилам!
А насчет равной ответственности… Ссылку на правила Visa/MC, если можно.
И если знаете вендора ПО EMV терминала, где можно указать что SDA только on-line, то пожалуйста поделитесь.
и если CVM по правилу "_203" будет failed, то бит 40 влияет только на то какой будет CVM бит в TVR,
и какая разница, если все одно транзакция по этой карте без on-line PIN запрещена?
может быть даже лучше, если терминал сразу откажет (по маске в TVR) чем пойдет на хост за отказом.
Впрочем, если хочется фиксировать все попытки провести операцию… то почему бы и нет.
в общем не однозначно. и то и то имеет право на жизнь.
главное для всех комбинаций в CVM тщательно расписать все сценарии и настойки хоста, что бы случайно не осталось «дырок» и нежелательных вариантов.
Хотя для такой карты сценарий хоста по CVM прост: нет успешной проверки PIN блока — нет транзакции.
А именно авторизацю транзакции на хосте эмитента.
Или вы имеете в вижу что то другое. Я не понял
В контексте авторизационного запроса эмитенту.
Поясните пожалуйста
Вполне логично. Хуже точно не будет.
И не совсем понял… зачем это эквайреру. Товар отдан. Транзакция по EMV карте по всем правилам ПС. Ничего у эквайрера не нарушено.
Не магнитка. никаких «смещений отвественности». Эмитент обязан ему возместить…
А дальше: TC транзакции проверяет (а чаще всего никто не проверяет) эмитент. И он что? «автоматически» компенсирует потери клиенту? слабо верится.
Все проблемы по подаче заявления и т.п. ложатся на клиента. Это я имею в виду «замучаешься».
Именно «замучаешься», а не «невозможно»
В сущности вопрос, лично у меня остается открытым, как такие диспуты решаются в ПС. По идее, это же эмитент выпустил карту с таким профилем и дырой в безопасности.
Спасибо! буду знать точно теперь. Сбербанк конечно не пинает только ленивый, но это уже перебор у них.
вот такой CVM, как мне кажется только и может быть допустим для карты без DDA/CDA.
00000000 00000000 0203 1F00
Чисто on-line приложения как прямая замена мегнитки.
Т.е. если в исходной карте не предусмотрен off-line PIN в CVM, то и в дубле его не будет.
Ну и терминал его никогда у карты не спросит. и остается только on-line PIN.
даже подпись клиента на чеке в CVM не так плохо как off-line PIN в CVM на клоне карты.
А вот если есть…
Терминал с off-line транзакцией и без PIN — ну это… например оплата туалета жд. вокзале (в Осло кажется с таким курьезом столкнулся) или… платная дорога.
А вот off-line операцию с off-line PIN вполне могу себе представить как разрешенную в каком ни будь супермаркете на сумму до 50Euro.
И мне было бы обидно кормит на 50Euro «несчастного беженца» которому местная диспора продала клон моей карты, сделанный по украденным в банке данным.
И это не магнитка… с EMV транзакцией замучишься доказывать что «не я там был».
экономия 10-100ms на проверку PIN блока в HSM, это не основополагающая причина.
Банк, выпускающий такие карты сознательно подставляет клиентов. Клиент даже доказать ничего не сможет если что.
Если это так, то у меня нет слов! Такие «дыры» в безопасности дискредитирую саму технологию. Хотя она не причем.
Явно у Сбера сознательный выбор, подставляющий невинных клиентов.
Если кто такую карту втихушку продублирует — это даже не магнитку скопировать. Это хуже!
Операции без PIN по магнитке хотя бы весьма ограничены без знания PIN. А тут клон, который «выглядит» гораздо защищенней чем магнитка, а по сути…
И что бы выпустить клон достаточно сосем не много
Любого низкуровнего лога (DGI данных персонализации, лога транзакции на уровне APDU или уже разобранных данных и т.д.) или 2 сек доступа к карте (засунуть в ридер)
Вы точно уверенны, что такие карты есть?
Постараюсь найти такую карту по знакомым с картами Сбер, что бы иметь доказательство…
Все же ссылаться на «слышал» для таких серьезных обвинений это мало.
Поскольку к Сберу отношения не имею, то смотрел (ради любопытства когда то) только свою личную Сберовскую карту. Был и есть честный MChip select c CDA…
В масштабах большей инфраструктуры, 2-20 Euro на загрузку POS терминала — это не мало
(по разным оценкам и по разным технологиями и разных странах… в сумму входят и зарплаты сотрудникам… чел./часы и пр.)
А накладные расходы на загрузку ключей в криптомодуль клавиатуры банкомата это малая часть расходов по установке и настройке банкоматов.
Разница, на общем фоне затрат на установку железки, между классической загрузкой компонент симметричных ключей с бумажек и более продвинутыми вариантами не столь принципиальна по стоимости.
Да и банкомат по определению (требования ПС) с on-line PIN. вариантов нет.
Ну и сети банкоматов обычно на порядок меньше чем POS (в общем случае)
Технически, создать такой профиль персонализации конечно можно.
Но… как то не верю в таких идиотов в банках. Не пуганных идиотов…
Названием банка не поделитесь? страна должна знать своих героев.
При этом эквайрер все сделал честно!
Если Вы говорите про установку PIN через IVR (телефон) или интернет банк… то новый off-line PIN придет в рамках первой же успешной on-line авторизации по чипу в ЛЮБОМ терминале любого типа.
Ну должен по крайней мере. (были прецеденты, когда промежуточные хосты «резали» скрипт эмитента)
Зачем дебетовым карточным продуктам возможность обслуживаться в off-line?
опечатка…
Ну и вдогонку. на чисто On-line картах зачастую даже SDA не делают. Вполне нормальный вариант.
Ошибки бывают и на ПО хоста.
Интересно, кому в таких случаях идет претензия.
Банку эмитенту который разрешил операцию или вендору ПО через суд…
Как то даже не задумывался, содержит ли лицензия на банковский софт типичную фразу насчет отказа от ответственности при использовании ПО.
Если это даже правилами запрещено для таких продуктов.
Рекомендованные профили, в которых нет DDA есть у всех платежных систем.
Очень много инфраструктур POS, где POS терминалы вообще без on-line PIN (Франция… Германия...)
И используется off-line PIN с on-line авторизацией.
Особенно там, где традиционно работали с чиповыми картами (местные не EMV платежные системы а чиповых картах).
Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…