<<
>>

Электронная коммерция (CNP)

На сегодняшний день ведущие платежные системы поддерживают единственный протокол безопасной электронной коммерции — 3D Secure (в платежной системе Visa этот протокол продвигается под брэндом Verified by VISA, а в системе MasterCard — под брэндом MasterCard SecureCode).
По мнению экспертов, повсеместное использование этого протокола торговыми предприятиями, обслуживающими банками и эмитентами карт уменьшит фрод в области электронной коммерции не менее чем на 80 %, доведя его до уровня ниже 5–7 базисных пунктов.

Требования международных платежных систем к безопасности операций ЭК формулируются следующим образом:

• должна обеспечиваться взаимная аутентификация участников электронной покупки (покупателя, торгового предприятия и его обслуживающего банка);

• реквизиты платежной карты (номер карты, срок ее действия, CVC2/CVV2, и т. п.), используемой при проведении транзакции ЭК, должны быть конфиденциальными для торгового предприятия;

• невозможность отказа от операции для всех участников транзакции электронной коммерции.

К сожалению, первый безопасный протокол электронной коммерции Secure electronic transaction (SET), удовлетворяющий всем перечисленным выше требованиям, сегодня платежными системами больше не поддерживается.

Это связано с дороговизной и сложностью внедрения протокола SET.

Для стимулирования внедрения протокола 3D Secure платежные системы ввели сдвиг ответственности, называемый merchant only liability shift, в соответствии с которым при поддержке торговой точкой протокола 3D Secure ответственность за мошенничество в ЭК, связанное с отказом держателя карты от совершения операции, возлагается на эмитента. В платежной системе Visa ответственности merchant only liability shift носит глобальный характер. В MasterCard сдвиг ответственности merchant only liability shift касается всех регионов за исключением Северной Америки (США и Канада), в которой ответственность за результат операции возвращается к эмитенту только в случае поддержки 3D Secure всеми участниками транзакции ЭК — онлайновым магазином, обслуживающим банком и банком-эмитентом (так называемая full authentication-авторизация).

Напомним, что для CNP-транзакций без использования защищенного протокола ответственность за мошенничество возлагается на обслуживающий банк.

Таким образом, в случае использования торговой точкой 3D Secure восстанавливается нормальное распределение ответственности, характерное для платежных операций других типов.

Протокол 3D Secure с точки зрения обеспечиваемой им защиты значительно слабее протокола SET. Он в общем случае не обеспечивает аутентификации держателем карты торгового предприятия и прозрачности данных о реквизитах карты для торгового предприятия. В то же время он проще при внедрении и аппаратно-программные решения, реализующие 3D Secure, существенно дешевле аналогичных решений для протокола SET.

Наиболее серьезной проблемой безопасности протокола 3D Secure является его беззащитность от атак типа «man-in the-middle». Например, при использовании держателем карты протокола 3D Secure мошеннические онлайновые магазины могут применять следующую процедуру компрометации пароля держателя карты (рис. 2). Merchant plug-in (MPI) мошеннического магазина, получив ответ VERes, содержащий динамический адрес (URL) страницы аутентификации сервера эмитента Access control server (ACS), направляет запрос на аутентификацию держателя карты PAReq не по указанному адресу, а на адрес своего SSL-сервера. Затем SSL-сервер перенаправляет данный запрос на URL ACS эмитента карты, тем самым, «изображая» для ACS компьютер держателя карты. В результате ACS принимает ложный сервер за персональный компьютер держателя карты и передает на ложный сервер свою страничку, предназначенную для аутентификации держателя карты. Эта страничка содержит сообщение Personal Assurance Message, с помощью которого в схеме 3D Secure клиент аутентифицирует свой банк (точнее сервер ACS своего банка). Обладая страничкой для аутентификации, мошеннический сервер теперь может играть роль ACS для настоящего клиента банка, запрашивая у последнего значение статического пароля.

Чтобы защититься от подобных краж статических паролей, были предложены различные схемы генерации и использования динамических паролей или, как их еще называют, разовых паролей (One time password (OTP).

Примером распространенного в банковской сфере алгоритма генерации OTP является метод Chip authentication program (CAP) разработанный MasterCard и принятый для использования в рамках Visa под брендом Dynamic passcode authentication (DPA).

Для реализации метода CAP клиент должен обладать микропроцессорной картой с EMV-приложением, а также специальным картридером, способным инициировать генерацию пароля OTP и отображать его значение, состоящее из 8 цифр, на дисплее ридера (иногда ридер и карта совмещаются в одном физическом устройстве). Такой ридер может стоить несколько евро (10–15 евро в зависимости от производителя и объема закупаемой партии устройств). Помимо дополнительных расходов на обеспечение ридерами держателей карт, другим недостатком такого подхода является тот факт, что за картридером клиенту необходимо придти в банк, а, кроме того, для совершения операции ридер нужно иметь под рукой, что не всегда удобно, поскольку размеры устройства значительно превышают размеры банковской карты, и в бумажнике такой ридер не помещается.

На этом фоне сотовый телефон, являясь наиболее массовым мобильным устройством, используемым населением планеты (по результатам 2005 г. во всем мире обращалось более 2 млрд сотовых телефонов, а к 2010 г. это устройство будут иметь примерно 3 млрд потребителей), давно привлекал внимание исследователей в качестве потенциального универсального инструмента аутентификации. Тем более, что возможности мобильных телефонов как с точки зрения их вычислительных способностей, поддерживаемых коммуникаций, так и с точки зрения функциональности, постоянно растут.

Тем не менее, на сегодняшний день существуют сложности в использовании мобильного телефона в качестве инструмента аутентификации. Они заключается в следующем. Известно, что по-настоящему защищенным местом хранения конфиденциальной информации на телефоне является SIM-карта (некоторые модели телефонов обладают отдельным микропроцессором, выполняющим функцию элемента безопасности-security element; но таких моделей на рынке мало).

Однако загрузить информацию на SIM-карту можно только с разрешения контролирующего ее оператора сотовой связи. При этом, даже если последний разрешит загрузку и использование конфиденциальной информации клиента на SIM-карте, единственно возможным способом реализовать это на практике является предварительная загрузка данных на SIM-карту в процессе ее персонализации силами оператора или уполномоченного им центра персонализации. Удаленная персонализация SIM-карты по технологии over-the-air (OTA-GSM 03.48), предназначенная для загрузки данных и приложений на SIM-карту и поддерживаемая всеми Java-картами, персонализированными с поддержкой профиля OTA profile, на практике фактически не используется, поскольку в этом случае банк должен делить свою конфиденциальную информацию с сотовым оператором. Дело в том, что процедура загрузки данных по технологии OTA сегодня находится под полным контролем оператора мобильной связи.

То же самое касается и технологии, основанной на использовании протокола Security and trusted services API (SATSA, JSR177), позволяющей мидлету пользоваться процедурами и данными, загруженными на SIM-карту, поддерживающую Java Card (таких SIM-карт сегодня большинство). Помимо того, что спецификация JSR177 является опциональной для профиля MIDP 2.0 платформы J2ME, и потому сотовыми телефонами практически не поддерживается, по-прежнему, со стороны сотового оператора требуется авторизация доступа мидлета к приложениям карты с использованием SATSA.

В то же время MasterCard выпустил спецификацию MasterCard mobile authentication (MMA), в основе которой лежит схема CAP, реализуемая мидлетом, загружаемым на Java-совместимый телефон. Напомним, что на входе алгоритма CAP задаются текущий номер операции (ATC), профиль приложения карты (AIP), на выходе — 8-значный цифровой разовый пароль, являющийся функцией от криптограммы AAC (authentication application cryptogram). Криптограмма формируется с помощью определенного в стандарте EMV алгоритма вычисления прикладной криптограммы.

В этом алгоритме используется ключ двойной длины (112 битов) customer master key, который и является единственным секретом, передаваемым на мобильный телефон.

Для обеспечения конфиденциальности секретных данных мидлета (customer master key) при его загрузке на телефон используется алгоритм PBE (password-based encryption), реализованный в рамках стандартного пакета Bouncy Castle APIs for J2ME, который, в свою очередь, реализует стандартный интерфейс к криптографическим функциям, определенный MIDP (mobile information device profile). В общих словах профиль MIDP представляет собой открытый программный интерфейс к библиотекам J2ME на сотовых телефонах и других устройствах. При формировании ключа в алгоритме PBE (для шифрования данных применяется алгоритм 3DES) в качестве пароля используется мобильный ПИН-код клиента, в качестве величины Salt — номер телефона (MSISDN).

Мобильный ПИН-код придумывается клиентом и используется им каждый раз при инициализации мидлета на своем телефоне. Вводимое клиентом значение мобильного ПИН-кода необходимо для расшифрования ключа customer master key, который хранится в телефоне в зашифрованном виде. Поэтому при вводе неправильного значения ПИН-кода в результате расшифрования будет получено неверное значение ключа customer master key, а значит будет вычислено неверное значение криптограммы AAC и разового пароля. Последний факт будет зафиксирован на сервере аутентификации клиента.

Таким образом, надежность описанной схемы главным образом определяется секретностью мобильного ПИН-кода клиента. Если телефон попадает в руки мошенника, не знающего значение ПИН-кода, то после трех безуспешных попыток аутентификации (неверного значения вычисленной криптограммы) клиент будет заблокирован на сервере аутентификации, и дальнейшее использование мидлета станет невозможным.

Анализ схемы аутентификации с помощью мидлета показывает, что поскольку все криптографические вычисления в этом случае производятся процессором телефона, то теоретически, загрузив на телефон программу-шпиона, отслеживающего состояние памяти телефона и передающее информацию из оперативной памяти наружу, можно скомпрометировать значение ключа customer master key, а значит и схему в целом.

На сегодняшний день список вирусов для сотовых телефонов состоит из 30–40 программ, в то время, как аналогичный список для персональных компьютеров составляет несколько сотен тысяч программ. При этом мы не очень боимся вводить на клавиатуре своего компьютера пароли для интернет-бэнкинга или для своей аутентификации при выполнении операций ЭК.

Обобщая сказанное выше, можно констатировать, что широкомасштабного внедрения протокола 3D Secure до сих пор не произошло. На середину 2007 г. протокол 3D Secure поддерживался более чем 115 тыс. онлайновых магазинов, примерно 400 обслуживающими банками и 3160 банками-эмитентами. Лидером по внедрению 3D Secure является Великобритания, на долю которой приходится более 31 тысячи онлайновых магазинов. В Европе находится примерно 65 % всех онлайновых магазинов, поддерживающих 3D Secure.

С точки зрения эмиссии для использования протокола только в платежной системе MasterCard зарегистрировалось более 20,5 млн держателей карт MasterCard и Maestro. Конечно, это очень малая доля (несколько процентов) держателей карт с точки зрения общего количества карт этой платежной системы. Можно говорить, что именно медленное внедрение эмиссионной части протокола является главной причиной повышения безопасности операций ЭК.

В то же время по данным MasterCard в июле 2007 г. примерно 22 % всех операций ЭК в Европе производилось в магазинах, поддерживающих 3D Secure. При этом, в примерно 6 % всех операций 3D Secure поддерживался как со стороны торговых предприятий и обслуживающих банков, так и со стороны эмитентов карт.

Многие обслуживающие банки (онлайновые магазины) применяют в своих системах дополнительные проверки при обработке транзакций ЭК. К таким проверкам относятся:

• проверка адреса держателя карты (address verification system); предоставление для проверки эмитенту значений CVV2/CVC2;

• проверка количества транзакций, выполненных с некоторого IP-адреса (IP address frequency check);

• контроль количества транзакций, выполненных по карте в течение определенного промежутка времени (card number frequency check );

• проверка на совпадение страны адреса доставки товаров со страной, резидентом которой является банк, выдавший карточку (country match). Страна, резидентом которой является банк, определяется по значению идентификационного номера банка (bank identification number, или BIN);

• проверка IP-адреса (или сетки адресов), с которого была инициирована транзакция, на предмет его нахождения в черном списке (block IP address);

• проверка местоположения держателя карты (по IP-адресу его Интернет-провайдера) с географией доставки товаров (geolocation );

• отсев карт по некоторым ВШам банков (block bank BINs);

• отсев транзакций, поступающих с анонимных прокси-серверов (block proxy);

• отсев транзакций, при совершении которых были указаны адреса электронной почты из определенных доменов, например доменов, которые предлагают услуги бесплатной электронной почты (block proxy);

• проверка номера карты на ее присутствие в черном списке (negative database);

• использование открытых ресурсов, хранящих черные списки реквизитов мошеннических карт (например, CyberSource Negative Database and Scoring System, SharedGlobal Negative Database and Scoring System), а также осуществляющих аутентификацию держателя карты по номеру его телефона (MyVirtualCard).

Первые две проверки из приведенного выше списка рекомендуются платежными системами. Так VISA считает, что использование проверки CVV2 уменьшает вероятность фрода более чем на 60 %. Сегодня платежные системы предпринимают шаги к тому, чтобы обязать эмитентов проверять значения CVC2/CVV2, полученные из авторизационных запросов, в своих процессинговых системах, а высокорискованные торговые предприятия (например, онлайновые казино) вставлять в авторизационные запросы значения этих криптовеличин.

Исследования компании ClearCommerce (США) относительно оценки эффективности использования системы AVS показывают, что только 40 % транзакций успешно проходят эту проверку при том, что доля мошеннических среди них менее процента. С другой стороны, при использовании AVS 35 % мошеннических операций успешно преодолевают эту защиту.

Кроме перечисленных выше проверок онлайновые магазины иногда обращают внимание на следующие факты, повышающие вероятность мошенничества:

• клиент впервые обслуживается в магазине;

• размер операции выше обычного для магазина значения;

• заказ состоит из большого количества одинаковых предметов;

• транзакции выполняются по картам с похожими номерами;

• адрес доставки заказа один и тот же для покупок, совершенных по разным картам;

• несколько транзакций по одной карте в течение короткого интервала времени;

• несколько транзакций, выполненных по различным картам с одним адресом доставки выписок (billing address), но разными адресами доставки товаров;

• транзакция, которую клиент хочет оплатить более чем одной картой.

У магазина (особенно MO (TO) — магазина) могут быть и другие причины для сомнения — нерешительность держателя карты в предоставлении персональных данных, требование к срочности выполнения заказа, странный адрес доставки, незаинтересованность клиента в свойствах товара (например, в цвете) и т. д.

Другой ранее упоминавшийся аспект проблемы мошенничества для CNP-транзакций — кража данных о реквизитах карт с серверов главным образом онлайновых магазинов. Несмотря на запрет платежных систем, обслуживающие банки и торговые предприятия хранят в своих системах значения CVC2/CVV2, данные магнитной полосы карты, адреса, используемые в AVS, зашифрованные PIN-блоки. Онлайновые магазины оставляют в своих БД доступные им данные: номер карты, срок ее действия, иногда CVV2/CVC2 и адрес, используемый в системе AVS. Исследования, выполненные Visa USA, показали, что в США 37 % торговых предприятий, несмотря на запреты платежных систем, продолжают хранить в своих системах информацию по картам.

В результате при взломе сайтов онлайновых магазинов происходит компрометация данных карт различных эмитентов. Самыми показательными является случаи взлома сервера TJX и БД процессора CardSystems Solutions, в результате которых были потенциально скомпрометированы соответственно 45,7 и 40,0 млн карт.

Для повышения уровня защиты информации ведущие платежные системы в течение нескольких последних лет требовали от своих банков участия в программах VISA account information security и MasterCard site data protection. Эти программы требуют от банков контроля обслуживаемых ими онлайновых магазинов с точки зрения выполнения ряда требований безопасности. К таким требованиям безопасности относятся:

• поддержка на сервере торгового предприятия средств защиты сетевого доступа (firewall );

• шифрование конфиденциальных данных при их хранении и передаче;

• использование актуальных антивирусных программ;

• своевременное применение «заплат безопасности» в используемом программном обеспечении;

• использования процедур разграничения доступа к серверам и данным;

• выполнение постоянных аудитов систем безопасности онлайновых магазинов.

В конце 2004 г. в основу программ защиты данных двух ведущих платежных систем был положен стандарт Plastic card industry data security standard (PCI DSS). Стандарт включает в себя 12 требований верхнего уровня, которые должны удовлетворяться информационными системами любого (в том числе онлайнового) магазина или третьестороннего процессора. Эти требования перечислены ниже:

1. Для защиты сетевого доступа к серверам, хранящим карточную информацию, необходимо использовать специализированные аппаратно-программные средства Firewall. Настройки Firewall, определяющие разрешенный сетевой трафик, должны постоянно контролироваться.

2. Нельзя использовать значения по умолчанию паролей и других параметров безопасности в используемых магазином системах. Как пример для иллюстрации, использование дефолтных значений параметров протокола WEP, применяемого для обеспечения безопасности беспроводной радиосвязи Wi-Fi при использовании стандарта IEEE 802.11b приводит к тому, что большинство устройств этого стандарта на данный момент не поддерживают необходимого уровня безопасности.

3. Хранимые данные карты должны быть защищены (с помощью шифрования, хэширования или усечения хранимой информации). В системах торговых предприятий не должна храниться информация (даже в зашифрованном виде), используемая для аутентификации держателя карты (например, значения PVV, вторая дорожка магнитной полосы карты и т. п.).

4. Передаваемые по сети данные держателя карты должны быть надежно зашифрованы (допускается использование симметричных алгоритмов 3DES с ключом не менее 112 битов, AES с длиной ключа 256 битов и асимметричного алгоритма RSA с длиной ключа 1024 битов).

5. Необходимо использовать и регулярно обновлять антивирусное программное обеспечение.

6. Необходимо уделять внимание обнаружению и устранению уязвимостей в используемом магазином программном обеспечении (вовремя использовать модификации ПО, устраняющие обнаруженные уязвимости, установить процесс тестирования разработанного своими силами ПО на предмет обнаружения уязвимостей, использовать лучшие практики разработки нового ПО и т. п.).

7. Использовать ограничение доступа сотрудников торгового предприятия только к функциям и информации, необходимым им по роду деятельности.

8. Каждый пользователь системы процессинга магазина должен иметь уникальный идентификатор, используемый для его аутентификации внутри системы. Уникальность идентификатора позволяет не только обеспечить разграничение доступа в системе, но и позволяет отслеживать действия всех сотрудников в информационной системе магазина.

9. Физический доступ сотрудников магазина к серверам, хранящим базы данных карт, должен быть ограничен. Это позволяет избежать возможности записи информации на внешние носители, замены и кражи оборудования, хранящего чувствительную информацию. Физический доступ должен быть ограничен и к телекоммуникационным ресурсам, через которые возможен доступ к серверам (в частности, к точкам доступа беспроводной связи).

10. Необходимо выполнять мониторинг доступа к Базам данных карт, используя механизмы логирования активности пользователей системы, связанной с доступом в систему, попытками аутентификации и т. п.

11. Необходимо регулярно проводить аудит и тестирование систем безопасности магазина.

12. Необходимо поддерживать политику безопасности внутри компании, четко определяющую для каждого сотрудника онлайнового магазина требования, предъявляемые к нему с точки зрения поддержания безопасности системы магазина в целом.

В зависимости от потенциальной угрозы доступа к хранящейся в информационных системах магазинов и третьесторонних процессоров информации по картам платежные системы делят магазины и процессоры по нескольким уровням и определяют следующие типы мероприятий, регулярно проводимых для оценки уровня соответствия магазина стандарту PCI DSS:

• аудит безопасности, проводимый непосредственно в торговом предприятии;

• самооценка системы безопасности магазина (процессора) по вопроснику, предлагаемому платежной системой;

• сетевое сканирование доступа к карточным данным.

Как уже отмечалось ранее, к сожалению, далеко не все торговые предприятия удовлетворяют требованиям PCI DSS. Многие торговые предприятия ссылаются на высокую стоимость модернизации используемых ими сегодня аппаратно-программных средств обработки карточных операций. В середине 2007 г. Visa объявила о запуске новой динамической системы авторизации Visa Advanced Authorization, на которую возлагаются большие надежды по борьбе с фродом. Система Visa использует разработанное на основе нейронных сетей решение, позволяющее в режиме реального времени оценить каждую операцию по карточке Visa с точки зрения потенциального мошенничества. В результате каждый эмитент будет получать в рамках авторизации оценку того, что авторизация является мошеннической.

В заключение следует сказать, что проблема карточного фрода является актуальной и угрожает существованию технологии пластиковых карт. Возможности карт с магнитной полосой в противодействии мошенничеству весьма ограничены. Карта с магнитной полосой является лишь носителем небольшого объема информации. Поэтому оказать противодействие мошенничеству могут только эмитент и обслуживающий банк, не имеющие своих полноценных представителей в точке продажи. Даже в предположении онлайнового характера всех карточных операций возможности эмитента и обслуживающего банка весьма ограничены. Эмитент в большинстве случаев может только проверить правильность статических данных карты, полученных при выполнении операции безналичной покупки, да проанализировать, насколько эта операция характерна для данного клиента с помощью программы мониторинга транзакций. Обслуживающий банк представлен кассиром торгового предприятия, далеко не всегда следующим при приеме карт инструкциям банка.

Микропроцессорные карты, речь о которых пойдет далее, коренным образом способны повысить уровень карточной безопасности.

<< | >>
Источник: А. Бабаева. Платежные карты: Бизнес-энциклопедия. 2008

Еще по теме Электронная коммерция (CNP):

  1. Платежные карты в системах электронной коммерции
  2. Сущность электронной коммерции и ее место в развитии бизнеса России Компьютеризация процессов управления коммерческой работы по оптовым закупкам и оптовой продаже товаров весьма актуальна.
  3. В. В. Щербаков, A.B. Парфенов. Коммерция и логистика: сборник научных трудов, 2011
  4. Основные статистические методы, используемые в коммерции
  5. Цены и наценки в коммерции
  6. Роль научно-технического прогресса в коммерции
  7. Понятие и сущность коммерции и коммерческой деятельности
  8. Социальные аспекты коммерции
  9. Риски в коммерции
  10. Коммерция в медицине
  11. Инновации в коммерции и логистике