Разработка программного доверенного загрузчика операционной системы

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

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

Загрузка ОС с неучтенного носителя позволяет злоумышленнику обойти многие из перечисленных выше способов защиты и получить доступ к защищённой информации. В качестве защиты от подобной атаки часто применяется опломбирование системного блока и запрет на работу с неавторизованными носителями информации в рабочем месте, что не является достаточным для гарантированного обеспечения защиты от НСД.

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

Реализация доверенного загрузчика ОС может быть выполнена на аппаратно-программном и программном уровне.

Аппаратно-программная реализация представляет из себя внешнее устройство, подключаемое к контролируемой ЭВМ на шину PCI/PCI-e. Устройству передаёт управление базовая система ввода-вывода в процессе инициализации аппаратной части ЭВМ. Доверенный загрузчик выполняет определённый разработчиком набор функций и, в зависимости от результата их выполнения, разрешает или запрещает загрузку операционной системы или нет.

Недостатком аппаратно-программной реализации является незащищённость устройства при нарушении организационных мер. АПМДЗ может быть удалено с шины PCI ЭВМ, после чего функции доверенной загрузки не будут выполняться.

Программная реализация доверенного загрузчика ОС не требует аппаратных устройств для своего функционирования. Инсталляция ПМДЗ заключается во внедрении программного кода в BIOS целевой ЭВМ. Это позволяет исполнять его до передачи управления из ПЗУ с прошивкой базовой системы ввода-вывода во внешние носители.

В данной работе рассматривается вопрос реализации программного доверенного загрузчика операционной системы.

1. Анализ предметной области

Загрузчик операционной системы - программа, выполняющая подготовку аппаратных средств ЭВМ к работе ОС и загрузку ядра операционной системы. Загрузчик ОС часто устанавливается вместе с операционной системой. В некоторых случаях его функции может выполнять система BIOS, установленная в SPI Flash-носителе.

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

1.1 Понятие и состав доверенного загрузчика операционной системы

Доверенный загрузчик операционной системы - программа, выполняющая подготовку аппаратных средств ЭВМ к работе ОС, аутентификацию пользователя ПК и контроль целостности BIOS, а также загрузку ядра ОС из доверенного носителя информации.

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

На данный момент существуют следующие программные модули доверенной загрузки:

- ViPNet SafeBoot - программный модуль доверенной загрузки, устанавливаемый в UEFI BIOS различных производителей. Поддерживает авторизацию на уровне BIOS и контроль целостности BIOS BIOS. После установки модуля извлечение невозможно. Имеет сертификат соответствия ФСТЭК России требованиям к средствам доверенной загрузки по «Профилю защиты средства доверенной загрузки уровня базовой системы ввода-вывода второго класса защиты»;

- МДЗ-Эшелон - программный модуль доверенной загрузки, устанавливаемый в UEFI BIOS. Совместим с аппаратными платформами семейства Intel x86, поддерживает архитектуру Эльбрус. Имеет сертификат соответствия ФСТЭК России требованиям к средствам доверенной загрузки по «Профилю защиты средства доверенной загрузки уровня базовой системы ввода-вывода второго класса защиты».

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

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

- ПМДЗ должен исполняться до передачи управления во внешние носители информации (оптические диски, FLASH-накопители, НЖМД);

- ПМДЗ должен обеспечивать целостность своего исполняемого бинарного файла и прошивки BIOS;

- ПМДЗ должен обеспечивать функции аутентификации пользователя ЭВМ.

Исходя из первого требования к ПМДЗ, модуль должен быть размещён на внутреннем носителе ЭВМ. Внутренним носителем является ПЗУ на материнской плате, в котором размещён образ BIOS.

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

Второе требование к ПМДЗ обеспечивается реализацией функционала подсчёта контрольных сумм на образ BIOS и ПМДЗ, размещённые в оперативной памяти. Контрольная сумма может быть вычислена по широко применяемым алгоритмам (md5, SHA и др).

Третье требование к ПМДЗ обеспечивается реализацией интерфейса получения от пользователя данных аутентификации и проверки по существующей базе логинов и паролей. В АПМДЗ зачастую данные от пользователя принимаются аппаратным считывателем ключа. При реализации ПМДЗ необходимо проектировать программу с учётом гарантированно имеющихся аппаратных возможностей современных ЭВМ. Аппаратные считыватели ключей и подобные им устройства не могут удовлетворять данному условию.

Схема ПМДЗ, удовлетворяющая предъявленным требованиям, представлена ниже (Рисунок 1).

Рисунок 1. Схема работы доверенного загрузчика ОС

В соответствии с данной схемой, в разработку ПМДЗ входит разработка BIOS для целевой аппаратной платформы. Модуль доверенной загрузки можно представить в виде отдельной исполняемой программы, которая будет размещена на SPI Flash-носителе в составе образа BIOS. Выделение функций МДЗ из BIOS упростит разработку и отладку доверенного загрузчика.

1.2 Понятие аппаратной платформы и критерии выбора целевой аппаратной платформы

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

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

- Актуальность. Аппаратная платформа должна быть востребована российскими разработчиками в сфере информационной безопасности;

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

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

В качестве архитектуры аппаратной платформы была выбрана x86-архитектура процессоров - самая распространённая на рынке на данный момент. Рассматривались процессоры архитектуры Эльбрус (SPARC), MIPS, ARM. Аппаратные платформы с ЦП данных архитектур реже используются российскими разработчиками в сфере информационной безопасности, что делает разработку доверенного загрузчика ОС для данных архитектур менее приоритетной задачей.

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

1.3 Бинарные файлы в составе современных BIOS

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

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

- Прошивка Management Engine firmware. Предназначена для исполнения в микроконтроллере Intel Management Engine (iME), выполняющем задачи по управлению аппаратной платформой, мониторингу ее работы, обслуживанию во время сна и загрузки. Может быть минимизирован путём вырезания незащищённых контрольной суммой регионов, вследствие чего микроконтроллер iME прекращает свою работу после включения ПК.

- Memory Reference Code (MRC) - бинарный файл от фирмы Intel, предназначенный для инициализации оперативной памяти аппаратных платформ на чипсетах Sandy Bridge, Ivy Bridge, Haswell. Не может быть минимизирован и удалён, поддаётся реверс-инжинирингу.

- Intel Firmware Support Package (FSP) - бинарный файл от фирмы Intel для инициализации процессора, контроллеров периферии, памяти и др. Используется аппаратными платформами на чипсетах BayTrail и старше, включает в себя MRC. Не может быть минимизирован и удалён, поддаётся реверс-инжинирингу.

- VGA BIOS - бинарный файл для инициализации встроенного в ЦП графического процессора. Может быть удалён в случае использования внешней видеокарты.

- Microcode - бинарный файл, содержащий реализацию CISC-инструкций процессора. Зашифрован 2048-битным RSA-ключом для невозможности реверс-инжиниринга процессорной логики. Может быть удалён в случае, если ОС и ПО не используют CISC-инструкций процессора. Не поддаётся реверс-инжинирингу.

- Gigabit Ethernet Firmware - бинарный файл, предназначенный для инициализации встроенного Ethernet-контроллера. Может быть удалён в случае, если внутренний Ethernet-контроллер не используется.

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

1.4 Выбор программной платформы для разработки BIOS

Разработка базовой системы ввода-вывода на текущий момент может быть выполнена с использованием специализированных платформ, предоставляющих средства для сборки и отладки образа BIOS. Как правило, в их состав входит программный код для начальной инициализации ЭВМ различных архитектур, набор вспомогательных утилит. Рассмотрим современные библиотеки и платформы для разработки BIOS:

- EDK II - платформа с открытым исходным кодом для разработки прошивок BIOS типа UEFI (Unified Extensible Firmware Interface) для процессорных архитектур x86, x64, ARM. Платформа имеет поддержку фирмы Intel, а также используется в продуктах данной компании: проект Tianocore, созданный разработчиками из Intel с помощью EDK II, применяется в качестве стандартной прошивки BIOS для плат Intel Minnowboard и Intel Galileo. EDK II поддерживает разработку и отладку из IDE MS Visual Studio

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

- Coreboot - платформа с открытым исходным кодом для разработки прошивок BIOS типа Legacy и UEFI для процессорных архитектур x86, x64, ARM, MIPS, SPARC [2]. Платформа имеет поддержку фирмы Google, а также используется в продуктах данной компании: прошивка, выполненная средствами проекта Coreboot, является стандартным BIOS для ноутбуков Google с операционной системой Chrome OS.

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

- Libreboot - платформа с открытым исходным для разработки прошивок BIOS типа Legacy и UEFI для платформ x86, x64, ARM. Разработчики данной платформы используют исходный код Coreboot, отличием является отказ от бинарных файлов в составе прошивок BIOS. Это является недостатком платформы, т.к. современные BIOS для материнских производителей Intel и AMD содержат большое число бинарных вставок. Их полная замена может быть проведена с помощью дизассемблирования, что серьёзно замедляет разработку и не позволяет создавать прошивки BIOS для современных аппаратных платформ.

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

Платформа Libreboot не позволяет разрабатывать BIOS для современных платформ ввиду полного отказа от бинарных файлов в составе прошивки. По этой причине данный проект не был выбран для разработки BIOS в рамках ВКР.

Платформа EDK II использует при построении прошивки BIOS большое количество бинарных файлов, что увеличивает вероятность присутствия опасных функциональных конструкций в составе прошивки. По этой причине данный проект не был выбран для разработки BIOS в рамках ВКР.

В результате анализа предметной области была определена структура программного модуля доверенной загрузки операционной системы: в SPI FLASH необходимо поместить прошивку BIOS и модуль доверенной загрузки.

Разработка BIOS возможна с использованием одной из нескольких специализированных платформ. В рамках ВКР был выбран проект Coreboot в качестве программной платформы для разработки BIOS.

В качестве производителя аппаратной платформы выбрана фирма Intel. Продукты данного производителя в большом количестве присутствуют на рынке, что делает разработку ПМДЗ для материнской платы данного производителя актуальной задачей. Целевой аппаратной платформой была выбрана линейка процессоров Intel Haswell, выполненных на системной логике Intel PCH. Платформа является достаточно современной и присутствует на рынке, при этом для разработки BIOS не потребуется использовать большое количество бинарных файлов.

В качестве целевой материнской платы была выбрана Asus H87_PLUS _ материнская плата с процессором Intel линейки Haswell. Данная материнская плата имеет широкий набор интерфейсов, что позволяет протестировать корректность инициализации BIOS аппаратных средств ЭВМ.

2. Разработка модулей BIOS

Разработка BIOS заключается в разработке отдельных модулей для целевой аппаратной платформы с целью обеспечения её полной функциональности. Это обусловлено небольшим количество изменений в базовой системе ввода-вывода относительно развития аппаратных платформ.

В качестве производителя аппаратной платформы выбрана фирма Intel. Продукты данного производителя в большом количестве присутствуют на рынке, что делает разработку ПМДЗ для материнской платы данного производителя актуальной задачей. Целевой аппаратной платформой была выбрана линейка процессоров Intel Haswell, выполненных на системной логике Intel PCH. Платформа является достаточно современной и присутствует на рынке, при этом для разработки BIOS не потребуется использовать большое количество бинарных файлов.

2.1 Модуль материнской платы

Разработка BIOS на платформе Coreboot началась с создания модуля материнской платы.

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

В файлы с настройками была включена общая информация для платформы Coreboot. Сюда входит конфигурация материнской платы (количество центральных процессоров, размер SPI FLASH, информация об аппаратной платформе и Super I/O), список файлов для подключения на этапе компиляции.

Наиболее важным файлом настройки является файл дерева устройств - devicetree.cb. В данном файле производится настройка шины PCI (подключение существующих устройств для их функционирования), ACPI и Super I/O [3].

ACPI - интерфейс управления питанием ЭВМ и конфигурацией материнской платы. Представляется в виде набора таблиц (статических и динамических), описывающих работу аппаратных средств ПК. Таблицы составлены на языке AML (ACPI Machine Language) и могут быть получены из оригинального BIOS с помощью ряда утилит (UEFITool, UefiParser).

В файле devicetree.cb необходимо самостоятельно заполнить настройки ACPI в соответствии с документацией к материнской плате. Наибольший интерес представляет настройка чипа Super I/O, отвечающего за работу устройств по низкоскоростным интерфейсам (SPI, COM, PS/2) в составе материнской платы. Устройствам соответствуют значение io и irq:

io - номер порта, по которому можно сообщаться с устройством;

irq - номер прерывания в таблице прерываний, установленный устройству.

Пример инициализации устройства, управляемого чипом Super I/O:

# Последовательный порт 1

device pnp 2e.2 on

io 0x60 = 0x3f8

irq 0x70 = 4

end

2.2 Шина LPC

Шина Low Pin Count (LPC) используется для сообщения с широким набором интерфейсов на материнской плате (COM, PS/2 и др.). За взаимодействие ЦП с внешними устройствами по данной шине на современных материнских платах отвечает чип Super I/O. Корректная настройка шины LPC и чипа Super I/O необходимо для обеспечения отладки загрузчика по COM-порту (вывод текстовых сообщений в консоль) и 80 порту на шине PCI (отладочный порт для вывода POST-кодов).

Инициализация со стороны PCH (Platform Controller Hub) заключается в поиске чипа Super I/O на шине PCI и отправке ему нужных параметров. Местонахождение Super I/O указано в дереве устройств, настроенном ранее (2.1). В числе параметров указываются настройки буфера для COM-порта, набор используемых периферийных устройств, специальных разъёмов (GPIO) и т.д. Конкретные значения этих параметров можно узнать в документации на используемый PCH.

Чипы Super I/O имеют общий интерфейс взаимодействия с PCH, но разное внутреннее устройство. Платформа Coreboot поддерживает использование чипов Super I/O фирм Winbond, Nuvoton, SMSC, Fintek и др., имеется возможность написать собственную инициализацию для необходимого Super I/O. На материнской плате Asus H87-PLUS используется Super I/O 6971d.

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

2.3 PC Speaker

PC Speaker - низкокачественное устройство воспроизведения звука, присутствующее на большинстве существующих материнских плат [5].

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

Управление PC Speaker на материнской плате H87-PLUS производится с помощью программируемого таймера I82C54, генерирующего звуковую волну на заданной частоте. Взаимодействие с PC Speaker устанавливается по порту 0x61 и заключается в записи управляющих «слов» в порты таймера и PC Speaker.

Функция speaker_tone() принимает в качестве параметров ожидаемую частоту в герцах и длину сигнала в миллисекундах. В функции speaker_enable() управляющие «слова» отправляются в порты таймеров и, после их настройки, в порт PC Speaker направляется «слово» его включения на заданной частоте. Длительность сигнала достигается путём приостановки исполняемой нити на переданную в параметре величину. Перед завершением функции speaker_tone() происходит выключение PC Speaker.

3. Разработка модуля доверенной загрузки

Модуль доверенной загрузки представлен в виде программы на языке Си. Файловая система Coreboot FileSystem позволяет встроить модуль доверенной загрузки в образ BIOS, после чего он может быть найден в момент исполнения базовой системы ввода-вывода и принять управление.

В рамках выполнения выпускной квалификационной работы было принято решение запретить загрузку со всех внешних носителей ЭВМ ввиду сложности реализации «белого списка» доверенных носителей. Разрешение загрузки только с портов SATA, расположенных внутри опломбированного корпуса ЭВМ является решением проблемы и может считаться доверенным источником информации, но было принято решение изучить возможность организации доверенного загрузчика ОС без НЖМД.

Ввиду установленных условий (отказ от внешних носителей, в том числе НЖМД по SATA, а также отсутствие специальных аппаратных средств), при проектировании и реализации ПМДЗ имелась возможность использовать следующие типы памяти для хранения информации:

1. SPI Flash- накопитель на материнской плате (не может быть изменён во время исполнения BIOS);

2. Энергонезависимая память CMOS, питаемая от специальной батареи (будет потеряна при выходе из строя батареи). [1]

3.1 Аутентификация пользователя

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

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

В начале работы программа принимает пользовательские данные. Логин и пароль считываются путём посимвольного чтения из буфера клавиатуры (доступ к нему осуществляется посредством прерывания INT 16H). На длину логина и пароля установлено ограничение в восемь символов, после достижения которых введённое значение принимается за конечное. Введена проверка на пустые логин и пароль. Пользовательские данные размещаются в структуре user, внутри которой располагаются два символьных буфера с динамически определяемым размером.

Рисунок 2. Алгоритм работы модуля доверенной загрузки

База пользователей не может быть размещена на НЖМД в следствие отказа от их использования. Присутствуют два варианта размещения базы пользователей:

- Размещение в энергонезависимой памяти CMOS.

Достоинством данного способа является возможность организации изменения логина и пароля, ввода новых пользователей. Недостатком являются ненадёжность хранения данных (в случае выхода из строя батареи база пользователей будет утеряна) и ограничение по размеру (256 байт). Кроме того, часть памяти задействуется BIOS под свои нужды (хранение даты и времени ПК), из-за чего размер доступной памяти становится меньше.

- Размещение в SPI Flash-носителе.

Достоинством данного способа является гарантия сохранения базы пользователей в ПЗУ и независимость от подачи питания. ПЗУ имеет большой объём, достаточный для размещения данных о большом количестве пользователей. В дальнейшем это позволит ввести дополнительные поля с правами пользователей и т.д.

Недостатком является невозможность изменить данные пользователей. При компрометации аккаунта и использовании аппаратной защиты от перезаписи SPI Flash-носителя потребуется покупка новой материнской и записи в её ПЗУ образа доверенного загрузчика ОС с новой базой пользователей.

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

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

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

3.2 Контроль целостности прошивки доверенного загрузчика

Контроль целостности - процесс подтверждения отсутствия модификаций в контролируемом файле.

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

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

В модуле безопасности была реализована функция crc32 - наиболее распространённой функции контроля целостности. За основу был взят алгоритм быстрой функции crc32 Ричарда Блэка, написанный в 1994 году [4]. Алгоритм представлен ниже (Рисунок 3).



Рисунок 3. Алгоритм вычисления контрольной суммы

Доверенный загрузчик ОС выполняет контроль целостности до начала аутентификации пользователя. Контролю целостности подвергается весь образ доверенного загрузчика, записанный в ПЗУ, кроме последних четырёх байтов - в эту позицию записывается полученная контрольная сумма. Содержимое SPI Flash-носителя проецируется в оперативную память (старшие 16 Мбайт), откуда и копируется в буфер с исходными данными для функции crc32.

3.3 Защита от перезаписи

Запрет модификации программного доверенного загрузчика ОС может быть осуществлён путём реализации защиты от перезаписи SPI Flash-носителя. Защита носителя на материнской плате, принадлежащей к аппаратной платформе фирмы Intel, может быть выполнена на аппаратном уровне с использованием технологии Intel Boot Guard.

Intel Boot Guard - технология фирмы Intel, позволяющая считать контрольную сумму на содержимое ПЗУ до его исполнения. Реализован данный механизм с помощью микроконтроллера Intel Management Engine, выполняемый до передачи управления на RESET-вектор, и аппаратно-изолированной области памяти, доступной только этому микроконтроллеру.

Принцип работы технологии базируется на записи в аппаратно-изолированную область памяти хэш ключа проверки подписи регионов BIOS и конфигурации Intel Boot Guard. Запись выполняется контроллеров Intel Management Engine при попытке запуска ЭВМ. После обновления памяти читается конфигурации Intel Boot Guard и считается контрольная сумма на регионы BIOS. В том случае, если контрольная сумма или хэш ключа не совпали, система выполняет поведение, указанное в настройках Intel Boot Guard: продолжение работы, немедленное выключение, выключение через определённый промежуток времени.

Редактирование настроек производится в программе Intel Flash Image Tool. Он позволяет отредактировать дескриптор BIOS (стандартный регион в BIOS фирмы Intel, содержащий опции конфигурации аппаратного обеспечения и средств Intel), в том числе сменить хэш ключа для подписи регионов BIOS и выставить настройки Intel Boot Guard таким образом, чтобы при несовпадении контрольных сумм система не совершала загрузку. В таком случае изменённый хэш ключа окажется в аппаратно-изолированной памяти навсегда. Смена ключа программатором невозможна, так как запись в область доступна только микроконтроллеру Intel Management Engine. Хэш ключа высчитывается по SHA256 от регионов BIOS.

Платформа Coreboot предоставляет возможность включить в состав прошивки BIOS дескриптор Intel и, таким образом, осуществить аппаратную защиту от перезаписи в SPI FLASH.

3.4 Доверенная загрузка ОС

Доверенная загрузка ОС - загрузка ядра операционной системы с носителя информации, внесённого авторизованным пользователем в список доверенных носителей.

Доверенным носителем может считаться носитель любого типа: НЖМД, соединённый с ЭВМ по интерфейсу SATA, оптический диск, USB Flash-накопитель. Пользователь, обладающий достаточными полномочиями, должен иметь возможность включить и исключить из списка доверенных носителей отдельные устройства. АПМДЗ часто предоставляют возможность указать загрузочный сектор устройства и применять к нему контроль целостности.

Сложность организации списка доверенной загрузки в ПМДЗ заключается в невозможности пользоваться дополнительными аппаратными средствами. Список доверенных носителей может быть размещён в CMOS, но утерян при выходе из строя батареи CMOS или её отсутствия на материнской плате. В ПЗУ список разместить нельзя ввиду невозможности модификации содержимого микросхемы.

В рамках выпускной квалификационной работы было принято решение сократить список доверенных носителей до SPI Flash. Так как микросхема ПЗУ защищена от перезаписи и подвергается контролю целостности, она гарантированно является доверенным носителем информации.

Загрузка операционной системы из ПЗУ возможна с использованием загрузочной дискеты дистрибутива ОС. Образ загрузочной дискеты занимает не больше 1,44 Мбайта и может быть включён в состав доверенного загрузчика путём добавления в файловую систему CBFS. Coreboot поддерживает сжатие добавляемых файлов по алгоритму LZMA и существенно уменьшить объём загружаемого образа. Поиск во время исполнения модуля безопасности происходит по тегу «floppyimg/», позволяющий получить список загрузочных дискет, включённых в образ прошивки загрузчика, из общего числа включённых файлов. На этапе загрузки, когда аппаратная часть ЭВМ инициализирована, управление передаётся загрузчику ОС в образе загрузочной дискеты.

В качестве операционной системы для загрузки из доверенного загрузчика была выбрана KolibriOS. ОС имеет графический интерфейс и набор встроенного ПО (офисное, сетевое, мультимедиа), его можно расширить путём добавления программ в образ загрузочной дискеты. Образ загрузочной дискеты после сжатия по алгоритму LZMA составляет 1,26 Мбайта.

Работа ЭВМ с установленной в SPI Flash-носитель операционной системой не требует внешних носителей информации, для работы необходимы центральный процессор, материнская плата и набор периферийных устройств. Содержимое ПЗУ нельзя изменить, поэтому для хранения данных необходимо использовать внешние носители информации.

4. Тестирование доверенного загрузчика

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

4.1 Отладка доверенного загрузчика

На этапе разработки очень важно проводить тестирование и отладку написанной программы. В случае с отладкой прикладной программы можно использовать встроенные решения в используемых средах разработки. Программа исполняется на ПК с целевой архитектурой, зачастую внутри специальной виртуальной машины. Отладка доверенного загрузчика усложняется тем, что после каждого изменения в исходном коде необходимо обновлять прошивку BIOS в SPI Flash-носителя отлаживаемой материнской платы.

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



Рисунок 4. Эмуляция в эмуляторе QEMU

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

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

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

В QEMU была проведена отладка операционной системы KolibriOS из ПЗУ. QEMU считывает данные с периферийных устройств, что позволило взаимодействовать с ОС с помощью мыши и клавиатуры.

Так как эмулятор QEMU не способен максимально точно воспроизвести целевую аппаратную платформу, после завершения основных работ отладка была проведена на реальной материнской плате. Сообщения отладки были получены через COM-порт по интерфейсу UART, POST-коды считаны специальной POST-платой с порта 80 шины PCI.

4.2 Тестирование BIOS

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

- Тестирование оперативной памяти.

Данный тест проводился с помощью утилиты Memtest86 -программы для проверки ОЗУ на ЭВМ с x86- и x64-битной архитектурой. Программа не требует инсталляции и может быть запущена с внешнего носителя после инициализации BIOS. Для проведения тестирования образ Memtest86 был временно записан в прошивку программного модуля доверенной загрузки операционной системы и запущен из SPI FLASH. Пример использования утилиты представлен ниже (Рисунок 5).

Рисунок 5. Работа утилиты Memtest86

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

Тестирование на ЭВМ с материнской платой Asus H87-PLUS проводилось в течение шести часов, при этом ни одной ошибки обнаружено не было. Это свидетельствует о корректной инициализации оперативной памяти.

- Тестирование COM-интерфейса.

Данный тест проводился с помощью утилиты для Linux Minicom, позволяющий обмениваться данными между через COM-порты по интерфейсу UART. Для тестирования в прошивке BIOS была включена опция «ENABLE DEBUG CONFIG», которая приводит к отправке большого количества отладочных сообщений при загрузке ЭВМ по интерфейсу UART. Вся переданная при включении материнской платы информация была успешно получена и выведена в консоль утилиты Minicom (Рисунок 6).

Рисунок 6. Работы утилиты Minicom

- Тестирование интерфейсов PCI/PCI-e.

Данный тест проводился с использованием аппаратных плат с разъёмами для данных портов:

a. Видеокарта (разъём PCI). При подключении к любому из портов на шине PCI материнской платы видеокарта передаёт видеосигнал на подключенный к ней монитор. Это свидетельствует о корректности работы шины PCI;

b. Ethernet-контроллер (разъём PCI-e). Тест проводился с использованием утилиты для Linux ping, позволяющей проверить качество соединения. В течение четырёх часов тестировалась связь с целевой материнской платой по сетевому кабелю, ни одной ошибки не было обнаружено. Это свидетельствует о корректности работы шины PCI-e.

- Тестирование Ethernet-контроллера.

Тест проводился с использованием утилиты для Linux ping, позволяющей проверить качество соединения. В течение четырёх часов тестировалась связь с целевой материнской платой по сетевому кабелю, ни одной ошибки не было обнаружено. Это свидетельствует о корректности работы встроенного Ethernet-контролера.

4.3 Тестирование модуля безопасности

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

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

Проверка контроля целостности была проведена с изменением битов в образе BIOS. Были изменены биты в области данных, пустой области, файле с логинами и паролями. Модуль безопасности сигнализировал об изменении в образе BIOS и прекращал загрузку ОС. В ряде случаев загрузка прерывалась ещё на стадии выполнения BIOS.

Проверка загрузки ОС из доверенного носителя информации была проведена с подключением различных внешних устройств с предустановленными операционными системами и попыткой произвести загрузку не из доверенного носителя. Внешние носители информации (HDD, USB FLASH, DVD) не видны в списке носителей информации, загрузку осуществить не удалось.

5. Руководство пользователя

В данном руководстве будут рассмотрены вопросы инсталляции и эксплуатации доверенного загрузчика операционной системы.

5.1 Инсталляция

Инсталляция доверенного загрузчика операционной системы проводится с помощью специального устройства для перезаписи SPI Flash_носителя (программатора).

Отключите материнскую плату от источника питания. На материнской плате найдите носитель типа SPI Flash. Существует два распространённых вида размещения носителя на материнской плате:

Носитель размещён в специальном сокете (Рисунок 7). Необходимо извлечь SPI Flash-носитель из сокета и записать в него доверенный загрузчик по приведённой ниже инструкции. При возврате носителя в сокет обратите внимание на «ключ» - выемку в сокете. На одном из концов SPI Flash-носителя также находится выемка, которая поможет правильно разместить SPI Flash-носитель на место.

Рисунок 7. SPI Flash-носитель в специальном сокете

Носитель припаян к материнской плате (Рисунок 8). В этом случае не пытайтесь извлечь SPI Flash_носитель из материнской платы. Подключите выходы программатора поверх выходов SPI Flash_носителя согласно инструкции, приведённой ниже.

Рисунок 8. SPI Flash-носитель припаян к плате

Для записи прошивки в SPI Flash_носитель требуется подключить выходы программатора к выходам накопителя согласно схеме подключения ISP-кабеля (Рисунок 9). На SPI Flash_носителе присутствует «ключ» - выемка, которая поможет правильно определить ориентацию носителя и подключиться к выходам в верном порядке.

Рисунок 9. Схема подключения ISP-кабеля

Убедитесь, что SPI Flash_носитель и программатор работают с одним напряжением во избежание порчи носителя. Рабочее напряжение носителя можно узнать по маркировке на корпусе. Чтобы сменить напряжение программатора, может потребоваться не только изменить настройки, но и сменить прошивку устройства. После этого следуйте документации вашего программатора, чтобы записать прошивку доверенного загрузчика в SPI Flash-носитель.

После успешной записи отсоедините программатор от носителя и установите SPI Flash-носитель в сокет в том случае, если он не припаян к материнской плате. Подайте питание и включите ЭВМ.

5.2 Эксплуатация

Для начала эксплуатации необходимо подать сигнал включения компьютера. Через некоторое время на экране возникнет сообщение о необходимости ввода логина (Рисунок 10).

Рисунок 10. Окно ввода логина

Ввод необходимо производить с клавиатуры. Для того, чтобы окончить ввод, необходимо нажать клавишу «Enter». После этого появится аналогичное сообщение с требованием ввести пароль (Рисунок 11). Максимальная длина логина и пароля - 8 символов.



Рисунок 11. Окно ввода пароля

В случае ошибочного ввода будет выведено сообщение о необходимости повтора ввода и количестве оставшихся попыток (Рисунок 12).

Рисунок 12. Окно повторного ввода данных

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



Рисунок 13. Окно загрузки из выбранного источника

Доверенный загрузчик операционной системы имеет только один источник загрузки - SPI FLASH с предустановленной операционной системой. При успешной загрузке появится окно с настройками операционной системы (Рисунок 14).

Рисунок 14. Окно настроек операционной системы

Рекомендуется выставить все настройки в значение «по умолчанию» и нажать «Enter» для начала загрузки ОС. Когда операционная система будет загружена, на экране появится рабочий стол ОС. ЭВМ готова к работе (Рисунок 15).



Рисунок 15. Окно загруженной операционной системы

Заключение

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

Программа исполняется до передачи управления внешним носителям и, в случае использования аппаратной блокировки, точно не может быть модифицирована. В процессе выполнения работы была реализована возможность встраивания образа операционной системы в состав доверенного загрузчика и записывать её в SPI Flash-носитель, что позволяет гарантированно загрузить ОС из доверенного источника и не передавать управление во внешние носители. В таком случае ПМДЗ можно представить в виде замкнутой системы, готовой к работе без внешних носителей.

Доверенный загрузчик операционной системы может быть улучшен путём проведения реверс-инжиниринга бинарных файлов в составе BIOS для достижения максимального объёма программного кода в исходном виде. Улучшить доверенный загрузчик может ввод авторизации пользователей с разными правами, меню с рядом настроек BIOS. Результаты работы могут быть использованы для разработки аналогичного программного продукта для других аппаратных платформ.

Литература

1. Darmawan Salihun. «BIOS. Дизассемблирование, модификация, программирование». 2006 г.

2. Coreboot Developer Manual. [Электронный ресурс]. - Электрон.дан. - URL: https://www.coreboot.org/Developer_Manual - 03.02.2018 г.

3. Vincent Zimmer. «Embedded Firmware Solutions». 2015 г.

4. Richard Black. [Электронный ресурс]. - Электрон.дан. - URL: http://www.cl.cam.ac.uk/research/srg/bluebook/21/crc/crc.html - 18.02.1994 г.

5. Функциональные узлы системной платы IBM PC-совместимого компьютера. [Электронный ресурс]. - Электрон.дан. - URL. - http://kaf401.rloc.ru/DSP/systdevprog.htm - 05.11.2006 г.

Приложение А

Файл secure.c

#include "../malloc.h"

#include "secure.h"

#include "realloc.h"

#include "../hw/rtc.h" // CMOS options

#include "../romfile.h"

#include "defs.h"

//Основная функция безопаности

int

secure_func(void)

{

int entries_count;

int try_count = 4;

struct Entry** entry;

struct Entry* user;

int id;

entry = get_entries(&entries_count);

if(entry == NULL)

{

printf("\nUser's data is not found. BOOT IS ABANDONED\n");

return -1;

}

print_cmos();

while(try_count){ // %try_count% попыток входа в систему

user = login_screen(); //Запрос данных о пользователе

id = authentification(entry, entries_count, user); //Проверка корректности введённых данных

if( id != -1)

{

printf("\nHello, %s!", entry[id]->login);

return 0;

}

else

{

try_count--;

printf("\nNo any %s in system. Try again\n", user->login);

printf("\n%d tries remaining\n", try_count);

}

}

return -1;

}

void

print_cmos()

{

printf("\n\nCMOS:\n");

for( int i = 0; i < 256; i++)

{

printf("%0d ", rtc_read(i));

}

printf("\n");

}

//Окно авторизации пользователя

struct Entry*

login_screen()

{

int* login_len;

int* password_len;

struct Entry* user;

//Выделение памяти под данные

login_len = (int*)malloc_low(sizeof(int));

password_len = (int*)malloc_low(sizeof(int));

user = (struct Entry*)malloc_low(sizeof(struct Entry));

user->login = (char*)malloc_low(sizeof(char) * MAX_USER_LEN);

user->password = (char*)malloc_low(sizeof(char) * MAX_PASSWORD_LEN);

//Получение данных от пользователя

printf("Atlas Secure System.\n");

printf("Authentification:");

while(1){

printf("\nuser: ");

scan_string(user->login, MAX_USER_LEN, login_len); //Get string

if(*login_len == 0){

printf("\nField 'user' can't be empty! Try again...\n\n");

}else{

break;

}

}

while(1){

printf("\npassword: ");

scan_string(user->password, MAX_PASSWORD_LEN, password_len);

if(*password_len == 0){

printf("\nField 'password' can't be empty! Try again...\n\n");

}else{

break;

}

}

#ifdef SECURE_WITH_DEBUG

printf("\n\nReceived:");

printf("\nlogin: '%s'", user->login);

printf("\npassword: '%s'", user->password);

#endif

return user;

}

//Scan one string

void

scan_string(char* string, const int MAX_STRING_LEN, int* string_len)

{

int scan_code; // One keystroke

char symbol;

*string_len = -1;

while(*string_len <= (MAX_STRING_LEN-1))

{

scan_code = get_keystroke(30);

if(scan_code == -1) //No any keystroke found

{

continue;

}

else if (scan_code == CODE_ENTER)

{

(*string_len)++;

memcpy(string + *string_len, "\0", sizeof(char)); //End of line

return;

}

else if(scan_code <= KEYBOARD_LEN)

{

(*string_len)++;

symbol = parse_scan_code(scan_code);

memcpy(string + *string_len, &symbol, sizeof(symbol));

printf("%c",symbol);

}

}

}

//Сравнение строк

int

compare_string(char* str1, const char* str2, int cmp_len)

{

for(int i = 0; i < cmp_len; i++)

{

if(str1[i] != str2[i])

return -1;

}

return 0;

}

//Извлечение символа из скан-кода клавиши на клавиатуре

char

parse_scan_code(int scan_code)

{

char table[64] = "__1234567890-+__qwertyuiop{}__asdfghjkl;'___zxcvbnm<>?";

return table[scan_code];

}

//Функция аутентификации

int

authentification(struct Entry** entry, int entry_count, struct Entry* user)

{

int i = 0;

for(i = 0; i < entry_count; i++)

{

//Проверка пользователя

if(strcmp(entry[i]->login, user->login) || strcmp(entry[i]->password, user->password) )

{

continue;

}

return i;

}

return -1;

}

//Формируем аккаунты пользователей

struct Entry**

get_entries(int* entries_count)

{

int romfile_len = 0;

char* romfile_data;

// Try to get our option.rom with user data

romfile_data = romfile_loadfile("entries.rom", &romfile_len);

if(romfile_data == NULL)

{

return NULL;

}

printf("entries.rom is found! Contains:\n%s\n", romfile_data);

// Проверка корректности считанного rom

if(is_entries_correct(romfile_data, romfile_len) != 0)

{

return NULL;

}

printf("entries.rom is correct!\n");

*entries_count = get_entries_count(romfile_data, romfile_len);

printf("%d entries found\n", *entries_count);

// Формирование данных пользователей

for(int i = 0; i < *entries_count; i++)

{

get_entry(i, romfile_data, romfile_len);

}

return NULL;

}

// Проверка того, что option.rom содержит корректные данные

int

is_entries_correct(char* romfile_data, int romfile_len)

{

const int SIGN_BEGIN_OFFSET = 0;

const int SIGN_END_OFFSET = romfile_len - SIGN_END_LEN;

const int MIN_ROMFINE_LEN = SIGN_BEGIN_LEN + SIGN_END_LEN + 4;

if (romfile_len < MIN_ROMFINE_LEN) // Проверка соответствия длины данных минимальным логину и паролю

return -1;

if( 0 != compare_string(romfile_data + SIGN_BEGIN_OFFSET, SIGN_BEGIN, SIGN_BEGIN_LEN) )

return -1;

if( 0 != compare_string(romfile_data + SIGN_END_OFFSET, SIGN_END, SIGN_END_LEN) )

return -1;

return 0;

}

//Вычисление количества аккаунтов в option.rom

int

get_entries_count(char* romfile_data, int romfile_len)

{

const int DATA_OFFSET = SIGN_BEGIN_LEN;

const int DATA_END_OFFSET = romfile_len - SIGN_END_LEN;

int partition_code;

int count = 0;

int partition_write_permission = 1;

if(romfile_data[DATA_OFFSET] != '%')

return -1;

partition_code = PART_LOGIN_SIGN;

// Обход всей информации

for(int i = DATA_OFFSET+1; i < DATA_END_OFFSET; i++)

{

if ( (romfile_data[i] == '%') && ( (partition_code == PART_LOGIN_SIGN) || (partition_code == PART_PASSWORD_SIGN)) ) // Ошибка в бинарном файле с данными

return -1;

if( (romfile_data[i] != '%') && partition_write_permission) // После сигнатуры имеем полезную информацию

{

partition_code++;

partition_write_permission = 0;

}

else if(romfile_data[i] == '%') // Встретилась новая сигнатура

{

if(partition_code == PART_PASSWORD)

...