В этой статье приведен перевод даташита Atmel 6253 "Safe and Secure Firmware Upgrade for AT91SAM Microcontrollers".

[Введение]

Микроконтроллеры все больше и больше используются в различной электронной продукции. С их помощью устройства получаются более гибкими, благодаря наличию в микроконтроллерах перепрограммируемой памяти программ (обычно FLASH), в которую сохраняют программное обеспечение продукта (firmware). Это означает, что устройство может быть продано и при этом все еще может обновлять свою программу уже у конечного пользователя ("в полях", upgraded in-field). Такая возможность очень востребована, так как позволяет устранять ошибки и добавлять новый функционал. На рисунке показана основная идея этой концепции.

1. Сначала производитель (Manufacturer) разрабатывает устройство (Device) и начальную версию firmware.
2. Устройство продается в магазине конечному потребителю (Customer).
3. Производитель выпускает новую версию программного обеспечения (New firmware).
4. Новое firmware распространяется по всему миру, попадая к пользователям (например, прошивка может быть выложена в разделе Download сайта производителя).
5. Потребитель, получив новую прошивку firmware, самостоятельно (с помощью бутлоадера) перепрограммирует свое устройство этой новой прошивкой.

Однако в таком сценарии кроются две серьезные проблемы, которые желательно решить. Во-первых, устройство не должно случайно испортиться при ошибке во время процесса обновления. Ошибка может быть самой разной - от тривиального исчезновения питания до обрыва связи в процессе передачи нового firmware. Решение этой первой проблемы мы назовем безопасным (safety) обновлением. На рисунке иллюстрируется проблема безопасного обновления.

1. Производитель (Manufacturer) разрабатывает устройство (Device) и начальную версию firmware.
2. Устройство попадает к конечному потребителю (Customer).
3. Производитель выпускает новую версию программного обеспечения (New firmware).
4. Новое firmware попадает к пользователю.
5. Пользователь запускает процесс обновления устройства новым firmware.
6. Во время обновления происходит ошибка при передаче (например, разрядилась батарея питания), что привело к полной потере работоспособности устройства.

Вторая проблема состоит в защите (security) программного обеспечения как интеллектуальной собственности. Основное беспокойство разработчиков firmware состоит в том, чтобы не допустить использования своих разработок конкурентами; поэтому новая программа должна быть защищена от неавторизованного доступа, когда прошивка firmware попадает к пользователям и в целевой продукт.

1. Производитель выпускает новую версию программного обеспечения (New firmware).
2. Конкурент (Competitor) получает новую прошивку firmware.
3. Код firmware подвергается дизассемблированию и анализу (reverse-engineered, обратная разработка) для получения исходного оригинального кода.

В секции 2 In-field Upgrading объясняется общий принцип - как происходит традиционный процесс обновления. Также описаны различные проблемы, связанные с этим процессом, как и советы для решения этих проблем.

[2. In-field Upgrading (обновление "в поле", т. е. у конечного пользователя)]

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

2.1 Bootloader

Многие современные микроконтроллеры используют память, изготовленную по технологии NOR Flash для хранения кода своей программы. Главное достоинство FLASH в том, что память может быть перезаписана самим программным обеспечением. Это ключевая особенность, которая делает возможным обновление "в поле": маленькая часть кода добавляется в основное приложение для предоставления возможности загружать обновления, которые заменят старое firmware в устройстве. Эта маленькая часть кода часто называется bootloader, потому что его основная роль заключается в загрузке новой программы при старте (boot).

Код бутлоадера всегда размещается в памяти, чтобы можно было в любой момент обновить устройство. На рисунке показано приблизительное распределение памяти при использовании бутлоадера. Таким образом, желательно сделать этот код минимального объема, поскольку объем памяти микроконтроллера ограничен, и никому не нужно терять значительное место кода просто так: бутлоадер (Bootloader) не функционально не дает никакой пользы для функционала программы (Application), кроме обновления.

Чтобы закачать новое firmware в устройство, необходимо сообщить бутлоадеру, что нужно это сделать (должно сработать условие обновления). Обычно бывает два типа условия - аппаратное (hardware) и программное (software). Под аппаратным условием подразумевается нажатие определенной кнопки при включении питания (или сбросе) или наличие перемычки. Программное условие - отправка специальной команды устройству, отсутствие в системе актуальной программы, или наличие нового файла прошивки на сменном носителе (карта SD/SDHC).

Когда система стартует, бутлоадер проверяет заранее определенные условия обновления: если одно из них выполнено, то делается попытка подключиться к хосту для получения нового firmware (или читается файл firmware с внешнего носителя). Теоретически хостом может быть любое устройство, однако чаще используется обычный компьютер PC со специальным программным обеспечением. Передача файла firmware может осуществляться через любой канал связи (media), который поддерживает целевое устройство, например RS232, USB, CAN, карта SD/SDHC и т. д. На рисунке показан механизм обновления firmware с использованием бутлоадера.

1. Производитель выпускает новую версию программного обеспечения (firmware).
2. Новое firmware попадает к пользователю.
3. Пользователь запускает бутлоадер, устанавливая условие обновления.
4. Бутлоадер соединяется с хостом.
5. Хост передает файл прошивки firmware.
6. Приложение firmware, которое находится в устройстве, перезаписывается на новое.
7. Запускается новое firmware.

После завершения передачи (шаг 5) бутлоадер заменяет старое firmware на его новую версию (шаг 6), и устройство получает теперь новую рабочую программу.

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

2.2 Проблемы

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

Пояснения к рисунку:

Safety issues - проблемы безопасного обновления устройства.
Corrupted firmware - поврежденное firmware.
Transmission error - ошибка при передаче.
Truncated firmware - firmware обрезано.
Information loss - потеря информации.
Incomplete firmware - неполностью закачанное firmware.
Device - обновляемое устройство, в котором находится программа приложения firmware.
Download - закачка.
Customer - конечный пользователь устройства.
Transport - канал передачи файла firmware конечному пользователю.
Manufacturer - производитель, который разрабатывает новые версии firmware.
Security issues - проблемы защиты firmware от несанкционированного доступа.
Unauthorized device - неавторизованное устройство (например, аналогичное устройство, произведенное конкурентами).
Third-party firmware - firmware, которое может быть разработано другими производителями.
Unauthorized firmware - неавторизованное firmware.
Firmware alteration - переделка firmware.
Modified firmware - модифицированное firmware.
Reverse-engineering - реверс-инжиниринг, обратная разработка.

В последующих секциях 2.2.1 Safety и 2.2.2 Security обсуждаются эти важные проблемы:

• Safety (безопасность обновления)
   – Ошибка при передаче (Transmission error)
   – Обрыв передачи (Transmission failure)
   – Потеря информации (Information loss)
• Security (защита ПО firmware от несанкционированного использования)
   – Обратная разработка (Firmware reverse-engineering)
   – Использование постороннего, неавторизованного ПО для устройства (unauthorized firmware)
   – Модификация ПО устройства (Firmware modification)
   – Использование ПО firmware на постороннем устройстве (unauthorized device).

2.2.1 Safety

На рисунке показаны проблемы безопасности обновления, которые происходят при использовании базовой версии бутлоадера.

Рис. 2-4. Проблемы безопасной загрузки firmware.

Для большинства устройств критично всегда иметь на борту рабочее firmware, поскольку иначе оно не сможет нормально работать. Однако использование бутлоадера может привести к проблематичной ситуации, когда новое firmware не было еще корректно установлено (а старое уже испорчено) - в результате получается "брикнутое", полностью неработоспособное устройство.

Тривиальная проблема может произойти, если устройство неожиданно потеряло питание во время процесса обновления. Область памяти приложения оказывается испорченной, и устройство перестанет работать. Этот случай можно отнести к проблеме 2 рисунка (Transmission failure).

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

Кроме того, возможен случай (проблема 1, показанная на рисунке, Transmission error), что файл firmware окажется случайно поврежденным в процессе передачи его к потребителю (например, в будет изменен один бит в каком-нибудь блоке данных). Результат может быть самый непредсказуемый - от незначительной ошибки в вычислениях (например, если будет изменена константа) до зависания при выполнении (если ошибка в адресе или команде кода).

И наконец, некоторые данные могут быть потеряны при передаче firmware в целевое устройство (проблема 3 рисунка). Это приведет к порче кода после пропущенной части. Некоторые каналы связи и протоколы могут поменять порядок блоков данных, что требует проверки - какой именно блок был принят, и где он должен располагаться в памяти.

2.2.2 Security

На рисунке показаны проблемы защиты firmware от несанкционированного использования, которые происходят с базовой версией бутлоадера.

Рис. 2-5. Проблемы защиты с базовым бутлоадером.

Защита ПО системы подразумевает удовлетворение следующих требований: privacy (частное использование), integrity (целостность), authenticity (аутентичность, подлинность).

Privacy означает, что никакие части данных не могут быть прочитаны неавторизованными пользователями или устройствами. Главная забота разработчиков firmware - не допустить попадания разработанного ими приложения к конкурентам. Поэтому им нужно, что бы их код оставался только в частном использовании (privacy), и целевые устройства имели только авторизованных пользователей.

Микроконтроллеры обычно имеют встроенный механизм, который делает невозможным преступное чтение кода, который записан в устройство. Однако при обновлении firmware у конечного пользователя производитель публично распространяет новый образ кода программного обеспечения firmware, чтобы пользователи могли обновить свое устройство самостоятельно. Следовательно, квалифицированный специалист может декомпилировать firmware и получить исходный код (проблема 4 рисунка, Reverse-engineering).

Authenticity (аутентичность) дает возможность проверить, что firmware действительно было выпущено производителем, а не кем-нибудь еще. И действительно, другая проблема при перепрограммировании состоит в том, что устройству можно предоставить для программирования firmware, произведенное не оригинальным производителем (original manufacturer), а сторонним разработчиком (third-party firmware, проблема 2 на рисунке). Особенно проблематично, когда firmware разработано с вредоносными целями, например чтобы обойти барьеры защиты, нелегально получить доступ к критическим функциям устройства, и т. д. Оригинальное firmware также может быть использовано не другом устройстве, на котором такое firmware может быть запущено (проблема 1 рисунка, Unauthorized device). Это может быть нелегальная, неавторизованная копия продукта, или устройство, специально разработанное для взлома (hacking). Здесь снова возникает проблема подлинности (authenticity), на этот раз касательно самого целевого устройства.

И наконец, integrity (проверка целостности) нужна для определения модификации данных. К примеру, авторизованное firmware может быть незначительно модифицировано (проблема 3 рисунка, Firmware alteration). Firmware может выглядеть полностью как оригинальное, но атака может быть такой же и с теми же целями, как было описано в предыдущем параграфе.

Без выполнения требований защиты, код firmware может быть предметом все атак касательно приватности, целостности и подлинности (privacy, integrity, authenticity). Поэтому необходимы некоторые техники для организации решения этих вопросов.

[3. Предложенное решение задач безопасности и защиты]

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

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

3.1 Safety

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

3.1.1 Стек протокола (Protocol Stack)

Стек протоколов используется в большинстве коммуникационных стандартов для обеспечения надежных передач данных. Эта надежность важна для бутлоадера, поскольку firmware не должно быть повреждено в процессе закачки (проблемы 2 и 3 на рисунке 2-4).

В стандартной модели OSI система обмена поделена на сем слоев, которые формируют стек протоколов. Каждый слой отвечает за определенный набор функций. Например, самый нижний физический слой (physical layer) отвечает за физическое соединение устройств. Надежность обычно реализована на транспортном слое (transport layer).

Надежность передачи всегда связана с добавлением некоторой избыточности в передаваемый поток данных, и на уровне транспортного протокола обычно реализуется с использованием кодов детектирования и коррекции ошибок (error detection/correction codes), нумерации блоков данных (block numbering) и подтверждения пакета (packet acknowledgement). Имеющиеся протоколы для доступных каналов связи (media) микроконтроллеров Atmel® ARM® Thumb® AT91SAM описаны в секции Section 3.1.1.4 Существующие протоколы.

3.1.1.1 Error Detection/Correction

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

Detection codes (коды детектирования ошибок) используют простое математическое вычисление некоторого числа (контрольной суммы) от всего массива отправляемых данных. Эта контрольная сумма передается отдельно, наряду со всеми оригинальными данными. Когда целевое устройство получает данные, оно заново само вычисляет контрольную сумму по такому же алгоритму, и сравнивает полученное значение с принятым значением контрольной суммы. Если оба значения контрольных сумм (полученная и принятая) совпадают, то передача считается успешной и безошибочной; иначе в принятом блоке данных имеется один или большее количество неправильных бит. Контрольная сумма может быть подсчитана как на один блок данных (малую часть передаваемого firmware), так и на весь массив данных firmware.

Correction codes (коды коррекции ошибок) работают по такому же принципу, за исключением того, что они могут не только детектировать наличие ошибок, но и еще и устранять их (восстанавливать оригинальное значение данных). Это полезно для того, чтобы избежать запросов к передающему узлу на повторную передачу ошибочно принятых данных. Второе отличие - может быть обнаружено и исправлено только строго ограниченное количество ошибок, определяемое применяемым методом кодирования. Третье отличие состоит в том, что практическое применение коррекции ошибок может быть осуществлено только на малую порцию данных firmware фиксированного размера, не на все firmware в целом.

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

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

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

3.1.1.2 Нумерация блоков

Назначение нумерации блоков (block numbering) состоит в том, чтобы исключить потери данных блока, или разрешить ситуацию, когда блоки пришли в неверном порядке. Это критично в передачах, ориентированных на файл, такие как закачка firmware: ошибки такого рода приведут к тому, что принятый код будет нерабочим.

Как подсказывает название нумерация блоков - простое добавление последовательно меняющегося числа к каждому переданному блоку. Это число для каждого последующего блока увеличивается на 1. Таким образом, получатель данных может просто определить, какие два блока поменялись местами, если блок №3 поступит раньше №2. Точно так же, если в последовательности принятых блоков за №3 сразу идет №5, то значит был пропущен блок №4.

Пояснения к рисунку:

Emitter - передатчик блоков данных firmware (обычно хост, передающий данные по каналу связи).
Receiver - получатель блоков данных firmware (бутлоадер, работающий на микроконтроллере устройства).
Transmitting block #1 - передача блока №1.
Expecting block #1 - ожидание поступления блока №1.
Lost! - потеря данных.
Wrong block received - принят неверный блок.

3.1.1.3 Подтверждение пакета

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

Пояснения к рисунку:

Emitter - передатчик блоков данных firmware (обычно хост, передающий данные по каналу связи).
Receiver - получатель блоков данных firmware (бутлоадер, работающий на микроконтроллере устройства).
Transmit block - передача блока.
Acknowledge block - подтверждение блока.
Wait for acknowledge - ожидание передатчиком подтверждения от приемника.
Lost! - потеря данных.
Retransmit block - повторная передача блока.

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

3.1.1.4 Существующие протоколы

Канал связи (communication medium), такой как RS-232 или Ethernet, на низком уровне нечасто используется для обновления firmware. Для этой цели чаще требуется использовать полный стек протоколов.

Протокол TCP/IP, находящийся на вершине стека протоколов Ethernet, используется наиболее часто. Протокол контроля транспорта (Transport Control Protocol, TCP), реализует надежность путем использования ка последовательной нумерации пакетов (packet sequence number), так и контрольной суммы (checksum, простая система определения наличия ошибки). TCP также использует вариант подтверждения пакета, однако в его алгоритме возможна ситуация, когда отправленные пакеты могут прийти к получателю не в том порядке, в котором были отправлены (поэтому все еще необходима отдельно организованная нумерация блоков). На рисунке показана структура фрейма (пакета) TCP.

Пояснения к рисунку:

Bits - биты.
Source port - номер порта источника пакета.
Destination port - номер порта получателя пакета.
Sequence number - последовательно меняющийся номер пакета.
Acknowledgement number - номер подтверждения.
Data offset - смещение данных.
Reserved - зарезервировано.
Flags - флаги.
Window - окно.
Checksum - контрольная сумма.
Urgent pointer - указатель срочности доставки.
Options - опции.
Data - передаваемые данные.

Протокол USB использует контрольный циклический код (Cyclic Redundancy Check, CRC) для детектирования наличия ошибок. Это не последовательный номер пакетов, однако получатель подтверждает каждый блок данных. Это работает так же, как и в протоколе шины CAN (CAN bus). На рисунке показана структура фрейма CAN.

Пояснения к рисунку:

Size - размер в битах.
Start-of-frame - флаг начала фрейма.
Identifier - идентификатор фрейма.
Remote transmission request - запрос удаленной (в смысле дальней) передачи.
Identifier extension bit - бит расширения идентификатора.
Reserved - зарезервировано.
Data length code - код длины данных.
Data - данные (до 8 байт).
Cyclic redundancy check - контрольный циклический код (CRC).
CRC delimiter - разделитель CRC.
ACK slot - слот ACK (место флага подтверждения).
ACK delimiter - разделитель ACK.
End-of-frame - конец фрейма.

И наконец, имеется некоторые ориентированные на передачу файла протоколы для интерфейса RS-232. Один из них X-MODEM, который был разработан в 1970 году. В нем встроена простая однобайтовая контрольная сумма, нумерация блока и подтверждение пакета. Поскольку контрольная сумма не очень надежная, то при использовании этого протокола желательно по завершении передачи проверять отдельно вычисленную контрольную сумму всех данных по более надежному алгоритму - CRC16 или CRC32. На рисунке показана структура фрейма протокола XMODEM.

Пояснения к рисунку:

Size - размер.
Start-of-frame - флаг начала фрейма.
Block number - номер блока.
Block number complement - комплемент номера блока.
Data - данные (128 байт).
Checksum - контрольная сумма.

3.1.2 Memory Partitioning (разделение памяти)

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

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

• Регион кода приложения (старое рабочее firmware, region A).
• Регион буфера для нового firmware (region B).

Регион B используется как буфер для закачки нового firmware, куда оно закачивается полностью перед тем, как будет запрограммировано в регион A. Этот метод обеспечивает условие, что всегда имеется рабочее firmware после завершения обновления - независимо от того, завершилось ли обновление успешно или нет.

3.1.3 Общие выводы

Детектирование ошибок и их коррекция
• Достоинства
– Детектирование ошибок передачи
• Недостатки
– Некоторая сложность реализации кода (особенно для коррекции ошибок)
– Незначительное увеличение размера кода (бутлоадера)
– Незначительное уменьшение скорости обновления (только при обновлении)

Memory partitioning (разделение памяти)
• Достоинства
– Успешно решаются все проблемы, связанные с безопасным и надежным обновлением
• Недостатки
– Удваивается требования к необходимой памяти
– Незначительное увеличение размера кода (бутлоадера)
– Уменьшение скорости обновления (только при обновлении)

Таким образом, наиболее целесообразно применять при передаче простую проверку блоков с помощью надежной контрольной суммы CRC с повторной передачей блоков при ошибках. Коррекцию ошибок применять нецелесообразно из-за сложности реализации и возможности повторных передач ошибочно переданных блоков. Разделение памяти имеет смысл применять в тех случаях, когда есть значительный запас памяти (RAM или FLASH).

3.2 Security (защита от несанкционированного использования)

В этой секции представлены некоторые техники, связанные проблемами с защиты от злоумышленников (см. также секцию 2.2.2). Более подробно см. секцию 5.2.

3.2.1 Integrity (целостность)

Проверка целостности означает проверку следующего:
• Целеустремленная модификация firmware
• Случайная модификация firmware

Случайная модификация относится к проблеме безопасности (safety), и уже обсуждалась. Проблема обычно успешно решается применением кодов обнаружения ошибок CRC16 или CRC32 (см. секцию 3.1.1.1).

Есть несколько путей проверки firmware, что оно не было специально модифицировано злоумышленником. Эти методы рассмотрены далее, и они могут решить проблему 3 (Firmware alteration), показанную на рисунке 2-5.

3.2.1.1 Хеш-функция

Назначение хеш-функции (hash function) - получение уникального цифрового отпечатка (fingerprint, hash) куска данных. Фактически это тоже самое, что и CRC, и код детектирования ошибок, и цифровая подпись - каждая часть данных должна иметь собственный уникальный отпечаток.

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

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

Пояснения к рисунку:

Bootloader - код бутлоадера.
Digest - цифровая подпись (хеш) кода firmware.
Host - хост, передающий код firmware бутлоадеру вместе с цифровой подписью.
Manufacturer - производитель устройства и firmware.
Compare - сравнение принятой подписи с вычисленной
Received digest - принятая подпись.
Digest#2 - вычисленная подпись.

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

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

3.2.1.2 Digital Signature (цифровая подпись)

Поскольку хеш легко вычислить, то хороший совет для защиты - зашифровать его (encrypt). Это базовый принцип цифровой подписи: подпись firmware вычисляется (с использование хеш-функции) и затем шифруется с использованием криптографии открытого ключа (public-key cryptography). Это породит цифровую подпись, родственную обычной подписи, которая используется в повседневной жизни.

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

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

3.2.1.3 Код аутентификации сообщений

Коды аутентификации сообщений (Message Authentication Codes, MAC) предоставляют тот же функционал, что и цифровые подписи, за исключением того, что используется криптография с секретным, закрытым ключом (private key cryptography). Современные алгоритмы криптографии с закрытым ключом, называемые также чипером (chiper) в большинстве практических применений бывают блочными (block ciphers). В блочных чиперах любой рабочий блок для шифрования имеет фиксированный размер, в отличие от потоковых чиперов (stream ciphers), которые работают с потоком данных.

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

• Любой, кто может проверить MAC, может так же и сгенерировать MAC.
• Если секретный ключ будет скомпрометирован (попадет к злоумышленнику или станет публичным), то защита системы потеряет свой смысл.

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

Нужно принять во внимание, что поскольку криптография с секретным ключом работает быстрее криптографии с открытым ключом, то MAC будет вычисляться и проверяться быстрее, чем цифровая подпись. Однако поскольку только одна MAC/подпись требуется для firmware, то для практического использования это не будет иметь большого значения.

3.2.2 Проверка аутентичности (Authentication)

Аутентичность относится к проверки идентификатора отправителя и получателя сообщения. В случае бутлоадера, это означает проверку, что firmware было действительно выпущено производителем, и цель (устройство) программирования является оригинальным (не подменено каким-то другим). Проверка аутентичности решает проблемы №1 и №2, показанные на рисунке 2-5.

Это означает, что методы проверки аутентичности также предоставляют возможность проверки целостности (integrity): они предоставляют цифровую подпись и MAC. Поскольку эти вопросы уже были рассмотрены с точки зрения целостности (см. секцию 3.2.1), то здесь будут обсуждаться только свойства аутентификации. Эта секция рассматривает только аутентификацию firmware, аутентификация цели программирования будет рассмотрена позже.

3.2.2.1 Digital Signature (цифровая подпись)

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

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

3.2.2.2 Код аутентификации сообщений

В отличие от подписи, код аутентификации сообщений (Message Authentication Code, MAC) не может использоваться для сертификации факта отправки сообщения оригинальным отправителем. И действительно, поскольку получатель также имеет секретный ключ, используемый для вычисления MAC, то он также может и сгенерировать MAC. Достоинство только в том, что и отправитель, и получатель могут расшифровать MAC, что защищает от того, что кто-то еще мог бы проверить сообщение (в нашем случае код firmware) на правильность.

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

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

3.2.3 Privacy (частное владение)

Защита частного владения данными осуществляется с использованием шифрования (encryption): данные обрабатываются по криптографическому алгоритму (cryptographic algorithm) в соответствии с ключом шифрования (encryption key), в результате появляется шифрованный текст, который отличается от незашифрованного оригинала. Без наличия ключа дешифровки (decryption key) данные становятся совершенно бесполезными, защищенными от неавторизованного чтения кем бы то ни было. Это решает проблему 4 (Reverse-engineering), показанную на рисунке 2-5.

На практике для генерации шифрованного firmware используется алгоритм с секретным ключом (private-key algorithm). Очевидно, что нельзя использовать криптографию с открытым ключом (public-key system), поскольку тогда firmware тогда могло бы быть расшифровано любым. В случае криптографии с секретным ключом, ключ для шифрования и дешифрования один и тот же, и хранится как у производителя, так и в коде бутлоадера.

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

Шифрование комбинируется также с кодом аутентификация (message authentication code, MAC). Поскольку и шифрование, и MAC используют симметричный алгоритм шифрования (ключ для шифрования и дешифровки один и тот же), то для экономии кода он может использоваться обоих случаях. Можно выбрать также режим защиты с комбинацией блочного чипера (для шифрования firmware) и MAC, использующих один и тот же ключ (см. секцию 5.2.1.2).

3.2.4 аутентификация целевого устройства (Target Device Authentication)

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

В частном случае, шифрование firmware также служит аутентификации устройства. В самом деле, нужен секретный ключ, чтобы расшифровать firmware. Только легальные, "чистые" устройства имеют встроенный в себя секретный ключ (в коде бутлоадера), а неавторизованные цели не смогут восстановить оригинальный код и запустить программу firmware. Это особенно полезно, поскольку аутентификация цели все равно не может быть решена без шифрования кода; в противном случае любой код может быть просто загружен в устройство.

Метод активной (active) аутентификации подразумевает добавление к цели специальной техники. Поскольку идентификация цели должна быть проверена хостом в процессе обновления, то код аутентификации сообщения (message authentication code, MAC) не может использоваться. Действительно, поскольку MAC требует для хоста иметь секретный ключ, атакующий может просто получить его. Добавление такого механизма также потребовало значительной дополнительной нагрузке по ресурсам - как с точки зрения размера бутлоадера (необходимо место, чтобы выделить место под дополнительный ключ и алгоритм шифрования цифровой подписи), так и с точки зрения уменьшения скорости обновления (поскольку транзакции требуют идентификации устройства). Кроме того, программа обновления для хоста все равно должна быть модифицирована для реализации дополнительного механизма.

3.2.5 Общие выводы по использованию технологий защиты

Хеш-функция
• Достоинства
   – Детектирует случайные и целенаправленные изменения кода
   – Может использоваться для проверки firmware на целостность во время выполнения
• Недостатки
   – Может быть вычислена заново злоумышленником
   – Приводит к незначительному увеличению размера кода
   – Незначительно уменьшает скорость обновления

Цифровая подпись (Digital signature)
• Достоинства
   – Детектирует модификацию firmware, и firmware, выпущенное сторонними производителями (third-party)
   – Даже если ключ в бутлоадере скомпрометирован, система остаются безопасно работающей
• Недостатки
   – Работает медленнее, чем MAC
   – Требует большую длину ключа
   – Увеличивает размер кода
   – Уменьшает скорость обновления

Код аутентификации сообщения (Message authentication code, MAC)
• Достоинства
   – Детектирует модификацию firmware, и firmware, выпущенное сторонними производителями (third-party)
   – Работает быстрее, чем цифровая подпись
• Недостатки
   – Если ключ в коде бутлоадера скомпрометирован, то система взломана
   – Увеличивает размер кода
   – Незначительно уменьшает скорость обновления

Шифрование кода (Code encryption)
• Достоинства
   – Предотвращает возможность обратной разработки firmware (reverse-engineering)
   – Аутентифицирует программируемую цель
• Недостатки
   – Если ключ в коде бутлоадера скомпрометирован, то система взломана
   – Увеличивает размер кода
   – Уменьшает скорость обновления

[4. Примеры использования]

В этой секции представлены несколько возможных вариантов использования и реализации бутлоадера. Возможные реализации каждого сценария обсуждаются с точки зрения достоинств безопасности и защиты (safety & security) против увеличения размера кода и ухудшения быстродействия.

4.1 Security

4.1.1 Сценарий 1

4.1.1.1 Исходные требования

Для этого базового сценария есть только одно требование - предотвратить получение злоумышленником доступа к коду firmware.

4.1.1.2 Основной метод решения

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

4.1.1.3 Опции

Поскольку Вы добавили для шифрования симметричный чипер, то этот же чипер может быть также использован для реализации кода аутентификации сообщения (message authentication code, MAC), таких как OMAC/CMAC. MAC сделает для бутлоадера возможным проверить, что firmware не было модифицировано (случайно или специально).

4.1.2 Сценарий 2

4.1.2.1 Исходные требования

Никогда нельзя ставить под угрозу возможность изменения устройства клиента или загрузки в него вредоносного firmware стороннего производителя.

4.1.2.2 Основные методы решения

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

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

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

4.1.2.3 Опции

Если используется MAC с симметричным чипером (такой как OMAC/CMAC), то Вы можете также принять решение о шифровании и самого firmware. Поскольку для этого используется тот же самый алгоритм (и можно использовать тот же ключ), то лишний расход кода будет минимальным.

4.1.3 Сценарий 3

4.1.3.1 Исходные требования

Требуется максимальная защита:
• Код firmware не должен быть прочитан пользователями
• Потребителю нельзя загрузить в устройство нелицензионное firmware
• Неавторизованные устройства (произведенные не по лицензии разработчика) не могут использовать оригинальное firmware

4.1.3.2 Основные методы решения

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

Аутентичность (подлинность, authenticity) и целостность (integrity) может быть обеспечена либо использованием MAC, либо цифровой подписью. Использование MAC позволит экономить на размере кода (путем повторного использования блочного чипера, добавленного для шифрования кода). Цифровая подпись позволит обеспечить улучшенную защиту.

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

[5. Рассмотрение вопросов дизайна]

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

5.1 Канал связи для передачи firmware (Transmission Media)

Микроконтроллеры AT91 имеют богатый набор стандартной периферии для обмена данными с внешним хостом:
• USB
• CAN
• RS232
• Ethernet
• Внешняя память (например DataFlash® или SD/SDHC).

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

Необходимо отметить, что класс устройств USB хорошо подходит к обновлению firmware. К этому классу относится класс Device Firmware Upgrade (DFU), который может использоваться для реализации функции бутлоадера. Однако имейте в виду, что этот класс не поддерживается драйверам Microsoft® Windows®, поэтому может быть труден в реализации (требуется разработка специального драйвера для ПО хоста).

И наконец, канал связи CAN или Ethernet имеют большой потенциал для массового программирования (batch programming): например, они могут позволить программировать несколько устройств одновременно. Хост может организовать широковещательную отправку сообщений, что позволит каждому подключенному к сети устройству получить firmware и обновиться.

5.2 Алгоритмы криптографии

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

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

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

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

5.2.1 Симметричные чиперы

Симметричные чиперы (или системы шифрования с секретным ключом) используются и для вычисления MAC, и для шифрования кода программы. Таким образом - это очень важная часть обеспечения защиты бутлоадера, и она должна быть мудро выбрана.

5.2.1.1 Выбор алгоритма шифрования

Алгоритм симметричного шифрования может быть охарактеризован по следующим характеристикам:
• Длина ключа в битах
• Длина блока в битах
• Защищенность
• Размер алгоритма и его скорость работы

Длина ключа (key length), используемого алгоритмом является очень важным параметром. Чем ключ длиннее, тем сложнее провести атаку на грубый подбор (брутфорс, brute-force attack), т. е. взломать код путем попыток перебрать все возможные варианты ключа, пока какой-нибудь один из них не заработает. Поскольку мощность компьютеров как вычислителей с каждым днем возрастает, то постоянно увеличивается и необходимая на сегодняшний день длина ключа. В настоящий момент подходящей длиной ключа можно считать 128 бит, именно такая длина выбрана для чипера Advanced Encryption Standard (AES).

Большая длина блока шифрования требуется для того, чтобы исключить атаку "по книжке" ("codebook attack"), например, чтобы по известному заранее куску кода (расшифрованного текста) и соответствующему ему блоку шифрованных данных нельзя было бы построить таблицу статистики, которая поможет декодировать остальную информацию.

В нашем случае (при обновлении firmware) атакующий вряд ли вообще получит доступ к открытому куску данных. Таким образом, длина блока чипера может быть любого (наиболее подходящего) размера. Большинство блочных чиперов используют как минимум 64 бита, современные чиперы используют блоки размером не менее 128 бит.

Вопрос защитных свойств (security) чипера также конечно очень важен. Если алгоритм имеет уязвимость, то его можно легко взломать. Старые чиперы наподобие DES были сочтены нестойкими и их сейчас мало используют. Так как криптоанализ постоянно развивается, то могут быть найдены новые методы для взлома шифров, которые сейчас рассматриваются как безопасные.

Взлом шифра не означает того, что он стал немедленно дешифрируемым; это может означать всего лишь, что при переборе из 2128 ключей, нужно провести к примеру только 2100 попыток. Таким образом, многие атаки могут быть непригодны даже для старых алгоритмов наподобие DES.

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

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

Табл. 5-1. Алгоритмы симметричного шифрования

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

Пояснения к рисунку:

Initial value - изначальное значение.
Block cipher - блочный чипер.
Hash - вычисленный хеш.
Digest - сгенерированная подпись.

5.2.1.2 Режимы работы

Для симметричных чиперов возможны несколько режимов работы:
• Electronic codebook (ECB)
• Выстраивание блоков в цепочку (Cipher block chaining: CBC, CFB, OFB, CTR)
• Шифрование с аутентификацией (Authenticated encryption: EAX, CCM, OCB)

Базовым является режим ECB: каждый блок открытого текста шифруется ключом по выбранному алгоритму, и в результате получается блок шифрованного текста. Однако этот режим очень небезопасен, так как он не скрывает известные заранее блоки входных данных. действительно, два одинаковых блока незашифрованного текста (пример все байты 0 или все байты FF) будут зашифрованы в одинаковые блоки шифрованного текста. Это позволит злоумышленнику легко подобрать ключ для дешифрования.

Чтобы решить эту проблему, используется выстраивание шифрованных блоков в цепочку (Cipher block chaining). Шифрование не только производится с текущим блоком открытого текста, на него также оказывают влияние данные предыдущего зашифрованного блока. В этой технологии первый блок шифруется случайным значением вектора инициализации (Initialization Vector, IV). Вектор инициализации может быть передан открыто, поскольку он не используется с тем же самым секретным ключом более одного раза. Вероятно, что производитель произведет перепрошивку своего продукта более одного раза за все время его жизни. Таким образом, IV не может быть сохранен в памяти чипа устройства, точно так же, как и ключ. Поэтому IV передается хостом вместе с шифрованным firmware. На рисунке показан режим работы CBC.

И наконец, режим шифрования с аутентификацией предоставляет сразу и частное использование кода (privacy), и целостность (integrity), и аутентификацию одновременно. Обычно это комбинация использования алгоритма MAC и симметричного блочного чипера. Такая реализация удобна, когда нужны три компонента защиты для реализация метода шифрования, такого как EAX, который будет работать быстрее и будет иметь меньше затрат по ресурсам, чем раздельное применение MAC и симметричного чипера. На рисунке показан режим работы EAX.

5.2.1.3 Затраты ресурсов в сравнении с кристаллом AT91SAM7XC

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

Чипер AES был протестирован в трех различных реализациях. Первая из них использовала библиотеку libTomCrypt [1], вторая базируется на стандартной реализации, предоставленной Paulo Baretto и Vincent Rijmen, и последняя использует аппаратную периферию для шифрования, имеющуюся в чипе SAM7XC.

Табл. 5-2. Измеренное быстродействие разных реализаций AES (на 128-битном ключе и 128-битных блоках)

Реализация тройного DES была протестирована на реализации с помощью библиотеки libTomCrypt и с помощью аппаратной акселерации чипа SAM7XC.

Табл. 5-3. Измеренное быстродействие разных реализаций тройного DES (Triple-DES, на 168-битном ключе и 64-битных блоках)

5.2.2 Хеш-функции

Хеш-функции имеют следующие характеристики:

• Выходная длина
• Защита (security)
• Размер кода и скорость его выполнения

Выходная длина данных хеша должна достаточно большой. Благодаря увеличению длины хеша можно достичь невозможности достижения коллизий, т. е. когда к примеру два разных файла будут иметь одинаковую подпись (хеш). Это также предотвращает от нахождения для некоторой части данных специфичного хеша. На практике большинство современных хеш-функций имеют как минимум 160-биный выход (наподобие SHA-1). Имейте в виду, что стандартные реализации все больше продвигают 512-битные реализации хеша.

Однако защищенность (security) хеш-функции более критична, чем выходная длина хеша. На самом деле, функция MD5 (которая имеет только 128-битный выход) остается все еще безопасной, если в ней нет уязвимостей в плане дизайна. Точно так же, как и для блочных чиперов, нахождение уязвимости в одном хеше еще не означает, что взлом полностью завершен; большинство атак все еще невозможно выполнить без гигантских вычислительных мощностей. Однако новые разработки, которые считаются более защищенными в настоящий момент, являются более предпочтительными, чем устаревшие известные алгоритмы.

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

Табл. 5-4. Обзор возможностей часто используемых алгоритмов вычисления хеша.

5.2.3 Коды аутентификации сообщения (Message Authentication Codes)

Коды аутентификации сообщения (MAC) конструируются с использованием других криптографических примитивов. Таким образом, выбор типа MAC часто диктуется тем, какие алгоритмы были использованы для других функций. Конечно, некоторые алгоритмы MAC признаны уязвимыми, так что остерегайтесь использовать их.

Имеются следующие различные (защищенные) типы MAC:
• HMAC: хеш-функция с секретным ключом
• UMAC: многие хеш-функции и блочный чипер
• OMAC/CMAC: блочный чипер в режиме CBC
• PMAC: блочный чипер в режиме CBC

Например, если Вы уже используете хеш-функцию (для проверки целостности firmware при старте), то использование HMAC не приведет к большим затратам.

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

5.2.4 Алгоритмы цифровой подписи

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

• Стандарт цифровой подписи (Digital Signature Standard, DSS)
• Системы, основанные на алгоритме Rivest-Shamir-Adleman (RSA) публичным ключом (public-key)

Стандарт DSS является, как можно судить по названию, специально разработанным для цифровых подписей. Он основан на алгоритме с публичным ключом, известном как схема Эль-Гамаля (ElGamal scheme). Длина ключа, необходимая для сильной защиты, должна быть как минимум 1024 бита.

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

Таким образом, для увеличения размера входных данных RSA требует использования схемы дополнения (padding scheme). Суть в том, что добавляются добавочные данные (pad) к шифруемому сообщению, что делает систему защищенной. Имеется три основные схемы дополнения:

• Полнодоменное хеширование (Full-domain hashing)
• Оптимальное дополнение асимметричного шифрования (Optimal Asymmetric Encryption Padding, OEAP)
• Схема вероятностной сигнатуры (Probabilistic Signature Scheme, PSS)

Полнодоменное хеширование - это не схема с дополнением, поскольку она использует хеш-функцию, которая выдает на выходе блок размером, эквивалентным длине ключа RSA. С таким способом цифровая подпись может быть представлена числом от 0 до 2^k (где k используемая длина ключа), что делает систему защищенной. Однако это на самом деле не очень пригодно к использованию на практике, поскольку в настоящее время нет хеш-функций, которые могли бы сгенерировать хеш длиннее 512 бит.

Схемы OEAP и PSS обе основаны на добавлении случайных данных для преобразования RSA в вероятностную схему шифрования (probabilistic encryption scheme). Эти два алгоритма, скомбинированные с RSA, показывают стойкие свойства защиты (которые доказуемы). Недостаток состоит в том, что эти схемы требуют использования генератора случайных чисел, чтобы добавить соли (случайности) к сообщению. Однако, это требуется только для подписи сообщения, вовсе не для его проверки; это не влияет на размер кода для алгоритма дешифровки.

5.2.5 Генераторы псевдослучайных последовательностей чисел (Pseudo-random Number Generators, PRNG)

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

Имейте однако в виду, что PRNG (генератор псевдослучайных чисел) не требуется для программируемой цели (для кода бутлоадера). PRNG используется только производителем для следующих операций:
• Генерация секретных ключей (private keys)
• Генерация векторов инициализации (initialization vectors, IV)
• Дополнения данных, когда используются RSA/OEAP или RSA/PSS

На практике это означает, что нет никаких реальных ограничений ни на скорость, ни на размер алгоритма PRNG. Это влияет только на качество защиты.

Алгоритмы PRNG работают от стартовой величины (seed) для генерации последовательных случайных чисел. Инициализация (seed) составляет основную проблему, которая упоминается как собирающая энтропия (gathering entropy). Рассмотрим случай, когда для инициализации seed для PRNG используется текущая дата и время. Атакующий мог бы получить эту информацию и таким образом восстановить произведенное использование каждого случайного числа, по которым отбирают: секретные ключи, векторы инициализации и т. д. Операционные системы обычно предоставляют механизм для получения энтропии, например имеется устройство /dev/random на системах Unix. Они используют, например, время ответа устройств, каких как жесткие диски, чтобы получить требуемую энтропию.

Многие PRNG полагаются на другой криптографический примитив (такой как блочный чипер или хеш-функция) для генерации псевдослучайных чисел на выходе.

Вот список некоторых защищенных PRNG:
• Любой блочный чипер в режиме CTR
• Yarrow
• Fortuna
• Генератор случайного числа Blum-Blum-Shub

5.2.6 Доступные реализации

Эта секция перечисляет источники библиотек и/или ссылки на реализации некоторых криптографических примитивов, описанных в этом документе. Это все источники с открытым исходным кодом (open-source), и/или свободные для использования реализации.

5.2.6.1 Библиотеки на языке C

libTomCrypt [1]
• Симметричные чиперы: AES, DES/Triple-DES, Blowfish, RC6, Twofish
• Режимы работы: ECB, CBC, OFB, CFB, CTR, EAX, OCB, CCM
• Хеш-функции: MD5, SHA-1, SHA-256, TIGER-192, RIPEMD-160, WHIRLPOOL
• Коды MAC: HMAC, CMAC, PMAC
• Цифровые подписи: DSA, RSA/OEAP, RSA/PSS
• Генераторы псевдослучайных последовательностей чисел: Yarrow, Fortuna

catacomb cryptographic library
• Симметричные чиперы: Blowfish, DES/Triple-DES, AES, Serpent, Twofish
• Режимы работы: ECB, CBC, CFB, OFB, CTR
• Хеш-функции: MD5, SHA-1, SHA-256, Tiger
• Коды MAC: HMAC
• Цифровые подписи: DSA, RSA/OEAP, RSA/PSS

OpenSSL crypto [2]
• Симметричные чиперы: Blowfish, DES/Triple-DES
• Режимы работы: ECB, CBC, CFB, OFB
• Хеш-функции: MD5, RIPEMD-160, SHA-1
• Коды MAC: HMAC
• Цифровые подписи: DSA, RSA/OEAP

5.2.6.2 Библиотеки на языке C++

Crypto++ [3]
• Симметричные чиперы: AES, RC6, Twofish, Serpent, DES/3DES, Blowfish
• Режимы работы: ECB, CBC, CFB, OFB, CTR
• Хеш-функции: MD5, HAVAL, RIPEMD-160, Tiger, SHA-1, SHA-256, WHIRLPOOL
• Коды MAC: HMAC, CMAC
• Цифровые подписи: RSA/OAEP, RSA/PSS, DSA
• Генераторы псевдослучайных последовательностей чисел: Blum Blum Shub

5.2.6.3 Отдельные реализации на языке C

Brian Gladman [4], см. раздел Technology -> Cryptography
• Симметричные чиперы: AES, Serpent
• Режимы работы: ECB, CBC, CFB, OFB, CTR, CCM, EAX
• Хеш-функции: SHA-1, SHA-256
• Коды MAC: HMAC, OMAC

5.3 Коды для детектирования наличия ошибок (Error Detection Codes)

Поскольку микроконтроллеры AT91 базируются на 32-разрядной архитектуре, кажется логичным реализовать коды, которые будут использовать разрядность как минимум той же длины. Это не будет дешевле с точки зрения скорости, чем 8- или 16-битный вариант.

Обычно для детектирования ошибок используется простая контрольная сумма. Она работает по принципу простого сложения всех байт от всего блока данных для получения конечного значения контрольной суммы. Однако, такой простой принцип очень ограничен: например, нельзя детектировать, был ли добавлены лишние или наоборот, удалены нулевые байты (0x00). Сейчас доступны более подходящие техники, поэтому избегайте простейших контрольных сумм.

Есть два алгоритма, которые стоит упомянуть здесь. Первый хорошо известен как Cyclic Redundancy Check (CRC), который имеет строгие математические свойства и очень быстр. 32-битная версия, называемая CRC-32, используется в стандарте IEEE® 802.3 specification.

Алгоритм Adler-32 несколько менее проверен, чем CRC-32, однако он работает значительно быстрее. Он слаб для очень коротких сообщений (< 100 байт), однако это не составит никаких проблем, если за один раз передавать блок размером 256 байт и более.

5.4 Формат файла firmware

Компиляторы поддерживают самые разнообразные форматы выходных файлов. Самым базовым является бинарный формат (.bin): это простой двоичный образ кода firmware. Некоторые форматы включают в себя дополнительную информацию, такую как адрес линковки (Motorola s-record, Intel® .hex) или отладочную информацию (Executable and Linking Format .elf).

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

5.5 Целевые микроконтроллеры (Target Chips)

Некоторые из чипов семейства AT91SAM имеют разные IP, например для контроллера FLASH. Это означает, что они должны программироваться по-разному; таким образом, некоторые версии кода должны быть написаны для поддержки всех микроконтроллеров. Это уже сделано для серии "Basic" приложений, которые предлагаются компанией Atmel для семейства AT91SAM.

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

Хорошим кандидатом для "первого чипа" выглядит AT91SAM7XC, поскольку он содержит в себе встроенные криптографические акселераторы. Это позволит протестировать как программную, так и аппаратную версии AES (и DES/3DES) без использования для этого двух отдельных микроконтроллеров.

[Ссылки]

1. LibTomCrypt.  
2. OpenSSL Project.
3. Crypto++® Library 5.6.1.
4. Brian Gladman's Home Page. 
5. Безопасная и защищенная реализация бутлоадера.