Сценарий 3 — Послать сниференные данные еще раз эмулируя Apple Pay. Конечно терминал посылает 9F37 Unpredictable Number, но SDA, DDA, CDA аутентификации не поддерживаются.
В том случае интересно как у ApplePay проверятся аутентификация карты(телефона)?
Уникальность транзакции проверяется по AC криптограмме и можно понадется (а так говорят бывает) что AC криптограмму ApplePay процессинг не проверяет.
Структура IAD различная на разных МПС. Описанна в EMV book 3 C7.2 «Issuer Application Data for Format Code ‘A’ ». Из интересного в ней можно найти «CVR» Card Verification Results, результаты проверок, проведенных картой.
Cryptogram Information Data (CID) — Я не осилил разбор этой структуры, помогите.
Описанна в EMV Book 3 «Table 14: Coding of Cryptogram Information Data ». Карта (телефон) вернула ARQC — что значит запрос на онлайн и без ошибок.
Существует устаревший протокол бесконтактной оплаты в режиме Magnetic Stripe (MSD)
Стоит отметить что MSD и VSDC это варианты VISA приложения. MSD действительно устаревший и эмулирует магнитную карту. Ваше приложение — VSDC.
Протокол MasterCard немного отличается, но в целом похож.
Интересно что бесконтактный MasterCard достаточно сильно отличается от безконтакной Visa и практически полностью идентичен контактному протоколу.
В AIP содержится важная информация о поддерживаемых методах аутентификации (SDA,CDA,DDA) платежа. Почему в моем случае все эти флаги равны нулю — я не понимаю.
Т.к. используется технология токинизации и только онлайн, что подтверждается виртуальной картой и начиличем EMV Tokenisation (Payment Account Reference (PAR)), аутентификация по SDA,CDA,DDA похоже становится не нужной. Также как запрос пина и т.д.
По вызову комманды GET PROCESSING OPTIONS карта инкрементирует Application Transaction Counter, который по достижению лимита 0xFFFF или 0x7FFF безвозвратно заблокирует приложение… т.е. уничтожит карту. В итоге получаем нецелевое использование платежного приложения которое уменьшает срок жизни карты.
Вцелом чтение и манипулирования PAN или TRACK в открытом виде и не в платежном терминале (и не следуя инструкциям PCI/PA-DSS) компроментирует важные платежные реквизиты владельца карты. Заодно вызывая повышенный интерес взломать данное решение.
APDU-команды (что они значат вообще? Хз, нужно прочитать)
Это комманды ReadRecord. GET PROCESSING OPTIONS в ответе возвращает AIP и AFL. ALF (Application File Locator) содержит данные о рекордах, которые находятся на карте.
Стоит наверное уточнить, что речь идет о POS-терминалах — десктопных приложениях на обычных станциях с ОС Windows. В штатах такие приложения работают преимущественно с магнитной полосой, данные которой несложно спарсить с виртуальной памяти во время их обработки. Для наших регионов это не актуально.
После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы. Ответственность по SDA, вроде как, делят эмитент и эквайер. Один такую карту выпустил, второй провел офлайн операцию по такой карте.
Или, перефразируя, приложение с off-line PIN должно быть с DDA/CDA аутентификацией. SDA как единственный метод офлайн аутентификации давно устарел (в отдельных регионах запрещенный к выпуску) и риски по SDA офлайн операциям, насколько я знаю, лежат на эквайервах и эмитентах.
Насчет CVV2 я не скажу. По аналогии с первым СVV (который на магнитной карте) скорее всего в расчете участвуют номер карты и срок действия. На основании этих данных и секретного ключа, по 3DES рассчитывается подпись. Далее нехитрыми манипуляциями получают 3х-значный код. Алгоритмы и данные для разных платежных систем разные и к сожалению я их точно не знаю (и насколько я помню они под NDA).
В пункте 6. Проверка держателя карты CVM есть небольшое описание. Также вот хорошая статья. Пин имеет больший приоритет над подписью и после его ввода проверять подпись не нужно. У вас все продавцы требуют пин и подпись в разных торговых точках?
Да такое возможно. Во многих дуальных картах можно включать/выключать бесконтактную часть приложения настройками карты. При очередной операции в терминале или банкомате, банк мог прислать обновление настроек приложения в скриптовой команде, и таким образом включить бесконтактную часть.
Со скомпрометированным юрлицом будет другой разговор. Хватит нескольких запросов ведущих в одну и ту же платежную точку.
Да и прав mmMike — как то это мелко при большой сложности. Оформить юрлицо, пройти 10 кругов ада получения терминала, долго искать карты у которых есть лимиты на операции без пина, что-бы потом красть по 1000 рублей. Затраты не отобьются.
СМС оповещения помогают заметить все списания по счету.
Все верно, для любой скриптовой команды изменяющей данные приложения потребуется состояние ONLINE или SCRIPT (выход в онлайн с любым результатом). Через AAC в первом GenerateAC просто получается быстрее.
Нет смысла выполнять второй GenerateAC, потому что не нужно оценивать риски (это не платежная операция, как было сказано выше) и не нужно аутентифицировать картой банк через ARPC (потому что данные придут, как минимум макированые на ключе эмитента).
Чип позволяет провести аутентификацию карты, то есть проверить ее подлинность, и оценить риски транзакции. Вы говорите о верификации пользователя карты.
Стоит уточнить что «защищенный способ верификации держателя карты», но не аутентификации карты. По большому счету, офлайн-пин больше предназначен для офлайн-транзакций, чем общий способ верификации. В итоге не корректно говорить о том, что какой-то из способов проверки пинов более защищенный и современный. У них разные задачи.
Этот парень, похоже, просто вез терминал в руках и неожиданно стал «звездой» интернета. Можно еще с натяжкой поверить что он считывал mifare проездные платежным терминалом. Далеко не все бесконтактные карты можно просто так считать, и даже если считали — делать с этими данными практически нечего. По поводу проведения таким способом транзакций приведу цитату из указанного вами источника:
«Сделать терминал, который будет считывать данные карты «из кармана» клиента, теоретически возможно. Но этот терминал должен иметь «на борту» криптографические ключи, полученные у банка-эквайера и платежной системы. Ключи выдаются по договору с юридическим лицом, то есть с банком-эквайером. Таким образом, мошенничество будет легко обнаружить и расследовать»
У вас просят подписать чек? Если для вашей карты не нужно вводить пин, скорее всего в приоритете CVM стоит проверка подписи. Для этого и требуют ID, на них обычно есть ваша подпись.
В том случае интересно как у ApplePay проверятся аутентификация карты(телефона)?
Уникальность транзакции проверяется по AC криптограмме и можно понадется (а так говорят бывает) что AC криптограмму ApplePay процессинг не проверяет.
Структура IAD различная на разных МПС. Описанна в EMV book 3 C7.2 «Issuer Application Data for Format Code ‘A’ ». Из интересного в ней можно найти «CVR» Card Verification Results, результаты проверок, проведенных картой.
Описанна в EMV Book 3 «Table 14: Coding of Cryptogram Information Data ». Карта (телефон) вернула ARQC — что значит запрос на онлайн и без ошибок.
Стоит отметить что MSD и VSDC это варианты VISA приложения. MSD действительно устаревший и эмулирует магнитную карту. Ваше приложение — VSDC.
Интересно что бесконтактный MasterCard достаточно сильно отличается от безконтакной Visa и практически полностью идентичен контактному протоколу.
Т.к. используется технология токинизации и только онлайн, что подтверждается виртуальной картой и начиличем EMV Tokenisation (Payment Account Reference (PAR)), аутентификация по SDA,CDA,DDA похоже становится не нужной. Также как запрос пина и т.д.
Вцелом чтение и манипулирования PAN или TRACK в открытом виде и не в платежном терминале (и не следуя инструкциям PCI/PA-DSS) компроментирует важные платежные реквизиты владельца карты. Заодно вызывая повышенный интерес взломать данное решение.
Это комманды ReadRecord. GET PROCESSING OPTIONS в ответе возвращает AIP и AFL. ALF (Application File Locator) содержит данные о рекордах, которые находятся на карте.
Да и прав mmMike — как то это мелко при большой сложности. Оформить юрлицо, пройти 10 кругов ада получения терминала, долго искать карты у которых есть лимиты на операции без пина, что-бы потом красть по 1000 рублей. Затраты не отобьются.
СМС оповещения помогают заметить все списания по счету.
Нет смысла выполнять второй GenerateAC, потому что не нужно оценивать риски (это не платежная операция, как было сказано выше) и не нужно аутентифицировать картой банк через ARPC (потому что данные придут, как минимум макированые на ключе эмитента).
«Сделать терминал, который будет считывать данные карты «из кармана» клиента, теоретически возможно. Но этот терминал должен иметь «на борту» криптографические ключи, полученные у банка-эквайера и платежной системы. Ключи выдаются по договору с юридическим лицом, то есть с банком-эквайером. Таким образом, мошенничество будет легко обнаружить и расследовать»