Финансовая сфера

Банковское обозрение


  • Оплата с помощью смартфона
03.11.2015 Аналитика

Оплата с помощью смартфона

В конце лета компании QIWI и VISA Inc. произвели интеграцию технологии бесконтактных платежей Visa payWave в функционал кошелька Visa QIWI Wallet. Обновленное приложение электронного кошелька поддерживает технологию Host Card Emulation (HCE)


Повсеместное внедрение HCE на уровне банковских процессингов и карточных устройств началось относительно недавно. В феврале 2014 года компания VISA была в числе первых, объявивших о поддержке технологии на международном уровне. В процессе интеграции технологий бесконтактной оплаты в функционал Visa QIWI Wallet были выработаны и по возможности учтены best-practice в обновленной архитектуре приложения и требований к защите продукта.

Новая технология, которая предлагает безопасный способ проведения бесконтактных платежей с помощью приложений, разработанных и размещенных на Android-устройствах, была представлена компанией Visa на Всемирном мобильном конгрессе в 2014 году. Благодаря этому финансовые организации получили возможность использовать преимущества технологии Host Card Emulation (HCE), являющейся новой функциональной возможностью операционной системы Android и позволяющей NFC-приложениям эмулировать смарт-карту на Android-устройствах. В течение последующих нескольких месяцев и другие производители мобильных операционных систем объявили о том, что новые версии также будут поддерживать NFC и HCE.

СПРАВКА Б.О
НСЕ-технология дает возможность передачи данных по набору протоколов Near Field Communication (NFC) между мини-терминалом оплаты и приложением для мобильного устройства, эмулирующего работу NFC-карты. В приложении QIWI-кошелька реализована эмуляция работы бесконтактной банковской карты PayWave от Visa.

Сегодня технологии бесконтактной оплаты быстро набирают популярность и активно входят в нашу жизнь. В 2015 году, по прогнозам аналитиков, будет продано почти 600 млн телефонов с поддержкой NFC и HCE . Объемы бесконтактных платежей в мире уже сейчас исчисляются миллиардами долларов. Пример QIWI делает доступным для российских пользователей эту перспективную и удобную технологию для совершения ежедневных покупок.

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

СПРАВКА Б.О
Создание инновационных продуктов и сервисов в банковской и околобанковской сферах всегда закладывает определенные ресурсы на разработку новых требований информационной безопасности. Функционал и контент мобильного платежного приложения подразумевает полноценную работу с персональными данными пользователя, его счетами, балансами карт, паспортными данными и др.

Для успешной реализации проекта было необходимо не только разработать внутренний набор требований информационной безопасности, но и следовать требованиям, разработанным компанией VISA: стандартам и спецификациям проведения бесконтактных платежей, безопасности облачных платежных систем и банковских мобильных приложений.

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

Во многом безопасность данных пользователя зависит от самого пользователя, от его действий. В случае, если он параллельно с множеством уже существующих приложений без вопросов устанавливает очередную мобильную игру из ненадежных источников, не читая описание запрашиваемых приложением полномочий, он сразу попадает в зону риска. Любимый пример security-экспертов — приложение «фонарик», которое при установке просит предоставить доступ к контактам, sms-сообщениям, памяти устройства, сетям, модулю NFC, и, соглашаясь с требованиями, пользователь открывает доступ к своей приватной информации.

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

Технология HCE на данный момент поддерживается только операционной системой Android, в ее контексте далее и пойдет речь.

Мобильные платформы продолжают развиваться, они давно превысили изначально закладываемые в них функции, и по уровню требований к безопасности системы уже сравнимы с настольными платформами. Типы уязвимостей под мобильные ОС уже выделяют в отдельный классификатор, один из них — OWASP Mobile Security Project топ-10. Причинами появления описываемых в нем рисков могут быть:

— стремительные изменения самой платформы (за последние три года — смена ядра, архитектуры, добавление большого количества функциональности в API), при этом очень много устройств так и остаются на старых версиях ОС, а их популярность не так стремительно падает — почти половина устройств в мире еще работает на версии Android 4.3 (выпущена в середине 2013 года) и ниже;

— плохая поддержка со стороны производителей устройств: многие из них не выпускают даже критичные обновления безопасности для устройств которым больше одного-двух лет;

— специфика архитектуры безопасности платформы: в архитектуру iOS и Windows Phone изначально закладывали подход с изолированной средой для каждого приложения, когда приложение имеет доступ только к выделенным для него директориям, файлам, хранилищам, в Andoird такой принцип появился лишь в версии 5.0;

— малое количество информации, исследований о защите приложений: всего известно порядка 2000 уязвимостей под Android, большую часть запротоколировали лишь в 2014 году, но и до сегодняшнего дня находятся 0-day уязвимости (Stagefright), при этом в классификаторе CVE сейчас описано лишь 54 бюллетеня для ОС Android, против 605 под iOS;

— недостаточная осведомленность разработчиков приложений о безопасности мобильных систем в виду частых изменений, когда многие аспекты устаревают, добавляются новые: порядка 40% коммерческих организаций не уделяет внимание безопасности своих мобильных приложений, в том числе и банки.

Конечный разработанный ряд требований к мобильному приложению мы выделили в отдельные группы.

1. Надежность канала передачи данных и SSL-pinning.

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

— принудительно выбирать наиболее надежный протокол передачи данных, предоставляемый сервером. Это исключает потенциальные атаки с понижением версии протокола (прим. SSL3 POODLE);

— проверять валидность серверного SSL-сертификата. Здесь был применен подход SSL-pinning — ассоциация сервера с его ожидаемым сертификатом. Приложение, зная адрес сервера, к которому обращается, также знает SSL-сертификат, с которым должен ответить сервер. Приложение игнорирует хранилище сертификатов устройства и доверяет только прописанному в нем самом источнику. Этот прием во многом помогает предотвратить возможность перехвата трафика (MitM-атаки), исключением будут вредоносные программы, отслеживающие и подменяющие сертификат локально на устройстве.

2. Хранение, шифрование и целостность данных.

В классификаторе OWASP Mobile топ-10 одна из самых распространенных уязвимостей — это небезопасное хранение так называемых чувствительных данных. Иными словами, хранение их в ненадежных источниках, недостаточное или полное отсутствие шифрования, наличие приватной информации в ресурсах, файлах конфигурации, излишнее хранение данных. Для Android-устройств это может быть база данных SQLite, логи приложения, дамп памяти.

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

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

3. Root, Debug, Emulation.

Требование, препятствующее изменению и распространению ложного приложения, которое должно блокировать часть функциональности, ответственную за работу наиболее критичного к защите компонента — самой функции HCE. Основная особенность простоты выполнения бесконтактного платежа накладывает серьезные обязательства по предотвращению внесения изменений в исходные данные и коды.

Root. Телефон с повышенными привилегиями доступа открывает возможность влияния на глобальный контекст операционной системы, т. е. доступ к контейнерам данных, внесение изменений на уровне платформы/ядра устройства. В случае QIWI возможность отслеживания повышенных привелегий пользователя может предотвратить, например, непреднамеренное включение опции бесконтактной оплаты, кражи аутентификационного ключа.

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

4. Контрольная сумма.

В ОС Android для совершения успешной атаки на клиентское приложение иногда достаточно изменить манифест приложения, не влезая в детальную реализацию кода. Ложно запущенная web-страница (WebView) может вести на фишинговые ресурсы.

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

5. Режим ожидания.

Особенность бесконтактных платежей состоит в отсутствии лишних действий при совершении транзакции. Это как преимущество для user-experience, так и недостаток для безопасности пользователя. Известны случаи, когда злоумышленники ходили в общественном транспорте со считывающим модулем в руках, эмулирующим работу POS-терминала. Прислоняя его к карманам пассажиров, они считывали данные с PayWave-карт жертв и тем самым проводили платеж.

Как компромиссное решение для обеспечения баланса безопасности и удобства пользования было поставлено требование: для совершения платежа необходимо минимальное действие со стороны пользователя — разблокировка устройства без необходимости входа в приложение.

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






Новости Релизы
Сейчас на главной

ПЕРЕЙТИ НА ГЛАВНУЮ