Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Правительство Российской Федерации

Федеральное государственное автономное образовательное

учреждение высшего образования

Национальный исследовательский университет

«Высшая школа экономики»

Факультет компьютерных наук

Департамент программной инженерии

Выпускная квалификационная работа

по направлению 09.03.04 «Программная инженерия»

подготовки бакалавра

Программное обеспечение для пропускной системы

на основе технологии NFC

Студента группы БПИ121 Кудрявцева Андрея Витальевича

Москва 2016 г.

Реферат

Работа посвящена организации пропускной системы на основе технологии NFC [12] и операционной системы Android [4].

В работе рассмотрены технические детали реализации стека протоколов NFC на Android OS и базовые средства обеспечения безопасности системы. Кроме того, особое внимание уделено механизму эмуляции бесконтактных карт в Android OS.

Объектом разработки является клиент-серверное приложение, обеспечивающее механизм виртуальных карт доступа. Серверная часть реализуется на базе фреймворка Flask, а клиентское приложение является Android-приложением для версии не меньше Android 4.4 KitKat.

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

Ключевые слова: пропускная система, СКУД, Android, NFC, HCE, Flask

Abstract

The paper is dedicated to organization of access control system based on NFC technology and Android OS [4].

In this work, there is a review of technical details of NFC protocols stack implementation in Android OS. Moreover, theoretical background on cryptography is presented to ensure the system security. In addition, special attention is paid to the mechanism of contactless cards emulation in Android OS.

Using a new approach including NFC technology allows to create simple and effective solution for access control system organization. Using of modern cryptographic algorithms allows to ensure the system security.

Keywords: Access Control System, Android, NFC, HCE, Flask

Основные определения, термины и сокращения

NFC (Near Field Communication) - технология, обеспечивающая простой и безопасный способ двусторонней коммуникации между устройствами. Особенностями технологии являются маленькая дистанция между устройствами (обычно, меньше 4 см.) и значительно меньшее энергопотребление в сравнении с похожей технологией Bluetooth [12]. Малая дистанция между устройствами позволяет избежать помех от других устройств, в особенности в людных местах. Максимальная скорость передачи данных по этой технологии составляет 424 кб/с, поэтому данная технология предназначена в основном для передачи небольших объемов данных.

RFID (Radio-frequency identification) - технология, использующая электромагнитное поле для передачи данных. Используется для автоматической идентификации объектов. Существуют два вида RFID меток: активные и пассивные. Активные метки имеют локальный источник энергии, а пассивные используют энергию от RFID считывателя. Существует огромное множество областей применения данных меток. Например, отслеживание животных или продуктов в супермаркетах [19].

Android - unix-подобная мобильная операционная система, в текущий момент разрабатываемая компанией Google. Android ОС была разработана в первую очередь для сенсорных экранов мобильных устройств, но после выхода версии Android 4.4 Kitkat, платформа также разрабатывается для других устройств, таких, как телевизоры, автомобили, часы и другие. Исходный код операционной системы доступен под лицензией Apache 2.0, за исключением патчей ядра операционной системы Linux, которые доступны под лицензией GPLv2. Согласно статистике, приведенной сайтом StatCounter, Android является самой популярной мобильной операционной системой с августа 2013 года [1].

Android Host-based Card Emulation - дополнительный метод эмуляции бесконтактных карт NFC, доступный начиная с Android 4.4 Kitkat. В отличие от предыдущей технологии эмуляции карт с элементом безопасности (Card Emulation with a Secure Element), данный метод не использует элемент безопасности, который обычно представляет собой отдельный чип в устройстве. Android HCE стек протоколов состоит из ISO14443-1 (физический слой), ISO14443-2 (радиочастотные параметры и модуляционные методы), ISO14443-3 (протокол инициализации и антиколлизионный протокол), ISO7816-4 (протокол обмена данными) [2]. На текущий момент, большинство существующих бесконтактных карт, включая бесконтактные платежные карты, основаны на этих протоколах. В дополнение, большинство популярных NFC устройств чтения, представленных сегодня, поддерживают данные протоколы. Эти факты позволяют создавать решения, основанные на эмуляции карт, используя исключительно устройства на базе операционной системы Android.

СКУД (Система контроля и управления доступом) - набор программного и технического обеспечений, предназначенных для регистрации и мониторинга объектов на территории организации.

MitM attack (man-in-the-middle) - способ атаки на систему, в котором злоумышленник перехватывает и подменяет сообщения без ведома корреспондентов.

Оглавление

• Реферат
• Abstract
• Основные определения, термины и сокращения
• Введение
• Глава 1. Особенности NFC в Android OS
• 1.1 HCE сервисы
• 1.2 Выбор сервиса
• 1.3 Группы AID
• 1.4 Application Protocol Data Unit (APDU)
• Выводы по главе
• Глава 2. Обеспечение безопасности системы
• 2.1 RSA
• 2.1.1 Генерация ключа
• 2.1.2 Шифрование
• 2.1.3 Расшифровка
• 2.2 Data Encryption Standard (DES)
• 2.2.1 Шифрование
• 2.2.2 Расшифровка
• 2.3 Advanced Encryption System (AES)
• 2.4 Протокол Диффи -- Хеллмана
• 2.4.1 Описание алгоритма
• 2.4.2 Пример20
• 2.5 HTTPS20
• 2.5.1 Как устанавливается SSL соединение20
• 2.5.2 Сертификаты
• 2.5.3Цифровая подпись
• Выводы по главе
• Глава 3. Разработка программы
• 3.1 Инструменты разработки серверной части
• 3.1.1 Django framework
• 3.1.2 Pyramid framework
• 3.1.3 Flask framework
• 3.1.4 Используемые плагины
• 3.2 Инструменты разработки клиентской части
• 3.3 Модель базы данных
• 3.4 Версионность базы данных
• 3.5 Описание API сервера
• 3.6 Описание процесса аутентификации API
• 3.6.1 Регистрация пользователя
• 3.6.2 Генерация токена
• 3.6.3 Получение токена
• 3.6.4 Использование токена
• 3.7 Описание API для коммуникации с СКУД31
• 3.8 Описание протокола коммуникации виртуальной карты и NFC-считывателя
• 3.9 Обеспечение безопасности коммуникации смартфона и NFC-считывателя
• 3.10 Анализ безопасности
• Выводы по главе
• Заключение
• Список использованных источников
• Введение

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

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

• Предложенное решение основано на использовании виртуальных карт доступа: смартфон участника используется как карта доступа. Данное решение лишено основных недостатков существующего аналога. Во-первых, выпуск виртуальной карты доступа не стоит ничего, а средняя цена карты с RFID тегом равняется $0.5 [14]. Для мероприятия с посещаемостью 20 000 стоимость карт составит $10 000. Во-вторых, чтобы получить карту пользователям не нужно ничего делать, карта может быть передана на их смартфон через Интернет.

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

1. изучить особенности работы NFC под операционной системой Android;

2. разработать модель базы данных для хранения пользовательской информации;

3. изучить существующие фреймворки для создания серверной части приложения;

4. выбрать фреймворк для сервера;

5. разработать API для коммуникации мобильного приложения и сервера;

6. разработать API для коммуникации сервера и СКУД организации;

7. реализовать серверную часть вместе с базой данных;

8. разработать мобильное Android приложение, использующее разработанное API;

9. провести анализ безопасности полученной системы;

10. разработать техническую документацию.

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

Глава 1. Особенности NFC в Android OS

Устройство на операционной системе Android с поддержкой технологии NFC поддерживает три способа взаимодействия. Первый способ - режим чтения/записи. Этот режим позволяет устройству считывать и записывать пассивные NFC метки. Пассивные метки - это микрокомпьютер, наподобие SIM-карт, со своими процессором, оперативной и постоянной памятью. Метки не имеют собственного источника питания, а питание получают за счет электромагнитной индукции при взаимодействии со считывателем [19]. Второй способ - режим peer-to-peer. Устройства могут обмениваться информацией, используя NFC. Данный метод используется технологией Android Beam [12]. Третий способ - режим эмуляции карты. Данный режим позволяет использовать устройство в роли NFC карты, которая может быть прочитана внешним NFC считывателем или другим Android устройством.

Примером использования первого режима работы является использование NFC меток рядом с объектами культуры, где они выступают в роли аналога QR-кодов и предоставляют ссылку на информацию о текущем объекте. Так же, с помощью Android устройства возможно создать свои собственные метки, например, можно создать метку с информацией о доступе к домашней Wi-Fi сети. Гость может прикоснуться своим смартфоном к такой метке и получить все необходимые данные для подключения. Разместить такую метку можно, например, на двери или на самом роутере. Примером второго режима является уже названная ранее технология Android Beam. С помощью данной технологии касанием устройств возможно поделиться контактом, ссылкой на страницу или передать фотографию [12]. Примерами третьего режима работы являются бесконтактная оплата и текущий проект - использование эмуляции карт для пропускной системы.

Рассмотрим подробнее режим эмуляции карты. Первый способ эмуляции карты - с использованием элемента безопасности (Secure Element). Элемент безопасности представляет собой отдельный микропроцессор аналогичный тем, что находятся в платежных картах. Элемент безопасности может быть встроенным в смартфон или находится на отдельном модуле: сим-карте UICC (Universal Integrated Circuit Card) или карте памяти [11]. Элемент безопасности сам взаимодействует с NFC терминалом. У Android-приложений нет возможности вмешиваться в эту транзакцию. После того как транзакция окончена, Android-приложение запрашивает статус транзакции у элемента безопасности - рис. 1 [11].

Рисунок 1. Эмуляция карт с использованием элемента безопасности

Другой способ - использование Host-based эмуляции карт. В этом способе взаимодействие происходит напрямую с CPU устройства - рис. 2.

Рисунок 2. Host-based эмуляция карт

1.1 HCE сервисы

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

1.2 Выбор сервиса

При прикосновении смартфона к считывателю, системе необходимо знать, какой сервис должен обработать этот запрос. Стандарт ISO/IEC 7816-4 определяет, каким образом это происходит. Процесс определения завязан на Application ID (AID). AID может состоять максимум из 16 байт. Если создается приложение, которое будет использовать существующую считывающую инфраструктуру, то необходимые AID обычно публично доступны. Если необходимо создать новую считывающую инфраструктуру, то необходимо создать свой AID. Процесс создания своего AID описан в стандарте ISO/IEC 7816-5.

1.3 Группы AID

В некоторых случаях сервису необходимо обрабатывать несколько AID. Для этого необходимо создать группу AID. Android гарантирует, что все AID в списке будут обрабатываться конкретным сервисом или ни один AID из списка не будет обработан данным сервисом. То есть невозможна ситуация, когда один AID из группы обрабатывается одним сервисом, а другой другим. Каждой AID группе должна соответствовать своя категория. Android 4.4 поддерживает две категории: CATEGORY_PAYMENT и CATEGORY_OTHER. Первая используется для платежных приложений, а вторая для всех остальных. Особенностью первой категории является то, что только одна AID группа в платежной категории может быть включена в системе в любой момент времени.

1.4 Application Protocol Data Unit (APDU)

На вход сервису от NFC считывателя приходит набор команд APDU. Формат этих команд определен в стандарте ISO/IEC 7816-4 [2]. APDU содержит либо команду, либо ответ на команду.

Команда APDU состоит из обязательного заголовка (CLA INS P1 P2) размером 4 байта и возможного тела сообщения (Табл. 1).

Таблица 1. Состав команды APDU

Заголовок	Тело
CLA INS P1 P2	[Lc поле] [Data поле] [Le поле]

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

Ответ APDU состоит из тела переменной длины и обязательного хвоста размером 2 байта (SW1 SW2) (Табл. 2).

Таблица 2. Состав ответа APDU

Тело	Хвост
[Data поле]	SW1 SW2

Описание полей заголовка команды и хвоста ответа приведены в табл. 3.

Таблица 3. Описание полей

Код	Имя	Описание
CLA	Class	Класс инструкции
INS	Instruction	Код инструкции
P1	Parameter 1	Параметр инструкции 1
P2	Parameter 2	Параметр инструкции 2
SW1	Status byte 1	Статус обработки команды
SW2	Status byte 2	Классификатор обработки команды

Возможные значения описанных выше полей описаны в стандарте ISO/IEC 7816-4 [2].

Выводы по главе

В данной главе рассмотрены особенности работы Near Field Communication в операционной системе Android. Были продемонстрированы режимы работы и способы применения данной технологии. Более подробно был описан механизм эмуляции бесконтактных карт Host-based Card Emulation.

сервер android фреймворк связь

Глава 2. Обеспечение безопасности системы

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

2.1 RSA

Для того, чтобы избежать перехват злоумышленниками пропусков, может быть использован криптографический алгоритм с открытым ключом RSA (Rivest, Shamir, Adleman). Алгоритм основан на асимметрии - умножить два больших простых числа не составляет труда, но задача факторизации является задачей большой сложности [6].

2.1.1 Генерация ключа

Ключи генерируются следующим образом [8]:

1. Выбрать два различных простых числа и . Такие числа могут быть эффективно найдены с помощью вероятностного теста Миллера-Рабина или Соловея-Штрассена.

2. Вычислить

3. Вычислить значение функции Эйлера от числа :

4. Выбрать целое число , взаимно простое с . Обычно выбираются простые числа Ферма (17, 257 или 65537), так как время, которое необходимо для шифрования с использованием быстрого возведения в степень, пропорционально количество битовых единиц в . Слишком малые значение e могут ослабить алгоритм [].

5. Вычислить такое, что , то есть мультипликативно обратное к числу по модулю .

6. Пара представляет открытый ключ.

7. Пара представляет закрытый ключ.

2.1.2 Шифрование

Предположим, что Боб хочет отправить сообщение Алисе. Сначала он кодирует сообщение в число . Затем берет открытый ключ Алисы и шифрует свое сообщение:

2.1.3 Расшифровка

Алиса получает сообщение и расшифровывает его с помощью своего приватного ключа : . Затем получает оригинальное сообщение .

2.2 Data Encryption Standard (DES)

Data Encryption Standard - созданный в 1975 году и стандартизированный в 1977 году блочный алгоритм симметричного шифрования. Алгоритм Triple DES (3DES) является прямым развитием алгоритма DES, в этом алгоритме шифрование и дешифрование выполняются путем троекратного выполнения алгоритма DES.

Рисунок 3. Алгоритм работы блочного шифра [17]

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

Блочные алгоритмы шифрования работают следующим образом: имеются два алгоритма и , соответственно, алгоритм шифрования и алгоритм дешифрования; На вход подаются: блок исходного сообщения длиной бит и ключ шифрования длиной . На выходе получается шифрованное сообщение длиной так же бит - рис. 3 [9].

2.2.1. Шифрование

Более подробный алгоритм блочного шифрования выглядит следующим образом: рис. 4.

Рисунок 4. Более подробная схема работы блочного шифра [17]

Входной ключ разбивается на n ключей с помощью алгоритма “key expansion”, который будет описан далее. Затем, сообщение итеративно проходит через функцию , которая принимает на вход ключ и текущую версию сообщения. Функция называется раунд-функцией (round function). Для 3DES .

Ключевой идеей DES является сеть Фейстеля рис. 5.



Рисунок 5. Сеть Фейстеля

Даны функции:

Необходимо построить инвертируемую функцию:

На вход подаются два блока и длиной бит. Блок встает на место , а получается из . Далее, аналогично, происходит итераций.

Рассмотрим полную схему алгоритма DES - рис. 6.

Рисунок 6. Структура DES [9]

Начальная и финальная перестановки - простые P-boxes перестановки, обратные друг другу.

Рассмотрим схему раунд-функции - рис. 7.

Рисунок 7. Раунд-функция [9]

Схема расширения 32-битного ключа в 48-битный изображен на рис. 8.

Рисунок 8. Expansion P-box [9]

Полученный XOR размером 48 бит разбивается на 8 групп по 6 бит. Затем каждые 6 бит попадают в так называемые S-boxes - отражение 6 бит в 4 бита. В итоге, получаем исходный размер - 32 бита.

2.2.2 Расшифровка

Расшифровка выглядит похожим образом на процесс шифрования, только процесс происходит в обратном порядке - рис. 9.

Рисунок 9. Расшифровка [17]

2.3 Advanced Encryption System (AES)

Advanced Encryption System - алгоритм шифрования, разработанный в 1998 году, который пришел на замену алгоритму DES. Данный алгоритм базируется на шифре Rijndael (Рэндал). Размер блока в AES бит, а размер ключа имеет три возможных значения: 128 бит, 192 бит и 256 бит. Чем больше размер ключа, тем безопаснее становится шифр, но, соответственно, увеличивается время работы алгоритма. Алгоритм AES, в отличие от DES, основан на сети подстановок-перестановок (Subs-Perm network). Отличие заключается в том, что в сети Фейстеля половина битов оставалась неизменной от раунда к раунду. В случае использования Subs-Perm network, все биты меняются каждый раунд [16].

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

Рассмотрим подробнее функции применяемые в каждом раунде - рис. 11, а именно:



Рисунок 10. Subs-Perm network

Рисунок 11. Алгоритм AES [7]

1. ByteSub

Операция замены байтов, где каждому значению исходной таблицы 4x4 ставится значение из таблицы замены размером 256 байт.

2. ShiftRow

Циклический сдвиг строк - рис. 12.

3. MixColumn

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

Стоит отметить, что в последнем раунде MixColumn не выполняется - рис. 11.



Рисунок 12. ShiftRow [16]

2.4 Протокол Диффи -- Хеллмана

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

Рисунок 13. Алгоритм Диффи-Хеллмана

2.4.1 Описание алгоритма

Обоим абонентам (Алиса и Боб) известны два числа и . Эти два числа открытые, они могут быть известны так же другим сторонам. является случайным простым числом. также должно быть случайным простым числом, для повышения безопасности. является первообразным корнем по модулю p () [23].

Алиса и Боб генерируют большие случайные числа и соответственно.

Затем Алиса вычисляет значение:

и пересылает его Бобу, а Боб вычисляет значение:

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

Алиса, на основе полученных данных, вычисляет:

Боб вычисляет:

В итоге, Алиса и Боб имеют одно и то же значение :

Наглядная работа алгоритма представлена на рис. 13.

2.4.2 Пример

2.5 HTTPS

HTTPS (HTTP over SSL/TLS) - это стандартный протокол HTTP со слоем шифрования по протоколу SSL/TLS. Сервер и клиент в случае HTTPS общаются все по тому же протоколу HTTP, но через безопасное SSL соединение, которое шифрует и дешифрует их запросы и ответы. SSL слой имеет 2 основные цели:

1. верификация того, что клиент коммуницирует именно с тем сервером, с каким он думает;

2. обеспечение того, что только сервер может прочитать данные, которые отправляет клиент, и только клиент может прочитать данные, которые посылает сервер.

Протокол обеспечивает безопасную коммуникацию даже по небезопасному каналу связи [9].

2.5.1 Как устанавливается SSL соединение

Коммуникация между клиентом и сервером начинается прежде всего с «рукопожатия» (SSL Handshake). Цели данного рукопожатия, следующие [10]:

1. клиент убеждается, что общается с нужным сервером (опционально, происходит и обратное);

2. стороны согласовывают набор шифров, который будет использоваться для коммуникации;

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

Фаза рукопожатия может быть разделена на 3 части:

1. Приветствие

Клиент отправляет клиентское приветствие (ClientHello) на сервер. Данное приветствие содержит поддерживаемые алгоритмы шифрования и максимальную версию SSL, которую поддерживает клиент. Сервер отвечает своим приветствием (ServerHello), которое содержит похожую информацию, включая решение какой шифр и какую версию SSL использовать из набора, используемого клиентом [10].

2. Обмен сертификатами

Когда соединение установлено, серверу необходимо доказать свою подлинность клиенту. Это достигается с помощью SSL сертификата, который выступает в роли документа, удостоверяющего личность. Данный сертификат содержит различную информацию, включающую имя владельца, домен, к которому прикреплен сертификат, публичный ключ сертификата, цифровую подпись и информацию о сроке действия сертификата. Клиент безоговорочно доверяет сертификату или же проверяет его с помощью одного из центров валидации (Certificate Authorities), которым он безоговорочно доверяет. Чуть более подробно об этом будет позже. Сервер также может запросить сертификат клиента, но обычно это происходит только в очень требовательных к безопасности приложениях [10].

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

Шифрование сообщений в протоколе SSL происходит с помощью симметричного алгоритма. Какой именно алгоритм будет использован было выяснено на фазе «рукопожатия». Обычно, это AES с размером ключа 128 бит (например, https://passport.yandex.ru использует данный алгоритм). Общий секретный ключ генерируется заново для каждого сеанса связи. Ключ представляет собой, обычно число длиной более 100 знаков [22]. Чтобы безопасно получить общий ключ для симметричного алгоритма, существует два самых популярных способа: первый способ - использование RSA. Клиент шифрует ключ публичным ключом сервера и передает его на сервер, где с помощью приватного ключа сервера сервер получает отправленный ключ. Второй способ - это использование алгоритма Диффи-Хеллмана, описание которого было представлено ранее [10].

2.5.2 Сертификаты

SSL сертификат представляет собой простой текстовый файл, который может быть редактирован и создан кем угодно. Чтобы убедиться в том, что сертификат легальный используется алгоритм цифровой подписи. Существуют две причины, чтобы доверять конкретному сертификату: сертификат находится в списке сертификатов, которым клиент безоговорочно доверяет и валидность сертификата можно проверить с помощью центра сертификации [10]. В первом случае, браузер имеет список предустановленных сертификатов от центров сертификации, которым можно доверять. Во втором случае, необходима проверка цифровой подписи, чтобы убедиться, что, например, владелец сертификата, утверждающий, что он Яндекс, действительно Яндекс.

2.5.3 Цифровая подпись

Алгоритм цифровой подписи основан на алгоритме RSA. Центр сертификации убеждается в том, что данный открытый ключ принадлежит определенному лицу или организации. Затем подписывает сертификат своим приватным ключом, который держится в секрете. В дальнейшем, любой может запросить публичный ключ центра сертификации и убедиться, что данный сертификат действительно подписан этим центром [3].

Выводы по главе

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

Глава 3. Разработка программы

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

3.1 Инструменты разработки серверной части

Для разработки серверной части приложения был выбран язык Python. Выбор языка обусловлен кроссплатформенностью решения и простотой разработки. Также для языка Python существуют большое количество фреймворков для создания RESTful API. Рассмотрим эти фреймворки.

3.1.1 Django framework

Фреймворк Django имеет все необходимое для разработки (шаблоны, формы, URL Routing, аутентификация, администрирование базы данных и прочее) сразу из коробки. Django также включает в себя ORM (Object Relational Mapper). Первый релиз Django произошел в 2006 году. Django - зрелый фреймворк с большим набором плагинов и расширений.

3.1.2 Pyramid framework

Фреймворк Pyramid включает инструменты для URL Routing и аутентификации, но не включает шаблоны и БД администрирование. Первый релиз в 2005 году. Так же, как и Django имеет большой набор расширений.

3.1.3 Flask framework

Flask позиционируется как микрофреймворк с базовым набором функций. Фреймворк создан прежде всего для небольших приложений. Flask самый молодой фреймворк, первый релиз датирован серединой 2010 года. Несмотря на возраст, фреймворк так же имеет большой набор плагинов. Так как наше приложение имеет относительно простой функционал (авторизация и хранение пропусков), то Flask фреймворк является оптимальным выбором.

Простейшее Web-приложение на Flask выглядит следующим образом - рис. 14.

Рисунок 14. Hello World на Flask

3.1.4 Используемые плагины

Flask-sqlalchemy

Данный плагин добавляет поддержку SQLAlchemy. SQLAlchemy в свою очередь является Object-relational mapping (ORM), позволяющем работать с базой данных.

Например, класс User с использованием данной ORM выглядит следующим образом - рис. 15.

Рисунок 15. Класс User

SQLAlchemy-migrate

Плагин используется для обеспечения версионности базы данных. Данный процесс будет описан далее.

3.2 Инструменты разработки клиентской части

Поскольку клиентская часть представляет собой приложение на базе операционной системы Android, то для ее разработки был выбран рекомендуемый разработчиком ОС язык Java. Для сборки используется так же рекомендуемые инструмент - Gradle.

3.3 Модель базы данных

База данных состоит из двух основных таблиц: User (табл. 4) и Passcard (табл. 5).

Таблица 4. Таблица User

Имя	Тип	Уникальное поле	Primary key	Описание
id	Integer	+	+	Идентификатор пользователя
f_name	String(40)	-	-	Имя
s_name	String(40)	-	-	Фамилия
t_name	String(40)	-	-	Отчество
password	String(32)	-	-	Хеш пароля
salt	String(50)	-	-	Соль для хеша пароля
phone	String(20)	+	-	Номер телефона
token	String(32)	-	-	Ключ для API
token_date	String(32)	-	-	Дата для ключа API
passes	Foreign key			Список пропусков

Таблица 5 Таблица Passcard

Имя	Тип	Уникальное поле	Primary key	Описание
id	Integer	+	+	Идентификатор пропуска
card_key	String(128)	-	-	Ключ пропуска
icon_url	String(256)	-	-	Ссылка на иконку
header_url	String(256)	-	-	Ссылка на фоновое изображения заголовка
title	String(128)	-	-	Заголовок
subtitle	String(128)	-	-	Дополнительная информация
expired	String(64)	-	-	Дата истечения пропуска (yyyy-mm-ddThh:mm:ss)

Также используется дополнительная таблица Passes (табл 6) для обеспечения связи много-ко-многим между классами User и Passcard.

Таблица 6 Таблица Passes

Имя	Тип	Уникальное поле	Primary key	Описание
pass_id	Integer	-	-	Идентификатор пропуска
user_id	Integer	-	-	Идентификатор пользователя

3.4 Версионность базы данных

С ростом приложения существует проблема обновления схемы базы данных с сохранением внесенных данных. Если информация в базе данных не может быть легко восстановлена необходимо создать скрипты для экспорта и импорта данных. Однако, существует плагин SQLAlchemy-migrate, который позволяет облегчить этот процесс [17].

Для начала использования этого плагина необходимо добавить следующие строчки в начало конфигурационного файла config.py рис. 16:

Рисунок 16. Конфигурация SQLAlchemy-migrate

SQLALCHEMY_DATABASE_URI - задает файл базы данных.

SQLALCHEMY_MIGRATE_REPO - задает директорию, где будут храниться файлы миграции.

Файл инициализации пакета приложения должен выглядеть следующим образом рис. 17:

Рисунок 17. __init__.py

Для создания базы данных используется следующий скрипт рис. 18:

Рисунок 18. db_create.py

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

Таблица 7 Таблица migrate_version

repository_id	repository_path	version
database repository	C:\...\PassCardServer\db_repository	4

Также создается директория db_repository, где находятся файлы для поддержки версионности. Каталог имеет следующую структуру рис. 19:

Рисунок 19. Структура db_repository

В папке versions находятся скрипты для миграции на определенную версию.

Для перехода на следующую версию БД используется следующий скрипт рис. 20:

Рисунок 20. db_migration.py

Суть миграции заключается в том, что скрипт вычисляет разницу между версиями БД и записывает эту разницу в виде скрипта в директорию /db_repository/versions.

Апгрейд и даунгрейд базы данных производятся с помощью следующий скриптов рис. 21 и рис. 22:

Рисунок 21. db_upgrade.py

Рисунок 22. db_downgrade.py

3.5 Описание API сервера

Таблица 8 Описание API

URL	Метод	Параметры	Возвращает	Вариант
/login	POST	phone - form-data	JSON {`token', `id'} - ID пользователя и токен	Успех
		password - form-data	JSON { 'error_msg': 'Not authorized'}, код 401	Неправильный логин/пароль
			JSON { 'error_msg': 'Bad parameters'}, код 400	Не заданы необходимые поля
/register	POST	phone - form-data	JSON {User}, код 201, редирект на /users/id	Успех
		password - form-data	JSON { 'error_msg': 'User with phone %s already exists}, код 409	Пользователь уже существует
/users/{id:int}	GET	id - параметр пути	JSON {User}, код 200	Успех
		token - аргумент	JSON { 'error_msg': 'Not authorized'}, код 401	Некорректный токен
			JSON { 'error_msg': `User not found'}, код 404	Пользователь не найден
	PUT	id - параметр пути	JSON {User}, код 200	Успех
		token - аргумент	JSON { 'error_msg': 'Not authorized'}, код 401	Некорректный токен
		password, f_name, s_name, t_name - аргументы	JSON { 'error_msg': `User not found'}, код 404	Пользователь не найден
/cards/{user_id:int}	GET	user_id - параметр пути	JSON {Passcard}, код 200	Успех
		token - аргумент	JSON { 'error_msg': 'Not authorized'}, код 401	Некорректный токен
			JSON { 'error_msg': `User not found'}, код 404	Пользователь не найден
/encrypt	GET	msg - сообщение для шифровки	JSON { 'msg': 'Encrypted message'}, код 200	Успех
			JSON { 'error_msg': 'Bad parameters'}, код 400	Не указан параметр msg
/decrypt	GET	msg - сообщение для расшифровки	JSON { 'msg': 'Decrypted message'}, код 200	Успех
			JSON { 'error_msg': 'Bad parameters'}, код 400	Не указан параметр msg
/new_card	POST	icon_url - ссылка на иконку	JSON {Passcard}, код 201	Успех
		header_url - ссылка на изображение для заголовка
		title - заголовок	JSON { 'error_msg': 'Not authorized'}, код 401	IP адрес клиента не входит в список доверенных
		subtitle - подзаголовок
		expired - время истечения пропуска в формате
/cards	GET	id - идентификатор	JSON {Passcard list}, код 200	Успех
		is_expired - истек ли срок
	DELETE	title - заголовок	JSON { 'error_msg': 'Not authorized'}, код 401	IP адрес клиента не входит в список доверенных
/card_to_user	PUT	card_id - идентификатор карты	JSON {User}, код 200	Успех
	DELETE	pass_id - идентификатор пропуска	JSON { 'error_msg': 'Not authorized'}, код 401	IP адрес клиента не входит в список доверенных

3.6 Описание процесса аутентификации API

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

3.6.1 Регистрация пользователя

Для регистрации пользователя необходимо методом POST передать на адрес `/register' телефон и пароль в полях `phone' и `password' (тип содержимого - multipart/form-data). Если пользователь с текущим телефоном не зарегистрирован, создается новый пользователь. Пароль пользователя перед сохранением хешируется с помощью алгоритма MD5 с использованием «соли». MD5 является одним из самых популярных алгоритмов хеширования, а использование соли позволяет избежать взлома хеша с помощью таблиц. Хеш и соль сохраняются в соответственные поля таблицы User.

3.6.2 Генерация токена

Токен генерируется по формуле: , где password - нехешированный пароль пользователя, salt - случайно сгенерированная «соль», tokenDate - время генерации токена. Использование времени генерации токена позволяет получать каждый раз разные токены.

3.6.3 Получение токена

Для того, чтобы получить Token необходимо обратиться к адресу `/login' методом POST. Тело запроса должно содержать два параметра `phone' и `password' (тип содержимого - multipart/form-data). В случае удачной аутентификации, клиент получает id пользователя и token в формате JSON.

3.6.4 Использование токена

Полученный токен должен передаваться с каждым последующим запросом в HTTP заголовке `Authorization'. Токен имеет ограниченное время жизни, которое равняется 5 минутам. Каждый запрос к API, который требует аутентификацию, продлевает время жизни текущего токена, сбрасывая его на 5 минут. Данный механизм позволяет избежать последствий утечки токена.

3.7 Описание API для коммуникации с СКУД

Особенностью API для коммуникации с СКУД является то, что авторизация методов происходит не с помощью токена, а с помощью проверки IP адреса клиента на вхождение в список доверенных. Использование данного подхода позволяет избежать создания дополнительного типа пользователей, но в то же время, обеспечивает необходимую безопасность. Для создания нового пропуска используется метод /new_card, для получения списка пропусков с заданными параметрами или для удаления пропусков используется метод /cards. Для того, чтобы связать пропуск и пользователя, используется метод /card_to_user. Более подробно эти методы описаны в главе 3.5.

3.8 Описание протокола коммуникации виртуальной карты и NFC-считывателя

Коммуникация между смартфоном и NFC-считывателем происходит путем обмена массивами типа byte. Инициатором коммуникации выступает NFC-считыватель. Считыватель посылает команду Select следующего формата:

Таблица 9 Формат команды Select от считывателя

CLA INS P1 P2	AID длина	AID карты	SW
0x00 0xA4 0x04 0x00	0x07	0xF0 0x01 0x02 0x03 0x04 0x05 0x06	0x00

Подробное описание полей можно найти в главе 1.4.

В ответ на запрос Select от считывателя смартфон посылает зашифрованный идентификатор активной виртуальной карты. В случае отсутствия активной виртуальной карты посылается пустой массив.

3.9 Обеспечение безопасности коммуникации смартфона и NFC-считывателя

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

Механизм основан на использовании алгоритма RSA. Клиент, используя защищенный протокол https отправляет pass_id выбранного пропуска методу encrypt на сервер. Метод encrypt приписывает текущую метку времени к идентификатору и шифрует публичным ключом. Полученный результат возвращается клиенту (рис. 23).

Клиент, используя NFC, отправляет полученную последовательность на считыватель. Считыватель обращается на сервер к методу decrypt, передавая полученную последовательность как параметр.



Рисунок 23. Шифрование идентификатора пропуска

Метод decrypt работает в режиме белого списка IP адресов. IP-адрес считывателя должен быть задан заранее в конфигурации сервера. Метод decrypt расшифровывает полученную последовательность, получая идентификаторы пропуска (pass_id) и временную метку (timestamp). Сервер осуществляет проверку на истечение полученного хеша: в случае, если на момент расшифровки прошло больше 30 секунд, сервер возвращает пустой результат (рис. 24).

Рисунок 24. Расшифровка идентификатора пропуска

3.10 Анализ безопасности

Для обеспечения безопасности системы было решено использовать протокол HTTPS для связи клиента и сервера. Использование протокола HTTPS для коммуникации клиента и сервера с использованием последней на данный момент версии TLS v.1.2 позволяет обеспечить защиту от перехвата персональных данных клиента и несанкционированного доступа к информации о пропусках. Механизм защиты описан в главе 2.5.

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

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

Выводы по главе

В главе 3 подробно рассмотрены аспекты реализации системы. Приведены обзор инструментов, схема используемой базы данных и описание полученного интерфейса (API) сервера. В дополнение, рассмотрены вопросы обеспечения безопасности такие, как аутентификация пользователя и шифрование каналов связи.

Заключение

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

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

Помимо разработки приложения были изучены современные алгоритмы криптографии такие, как RSA, DES и AES. Была исследована работа безопасного протокола HTTPS. После завершения разработки программы был проведен анализ безопасности полученной системы.

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

1. изучены особенности работы NFC под операционной системой Android;

2. разработана модель базы данных для хранения пользовательских данных;

3. изучены существующие фреймворки для создания серверной части приложения;

4. выбран фреймворк для сервера;

5. разработан API для коммуникации мобильного приложения и сервера;

6. разработан API для коммуникации сервера и СКУД организации;

7. реализована серверная часть вместе с базой данных;

8. разработано мобильное Android приложение, использующее разработанное API;

9. проведен анализ безопасности полученной системы;

10. разработана техническая документация.

Список использованных источников

1. AES vs SSL/TLS: Encryption for the internet of things // Electronic products.

2. Android // Android.

3. Automatic Identification and Data Collection (AIDC) // MHI:

4. Boneh D. Twenty Years of attacks on the RSA Cryptosystem, 1999. С. 203-213.

5. Bulk Encryption on GPUs // AMD.

6. Chiluka S.R. Public key Cryptography

7. Data Encryption Standard // Tutorials Point.

8. Free Invisible Web Tracker, Hit Counter and Web Stats // StatCounter

9. Heaton R. How does HTTPS actually work?

10. Host-based Card Emulation // Android Developers.

11. Near Field Communication // Android Developers.

12. NFC and Contactless Technologies // NFC Forum.

13. RFID FREQUENTLY ASKED QUESTION // RFID Journal

14. Rivest R. The Early Days of RSA -- History and Lessons

15. Standing Document 1 (SD1): WG8 Projects // Draft ISO/IEC 14443 standards

16. The AES block cipher // Courser.

17. The Data Encryption Standard // Coursera.

18. The Flask Mega-Tutorial, Part IV: Database // Flask Web Development.

19. Используем NFC для автоматизации // Xaker.

20. Как мы превратили телефон в банковскую карту // Habrahabr.

21. Технология NFC в смартфонах // IXBT.com

22. Что такое протокол HTTPS, и как он защищает вас в интернете // Блог Яндекса.

23. Шнаер Б. Прикладная криптография. Москва: Триумф, 2002. 54-86 с.

Размещено на Allbest.ru