Очень интересно было бы послушать описание механизмов безопасности с объяснением, почему сделано так; вот как вы сейчас рассказали. А то ведь мало знать механизмы, нужно понимать, зачем они были придуманы.
Ну и принципиально процедуру проверки это не меняет. Кстати, хранятся у нас действительно PVV, о чем в названиях полей написано. Просто не знал таких тонкостей, поэтому рассказал так, чтобы понятно всем было.
Конечно. Но что мешает хранить два ПИН-блока (зашифрованных ПИН) — верный и ложный? Когда приходит ПИН-блок от банкомата, проверяем его сначала на равенство верному, если не прошло — на равенство ложному. Если и так не прошло, значит вообще левый.
п.4 В принципе да, но я бы разделил ПО для банкоматов по другому.
Ну если делить по протоколам, то надо каждый вид банкомата в отдельную группу выводить. Я же постарался сделать разделение по фундаментальному признаку.
п.3 На начальном этапе обработки карты ПО банкомата читает номер карты и по ее первым цифрам (это не обязательно BIN) может глобально переключится на ветку в сценарии работы и настроек.
Дополню. Тут даже не обязательно, чтобы это переключение делал банкомат. Протокол NDC/DDC также позволяет в любом ответе обновить экраны, которые банкомат показывает — но для поддержки локализации это, естественно, хуже, чем один раз загрузить все нужные экраны и просто выбирать нужные на стороне банкомата. В случае инкассации транзакция уйдет в процессинг как обычно, а он уже выдаст команду на закрытие и прочее, необходимое для инкассации.
Но администраторы сценариев банкоматов очень ленивые FIT-таблицы практически не используются.
Думаю, тут дело в том, что таких клиентов очень мало. Да и сценарии банк в основном не пишет сам с нуля, а максимум, чуток подгоняет под себя — он же не держит у себя людей для этой цели — сценарий один раз написал и он работает. Например, базовые сценарии мы сами предоставляем, да еще и сопровождаем (за денюжку, я думаю).
Пожалуй, уточню. ПИН, естественно, уходит процессингу, иначе как он сможет его проверить? Другое дело, что он никогда не уходит в чистом виде — он всегда зашифрован рабочим ключом банкомата. А этот ключ может меняться так часто, как нужно. Правда, тут есть некоторые ограничения для некоторых видов банкоматов — например, NDC/DDC необходимо закрыть (перевести в состояние Out-Of-Service), чтобы поменять ключи.
Вы имели ввиду, наверное, что чистый ПИН практически никогда не циркулирует в приложении — если он вводится через ПИН-пад, то он там сразу шифруется и наружу отдается в виде ПИН-блока.
У нас в системе так и называется :). Ну, может про сокращение iPIN ошибся, и это действительно не Illegal/Invalid PIN, а Internet PIN. Посмотрю, как это поле называется в английской версии.
Всегда пожалуйста :). Боюсь, ничего про серверную часть рассказать не смогу. Я работал только с эквайрингом, и то, только той его части, которая связана с банкоматами — это настройки банкоматов (свойства, применяемые к ним на серверной части), конфигурации банкоматов (специфические настройки, прогружаемые на банкомат, например, это сценарии взаимодействия), сами банкоматы.
По большему счету, ничего интересного там нет — сплошная нудятина: есть запрос от банкомата, его нужно переложить в транзакционный запрос системы и скормить транзакционному ядру. Потом получить от него ответ и преобразовать в ответ банкомату. Единственное, что тут может быть интересно — это сам механизм описания бинарных сообщений, чтобы с ними было удобно работать. Может, когда-нибудь опишу его подробнее. Сейчас просто нет достаточного материала.
Я думаю, в случае зеркального ПИН-а просто не будет работать функция ложного ПИН-а, если он действительно по умолчанию предлагается как реальный наоборот. Может, если время будет, гляну, как у нас проверка сделана.
В банковской сфере почти все на джаве (как минимум, серверная часть).
В нашей системе мониторинг и обработка транзакций выполняются одним и тем же сервером (не физически, конечно, сервер распределенный. То есть не совсем так. Где именно что выполняется — хрен его знает. Программно мониторинг и обработка транзакций — один сервер). Мониторинг — просто один еще модуль сервера :).
Некоторые банкоматы умеют пинговать сервер раз в какой-то промежуток времени (Triton), другие рапортуют только при изменениях (NDC/DDC, Wincor — который является по протоколу клоном первых двух, с небольшими отличиями), у третьих мы сами решаем, что и когда нам слать (банкоматы на платформе Kalignite).
Во время отсчета может случиться, что одну купюру замяло, или она слиплась с другой, и банкомат отбраковывает всю пачку. Автоматически он не пытается набрать ее заново, а просто посылает на хост аппаратную ошибку о невозможности выдать указанную сумму. А там хост уже может сделать реверс или послать команду на выдачу во второй раз — но для этого ему нужно будет заново пересчитать покупюрную сумму. А она обычно считается во время выполнения транзакции и прикрепляется к ней, так что скорее всего будет реверс.
Также банкомат может послать реверс сам сразу после сообщения о неудачной выдачи. Тут уж реверс придется делать.
Карта у вас вернулась потому, что данный сценарий не различает эту ошибочную ситуацию от любой другой и по сценарию при любой ошибке карту выплевывает от греха подальше (т.к. это могла быть и ошибка CardReader-а). Перезагрузка обычно делается для того, чтобы попытаться исправить ошибку, если она связана с программной частью. Может сценарий у этого был настроен так, что при каждой ошибке он в перезагрузку отправляется, а может ошибка была довольно серъезной. Kalignite, например, так делает.
Другое дело, что если в банкомате физически нет запрошенной суммы на момент начала операции — тогда это косяк создателей сценария — могли бы сразу предупредить об этом.
Может еще быть так, что физически сама сумма есть, но выдать ее имеющимися номиналами невозможно, причем, так как банкомат в большинстве случаев сам не рассчитывает покупюрный расклад, до того, как пошлется запрос на хост, это определить невозможно.
Ну, я больше с программной частью связан. Всех тонкостей не знаю, т.к. работаю только с тем, что в спецификациях написано — а про проскакивание купюр мимо чего-то там, естественно, ничего нет. Вообще, разве это возможно? Ну, если не учитывать неплотно прилегающее устройство. И что такое «тампер»? Не встречал это слово.
Ну и принципиально процедуру проверки это не меняет. Кстати, хранятся у нас действительно PVV, о чем в названиях полей написано. Просто не знал таких тонкостей, поэтому рассказал так, чтобы понятно всем было.
Конечно. Но что мешает хранить два ПИН-блока (зашифрованных ПИН) — верный и ложный? Когда приходит ПИН-блок от банкомата, проверяем его сначала на равенство верному, если не прошло — на равенство ложному. Если и так не прошло, значит вообще левый.
Ну если делить по протоколам, то надо каждый вид банкомата в отдельную группу выводить. Я же постарался сделать разделение по фундаментальному признаку.
Дополню. Тут даже не обязательно, чтобы это переключение делал банкомат. Протокол NDC/DDC также позволяет в любом ответе обновить экраны, которые банкомат показывает — но для поддержки локализации это, естественно, хуже, чем один раз загрузить все нужные экраны и просто выбирать нужные на стороне банкомата. В случае инкассации транзакция уйдет в процессинг как обычно, а он уже выдаст команду на закрытие и прочее, необходимое для инкассации.
Думаю, тут дело в том, что таких клиентов очень мало. Да и сценарии банк в основном не пишет сам с нуля, а максимум, чуток подгоняет под себя — он же не держит у себя людей для этой цели — сценарий один раз написал и он работает. Например, базовые сценарии мы сами предоставляем, да еще и сопровождаем (за денюжку, я думаю).
Вы имели ввиду, наверное, что чистый ПИН практически никогда не циркулирует в приложении — если он вводится через ПИН-пад, то он там сразу шифруется и наружу отдается в виде ПИН-блока.
По большему счету, ничего интересного там нет — сплошная нудятина: есть запрос от банкомата, его нужно переложить в транзакционный запрос системы и скормить транзакционному ядру. Потом получить от него ответ и преобразовать в ответ банкомату. Единственное, что тут может быть интересно — это сам механизм описания бинарных сообщений, чтобы с ними было удобно работать. Может, когда-нибудь опишу его подробнее. Сейчас просто нет достаточного материала.
В нашей системе мониторинг и обработка транзакций выполняются одним и тем же сервером (не физически, конечно, сервер распределенный. То есть не совсем так. Где именно что выполняется — хрен его знает. Программно мониторинг и обработка транзакций — один сервер). Мониторинг — просто один еще модуль сервера :).
Некоторые банкоматы умеют пинговать сервер раз в какой-то промежуток времени (Triton), другие рапортуют только при изменениях (NDC/DDC, Wincor — который является по протоколу клоном первых двух, с небольшими отличиями), у третьих мы сами решаем, что и когда нам слать (банкоматы на платформе Kalignite).
Также банкомат может послать реверс сам сразу после сообщения о неудачной выдачи. Тут уж реверс придется делать.
Карта у вас вернулась потому, что данный сценарий не различает эту ошибочную ситуацию от любой другой и по сценарию при любой ошибке карту выплевывает от греха подальше (т.к. это могла быть и ошибка CardReader-а). Перезагрузка обычно делается для того, чтобы попытаться исправить ошибку, если она связана с программной частью. Может сценарий у этого был настроен так, что при каждой ошибке он в перезагрузку отправляется, а может ошибка была довольно серъезной. Kalignite, например, так делает.
Другое дело, что если в банкомате физически нет запрошенной суммы на момент начала операции — тогда это косяк создателей сценария — могли бы сразу предупредить об этом.
Может еще быть так, что физически сама сумма есть, но выдать ее имеющимися номиналами невозможно, причем, так как банкомат в большинстве случаев сам не рассчитывает покупюрный расклад, до того, как пошлется запрос на хост, это определить невозможно.