17 августа 2012,
16:17
1030
MMA и NFC: «мобильная» аутентификация
Новые универсальные технологии аутентификации с использованием мобильного телефонаИгорь Голдовский, генеральный директор ЗАО...
Новые универсальные технологии аутентификации с использованием мобильного телефона
Игорь Голдовский, генеральный директор ЗАО "Платежные технологии"
Как известно, аутентификация является важнейшим элементом практически любой современной информационной системы, будь то СУБД, система электронной почты, Интернет-банкинг, электронная коммерция или иной канал предоставления услуг. При этом всякий раз, когда услуга (сервис) ограничена в использовании, необходимо проверить факт того, что лицо, запрашивающее эту услугу или сервис, имеет право на ее получение. А для этого необходимо сначала выполнить аутентификацию этого лица, т. е. доказать, что лицо, называющее себя субъектом Х, таковым и является, а затем проверить доступность запрашиваемой услуги субъекту Х.
В банковской сфере, и в карточных технологиях в частности, аутентификация клиента банка требуется буквально на каждом шагу и имеет самые разнообразные формы в зависимости от используемого клиентом канала доставки удаленных банковских услуг. Например, для аутентификации клиента при выполнении им операции снятия денег в банкомате применяется ПИН-код, для блокировки/разблокирования карты или при получении услуг через телефонный банкинг используются кодовые слова (буквенные последовательности, представляющие собой понятные при телефонном разговоре слова), в электронной (мобильной) коммерции (банкинге) часто применяются статические пароли (буквенно-цифровые последовательности, вводимые с клавиатуры компьютера/телефона).
В последнее время в вопросах аутентификации клиента со стороны эмитентов четко прослеживаются две тенденции:
• стремление унифицировать процедуру аутентификации для всех каналов доставки клиентам услуг;
• недоверие к статическим паролям (наиболее массовому способу аутентификации клиента) как к наименее надежному методу аутентификации.
Первая тенденция очевидна. Клиент заинтересован в использовании единой процедуры своей идентификации/аутентификации для доступа к широкому спектру услуг, что значительно упрощает его жизнь – не нужно запоминать многочисленные пароли/коды/идентификаторы для работы со всей инфраструктурой, требующей его аутентификации, – с корпоративной почтой, системой Интернет-банкинга и т.п. Вторая тенденция также понятна. Статический пароль выдается однажды на значительный период времени и может быть скомпрометирован, а стало быть, использован мошенниками для получения услуги от лица законного клиента.
Скомпрометировать пароль можно разными способами. Например, целый спектр уловок, используемых преступниками для компрометации ПИН-кода (цифрового пароля), подробно рассмотрен в материале автора настоящей статьи «О путешествии ПИН-кода из ПИН-пада терминала в HSM эмитента» (см. ПЛАС №2/2007). Пароль, вводимый на клавиатуре компьютера, может быть скомпрометирован, например, с помощью специальных программ-шпионов (spyware), загруженных на компьютер клиента и отслеживающих данные, набираемые клиентом на клавиатуре компьютера (keyboard logger) и/или отображаемые на экране компьютера (screen logger). Бичом последних лет стал фишинг (phishing), при котором мошенники, используя психологические методы воздействия, выманивают конфиденциальную информацию непосредственно у самого пользователя с помощью «фишинговых» рассылок по электронной почте и т.д.
В специальных схемах могут применяться и более изощренные технологии кражи паролей. Например, при использовании держателем карты протокола 3D Secure мошеннические онлайновые магазины могут применять следующую процедуру компрометации статического пароля (данная процедура позволяет также компрометировать одно значение динамического пароля, однако последнее не имеет столь драматичных последствий, как в случае статического пароля) (см. рис. 1). 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 Worldwide и принятый для использования в рамках Visa Int. под брендом Dynamic Passcode Authentication (DPA).
Для реализации метода CAP клиент должен обладать микропроцессорной картой с EMV-приложением, а также специальным картридером, способным инициировать генерацию пароля OTP и отображать его значение, состоящее из 8 цифр, на дисплее ридера. Такой ридер может стоить несколько евро (10–15 евро в зависимости от производителя и объема закупаемой партии устройств). Помимо дополнительных расходов на обеспечение ридерами держателей карт, другим недостатком такого подхода является тот факт, что за картридером клиенту необходимо прийти в банк, а кроме того, для совершения операции ридер нужно иметь под рукой, что не всегда удобно, поскольку размеры устройства значительно превышают размеры банковской карты и в бумажнике такой ридер не помещается.
На этом фоне сотовый телефон, являясь наиболее массовым мобильным устройством, используемым населением планеты (по результатам 2005г., во всем мире обращалось более 2 млрд. сотовых телефонов, а к 2010г. это устройство будут иметь примерно 3 млрд. потребителей), давно привлекал внимание исследователей в качестве потенциального универсального инструмента аутентификации. Тем более что возможности мобильных телефонов как с точки зрения их вычислительных способностей, поддерживаемых коммуникационных протоколов, так и с точки зрения функциональности постоянно растут.
Сложность использования мобильного телефона в качестве инструмента аутентификации заключается в следующем. Всем известно, что по-настоящему защищенным местом хранения конфиденциальной информации на телефоне является SIM-карта (некоторые модели телефонов обладают отдельным микропроцессором, выполняющим функцию элемента безопасности – Security Element; но таких моделей пока очень мало). Однако загрузить любую информацию на SIM-карту можно только с разрешения контролирующего ее оператора сотовой связи.
При этом, даже если последний разрешит загрузку и использование конфиденциальной информации клиента на SIM-карте, единственно возможным способом реализовать это на практике является предварительная загрузка данных на SIM-карту в процессе ее персонализации силами оператора или уполномоченного им центра персонализации. Удаленная персонализация SIM-карты по технологии overtheair (OTA – GSM 03.48), предназначенная для загрузки данных и приложений на SIM-карту и поддерживаемая всеми Javaкартами, персонализированными с поддержкой профиля OTA profile, на практике фактически не используется, поскольку в этом случае банк должен делить свою конфиденциальную информацию с сотовым оператором. Дело в том, что процедура загрузки данных по технологии OTA сегодня находится под полным контролем оператора мобильной связи.
То же самое справедливо и в отношении технологии, основанной на использовании протокола Security and Trusted Services API (SATSA, JSR177), позволяющей мидлету пользоваться процедурами и данными, загруженными на SIM-карту, поддерживающую Java Card (таких SIMкарт сегодня большинство). Помимо того что спецификация JSR177 является опциональной для профиля MIDP 2.0 (Mobile Information Device Profile 2.0) платформы J2ME и потому сотовыми телефонами практически не поддерживается, со стороны сотового оператора по-прежнему требуется авторизация доступа мидлета к приложениям карты.
Между тем в последние годы в подходах банков к построению систем мобильного банкинга произошли серьезные перемены. Если ранее в качестве единственно возможного с точки зрения безопасности решения рассматривалось использование SIM-карты как средства хранения приложения и секретных клиентских данных, то теперь набирают обороты проекты, в которых используются специальные программы-мидлеты, реализующие функции мобильного банкинга на стороне телефона и хранящие зашифрованные данные, которые используются для аутентификации держателя мидлета. Такие мидлеты хранятся в памяти телефонного аппарата и не загружаются на SIM-карту.
Безусловно, технология SIM-карты с точки зрения использования SIM-карты в качестве средства хранения приложений и конфиденциальных данных, является более надежной и безопасной. С другой стороны, эта технология, как было отмечено ранее, требует от клиента посещения отделения своего банка и замены SIM-карты на карту, содержащую предустановленное на нее приложение (как следствие, в ряде случаев – и замену телефонного номера клиента). Кроме того, как уже отмечалось, ридер обойдется клиенту/банку примерно в 10–15 евро. Технология мидлетов также имеет свои ограничения. Она может использоваться только на Java-совместимых телефонах, поддерживающих протоколы безопасной связи WTLS и/или HTTPS и, желательно, достаточно высокоскоростной транспортный протокол (GPRS или даже EDGE) для защищенной загрузки мидлетов на телефон. И в то же время у технологии мидлета имеются такие очевидные преимущества, как:
• независимость эмитента приложений (мидлетов) от операторов сотовой связи;
• простота загрузки/удаления новых приложений;
• возможность использования разнообразных недорогих средств загрузки мидлета: GPRS, EDGE, USSD, Bluetooth, IrDA, NFC и т.п.;
• возможность широкого использования мультимедийных ресурсов телефона.
В основе технологии мидлета лежит протокол аутентификации клиента MasterCard Mobile Authentication (MMA). Суть протокола MMA состоит в следующем. На сотовые телефоны клиентов загружаются специальные программы-мидлеты (Java-приложения для профиля MIDP/JTWI/MSA операционной платформы J2ME сотового телефона). Размер такого мидлета – 20 КБ и более (в соответствии с рекомендациями MasterCard размер мидлета MMA не должен превышать 35 КБ). Поэтому надежно передать его с помощью SMS-сообщений не получится. Потребуется отправить более 140 сообщений, что снижает надежность передачи мидлета и увеличивает время его загрузки до часто неприемлемых значений. Кроме того, хотя теоретически и возможно передавать сообщение в виде последовательности до 255 SMS-сообщений, но на практике размер сообщения, передаваемого по технологии SMS, не превышает 6–8 SMS-сообщений. Сегодня наиболее распространенным способом загрузки мидлетов является метод WAP/GPRS. Технологии WAP и GPRS предоставляются всеми крупнейшими операторами сотовой связи. Более того, операторы оказывают услуги по удаленному конфигурированию WAP/GPRS в ответ на запрос SIM-карты/телефона клиента с учетом используемой клиентом модели сотового телефона. Кроме протоколов WAP/GPRS для загрузки мидлета могут использоваться схемы WAP/EDGE и WAP/USSD. Кроме того, загрузка мидлета может быть выполнена с использованием протокола HTTPS, который является стандартной функцией MIDP 2.0.
При использовании протокола WAP для обеспечения безопасности загрузки мидлета (аутентификации источника мидлета, обеспечения целостности и конфиденциальности данных мидлета) устанавливается защищенное соединение, реализуемое по протоколу WTLS (беспроводная версия протокола SSL). На WAP-сервере, поддерживающем загрузку персонализированных мидлетов, размещается сертификат открытого ключа типа WTLS Class 3 Server Certificate, полученный от одного из признанных международных центров сертификации (например, от Verisign, Thawte и т. п.). Открытые ключи наиболее известных публичных центров сертификации находятся на всех телефонах, поддерживающих WAP.
Сегодня многие телефоны способны поддерживать протокол HTTPS (J2MEсовместимые телефоны, поддерживающие MIDP 2.0). В этом случае безопасная загрузка мидлета может быть выполнена с использованием этого протокола. Более того, как будет показано ниже, загрузка мидлета с помощью HTPPS является более надежной и простой в реализации. Для реализации процедур аутентификации клиентов банка загружаемые мидлеты используют стандарт MasterCard Mobile Authentication, реализующий алгоритм CAP (Chip Authentication Program) с использованием вычислительных и операционных средств сотового телефона. На входе алгоритма задаются текущий номер операции (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, который в общих словах задает открытый интерфейс к библиотекам J2ME на сотовых телефонах и других устройствах. При формировании ключа в алгоритме PBE (для шифрования данных применяется алгоритм 3DES) в качестве пароля используется специальный, т. н. мобильный ПИН-код клиента, в качестве величины Salt – номер телефона (MSISDN). Мобильный ПИН-код клиента придумывается последним один раз и используется им каждый раз при инициализации мидлета на своем телефоне. Вводимое клиентом значение мобильного ПИН-кода необходимо для расшифрования ключа Customer Master Key, который хранится в телефоне в зашифрованном виде.
Поэтому при вводе неправильного значения ПИН-кода в результате расшифрования будет получено неверное значение ключа Customer Master Key, а значит, будет вычислено неверное значение криптограммы AAC и разового пароля. Последний факт будет зафиксирован на сервере аутентификации клиента. Таким образом, надежность описанной схемы главным образом определяется секретностью мобильного ПИН-кода клиента. Если телефон попадает в руки мошенника, не знающего значение ПИН-кода, то после трех безуспешных попыток аутентификации (неверного значения вычисленной криптограммы) клиент будет заблокирован на сервере аутентификации, и дальнейшее использование мидлета станет невозможным.
Для регистрации клиента кредитно-финансового института для последующего предоставления ему мидлета могут использоваться различные схемы, например, с применением автоматизированного устройства банковского самообслуживания или системы Интернет-банкинга (см. рис. 2). Например, при использовании системы Интернет-банкинга клиент после выполнения процедуры аутентификации на соответствующей web-странице сайта банка выбирает операцию «Покупка универсального ПИН-кода», вводит номер своего телефона, модель телефона, название оператора сотовой связи и «мобильный ПИНкод». Предполагается, что реквизиты платежной карты клиента уже введены при его подключении к Интернет-банкингу. После этого клиент ждет, когда ему на телефон придет SMS-сообщение с адресом URL загрузочного сервера (так называемый downloading ticket), на котором располагается персонализированный для клиента мидлет. Когда сообщение приходит, клиент его открывает и активирует соединение с сервером по URL в отображаемом на экране телефона SMS-сообщении. В результате телефон клиента подключается к серверу, с которого на него по протоколам WAP/GPRS или HTTPS/SOAP/XML загружается предназначенный клиенту и соответствующим образом персонализированный мидлет. В результате в меню телефона появляется иконка, соответствующая загруженному мидлету.
Следует отметить, что название оператора связи и модель сотового телефона необходимы серверу для того, чтобы, вопервых, выбрать коммуникационный протокол для загрузки мидлета (GPRS, EDGE, USSD и т.п.), а, во-вторых, подготовить сборку мидлета с учетом особенностей реализации J2ME (у разных производителей имеются небольшие различия) и ограничений на размер памяти конкретной модели телефона, находящегося в распоряжении клиента.
Время ожидания клиентом прихода сообщения на телефон клиента с момента заказа мидлета в банкомате или через систему Интернет-банкинга зависит от способа реализации данной схемы в конкретном банке. Процедуру заказа можно сделать почти онлайновой, если подключить загрузочный сервер к карточному процессингу банка / сайту банка с помощью онлайнового интерфейса. Если загрузочный сервер общается с процессингом в режиме offline (наиболее простая реализация), то загрузка мидлета будет выполняться в офлайновом режиме.
Для генерации разового пароля OTP клиент входит в меню телефона и выбирает иконку мидлета. После открытия мидлета на экране телефона появляется окошко, призывающее клиента ввести его мобильный ПИН-код. После ввода ПИНкода на экране телефона появляется 8-значное цифровое значение вычисленного OTP. Значение OTP определяется в соответствии со стандартом Chip Authentication Program, признанным MasterCard Worldwide и Visa Int.
Клиент может использовать OTP для доступа к самым разнообразным каналам доставки услуг. Например, для предоставления доступа к услугам Интернет-банкинга система запрашивает у клиента разовый пароль, он вычисляет его на телефоне описанным выше способом и набирает в соответствующем окне web-страницы аутентификации клиента в системе Интернет-банкинга. При этом сервер Интернетбанкинга обращается к серверу аутентификации за проверкой разового пароля. Итак, мы рассмотрели процесс загрузки и использования мидлета для аутентификации клиента. Совершенно аналогично можно загрузить мидлет, предназначенный для мобильного банкинга. Функция аутентификации клиента является составной частью мидлета мобильного банкинга. С помощью мидлета мобильного банкинга можно через меню телефона выбрать нужную операцию (просмотр остатка на счете, информации по нескольким последним операциям, перевод денег с одного счета на другой, блокирование карты, блокирование счета и т. п.), задать ее параметры и выполнить. При этом конфиденциальность обмена данными с сервером мобильного банкинга обеспечивается средствами мидлета!
Проведем краткий анализ уровня безопасности, обеспечиваемого при использовании рассмотренной нами схемы MMA. Очевидно, что наиболее уязвимыми с точки зрения защиты конфиденциальной информации, хранящейся в мидлете, моментами являются процесс передачи мидлета на телефон и возможные атаки мошенников с целью получить несанкционированный доступ к конфиденциальным данным, хранящимся в памяти самого телефона. Рассмотрим каждый из этих моментов в отдельности.
Передача мидлета на телефон. Здесь существуют следующие механизмы защиты.
1. Как уже говорилось, мидлет может загружаться на телефон с использованием средств WTLS, обеспечивающих аутентификацию источника мидлета, целостности и конфиденциальности данных мидлета. В протоколе WTLS в реализации WAP 1.0 известна следующая «дыра». WAP-сервер общается с телефоном не напрямую, а через шлюз WAP Gateway, осуществляющий переформатирование данных из форматов WML (язык представления данных в WAP) в форматы HTML, и наоборот. Шлюз WAP Gateway также устанавливает безопасное соединение с WAP-сервером через Интернет на основе протокола SSL/TLS. Таким образом, возникает разрыв в процедурах обеспечения безопасности данных, циркулирующих между телефоном и WAPсервером (см. рис. 3).
Указанная проблема успешно решается в реализации WAP 2.0, где предусмотрена возможность переадресации сотового телефона с публичного шлюза WAP Gateway на выделенный шлюз WAP Gateway эмитента мидлета. Отмеченная проблема отсутствует в случае использования протокола HTTPS для загрузки мидлета. В этом случае HTTPS-соединение устанавливается непосредственно между телефоном и загрузочным сервером.
2. Ключ Customer Master Key зашифрован с помощью процедуры PBE, в основе которой лежит алгоритм 3DES.
3. Мидлет (файл формата Jar) передается на телефон, будучи уже подвергнутым процедуре обфускации (obfuscation), назначение которой заключается в сжатии данных, а также переименовании переменных мидлета и даже изменении последовательности команд в тексте программы. Другими словами, мошенник, перехвативший Jar-файл, подвергшийся процедуре обфускации, не сможет в нем разобраться (декомпилировать), имея в своем распоряжении только декомпилятор Java.
4. Перехваченный мошенниками мидлет нельзя использовать на другом телефоне. Дело в том, что мидлет работает таким образом, что для расшифрования ключа используется номер телефона, который мидлет находит самостоятельно на телефоне, пользуясь стандартными средствами MIDP. Поэтому, даже зная ПИНкод клиента, потребуется модификация мидлета для его использования на другом телефоне. Эта модификация будет заключаться в подстановке значения номера телефона, для которого предназначался перехваченный мидлет.
Но и модификация мидлета, связанная с подстановкой «правильного» номера телефона, не всегда поможет мошенникам. Например, в случае попытки несанкционированно использовать приложения мобильного банкинга. Дело в том, что общение мидлета для мобильного банкинга с сервером аутентификации происходит с помощью SMS-сообщений. Адрес отправителя сообщения вставляется в заголовок SMS-сообщения не телефоном, а SMS-центром. Поэтому тот факт, что правильная криптограмма получена с неверного телефона, будет выявлен сервером аутентификации клиента. Таким образом, возможна такая организация аутентификации пользователя, при которой воспользоваться украденными с телефона пользователя данными преступники смогут, только имея инсайдера в SMS-центре сотового оператора, что на практике делает такого рода атаки труднореализуемыми. Отметим, что этот вывод справедлив и в случае компрометации ключа Customer Master Key. Воспользоваться скомпрометированным ключом возможно, только генерируя SMS-сообщение с паролем OTP в SMS-центре любого сотового оператора.
5. Другой способ компрометации данных мидлета – перехват значения разового пароля OTP, сформированного мидлетом, для которого, в свою очередь, ранее удалось перехватить зашифрованное значение Customer Master Key. Тогда перебором всех возможных значений мобильного ПИН-кода можно будет определить те его значения, при которых на получившемся в результате расшифрования значении Customer Master Key формируется перехваченное значение OTP. Можно показать, что вероятность того, что в результате перебора перехваченное значение OTP будет соответствовать не более чем K различным значениям ПИН-кода, равна:
,
где n – общее число различных значений мобильного ПИН-кода (при 4-значном цифровом значении ПИН-кода n=104), p – вероятность получить одно из n=108 равновероятных значений OTP. Подстановкой значений n и p в приведенное выше выражение легко убедиться: вероятность того, что перехваченному значению OTP соответствует единственное значение ПИН-кода (K=1), равна примерно 0,9999. Еще раз повторим, что в ряде приложений, в которых значение OTP передается на сервер аутентификации в SMSсообщении, воспользоваться полученным в результате описанной атаки значением ключа Customer Master Key можно, только вводя SMS-сообщение непосредственно в SMS-центре.
Рассмотрим теперь возможности компрометации конфиденциальных данных, хранящихся в памяти самого телефона, после того как Jar-файл будет установлен на мобильном телефоне в виде Jad-файла. При инсталляции мидлета создается файл, который хранит данные, связанные с мидлетом и, в частности, зашифрованное значение Customer Master Key. Система управления файлами среды J2ME обеспечивает возможность доступа к файлам, порождаемым при загрузке мидлета на телефоне, только из данного мидлета. В соответствии с руководством Best Practices Guide for MMA, подготовленным MasterCard, мидлет должен очищать использовавшуюся им память телефона при окончании своей работы. Кроме того, изображение пароля на дисплее телефона должно автоматически исчезать по прошествии 60/120 секунд с начала его отображения.
И все-таки на телефон, как и на персональный компьютер, может быть загружен вирус, способный отслеживать данные, находящиеся в оперативной памяти телефона, и передавать их мошенникам для анализа. Нужно отметить, что сегодня в мире насчитывается всего 30–40 вирусов, разработанных для сотовых телефонов (например, БД вирусов для персональных компьютеров насчитывает несколько сотен тысяч вирусов). Ни один из них не работает так, как описано выше. Кроме того, как уже отмечалось, для некоторых приложений (мобильный банкинг/мобильная коммерция) существует возможность так организовать аутентификацию пользователя, что воспользоваться данными, полученными в результате атаки на память телефона, можно будет только с помощью инсайдера в SMS-центре сотового оператора, что позволяет рассматривать вероятность практической реализации как крайне невысокую.
Таким образом, реальными являются только угрозы перехвата значения OTP при уже известном мошенникам значении зашифрованного ключа Customer Master Key, а также загрузка вирусов-шпионов на сотовый телефон. Переоценивать значимость этих угроз не следует. На этом фоне можно со всей уверенностью утверждать, что доступ к информации о счетах клиентов, а также операции на ограниченные суммы вполне могут быть безопасно выполнены с использованием удобной и практичной технологии мидлетов. В то же время, чтобы окончательно устранить перечисленные нами проблемы обеспечения безопасности, существует возможность использования бесконтактной карты, поддерживающей стандарт ISO 14443 Type A, вместе с сотовым телефоном стандарта NFC (ISO18092/ECMA-340). В этом случае все криптографические функции и хранение ключей выполняются картой, а телефон используется как эмулятор платежного терминала, ведущего диалог с картой, и как средство отображения результатов вычислений карты. В этом случае на телефон загружается мидлет, не хранящий никакой секретной информации даже в зашифрованном виде. Уже сегодня на рынке имеются телефоны моделей Nokia 3220 и 6131, Samsung D500 и Onyx700, BENQ M700 и T80, поддерживающие NFC, которые можно было бы использовать в качестве устройства аутентификации. Однако, к сожалению, таких телефонов выпущено пока мало (несколько десятков миллионов), как, впрочем, и бесконтактных карт. По всей видимости, некая «критическая масса» телефонов и карт будет достигнута в течение 3–5 лет. При этом уже на конец 2006г. было выпущено 170 млн. NFC-чипов, из которых 30 млн. – для сотовых телефонов. Согласно некоторым прогнозам, уже к концу 2011г. во всем мире стандарт NFC будут поддерживать полмиллиарда (или каждый шестой) сотовых телефонов.
Игорь Голдовский, генеральный директор ЗАО "Платежные технологии"
Как известно, аутентификация является важнейшим элементом практически любой современной информационной системы, будь то СУБД, система электронной почты, Интернет-банкинг, электронная коммерция или иной канал предоставления услуг. При этом всякий раз, когда услуга (сервис) ограничена в использовании, необходимо проверить факт того, что лицо, запрашивающее эту услугу или сервис, имеет право на ее получение. А для этого необходимо сначала выполнить аутентификацию этого лица, т. е. доказать, что лицо, называющее себя субъектом Х, таковым и является, а затем проверить доступность запрашиваемой услуги субъекту Х.
В банковской сфере, и в карточных технологиях в частности, аутентификация клиента банка требуется буквально на каждом шагу и имеет самые разнообразные формы в зависимости от используемого клиентом канала доставки удаленных банковских услуг. Например, для аутентификации клиента при выполнении им операции снятия денег в банкомате применяется ПИН-код, для блокировки/разблокирования карты или при получении услуг через телефонный банкинг используются кодовые слова (буквенные последовательности, представляющие собой понятные при телефонном разговоре слова), в электронной (мобильной) коммерции (банкинге) часто применяются статические пароли (буквенно-цифровые последовательности, вводимые с клавиатуры компьютера/телефона).
В последние годы в подходах банков к построению систем мобильного банкинга произошли серьезные перемены. Если ранее в качестве единственно возможного с точки зрения безопасности решения рассматривалось использование SIM-карты как средства хранения приложения и секретных клиентских данных, то теперь набирают обороты проекты, в которых используются специальные программы-мидлеты, реализующие функции мобильного банкинга на стороне телефона и хранящие зашифрованные данные, которые используются для аутентификации держателя мидлета
В последнее время в вопросах аутентификации клиента со стороны эмитентов четко прослеживаются две тенденции:
• стремление унифицировать процедуру аутентификации для всех каналов доставки клиентам услуг;
• недоверие к статическим паролям (наиболее массовому способу аутентификации клиента) как к наименее надежному методу аутентификации.
Первая тенденция очевидна. Клиент заинтересован в использовании единой процедуры своей идентификации/аутентификации для доступа к широкому спектру услуг, что значительно упрощает его жизнь – не нужно запоминать многочисленные пароли/коды/идентификаторы для работы со всей инфраструктурой, требующей его аутентификации, – с корпоративной почтой, системой Интернет-банкинга и т.п. Вторая тенденция также понятна. Статический пароль выдается однажды на значительный период времени и может быть скомпрометирован, а стало быть, использован мошенниками для получения услуги от лица законного клиента.
Скомпрометировать пароль можно разными способами. Например, целый спектр уловок, используемых преступниками для компрометации ПИН-кода (цифрового пароля), подробно рассмотрен в материале автора настоящей статьи «О путешествии ПИН-кода из ПИН-пада терминала в HSM эмитента» (см. ПЛАС №2/2007). Пароль, вводимый на клавиатуре компьютера, может быть скомпрометирован, например, с помощью специальных программ-шпионов (spyware), загруженных на компьютер клиента и отслеживающих данные, набираемые клиентом на клавиатуре компьютера (keyboard logger) и/или отображаемые на экране компьютера (screen logger). Бичом последних лет стал фишинг (phishing), при котором мошенники, используя психологические методы воздействия, выманивают конфиденциальную информацию непосредственно у самого пользователя с помощью «фишинговых» рассылок по электронной почте и т.д.
В специальных схемах могут применяться и более изощренные технологии кражи паролей. Например, при использовании держателем карты протокола 3D Secure мошеннические онлайновые магазины могут применять следующую процедуру компрометации статического пароля (данная процедура позволяет также компрометировать одно значение динамического пароля, однако последнее не имеет столь драматичных последствий, как в случае статического пароля) (см. рис. 1). 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 Worldwide и принятый для использования в рамках Visa Int. под брендом Dynamic Passcode Authentication (DPA).
Для реализации метода CAP клиент должен обладать микропроцессорной картой с EMV-приложением, а также специальным картридером, способным инициировать генерацию пароля OTP и отображать его значение, состоящее из 8 цифр, на дисплее ридера. Такой ридер может стоить несколько евро (10–15 евро в зависимости от производителя и объема закупаемой партии устройств). Помимо дополнительных расходов на обеспечение ридерами держателей карт, другим недостатком такого подхода является тот факт, что за картридером клиенту необходимо прийти в банк, а кроме того, для совершения операции ридер нужно иметь под рукой, что не всегда удобно, поскольку размеры устройства значительно превышают размеры банковской карты и в бумажнике такой ридер не помещается.
На этом фоне сотовый телефон, являясь наиболее массовым мобильным устройством, используемым населением планеты (по результатам 2005г., во всем мире обращалось более 2 млрд. сотовых телефонов, а к 2010г. это устройство будут иметь примерно 3 млрд. потребителей), давно привлекал внимание исследователей в качестве потенциального универсального инструмента аутентификации. Тем более что возможности мобильных телефонов как с точки зрения их вычислительных способностей, поддерживаемых коммуникационных протоколов, так и с точки зрения функциональности постоянно растут.
Сложность использования мобильного телефона в качестве инструмента аутентификации заключается в следующем. Всем известно, что по-настоящему защищенным местом хранения конфиденциальной информации на телефоне является SIM-карта (некоторые модели телефонов обладают отдельным микропроцессором, выполняющим функцию элемента безопасности – Security Element; но таких моделей пока очень мало). Однако загрузить любую информацию на SIM-карту можно только с разрешения контролирующего ее оператора сотовой связи.
При этом, даже если последний разрешит загрузку и использование конфиденциальной информации клиента на SIM-карте, единственно возможным способом реализовать это на практике является предварительная загрузка данных на SIM-карту в процессе ее персонализации силами оператора или уполномоченного им центра персонализации. Удаленная персонализация SIM-карты по технологии overtheair (OTA – GSM 03.48), предназначенная для загрузки данных и приложений на SIM-карту и поддерживаемая всеми Javaкартами, персонализированными с поддержкой профиля OTA profile, на практике фактически не используется, поскольку в этом случае банк должен делить свою конфиденциальную информацию с сотовым оператором. Дело в том, что процедура загрузки данных по технологии OTA сегодня находится под полным контролем оператора мобильной связи.
То же самое справедливо и в отношении технологии, основанной на использовании протокола Security and Trusted Services API (SATSA, JSR177), позволяющей мидлету пользоваться процедурами и данными, загруженными на SIM-карту, поддерживающую Java Card (таких SIMкарт сегодня большинство). Помимо того что спецификация JSR177 является опциональной для профиля MIDP 2.0 (Mobile Information Device Profile 2.0) платформы J2ME и потому сотовыми телефонами практически не поддерживается, со стороны сотового оператора по-прежнему требуется авторизация доступа мидлета к приложениям карты.
Между тем в последние годы в подходах банков к построению систем мобильного банкинга произошли серьезные перемены. Если ранее в качестве единственно возможного с точки зрения безопасности решения рассматривалось использование SIM-карты как средства хранения приложения и секретных клиентских данных, то теперь набирают обороты проекты, в которых используются специальные программы-мидлеты, реализующие функции мобильного банкинга на стороне телефона и хранящие зашифрованные данные, которые используются для аутентификации держателя мидлета. Такие мидлеты хранятся в памяти телефонного аппарата и не загружаются на SIM-карту.
Безусловно, технология SIM-карты с точки зрения использования SIM-карты в качестве средства хранения приложений и конфиденциальных данных, является более надежной и безопасной. С другой стороны, эта технология, как было отмечено ранее, требует от клиента посещения отделения своего банка и замены SIM-карты на карту, содержащую предустановленное на нее приложение (как следствие, в ряде случаев – и замену телефонного номера клиента). Кроме того, как уже отмечалось, ридер обойдется клиенту/банку примерно в 10–15 евро. Технология мидлетов также имеет свои ограничения. Она может использоваться только на Java-совместимых телефонах, поддерживающих протоколы безопасной связи WTLS и/или HTTPS и, желательно, достаточно высокоскоростной транспортный протокол (GPRS или даже EDGE) для защищенной загрузки мидлетов на телефон. И в то же время у технологии мидлета имеются такие очевидные преимущества, как:
• независимость эмитента приложений (мидлетов) от операторов сотовой связи;
• простота загрузки/удаления новых приложений;
• возможность использования разнообразных недорогих средств загрузки мидлета: GPRS, EDGE, USSD, Bluetooth, IrDA, NFC и т.п.;
• возможность широкого использования мультимедийных ресурсов телефона.
В основе технологии мидлета лежит протокол аутентификации клиента MasterCard Mobile Authentication (MMA). Суть протокола MMA состоит в следующем. На сотовые телефоны клиентов загружаются специальные программы-мидлеты (Java-приложения для профиля MIDP/JTWI/MSA операционной платформы J2ME сотового телефона). Размер такого мидлета – 20 КБ и более (в соответствии с рекомендациями MasterCard размер мидлета MMA не должен превышать 35 КБ). Поэтому надежно передать его с помощью SMS-сообщений не получится. Потребуется отправить более 140 сообщений, что снижает надежность передачи мидлета и увеличивает время его загрузки до часто неприемлемых значений. Кроме того, хотя теоретически и возможно передавать сообщение в виде последовательности до 255 SMS-сообщений, но на практике размер сообщения, передаваемого по технологии SMS, не превышает 6–8 SMS-сообщений. Сегодня наиболее распространенным способом загрузки мидлетов является метод WAP/GPRS. Технологии WAP и GPRS предоставляются всеми крупнейшими операторами сотовой связи. Более того, операторы оказывают услуги по удаленному конфигурированию WAP/GPRS в ответ на запрос SIM-карты/телефона клиента с учетом используемой клиентом модели сотового телефона. Кроме протоколов WAP/GPRS для загрузки мидлета могут использоваться схемы WAP/EDGE и WAP/USSD. Кроме того, загрузка мидлета может быть выполнена с использованием протокола HTTPS, который является стандартной функцией MIDP 2.0.
При использовании протокола WAP для обеспечения безопасности загрузки мидлета (аутентификации источника мидлета, обеспечения целостности и конфиденциальности данных мидлета) устанавливается защищенное соединение, реализуемое по протоколу WTLS (беспроводная версия протокола SSL). На WAP-сервере, поддерживающем загрузку персонализированных мидлетов, размещается сертификат открытого ключа типа WTLS Class 3 Server Certificate, полученный от одного из признанных международных центров сертификации (например, от Verisign, Thawte и т. п.). Открытые ключи наиболее известных публичных центров сертификации находятся на всех телефонах, поддерживающих WAP.
Сегодня многие телефоны способны поддерживать протокол HTTPS (J2MEсовместимые телефоны, поддерживающие MIDP 2.0). В этом случае безопасная загрузка мидлета может быть выполнена с использованием этого протокола. Более того, как будет показано ниже, загрузка мидлета с помощью HTPPS является более надежной и простой в реализации. Для реализации процедур аутентификации клиентов банка загружаемые мидлеты используют стандарт MasterCard Mobile Authentication, реализующий алгоритм CAP (Chip Authentication Program) с использованием вычислительных и операционных средств сотового телефона. На входе алгоритма задаются текущий номер операции (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, который в общих словах задает открытый интерфейс к библиотекам J2ME на сотовых телефонах и других устройствах. При формировании ключа в алгоритме PBE (для шифрования данных применяется алгоритм 3DES) в качестве пароля используется специальный, т. н. мобильный ПИН-код клиента, в качестве величины Salt – номер телефона (MSISDN). Мобильный ПИН-код клиента придумывается последним один раз и используется им каждый раз при инициализации мидлета на своем телефоне. Вводимое клиентом значение мобильного ПИН-кода необходимо для расшифрования ключа Customer Master Key, который хранится в телефоне в зашифрованном виде.
Поэтому при вводе неправильного значения ПИН-кода в результате расшифрования будет получено неверное значение ключа Customer Master Key, а значит, будет вычислено неверное значение криптограммы AAC и разового пароля. Последний факт будет зафиксирован на сервере аутентификации клиента. Таким образом, надежность описанной схемы главным образом определяется секретностью мобильного ПИН-кода клиента. Если телефон попадает в руки мошенника, не знающего значение ПИН-кода, то после трех безуспешных попыток аутентификации (неверного значения вычисленной криптограммы) клиент будет заблокирован на сервере аутентификации, и дальнейшее использование мидлета станет невозможным.
Для регистрации клиента кредитно-финансового института для последующего предоставления ему мидлета могут использоваться различные схемы, например, с применением автоматизированного устройства банковского самообслуживания или системы Интернет-банкинга (см. рис. 2). Например, при использовании системы Интернет-банкинга клиент после выполнения процедуры аутентификации на соответствующей web-странице сайта банка выбирает операцию «Покупка универсального ПИН-кода», вводит номер своего телефона, модель телефона, название оператора сотовой связи и «мобильный ПИНкод». Предполагается, что реквизиты платежной карты клиента уже введены при его подключении к Интернет-банкингу. После этого клиент ждет, когда ему на телефон придет SMS-сообщение с адресом URL загрузочного сервера (так называемый downloading ticket), на котором располагается персонализированный для клиента мидлет. Когда сообщение приходит, клиент его открывает и активирует соединение с сервером по URL в отображаемом на экране телефона SMS-сообщении. В результате телефон клиента подключается к серверу, с которого на него по протоколам WAP/GPRS или HTTPS/SOAP/XML загружается предназначенный клиенту и соответствующим образом персонализированный мидлет. В результате в меню телефона появляется иконка, соответствующая загруженному мидлету.
Следует отметить, что название оператора связи и модель сотового телефона необходимы серверу для того, чтобы, вопервых, выбрать коммуникационный протокол для загрузки мидлета (GPRS, EDGE, USSD и т.п.), а, во-вторых, подготовить сборку мидлета с учетом особенностей реализации J2ME (у разных производителей имеются небольшие различия) и ограничений на размер памяти конкретной модели телефона, находящегося в распоряжении клиента.
Время ожидания клиентом прихода сообщения на телефон клиента с момента заказа мидлета в банкомате или через систему Интернет-банкинга зависит от способа реализации данной схемы в конкретном банке. Процедуру заказа можно сделать почти онлайновой, если подключить загрузочный сервер к карточному процессингу банка / сайту банка с помощью онлайнового интерфейса. Если загрузочный сервер общается с процессингом в режиме offline (наиболее простая реализация), то загрузка мидлета будет выполняться в офлайновом режиме.
Для генерации разового пароля OTP клиент входит в меню телефона и выбирает иконку мидлета. После открытия мидлета на экране телефона появляется окошко, призывающее клиента ввести его мобильный ПИН-код. После ввода ПИНкода на экране телефона появляется 8-значное цифровое значение вычисленного OTP. Значение OTP определяется в соответствии со стандартом Chip Authentication Program, признанным MasterCard Worldwide и Visa Int.
Клиент может использовать OTP для доступа к самым разнообразным каналам доставки услуг. Например, для предоставления доступа к услугам Интернет-банкинга система запрашивает у клиента разовый пароль, он вычисляет его на телефоне описанным выше способом и набирает в соответствующем окне web-страницы аутентификации клиента в системе Интернет-банкинга. При этом сервер Интернетбанкинга обращается к серверу аутентификации за проверкой разового пароля. Итак, мы рассмотрели процесс загрузки и использования мидлета для аутентификации клиента. Совершенно аналогично можно загрузить мидлет, предназначенный для мобильного банкинга. Функция аутентификации клиента является составной частью мидлета мобильного банкинга. С помощью мидлета мобильного банкинга можно через меню телефона выбрать нужную операцию (просмотр остатка на счете, информации по нескольким последним операциям, перевод денег с одного счета на другой, блокирование карты, блокирование счета и т. п.), задать ее параметры и выполнить. При этом конфиденциальность обмена данными с сервером мобильного банкинга обеспечивается средствами мидлета!
Проведем краткий анализ уровня безопасности, обеспечиваемого при использовании рассмотренной нами схемы MMA. Очевидно, что наиболее уязвимыми с точки зрения защиты конфиденциальной информации, хранящейся в мидлете, моментами являются процесс передачи мидлета на телефон и возможные атаки мошенников с целью получить несанкционированный доступ к конфиденциальным данным, хранящимся в памяти самого телефона. Рассмотрим каждый из этих моментов в отдельности.
Передача мидлета на телефон. Здесь существуют следующие механизмы защиты.
1. Как уже говорилось, мидлет может загружаться на телефон с использованием средств WTLS, обеспечивающих аутентификацию источника мидлета, целостности и конфиденциальности данных мидлета. В протоколе WTLS в реализации WAP 1.0 известна следующая «дыра». WAP-сервер общается с телефоном не напрямую, а через шлюз WAP Gateway, осуществляющий переформатирование данных из форматов WML (язык представления данных в WAP) в форматы HTML, и наоборот. Шлюз WAP Gateway также устанавливает безопасное соединение с WAP-сервером через Интернет на основе протокола SSL/TLS. Таким образом, возникает разрыв в процедурах обеспечения безопасности данных, циркулирующих между телефоном и WAPсервером (см. рис. 3).
Указанная проблема успешно решается в реализации WAP 2.0, где предусмотрена возможность переадресации сотового телефона с публичного шлюза WAP Gateway на выделенный шлюз WAP Gateway эмитента мидлета. Отмеченная проблема отсутствует в случае использования протокола HTTPS для загрузки мидлета. В этом случае HTTPS-соединение устанавливается непосредственно между телефоном и загрузочным сервером.
2. Ключ Customer Master Key зашифрован с помощью процедуры PBE, в основе которой лежит алгоритм 3DES.
3. Мидлет (файл формата Jar) передается на телефон, будучи уже подвергнутым процедуре обфускации (obfuscation), назначение которой заключается в сжатии данных, а также переименовании переменных мидлета и даже изменении последовательности команд в тексте программы. Другими словами, мошенник, перехвативший Jar-файл, подвергшийся процедуре обфускации, не сможет в нем разобраться (декомпилировать), имея в своем распоряжении только декомпилятор Java.
4. Перехваченный мошенниками мидлет нельзя использовать на другом телефоне. Дело в том, что мидлет работает таким образом, что для расшифрования ключа используется номер телефона, который мидлет находит самостоятельно на телефоне, пользуясь стандартными средствами MIDP. Поэтому, даже зная ПИНкод клиента, потребуется модификация мидлета для его использования на другом телефоне. Эта модификация будет заключаться в подстановке значения номера телефона, для которого предназначался перехваченный мидлет.
Но и модификация мидлета, связанная с подстановкой «правильного» номера телефона, не всегда поможет мошенникам. Например, в случае попытки несанкционированно использовать приложения мобильного банкинга. Дело в том, что общение мидлета для мобильного банкинга с сервером аутентификации происходит с помощью SMS-сообщений. Адрес отправителя сообщения вставляется в заголовок SMS-сообщения не телефоном, а SMS-центром. Поэтому тот факт, что правильная криптограмма получена с неверного телефона, будет выявлен сервером аутентификации клиента. Таким образом, возможна такая организация аутентификации пользователя, при которой воспользоваться украденными с телефона пользователя данными преступники смогут, только имея инсайдера в SMS-центре сотового оператора, что на практике делает такого рода атаки труднореализуемыми. Отметим, что этот вывод справедлив и в случае компрометации ключа Customer Master Key. Воспользоваться скомпрометированным ключом возможно, только генерируя SMS-сообщение с паролем OTP в SMS-центре любого сотового оператора.
5. Другой способ компрометации данных мидлета – перехват значения разового пароля OTP, сформированного мидлетом, для которого, в свою очередь, ранее удалось перехватить зашифрованное значение Customer Master Key. Тогда перебором всех возможных значений мобильного ПИН-кода можно будет определить те его значения, при которых на получившемся в результате расшифрования значении Customer Master Key формируется перехваченное значение OTP. Можно показать, что вероятность того, что в результате перебора перехваченное значение OTP будет соответствовать не более чем K различным значениям ПИН-кода, равна:
,
где n – общее число различных значений мобильного ПИН-кода (при 4-значном цифровом значении ПИН-кода n=104), p – вероятность получить одно из n=108 равновероятных значений OTP. Подстановкой значений n и p в приведенное выше выражение легко убедиться: вероятность того, что перехваченному значению OTP соответствует единственное значение ПИН-кода (K=1), равна примерно 0,9999. Еще раз повторим, что в ряде приложений, в которых значение OTP передается на сервер аутентификации в SMSсообщении, воспользоваться полученным в результате описанной атаки значением ключа Customer Master Key можно, только вводя SMS-сообщение непосредственно в SMS-центре.
Рассмотрим теперь возможности компрометации конфиденциальных данных, хранящихся в памяти самого телефона, после того как Jar-файл будет установлен на мобильном телефоне в виде Jad-файла. При инсталляции мидлета создается файл, который хранит данные, связанные с мидлетом и, в частности, зашифрованное значение Customer Master Key. Система управления файлами среды J2ME обеспечивает возможность доступа к файлам, порождаемым при загрузке мидлета на телефоне, только из данного мидлета. В соответствии с руководством Best Practices Guide for MMA, подготовленным MasterCard, мидлет должен очищать использовавшуюся им память телефона при окончании своей работы. Кроме того, изображение пароля на дисплее телефона должно автоматически исчезать по прошествии 60/120 секунд с начала его отображения.
И все-таки на телефон, как и на персональный компьютер, может быть загружен вирус, способный отслеживать данные, находящиеся в оперативной памяти телефона, и передавать их мошенникам для анализа. Нужно отметить, что сегодня в мире насчитывается всего 30–40 вирусов, разработанных для сотовых телефонов (например, БД вирусов для персональных компьютеров насчитывает несколько сотен тысяч вирусов). Ни один из них не работает так, как описано выше. Кроме того, как уже отмечалось, для некоторых приложений (мобильный банкинг/мобильная коммерция) существует возможность так организовать аутентификацию пользователя, что воспользоваться данными, полученными в результате атаки на память телефона, можно будет только с помощью инсайдера в SMS-центре сотового оператора, что позволяет рассматривать вероятность практической реализации как крайне невысокую.
Таким образом, реальными являются только угрозы перехвата значения OTP при уже известном мошенникам значении зашифрованного ключа Customer Master Key, а также загрузка вирусов-шпионов на сотовый телефон. Переоценивать значимость этих угроз не следует. На этом фоне можно со всей уверенностью утверждать, что доступ к информации о счетах клиентов, а также операции на ограниченные суммы вполне могут быть безопасно выполнены с использованием удобной и практичной технологии мидлетов. В то же время, чтобы окончательно устранить перечисленные нами проблемы обеспечения безопасности, существует возможность использования бесконтактной карты, поддерживающей стандарт ISO 14443 Type A, вместе с сотовым телефоном стандарта NFC (ISO18092/ECMA-340). В этом случае все криптографические функции и хранение ключей выполняются картой, а телефон используется как эмулятор платежного терминала, ведущего диалог с картой, и как средство отображения результатов вычислений карты. В этом случае на телефон загружается мидлет, не хранящий никакой секретной информации даже в зашифрованном виде. Уже сегодня на рынке имеются телефоны моделей Nokia 3220 и 6131, Samsung D500 и Onyx700, BENQ M700 и T80, поддерживающие NFC, которые можно было бы использовать в качестве устройства аутентификации. Однако, к сожалению, таких телефонов выпущено пока мало (несколько десятков миллионов), как, впрочем, и бесконтактных карт. По всей видимости, некая «критическая масса» телефонов и карт будет достигнута в течение 3–5 лет. При этом уже на конец 2006г. было выпущено 170 млн. NFC-чипов, из которых 30 млн. – для сотовых телефонов. Согласно некоторым прогнозам, уже к концу 2011г. во всем мире стандарт NFC будут поддерживать полмиллиарда (или каждый шестой) сотовых телефонов.
