КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ ПРИ ПЕРЕДАЧЕ ПО ИНТЕРФЕЙСУ NFC (ДИПЛОМНАЯ РАБОТА)

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ ПРИ ПЕРЕДАЧЕ ПО ИНТЕРФЕЙСУ NFC

по специальности 090105.65 – Комплексное обеспечение информационной безопасности автоматизированных систем

ЗАДАНИЕ

студенту

на дипломную работу

1. Тема работы

   
    

   

2. Срок сдачи студентом законченной работы

   

3. Исходные данные к работе

   

   
    

   

   
    

   

   
    

   

   
    

   

   
    

   

   
    

   

4. Содержание расчетно-пояснительной записки (перечень подлежащих разработке вопросов)

   
    

   

   
    

   

   
    

   

   
    

   

   
    

   

5. Дата выдачи задания

Руководитель

( )

(подпись руководителя) (Фамилия и инициалы)

Задание принял к исполнению « »

( )

(подпись студента) (Фамилия и инициалы)

РЕФЕРАТ

Работа состоит из: 62 страниц, 14 рис., 7 табл., x источников.

ТЕХНОЛОГИЯ NFC, ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ, МОБИЛЬНЫЕ ТЕХНОЛОГИИ

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

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ‌

APDU Applicationprotocoldataunits — блоки данных прикладного протокола

API ApplicationProgrammingInterface — Интерфейс прикладного программирования

ATR Answer To Reset — Ответнасброс

RFID Radio Frequency Identification — радиочастотнаяидентификация SE SecurityElement — Элемент безопасности

SIM Subscriber Identification Module — модульидентификацииабонента

SWP SingleWireProtocol — Одноместный протокол связи

UICC Universal Integrated Circuit Card — расширенный стандарт микропроцессорной карты

USIM Universal Subscriber Identity Module — расширенныйстандарт SIM-карты

Содержание

ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ 4

ВВЕДЕНИЕ 6

1. Архитектура комплекса программно-аппаратных средств, реализующих технологию NFC 8

   1. NFC-интерфейс 9

   2. Элемент безопасности 12

   3. Режимы работы NFC-контроллера 14

   4. Режимы работы NFC-устройства 16

2. Стандарты и протоколы NFC 21

   1. Основные стандарты 22

      2.1.1. ISO / IEC 14443 22

      1. NFCIP-1 27

      2. NFCIP-2 28

   2. Высокоуровневые NFC стандарты 29

1. Спецификация тегов NFC Forum 30

2. NDEF 32

1. Интерфейс между элементом безопасности и контроллером NFC 32

   1. Стандарт NFC-WI 32

   2. Single Wire Protocol 33

2.4 ISO / IEC 7816-4 34

1. Блоки данных прикладного протокола 34

   1. Структура C-APDU 35

   2. Структура ответа APDU 36

2.4.2 Файловая система в соответствии с ISO / IEC 7816-4 36

1. Анализ угроз и методов защиты при передаче данных по NFC в режиме точка-точка 38

   1. Прослушивание 38

      2.2. Повреждение данных 39

      1. Модификация данных 40

      2. Человек посередине 42

2. Разработка защиты канала при передаче по интерфейсу NFC 46

   1. Стек протоколов NFC 46

   2. Общая схема установки защищенного канала 48

   3. Обмен ключами 49

   4. Шифрование 49

5. Практическая реализация защиты канала передачи по интерфейсу NFC. . .52 5.1 Выбор платформы для реализации 52

1. Android 52

2. iOS 54

3. BlackBerry 55

4. Windows 55

1. Результаты 57

   ЗАКЛЮЧЕНИЕ 62

   СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 64

   
    

   ВВЕДЕНИЕ‌

   
    

   NFC (Near Field Communication) — технология беспроводной высокочастотной связи малого радиуса действия, позволяющая осуществлять бесконтактный обмен данными между мобильными телефонами, смарт- картами, платёжными терминалами, системами контроля доступа и прочими

   устройствами.

   Поддержка технологии смартфонами началась с выходом версии ОС

   Android 4.0 "Ice Cream Sandwich" в 2011 году, а также с выходом в 2014 году Apple iPhone 6 и смартфонов на базе WindowsPhone 8.1.

   Оснащенный NFC смартфон может быть как смарт-картой, используемой для оплаты, так и самим считывателем, что можно

   использовать для перевода средств между картами-смартфонами и

   превращения реальных банковских карт с поддержкой стандарта ISO/IEC 14443 (стандарт бесконтактных смарт-карт) в виртуальные.

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

   ссылками, паролями, контактными и другими данными между смартфонами. По умолчанию передача данных по NFC начинается при сближении

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

   банковской карты, привязанной к смартфону.

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

   сервисов.

   Цель работы — повышение безопасности персональных данных при передаче с использованием технологии NFC в смартфонах на платформе Windows. Для достижения поставленной цели в работе должны быть решены следующие задачи:

   • исследование архитектуры комплекса программно-аппаратных средств, реализующих технологию NFC;

   • исследование стандартов и протоколов NFC;

   • анализ угроз и методов защиты при передаче данных по интерфейсу

     NFC;

   • защита, канала передачи данных, с помощью существующих

шифрование данных при передаче по интерфейсу NFС.

1. Архитектура комплекса программно-аппаратных средств, реализующих технологию NFC‌

   
    

   Технология NFC – расширение стандарта бесконтактных карт (ISO 14443). В настоящее время технология уже активно используется в общественном транспорте и платежных системах. В последнее время началось активное развитие использования технологии в мобильных

   устройствах.

   Технология представляет собой совокупность аппаратных и программных средств. Конечно, эти средства для различных устройств — смартфоны, пассивные теги, POS-терминалы, считыватели в транспорте имеют, — различны и имеют свои особенности. Но все устройства, поддерживающие технологию NFC, объединены общими стандартами, которых должны придерживаться разработчики аппаратной и программной

   части.

   Основные компоненты, задействованные в обмене данными по технологии NFC — это NFC-совместимые устройства и NFC-теги.

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

   бесконтактными смарт-картами.

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

   устройствами являются смартфоны.

   Помимо мобильных телефонов примерами NFC-устройств являются точки продаж — POS-терминалы, которые могут выполнять бесконтактные платежи, различные аксессуары, такие как наушники Bluetooth, объективы,

   медицинские приборы, и т.д.

   Далее будут рассмотрены различные составляющие, отвечающие за передачу данных по NFC и режимы работы NFC-устройств.

   1. NFC-интерфейс‌

      
       

      Основным компонентом NFC-устройства является беспроводной NFC- интерфейс, который непосредственно общается с другими устройствами NFC или RFID. Интерфейс NFC сочетает в себе функциональность

      приемопередатчика данных, чтения RFID-меток и передачи RFID-меток.

      Интерфейс NFC, как правило, состоит из контроллера NFC и NFC- антенны. Кроме того, иногда бесконтактный конечный модем (NFC CLF – Contactless Front-End) также заявлен как часть NFC интерфейса, он отвечает за управления специфичными для NFC протоколами связи между антенной и

      конечным NFC-устройством [1].

      Контроллер NFC имеет аналоговый радиочастотный интерфейс, который включает в себя передатчик для отправки сигналов на частоте 13,56 МГц, приемник на той же частоте, и другой приемник для загрузки модулированных сигналов на частоте 848 кГц (такие модулированные сигналы генерируются пассивными NFC устройствами). Радиочастотный интерфейс также может включать в себя модулятор нагрузки, который используется в режиме эмуляции карты для модуляции ответов на активных NFC-устройствах.

      Другая часть контроллера — бесконтактный универсальный асинхронный приемопередатчик (UART), где данные кодируются и декодируются в соответствующие формы сигналов, необходимых для

      передачи ядру контроллера, который обрабатывает протоколы сообщений.

      Ядро контроллера — микропроцессор, который обрабатывает протоколы сообщений. Контроллер NFC обеспечивает несколько интерфейсов для связи с хост-контроллером и Элементом Безопасности (через специальные протоколы — Single Wire Protocol (SWP) и интерфейс

      NFC Wireless Interface (NFC-WI)).

      Блок-схема контроллера NXP PN544 NFC, использующегося в современных смартфонах приведена на Рисунке 1, чтобы проиллюстрировать

      типичные компоненты и интерфейсы управления [2].

      

      При использовании NFC-WI, безопасный элемент присоединен с помощью двух проводов к RF-интерфейсу контроллера NFC. NFC-WI интерфейс в контроллере NFC показан на Рисунке 1. Провода передают сигналы модуляции между приемопередатчиком NFC и NFC-контроллером. Элемент безопасности кодирует и декодирует сигналы от проводов, а также делает обработку протокола передачи данных. NFC-WI полностью совместим со стандартами NFCIP-1 и ISO / IEC 14443, которые будут рассмотрены дальше. Поддерживаемые скорости передачи - 106, 212 и 424 кбит / с.

      Рисунок 1 — NXP PN544. Пример контроллера NFC, встроенного в современных смартфонах

      Протокол Single Wire Protocol (SWP) — протокол, обеспечивающий соединение однопроводной связи между интерфейсом элементом безопасности на сим-карте (UICC SE) и NFC. Используется только один провод для передачи данных, поскольку только один из восьми контактных путей на поверхности SIM-карты, доступен для передачи данных. В отличие от NFC-WI, протокол передачи данных (ISO / IEC 14443) обрабатывается микропроцессором интерфейса NFC и только данные приложения направляются в элемент безопасности с помощью SWP. Элемент безопасности на сим-карте может быть непосредственно подключен к интерфейсу NFC, даже когда напряжение подается не по телефону, а через интерфейс NFC вместо этого. Это позволяет элементу безопасности совместно работать с интерфейсом NFC в режиме эмуляции карты, даже когда аккумулятор телефона является практически разряжен.

      
       

   2. Элемент безопасности‌

      
       

      Некоторые приложения, использующие NFC, например, приложения для проведения платежа, или покупки электронных билетов требуют, чтобы данные хранящиеся в памяти были защищены, так как злоумышленник

      потенциально может манипулировать данными или читать их из памяти.

      Данные, доступ к которым может получить злоумышленник, могут быть очень критичны – например, сведения о банковской карте, получив

      доступ к которым, злоумышленник может создавать клоны карт.

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

      поддержки безопасной среды для хранения и выполнения.

      ЭБ должен иметь операционную систему, в которой приложения устанавливаются и используются (как правило, приложения устанавливаются

      в виде JAVA-аплетов). Пример таких ОС: MULTOS (Multi Application Card

      Operating System) или Java Card OS [3].

      

      Существует несколько вариантов аппаратных модулей, которые могут служивать в качестве элемента безопасности в смартфонах (Рисунок 2) [4]:

      
       

      Рисунок 2 — Варианты аппаратных модулей, использующихся в качестве ЭБ

      Встроенный аппаратный ЭБ. ЭБ может быть непосредственно встроен в телефон. Поэтому он не может быть удален или переведен в другой девайс. Это решение имеет некоторые недостатки: права доступа к встроенному ЭБ полностью контролируются производителем телефона и если они строгие, то ЭБ не может даже позволить установить

      пользовательские приложения.

      UICC (Universal Integrated circuit card). ЭБ содержится на SIM/USIM- карте мобильного телефона и может обслуживать несколько приложений,

      выпущенных различными поставщиками приложений.

      Съемный носитель. Съемный носитель (например, SD-карта) состоит из памяти, встроенной смарт-элемента карты и смарт-карты контроллера. Он обеспечивает такой же высокий уровень безопасности, как смарт-карта и совместим с большинством основных стандартов для смарт-карт. Его

      преимущества в том, что он легко меняется в диапазоне от телефона к

      телефону — в отличие от UICC, который связан с определенным номером мобильного телефона.

      Элемент безопасности содержит операционную систему, которая позволяет запускать несколько приложений в виртуальной машине поверх родной ОС смартфона. Типичная ОС используемая в ЭБ – JavaCardOS[ 3]. Она имеет фреймворк под названием Java Card Runtime Environment (JCRE), который поддерживает приложения, реализованные в ограниченной версии языка Java (подмножество конструкций оригинального языка Java и

      библиотечных функций).

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

      
       

   3. Режимы работы NFC-контроллера‌

      
       

      Устройство NFC может работать в пассивном режиме и в активном режиме. Если устройство генерирует собственное радиочастотное поле – то оно работает в активном режиме, и называется «Инициатор». В противном случае устройство работает в пассивном режиме, и называется «Таргет». Активные устройства — как правило, имеют источник питания (например, смартфон), пассивные — источника питания не имеют (например, смарт- карты, nfc-теги).

      Возможны два варианта обмена данными между устройствами: когда

      оба устройства NFC активны, и когда одно устройство активно, второе пассивно.

      Схема обмена данными в случае, когда оба устройства активны, приведена на Рисунке 3 [2]. Когда первое устройство посылает запрос — оно генерирует радиочастоту, пока ожидается ответ от второго устройства, частота не генерируется. Таким образом, когда два устройства обмениваются данными, они генерируют частоту по очереди. Пример такого взаимодействия: два смартфона обменивающиеся данными — фото, видео- ролики, ссылки и т.п.

      
       

      

      
       

      Рисунок 3 — Схема работы устройств в активном режиме

      
       

      В активном режиме базовый радиочастотный сигнал (13,56 МГц) модулируется с данными в соответствии со схемой кодирования. Если активное устройство передает данные со скоростью 106 кбит/с, тогда используется модифицированный код Миллера со 100 % модуляцией. Во всех других случаях используется манчестерское кодирование с коэффициентом

      модуляции 10 %.

      Пассивный режим (Рисунок 4) [2] взаимодействия NFC-устройств происходит тогда, когда электромагнитное поле генерирует только инициатор сеанса связи. Такое взаимодействие может происходить, когда активное

      

      устройство (например, смартфон) считывает данные с пассивного устройства (например, nfc-тег).

      
       

      Рисунок 4 — Схема работы устройств в пассивном режиме.

      
       

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

      
       

   4. Режимы работы NFC-устройства‌

      
       

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

      эмуляция карты оплаты, режим точка-точка, режим чтения/записи.

      NFC-устройство может работать в трех режимах (Рисунок 5): эмуляция NFC-карты, пиринговый режим и режим чтения/записи.

      
       

      

      
       

      Рисунок 5 — Режимы работы NFC-контроллера

      
       

      Режим чтения / записи: в режиме чтения/записи, устройство NFC работает в качестве RFID-считывателя и способен читать пассивные метки NFC, а также писать в них. К приложениям использующим этот режим относятся прежде всего информационные приложения, позволяющие получать данные с RF или NFC-меток и созданных на их основе смарт- постеров, загружать различные билеты, дисконтные ваучеры и т. д. для последующего предъявления. Этот режим также эффективен при реализации транспортных приложений. Он может использоваться и в приложениях, имеющих вспомогательный характер по отношению к другим NFC- приложениям. Например, при покупке транспортного билета по технологии NFC можно дополнительно загрузить схему проезда или расписание работы транспорта. Этот режим может стать основным для работы транспортного NFC-приложения, если речь идет о загрузке в мобильный телефон транспортного билета с последующей оплатой на основе выставленного

      оператором счета.

      Режим точка-точка (P2P): в режиме P2P, устройство NFC имеет двунаправленное соединение с другим NFC устройством для обмена данными. Этот режим может быть использован для обмена небольшим количеством данных между телефонами (например, URL), обмен

      контактными данными или WiFi-настройками. Следует отметить, что универсальность стандартов NFC позволяет обмениваться данными в режиме точка-точка не только между смартфонами, но и между другими устройствами — NFC-считывателями, компьютерами, фотоаппаратами,

      музыкальными центрами.

      Режим эмуляции карт: в этом режиме, NFC-устройство эмулирует бесконтактные смарт-карты (ISO / IEC 14443 или FeliCa карты) и действует в качестве пассивного устройства. Эмуляция прозрачна и для других устройств, такое устройство-эмулятор выглядит как традиционная смарт- карта. Устройство в таком режиме может быть использовано как проездной в общественном транспорте, как банковская карта, используемая для оплаты покупок. Устройство в режиме эмуляции карты также может быть

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

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

      привести к несанкционированному списанию денежных средств.

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

      разработчиков такая полезная возможность остается закрытой.

      Подводя итоги, приведем диаграмму (Рисунок 6) [5] работы технологии NFC в смартфоне.

      
       

      

      Рисунок 6 — Схема работы технологии NFC в смартфоне

      
       

      Данная схема наглядно показывает взаимодействие элементов телефона друг с другом. В центре схемы — контроллер NFC, Host Controller —

      процессор самого телефона и антенна.

      NFC-контроллер с помощью антенны взаимодействует с другим NFC- устройством по низкоуровневому протоколу NFC Contactless Front-End и затем передает данные хост-контроллеру устройства для их последующей

      обработки.

      Если контроллер работает в режиме эмуляции карты, то при взаимодействии с другим NFC-устройством, NFC-контроллер напрямую соединяется с Элементом безопасности. Элемент безопасности обрабатывает данные, при этом приложение NFC использующее режим эмуляции карты, запускается не на основном процессоре телефона, а на чипе элемента безопасности. И только после этого, некоторые данные передаются основному процессору.

      
       

2. Стандарты и протоколы NFC‌

Технология NFC была одобрена как ISO/IEC стандарт 8 декабря 2003 и позже как стандарт ECMA [6]. NFC — технология с открытой платформой, стандартизированная в ECMA-340 и ISO/IEC 18092. Эти стандарты определяют схемы модуляции, кодирование, скорости передачи и радиочастотную структуру интерфейса устройств NFC, а так же схемы инициализации и условия, требуемые для контроля за конфликтными ситуациями во время инициализации — и для пассивных и для активных режимов NFC. Кроме того, они также определяют протокол передачи,

включая протокол активации и способ обмена данными.

NFC объединяет множество ранее существовавших стандартов, включая ISO 14443, ISO 15693. Таким образом, телефоны, снабженные NFC, способны к взаимодействию с существующей ранее инфраструктурой

считывателей. Особенно в «режиме эмуляции карты» устройство NFC

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

Помимо основных стандартов, существуют также стандарты, созданные организацией NFC Forum. NFC Forum является некоммерческой ассоциацией, основанной 18 марта, 2004 компаниями NXP Semiconductors, Sony и Nokia, чтобы продвинуть использование NFC в бытовой электронике, мобильных устройствах и персональных компьютерах [6]. NFC Forum содействует реализации и стандартизации технологии NFC, чтобы гарантировать способность к взаимодействию между устройствами и услугами. Стандарты NFC Forum не являются обязательными, но они способствуют созданию универсального способа связи NFC-устройствами разного типа — смартфонами, компьютерами, NFC-считывателями и бытовыми электронными приборами.

1. Основные стандарты‌

   
    

   Приведем перечень основных стандартов NFC [7]:

   
    

   • ISO / IEC 18902 или ECMA-340 (NFCIP-1). Стандарты описывают физический уровень и связь между двумя NFC устройствами.

   • ISO / IEC 21481 или ECMA 352 (NFCIP-2). Стандарт определяет

     механизм выбора режима связи между устройствами, которые

     работают на частоте 13,56 МГц.

   • ISO / IEC 14443 (Proximity-Coupling Smart Cards). Стандарт описывает

     бесконтактные смарт-карты, методы работы и протоколы передачи

     данных для связи между картой и устройством считывания. Такие смарт-карты работают на расстоянии до 7-15 см.

   • ISO / IEC 15693 (Vicinity-Coupling Smart Cards). Стандарт описывает

   способ функционирования и эксплуатации Vicinity-Couplingсмарт-карт. Основное отличие от бесконтактных карт является то, что данные с карты могут быть считаны с большего расстояния (до 1-1,5 метров).

   

   Далее будет приведено более детальное описание NFCIP-1, NFCIP-2 и ISO / IEC 14443.

   
    

   1. ISO / IEC 14443‌

      ISO / IEC 14443 — основной стандарт определяет методы работы бесконтактных смарт-карт. Он включает в себя следующие 4 части:

      • Часть 1. Физические характеристики;

      • Часть 2. Радиочастотная мощность и сигнальный интерфейс;

      • Часть 3. Инициализация и предотвращение коллизий;

      • Часть 4. Протокол передачи данных.

      
       

      ISO / IEC 14443 может быть принят в качестве эквивалента протокола ISO / IEC 7816, который стандартизирует методы работы для контактных смарт-карт. Взаимоотношение обоих протоколов и их отображение на уровни модели OSI можно видеть на рисунке 7 [8].

      
       

      Рисунок 7 — Схема взаимоотношений стандартов ISO / IEC 14443 и ISO / IEC 7816

      
       

      1. Часть 2. Радиочастотная мощность и сигнальный интерфейс

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

         несовместимы [10].

         Тип A. 100% ASK (амплитудная модуляция) с модифицированным кодированием Миллера устанавливается для передачи данных в направлении считыватель-карта. Для передачи данных в направлении карта-считыватель используется Манчестерское кодирование. Скорость передачи данных по

         умолчанию 106 кбит / с в обоих направлениях.

         Тип В. 10% ASK модуляция с манчестерским кодированием используется для передачи данных от считывателя к карте. В другом направлении, поднесущая модулируется с помощью двоичной фазовой манипуляции (Binary Phase-Shift Keying — BPSK), используя кодирование Non Returnto Zero (NRZ). Скорость передачи битов является такой же, как для типа А.

         
          

      2. Часть 3. Инициализация и предотвращение коллизий.

         
          

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

         Методы предотвращения коллизий отличаются для карт типа А и типа

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

            передача данных не прерывается.

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

            
             

      3. Часть 4. Протокол передачи данных.

После того, как соединение между считывателем и картой было установлено, команды для карты могут быть отправлены считывателем с использованием специального протокола передачи данных (Transmission

Protocol).

Выбор карты в процедуре анти-коллизии подтверждается отправкой SAK-команды (Select Acknowledge) от карты к считывателю. SAK содержит информацию о том, соответствует ли смарт-карта ISO / IEC 14443-4 или она

поддерживает собственный протокол.

Если карта сообщает, что она поддерживает ISO / IEC 14443-4 в SAK, считыватель затем отправляет сообщение RАТS (RequestAnswerToSelect). RАТS содержит два важных значения для последующей связи: CID и FSDI [12]:

• CID (Сard Indentifier) — номер, уникальный для каждой карты в

  активном состоянии. Он используется для адресации в виде логического идентификатора карты;

• FSDI (Frame Size Device Integer) — значение максимального размера

  блока, который считыватель способен получить от карты. Значение может быть до 256 байт.

  После приема RATS, карта посылает команду АТС (Answer to Select) в ответ. ATS содержит несколько параметров протокола, которые играют важную роль в создании связи. Основные параметры:

• DS / DR — поддерживаемые скорости передачи данных смарт-карты во

  время передачи данных от карты к считывателю, и от считывателя к карте соответственно;

• FSDI (Frame Size Device Integer) — по аналогии с FSDI, это

  максимальный размер блока направленный от считывателя на карту. Максимальное значение составляет 256 байт;

• FWI (Frame Waiting Integer) — таймаут, т.е. время которое считыватель

  должен ждать ответа от карты после передачи команды.

  
   

  После получения АТС, считыватель может увеличить скорость битовой

  передачи (путем отправки специальной команды PPS), когда карта сигнализирует что поддерживает эту скорость сообщением DS / DR.

  После установления соединения начинается передача данных по протоколу передачи данных (Transmission Protocol). Как показано на Рисунке 7, протокол размещается на транспортном уровне модели OSI. Его роль заключается в обеспечении правильной адресации блоков данных, последовательной передачи блоков данных, контроле времени передачи и обработки ошибок при передаче. Протокол способен передавать данные приложений с помощью блоков данных протокола приложения (APDUs –

  Application Protocol Data Units), определенных в ISO 7816-4.

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

  инициировать никаких сообщений, не получив первой команды. Базовой

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

  Существует три различных типа блоков данных:

  
   

  • I-блок (Information Block) — используется для передачи данных приложения;

  • R-блок (Receive Ready Block) — используется для положительных или

    отрицательных ответов. Ответ относится к последнему принятому

    блоку;

  • S-блок (Super Visory Block) — используется для обмена управляющей

    информацией.

    
     

    В Таблице 1 показана структура блока данных.

    
     

    Таблица 1 Структура блока данных Transmission Protocol

    
     

    Prologue field	Information field
    PCB	CID NAD
    1 byte	1 byte	1 byte

     

    Epilogue field

    
     

    INF EDC

    2 bytes

    
     

• PCB (Protocol Сontrol Byte) определяет тип блока и номер блока;

• CID (ID карты) – логический идентификатор карты для адресации

  конкретной карты;

• NAD (Node Address Field) – поле зарезервировано для создания и

  решения различных логических соединений, его использование не

  определено в спецификации;

• INF поле несет полезную нагрузку (например, данные приложения) от

  прикладного уровня в случае I-блока;

• EDC (Error Detection Code) представляет собой 16 избыточных битов

  для обнаружения ошибок.

  
   

  Максимальный размер блока определяется значениями FSCI и FSDI. Для построения цепочки блоков (если данные не помещаются в один блок) и для контроля последовательности блоков цепочки используется PCB поле.

  
   

  1. NFCIP-1‌

     
      

     NFCIP-1 стандарт частично основан на стандарте ISO / IEC 14443. Он определяет два режима связи, активный и пассивный режим. В отличие от пассивного режима, активный режим поддерживает связь двух устройств, которые имеют свой собственный источник питания (принцип работы в

     активном и пассивном режиме описан в разделе 1.3).

     Стандарт определяет схемы модуляции, кодирование, скорость передачи и формат фрейма RF-интерфейса, а так же схемы инициализации и условия, требуемые для контроля коллизий данных во время инициализации

     [9].

     Кроме того, он определяет транспортный протокол, называемый протоколом обмена данными (DEP — Dataexchangeprotocol). DEP является полудуплексным протоколом, поддерживающим передачу блочно- ориентированных данных с обработкой ошибок. Для данных, не вписывающихся в одном фрейме, определен механизм передачи по цепочки. Режим точка-точка NFC может использовать NFCIP-1 в качестве базового протокола. Протокол передачи, радио интерфейс и методы анти-коллизий задаются аналогично тем, которые определены в стандарте ISO / IEC 14443.

     
      

  2. NFCIP-2‌

  
   

  NFCIP-2 определяет механизм выбора между различными режимами связи, реализующих ISO / IEC 14443, ISO / IEC 15693, NFCIP-1 [13]. Каждое NFC-совместимое устройство, реализующее NFCIP-2, выбирает (в начале каждого сообщения) между заданными режимами:

• PCD — устройство работает как считыватель ISO / IEC 14443 совместимых карт;

• PICC — устройство эмулирует бесконтактную смарт-карту, в так

  называемом режиме эмуляции карт;

• NFC — в этом режиме устройство работает в соответствии с NFCIP-1

  спецификацией, и может работать как в активном так и в пассивном режиме.

  
   

  1. Высокоуровневые NFC стандарты‌

     
      

     Высокоуровневые стандарты не официальное название, но оно характеризует группу норм, выданных организацией NFC Forum, в основе которых лежат стандарты ISO/IEC [14]. NFC Forum — международная организация целью которой является развитие технологии NFC. Некоторые из этих стандартов подводят различные технологии под один общий стандарт (например, Цифровой протокол (Digital Protocol)), другие обеспечивают расширенную функциональность и новые методы работы для NFC- устройств:

• Стандарт NDEF (NFC Data Exchange Format) определяет формат данных между NFC-совместимыми устройствами и метками;

• Стандарт RTD (Record Type Definition) определяет типы записей для

  различных целей в сообщениях NDEF;

• Протокол Connection Handover определяет, как использовать NFC для

  установления соединения с использованием других технологий

  беспроводной связи (например, Bluetooth, Wi-Fi);

• Эксплуатационные спецификации для типов тегов 1-4;

• Logical Link Control Protocol (LLCP) — протокол для поддержки P2P

  связи между двумя устройствами, используемых на вершине NFCIP-1;

• Digital Protocol — цифровой протокол для NFC-устройств связи,

  обеспечивает спецификации по реализации на вершине стандартов ISO / IEC 18092 и ISO / IEC 14443;

• NFC Activity Technical Specification — объясняет, как настроить

  протокол связи с другим устройством NFC или NFC метками;

• Simple NDEF Exchange Protocol (SNEP) — простой протокол обмена

  NDEF-сообщениями, используется в верхней части LLCP, позволяет производить обмен сообщениями NDEF.

  1. Спецификация тегов NFC Forum‌

     
      

     NFC Forum определил четыре типа тегов, которые должны работать для NFC-устройств. Каждый тип тега основан на различных технологий. Их описание, приведено ниже [1]. Сравнение параметров каждого типа тега приведены в таблице 2.

     • Тип 1: Тип 1 тега основан на стандарте ISO / IEC 14443 Типа А

       ( Цифровой протокол гласит, что он использует определенный набор NFC-технологий, без учета антиколлизии). По умолчанию, это теги для чтения и записи, но пользователи, при необходимости, могут настроить тег, так чтобы было доступно только для чтение. Свободной памяти у тега мало, только 96 байт, но она может быть расширена до 2 кбайт. Скорость передачи данных составляет 106 Кбит/с. Объем памяти невелик, так что этот тип тегов можно использовать для

       хранения только короткого текста, например, URL-адреса;

     • Тип 2: Тип 2 тегов также основан на стандарте ISO / IEC 14443 Типа А

       (Цифровой протокол гласит, что он использует определенный набор NFC-технологий, а в том числе антиколлизии). Теги могут использоваться и для чтения и для записи, но также как и тег первого типа может быть настроен только для чтения. По умолчанию объем памяти составляет 48 байт и возможностью расширения до 2 Кб. Скорость передачи данных такая же как и у тегов первого типа и

       составляет 106 кбит/с;

     • Тип 3: Тип 3 тегов основан на спецификации JISX 6319-4, также

       известной как FeliCa (технологии NFC-F). Скорость передачи данных по сравнению с тегами первого и второго типа увеличена до 206 Кбит/с, а объем памяти является переменной величиной, но его теоретический предел составляет 1 МБ за каждый сервис (тег может содержать несколько служб). Метки такого типа предназначены для сложных применений и являются более дорогостоящими по сравнению с другими типами тегов;

       • Тип 4: Тип 4 тегов полностью совместим со стандартом ISO / IEC

14443 (в том числе с частью 4 этого стандарта – «Протокол передачи данных»). Интерфейс связи либо Тип А, либо Тип B. Теги предварительно настроены либо на чтение и перезапись, или только для чтения. Объем встроенной памяти составляет до 32 КБ на обслуживание и скорость передачи данных варьируется от 106 до 424 кбит / с.

Таблица 2. Сравнение параметров типов тегов

1. NDEF‌

   
    

   NDEF (NFC Data Exchange Format) является двоичным форматом данных для обмена информацией между устройствами NFC. Спецификация NDEF определяется стандартами NFC Forum. Основная единица данных NDEF — это сообщение, которое содержит одну или несколько записей NDEF. Каждая запись имеет свою полезную нагрузку, ограниченную 231-1 байт, но записи могут быть соединены друг с другом, так что общий размер передаваемых сообщений практически неограничен. Каждая запись NDEF имеет три параметра: размер полезной нагрузки, тип полезной нагрузки и необязательный идентификатор полезной нагрузки. Есть много типов NDEF записей, сведения о всех типах находятся в спецификации NDEF [15].

1. Интерфейс между элементом безопасности и контроллером NFC Эти протоколы используются в режиме эмуляции карты, для‌

   приложений, которые требуют использования элемента безопасности. Рассмотрим два основных протокола: NFC-WI (NFC Wired Interface) и SWP (Single Wired Protocol)).

   
    

   1. Стандарт NFC-WI‌

      
       

      Стандарт NFC-WI определен в ECMA-373 [16]. Другое название этой

      
       

      2

       

      технологии является S

      C (SignalIn/SignalOutconnection). В этом решении,

      
       

      безопасный элемент (обозначенный как приемопередатчик NFC) соединен с помощью двух проводов к RF-интерфейсу контроллера NFC (обозначенный как NFC Front-End). NFC-WI интерфейс в контроллере NFC показано на

      рисунке 1.

      Провода называются Signal-in и Signal-Out и передают сигналы модуляции между приемопередатчиком NFC и NFC Front-End. Внешне интерфейс SE и NFC вместе ведут себя как бесконтактная смарт-карта.

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

      делает обработку протокола передачи.

      NFC-WI полностью совместим с NFCIP-1 и стандартом ISO / IEC 14443. Поддерживаемые скорости передачи битов на проводах являются 106,

      212 и 424 кбит/с — они являются соответствующими поддерживаемым беспроводным стандартам.

      
       

   2. Single Wire Protocol‌

Одноместный протокол связи (Single Wire Protocol — SWP) указан в стандарте ETSITS 102 613 [17] в виде ориентированного на биты цифрового дуплексного протокола, обеспечивающего соединение однопроводной связи между интерфейсом UICCSE и NFC. Используется только одиночный провод, поскольку существует только один из восьми контактных путей на поверхности контакта SIM-карты, доступных для передачи данных. В отличие от NFC-WI, протокол передачи данных (т.е. ISO / IEC 14443) обрабатывается микропроцессором интерфейса NFC сам и только данные

приложения направляются в SE с помощью SWP.

Интерфейс SWP также позволяет установить UICC SE включенным, UICC SE может быть непосредственно подключен к интерфейсу NFC, так что напряжение подается не по телефону, а вместо этого через интерфейс NFC непосредственно. Это позволяет SE совместно работать с интерфейсом NFC в режиме эмуляции карты, даже когда заряд аккумулятора телефона низкий.

2.4 ISO / IEC 7816-4‌

В соответствии со стандартом [18], ISO / IEC 7816-4 определяет организацию, безопасность и команды для обмена между считывателем и картой. Это включает в себя:

• Содержание пар команда-ответ обмена между интерфейсами карт.

  Каждая пара состоит из двух блоков данных прикладного протокола (сокращенно APDU — Application Protocol Data Units);

• Структура файлов и данных на карте памяти;

• Структура и содержание так называемых исторических байтов,

  описывающих эксплуатационные характеристики карты — байты команды Answer To Reset (ATR), отправленные с помощью карты. Эта команда является специальной командой, отправленной картой после ее

  электрического перезапуска с помощью считывателя;

• Методы доступа к файлам и данным в архитектуре карты и

  безопасности, определяющие права доступа к файлам

• Методы безопасного обмена сообщениями.

  
   

  1. Блоки данных прикладного протокола‌

     
      

     Блоки данных прикладного протокола (Application Protocol Data Unit — APDUs) используются для обмена данными между смарт-картой и считывателем на прикладном уровне. APDUs всегда образуют пары сообщений команды и ответа. Во-первых, команда APDU (обозначается как CAPDU) отправляется от считывателя на карту, которая отвечает, посылая ответ APDU (обозначенный как R-APDU). Формат данных предназначен, чтобы быть независимым от основного Протокола передачи [3].

     
      

     1. Структура C-APDU‌

        
         

        C-APDU состоит из заголовка и тела.Заголовок имеет фиксированную длину, тело имеет переменную длину, и может отсутствовать в некоторых случаях.Заголовок состоит из флагов CLA, INS, P1, P2 ,остальное тело.Структура блока команды прикладного протокола представлена в

        таблице 3 [19].

        Таблица 3 Структура блока команды прикладного протокола

        
         

        
         

        Поле

        CLA

        INS

        P1

        P2

        Lc

        Data

        Le

        
         

        Длина

        1

        1

        1

        1

        0, 1 или 3

        Переменна я

        0-3

        
         

• CLA — байт класса инструкция;

• INS — байт номера инструкции;

• P1, P2 — Дополнительные параметры;

• Lc — длина данных команды;

• Le — длина ожидаемого ответа.

  
   

  Длина полей Lc и Le зависит от возможности карты к общению, эта возможность называется «расширенный APDUs». О возможностях карты говорится в исторических байтах или ATR карты. Если карта поддерживает расширенный APDU, то Lс равняется 3 байтам и поле данных команды имеет длину до 65535 байт. Le в случае расширенного APDU, также как и Lc имеет максимальную длину 3 байта и длина поля данных для ответа составляет до 65535 байт. В случае обычного APDU, как Lc так и Le имеют максимальную длину 1 байт и длина поля данных команд и поле данных ответа ожидается до 255 и 256 байт соответственно.

  
   

  1. Структура ответа APDU‌

     
      

     Структура блока ответа прикладного протокола представлена в таблице

     4.

     Таблица 4 Структура блока ответа прикладного протокола

     
      

     
      

     Поле	Данные	SW1	SW2
     Длина	Переменная	1	1

     
      

     Тело (опционально) состоит только из области данных. Заголовок состоит из двух флагов-статусов: SW1 и SW2. Они кодируют состояние обработки команды. Например, код состояния '90 ' означает, что команда была выполнена полностью и успешно. Остальные коды состояния находятся в описании стандарта [9].

  1. Файловая система в соответствии с ISO / IEC 7816-4‌

  
   

  В соответствии со стандартом ISO / IEC 7816-4 есть два типа файлов [3]

  
   

• Выделенные файлы (Dedicated Files —DF) — файлы директорий

• Элементарные файлы (Elementary Files — EF) — файлы, которые

содержат фактические данные

Корневой DF файл называется мастер-файл (Master File — MF) и является обязательным. Другие DF не являются обязательными.

Существует два типа EF файлов:

• Внутренние EF — предназначены для хранения данных,

  интерпретируемые-карты, т.е. данные, используемые картой для управления и контроля.

• Рабочие EF — предназначены для хранения данных, не

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

3 Анализ угроз и методов защиты при передаче данных по NFC в режиме точка-точка‌

3.1 Прослушивание‌

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

чтобы обмениваться сообщениями или данными.

Злоумышленник может использовать антенну, чтобы принимать передаваемые сигналы. Злоумышленнику необходимо оборудование, необходимое для радиочастотного сигнала, а также оборудование для декодирования радиочастотного сигнала. Передача данных по интерфейсу NFC обычно происходит между двумя устройствами, находящимися в непосредственной близости друг от друга. Обычно это расстояние не больше 10 см. Главный вопрос в том, как близко злоумышленник должен быть, чтобы иметь возможность извлечь полезную информацию из радиосигнала. Точного ответа на этот вопрос нет, так как расстояние необходимо для атаки зависит от многих факторов [20], таких как:

• Характеристика радиочастотного поля посылающего сигнал устройства (геометрия антенны, экранирование, окружающая среда);

• Характеристика антенны атакующего;

• Качество приемника атакующего;

• Качество декодера атакующего;

• Мощность посылаемого сигнала NFC-устройства;

• Барьеры на местности (стены, металл, уровень шума).

Таким образом, любое точное число, соответствующее расстоянию,

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

Кроме того, имеет значение, в каком режиме устройство отправляет данные — в активном или пассивном. Это означает, что отправитель генерирует собственное поле (активный режим) или же отправитель

использует радиочастотное поле, порожденное другим устройством (пассивный режим). В разных режимах используются разные способы передачи данных. И прослушивать пассивные устройства гораздо тяжелее. Например, когда устройство посылает данные в активном режиме, злоумышленник может находится на расстоянии около 10 метров. Если же устройство находится в пассивном режиме, это расстояние уменьшается до 1

метра.

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

технологии NFC.

Единственным реальным решением против подслушивания является защита канала передачи с помощью шифрования, как показано в разделе 4.

2.2. Повреждение данных‌

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

используемые схемы модуляции и кодирования.

Устройства с поддержкой технологии NFC могут противостоять этому нападению, потому что они могут проверять радиочастотные поля на наличие возмущений, во время передачи данных. Если NFC совместимое устройство

делает это, оно сможет обнаружить атаку.

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

1. Модификация данных‌

   При модификации данных злоумышленник хочет не повредить данные, а подменить их, незаметно от пользователя.

   Возможность такой атаки сильно зависит от силы амплитуды

   модуляции. Это происходит потому, что декодирование сигнала отличается на 100% и 10% модуляции.

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

   нулевой сигнал в приемнике. Это практически невозможно [20].

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

   предшествует единице.

   В 100% модуляции злоумышленник не может изменить бит со значением 0 в бит значения 1, но злоумышленник может изменить бит со значением 1 в бит значения 0, в случае если этот бит предшествует битом

   значения 1 (т.е. с вероятностью 0,5).

   В 10% модуляции декодера оба уровня сигнала (82% и полное) и

   сравнивает их. В случае, если они находятся в правильном диапазоне сигнал является действительным, и получается его декодировать.

   Возможность атаки во многом зависит от динамического диапазона входного сигнала приемника. Это очень вероятно, что высокий уровень

   модифицированного сигнала будет превышать возможный диапазон входного

   сигнала.

   Вывод таков, что для модифицированного кодирования Миллера с 100% ASK эта атака является допустимой для некоторых битов и невозможно для других битов, но Манчестерского кодирования с 10% ASK эта атака возможна для всех битов. Но следует отметить, что на практике добиться

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

   Защита от модификации данных может быть достигнута различными способами. С помощью скорости передачи 106 кбит/с в активном режиме злоумышленнику практически невозможно изменить все данные, которые передаются по радиочастоте, как описано в этом разделе выше. Это означает, что для защиты необходимо, чтобы оба устройства работали в активном режиме. Хотя это осуществимо, существует серьезный недостаток — активный режим является наиболее уязвимым к прослушиванию. Кроме того, такая защита от модификации не является идеальной, так как даже при скорости 106 кбит/с некоторые биты могут быть изменены [20]. Поэтому

   могут быть предпочтительным два других варианта.

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

   обнаружении атаки.

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

   
    

2. Человек посередине‌

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

В классической схеме атаки «Человек посередине», есть две стороны, которые хотят общаться друг с другом — это Алиса и Боб, и третья сторона злоумышленник — Ева. Это показано на Рисунке 8.

Рисунок 8 — Схема атаки «Человек посередине»

Алиса и Боб не должны быть осведомлены о том, что они не разговаривают друг с другом, и о том, что оба они принимают и передают данные третьей стороне Еве. Это классическая угроза при аутентификации в протоколах подобных протоколу Диффи-Хеллмана: Алиса и Боб хотят договориться о секретном ключе, который они затем будут использовать для безопасного канала. Но Ева, находясь посередине, может установить собственный ключ с Алисой и еще один ключ с Бобом. И когда Алиса и Боб позже будут использовать свои ключи для защиты данных, Ева легко может

прослушать передаваемые данные, а также модифицировать их. Теперь рассмотрим эту же атаку в рамках NFC-общения.

Предположим, что Алиса использует активный режим, а Боб пассивный. Схема такой атаки приведена на рисунке 9.

Рисунок 9 — Схема атаки человек посередине в случае активного и пассивного NFC-устройства

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

устройство находится в активном состоянии, а другое в пассивном.

Рассмотрим следующий вариант, который заключается в том, что и Алиса и Боб используют активный режим. Схема атаки показана на рисунке 10.

Рисунок 10 — Схема атаки человек посередине в случае двух активных NFC- устройств

В этом случае Алиса посылает некоторые данные Бобу. Ева должна перехватить эти данные и должна нарушить передачу Алисы, чтобы убедиться, что Боб не получил данные Алисы. При этом Алиса уже может обнаружить возмущения радиочастотного поля, проделанные Евой и остановить протокол. Но опять предположим, что Алиса не делает эту проверку и протокол продолжается. Следующим шагом Евы должна быть отправка данных Бобу. На первый взгляд ситуация складывается лучше, чем в примере когда есть активное и пассивное устройство. Ведь сейчас, когда взаимодействуют два активных-устройства Алиса выключила свое радиочастотное поле, чтобы Боб мог сгенерировать свое поле. Теперь Ева вместо Боба может включить свое поле РФ и отправлять данные. Но существует следующая проблема для злоумышленника: Алиса прослушивает все радиочастотные сигналы, пока она ожидает ответа от Боба. Следовательно, Алиса будет получать данные, передаваемые Евой и может снова обнаружить проблему в протоколе и остановить протокол. Значит Ева не может отправить данные только Алисе или только Бобу, так как отправляемые данные получат оба, а значит атака Человек-посередине невозможна.

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

участников.

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

1. Разработка защиты канала при передаче по интерфейсу NFC‌

   
    

   Как уже было сказано в разделе 3, создание защищенного канала между двумя NFC устройствами лучший подход к защите от прослушивания и

   модификации и искажения данных.

   Из-за присущей технологии NFC особенностей, позволяющих защититься от атаки человек-посередине, возможно использование стандартного протокола распределения ключей Диффи-Хеллмана на основе RSA или на основе эллиптических кривых. Так как угрозы человек- посередине нет, то оригинальная версия протокола Диффи-Хеллмана отлично

   подойдет для обмена ключами между двумя устройствами.

   Полученный ключ может быть использован для получения симметричного ключа для алгоритмов 3DES или AES, который затем будет

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

   работы 3DES и AES.

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

   
    

   1. Стек протоколов NFC‌

      
       

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

      контроллера.

      Поэтому стек протоколов будет выглядеть, как показано на рисунке 11.

      

      
       

      Рисунок 11— Стек протоколов NFC

      
       

      При передаче данных происходит следующее:

      1. На вершине стека на уровне приложений находятся крипто- протоколы. Выбираются данные, которые необходимо отправить и

         шифруются.

      2. На следующем шаге, данные подготавливаются к отправке — формируются специальные блоки APDU или NDEF сообщения, содержащие

         зашифрованные данные.

      3. При сближении устройств устройства индуктивно соединяются с

         помощью переменного магнитного поля одного из устройств.

      4. После сближения запускается протокол активации соединения и

         антиколлизий.

      5. После установления соединения запускается протокол передачи данных. Происходит передача зашифрованных/подписанных данных в формате NDEF.

      

   2. Общая схема установки защищенного канала‌

      
       

      Установка и создание защищенного канала определяется криптографическими механизмами, которые используют протокол Диффи- Хелмана для обмена ключами ключей и алгоритм AES для шифрования. С помощью протокола создается защищенный канал между двумя устройствами NFC, желающими обменяться данными. Защищенный канал распадается, когда устройства удаляются друг от друга на расстояние

      недоступное для связи по NFC.

      Общая схема установки защищенного канала показана на Рисунке 12:

      1. Обмен ключами.

      2. Формирование ключа для шифрования.

      3. Обмен зашифрованными сообщениями

      4. Завершение сеанса связи

         
          

         Рисунок 12— Схема установки защищенного канала

         
          

   3. Обмен ключами‌

      Для обмена ключами предлагается использовать протокол Диффи- Хелмана.

      Для установки защищенной связи два пользователя Алиса и Бобб совместно выбирают два числа g и p, которые не являются секретными и могут быть известны также другим заинтересованным лицам.

      Для того, чтобы создать, неизвестный более никому секретный ключ, оба абонента генерируют большие случайные числа: Алиса — число a, Боб

      a

       

      • число b. Затем Алиса вычисляет значение A=g

        mod p и пересылает его

        
         

        b

         

        Бобу. А Боб вычисляет B=g

        mod p и передает Алисе.

        Предполагается, что злоумышленник может получить оба эти значения,

        но не модифицировать их.

        На следующем этапе Алиса на основе имеющегося у нее числа a и

        
         

        a

         

        ab

         

        полученного по сети B вычисляет значение B =g

        mod p . Аналогично Боб

        
         

        на основе имеющегося у него b и полученного по сети A вычисляет значение:

        Ab =gab mod p .

        В результате и у Алисы и у Боба получилось одно и то же число:

        K=gab mod p .

        
         

   4. Шифрование‌

Передаваемые данные шифруются алгоритмом AES в режиме сцепления блоков шифра (Cipher Block Chaining — CBC). AES был выбран в качестве алгоритма шифрования, так как на момент написания работы он

является одним из самых стойких алгоритмов [21].

AES представляет собой алгоритм шифрования 128-битных блоков

данных ключами по 128, 192 и 256 бит.

В режиме CBC к каждому блоку открытого текста перед шифрованием прибавляется результат шифрования предыдущего блока с помощью побитовой операции XOR. К первому блоку открытого текста прибавляется вектор инициализации, который генерируется случайным образом и обычно передается вместе с зашифрованными данными, чтобы их можно было дешифровать. Шифрование и дешифрование в режиме CBC показаны на Риc. 13 и Риc. 14 [21].

Рисунок 13—Шифрование в режиме CBC

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

Рисунок 14—Дешифрование в режиме CBC.

Алгоритмы блочного шифра шифруют за один раз данные в блоке, а не в одном байте. Самый распространенный размер блока — 8 байт. Поскольку каждый блок подвергается серьезной обработке, блочные шифры обеспечивают более высокий уровень безопасности по сравнению с поточными шифрами. Однако алгоритмы блочного шифрования выполняются

медленнее, чем поточные шифры.

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

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

1. Практическая реализация защиты канала передачи по интерфейсу NFC‌

   
    

   1. Выбор платформы для реализации‌

      
       

      Для выбора платформы реализации был проанализирован набор API, предоставляющих доступ к функциям NFC для основных мобильных операционных систем: Android, iOS, BlackBerry, Windows.

      
       

      1. Android‌

         
          

         Несмотря на то, что в настоящее время практически все современные смартфоны на платформе Android оснащены поддержкой NFC, технология остается удивительно ограниченной для разработчиков приложений на этой

         платформе.

         Рассмотрим варианты использования элемента безопасности и встроенных в него крипто-средств в смартфонах на базе Android.Первый

         вариант расположение ЭБ на UICC. UICC ЭБ подключается только к основной полосе процессора. Процессор базовой полосы отделен от процессора приложений под управлением операционной системы. Таким образом, ресурсы UICC не могут быть доступны непосредственно в приложениях Android, все коммуникации должны пройти через слой Радио интерфейса (Radio Interface Layer — RIL). Кроме того, UICC ЭБ использует для связи некоторые зарезервированные команды, которые, к сожалению, не поддерживается текущим менеджером Android (услуги, имеющей доступ к RIL). Эта проблема решается использованием проекта «Secure Element Evaluation Kit for the Android platform» (SEEK) для Android, который реализует недостающую функциональность и позволяет осуществлять

         коммуникация через стандартный API смарт-карт.

         Однако, SEEK не часть системы Android по умолчанию, и он должен быть скомпилирован вместе с системой, чтобы начать работать. Альтернативный способ связи между прикладным процессором иUICCSE является использование протокола SWP и общение с помощью контроллера NFC. Такое общение часто по умолчанию отключено, но, как и в предыдущем случае, патч существует. Но так как это не часть Android, для применения

         патча необходима перекомпиляция операционной системы.

         Следующий вариант расположения — встроенный ЭБ, он является частью многих мобильных телефонов с поддержкой NFC и соединен с контроллером NFC через интерфейс NFC-WI. Он имеет 3 режима работы: OFF, проводной и виртуальный режим. В OFF Режим, нет никакой связи с ЭБ. В проводном режиме, ЭБ является видимым для процессора приложений как если бы он был бесконтактной смарт-картой, подключенной к радио интерфейсу NFC-контроллера. В виртуальном режиме, ЭБ виден внешним считывателям, так если бы телефон был бесконтактной смарт-картой. Все эти режимы являются взаимоисключающими, поэтому мы можем общаться с ЭБ или через проводной интерфейс или с помощью бесконтактного интерфейса. SE среда называется Execution Environment NFC (NFC EE) в Android и API

         для доступа к ней остается скрытым из SDK приложения (пакет

         com.android.nfc_extras).

         Пакет com.android.nfc_extras предлагает базовый интерфейс связи в NFC EE, в нем содержатся только простые методы для открытия, закрытия соединения и отправки сырых байт. Связь осуществляется с использованием сообщений APDU, с набором команд, как определено в стандарте ISO / IEC 7816-4. Кроме того доступ к SE не является общедоступными и контролируется Google и ее партнерами, в настоящее время нет никакого способа установки пользовательских апплеты на встроенные SE [22]. Использование элемента безопасности зарезервировано для приложений Google, таких как GoogleWallet. Следовательно, использовать средства элемента безопасности для реализации нашего криптографического

         протокола не представляется возможным.

         Следующим вариантом разработки на платформе Android является отказ от использования защищенного элемента и разработка с использованием режима точка-точка. Однако в AndroidAPI нет способа использования режима NFC точка-точка отдельно от технологии AndroidBeam. Эта технология представляет собой функции высокого уровня, реализованные поверх режима NFC точка-точка, для отправки сообщений NDEF между двумя телефоны. К сожалению, эта технология не подходит для комплекса связи с использованием более одного сообщения, потому что каждое сообщение должно быть вручную одобрено для отправки с помощью прикосновения к экрану при появлении надписи «Touch to Beam». Т.е. общение между устройствами с использованием нескольких сообщений практически невозможно, так как пользователю придется нажимать на экран

         телефона большое количество раз.

         Технология Android Beam построена по протоколу SNEP, что позволяет осуществлять прозрачный обмен данными с помощью сообщений NDEF. Но,

         к сожалению, нет API для прямого использования протокола SNEP.

         Лучшим режимом работы NFC, который поддерживается, является режим чтения / записи. Основной случай использованияNFC на Android – "читать NDEF из NFC метки» [23], что означает, что телефон превратится в

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

         секрета.

         Следовательно, использовать платформу Android для реализации криптографического протокола неудобно, из-за ограничений в API в использовании протокола SNEP и ограничений накладываемых технологией AndroidBeam.

         
          

      2. iOS‌

         
          

         Поддержка технологии NFC на устройствах с операционной системой iOS началась с выхода в сентябре 2014 смартфонов iPhone 6 и iPhone 6 plus. Однако, ход компании таков, что использование технологии NFC не доступно никому, кроме самой компании Apple. Технология NFC в iPhone жестко связана с платежной системой ApplePay и использование технологии не доступно сторонним разработчикам.

         
          

      3. BlackBerry‌

         
          

         Несмотря на меньшую распространенность смартфонов на платформе BlackBerryпо сравнению с Android, iOSи Windows, BlackBery предоставляет API для работы со всеми режимами NFC практически без ограничений [24]. Кроме того, дополнительно представлена возможность с помощью NFC установить соединение Bluetoothили Wi-fi. Однако, ввиду того, что нет эмуляторов NFC для платформы BlackBerry, а также из-за недоступности реальных устройств от идеи реализовать протокол на платформе BlackBerry пришлось отказаться.

         
          

      4. Windows‌

Функции в Windows API для взаимодействия по технологии NFC имеют больше возможностей в отличии от Android API. Также как и на платформе Android поддерживаются режимы точка-точка и режим

чтения/записи меток.

Помимо API Microsoft предоставляет возможность настроить среду для разработки и тестирования без настоящих NFC-устройств, с использованием

симуляторов.

Функции в Windows API для NFC взаимодействия в режиме точка- точка, как сказано в справочнике по API [25], не обеспечивают аутентификацию, шифрование или целостность сообщений. Microsoft рекомендует не использовать технологиюNFC для передачи конфиденциальных сведений пользователей, каких как пароли, финансовые данные, текстовые сообщения, сообщения электронной почты, фотографии

или официальные идентификационные номера.

Устанавливать связь с помощью технологии близкого взаимодействия на платформе Windows можно несколькими способами:

• Сеансы за пределами диапазона. Можно установить сеанс с помощью

  объекта PeerFinder, который соединяет устройства путем передачи данных за пределами диапазона (Bluetooth или Wi-Fi). Хотя диапазон работы технологии NFC ограничен 10 сантиметрами, возможности передачи данных за пределами диапазона намного шире и больше скорость передачи. Поэтому есть смысл использовать NFC как быстрое

  и удобное соединение с помощью других беспроводных технологий.

• Установка одноранговой связи. Можно установить сеанс с помощью

  метода PeerFinder.FindAllPeersAsync(). Этот метод позволяет найти все удаленные одноранговые устройства, на которых выполняется это же приложение, если на них также был вызван метод PeerFinder.Start(),

  чтобы объявить их доступными для однорангового сеанса.

• Публикация и подписка на сообщения: можно отправлять и получать

сообщения при касании с помощью объекта ProximityDevice.

Кроме того, есть разумные ограничения на использования связи посредством NFC. Можно находить другие устройства, только если приложение которое выполняет поиск и соединение устройств выполняется на переднем плане. Это ограничение является защитой от

несанкционированного считывания или передачи данных.

Для взаимодействия по NFC приложение может создавать только

объекты StreamSocket, если в приложении задействовано соединение другого типа, то оно не сможет использовать для связи NFC-интерфейс.

После того, как приложение вызывает метод ConnectAsync для подключения к одноранговому устройству, приложение больше не будет объявлять о подключении и не будет найдено методом FindAllPeersAsync(), пока не вызовет метод StreamSocket.Close для закрытия подключения через сокет. При этом, если открывается подключение через сокет при помощи метода ConnectAsync, для устройства каждый раз можно открыть только одно подключение через сокет. Если разработанное приложение NFC или любое другое приложение вызывает метод ConnectAsync, существующее

подключение через сокет будет закрыто.

Каждое приложение на устройстве может иметь одно открытое подключение к одноранговому приложению на другом устройстве, если это подключение было установлено с помощью жеста касания. Можно открыть подключения через сокет из одного приложения к одноранговому приложению на нескольких устройствах, коснувшись каждого устройства. Но если создается подключение с помощью жеста касания, новый жест касания не закроет существующее подключение. Необходимо вызвать метод StreamSocket.Close объекта-сокета, чтобы создать новое подключение к тому же одноранговому приложению на том же одноранговом устройстве с

помощью жеста касания.

Однако, у Windows API, в отличие от Android, нет доступных для разработчиков функций для режима эмуляции карт. Но так как разработанный способ защиты канала требует режима точка-точка, это не является помехой. Поэтому, несмотря на отсутствие поддержки режима эмуляции карты, платформа Windows была выбрана в качестве платформы для реализации.

5.2 Результаты‌

В результате работы разработано приложение, написанное на языке C# и использующее криптографические средства из пространства имен System.Security.Cryptography. Приложение имеет простой интерфейс, скриншот представлен на Рисунке 14.

Рисунок 14 — Внешний вид разработанного приложения

В процессе разработки, отладки и тестирования использовались эмуляторы смартфона на платформе Windows и эмулятор NFC. В качестве эмулятора NFC использовался пример драйвера близкого взаимодействия из комплекта разработки драйверов для Windows (WDK). После установки WDK и примеров драйверов пример драйвера близкого взаимодействия будет находится в каталоге src\nfp в расположении, в которое были установлены примеры WDK. После запуска симулятор выполняется в фоновом режиме,

тогда как разработанное приложение близкого взаимодействия выполняется

на переднем плане.

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

Рисунок 15 — Схема работы приложения

Поясним схему:

1. Сближения устройства

2. Поиск устройства с помощью класса PeerFinder. Если другое устройство найдено, то статус меняется на PeerFound.

3. Найденному устройству, отправляется connectionRequest — у

   пользователя другого устройство запрашивается согласие на соединение.

4. Статус устройства A меняется на Listening, это значит что другое

   устройство начало жест касания.

5. Меняется и статус устройства B. Статус Connecting означает, что на

   устройстве был произведен жест касания и ожидается окончание установки соединения.

6. После того как соединение установилось, статус обоих устройств

   меняется на Completed.

7. Создается сокет с помощью объекта StreamSocket. С этого моментаникакое устройство больше не может найти настоящее устройство с

   помощью PeerFinder, пока не будет закрыто установленное соединение.

8. На каждом устройстве генерируются исходные данные для обмена ключами по Диффи-Хеллману с помощью класса

   ECDiffieHellmanKeyDerivationFunction.

9. Обмен сгенерированными данными. Данные упаковываются в NDEF

сообщение.

10.Вычисление общего ключа: byte[] z = CngKey.Import(bobPublicKey,

CngKeyBlobFormat.EccPublicBlob).

11. Генерация ключа для алгоритма шифрования: byte[] key =

alice.DeriveKeyMaterial(z)

12.Шифрование сообщение через CryptoStream.

1. Передача NDEF сообщения с зашифрованными данными. Дальше возможны два варианта разрыва соединения:

   
    

   • Вызывается метод CloseSocket, который закрывает созданный

     сокет, после вызова переменная хранящая симметричный ключ

     шифрования очищается. Для нового обмена данными необходимо заново создать сокет и сгенерировать новый ключ.

   • Устройства отдаляются. Тогда их статусы принимают значения

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

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

Таблица 5 Измерение времени передачи через интерфейс NFC

Как видно из таблицы разница в передаче сообщений небольшая. Все измерения проводились на машине с процессором Intel Core i7, 2.6 Гц, ОЗУ 8Гб, ОС: Windows 8.1 Pro. В качестве симулятора NFC использовался пример nfc-драйвера из Windows Driver Kit.

ЗАКЛЮЧЕНИЕ‌

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

Технология NFC сама по себе не защищает пользователей от

прослушивания трафика, т.е. все данные передаются в открытом виде. Отсутствуют стандарты и протоколы для защиты передаваемых данных.

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

данных по интерфейсу NFC.

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

прослушивания.

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

Хеллмана.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ‌

1. Vedat Coskun, Kerem Ok, Busra Ozdenizci, ― Near Field Communication From Theory to Practice‖, NFC Lab Istanbul, ISIK University, Turkey, 2012.

2. NFC controller PN544 for mobile phones and portable equipment [Электронный ресурс] URL: http://www.nxp.com/documents/leaflet/ 75016890.pdf (Дата обращения 12.05.2015).

3. Rankl Wolfgang. Smart card handbook. Chichester: Wiley, 2003, 1088 с.

4. Finkenzeller Klaus. RFID handbook: Fundamentals and applications in contactless smart cards, radio frequency identification and near-field communication. Chichester: Wiley, 2010, 462 с.

5. О технологии NFC [Электронный ресурс] URL: http://www.nfcexpert.ru/ru/glossary/nfc (Дата обращения 12.05.2015).

6. Near Field Communication [Электронный ресурс] URL: https://ru.wikipedia.org/wiki/Near_Field_Communication (Дата обращения 12.05.2015).

7. Warakagoda Narada. Презентация: Near Field Communication (NFC): Opportunities & Standards. [Электронный ресурс] URL: http://www.umts.no/ files/081028%20nfc_standards_payments%20Narada.pdf (Дата обращения 12.05.2015).

8. Yeager C. Douglas. Systems and methods for authorizing a transaction. [Электронный ресурс] URL: http://www.google.com/ patents/WO2012170895A1 (Дата обращения 12.05.2015).

9. ECMA-340. Near Field Communication Interface and Protocol (NFCIP-1).

10. ISO/IEC 14443-2. Identification cards — Contactless integrated circuit(s) cards

    • Proximity cards: Part 2: Radio frequency power and signal interface.

11. ISO/IEC 14443-3. Identification cards — Contactless integrated circuit(s) cards

    - Proximity cards: Part 3: Initialization and anticollision.

12. ISO/IEC 14443-4. Identification cards - Contactless integrated circuit(s) cards - Proximity cards: Part 4: Transmission protocol.

13. ECMA-352. Near Field Communication Interface and Protocol - 2 (NFCIP-2).

14. Стандарты NFC Forum [Электронный ресурс] URL: http://nfc-forum.org/ (Дата обращения 12.05.2015).

15. Техническая спецификация NFCForum-TS-NDEF-1.0. NFC Data Exchange Format (NDEF).

16. ECMA-373. Near Field Communication Wired Interface (NFC-WI).

17. TS 102 613. Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical and data link layer characteristics.

18. ISO/IEC 7816-4. Identification cards — Integrated circuit cards: Part 4: Organization, security and commands for interchange.

19. Rancl Wolfgang. Smart card handbook. Chichester: Wiley, 2003, 1088 c. 20.Ernst Haselsteiner, Klemens Breitfub. Security in Near Field Communication (NFC) .

1. К.С. Пан, М.Л. Цымблер — Алгоритм блочного симметричного шифрования Advanced Encryption Standard (AES) Технический отчет CELLAES-01, 2009 [Электронный ресурс] URL:http://pcs.susu.ru/projects/3/aes.pdf (Дата обращения 12.05.2015).

2. Android secure element execution environment. ELENKOV, Nikolay. Android Explorations [Электронный ресурс] URL: http://nelenkov.blogspot.nl/2012/08/ android-secure-element-execution.html (Дата обращения 12.05.2015).

23, Advanced NFC. Android Developers [Электронный ресурс] URL: http:

//developer.android.com/guide/topics/connectivity/nfc/advanced-nfc.html (Дата обращения 12.05.2015).

1. Справочник по NFC API BlackBerry [Электронный ресурс] URL: http://developer.blackberry.com/native/documentation/device_comm/nfc/nfc_api.h tml (Дата обращения 12.05.2015).

2. Справочник по NFC API Windows. [Электронный ресурс] URL: https://msdn.microsoft.com/ru-ru/library/windows/apps/br212057.aspx (Дата обращения 12.05.2015).

////////////////////////////