Безопасность платежей в Интернете

31 
стремительно. Только за последние три месяца объем операций по нашим 
картам в Интернете вырос в 2 раза [1]. 
Один из технологических приемов, который применяют российские 
банки-эмитенты для приобретения данной аудитории и повышения 
безопасности деятельности в Интернете, - выпуск виртуальных карт. 
С самого начала внедрения электронной коммерции стало очевидно, что 
методы идентификации владельца карты, применяемые в обычных 
транзакциях, являются неудовлетворительными для транзакций в интернет -
торговле.
Всюду далее под протоколом в интернет - торговле понимается алгоритм, 
определяющий порядок взаимодействия участников интернет - торговли 
(владельца карты, торгового предприятия, обслуживающего банка, банка - 
эмитента и центра сертификации) и форматы сообщений, которыми участники 
интернет - торговли обмениваются друг с другом с целью обеспечения 
процессов авторизации и расчетов. 
Действительно, при совершении операции покупки в физическом 
магазине продавец имеет возможность рассмотреть предъявляемую для 
расчетов пластиковую карту на предмет ее соответствия требованиям 
платежным системам (в частности, проверить наличие голограммы, 
специальных секретных символов, сверить подпись на панели подписи и 
торговом чеке и т. п.). Кроме того, продавец может потребовать от покупателя 
документ, удостоверяющий его личность. Все это делает мошенничество по 
поддельной карте достаточно дорогим мероприятием. 
В случае транзакции в интернет - торговле все, что требуется от 
мошенника - знание реквизитов карты. Затраты, связанные с изготовлением 
поддельной физической карты, в этом случае не требуются. Безусловно, это не 
может не привлечь внимание криминала к этому типу коммерции, свидетелями 
чему мы становимся уже сегодня [1]. 
В мире пластиковых карт с магнитной полосой самым надежным 
способом защиты транзакции от мошенничества является использование PIN - 
кода для идентификации владельца карты его банком - эмитентом. Секретной 
информацией, которой обладает владелец карты, является PIN - код. Он 
представляет собой последовательность, состоящую из 4 - 12 цифр, известную 
только владельцу карты и его банку - эмитенту. PIN - код применяется всегда 
при проведении транзакций повышенного риска, например, при выдаче 
владельцу карты наличных в банкоматах. Выдача наличных в банкоматах 
происходит без присутствия представителя обслуживающего банка (ситуация 
похожа на транзакцию в интернет -торговле). Поэтому обычных реквизитов 
карты для защиты операции "снятие наличных в банкомате" недостаточно и 
используется секретная дополнительная информация - PIN - код [1].
Более того, общая тенденция развития платежных систем - более 
активное использование PIN - кода для операций "покупка" по дебетовым 
картам. 

32 
Казалось бы, использование подобного идентификатора могло бы помочь 
решить проблему безопасности в интернет - торговле, однако это не так. К 
сожалению, в приложении в интернет -торговле этот метод в классическом 
виде неприменим [1].
Действительно, использование PIN - кода должно производиться таким 
образом, чтобы этот секретный параметр на всех этапах обработки транзакции 
оставался зашифрованным (PIN - код должен быть известен только владельцу 
карты и ее эмитенту). В реальном мире это требование реализуется за счет 
использования в устройствах ввода транзакции специальных физических 
устройств, называемых PIN - PAD и содержащих Hardware Security Module - 
аппаратно-программные устройства, позволяющие хранить и преобразовывать 
некоторую информацию весьма надежным способом. Эти устройства хранят 
специальным способом защищенный секретный коммуникационный ключ, 
сгенерированный обслуживающим банком данного торгового предприятия. 
Когда владелец карты вводит значение PIN - кода, оно немедленно закрывается 
(шифруется) 
коммуникационным 
ключом 
и 
отправляется 
внутри 
авторизационного запроса на хост обслуживающего банка. 
Точнее говоря, шифруется не сам PIN - код, а некоторый электронный 
"конверт", в который код помещается. На хосте обслуживающего банка 
зашифрованный идентификационный код перекодируется внутри Hardware 
Security Module хоста (хост обслуживающего банка также имеет свое 
устройство шифрования) в блок, зашифрованный на коммуникационном ключе 
платежной системы, и передается в сеть для дальнейшего предъявления 
эмитенту. По дороге к эмитенту PIN - код будет преобразовываться еще 
несколько раз, но для наших рассуждений это не важно. Важно другое - для 
того чтобы следовать классической схеме обработки PIN-кода, каждый 
владелец карты должен хранить криптограммы коммуникационных ключей 
всех обслуживающих банков, что на практике невозможно.
Классическую схему можно было бы реализовать с помощью применения 
асимметричных алгоритмов с шифрованием PIN - кода владельца карты 
открытым ключом торгового предприятия. Однако для представления PIN - 
кода в платежную сеть его необходимо зашифровать, как это принято во всех 
платежных системах, симметричным ключом [1]. 
Существует другое, неклассическое решение по использованию PIN - 
кода. Например, можно на компьютере владельца карты шифровать PIN - код 
плюс некоторые динамически меняющиеся от транзакции к транзакции данные 
на ключе, известном только эмитенту и владельцу карты. Такой подход 
потребует решения задачи распределения секретных ключей. Эта задача 
является весьма непростой (очевидно, что у каждого владельца карты должен 
быть свой индивидуальный ключ), и если уж она решается, то использовать ее 
решение имеет смысл для других, более эффективных по сравнению с 
проверкой PIN - кода методов аутентификации владельца карты.
В то же время идея проверки PIN - кода была реализована для повышения 
безопасности транзакций в интернет -торговле по картам, БД которых хранится 

33 
на хосте процессора STB CARD. В общих чертах STB CARD реализует 
следующую схему. Владельцы карт, эмитенты которых держат свою БД 
карточек на хосте STB CARD, могут получить дополнительный PIN - код, 
называемый ПИН2. Этот код представляет собой последовательность из 16 
шестнадцатеричных цифр, которая распечатывается в PIN - конверте, 
передаваемом 
владельцу 
карты 
(специальный 
бумажный 
конверт, 
используемый банком - эмитентом для хранения в нем секретной информации, 
относящейся к эмитированной карте), и вычисляется эмитентом с помощью 
симметричного алгоритма шифрования, примененного к номеру карты и 
использующего секретный ключ, известный только эмитенту карты.
Далее во время проведения транзакции в интернет -торговле на одном из 
ТП, обслуживаемом банком STB CARD, у владельца карты в процессе 
получения данных о клиенте запрашивается информация по ПИН2. Клиент 
вводит значение кода ПИН2 в заполняемую форму и возвращает ее торговому 
предприятию [1]. 
Здесь нужно сделать важное замечание относительно сказанного ранее. 
Владелец карты в действительности ведет диалог в защищенной SSL - сессии 
не с торговым предприятием, а с виртуальным POS - сервером, через который 
работает торговое предприятие (система STB CARD в настоящее время 
использует сервер Assist).
Возвращаясь к схеме STB CARD, отметим, что, конечно же, в 
заполненной клиентом форме ПИН2 не содержится, а в действительности все 
выглядит следующим образом: ТП (точнее, сервер Assist), определив, что имеет 
дело с картой банка STB CARD, передает владельцу карты форму, содержащую 
подписанный Java - апплет, реализующий некоторый симметричный алгоритм 
шифрования. При этом ПИН2 играет роль секретного ключа этого алгоритма 
шифрования, а шифруемые данные получаются в результате применения хэш - 
функции к номеру карты, сумме и дате транзакции, а также случайному числу 
x, генерируемому торговому предприятию. Таким образом, в заполненной 
владельцем карты форме присутствует только результат шифрования 
перечисленных выше данных о транзакции на ключе ПИН2.
Далее торговое предприятие формирует авторизационное сообщение, 
передаваемое на хост обслуживающего банка, содержащее помимо 
"стандартных" данных о транзакции еще результат шифрования и случайное 
число x.
Эмитент карты, получив сообщение торгового предприятия, по номеру 
карты вычисляет значение ПИН2, и далее по номеру карты, сумме и дате 
транзакции, а также по случайному числу x, вычисляет результат шифрования 
этих данных на ключе ПИН2. Если полученная величина совпадает с 
аналогичной величиной из сообщения торгового предприятия, верификация 
PIN - кода считается выполненной успешно. В противном случае транзакция 
отвергается [1]. 
Таким образом, технология проверки PIN - кода, принятая в системе STB 
CARD, в действительности обеспечивает не только динамическую 

34 
аутентификацию клиента, но еще и гарантирует "сквозную" целостность 
некоторых данных о тр анзакции (сумма транзакции, номер карты). Под 
"сквозной" целостностью здесь понимается защита от модификации данных на 
всем протяжении их передачи от клиента до банка - эмитента.
Минусы данного подхода состоят в следующем:
1 Для реализации схемы проверки значения PIN - кода необходимо, 
чтобы торговое предприятие "умело" формировать соответствующую форму с 
Java - апплет, что сразу сужает область применения схемы в относительно 
небольшом множестве торговых предприятий. 
2 Использование длинного (шестнадцать шестнадцатеричных цифр) 
ключа делает его применение на практике крайне неудобным для владельца 
карты.
3 Защита от подставки (форма, запрашивающая ПИН2, предоставляется 
владельцу карты не торгового предприятия, а мошенником, желающим узнать 
значение ПИН2) основана на надежности аутентификации клиентом сервера 
торгового предприятия, а также на подписывании апплета секретным ключом 
сервера торгового предприятия. Поскольку нарушение обеих защит приводит 
только к появлению на экране монитора владельца карты соответствующего 
предупреждения, сопровождаемого вопросом - продолжить сессию или нет, то 
особенно доверять этим формам защиты не стоит [1].
Обеспечить надежную защиту от подставки можно с помощью 
электронного бумажника клиента (специального программного обеспечения, 
которое клиент может "скачать" на свой компьютер с некоторого сайта), 
заменяющего по своей функциональности Java - апплет в форме торгового 
предприятия. Такой электронный бумажник может использовать сколь угодно 
мощные средства шифрования данных. Секретные ключи владельца карты 
могут держаться в порядке повышения надежности их хранения на диске 
компьютера, дискете или микропроцессорной карте. Доступ к электронному 
бумажнику должен производиться по паролю его владельца.
В результате проведенного анализа платежные системы сформировали 
основные требования к схемам проведения транзакции в интернет-торговле, 
обеспечивающим необходимый уровень ее безопасности. Эти требования 
сводятся к следующему: 
1 Аутентификация 
участников 
покупки 
(покупателя, 
торгового 
предприятия и его обслуживающего банка). Под аутентификацией покупателя 
(продавца) понимается процедура, доказывающая (на уровне надежности 
известных криптоалгоритмов) факт того, что данный владелец карты 
действительно является клиентом некоторого эмитента - участника 
(обслуживающего банка - участника) данной платежной системы. 
Аутентификация обслуживающего банка доказывает факт того, что банк 
является участником данной платежной системы [1]. 
2 Реквизиты платежной карты (номер карты, срок ее действия, 
CVC2/CVV2, и т. п.), используемой при проведении транзакции интернет - 
торговли, должны быть конфиденциальными для торгового предприятия.

35 
3 Невозможность отказа от транзакции для всех участников транзакции 
интернет - торговли, то есть наличие у всех участников неоспоримого 
доказательства факта совершения покупки (заказа или оплаты).
4 Гарантирование магазину платежа за электронную покупку - наличие у 
торгового предприятия доказательства того, что заказ был выполнен.
Правовая база регулирования отношений интернет торговли в России 
достаточно невелика, отсюда и многочисленные факты мошенничества в 
Интернете и как следствие, недоверие людей к системам оплаты. В настоящее 
время законодательную базу составляют два таких основных закона как 
Федеральный закон «Об электронно-цифровой подписи» [1] и Федеральный 
закон «Об электронной торговле» [1].Целью Федерального закон «Об 
электронно-цифровой подписи» является обеспечение правовых условий для 
использования электронной цифровой подписи в процессах обмена 
электронными данными, при соблюдении которых электронная цифровая 
подпись признается юридически равнозначной подписи физического лица, в 
том числе полномочного представителя юридического лица. Целью же 
Федерального закон «Об электронной торговле» является обеспечение 
правовых условий для электронной торговли: закрепление прав и обязанностей 
лиц, осуществляющих электронную торговлю, определение правил совершения 
сделок с использованием электронных документов, подписанных аналогами 
собственноручной подписи, а также признание электронных документов в 
качестве судебных доказательств.

жүктеу/скачать 3.35 Mb.

Достарыңызбен бөлісу: