Стандарты архитектуры для Internet of Things
На днях мне понадобилась информация о том, какая архитектура IoT является типовой (референсной). Такую информацию оперативно найти не удалось ни на «хабре», ни на других ресурсах. Оказалось, что первые попытки разработать стандарты в этом направлении были предприняты всего два года назад, и работы все еще находятся в стадии «проект». В этой статье вы найдете «срез» состояния разработки стандартов IEEE & ISO/IEC по описанию референсной архитектуры IoT (IoT Reference Architecture).
Источник
Зачем нужны стандарты?
Начнем с холиварной неоднозначной темы стандартизации.
Мировой технический прогресс движется в следующем направлении: когда технология становится достаточно зрелой, наступает пора ее стандартизации, что является шагом к так называемым «открытым системам» с типовыми компонентами и интерфейсами. Если рассматривать известный Gartner Hype Cycle, то стандартизация может выполняться с упреждением, задолго до готовности технологии к массовому внедрению.
Весь мир технических (и не только) изделий определяется стандартами, а без этого всех нас накрыл бы хаос.
Что касается IoT, то использование стандартов является еще и важной платформой при работе с крупными государственными и корпоративными заказчиками, в том числе и в области приложений, важных для безопасности (safety critical, security critical, mission critical, etc.).
«Прославляя» стандартизацию нельзя не сказать о «темной стороне силы», к которой, на мой взгляд, относится:
— существование избыточного количества стандартов, отсутствие четкой системы, наличие разных организаций, занимающихся стандартизацией в одной и той же сфере;
— неполное и неравномерное покрытие объектов стандартизации;
— «война стандартов», т.е. лоббирование интересов отдельных фирм в ущерб решению общих проблем стандартизации;
— регламентация в основном только наиболее простых объектов и массовых процессов;
— бюрократизированная процедура и долгий срок разработки стандартов (в среднем, три-пять лет), что приводит к их консерватизму и отставанию от практических потребностей.
Тем не менее, мир стандартов существует, и нам в нем жить.
IEEE vs ISO/IEC
Те, кто сталкивался с миром стандартов, знает, что в области IT этот мир биполярен, поскольку есть две общепризнанных организации: IEEE (Institute of Electrical and Electronics Engineers) и IEC (International Electrotechnical Commission – Международная электротехническая комиссия, МЭК).
В разных областях стандартизации взаимное влияние IEEE и IEC различно, но «в среднем» (есть исключения) Америка любит IEEE, а Европа – IEC.
По некоторым направлениям IEC сотрудничает с ISO, например, интересующей нас областью IoT занимается ISO/IEC JTC1 (Joint Technical Committee in International and Communication Technology).
Существуют, конечно, и другие международные организации по стандартизации, например, CENELEC, разрабатывающий EN (European Normative), ITU-T (International Telecommunication Union Telecommunication Standardization Sector), американский NIST (National Institute of Standards and Technology) и многие другие.
Чем занимается IEEE в области IoT
IoT попал в сферу интересов IEEE и ISO/IEC JTC1 практически одновременно. В июле 2014 года была создана рабочая группа IEEE P2413 и проведен первый митинг по разработке «Standard for an Architectural Framework for the Internet of Things (IoT)». В состав рабочей группы вошли представители Cisco, Emerson, Hitachi, Honeywell, Huawei, Intel, Kaspersky Lab, Rockwell Automation, Schneider Electric, Siemens, STMicroelectronics, Toshiba, Yokogawa и другие. Microsoft и Google замечены не были.
В 2014-2016 гг. митинги проводятся 4 раза в год. Подробной информации о состоянии разработки на сайте группы не приводится, есть только высокоуровневые презентации.
Интересным фактом является внимательное отношение рабочей группы IEEE P2413 к вопросам обеспечения надежности и безопасности (Dependability & Security).
Источник
Следовательно, IoT планируется к применению в области уже упомянутых систем, важных для безопасности (safety critical, security critical, mission critical, etc.). Это подтверждается также участием в разработке стандарта «монстров» промышленной автоматизации.
Чем занимается ISO/IEC JTC1 в области IoT
Решение по созданию рабочей группы “Working Group on Internet of Things (WG10)” было принято на пленарном митинге ISO/IEC JTC1 в 2014 году. В январе 2015 года состоялся первый митинг WG10, на котором было принято решение по разработке стандарта ISO/IEC 30141 “Internet of Things Reference Architecture (IoT-RA)”, с тех пор подобные митинги проводятся трижды в год. На странице ISO/IEC JTC1 содержится исходный отчет по состоянию дел в области IoT (Study Report on IoT Reference Architectures/Frameworks) и некоторые результаты работы “WG10 on IoT”. Остановимся на упомянутом отчете
Что удается понять из скудных фактов?
Во-первых, многие положения будущего стандарта IoT-RA заимствуются из смежных уже стандартизированных областей, таких как:
— домашние электронные системы (Home Electronic Systems, описанные в стандартах серии ISO/IEC 14543);
— MPEG-V архитектура для управления медиа (Media context and control, описанные в стандартах серии ISO/IEC 23005);
— Sensor Network Reference Architecture (SNRA, описанная в стандартах серии ISO/IEC 29182).
По поводу последней архитектуры следует отметить, что именно она явилась стандартизованным прообразом архитектуры IoT, предложив четыре типовых уровня: device, network, service, and application.
Во-вторых, описание архитектуры для IoT будет адаптировано из уже существующих с 2012 стандартов ITU-T ( (International Telecommunication Union Telecommunication Standardization Sector), в частности ITU-T Y.2060 «Overview of the Internet of things».
Соответствующие уровни архитектуры и связь между ними (так называемая «экосистема») приведены ниже.
Источник
В-третьих, разрабатываемые требования к компонентам IoT будут структурированы согласно таксономии, предложенной в ITU-T Y.2066 «Common requirements of the Internet of things», которая включает в себя следующие группы требований:
— Implementation and operability requirements;
— Non-functional requirements
— Application support requirements;
— Service requirements;
— Communication requirements;
— Device requirements;
— Data management requirements;
— Security and privacy protection requirements.
Заключение
В ближайшее время предполагается выпуск стандартов, описывающих референсную архитектуру (Reference Architecture) для IoT. Этот факт еще более приблизит IoT к «открытым системам» с типовыми совместимыми компонентами и интерфейсами.
С 2014 года разработка таких стандартов ведется параллельно IEEE Working Group P2413 и ISO/IEC “Working Group on Internet of Things (WG10)”. Наличие двух стандартов добавит головной боли поставщикам компонентов и системным интеграторам.
Открытой информации об этих разработках доступно немного. Очевидно, что стандартизоваться будут уже существующие наработки, в частности, от ITU-T, согласно которым референсная архитектура включает четыре типовых уровня: device layer, network layer, service layer, and application layer.
Стандарт IEEE 1609.2: защита информации в сетях V2X
Вступление
В настоящее время интеллектуальные транспортные системы (англ.: Intelligent Transport Systems, ITS) активно развиваются. Их функционирование невозможно без создания телекоммуникационных систем, позволяющих транспортным средствам обмениваться информацией со внешними устройствами (англ. Vehicle-to-Everything, V2X). Транспортные средства накапливают информацию посредством различных сенсоров, радаров, лидаров и камер. Для обеспечения автономного вождения и передвижения машин в плотном строю (так называемый platooning) необходимо обеспечивать обмен этой информацией между различными транспортными средствами. Обмен информацией может также осуществляться с элементами дорожной инфраструктуры, что позволяет обеспечивать большую безопасность движения посредством передачи объектами инфраструктуры предупреждающих сообщений. Кроме того, существует большое число других приложений, которые обеспечивают удобство вождения и безопасность, а также уменьшают число пробок и предоставляют различные развлекательные сервисы. Разнообразные приложения порождают различные требования на задержки, надёжность и скорость беспроводной передачи данных. Однако кроме требований на производительность сети во многих случаях важно, чтобы передаваемые данные были защищены. В этой статье я хотел бы дать краткий обзор основных механизмов стандарта IEEE 1609.2, который описывает методы защиты информации в транспортных сетях, построенных по технологии Wi-Fi.
DSRC телекоммуникации
На данный момент одним из самых распространённых способов коммуникации в V2X является выделенная связь на короткие расстояния (англ.: Dedicated Short Range Communications, DSRC), для обеспечения которой используется набор стандартов беспроводной связи в транспортной среде: стандарты IEEE 1609 и IEEE 802.11p. Комитетом IEEE был выпущен специальный гайд, в котором они детально описаны. Заинтересовавшиеся могут найти его по ссылке.
Набор стандартов для DSRC
Стандарт IEEE 802.11p описывает работу физического и основной части MAC уровня модели OSI в диапазоне частот 5,9 ГГц (и 60 ГГц опционально). Как видно, этот диапазон частот отличается от частот, на которых работает «классический Wi-Fi»: 2,4 ГГц и 5 ГГц. «Классические» частоты являются нелицензируемыми, и это приводит к их зашумлённости передачами устройств, работающих по другим стандартам, что крайне нежелательно для транспортных сетей, которые сделаны в частности для поддержки приложений, обеспечивающих безопасность дорожного движения. В свою очередь, диапазон частот в 5,9 ГГц является бесплатным и лицензированным в том плане, что в этом диапазоне могут работать только устройства, использующие определённый набор стандартов. Стандарт IEEE 1609.4 описывает многоканальные методы доступа к среде, которые позволяют поочерёдно передавать сразу в двух каналах, например, канале для передачи данных и канале для контрольных сообщений. IEEE 1609.3 описывает WSMP (Wave Short Message Protocol), который является альтернативой протоколам TCP/UDP и IP на транспортном и сетевом уровне соответственно. Также стандарт IEEE 1609.3 выполняет некоторые другие функции, например, выбор канала для передачи данных. Стандарт IEEE 1609.2 описывает методы обеспечения безопасной передачи данных и именно ему я хотел бы уделить внимание в данной статье.
Основные положения IEEE 1609.2
Стандарт IEEE 1609.2 основывается на асимметричной криптографии и в частности описывает методы шифрования сообщений и методы создания цифровой подписи. Единицей данных для этого стандарта является так называемый SPDU (Secured Protocol Data Unit), который состоит из защищаемых данных и специальных полей для обеспечения защиты информации. IEEE 1609.2 защищает только данные, являющиеся полезной нагрузкой для протокола транспортного уровня. То есть заголовки транспортного, сетевого, LLC, MAC, а тем более физического уровней стандарт IEEE 1609.2 не защищает. Пример пакета, который иллюстрирует местоположение защищаемых данных, представлен на рисунке ниже. Базовая структура SPDU стандарта IEEE 1609.2 представлена здесь под буквой D:
Местоположение данных, защищаемых стандартом IEEE 1609.2
Инфраструктура открытых ключей в сетях V2X
Сразу оговорюсь, что далее я буду говорить только о транспортных средствах, поддерживающих процедуру создания и проверки электронной подписи по стандарту IEEE 1609.2, так как на данный момент этот стандарт поддерживают не все транспортные средства. Сперва я хотел бы отметить, что у каждого транспортного средства имеется 2 типа секретных ключей: долгосрочный и краткосрочный. При этом краткосрочных ключей может быть несколько. Долгосрочный секретный ключ выдаётся при производстве транспортного средства по договорённости производителя и властей того региона, где ключ выдавался. Выдаётся он вместе с соответствующим открытым ключом, некоторой технической и идентификационной информацией о транспортном средстве и сертификатом открытого ключа (сертификат содержит открытый ключ и некоторую информацию о владельце соответствующего секретного ключа). Долгосрочный секретный ключ известен только устройству, которому он выдан, и хранится в так называемом аппаратном защитном модуле транспортного средства, из которого секретный ключ не так-то просто достать. Открытый ключ, его сертификат и некоторая идентификационная информация устройства хранятся в сертификационном центре (англ.: Certification Authority, CA), из которого другие устройства могут получить информацию о сертификате и открытом ключе зарегистрированного устройства. Стоит отметить, что во время производства нового транспортного средства оно получает также 2 открытых ключа сертификационного центра: один для проверки электронной подписи сообщений, переданных от CA, а второй на случай, если злоумышленнику удастся узнать первый секретный ключ CA. Если злоумышленнику удастся узнать этот ключ, то CA сможет сменить секретный и открытый ключ, разослав новый открытый ключ всем устройствам и подписав сообщение вторым секретным ключом. Стоит отметить, что время жизни долгосрочного секретного ключа должно быть равно времени жизни транспортного средства или по крайней мере составлять большую часть его жизни.
Теперь я хотел бы пояснить, зачем нужны краткосрочные закрытые ключи. Как я уже говорил, долгосрочный ключ рассчитан на длительное использование, поэтому хотелось бы использовать его нечасто, чтобы у злоумышленника было меньше шансов взломать этот ключ. Для этого используются секретные краткосрочные ключи. Транспортное средство генерирует несколько пар краткосрочных секретных и открытых ключей и отправляет CA сообщение с сертификатами открытых ключей. Сообщение подписывается долгосрочным закрытым ключом. После того как CA получил сертификаты краткосрочных открытых ключей от транспортного средства, он сохраняет их у себя в памяти, и далее эти сертификаты могут получить другие устройства. После отправки сертификатов краткосрочных открытых ключей CA наше устройство начинает подписывать сообщения краткосрочными секретными ключами. Периодически оно меняет свои секретные и соответствующие им открытые ключи. При этом уже использованные закрытые и соответствующие им открытые ключи стираются из памяти и больше не используются. Поэтому устройству периодически нужно генерировать новые пары открытых и закрытых ключей и рассылать соответствующие сертификаты открытых ключей на CA.
Я довольно много говорил об обмене информацией между CA и нашим устройством, но не сказал, как он осуществляется. Для пояснения я приведу следующую картинку:
Обмен информацией между сертификационным центром и транспортным средством
Транспортные средства обмениваются информацией с CA посредством придорожной инфраструктуры (англ.: Road-Side Unit, RSU). Ранее я писал, что стандарт IEEE 1609.2 защищает только полезную нагрузку транспортного уровня, но не заголовки транспортного уровня и нижележащих уровней модели OSI, что позволяет RSU и другим устройствам, выполняющим роль маршрутизатора, передавать сообщения от транспортного средства к CA и обратно, даже не имея возможности узнать содержимое сообщения (если оно зашифровано, например). То есть обмен информацией между автомобилями и CA осуществляется через RSU.
Теперь я хотел бы описать обмен информацией между транспортными средствами. При отправке радиомодулем автомобиля широковещательного сообщения сущность, отвечающая за безопасность передачи данных, должна прицепить к сообщению электронную подпись и сертификат открытого ключа для проверки этой электронной подписи. При приёме сообщения другое транспортное средство должно сперва проверить, что полученный сертификат зарегистрирован и отмечен как действительный в CA, а затем использовать открытый ключ из сертификата для проверки электронной подписи. Для проверки действительности сертификата при первом его получении нужно направлять запрос в CA. Дальнейшая проверка действительности сертификата может осуществляться посредством его временного сохранения в буфере транспортного средства (то есть устройство на время запоминает, что сертификат действительный).
Стоит отдельно отметить, что CA может не только регистрировать сертификаты, но и отзывать их по истечении срока жизни или по каким-то иным причинам. Так что если злоумышленник захочет сбить систему дорожной безопасности транспортного средства с толку, но сертификат открытого ключа злоумышленника не будет зарегистрирован в CA, то у него ничего не выйдет. Больше информации об инфраструктуре открытых ключей в транспортных сетях можно узнать, например, из статьи №1 или статьи №2, на которых основывается мой рассказ про инфрастурктуру открытых ключей в V2X.
Параметры алгоритма создания электронной подписи и операции на эллиптических кривых
Для создания и проверки электронной подписи в стандарте IEEE 1609.2 используется алгоритм цифровой подписи на основе эллиптических кривых (англ.: Elliptic Curve Digital Signature Algorithm, ECDSA). Здесь я дам его краткое описание. Больше информации об этом алгоритме и криптографии на эллиптических кривых можно найти, например, в этой статье на хабре или в этой научной статье. Алгоритм ECDSA позволяет создать электронную подпись сообщения с помощью закрытого ключа, а затем проверить её с помощью открытого. То есть отправитель должен знать секретный ключ, а все принимающие устройства должны знать открытый ключ. Однако кроме знания одного из двух ключей устройства также должны знать параметры алгоритма. Первыми двумя параметрами алгоритма являются коэффициенты используемой эллиптической кривой. В алгоритме ECDSA используются эллиптические кривые форме Вейерштрасса, под которыми в криптографии подразумевается множество точек (x, y) следующего вида (далее под эллиптической кривой буду подразумевать именно это множество точек):
Операция сложения на эллиптической кривой в форме Вейерштрасса
Стоит отметить, что на представленном выше рисунке изображена не только сама эллиптическая кривая, но и геометрический смысл операции сложения. Чтобы найти сумму двух разных точек эллиптической кривой, не симметричных относительно оси симметрии этой кривой (на рисунке точки P и Q), необходимо провести через них прямую и найти её точку пересечения с кривой (точка пересечения существует в силу условий на параметры a и b). Тогда суммой точек эллиптической кривой называется точка, обратная к указанной выше точке пересечения. Для нахождения результата сложения некоторой точки эллиптической кривой с самой собой (на рисунке P + P) необходимо провести касательную к этой точке, найти пересечение касательной с эллиптической кривой (пересечения опять-таки существует в силу условий на a и b) и взять точку, обратную к пересечению. Для реализации алгоритма ECDSA на компьютере указанные выше операции сложения необходимо записать в аналитическом виде. Это можно сделать, используя методы аналитической геометрии. Здесь я напишу лишь конечные формулы для сложения точек в полях Галуа. Будьте внимательны! Я не зря выделил последнюю фразу жирным шрифтом. Под делением в полях Галуа я подразумеваю взятие обратного элемента: элемент x поля Галуа называется обратным к элементу y поля Галуа если:
Для вычисления обратного элемента обычно используется расширенный алгоритм Евклида. С учётом замечания про взятие обратного элемента формула для сложения разных точек 
и 
, не симметричных относительно оси симметрии эллиптической кривой, имеет следующий вид (все. операции по модулю p):
В свою очередь, формула для сложения точки с самой собой имеет вид:
Здесь под N подразумевается порядок всей эллиптической кривой, то есть число элементов в ней. В силу так называемой теоремы Лагранжа, n всегда является делителем числа N, так что кофактор определён корректно.
В стандарте IEEE 1609.2 возможно использование лишь определённого набора параметров, для которых нет общеизвестных методов быстрого взлома алгоритма ECDSA (о том, как его можно взломать я расскажу чуть позже). Используемый набор параметров для передающего устройства можно получить вместе с его открытым ключом от CA. Примеры этих наборов можно найти, например, в этой статье в разделе ECDSA.
Алгоритм ECDSA
Теперь перейду к описанию самого алгоритма ECDSA. Этот алгоритм работает не с самим передаваемым сообщением, а с его хэшем. Хэш-функция позволяет преобразовать сообщение произвольной длины в последовательность бит фиксированной длины. При этом данное преобразование выполняется таким образом, что восстановление всех возможных исходных значений сообщения по заданному значению хэша является вычислительно сложной задачей, тогда как вычисление самой хэш-функции можно произвести быстро. Полученную после действия хэш-функции последовательность бит можно интерпретировать как десятичное число в двоичной форме записи. Именно это число используется алгоритмом ECDSA. Если это число получается большим, чем n, то хэш сообщения необходимо урезать. Стандарт IEEE 1609.2 определяет всего 2 допустимые хэш-функции: SHA-256 и SHA-384.
Для вычисления значения открытого ключа по закрытому ключу и генерирующей точке существуют эффективные алгоритмы, позволяющие вычислить открытый ключ быстро. А вот обратная задача, то есть вычисление закрытого ключа по известной генерирующей точке и открытому ключу, считается сложной. Эта задача называется задачей дискретного логарифмирования, и именно на сложности её решения базируется криптографическая стойкость алгоритма ECDSA. Для того чтобы эта задача была по-настоящему сложной и не решалась за приемлемое время на обычных компьютерах, необходимо выбирать большие значения p и n. Например, для одного из специфицируемых стандартом IEEE 1609.2 набора параметров алгоритма ECDSA под названием NIST P-224 параметры p и n имеют следующие значения:
Процедура проверки электронной подписи выглядит следующим образом:
Проверка корректности алгоритма
Теперь проверим корректность этого алгоритма (нестрого). Сперва перепишем P в несколько другом виде, учитывая что 
:
Учитывая определение 
и 
, получим:
Ранее было дано следующее определение:
Умножив обе части уравнения на k и поделив на s, мы получим, что:
Из написанной выше проверки корректности следует, что посредством этого алгоритма значение r было вычислено двумя способами: на передающем устройстве с помощью закрытого ключа и на принимающем с помощью открытого. Затем 2 значения r были сопоставлены друг с другом.
Заключение
В данной статье были рассмотрены базовые принципы функционирования стандарта IEEE 1609.2, описывающего защиту информации в транспортных сетях, работающих по технологии Wi-Fi. Сперва был рассмотрен набор стандартов для беспроводной связи в транспортных сетях. Затем был сделан обзор методов распределения открытых и генерации секретных ключей в сетях V2X. Далее была описана арифметика криптографии на эллиптических кривых и алгоритм ECDSA, используемый для создания электронной подписи в стандарте IEEE 1609.2. В конце была проверена корректность алгоритма ECDSA.
