Программное обеспечение для шифрования прошивки

Обновлено: 21.11.2024

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

Многое можно сделать и написать о безопасности обновлений встроенного ПО, но, возможно, самым важным моментом является подписание встроенного ПО. Другие меры безопасности бесполезны, если мы не можем проверить подлинность обновления прошивки!

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

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

Нравится прерывание? Подпишитесь, чтобы получать наши последние публикации прямо в ваш почтовый ящик.

Содержание

Подписание прошивки

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

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

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

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

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

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

Зачем подписывать наши прошивки

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

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

  • Заблокировать устройство или весь парк.
  • Слежение за конечными пользователями и нарушение их конфиденциальности и безопасности.
  • Стратегический сбой в критический момент

Это крайне нежелательные результаты, которые могут быть достигнуты в больших масштабах благодаря Интернету вещей. В 2020 году будет безрассудно обновлять встроенное ПО для наших систем без какой-либо формы аутентификации.

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

ECDSA

Для подписи прошивки можно использовать несколько алгоритмов, включая RSA, DSA и ECDSA. В этом посте мы сосредоточимся на ECDSA по нескольким причинам:

  1. Безопасность. ECDSA — это новейший и лучший алгоритм подписи. Хотя большинство считает, что стандартный DSA нарушен, ожидается, что ECDSA останется безопасным до тех пор, пока квантовые вычисления не станут широко доступными.
  2. Популярность. ECDSA широко используется в различных приложениях, от криптовалют (биткойн) до безопасного обмена сообщениями. С популярностью приходят проверенные на практике реализации и надежность.
  3. Доступность. Для микроконтроллеров доступны реализации ECDSA с открытым исходным кодом, включая mbedtls 1 , wolfssl 2 и micro-ecc.
  4. Небольшой размер. Реализации ECDSA очень малы (одна цифра в килобайтах) и требуют ключей меньшего размера, чем RSA или DSA, для аналогичного уровня безопасности. Это экономит место для кода и оперативную память, а также делает ECDSA подходящим для встроенных сред.

Понимание математики ECDSA выходит за рамки этой статьи, но вот общий обзор того, как работает этот процесс:

  1. Создается криптографический хэш двоичного файла микропрограммы. Должен работать любой алгоритм криптографического хеширования, хотя рекомендуются хэши семейства SHA-2. В случае SHA-256 это дает 32-байтовое число.
  2. Подпись создается с использованием закрытого ключа и криптографического хэша. Эта подпись распространяется вместе с прошивкой и открытым ключом. Подпись может быть недетерминированной, поэтому не беспокойтесь, если несколько вызовов вашего кода ECDSA дадут разные подписи. Эта подпись представляет собой пару целых чисел, каждое из которых имеет длину 32 байта.
  3. Чтобы проверить двоичный файл, для двоичного файла микропрограммы еще раз вычисляется хэш SHA-256.
  4. Открытый ключ и хэш можно использовать для проверки того, что подпись была сгенерирована с использованием совпадающих входных данных.

Реализация подписи встроенного ПО

Наша реализация основана на коде, который мы написали для публикации об архитектуре обновления микропрограммы. Вы можете найти этот код на Github по адресу interrupt@20ec4ba.

Настройка

Как и в предыдущем посте «Пособие по обновлению прошивки», мы используем Renode для запуска примеров из этого поста. В предыдущем посте есть подробная инструкция, но вкратце:

Одно изменение, которое мы сделали по сравнению с предыдущими публикациями, — это запуск в автономном режиме. Это делается путем вызова Renode со следующими флагами:

Затем мы можем использовать telnet для подключения к консоли Renode:

Аналогичным образом мы направляем UART устройства к порту telnet, а не к графическому окну, добавляя две строки в наш renode-config.resc :

Затем мы можем получить доступ к UART нашего эмулируемого устройства через telnet:

Архитектура

Напоминаем, вот как выглядит архитектура обновления встроенного ПО нашего устройства:

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

Что вы узнаете:

  • Как безопасно выполнять обновления по беспроводной сети (OTA).
  • Наилучшие методы шифрования связи в хост-сети.
  • Безопасное совместное использование ключей и асимметричная криптография.
  • Реализация аутентификации.

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

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

Безопасные обновления OTA

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

При общении в Интернете целостность и подлинность данных вызывают всеобщую озабоченность. Потенциальные опасности, такие как атаки «человек посередине» (MITM), требуют проверки того, действительно ли устройство загружает то, что, по его мнению, у него есть. Если он загружает и устанавливает то, что злоумышленник выдает за законную прошивку, то злоумышленник успешно захватил устройство.

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

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

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

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

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

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

В этом блоге мы рассмотрим уровень абстракции, который мы представили в Trusted Firmware-A (TF-A) и Open Portable Trusted Execution Environment (OP-TEE) для поддержки шифрования прошивки. Это упростило поставщикам полупроводниковых компонентов шифрование встроенного ПО с минимальными затратами на поддержку платформы и снижение нагрузки на дальнейшее обслуживание встроенного ПО. Об этом говорилось на Linaro virtual connect 2020, но из-за пандемии мы никогда не обсуждали эту функцию так широко, как могли бы. Мы решили исправить это в этой записи блога!

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

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

В системах Armv8 программное обеспечение DRM обычно работает как доверенное приложение (TA), работающее в среде TEE, возможно, дополненное некоторыми аппаратными драйверами в доверенной ОС. Следовательно, чтобы обеспечить шифрование прошивки, мы должны добавить поддержку в TF-A для расшифровки полезной нагрузки доверенной ОС (BL32), которая для OP-TEE состоит из самой ОС вместе с любыми связанными ТА (включая псевдоТА). Кроме того, OP-TEE должен поддерживать расшифровку TA, загружаемых из файловой системы Linux. В обоих случаях ранее существовавшие загрузчики поддерживали аутентификацию, но не расшифровку.

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

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

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

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

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

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

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

Ниже приведены скриншоты незашифрованной прошивки.

Затем вы можете использовать программное обеспечение для извлечения содержимого для изучения:


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

Вот веб-файловая система:

Вот прошивка, которая зашифрована. Обратите внимание, что в нем указано, что файл использует шифрование OpenSSL.

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

Arecont surrountvideo omni g2 av20275dn v65199 неизвестно/возможно зашифровано

Линейка камер Avigilon H4 ES ACC6.0.0.24 h4HD-FW-t200-3.16.2.52 без шифрования

Axis P3225-LVE без шифрования

Bosch dinion ip dynamic 7000 hd cpp 6.32.0099 неизвестно/возможно зашифровано

Canon vbh43 v.1.25 не зашифрован

DH-IPC-HDBW42A1FN-AS v432105 без шифрования

Цифровой сторожевой таймер wdc-md421d 2.1.5.3 не зашифрован

Flir quasar gen II fs20160805nsz — широковещательный заголовок, не включен.

Hanwha Techwin QND-7080R v1.01 с шифрованием

Hikvision DS-4x12 v5.4.0 не зашифрован

Panasonic SFV78L v2.53es неизвестен/возможно зашифрован

Купольные камеры Pelco Sarix IME+ следующего поколения — IME329 v6.2.1.73 без шифрования

Sony G6 v2.7.3 Без шифрования

Vivotek FD8369A-V v0200e не зашифрован

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

Читайте также: