Чтение онлайн

К сожалению, первый безопасный протокол электронной коммерции 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 и разового пароля. Последний факт будет зафиксирован на сервере аутентификации клиента.