Как программная эмуляция карт (HCE) гарантирует безопасность NFC?

С введением HCE для эмуляции карты не требуется никакого элемента безопасности (SE). В результате нет места для хранения конфиденциальной информации приложения, эмулирующего карту, такой как баланс, CVV2, PIN-коды и т. д.

Я просто хочу знать, как андроид решает эту проблему? Где должна храниться конфиденциальная информация приложений? Использует ли Google Кошелек эту технологию? если да, то как обеспечивается безопасность конфиденциальной информации?

Обновление 1: некоторые ссылки в Интернете относятся к Cloud-Based SE (Cloud SE) при использовании HCE, но я не могу понять, что ТОЧНО делает этот Cloud SE. Любые ссылки, документы или дополнительные материалы по этой теме?


person Gupta    schedule 27.04.2014    source источник


Ответы (5)


Ключевая особенность HCE заключается в том, что, когда устройство NFC находится в режиме эмуляции карты (CEM), все данные, поступающие от контроллера NFC, по умолчанию направляются в ЦП устройства (читай ОС Android). Раньше такого не было, когда маршрутизация по умолчанию в CEM была направлена ​​на защищенный элемент (SE). Хранение конфиденциальных данных в памяти ОС вызывает серьезные проблемы с безопасностью — те, о которых вы спрашивали, — в случае, когда устройство «рутировано». Есть два способа уменьшить эти риски безопасности:

A) Обеспечить более безопасное место для конфиденциальных данных

Это «более безопасное место» может быть Trusted Execution Environment (TEE) — специальной частью ЦП, которая запускает свою собственную отдельную ОС и поэтому не подвергается риску, когда основная ОС рутируется. По шкале безопасности TEE обеспечивает большую безопасность, чем ОС и «SE в облаке», но меньшую, чем SE. Если TEE недостаточно (как в случае с такими услугами, как платежи без обратной связи, услуги аутентификации - удостоверения личности, паспорта), никто не запрещает вам использовать SE на телефоне, предоставляющем услугу HCE. В этом случае маршрутизация по умолчанию на ЦП (служба HCE для ОС Android) может быть предотвращена с помощью таблиц маршрутизации (данные, предназначенные для приложения с определенным AID, направляются в SE).

B) Внедрить механизм безопасности, чтобы сделать существующее местоположение более безопасным

Если у вас нет TEE и вы не можете использовать SE, вы можете сделать вещи более безопасными, используя такие методы, как: проверка пользователя (что-то, что «этот пользователь знает», например PIN-код, или, что еще лучше, если возможно, «что-то, что пользователь» - биометрия), ограничения транзакций (транзакции с низкой стоимостью, ограниченное количество транзакций за один период времени и т. д.), токенизация, выполнение ОС Android проверок предыдущей транзакции (т. е. есть ли у пользователя привилегии root) и т. д.

Лучше всего сочетать А и Б.

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

Вы можете прочитать больше об этом в документе, написанном Томом Янссеном и Марком Зандстра, людьми из UL-TS (бывший Коллис), под названием «Последствия безопасности HCE». Вы можете скачать его отсюда: http://www.ul-ts.com/downloads/whitepapers/finish/6-whitepapers/289-hce-security-implications.

person borko.lepojevic    schedule 03.05.2014
comment
Большое спасибо broko за ваш ответ и полезную ссылку. Как выглядит этот ТЭО? это сопроцессор (криптопроцессор), расположенный в процессоре телефона? Что вы подразумеваете под специальной частью ЦП, на которой работает отдельная ОС? Вы имеете в виду, что специальная часть ЦП работает под управлением собственной ОС? - person Gupta; 05.05.2014
comment
TEE — это концепция, определенная Global Platform. Реализации могут различаться. Идея состоит в том, чтобы хранить и выполнять конфиденциальные данные и приложения в пространстве, отделенном аппаратным обеспечением от незащищенной операционной системы. Предполагается, что TEE работает на основном процессоре устройства. Так что да, это своего рода сопроцессор внутри основного процессора. Проверьте эти документы и сайты, чтобы получить более полное представление: 1. globalplatform.org/documents/ 2. trustonic.com/products-services/trusted-execution-environment С уважением - person borko.lepojevic; 06.05.2014
comment
Броко спасибо за ответы. Знаете ли вы о каких-либо технических документах по кошельку Google и его рабочим протоколам? - person Gupta; 10.05.2014
comment
Я не особо изучал гугл-кошелек. Я думаю, что Майкл Роланд написал некоторую работу об ретрансляционной атаке на Google Wallet... С уважением - person borko.lepojevic; 11.05.2014

Я просто хочу знать, как Android решает эту проблему?

Простой ответ: нет. Google Wallet хранит данные карты (номер карты, информацию о сроке действия, динамический код проверки карты и т. д.) в памяти мобильного телефона (оперативная память, частично флэш-память?). Обратите внимание, что на кредитной карте не хранится информация о балансе. Google Wallet (на самом деле это MasterCard) также не хранит код CVC2 или PIN-код карты.

Где должна храниться конфиденциальная информация приложений? Использует ли Google Кошелек эту технологию?

Должен ... ну ... Он действительно хранит (временные) данные карты в ОЗУ и, возможно, во (внутренней) флэш-памяти телефона. Здесь обычно не используется защищенная память.

Если да, как обеспечивается безопасность конфиденциальной информации?

Это сложная часть. Вот тут-то и появляется облачная SE. Cloud SE означает, что конфиденциальные данные карты хранятся «в облаке», а не (или только временно) на устройстве конечного пользователя. На практике это может быть реализовано двумя способами:

  1. Облачный SE действует как обычная смарт-карта/защитный элемент. В этом случае приложение HCE на устройстве конечного пользователя будет немедленно перенаправлять все полученные команды смарт-карты (APDU) в «облако». Облачный SE обработает команду и сгенерирует ответ. Затем приложение отправляет этот ответ обратно на платежный терминал через интерфейс NFC (HCE). Основным недостатком этого сценария является то, что для связи HCE требуется стабильное (и относительно быстрое) соединение с «облаком» на протяжении всей связи.

  2. [Вот так работает Google Wallet.] Облачная SE действует как служба токенов, которая генерирует временные данные карты (временный номер карты и временные коды динамической проверки), которые действительны только для ограниченного числа транзакций и в течение очень ограниченного периода времени. . Всякий раз, когда срок действия этой временной информации истекает, приложение HCE запрашивает новый набор данных временной карты и сохраняет его в памяти телефона. Когда платежный терминал устанавливает соединение с приложением HCE (эмулированная кредитная карта), приложение взаимодействует с протоколом платежной карты (EMV) и встраивает временную информацию в данные эмулированной карты.

person Michael Roland    schedule 28.04.2014
comment
Спасибо, Майкл. Учитывая ваш опыт в области NFC и безопасности, не могли бы вы представить мне некоторые технические документы или ссылки по этой теме? Меня также интересуют безопасность NFC, мобильный кошелек и мобильная безопасность. Большое спасибо заранее. :) - person Gupta; 29.04.2014

Я не думаю, что Android «исправляет эту проблему» или даже собирается это сделать: это скорее задача разработчиков приложений. Возможные подходы:

  • Храните конфиденциальную информацию вне телефона: «SE в облаке». Очевидным недостатком является то, что телефон должен быть в сети, чтобы транзакция прошла успешно.
  • Генерируйте конфиденциальную информацию, обрабатывая некоторый секретный ввод (например, пользователь вводит пароль или PIN-код) и проверяйте ее вне телефона, например, с помощью бесконтактной инфраструктуры.
person mictter    schedule 28.04.2014

ОС Android не предоставляет безопасного хранилища для хранения конфиденциальных данных, которые используются в транзакции HCE.

В случае мобильного приложения HCE (облачная SE) конфиденциальные данные не хранятся как Secure Element.

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

Защита PAN

Спецификация токенизации EMV используется для замены PAN на токенизированный PAN, где токенизированный PAN ограничен определенным доменом.

Защита симметричного ключа

Мастер-ключ симметричной карты заменен ограниченной версией симметричного ключа.

Спецификация VISA HCE определяет ключ ограниченного использования (LUK), использование которого ограничено в течение ограниченного периода времени и операций.

Спецификация MasterCard HCE определяет использование одноразового ключа (SUK) для одной транзакции.

Другие спецификации HCE следуют аналогичному механизму.

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

Мобильное приложение использует криптографию белого ящика, чтобы предотвратить кражу данных, как это предлагается VISA, MasterCard и другими. Криптографию белого ящика трудно взломать.

Кстати, это называется Облачная SE, потому что конфиденциальные данные хранятся в облаке, а не в мобильном приложении, что отличается от Secure Element (в SE/Mobile SE конфиденциальные данные хранятся в SE).

person Shahidul    schedule 05.01.2017

Используйте токенизацию в сочетании с "SE в облаке"... это поможет избежать зависимости "Телефон должен быть в сети".

person Pavan    schedule 22.05.2015
comment
Можете ли вы описать свое решение более подробно, Паван? - person Gupta; 24.05.2015