"We just did not have that on the embedded system": Perspectivas y Desafíos para Asegurar Sistemas de Microcontroladores desde las Competiciones Embedded CTF

Información Básica

• ID del Artículo: 2503.08053
• Título: "We just did not have that on the embedded system": Insights and Challenges for Securing Microcontroller Systems from the Embedded CTF Competitions
• Autores: Zheyuan Ma, Gaoxiang Liu, Alex Eastman, Kai Kaufman, Md Armanuzzaman, Xi Tan, Katherine Jesse, Robert J. Walls, Ziming Zhao
• Clasificación: cs.CR (Criptografía y Seguridad)
• Fecha de Publicación/Conferencia: ACM SIGSAC Conference on Computer and Communications Security (CCS '25)
• Enlace del Artículo: https://arxiv.org/abs/2503.08053

Resumen

Los sistemas de microcontroladores son indispensables en la vida cotidiana, proporcionando potencia a aplicaciones críticas como vehículos, dispositivos médicos y sistemas de control industrial. Este estudio analiza el ciclo de vida completo del desarrollo seguro de sistemas de microcontroladores desde perspectivas técnicas y cognitivas, mediante el análisis de presentaciones de equipos y entrevistas posteriores a la competición de las competiciones MITRE Embedded CTF (eCTF) de 2023 y 2024. La investigación identifica dos categorías principales de desafíos: conceptuales y prácticos. Conceptualmente, existen dificultades en la migración de sistemas de microprocesadores a sistemas de microcontroladores, y los participantes carecen de comprensión sobre ataques específicos de microcontroladores. Prácticamente, lenguajes seguros en memoria como Rust carecen de soporte adecuado en microcontroladores, y las fuentes de entropía de baja calidad debilitan la seguridad criptográfica y la generación de claves. El estudio proporciona recomendaciones específicas para investigadores, desarrolladores, proveedores y educadores.

Antecedentes de Investigación y Motivación

1. Preguntas de Investigación

Los sistemas de microcontroladores (MCU) se aplican ampliamente en infraestructuras críticas, pero su desarrollo seguro enfrenta desafíos únicos. La investigación existente se enfoca principalmente en análisis de vulnerabilidades de firmware, careciendo de una comprensión profunda de las raíces de las vulnerabilidades, particularmente en los niveles cognitivo y práctico de los desarrolladores.

2. Importancia del Problema

• Aplicabilidad Generalizada: Los microcontroladores impulsan vehículos, dispositivos médicos, sistemas de control industrial y otros sistemas críticos
• Fragilidad de Seguridad: Carecen de características de seguridad estándar como MMU, y la programación común en C/ensamblador es propensa a errores de memoria
• Accesibilidad Física: Son más susceptibles a ataques de hardware como canales laterales e inyección de fallos en comparación con computadoras de propósito general

3. Limitaciones de Métodos Existentes

• Obstáculos de Código Cerrado: El firmware real es difícil de obtener y analizar
• Perspectiva Única: Solo análisis técnico, ignorando la cognición y los procesos de decisión de los desarrolladores
• Falta de Perspectiva de Ciclo de Vida Completo: Imposibilidad de rastrear la evolución de vulnerabilidades desde el diseño hasta la implementación

4. Motivación de la Investigación

A través de la perspectiva única de las competiciones eCTF, el equipo de investigación puede:

• Acceder a código fuente completo, documentación y herramientas de construcción
• Combinar análisis técnico con entrevistas de desarrolladores
• Observar prácticas de seguridad de investigadores tempranos, proporcionando base para mejoras educativas
• Identificar desafíos de seguridad sistémicos y empíricos

Contribuciones Principales

1. Innovación Metodológica: Propone un método para estudiar desafíos de seguridad de sistemas de microcontroladores a través de competiciones CTF, examinando el ciclo de vida completo de desarrollo combinando análisis técnico y perspectiva cognitiva
2. Marco de Clasificación de Desafíos Duales: Identifica y clasifica sistemáticamente desafíos conceptuales (brechas de conocimiento) y desafíos prácticos (limitaciones de herramientas/recursos)
3. Hallazgos Empíricos:
   • Desafíos conceptuales: Aplicación insuficiente de mecanismos de seguridad fundamentales como separación de privilegios, borrado de memoria y canarios de pila; dificultad en adaptación de plataformas; débil conciencia sobre defensa contra ataques de hardware
   • Desafíos prácticos: Soporte insuficiente para lenguajes seguros en memoria como Rust; falta de fuentes de entropía de alta calidad
4. Recomendaciones Accionables: Proporciona 9 recomendaciones específicas para cinco categorías de partes interesadas (investigadores, proveedores, educadores, desarrolladores, mantenedores de compiladores)
5. Recursos de Datos: Análisis de 47 presentaciones de equipos (20 de 2023, 27 de 2024), completando 22 entrevistas en profundidad

Detalles de la Metodología

Definición de Tareas

El objetivo de la investigación es identificar y comprender desafíos en el desarrollo seguro de sistemas de microcontroladores, incluyendo específicamente:

• Entrada: Presentaciones de equipos eCTF (código fuente, documentación, herramientas de construcción) + datos de entrevistas de participantes
• Salida: Clasificación de desafíos de seguridad, análisis de causas raíz, recomendaciones de mejora
• Restricciones: Enfoque en entorno de competición orientado a seguridad, participantes como desarrolladores en etapa temprana de carrera

Arquitectura de Investigación

1. Análisis de Presentaciones (Submission Analysis)

Fuentes de Datos:

• 2023: 20 equipos, utilizando placa de desarrollo TI TM4C123GXL (ARM Cortex-M4F)
• 2024: 27 equipos, utilizando placa de desarrollo Analog Devices MAX78000FTHR (ARM Cortex-M4 + RISC-V)

Dimensiones de Análisis:

• Herramientas de Construcción: Lenguajes de programación, compiladores, niveles de optimización, banderas de compilación segura, atributos de scripts de enlace
• Código Fuente: Uso de git diff para rastrear modificaciones, verificación de ensamblador en línea, operaciones de memoria, generación de números aleatorios, código relacionado con temporización
• Desensamblado: Verificación del impacto de optimizaciones del compilador en características de seguridad
• Análisis en Tiempo de Ejecución: Uso de herramientas de depuración para verificar incertidumbres del análisis estático

Puntos de Verificación Clave:

• Separación de privilegios (configuración de MPU)
• Implementación de borrado de memoria (problema de optimización memset)
• Habilitación de canarios de pila
• Configuración de pila no ejecutable
• Defensa contra ataques de hardware (canales laterales, inyección de fallos, manipulación física)
• Calidad de fuentes de entropía

2. Entrevistas de Participantes (Participant Interviews)

Características de la Muestra (n=22):

• Antecedentes educativos: 12 estudiantes de pregrado, 6 estudiantes de posgrado, 4 estudiantes de doctorado
• Experiencia en cursos de seguridad: 8 personas sin antecedentes en cursos de seguridad
• Experiencia en sistemas embebidos: 14 personas con experiencia en desarrollo embebido

Diseño de Entrevista:

• Entrevistas semiestructuradas, duración 42-107 minutos (promedio 69 minutos)
• Preguntas derivadas de problemas recurrentes en análisis de presentaciones
• Exploración de cognición (conocimiento, conceptos erróneos) y decisiones (prioridades, compensaciones)

Análisis de Datos:

• Transcripción con Otter AI y revisión manual
• Codificación abierta independiente por tres investigadores
• Desarrollo iterativo de libro de códigos: 8 temas principales, 40 subtemas, 278 códigos
• Resolución colaborativa de conflictos de codificación, sin necesidad de verificación formal de confiabilidad

Puntos de Innovación Técnica

1. Metodología de Doble Enfoque: Primera combinación de análisis de código a gran escala con entrevistas en profundidad, revelando "qué" y "por qué"
2. Perspectiva de Ciclo de Vida Completo: Desde documentos de diseño → código fuente → binario → cognición del desarrollador, rastreando evolución de vulnerabilidades
3. Marco de Análisis del Ecosistema: Identifica problemas no solo atribuibles a desarrolladores, sino también involucrando compiladores, proveedores, educación y otros
4. Reproducibilidad: Publicación de materiales de entrevista y libro de códigos (https://github.com/CactiLab/eCTF-User-Study-Material)

Configuración Experimental

Conjunto de Datos

Datos de Competición:

• eCTF 2023: Sistema de entrada sin llave remota (firmware de vehículo + llavero)
• eCTF 2024: Sistema de bomba de insulina (controlador + monitoreo de glucosa + ejecutor de bomba)
• Diseño de Referencia: Escrito en C, cumple requisitos funcionales pero sin características de seguridad

Modelo de Amenaza:

• Acceso físico a dispositivos y canales de comunicación
• Acceso a código fuente (sin claves/banderas)
• Ataques de software, red y hardware

Métricas de Evaluación

Métricas Cuantitativas:

• Tasa de implementación de mecanismos de seguridad (separación de privilegios, canarios de pila, borrado de memoria, pila no ejecutable)
• Tasa de defensa contra ataques de hardware (canales laterales, inyección de fallos, manipulación asincrónica)
• Distribución de uso de fuentes de entropía

Métricas Cualitativas:

• Saturación de temas de entrevista
• Tipos de conceptos erróneos cognitivos
• Patrones de prioridades de decisión

Métodos Comparativos

Comparación con investigación existente:

• Investigación de Análisis de Firmware (FirmXRay, Nino et al., Tan et al.): Solo análisis técnico, este artículo añade dimensión cognitiva
• Investigación BIBIFI: Enfoque en sistemas de microprocesadores, este artículo se enfoca en desafíos únicos de microcontroladores
• Investigación de Adopción de Rust (Fulton et al., Sharma et al.): Este artículo combina restricciones específicas de sistemas embebidos

Detalles de Implementación

• Colaboración de tres investigadores de nivel PhD en seguridad embebida
• Equipo de autores participó en competición pero excluido del estudio de caso
• Exención de revisión IRB
• Compensación de $50 USD por participante

Resultados Experimentales

Resultados Principales

Estadísticas de Desafíos Conceptuales

1. Tasa de Implementación de Mecanismos de Seguridad (Figura 1):

2. Tasa de Defensa contra Ataques de Hardware (Figura 2):

• Cualquier defensa: 17/47 (36.17%)
• Defensa contra canales laterales: 13/17 (76.47%)
• Defensa contra inyección de fallos: 9/17 (52.94%)
• Defensa contra manipulación asincrónica: 7/17 (41.18%)

3. Uso de Fuentes de Entropía (Figura 3):

• 2023: 25% sin entropía, 25% codificada/defectuosa, 45% fuente única de entropía, 5% fuentes mixtas
• 2024: 22.2% sin entropía, 14.8% codificada/defectuosa, 55.6% fuente única de entropía, 7.4% fuentes mixtas

Estadísticas de Desafíos Prácticos

Tasa de Adopción de Rust en Declive:

• 2023: 5/20 (25%) equipos utilizan Rust
• 2024: 2/27 (7.4%) equipos utilizan Rust
• Causa Principal: SDK de 2024 de gran tamaño, compilación mixta Rust+C excede límite de memoria flash

Experimentos de Ablación

Caso de Optimización del Compilador de Borrado de Memoria

Caso T12 (Listing 1):

• Uso de memset 10 veces para borrar datos sensibles
• Compilador optimiza 5 llamadas (incluyendo borrado de clave AES)
• Entrevista con desarrollador muestra: Completamente desconocedor de que el compilador optimizaría

Casos de Implementación Efectiva:

• T20/T15: Uso de crypto_wipe de biblioteca Monocypher (palabra clave volatile)
• T14/T02: Uso de biblioteca zeroize de Rust
• T18: Función en línea personalizada para prevenir optimización

Problema de Configuración de Canarios de Pila

• Solo 2/47 equipos habilitan bandera del compilador
• Ningún equipo inicializa valor de canario aleatorio (valor constante fijo por defecto)
• Consistente con firmware real: <0.2% tasa de habilitación (investigación de Xi et al.)

Análisis de Casos

Caso 1: Concepto Erróneo de Pila No Ejecutable (T18, T13)

Implementación Incorrecta:

// Script de enlace de T18
MEMORY {
    FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x00038000
    SRAM (rw) : ORIGIN = 0x20000000, LENGTH = 0x00008000  // Solo marcado rw
}

Problema:

• Solo modifica atributos de encabezado ELF, no configura MPU durante inicialización de firmware
• Entrevista revela: 21/22 participantes creen que banderas del compilador son suficientes

Implementación Correcta (4 equipos):

1. Habilitar MPU
2. Configurar región de memoria de pila como XN (eXecute Never)
3. Habilitar esa región

Caso 2: Abuso de Bloques Unsafe de Rust (T11)

Problema: Uso generalizado de bloques unsafe para llamar funciones SDK de C Razón: Modelo de desarrollo incremental, permitiendo migración gradual de código a Rust Contraste: C18-T08 limitó unsafe a capa de interacción de hardware de bajo nivel

Caso 3: Combinación de Fuentes de Entropía (T14)

Estrategia: Mezcla de cuatro fuentes de entropía

• Desviación de reloj RTC vs reloj de CPU
• Semilla específica del dispositivo
• ADC de temperatura interna
• SRAM no inicializada (realmente inefectiva)

Efecto: Incluso si una fuente falla, la semilla combinada sigue siendo impredecible

Hallazgos Experimentales

Observación 1: Las optimizaciones del compilador pueden romper estados de seguridad más allá de la especificación del lenguaje (como borrado de memoria)

Observación 2: La brecha de conocimiento sobre ataques específicos de sistemas embebidos es el factor principal que obstaculiza la implementación de defensas

Observación 3: Factores de decisión de Rust: familiaridad, soporte de proveedores, soporte de bibliotecas, curva de aprendizaje

Observación 4: Los usuarios de Rust enfrentan desafíos: compilación no_std, implementación de HAL, gestión unsafe

Observación 5: La transformación automatizada de descriptores de hardware a estructuras Rust puede acelerar desarrollo de HAL, pero se requiere investigación adicional sobre fidelidad y seguridad

Observación 6: A pesar de fuentes de entropía limitadas en microcontroladores, combinar múltiples fuentes disponibles puede mejorar efectivamente la robustez de aleatoriedad

Trabajo Relacionado

Investigación de CTF

• Orientada a Educación: Vigna et al. (marco iCTF), Vykopal et al. (CTF como herramienta de enseñanza)
• Análisis de Desafíos: Crispin et al. (experiencia Defcon CTF), Chung et al. (organización de trampas)
• Distinción de Este Artículo: Primera combinación de análisis de presentaciones con entrevistas, enfocándose en desafíos de desarrollo seguro en lugar de efectos educativos

Desarrollo Seguro de Software e Investigación de Usuarios

• Investigación BIBIFI (Parker et al., Ruef et al., Votipka et al.): Análisis de desarrollo de sistemas de microprocesadores, descubrimiento de que la mayoría de vulnerabilidades provienen de conceptos erróneos en lugar de errores
• Investigación de Adopción de Rust:
  • Fulton et al.: Perspectiva de desarrolladores de alto nivel, identificación de curva de aprendizaje y problemas de soporte de bibliotecas
  • Sharma et al.: Análisis de 6000+ proyectos Rust embebidos, revelación de soporte de ecosistema insuficiente
• Contribución de Este Artículo: Enfoque en restricciones específicas de microcontroladores, combinando perspectiva técnica y cognitiva dual

Seguridad de Sistemas de Microcontroladores

• Técnicas de Defensa: Separación de privilegios (Kage, ACES, EPOXY), CFI (μRAI, Silhouette, SHERLOC), aleatorización (fASLR, HARM)
• Análisis de Firmware: FirmXRay, Nino et al., Tan et al. (análisis estático de firmware real)
• Singularidad de Este Artículo: Primera investigación de desafíos cognitivos de desarrolladores, en lugar de solo soluciones técnicas

Conclusiones y Discusión

Conclusiones Principales

1. Responsabilidad del Ecosistema: La implementación segura es responsabilidad conjunta de desarrolladores, educadores, investigadores y proveedores
2. Necesidades Únicas del Desarrollo de MCU:
   • Comprensión profunda de características de plataforma (hardware, compilador, cadena de herramientas)
   • Manejo de comportamiento opaco y contraintuitivo del compilador
   • Defensa contra amenazas únicas de acceso físico
3. Brecha Educativa: Los cursos existentes no preparan suficientemente a estudiantes para desafíos específicos de sistemas embebidos
4. Tres Desafíos Conceptuales Principales:
   • Aplicación insuficiente de mecanismos de seguridad fundamentales
   • Dificultad en adaptación de plataformas
   • Débil conciencia sobre defensa contra ataques de hardware
5. Dos Desafíos Prácticos Principales:
   • Soporte insuficiente para lenguajes seguros en memoria
   • Falta de fuentes de entropía de alta calidad

Limitaciones

1. Validez Externa:
   • eCTF es entorno de competición, elementos de gamificación pueden afectar comportamiento
   • Participantes mayormente estudiantes/desarrolladores tempranos, generalización a entorno industrial profesional limitada
   • Autores consideran hallazgos como límite inferior conservador de vulnerabilidades reales
2. Alcance de Investigación:
   • No cubre dinámicas de colaboración de equipos y estructura de competición
   • Clasificación conceptual/práctica puede tener solapamientos
3. Limitaciones de Datos:
   • Datos de auto-reporte pueden tener sesgo de expectativa social
   • Tamaño de muestra (n=22) relativamente pequeño
   • Falta de datos detallados de antecedentes educativos, recomendaciones educativas son preliminares
4. Modelo de Amenaza:
   • Modelo de amenaza de competición puede no reflejar completamente todos escenarios reales

Direcciones Futuras

1. Investigación Educativa: Revisión sistemática de cursos de seguridad embebida existentes, identificación de brechas curriculares
2. Comparación Empírica: Investigación de si profesionales experimentados enfrentan desafíos similares
3. Desarrollo de Herramientas:
   • Herramientas automatizadas de separación de privilegios
   • Herramientas de verificación de optimización segura del compilador
   • Herramientas para simplificar desarrollo de HAL en Rust
4. Soporte de Proveedores:
   • SDK completo de Rust o enlaces Rust-C
   • Transparencia de fuentes de entropía y estandarización de API

Evaluación Profunda

Fortalezas

1. Innovación Metodológica:
   • Primera combinación de análisis de código con entrevistas en profundidad, revelando "qué" y "por qué"
   • Perspectiva de ciclo de vida completo rastreando evolución de vulnerabilidades
   • Fuerte reproducibilidad (datos y libro de códigos públicos)
2. Rigor Empírico:
   • Análisis completo de 47 presentaciones de equipos
   • 22 entrevistas en profundidad (promedio 69 minutos)
   • Verificación triangular (código, documentación, entrevistas, desensamblado)
   • Análisis cualitativo siguiendo métodos maduros (Saldaña, Clarke & Braun)
3. Valor Práctico:
   • 9 recomendaciones específicas para 5 categorías de partes interesadas
   • Identificación de obstáculos sistémicos (no solo fallos personales)
   • Consistencia con tasas de vulnerabilidades en firmware real, validando representatividad de hallazgos
4. Profundidad de Perspectiva:
   • Revelación de cómo optimizaciones del compilador rompen seguridad (Observación 1)
   • Identificación de brecha de conocimiento como obstáculo principal (Observación 2)
   • Descubrimiento de desafíos multidimensionales de adopción de Rust (Observaciones 3-5)
5. Claridad de Escritura:
   • Clasificación estructurada (conceptual vs práctico)
   • Casos y ejemplos de código abundantes
   • Gráficos claros (Figuras 1-3)

Deficiencias

1. Limitaciones de Generalización:
   • Diferencias entre entorno de competición y práctica industrial
   • Nivel de experiencia de participantes relativamente inicial
   • Solo cubre dos años de datos (2023-2024)
2. Inferencia Causal:
   • Imposibilidad de separar completamente efectos de presión de competición vs brecha de conocimiento
   • Falta de análisis sistemático de diferencias entre participantes con/sin cursos de seguridad
3. Profundidad de Análisis Cuantitativo:
   • Falta de pruebas de significancia estadística
   • No cuantifica importancia relativa de diferentes factores
   • Tamaño de muestra de entrevista relativamente pequeño (n=22)
4. Evaluación de Herramientas:
   • No prueba efectivamente las recomendaciones propuestas
   • Falta de experimentos de intervención validando medidas de mejora
5. Cobertura:
   • Solo enfoque en plataformas ARM Cortex-M
   • No cubre entorno RTOS (solo bare-metal)
   • Exploración limitada de factores de colaboración de equipos

Impacto

1. Contribución Académica:
   • Inaugura nuevo paradigma de investigación de usuarios en seguridad embebida
   • Proporciona base empírica para reforma educativa
   • Identifica direcciones de mejora de compilador y cadena de herramientas
2. Valor Práctico:
   • Proveedores pueden mejorar SDK y documentación
   • Educadores pueden ajustar diseño curricular
   • Desarrolladores pueden evitar trampas comunes
3. Significancia Política:
   • Apoya incorporación de seguridad en estándares de desarrollo embebido
   • Proporciona análisis de causa raíz de vulnerabilidades para organismos reguladores
4. Reproducibilidad:
   • Materiales públicos facilitan verificación y extensión
   • Metodología aplicable a otros CTF o competiciones de desarrollo

Escenarios de Aplicación

1. Educación:
   • Diseño de cursos de seguridad de sistemas embebidos
   • Organización y evaluación de competiciones CTF
   • Materiales de capacitación de desarrolladores
2. Industrial:
   • Auditoría de seguridad de dispositivos IoT
   • Mejora de ciclo de vida de desarrollo seguro (SDL)
   • Selección y configuración de cadena de herramientas
3. Investigación:
   • Optimización segura de compiladores
   • Adaptación de lenguajes seguros en memoria para sistemas embebidos
   • Automatización de defensa contra ataques de hardware
4. Establecimiento de Estándares:
   • Guías de mejores prácticas de seguridad embebida
   • Requisitos de seguridad de SDK de proveedores

Resumen de Nueve Recomendaciones Principales

Referencias Seleccionadas

1. Separación de Privilegios:
   • 16 Kage (Du et al., 2022)
   • 10 ACES (Clements et al., 2018)
   • 11 EPOXY (Clements et al., 2017)
2. Seguridad de Memoria:
   • 18 Investigación de Adopción de Rust (Fulton et al., 2021)
   • 52 Desafíos de Rust Embebido (Sharma et al., 2024)
3. Análisis de Firmware:
   • 65 FirmXRay (Wen et al., 2020)
   • 42 Seguridad de Firmware IoT (Nino et al., 2024)
   • 56 Revisión de Sistemas Cortex-M (Tan et al., 2024)
4. Investigación de Usuarios:
   • 46 BIBIFI (Ruef et al., 2016)
   • 62 Conceptos Erróneos de Seguridad de Desarrolladores (Votipka et al., 2020)

Evaluación General: Este es un artículo de alta calidad de investigación de usuarios en seguridad embebida, revelando desafíos profundos en el desarrollo seguro de sistemas de microcontroladores a través de una metodología innovadora de doble enfoque. Su mayor valor radica en combinar análisis técnico con cognición de desarrolladores, proporcionando una ruta accionable para mejorar educación, herramientas y práctica. Aunque existen limitaciones de generalización, la consistencia de sus hallazgos con tasas de vulnerabilidades en firmware real fortalece la credibilidad de conclusiones. Esta investigación establece un nuevo paradigma de investigación para la comunidad de seguridad embebida, mereciendo trabajo posterior para verificación y extensión adicional.