У даній статті будуть розглянуті різні аспекти безпеки технології віртуальних карт (e-card), створеної спеціально для ведення розрахунків через мережу. Ідея віртуальної карти (е-card) заснована на тому, що під час проведення CNP-транзакції (CPN-Cardholder Not Present — операція купівлі за пластиковою карткою, у момент здійснення якої клієнт особисто не присутній особисто в торговій точці, а повідомляє їй реквізити своєї картки, необхідні для проведення авторизації) пластикова картка як фізичний об’єкт не застосовується. Використовуються лише реквізити карти, і зовсім необов’язково, щоб вони були нанесені на пластик. Тому можна виділити окремі призначені спеціально для електронної комерції номери карток із супутніми їм реквізитами і «прив’язати» до таких віртуальних картах рахунки з невеликим залишком. У цьому випадку клієнт буде застрахований від великих втрат, пов’язаних з ризиком шахрайства.

Таким чином, сенс віртуальної карти полягає в тому, щоб психологічно «розкріпачити» клієнта при здійсненні електронних покупок. Дійсно, карта, якою користується покупець, пов’язана з невеликим за розміром рахунком, і тому весь ризик покупця обмежений втратою коштів на цьому рахунку.

Гута Банк став першим російським банком, який приступив до емісії віртуальних карт платіжної системи VISA, які отримали назву VISA [email protected] і спеціально призначених для здійснення платежів в Інтернеті. Проект був запущений влітку 2000 р. після того, як компанія VISA International завершила сертифікацію VISA [email protected] і офіційно санкціонувала їх емісію Гута Банком.

Карти VISA [email protected] призначені для оплати через Інтернет будь-яких видів товарів і послуг у будь-яких електронних магазинах в усьому світі, в тому числі для оплати послуг операторів стільникового зв’язку, Інтернет-провайдерів, туристичних компаній, підприємств готельного бізнесу і т. д. Для проведення інших операцій (розрахунків у звичайній торговельній мережі, одержання готівкових коштів) карта VISA [email protected] не призначена.

Використання віртуальної карти зручно для клієнта у випадку, коли банк-емітент додатково надає йому послуги Інтернет-банкінгу для управління своїми рахунками. У цьому випадку клієнт у віддаленому режимі за допомогою тільки персонального комп’ютера, підключеного до Інтернету, може в режимі реального часу перевести кошти зі свого «головного» рахунку на рахунок, пов’язаний з віртуальною картою, у кількості, необхідній для здійснення намічених електронних покупок.

Вимоги до віртуальних карт полягають у наступному:

– віртуальна карта повинна мати номер (система MasterCard вимагає, щоб номер карти складався з 16 цифр) та строк дії;

– система MasterCard вимагає, щоб з віртуальною картою була пов’язана величина CVC2 (VISA залишає питання використання величини CVV2 для віртуальної карти на рішення емітента картки);

– до віртуальних картах застосовуються ті ж правила, що і до звичайних картах, за винятком правил, які пов’язані з фізичними характеристиками карт;

– емітенти повинні зрозумілим для клієнта чином передати йому номер картки, термін її дії тощо, а також спосіб її використання;

– емітенти повинні затвердити випуск віртуальних карток у відповідних департаментах сертифікації карток міжнародних платіжних систем;

– емітент повинен ясно пояснити власнику віртуальної карти, що вона не може використовуватися в режимі Dual Mode, коли авторизація проводиться по віртуальній карті, а презентмент сформований по звичайній карті, прив’язаною до того ж рахунку, що і віртуальна карта.

Для того щоб передати клієнту реквізити віртуальної картки, емітент може використовувати певний фізичний носій інформації про реквізити картки (Reference Device — RD). RD за своїм фізичним характеристикам має явно відрізнятися від звичайної карти. Зокрема, RD не повинен мати тих же розмірів і пропорцій, що і звичайна карта, містити голограм платіжних систем, а також магнітної смуги і чіпа.

У той же час на фізичному носії повинен знаходитися логотип платіжної системи, розміри і колір якого визначаються правилами платіжної системою. Дизайн фізичного носія, а також інші засоби доведення інформації про реквізити картки та правила її використання повинні пройти обов’язкову сертифікацію в платіжній системі.

Інша важлива вимога міжнародних платіжних систем полягає в тому, що віртуальна картка може бути видана:

– власника «фізичної» карти;

– клієнту, який не має «фізичної» карти платіжної системи, але має можливість отримати її за його першою вимогою.

Ці умови за задумом платіжних систем повинні сформувати настільки ж серйозне відношення банку-емітента на віртуальній карті, як і до звичайного, оскільки відповідальність банку за свого клієнта-власника віртуальної картки не змінюється в порівнянні з випадком власника звичайної карти.

Ключовим фактором у реалізації програм віртуальних карт є невеликий час, необхідне міжнародним системам і банкам-емітентам для їх запуску. Сьогодні це час оцінюється в два тижні.

Віртуальні номери карт

Ідея віртуальної карти отримала розвиток в технології віртуального номера карти (використовуються також терміни pseudo card number і proxy card number). Суть цієї технології полягає в тому, що при заповненні форми торговельного підприємства під час операції по оплат власник картки замість реального номера картки повідомляє Інтернет-магазину деякий випадковий номер. Після того як транзакція надходить у систему емітента для авторизації, здійснюється зворотне перетворення віртуального номера карти в реальний номер. В результаті при виконанні операцій купівлі реальний номер карти ніколи не передається в платіжну мережу і залишається в системі емітента. Таким чином, ймовірність компрометації реальних номерів карт, а також імовірність успішного здійснення транзакції шахраєм стають близькими до нуля.

Технічно ідея віртуального номера картки може бути реалізована наступним чином. Клієнт для оплати електронних покупок з допомогою технології віртуального номера картки повинен встановити на свій комп’ютер спеціальне ПЗ. Після того як клієнт отримує від Інтернет-магазину для заповнення форму, що містить інформацію про реквізити картки, ЗА клієнта ініціює звернення до системи свого емітента. Емітент генерує для клієнта віртуальний номер картки і повертає його клієнту. При цьому емітент контролює в деякому сенсі унікальність згенерованого номери карти, а також належність префікса карти до виділеного для емітента діапазону значень BIN.

Після цього транзакція виконується звичайним чином. Клієнт направляє Інтернет-магазину заповнену форму, в якій в якості номера картки фігурує віртуальний номер. В результаті виконання стандартних процедур обробки транзакції в системі обслуговуючого банку та платіжної системи з останньої в систему емітента надходить авторизаційний запит, що містить віртуальний номер карти. Емітент, отримавши авторизаційний запит, встановлює відповідність між даними, що були сформовані при ініціалізації транзакції, і даними авторизаційного запиту. Відповідність шукається по цілому ряду параметрів.

Наприклад, система MasterCard обов’язковим параметрам відносить номер картки, термін її дії, ім’я магазину (Merchant Name), ідентифікатор магазину (Merchant ID), суму транзакції і валюту транзакції. Емітент визначає реальний номер картки, виконуючи зворотне перетворення, проводить з його використанням авторизацію транзакції і результат повертає платіжну мережа, попередньо знову підставивши в авторизаційний відповідь віртуальний номер карти.

Якщо в платіжній системі використовується технологія Single Message System (авторизаційний запит є одночасно і фінансовим повідомленням, що вимагає від емітента відшкодування коштів), то процес на цьому завершується. У разі застосування технології Dual Message System (процедури авторизації і розрахунків розділені) система емітента буде зобов’язана також обробити клірингова (фінансовий) повідомлення, пов’язане з розглянутої транзакцією. При обробці клірингового повідомлення потрібно виконати необхідну підстановку реального номера картки замість віртуального номера.

Гідність ідеї віртуального номера карти вже зазначалося. Ймовірність шахрайства при реалізації ідеї емітентом практично дорівнює нулю. При цьому технологія роботи платіжної системи ніяк не зачіпається, починаючи з рівня торгової точки — ті ж протоколи, формати повідомлень і т.п.

У той же час, ідея віртуальних номерів карт має і ряд недоліків.

По-перше, як вже згадувалося, власник картки повинен встановити на своєму комп’ютері спеціальне ПО, зване електронним гаманцем. Для деякої категорії клієнтів така процедура сама по собі представляє проблему.

По-друге, емітент повинен запропонувати клієнту процедуру його автентифікації під час звернення клієнта за віртуальним номером у систему емітента. Як правило, використовується система паролів — клієнт захищеної сесії з системою емітента повідомляє останньої свій ідентифікатор і кодове слово (пароль). Тут існують кілька підходів до вирішення завдання. Найбільш надійним є отримання клієнтом своїх ідентифікатора і пароля безпосередньо у банку (у крайньому випадку листом з банку, причому ідентифікатори клієнта повинні роздруковуватися у PIN-конверті для того, щоб зробити інформацію закритою для банківського персоналу). Цей підхід є незручним для клієнта. Тому на практиці знаходить застосування іншої, менш надійний метод. Клієнт отримує свої ідентифікатори під час першої сесії з системою емітента. Він ідентифікує себе, представляючи емітенту реквізити карти, а також додаткову інформацію, запитувану емітентом (наприклад,
номер паспорта, дівоче прізвище матері тощо). У відповідь у разі позитивного результату аутентифікації клієнт отримує свій ідентифікатор і пароль. Весь обмін інформацією між клієнтом і системою емітента відбувається в захищеній сесії. Логічне з’єднання з системою емітента забезпечується гаманцем клієнта. Більш низька захищеність цього методу пов’язана з тим, що в процесі ідентифікації клієнта можуть бути різні підставки з боку шахраїв, що імітують роботу емітента.

По-третє, крім віртуального номера карти система емітента в деяких випадках має в режимі реального часу генерувати значення CVC2/CVV2.

Звичайно, емітент, який застосовує технологію віртуальних номерів карт, може і не перевіряти значення CVC2. У цьому разі платіжну мережа може направлятися будь-яке випадкове значення CVC2. Однак при такому підході емітент позбавляється можливості використовувати резервну авторизацію (авторизацію Stand-In), яка надається в його розпорядження багатьма платіжними системами на випадок відмови в роботі системи емітента. В режимі резервної авторизації платіжна мережа від особи емітента у відповідності з параметрами, установленими емітентом, здійснює авторизацію транзакцій. В системі резервної авторизації існує загальний параметр для всіх префіксів карт, що визначає дію емітента на випадок невірного значення CVC2/CVV2 — відхилити транзакцію відразу або продовжити інші перевірки. Якщо такий параметр встановити рівним значенню, що означає «не відхиляти», то й за всіма іншими операціями і префиксам буде прийматися те ж рішення, що напевно суперечить інтересам
емітента.

По-четверте, застосування технології віртуальних номерів карт спричинить за собою проблеми для тих Інтернет-магазинів, які зберігають номери карток клієнтів, який одного разу вже зверталися в торговельне підприємство за послугами, щоб не змушувати клієнта набирати свої реквізити при наступних зверненнях в торгову точку. Очевидно, що при масовому застосуванні технології віртуальних номерів карток БД таких магазинів швидко переповняться, що спричинить за собою операційні проблеми в їх функціонуванні.

В Інтернет-магазинів є й інші проблеми. Наприклад, якщо клієнт зробив в одному і тому ж магазині протягом відносно короткого проміжку часу дві транзакції на однакову суму, при необхідності провести операцію «повернення покупки» буде неясно, який номер карти підставляти в транзакцію повернення. Це пов’язано з тим, що в системах торгової точки в якості ключа для пошуку транзакції, як правило, використовується номер картки і сума транзакції. Тому, якщо клієнт не може назвати точне значення номера карти, існує ймовірність того, що при формуванні повернення буде підставлено неправильне значення номера картки та в обліковій системі магазину з’явиться запис — «повернуто» не той товар з усіма витікаючими наслідками для підсистеми управління запасами магазину і т. п.

Нарешті, використання віртуальних номерів карток тягне за собою і проблеми в системах емітента. Необхідність зберігання інформації про всіх номерах карт — одна з них.

Вимоги до технології віртуальних номерів карт при використанні наприклад карт Maestro полягають у наступному. Емітент повинен генерувати 16-цифрові номери карт (при цьому віртуальний номер картки може не збігатися з реальним номером карти), а також перевіряти відповідність між даними, що були сформовані при ініціалізації транзакції, і даними авторизаційного запиту. Як зазначалося раніше, відповідність шукається як мінімум по номеру картки, термін її дії, імені магазину (Merchant Name), ідентифікатору магазину (Merchant ID), суми транзакції і валюті транзакції.

Відмітна особливість рішення для карт Maestro полягає в тому, що власник картки не повинен встановлювати на своєму комп’ютері ніякого спеціального ПО (електронного гаманця). Транзакція виконується наступним чином. Після того як власник картки повідомив торговій точці про готовність платити з використанням картки Maestro, Інтернет-магазин відправляє на сервер емітента (e-Wallet в термінах Maestro), що зберігає інформацію про реквізити своїх карт, спеціальне повідомлення. Це повідомлення містить інформацію про торговельній точці (Merchant Name, Merchant ID), про суму і валюту покупки, ідентифікатор транзакції в системі торгової точки і т. п. Одночасно сервер магазину перемикає власника картки на сервер емітента.

Сервер емітента встановлює з власником картки захищене з’єднання і направляє клієнту форму для проведення його аутентифікації. Наприклад, емітент може запитати у власника карти раніше надані йому ідентифікатор і пароль. Після того як власник картки аутентифікований сервером емітента, останній формує запит на сервер торгової точки, що містить згенерований емітентом віртуальний номер карти.

За рішенням Maestro є кілька питань, відповіді на які явно не йдуть з офіційного опису схеми.

По-перше, не визначено, яким чином торгова точка дізнається адресу сервера емітента картки Maestro. У найпростішому випадку торгова точка знає адреси серверів емітента для деякого обмеженого набору префіксів (локальне рішення). У загальному випадку необхідно створити певну централізовану директорію адрес, і в цьому випадку торгова точка повинна звертатися до сервера директорії, який вже скеровує запит на сервер емітента.

Друге питання пов’язане з необхідністю визначення специфікації інтерфейсу між торговою точкою і сервером емітента. Мова йде про семантику і синтаксис повідомлень, якими обмінюються торгова точка і сервер емітента.

Розподіл відповідальності при виникненні диспуту по транзакції нічим не відрізняється від того, яким чином воно здійснюється при використанні моделі трьох доменів.

Використовуваний матеріал:

1. М. Paitel «Digital transformation»

2. В. Голдовський «Безпека платежів в Інтернеті»