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


Разработка под встраиваемые применения всегда несла в себе определённые особенности, причём такие, что большинство «обычных» программистов даже не задумываются об этом, а понятие QA и процесс тестирования в многих случаях кардинально отличается от того, что принято понимать в общем случае.

Одна из любимых и периодически обсуждаемых тем в крупном IT-канале в Телеграм Embedded Group — «почему embedded разработчиков никто не понимает и так мало платят? (на фоне «обычных» программистов)» :)

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



Левое изображение взято из статьи Wikipedia про встраиваемые системы, это пример крупной сложной системы. Справа фото из обзора умного дома Redmond, здесь всё гораздо проще и компактнее, по сути всё устройство сделано на одном чипе с минимальной обвязкой. Важно, что оба устройства функционируют, как законченные устройства (одноплатному компьютеру всё же нужен корпус и какая-то периферия).

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

Ещё одной особенностью разработки под встраиваемые системы является то, что они практически всегда имеют гораздо меньше ресурсов, как по вычислительной мощности, так и памяти, каналу данных, а также потреблению. Большинство привычных многим технологий запустить на таких системах невозможно, даже ОС есть не везде. Необходимо вписаться в доступные ресурсы и часто значительно экономить. В том числе это сказывается и на безопасности — многие стандарты из «большого мира» не поддерживаются или поддерживаются с ограничениями.

C до сих пор является самым массовым языком разработки встраиваемых систем. У него есть ряд недостатков по работе с памятью, прямо влияющих на безопасность. Для их решения был разработан Rust, он набирает популярность (на первом месте любимых языков на StackOverflow уже несколько лет, обгоняя даже Python и Kotlin, особо популярные последнее время), но всё равно пока ещё далёк от лидера по применимости в embedded из-за поддерживаемых систем и библиотек. Более высокоуровневые языки являются редкостью для встраиваемых систем и скорее всего таковыми и останутся в ближайшее время.

Важной особенностью разработки встраиваемых системы является ограничение аппаратных возможностей платформой и SDK поставляемого производителем. Многие технологии реализовать своими силами с нуля для отдельного проекта просто невозможно или крайне затратно. Поэтому крайне важно, чтобы производитель чипов поддерживал современные технологии по безопасности. До недавнего времени этому уделяли на так много внимания. Например, если аппаратный AES появился достаточно давно почти у всех, то поддержку TLS/DTLS до сих пор многие не умеют. Встаёт вопрос, каким образом этого достичь. Недавно я писал про новый SDK на базе Zephyr от Nordic, который решает эту задачу за счёт интеграции с крупным проектом поддерживаемым Linux Foundation. Это один из подходов. Ниже рассмотрим другие.

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

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

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

Как правило крупные компании, производители облачных сервисов заботятся о безопасности своих сервисов по ряду причин:

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

Устройства же интернета вещей работают в прямо противоположном виде:

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

Для наглядности приведу сравнительную таблицу. Сразу оговорюсь, что:

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

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

Наиболее известны взломы встраиваемых систем за последнее время:

• ботнет Mirai в 2016 году, работающий в основном на видеокамерах. По разным оценкам количество заражённых устройств превышало 380 тысяч. Его наследник Satori в 2018 захватил уже 700 тысяч устройств, ориентируясь в первую очередь на майнеры криптовалюты.
• KRACK поразивший в 2017 году WPA2 Wi-Fi (практически все устройства с Wi-Fi за последние 15 лет) и его наследник Kr00k, с числом более миллиарда устройств в 2019 году.
• В 2018 году Bleedingbit поразил BLE-чипы Texas Instruments. Официально проблеме были подвержены только несколько моделей точек доступа, которые использовали семейства CC26xx, а сама проблема решалась в новой версии стека. Однако, в данном случае не учитывается, что данные чипы используются в гораздо большем числе устройств (второй в мире производитель BLE, 16% от 3.9 млрд за 2018 год).

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

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

ARM ещё в 2017 года рассказывал про безопасность встраиваемых систем на основе CryptoCell и Cortex-M33, однако серийные образцы чипов на M33 появились лишь в прошлом году. Представленная технология получила название Platform Security Architecture (PSA).


Суть идеи заключалась в том, чтобы разделить критичные части системы (ключи, права, прошивку) от потенциально подверженных взлому компонентов, как аппаратных, так и программных, для систем, где полная реализация TEE невозможна или затруднена. Технология ориентирована в первую очередь на Cortex-M, но совместима со всеми семействами Cortex-A/-R/-M.



В основном рассматривают 4 этапа защиты устройств интернета вещей. Рассмотрим их в последовательности по мере возникновения в процессе работы устройства.

Безопасная загрузка (Secure Boot)

• Проверяется, что прошивка является подлинной, не была изменена и не может быть понижена в версии (downgrade).

Безопасное обновление прошивки по воздуху (Secure FOTA)

• Могут быть загружены только аутентифицированные и проверенные обновления.
• Будущие угрозы безопасности могут быть устранены (сохранение контроля над обновлением в будущем)

Безопасные физические интерфейсы и API

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

Безопасный транспортный уровень

• Устройство может аутентифицировать и подписывать или шифровать сообщения с сервером
• Нет атак посредника (MITM) на пути между устройством и сервером

Для защиты устройства предлагается идентифицировать/верифицировать данные поступающие на каждом этапе. В основе концепции лежит идея корня доверия (Root-of-Trust, RoT). Суть заключается в том, что в устройстве зашивается некий идентификатор (ключ) и происходит аппаратная процедура проверки соответствия уникальности ключа текущей платформе и исполняемому коду. В дальнейшем все важные библиотеки используют RoT для собственной работы.


Как правило это происходит в 3 основных этапа:

1. Предоставление доверия: включение Root-of-Trust на этапе производства в структуру чипа
   Неизменяемый идентификатор чипа и аппаратный корень доверия обеспечивают базовую безопасность и уникальную идентификацию устройства.
2. Использование доверия: получение доверенных ключей
   Защищенные библиотеки позволяют создавать аппаратные криптографические функции и ключи, которые используются обычными функциями в дальнейшем
3. Гарантия доверия: ключи используются для защиты любой функции
   Гарантируется подлинность, целостность и конфиденциальность работы любой функции с использованием ключей и функций со 2 этапа.

Наиболее распространённым решением на рынке является TrustZone от ARM. Про его реализацию на Хабре написано достаточно много, так как сама технология была представлена достаточно давно. Наиболее наглядно на мой взгляд резюмировали в одной из последних публикаций.

В контексте данной статьи стоит отметить, что ранее TrustZone был привилегией высокопроизводительных процессоров семейства Cortex-A. А за прошедший год практически все производители беспроводных систем на кристалле выпустили решения на базе Cortex-M, наибольшей популярностью пользуется Cortex-M33.

Говоря про информационную безопасность стоит напомнить про систему общих критериев (Common Criteria), принятых как на международном уровне, так и качестве национального стандарта. Она позволяет определить уровень доверия Evaluation Assurance Level (EAL) от 1 до 7 (EAL1 — EAL7), более высокая цифра показывает более высокий уровень безопасности. Для понимания, уровень EAL4 или EAL4+ имеют большинство ОС Windows, LInux/Unix, EAL5 в осном имеют смарт-карты (банковские, транспортные, в том числе бесконтактные), EAL6 позволяет использовать решение в высокорисковых ситуациях, EAL7 в экстремально рисковых ситуациях, например, для однонаправленных сетей (диодов данных).

В апреле этого года Cortex-M33 и M35P были сертифицированы по уровню EAL6+. Это очень высокий уровень, позволяющий применять решения в высокорисковых ситуациях.

ARM TrustZone Cryptocell в новых Cortex-M33/M23 обеспечивает безопасное хранение ключей (в том числе с уникальным аппаратным идентификатором), проверку прошивок, как на этапе загрузки, так и обновления по воздуху, аппаратное ускорение шифрования AES, SHA, ChaCha, ECC, в том числе с DMA (как следствие все данные во Flash и RAM могут быть зашифрованы), генераторы случайных чисел (TRNG, PRNG).


Из интересного можно отметить, что CryptoCell позволяет иметь несколько корней доверия для различных задач (например, встраивать дополнительный RoT под заказчика, который хочет интегрировать массовое решение с рынка в свою закрытую IT систему, например, банк, не привязываясь к основному RoT от производителя), а также безопасную отладку (Secure Debug) с авторизацией прав.

300 серия CryptoCell ориентирована как раз на малопотребляющие устройства интернета вещей. Потребление новых M33 примерно на 20-40% ниже, чем M4, учитывая потери в энергопотреблении на работу TrustZone в 20% имеем такой же или более низкий уровень потребления, чем сейчас. Как следствие можно сказать, что аппаратная безопасность пришла в наиболее массовый бюджетный сегмент с Cortex-M33/M23 и в ближайшее время количество продуктов на базе их будет только увеличиваться.

В качестве TrustZone альтернативы можно назвать OpenTitan спонсируемый Google. Однако, он пока не распространён и ориентирован на другие применения, нежели конечные устройства интернета вещей.

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

Рассмотрим 5 этапов эволюции реализации Root-of-Trust в модулях сотовой связи uBlox, разработанной в сотрудничестве с Kudelski Group. Это интересно с точки зрения поставленной задачи, так как их решения значительно отличаются от подходов других компаний. Модули сотовой связи Nb-IoT/ LTE Cat-M относятся к переходным классам между 4 и 5 поколениям LTE и ориентированы на низкопотребляющие сети LPWAN. В большинстве случаев устройства должны работать годами без вмешательства человека. Современные решения позволяют работать 7-10 лет на одном элементе питания (батарейке). Средний срок службы устройства часто достигает 15 лет. За это время могут значительно измениться требования по безопасности, появиться новые угрозы. Устройства при этом должны работать стабильно без вмешательства человека весь срок службы. Соответственно необходимо защищать подобные устройства с учётом срока и характера их работы.


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

1 и 3 варианты признаны ненадёжными по мнению uBlox/Kudelski из-за программной реализации RoT и наиболее вероятного взлома. В том числе для случая вынесения корня доверия во внешний eSIM (eUICC), который обеспечивает защиту достаточную для банковских применений начального уровня EAL4 (ключи в eUICC невозможно прочитать или изменить, чтобы это не стало заметно извне). Однако такой подход несёт с собой недостатки и потенциальные уязвимости, возникающие из-за того, что общение с внешним компонентом можно перехватить и потенциально исказить, сложности взаимодействия на начальных этапах инициализации системы (проверка загрузчика), а также сложный механизм программирования из-за ограниченных ресурсов чипов в UICC. Кроме того внешний модуль можно заменить или удалить из системы (просто поменяв SIM карту) и тем самым оставив всю систему без корня доверия.

Поэтому дальнейший путь развития заключается в интеграцией корня доверия в защищённой области чипа. Этот подход соответствует компепции ARM TrustZone CryptoCell.

Вариант с реализацией Root-of-Trust в защищённой ОС является наиболее распространённым на рынке и обеспечивает достаточный для большинства задач уровень безопасности. Наиболее распространённое решение на рынке — ARM TrustZone (про него выше), но ещё без CryptoCell, хранящего ключи в защищённой области.

Наибольшей же защитой обладает решение с защитой интегрированной внутрь чипсета, к которому практически нет доступа извне. В текущем решении используется встроенный элемент безопасности (Secure Element), сертифицированный по уровню EAL5+. Это допускает сертификацию Common Criteria для всего устройства в целом, а также позволяет размещать функции SIM-карты и профили мобильного сетевого оператора (MNO) внутри устройства. Это соответствует современному уровню безопасности.

В разработке находится следующее поколение чипсета от uBlox, где Secure Element будет интегрирован в кремний самого модемного чипсета. Это еще больше уменьшает поверхность атаки и повышает безопасность до самого высокого уровня. Это будет реализовано через iUICC (Integrated Universal Integrated Circuit Card) — следующее поколение UICC, при котором весь код и SIM идентификатор будут располагаться внутри системы на кристалле, стандарт пока не завершён.

Выводы:

• Всё больше производителей электронных компонентов разрабатывают и выпускают устройства с учётом требований безопасности, начиная с самых ранних этапов разработки.
• Компании разработчики конечных устройств получают инструменты управления безопасностью, работающие прямо из коробки. Привлечение экспертов на этапе разработки инструментов позволяет избежать ошибок, а также значительно снизить стоимость решения в целом.
• Ценник на новые решения зачастую оказывается близок к текущим решениям, но даёт принципиально иной уровень защиты, что также значительно упрощает переход
• Рост числа устройств обеспечивающий новый уровень безопасности является лишь вопросом времени
• В новых решениях secure element UICC переносится внутрь кристалла чипа для повышения безопасности и затруднения атаки
• Современные решения позволяют получить уровни безопасности вплоть до EAL6+, достаточные для использования в высокорисковых ситуациях.
• В разработке находятся решения уровня EAL7, однако они используют технологии без окончательно утверждённого стандарта, поэтому срок доступности их рынке не определён.