Протокол 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. Конечно, это очень малая доля (несколько процентов) держателей карт с точки зрения общего количества карт этой платежной системы. Можно говорить, что именно медленное внедрение эмиссионной части протокола является главной причиной повышения безопасности операций ЭК.
