"We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions

Основная информация

• ID статьи: 2503.08053
• Название: "We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions
• Авторы: Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Kai Kaufman, Md Armanuzzaman, Xi Tan, Katherine Jesse, Robert J. Walls, Ziming Zhao
• Категория: cs.CR (Криптография и безопасность)
• Время публикации/Конференция: ACM SIGSAC Conference on Computer and Communications Security (CCS '25)
• Ссылка на статью: https://arxiv.org/abs/2503.08053

Аннотация

Микроконтроллерные системы являются неотъемлемой частью повседневной жизни, обеспечивая работу критически важных приложений в автомобилях, медицинских устройствах и системах промышленного управления. Данное исследование анализирует полный жизненный цикл разработки защищённых микроконтроллерных систем с технической и когнитивной точек зрения, основываясь на анализе представленных работ команд и постконкурсных интервью из соревнований MITRE Embedded CTF (eCTF) в 2023 и 2024 годах. Исследование выявило две категории проблем: концептуальные (трудности при переходе с микропроцессорных систем на микроконтроллерные, недостаточное понимание специфичных для микроконтроллеров атак) и практические (ограниченная поддержка языков с безопасностью памяти, таких как Rust, на микроконтроллерах; низкокачественные источники энтропии, ослабляющие криптографическую безопасность и генерацию ключей). Исследование предоставляет целевые рекомендации для исследователей, разработчиков, поставщиков и преподавателей.

Исследовательский контекст и мотивация

1. Исследовательский вопрос

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

2. Значимость проблемы

• Широкое применение: Микроконтроллеры управляют автомобилями, медицинскими устройствами, системами промышленного управления и другими критическими системами
• Уязвимость безопасности: Отсутствие стандартных функций безопасности, таких как MMU; программирование на C/ассемблере часто приводит к ошибкам памяти
• Физическая доступность: По сравнению с персональными компьютерами более подвержены атакам по побочным каналам и атакам внедрения ошибок

3. Ограничения существующих подходов

• Препятствия закрытого исходного кода: Реальные прошивки сложно получить и анализировать
• Однобокий подход: Только технический анализ без учёта когнитивных процессов и решений разработчиков
• Отсутствие полного жизненного цикла: Невозможно отследить эволюцию уязвимостей от проектирования к реализации

4. Исследовательская мотивация

Благодаря уникальной перспективе соревнований eCTF исследовательская группа может:

• Получить доступ к полному исходному коду, документации и инструментам сборки
• Объединить технический анализ с интервью разработчиков
• Наблюдать практики безопасности ранних исследователей для улучшения образования
• Выявить системные и эмпирические проблемы безопасности

Основные вклады

1. Методологическое инновация: Предложен подход к исследованию проблем безопасности микроконтроллерных систем через соревнования CTF, объединяющий технический анализ и когнитивную перспективу полного жизненного цикла разработки
2. Двойная классификационная схема вызовов: Систематически выявлены и классифицированы концептуальные вызовы (пробелы в знаниях) и практические вызовы (ограничения инструментов/ресурсов)
3. Эмпирические находки:
   • Концептуальные вызовы: недостаточное применение фундаментальных механизмов безопасности (разделение привилегий, стирание памяти, защита стека); трудности адаптации платформы; слабое осознание защиты от аппаратных атак
   • Практические вызовы: ограниченная поддержка языков с безопасностью памяти; отсутствие высококачественных источников энтропии
4. Практические рекомендации: Девять конкретных рекомендаций для пяти категорий заинтересованных сторон (исследователи, поставщики, преподаватели, разработчики, разработчики компиляторов)
5. Ресурсы данных: Анализ 47 представленных работ команд (20 из 2023 года, 27 из 2024 года), проведено 22 глубоких интервью

Подробное описание методологии

Определение задачи

Цель исследования — выявить и понять проблемы безопасной разработки микроконтроллерных систем, включая:

• Входные данные: Представленные работы команд eCTF (исходный код, документация, инструменты сборки) + данные интервью участников
• Выходные данные: Классификация проблем безопасности, анализ корневых причин, рекомендации по улучшению
• Ограничения: Фокус на среде соревнований, ориентированной на безопасность; участники — разработчики на ранних этапах карьеры

Исследовательская архитектура

1. Анализ представленных работ (Submission Analysis)

Источники данных:

• 2023 год: 20 команд, использующих плату TI TM4C123GXL (ARM Cortex-M4F)
• 2024 год: 27 команд, использующих плату Analog Devices MAX78000FTHR (ARM Cortex-M4 + RISC-V)

Измерения анализа:

• Инструменты сборки: Языки программирования, компиляторы, уровни оптимизации, флаги безопасности компиляции, свойства скриптов связывания
• Исходный код: Использование git diff для отслеживания изменений, проверка встроенного ассемблера, операций с памятью, генерации случайных чисел, кода, связанного с синхронизацией
• Дизассемблирование: Проверка влияния оптимизации компилятора на функции безопасности
• Анализ во время выполнения: Использование инструментов отладки для проверки неопределённостей статического анализа

Ключевые контрольные точки:

• Разделение привилегий (конфигурация MPU)
• Реализация стирания памяти (проблемы оптимизации memset)
• Включение защиты стека (stack canary)
• Конфигурация неисполняемого стека
• Защита от аппаратных атак (побочные каналы, внедрение ошибок, физическое вмешательство)
• Качество источника энтропии

2. Интервью участников (Participant Interviews)

Характеристики выборки (n=22):

• Образовательный уровень: 12 студентов бакалавриата, 6 студентов магистратуры, 4 студента докторантуры
• Опыт курсов безопасности: 8 человек без опыта курсов безопасности
• Опыт встроенных систем: 14 человек с опытом разработки встроенных систем

Дизайн интервью:

• Полуструктурированные интервью, продолжительность 42-107 минут (в среднем 69 минут)
• Вопросы основаны на повторяющихся проблемах из анализа представленных работ
• Исследование когнитивных аспектов (знания, неправильные представления) и решений (приоритеты, компромиссы)

Анализ данных:

• Транскрипция с использованием Otter AI и ручная проверка
• Независимое открытое кодирование тремя исследователями
• Итеративная разработка кодовой книги: 8 основных тем, 40 подтем, 278 кодов
• Совместное разрешение конфликтов кодирования без необходимости формальной проверки надёжности

Технические инновационные моменты

1. Двусторонний методологический подход: Впервые объединены крупномасштабный анализ кода и глубокие интервью для раскрытия "что" и "почему"
2. Перспектива полного жизненного цикла: От документов проектирования → исходный код → двоичный файл → когнитивные процессы разработчиков, отслеживание эволюции уязвимостей
3. Структура анализа экосистемы: Выявление проблем не только как результата действий разработчиков, но и вовлечение компиляторов, поставщиков, образования и других сторон
4. Воспроизводимость: Открытые материалы интервью и кодовая книга (https://github.com/CactiLab/eCTF-User-Study-Material)

Экспериментальная установка

Набор данных

Данные соревнований:

• 2023 eCTF: Система дистанционного отпирания без ключа (прошивка автомобиля + брелока)
• 2024 eCTF: Система инсулиновой помпы (контроллер + мониторинг глюкозы + исполнительный механизм помпы)
• Эталонная конструкция: Написана на C, удовлетворяет функциональным требованиям, но без функций безопасности

Модель угроз:

• Физический доступ к устройству и каналам связи
• Доступ к исходному коду (без ключей/флагов)
• Программные, сетевые и аппаратные атаки

Метрики оценки

Количественные метрики:

• Коэффициент реализации механизмов безопасности (разделение привилегий, защита стека, стирание памяти, неисполняемый стек)
• Коэффициент защиты от аппаратных атак (побочные каналы, внедрение ошибок, асинхронное вмешательство)
• Распределение использования источников энтропии

Качественные метрики:

• Насыщение тем интервью
• Типы когнитивных неправильных представлений
• Модели приоритизации решений

Сравнительные методы

Сравнение с существующими исследованиями:

• Исследования анализа прошивки (FirmXRay, Nino et al., Tan et al.): Только технический анализ; данная работа добавляет когнитивное измерение
• Исследование BIBIFI: Фокус на микропроцессорные системы; данная работа сосредоточена на уникальных проблемах микроконтроллеров
• Исследования принятия Rust (Fulton et al., Sharma et al.): Данная работа объединяет специфичные для встроенных систем ограничения

Детали реализации

• Совместный анализ трёх исследователей уровня PhD в области безопасности встроенных систем
• Команда авторов участвовала в соревнованиях, но исключена из тематического исследования
• Освобождение от проверки IRB
• Компенсация участникам: 50 долларов США на человека

Результаты экспериментов

Основные результаты

Статистика реализации концептуальных вызовов

1. Коэффициент реализации механизмов безопасности (Рисунок 1):

2. Коэффициент защиты от аппаратных атак (Рисунок 2):

• Любая защита: 17/47 (36.17%)
• Защита от побочных каналов: 13/17 (76.47%)
• Защита от внедрения ошибок: 9/17 (52.94%)
• Защита от асинхронного вмешательства: 7/17 (41.18%)

3. Использование источников энтропии (Рисунок 3):

• 2023 год: 25% без энтропии, 25% жёстко закодировано/дефектно, 45% один источник энтропии, 5% смешанные источники
• 2024 год: 22.2% без энтропии, 14.8% жёстко закодировано/дефектно, 55.6% один источник энтропии, 7.4% смешанные источники

Статистика практических вызовов

Снижение принятия Rust:

• 2023 год: 5/20 (25%) команд использовали Rust
• 2024 год: 2/27 (7.4%) команд использовали Rust
• Основная причина: В 2024 году SDK имел большой размер, смешанная компиляция Rust+C превышала лимит флеш-памяти

Абляционные эксперименты

Случай оптимизации компилятора стирания памяти

Случай T12 (Listing 1):

• Использование memset 10 раз для стирания конфиденциальных данных
• Оптимизация компилятора удалила 5 вызовов (включая стирание ключа AES)
• Интервью разработчика показало: полное незнание того, что компилятор будет оптимизировать

Случаи эффективной реализации:

• T20/T15: Использование функции crypto_wipe библиотеки Monocypher (ключевое слово volatile)
• T14/T02: Использование библиотеки zeroize Rust
• T18: Пользовательская встроенная функция для предотвращения оптимизации

Проблемы конфигурации защиты стека

• Только 2/47 команд включили флаг компилятора
• Ни одна команда не инициализировала случайное значение защиты стека (используется фиксированная константа по умолчанию)
• Согласуется с реальной прошивкой: <0.2% коэффициент включения (исследование Xi et al.)

Анализ случаев

Случай 1: Неправильное представление о неисполняемом стеке (T18, T13)

Ошибочная реализация:

// Скрипт связывания T18
MEMORY {
    FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x00038000
    SRAM (rw) : ORIGIN = 0x20000000, LENGTH = 0x00008000  // Только отмечено rw
}

Проблема:

• Только изменены свойства заголовка ELF, MPU не был сконфигурирован при инициализации прошивки
• Интервью показало: 21/22 участников считали, что флагов компилятора достаточно

Правильная реализация (4 команды):

1. Включение MPU
2. Конфигурация области памяти стека как XN (eXecute Never)
3. Включение этой области

Случай 2: Злоупотребление блоками unsafe в Rust (T11)

Проблема: Широкое использование блоков unsafe для вызова функций C SDK Причина: Модель инкрементальной разработки, позволяющая постепенно переносить код на Rust Сравнение: C18-T08 ограничивает unsafe низкоуровневым взаимодействием с оборудованием

Случай 3: Комбинация источников энтропии (T14)

Стратегия: Смешивание четырёх источников энтропии

• Дрейф RTC и тактовой частоты CPU
• Специфичное для устройства начальное значение
• Внутренний датчик температуры ADC
• Неинициализированная SRAM (фактически неэффективна)

Эффект: Даже если один источник отказывает, комбинированное начальное значение остаётся непредсказуемым

Экспериментальные находки

Наблюдение 1: Оптимизация компилятора может нарушить состояние безопасности, выходящее за пределы спецификации языка (например, стирание памяти)

Наблюдение 2: Пробел в знаниях о специфичных для встроенных систем атаках является основным фактором, препятствующим реализации защиты

Наблюдение 3: Факторы решения о Rust: знакомство, поддержка поставщика, поддержка библиотек, кривая обучения

Наблюдение 4: Пользователи Rust сталкиваются с проблемами: компиляция no_std, реализация HAL, управление unsafe

Наблюдение 5: Автоматизированное преобразование дескрипторов оборудования в структуры Rust может ускорить разработку HAL, но верность и безопасность требуют дальнейшего исследования

Наблюдение 6: Несмотря на ограниченные источники энтропии микроконтроллеров, комбинирование нескольких доступных источников может эффективно повысить надёжность случайности

Связанные работы

Исследования CTF

• Образовательная направленность: Vigna et al. (структура iCTF), Vykopal et al. (CTF как инструмент обучения)
• Анализ вызовов: Crispin et al. (опыт Defcon CTF), Chung et al. (организация ловушек)
• Отличие данной работы: Впервые объединены анализ представленных работ и интервью, фокус на проблемах безопасной разработки, а не на образовательных эффектах

Безопасная разработка программного обеспечения и исследования пользователей

• Исследования BIBIFI (Parker et al., Ruef et al., Votipka et al.): Анализ разработки микропроцессорных систем, выявление того, что большинство уязвимостей происходят из неправильных представлений, а не ошибок
• Исследования принятия Rust:
  • Fulton et al.: Перспектива высокоуровневых разработчиков, выявление кривой обучения и проблем поддержки библиотек
  • Sharma et al.: Анализ 6000+ проектов встроенного Rust, раскрытие недостаточной поддержки экосистемы
• Вклад данной работы: Фокус на специфичные для микроконтроллеров ограничения, объединение технической и когнитивной перспектив

Безопасность микроконтроллерных систем

• Технологии защиты: Разделение привилегий (Kage, ACES, EPOXY), CFI (μRAI, Silhouette, SHERLOC), рандомизация (fASLR, HARM)
• Анализ прошивки: FirmXRay, Nino et al., Tan et al. (статический анализ реальной прошивки)
• Уникальность данной работы: Впервые исследуются когнитивные проблемы разработчиков, а не только технические решения

Выводы и обсуждение

Основные выводы

1. Ответственность экосистемы: Безопасная реализация — это совместная ответственность разработчиков, преподавателей, исследователей и поставщиков
2. Уникальные потребности разработки МКУ:
   • Глубокое понимание характеристик платформы (оборудование, компилятор, инструментальная цепь)
   • Работа с непрозрачностью компилятора и контринтуитивным поведением
   • Защита от уникальных угроз, связанных с физическим доступом
3. Пробел в образовании: Существующие курсы недостаточно подготавливают студентов к проблемам, специфичным для встроенных систем
4. Три основных концептуальных вызова:
   • Недостаточное применение фундаментальных механизмов безопасности
   • Трудности адаптации платформы
   • Слабое осознание защиты от аппаратных атак
5. Два основных практических вызова:
   • Ограниченная поддержка языков с безопасностью памяти
   • Отсутствие высококачественных источников энтропии

Ограничения

1. Внешняя валидность:
   • eCTF — это среда соревнований, элементы геймификации могут влиять на поведение
   • Участники в основном студенты/разработчики на ранних этапах карьеры; обобщение на опытную промышленную среду ограничено
   • Авторы считают, что выводы представляют консервативную нижнюю границу реальных уязвимостей
2. Область исследования:
   • Не охватывает динамику командной работы и структуру соревнований
   • Классификация концептуальных/практических может иметь перекрытия
3. Ограничения данных:
   • Данные самоотчёта могут содержать смещение социальной желательности
   • Размер выборки (n=22) относительно небольшой
   • Отсутствие подробных данных об образовательном фоне; рекомендации по образованию являются предварительными
4. Модель угроз:
   • Модель угроз соревнований может не полностью отражать все реальные сценарии

Будущие направления

1. Исследования образования: Систематический обзор существующих курсов безопасности встроенных систем, выявление пробелов в программе
2. Сравнение опыта: Исследование того, сталкиваются ли опытные профессионалы с аналогичными проблемами
3. Разработка инструментов:
   • Автоматизированные инструменты разделения привилегий
   • Инструменты проверки безопасной оптимизации компилятора
   • Инструменты упрощения разработки Rust HAL
4. Поддержка поставщиков:
   • Полные SDK Rust или привязки Rust-C
   • Прозрачность источников энтропии и стандартизация API

Глубокая оценка

Преимущества

1. Методологическое инновация:
   • Впервые объединены анализ кода и глубокие интервью для раскрытия "что" и "почему"
   • Перспектива полного жизненного цикла отслеживает эволюцию уязвимостей
   • Высокая воспроизводимость (открытые данные и кодовая книга)
2. Эмпирическая строгость:
   • Полный анализ 47 представленных работ команд
   • 22 глубоких интервью (в среднем 69 минут)
   • Треугольная валидация (код, документация, интервью, дизассемблирование)
   • Качественный анализ следует зрелым методам (Saldaña, Clarke & Braun)
3. Практическая ценность:
   • 9 конкретных рекомендаций для 5 категорий заинтересованных сторон
   • Выявление системных препятствий (не только личных ошибок)
   • Согласованность с коэффициентами уязвимостей реальной прошивки подтверждает репрезентативность выводов
4. Глубина понимания:
   • Раскрытие того, как оптимизация компилятора может нарушить безопасность (Наблюдение 1)
   • Выявление пробелов в знаниях как основного препятствия (Наблюдение 2)
   • Обнаружение многомерных проблем принятия Rust (Наблюдения 3-5)
5. Ясность изложения:
   • Структурированная классификация (концептуальное vs практическое)
   • Богатые примеры и фрагменты кода
   • Ясные диаграммы (Рисунки 1-3)

Недостатки

1. Ограничения обобщения:
   • Среда соревнований отличается от промышленной практики
   • Опыт участников относительно начальный
   • Охватывает только двухлетние данные (2023-2024)
2. Причинный вывод:
   • Невозможно полностью разделить влияние давления соревнований vs пробелов в знаниях
   • Отсутствует систематическое сравнение между участниками с/без курсов безопасности
3. Глубина количественного анализа:
   • Отсутствуют тесты статистической значимости
   • Не количественно определена относительная важность различных факторов
   • Размер выборки интервью относительно небольшой (n=22)
4. Оценка инструментов:
   • Не проведено практическое тестирование предложенных рекомендаций
   • Отсутствуют интервенционные эксперименты для проверки мер по улучшению
5. Охват:
   • Фокус только на платформах ARM Cortex-M
   • Не охватывает среды RTOS (только bare-metal)
   • Не глубоко исследует факторы командной работы

Влияние

1. Академический вклад:
   • Открытие новой парадигмы исследования безопасности встроенных систем с участием пользователей
   • Предоставление эмпирической основы для реформы образования
   • Выявление направлений улучшения компилятора и инструментальной цепи
2. Практическая ценность:
   • Поставщики могут улучшить SDK и документацию
   • Преподаватели могут адаптировать программы курсов
   • Разработчики могут избежать распространённых ошибок
3. Политическое значение:
   • Поддержка включения безопасности в стандарты разработки встроенных систем
   • Предоставление анализа корневых причин уязвимостей для органов регулирования
4. Воспроизводимость:
   • Открытые материалы облегчают проверку и расширение
   • Методология применима к другим CTF или конкурсам разработки

Применимые сценарии

1. Образование:
   • Проектирование курсов безопасности встроенных систем
   • Организация и оценка соревнований CTF
   • Материалы обучения разработчиков
2. Промышленность:
   • Аудит безопасности устройств IoT
   • Улучшение жизненного цикла безопасной разработки (SDL)
   • Выбор и конфигурация инструментальной цепи
3. Исследования:
   • Безопасная оптимизация компилятора
   • Адаптация языков с безопасностью памяти для встроенных систем
   • Автоматизация защиты от аппаратных атак
4. Стандартизация:
   • Руководства по лучшим практикам безопасности встроенных систем
   • Требования безопасности SDK поставщиков

Резюме девяти основных рекомендаций

Избранные ссылки

1. Разделение привилегий:
   • 16 Kage (Du et al., 2022)
   • 10 ACES (Clements et al., 2018)
   • 11 EPOXY (Clements et al., 2017)
2. Безопасность памяти:
   • 18 Исследование принятия Rust (Fulton et al., 2021)
   • 52 Проблемы встроенного Rust (Sharma et al., 2024)
3. Анализ прошивки:
   • 65 FirmXRay (Wen et al., 2020)
   • 42 Безопасность прошивки IoT (Nino et al., 2024)
   • 56 Обзор систем Cortex-M (Tan et al., 2024)
4. Исследования пользователей:
   • 46 BIBIFI (Ruef et al., 2016)
   • 62 Неправильные представления разработчиков о безопасности (Votipka et al., 2020)

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