CC BY
41RESEARCH AND ANALYSIS OF SMART HOME SYSTEMS MOBILE APPLICATION SECURITY
Sabirzyanov D.S
4rd year postgraduate student of the Mathematical Modeling department of the
National Research University "MPEI"
ИССЛЕДОВАНИЕ И АНАЛИЗ БЕЗОПАСНОСТИ МОБИЛЬНОГО ПРИЛОЖЕНИЯ СИСТЕМЫ
ТИПА «УМНЫЙ ДОМ»
Сабирзянов Д.Ш.
аспирант 4-го года обучения кафедры Математического Моделирования Национального Исследовательского университета "МЭИ"
Abstract
In this work are adduced the review and analysis of smart home hybrid mobile application security. It's made a guess that there is a possibility for an access to all smart home security and engineering systems from mobile application. Because of it the mobile application security is one of the most important things have to be in smart home systems.
The aim of this work is to generalize, analyze and show vulnerabilities from point of view of mobile application security and also to offer decision for providing the highest mobile application security level against possible interventions from the side of malefactors.
In this work also is adduced technical architecture of fault tolerant and crypto tolerant client-server mobile applications.
Аннотация
В данной работе представлен обзор и анализ систем безопасности гибридных мобильных приложений управления системой типа «Умный дом». Поскольку предполагается, что с мобильного приложения возможен доступ ко всем инженерным системам и системам безопасности умного дома, вопрос безопасности самого мобильного приложения также является очень важным.
Целью данной работы является обобщить, проанализировать и показать уязвимости с точки зрения безопасности мобильного приложения, а также предложить решения для обеспечения максимального уровня защиты приложения от возможных вмешательств со стороны злоумышленников.
Также в этой работе подробно описана схема построения отказоустойчивых и криптоустойчивых клиент-серверных мобильных приложений.
Keywords: smart home, home automation, building automation, mobile application security.
Ключевые слова: умный дом, система домашней автоматизации, автоматизация зданий, безопасность мобильных приложений.
Введение
В данной работе рассмотрена масштабируемая архитектура клиент-серверного приложения для многопользовательской системы умный дом. Предложены варианты масштабирования, использования различных методов для возможности обеспечить многопользовательские подключения.
Также рассмотрен один из вопросов безопасности приложения, предложены варианты шифрования данных и аутентификации на стороне сервера на основе протокола Kerberos и схемы Блома.
1. Архитектура клиент-серверных мобильных приложений 1.1. Общее описание и архитектура системы
Мы предполагаем, что мобильное приложение управления системой «умный дом» имеет клиент-серверную архитектуру.
На схеме ниже представлена удобная для восприятия схема клиент-серверной архитектуры:
Android iOS Browser
Рис 1. Клиент-серверная архитектура кросс-платформенных приложений1
В этом случае сервер (или кластер серверов) является центральным управляющим элементом системы «умный дом». Он же - хранилище данных для функционирования системы и для восстановления их в случае нештатной ситуации.
Вся архитектура является масштабируемой, портируемой, интероперабельной, отказоустойчивой, безопасной. Рассмотрим подробнее отказоустойчивость и безопасность.
1.1. Отказоустойчивость
Отказоустойчивость — свойство технической системы сохранять свою работоспособность после отказа одного или нескольких составных компонентов. 2
Говоря об отказоустойчивости системы мы подразумеваем отказоустойчивость центрального контроллера, поскольку он - центральное и самое высоконагруженное звено системы, так или иначе подконтрольное разработчику. Здесь можно использовать принципы построения fault-tolerant серверных архитектур. [3], [4], [5], [6], [7], [8], [9]
Изначально система «умный дом» не является отказоустойчивой, однако используя методы горизонтального масштабирования можно сделать ее таковой.
Рассмотрим 2 возможных варианта размещения центрального контроллера, которое предполагается в системе.
1.1.1. Центральный контроллер - находится локально внутри системы.
Другими словами - за центральный контроллер отвечает конечный пользователь: чаще всего в таких случаях центральный контроллер размещается в том здании, внутри которого будет реализована система «умный дом». Самым распространенным решением является масштабирование системы
до отказоустойчивой. Это означает, что необходимо дублировать центральный контроллер так, что при выходе его из строя в систему включалась дублирующий центральный контроллер. Также в отдельных случаях можно дублировать актуаторы, датчики и линии коммуникации, но, как правило, на практике такие решение получаются чрезвычайно громоздкими и дорогостоящими.
1.1.2. Центральный контроллер будет находится на удаленном сервере разработчика в да-тацентре.
Доступ к центральному контроллеру будет происходить из системы «умный дом» как к удаленному серверу. Организацию серверной архитектуры в этом случае берет на себя разработчик системы. Нужно оговориться, что в этом случае, при необходимости пользователю все же может потребоваться установка и несложная настройка шлюза и маршрутизатора локально внутри системы «умный дом», если взаимодействие оборудования идет не по протоколу TCP/IP.
Планируя высокие нагрузки на систему, большое количество обращений и высокие требования по времени доступности центрального сервера, необходимо использовать архитектуру, которая помимо отказоустойчивости соответствовала бы минимальным требованиям так называемых high-load систем (под high-load понимают высоконагружен-ную систему). Понятия high-load и отказоустойчивость идут бок о бок. В качестве решения обеспечения одновременно и отказоустойчивости и high-load является архитектура, взятая из реального проекта автора данной работы и изображенная на рисунке 8.
1 https://edipsesource.com/blogs/2012/04/16/serving-mobile-devices-with-server-side-apps/
2 https://ru.wikipedia.org/wLki/Отказоvстойчивость
■ CDN for exchange for EU * 1 1 i
Requests handler servers 5.187.0.66 5.187.5.39 212.224.113.170 91.228.154.188 91.228,153,141 1 1 1
Servers with databasesMasters fMvSQL. -i -i 1 1 1
Servers with Databases-Slaves (MySQL, Redis) 185.26.97.208 (APR) i 1
Balancer Server (EU) i
1
212.224.112.22 5.187.5.61 5.187.2.4 91.228.153.181 5.187.2.101 5.187.0.132 Redis) 5.167.2.22 (APR) i i
1 1 i
I I 1 1
I I
i i 1 1 1
1 1 1
i 1
Рис. 2. Пример обеспечения отказоустойчивости и high-load
На рис. 8:
Balancer Server - сервер-балансировщик, к которому идут все обращения. Этот сервер основан на HTTP-сервере nginx и его основная цель - балансировать нагрузку, перенаправляя запросы дальше на наиболее разгруженный сервер в данный момент времени.
Request handler servers - серверы-обработчики запросов, каждый из которых идентичен другому. На каждом из серверов находится программный код приложения, который исполняется при вызове конкретного сервера.
Servers with databases-masters - сервер баз данных для записи данных, в которой хранится информация о состоянии системы, аутентификационные данные пользователей и другая информация для доступа к системе «умный дом» и восстановления данных в случае нештатной ситуации. Для чаще всего востребованных данных также можно использовать Redis - программное обеспечение для ускорения чтения и записи наиболее востребованных, так называемых «горячих», данных.
Servers with databases-slaves - сервер баз данных, который является копией предыдущего сервера, однако данные в нем предназначены только для чтения.
Также не стоит забывать о серверах, на которых находится программная реализация конструктора кросс-платформенных мобильных приложений и интерфейс пользователя, при помощи которого будет создаваться и настраиваться приложение под конкретный «умный дом» (см. рис. 2).
Все сервера должны находится в одной локальной сети для минимизации времени обращения между ними.
Также при широких масштабах распространения можно построить систему CDN по всему земному шару для обеспечения быстрого отклика от удаленного сервера.
Сеть доставки (и дистрибуции) содержимого (англ. Content Delivery Network или Content Distribution Network, CDN) — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию содержимого конечным пользователям в сети Интернет. Использование контент-провайдерами CDN способствует увеличению скорости загрузки интернет-пользователями аудио-, видео-, программного, игрового и других видов цифрового содержимого в точках присутствия сети CDN. 3
Основной прицип CDN - развертывание идентичных систем в географически распределенных датацентрах для минимизации времени соединения между управляющими, исполнительными устройствами и центральным сервером.
Выбор CDN может происходить после определения географии нахождения пользователя по IP-адресу при его первом обращении к системе при помощи сторонних продуктов, таких как, GeoIP2 от компании MaxMind.4
2. Безопасность гибридного приложения 2.1. Общие особенности системы безопасности гибридного приложения Безопасность системы играет важную роль. Действительно, заполучив доступ к системе «умный дом», злоумышленник мог бы управлять оборудованием в доме, что, безусловно, повлияло бы на покой жителей и на безопасность их быта.
Рассмотрим более подробно нашу систему. [1],
[2]
Каждое приложение представляет собой потенциальную угрозу для ее разработчиков. При вмешательстве хакеров5 они могут лишиться, например, части прибыли от продажи контента, потерять статус уникальности приложения, и т.д. Популярное приложение с надежной архитектурой, большим функционалом, хорошей графикой и платным контентом имеет большие шансы быть атакованным хакерами. Причины атаки могут быть
3 https://ru.wikipedia.org/wiki/Content Delivery Network
4 https://www.maxmind.com/ru/home
5 Здесь и далее «хакер», «криптоаналитик» и «злоумышленник» - одно и то же понятие
разными: копирование структуры приложения, взлом платного контента и т.п.
Стоит также помнить о том, что не существуют абсолютно безопасных приложений. Как показывает практика, если злоумышленникам действительно нужно взломать приложение, они это сделают. Но взлом в таком случае займет много времени и других ресурсов. Главной целью системы безопасности является запутывание злоумышленника, чтобы он посчитал, что взлом приложения слишком трудоемкий процесс и отказался от него.
Как уже говорилось ранее архитектура конструктора мобильного приложения имеет клиент-серверную структуру (см. рис. 7). Основные компоненты клиент-серверной архитектуры: клиент (в нашем случае мобильное устройство), сервер (в нашем случае ^аодо-СМ8 сервер, сервер баз данных и сервер-обработчик данных), и связь между ними для передачи данных.
Для безопасности приложения должны быть безопасными все части архитектуры. В этом параграфе будет исследована комплексная система безопасности, сделан выбор в пользу наиболее оптимального варианта и указаны некоторые подробности реализации. Решения будут рассматриваться для всех трех компонентов: безопасность устройства, безопасность серверной части и безопасность передачи данных между ними.
Основные требования к системе безопасности:
1. Система безопасности должна обеспечивать защиту от «гип-йтоьманипуляций, реверс-инжиниринга.
2. Система безопасности должна давать возможность шифровать данные и обеспечивать безопасность контента, загруженного клиентом на сервер.
3. Система безопасности должна обеспечивать безопасность всех частей архитектуры конструктора кроссплатформенных мобильных приложений.
4. Система безопасности должна обеспечивать защищенность схемы покупки платного контента.
Система безопасности должна разрабатываться комплексно: недостаточно разработать шифрование данных без, например, разработки обфускации. В таком случае хакер может прочитать исходный код и понять алгоритм шифрования. После - несложно расшифровать зашифрованные данные. Аналогичная ситуация и с другими частями системы безопасности. Другими словами, система безопасности должна быть, как бы, полной.
Рассмотрим далее возможные атаки и варианты реализации защиты данных на стороне устройства.
Подробно с методами обфускации кода, технологиями для ограничения доступа к данным приложения, способами хранения ключей шифрования, безопасностью передачи данных, безопасностью на стороне клиента и сервера, методами распознавания Jailbreak и root-устройств можно ознакомиться в [2].
Рассмотрим подробнее методы шифрования файлов на стороне устройства.
2.2. Шифрование данных
Для обеспечения конфиденциальности данных на устройстве должно быть защищенное хранилище данных, которое может обеспечить безопасное чтение и запись файлов.
Для лучшего уровня безопасности должно быть реализовано шифрование файлов «на лету», например, при получении их с сервера. Известно, что протоколы передачи данных по сети дробят файлы на пакеты и передают их.
Помимо классических методов шифрования можно использовать внутренние web-сервера в приложении (напр., «cocoahttpServer»6 для iOS) для хранения данных в базе данных web-сервера. Обмен данными между встроенным web-сервером и остальной частью памяти посредством https-прото-кола (или посредством «HTTP Live Streaming» в iOS).7 [10]
Как можно заметить, принцип заключается в получении файлов, как бы, частями, по блокам. При этом каждый последующий блок шифруется и сохраняется в памяти устройства. Это делается для того, чтобы в памяти устройства данные не задерживались на долгое время, и шифровались сразу по мере поступления. Похожий алгоритм работает при расшифровке файла для его чтения.
Блочное шифрование должно быть последовательным, так как для воспроизведения медиа-контента нужно расшифровывать данные последовательно.
Вариант с использованием внутренних web-серверов в приложении является очень безопасным из-за наличия встроенной базы данных с контролируемым доступом внутри web-сервера внутри приложения. Однако такая архитектура делает приложение более громоздким и сложным с точки зрения реализации внутренней архитектуры. Нативные решения такого плана, к тому же, не являются гибкими, ибо при изменении, например, протокола передачи данных или web-сервера необходимо менять исходный код программы, пользователям же надо обновить приложение.
Кроме того должен быть реализован обмен данными между web-сервером и другими частями приложения. Например, в операционной системе iOS существует специальный видео-ориентированный протокол «HTTP Live Stream»8, посредством
6 Описание CocoaHTTPServer: https://github.com/robbiehanson/CocoaHTTPServer
7 Согласно обсуждениям на форумах: http://stackoverflow.com/questions/13271624/can-ios-de-
vices-stream-m3u8-segmented-video-from-the-local-file-system-using-htm/
http://stackoverflow.com/questions/13286992/can-i-deploy-cocoa-http-server-with-my-phonegap-cordova-ios-app/ 8 Руководство Apple Developer:
https://developer.apple.com/library/ios/documentation/netw orkinginternet/conceptual/streamingmediaguide/UsingHTTP LiveStreaming/UsingHTTPLiveStreaming.html#//apple ref/ doc/uid/TP40008332-CH102-SW1
которого возможна передача зашифрованных данных. Но в других операционных системах подобных специализированных протоколов не существует, можно только использовать SSL-протокол в комбинации с инструментами шифрования/дешифрования и воспроизведения. Использование SSL-протокола внутри приложения несет в себе обязанности по периодическому обновлению протокола и по обязательству пользователей переустановки приложения после каждого такого обновления.
Наиболее подходящим в нашем случае является вариант, когда зашифрованный файл все время хранится на носителе и перед использованием расшифровывается в оперативную память. Далее файл считывается и после этого удаляется из оперативной памяти. Шифрование происходит по похожему алгоритму: при получении файлов весь файл сначала записывается в оперативную память, затем шифруется и записывается в основную память, при этом после шифрования файл удаляется из оперативной памяти.
Наиболее распространенными симметричными алгоритмами блочного шифрования данных на сегодняшний день являются AES и DES.
Однако, из-за возможности прослушивания канала передачи данных, стоит рассмотреть возможности защиты от таких атак.
Так как одним из условий является возможность хранения данных на устройстве и их использовании без наличия интернета, необходимо рассматривать симметричные алгоритмы предварительного распределения ключей, чтобы устройство могло расшифровывать данные без доступа канала передачи данных.
Распространенным решением подобных задач является схема распределения ключей Блома. [12]
Суть схемы распределения ключей Блома следующая: доверенная сторона раздаёт каждому участнику открытый и закрытый ключ. Далее все участники, обмениваются между собой только открытыми ключами по каналам связи (которые могут быть незащищенными), а также могут сгенерировать секретный сеансовый ключ для общения между собой.
Говоря подробнее, сначала происходит инициализация, т.е. доверенная сторона выбирает симметричную матрицу Б размерности к на к над конечным полем вР(р). Далее, когда новый участник хочет присоединиться к системе (т.е. появляется новый клиент), доверенная сторона выбирает для него новый открытый ключ, который представляет собой вектор (столбец) I размера к. В качестве доверенной стороны мы будем использовать сервер хранения данных клиент-серверной архитектуры. Вопрос аутентификации на этом сервере будет рассмотрен ниже.
Далее доверенная сторона вычисляет закрытый ключ g = Б * I.
Затем открытый и закрытый ключ сообщаются участнику по надёжному каналу без возможности прослушивания.
Если клиент и сервер хотят установить между собой секретный канал, они посылают друг другу по открытому каналу свои открытые ключи. Далее каждый из них умножает свой закрытый ключ на открытый ключ другой стороны.
- (д'АТпУ - {РдОТвУ - 1*ВША SB = (у'в1лУ = (РВШЛ)* = 1*ЛШВ sa — SB
В результате у них получится одно и тоже число (это следует из симметричности матрицы D, которое и будет использоваться как общий сеансовый ключ). Далее - сеансовый ключ будет использован для шифрования на стороне сервера и расшифровки на стороне клиента. Другими словами, одним из участников всегда будет сервер хранения данных, а другим - клиент.
Надёжность схемы напрямую зависит от размера секретной матрицы, используемой в схеме. Для восстановления секретной матрицы (точнее, любой выполняющей аналогичную функцию) необходимо иметь число ключей, равное количеству строк матрицы.
В качестве алгоритма шифрования выберем реализацию ЛБ8-СБС с длиной ключа 256 бит. [2] Уязвимым местом этого алгоритма является обязательность наличия секретного канала передачи для передачи открытого и закрытого ключа. Рассмотрим как можно решить этот вопрос. Серверная часть.
Рассмотрим несколько симметричных протоколов распределения ключей.
1. Лягушка с открытым ртом.
Протокол "Лягушка с открытым ртом" (Wide-Mouth Frog англ.), оригинальная статья Wide-Mouth Frog - простейший протокол управления ключами. Он позволяет двум абонентам установить общий сессионный ключ для защищенного общения между собой.[1] В протоколе принимает участие доверенный центр.
Итак, Алиса хочет установить сессионный ключ с Бобом. Она начинает, формируя:
• K - случайный сеансовый ключ
• TA - метку времени
и отправляет Тренту (доверенному центру), добавив своё имя:
M0 = A, EA (TA, B, K)
Трент, используя общий с Алисой секретный ключ, расшифровывает сообщение и проверяет правильность метки времени TA и идентификатора Боба. Если все хорошо, он формирует:
ТВ - новую метку времени (которая может отличаться от ТА) и отправляет Бобу
М1 = ЕВ (ТВ, А, К)
Боб получает сообщение, расшифровывает его общим с Трентом ключом и проверяет метку времени ТА и идентификатор Алисы. Если сообщение прошло проверку, то теперь Боб имеет общий с Алисой ключ. Протокол является довольно тривиальным и имеет крипто-неустойчивые точки [12].
2. Протокол Нидхема-Шрёдера
Данный протокол является примером протокола, не зависящего от меток времени и при этом обеспечивающего выработку и подтверждение ключа.
Ситуация перед началом работы протокола:
3 действующих лица: клиенты Алиса и Боб, которые хотят получить ключ для общения между собой, Трент - доверенный центр.
У Алисы и Боба есть секретные ключи ЕА и ЕВ соответственно для общения с Трентом.
Алиса выбирает число КА, Боб выбирает число КВ.
Итак, Алиса запускает протокол, формирует сообщение, состоящее из своего и Боба идентификаторов, а так же выбранного числа NA и отправляет его Тренту.
М0 = А, В, КА.
Получив сообщение от Алисы, Трент формирует сообщение, состоящее из двух частей. В первую часть он кладет ЫА. идентификатор Боба, а
также новый ключ K, который и хотят получить Алиса и Боб. Вторая часть сообщения так же содержит новый ключ K и еще идентификатор Алисы, но при этом она зашифрована секретным ключом Трента и Боба EB. Все сообщение шифруется секретным ключом Алисы и Трента EA. и отправляется Алисе.
M1 = EA (NA, B, K, EB (K, A))
Алиса расшифровывает сообщение. Найдя в сообщении NA, она убеждается, что поговорила с Трентом. Вторую часть, зашифрованную EB она прочитать совершенно не способна, пересылает её Бобу.
M2 = EB (K, A)
Боб получает и расшифровывает сообщение, достает оттуда новый ключ K и формирует сообщение для Алисы, в котором сообщает ей своё число NB, шифрованное новым ключом.
M3 = EK (NB)
Алиса получает сообщение, достает оттуда NB, меняет его и отправляет обратно Бобу.
M4 = EK (NB - 1)
Алиса и Боб владеют общим ключом K. [13]
3. Протокол Kerberos
Протокол Kerberos - это распределенная система аутентификации, которая позволяет клиенту доказать свою личность серверу без отправления данных по сети. Kerberos при необходимости обеспечивает целостность и конфиденциальность данных, передаваемых между клиентом и сервером.
Рис. 3. Схема работы протокола Kerberos 9
Перед началом работы протокола необходимо определить 3 действующих лица: Алиса - клиент, Боб - сервер, которому Алиса хочет доказать свою подлинность, Трент - доверенный центр.
У Алисы и Боба есть секретные ключи EA и EB соответственно для общения с Трентом.
Алиса выбирает число NA, а так же устанавливает метку времени TA по своим часам. t - период валидности (lifetime), выбираемый Трентом.
Затем Алиса, запуская протокол, в открытом виде передает Тренту свой идентификатор, идентификатор Боба и NA.
МО = А, В, КА
Трент, получив сообщение от Алисы, генерирует ключ К для дальнейшего общения Алисы и Боба и передает обратно Алисе сообщение из двух частей: первая часть зашифрована секретным ключом Алисы и содержит К, NA, период валидности t и идентификатор Боба; вторая часть неизвестна
9 https://ш.wikipedia.org/wLki/Протокол распределения ключей
Алисе - она зашифрована секретным ключом Боба, и в ней содержится К, t и идентификатор Алисы.
М1 = БЛ (К, МЛ, ^ Б) , ББ (К, Л, г)
Алиса расшифровывает первую часть принятого от Трента сообщения, и получив ключ К, создает новый пакет для отправки Бобу, в который входят идентификатор Алисы, t и метка времени ТА. После этого Алиса отправляет Бобу сообщение из двух частей: первая часть - это та, что пришла от Трента, а вторая - созданная Алисой.
М2 = ББ (К, Л, ^ БК(Л, ТА, г)
Боб принимает сообщение. Расшифровав первую часть, он достает новый ключ К, а затем, используя его, расшифровывает вторую часть. Чтобы подтвердить Алисе, что он знает новый ключ К, Боб отправляет ей сообщение с меткой времени, зашифрованное новым ключом К.
М3 = БК (ТЛ)
Алиса удостоверяется, что Боб - это Боб. Здесь применимы следующие рассуждения: Боб мог расшифровать сообщение от Алисы с меткой времени, только если он знал ключ К. А ключ К он мог узнать, только если знает ЕВ. А так как это секретный ключ Боба и Трента, то приславший сообщение Алисе - Боб.
Далее, при использовании схемы Блома открытый и закрытый ключи передаются с использованием ключа К. [14]
4. Протокол Отвея-Рииса
Протокол Отвея-Рииса - протокол на симметричных ключах, позволяющий распределять ключи, не используя метки времени.
Перед началом работы протокола у нас есть:
• Доверенный центр Трент
• 2 пользователя: Алиса и Боб, которые получили ЕА и ЕВ
• Алиса выбирает числа N и NA, Боб выбирает КВ.
Алиса формирует сообщение для Боба, в котором открытым текстом передает К, А, В, а также те же самые К, А, В с КА, зашифрованные общим с Трентом ключом ЕА.
М0 = М Л, Б, БЛ^Л, М Л, Б)
Боб получает сообщение, вторая часть которого для него нерасшифровываемая, добавляет в него еще одну строчку, которую шифрует ключом ЕВ и отправляет Тренту.
М1 = М Л, Б, БЛ(МЛ, М Л, Б), ББ(Ш, М Л,
Б)
Трент, зная оба ключа, может расшифровать сообщения Алисы и Боба. Теперь его цель - подтвердить, что он - Трент и сформировать ключ К для дальнейшего общения Алисы и Боба.
Трент генерирует ключ К и посылает Бобу сообщение.
М3 = БЛ (МЛ, К), ББ (МБ, К)
Первую часть, зашифрованную ключом Алисы, Боб расшифровать не может, а вторую часть он расшифровывает и, считав, КВ, удостоверяется, что сообщение пришло от Трента. Затем
принимает сгенерированный ключ K. Теперь Боб готов к общению с Алисой, осталось только доставить ей ключ. Боб отправляет Алисе первую часть сообщения от Трента.
M4 = EA (NA, K)
Алиса принимает сообщение, удостоверяется, что оно от Трента (NA), и считывает ключ K.
Алиса и Боб готовы к общению.
В результате получаем:
• Боб уверен, что поговорил с Трентом: Боб отправил ему число NB, шифрованное секретным ключом EB, и получил обратно другое сообщение, содержащее то же самое число и шифрованное тем же самым ключом.
• Алиса в свою очередь тоже уверена, что Боб поговорил с Трентом, потому что она послала своё число NA, шифрованное ключом EA, и получила обратно другое сообщение, но при этом тоже содержащим NA и шифрованное EA.
• У Алисы и Боба появился общий ключ K.
Проблема заключается в том, что Алиса никак
не может быть уверена, что Боб - это Боб. Она лишь уверена, что общается с неким лицом, которое может ходить к Тренту. Чтобы решить эту проблему на 4 шаге Боб может отправить Алисе не только EA (NA, K), но еще и, например, EK (NA, NB), доказывая тем самым, что он знает ключ K. А Алиса в свою очередь может ответить Бобу EK (NB), тоже доказывая, что знает ключ K. [15]
Протокол Нидхема-Шрёдера на симметричных ключах является основой для многих протоколов распространения ключей, использующих доверенный центр, в том числе для Kerberos и Otway-Rees.
Из всех рассмотренных протоколов Kerberos является самым рациональным для нашей системы, поэтому для аутентификации на сервере (доверенной стороне) рациональнее всего использовать Kerberos. Однако существуют модификации метода Kerberos, один из которых - детерминированный алгоритм HAKDP10. [16]
Отметим, что шифрование обеспечивает конфиденциальность данных на сервере. Даже если злоумышленник имеет доступ к зашифрованным данным, он не сможет увидеть их содержание без расшифровки.
Все файлы кросс-платформенного приложения для каждого конкретного проекта хранятся в своей директории на сервере в зашифрованном виде.
Нативная часть. Применение шифрования и расшифровки во время загрузки контента.
Для лучшей читаемости программного кода и консолидации всех действий, происходящих с загружаемыми данными приложения, вызов функций шифрования и расшифровки более не зашифрованных файлов происходит в классе, в котором также реализована загрузка данных с сервера разработчика на устройство.
Такая реализация обусловлена также безопасностью и производительностью: в реализации нет пересылок между классами (т.е. вызовов функций
10 Hashed Key Distribution Patterns
из разных классов). Шифрование данных, как и расшифровка, происходит в переменную, т.е. в оперативную память. Потом следует запись зашифрованного файла в память устройства (в случае шифрования) или же использование данных с последующим их удалением (в случае расшифровки).
До загрузки контента формируется список ссылок зашифрованных файлов (т.е. их адреса в памяти устройства) на основе данных, присланных после отработки менеджера синхронизации на сервере разработчика. Текущий список ссылок на зашифрованные файлы хранится в стандартном инструменте «NSUserDefaults».
Для начала нужно проверить наличие изменений в новом списке зашифрованных файлов относительно старого списка.
Сформированный новый список ссылок зашифрованных файлов сравнивается с текущим списком. При наличии различий с файлами на сервере загружается зашифрованный файл. Стоит отметить, что сначала с сервера файл загружается в оперативную память, и лишь потом сохраняется на флэш-носителе. С оперативной памяти злоумышленнику практически невозможно считать данные. Далее замещаем старый список зашифрованных файлов в «NSUserDefaults» новым.
После каждого запуска приложения файлы помещаются в оперативную память и расшифровываются.
Нативная часть. Механизмы шифрования и расшифровки.
Шифрование и расшифровка будут реализованы с использованием библиотеки «CryptoCommon».
Выбранный алгоритм - AES-256, т.е. алгоритм AES с длиной ключа 256 бит. [10].
Можно сделать алгоритм более гибким, если использовать вместо «жестко зашитых» в код чисел переменные шифрования, которые время от времени будут меняться.
Заключение
В данной работе удалось рассмотреть и реализовать масштабируемую систему для многопользовательского использования системы умный дом, а также найти приемлемый вариант для обеспечения конфиденциальности данных как на стороне клиента, так и на стороне сервера.
СПИСОК ЛИТЕРАТУРЫ:
1. Даниил Мигачев «Konzeption und Realisierung eines WYSIWYG-Systems für den plattformübergreifenden Online-Entwurf von Apps für Smart-phones und Tablet-Computer am Beispiel der Plattformen iOS und Android», Технический Университет Ильменау, 2013
2. Дамир Сабирзянов «Разработка и исследование системы онлайн-проектирования крос-сплатформенных приложений для мобильных устройств с безопасным управлением платным контентом», НИУ МЭИ, 2015
3. VMware, Inc. "VMware vSphere 6 Fault Tolerance Architecture and Performance", 2016 https://www.vmware.com/files/pdf/techpa-per/VMware-vSphere6-FT-arch-perf.pdf
4. VMware, Inc. "Performance Best Practices for VMware vSphere 6.0.", 2015 http://www.vmware.com/files/pdf/techpaper/VMware-PerfBest-Practices-vSphere6-0.pdf
5. Dominic Giles "Swingbench.", 2015 http ://dominicgiles.com/swingbench. html
6. Transaction Processing Performance Council "TPC-E", 2015 http://www.tpc.org/tpce/
7. Mohan Potheri, G. Blair Fritz, and Puneet Gupta "VMware vCenter Server 6.0 Availability Guide.", 2015 http://www.vmware.com/files/pdf/techpaper/VMware-vCenter-Server6-Availability-Guide.pdf
8. Mike Stunes and Ravi Soundararajan "vCenter Server 6.0 Performance and Best Practices.", 2015 https://communities.vmware.com/docs/DOC-29203
9. VMware, Inc. "vSphere Availability.", 2015 http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-availability-guide.pdf
10. Официальный сайт для разработчиков iOS https://developer.apple.com/
11. Blom R. An optimal class of symmetric key generation systems // Advances in Cryptology -EUROCRYPT '84: A Workshop on the Theory and Application of Cryptographic Techniques Paris, France, April 9-11, 1984. Proceedings of / T. Beth, N. Cot, I. Ingemarsson - Springer-Verlag New York, 1985. - P. 335-338. - (Lecture Notes in Computer Science; Vol. 209) - ISBN 978-3-540-16076-2 - ISSN 0302-9743
12. Pablo Giambiagi. Secrecy for Mobile Implementations of Security Protocols. - 2001. - ISSN 14035286.
13. An Analysis of the Needham-Schroeder Public-Key Protocol with MGS - Olivier Michel - University of Paris-Est - 2009
14. B. Clifford Neuman and Theodore Ts'o "Kerberos: An Authentication Service for Computer Networks", IEEE Communications Magazine, 1994
15. Сергей Николенко, Криптография CS-Club, 2009
16. Щуров Игорь «Методы и программные средства предварительного распределения ключей», НИУ МЭИ, 2008
