Firmware seguro

01 · Primero, contra quién

El modelo de amenazas

La seguridad no se agrega al final como una capa de protección universal: se diseña contra amenazas concretas, y empieza con tres preguntas. ¿Qué hay que proteger? (los activos). ¿De quién? (los atacantes, con sus medios y su motivación). ¿Por dónde pueden entrar? (los vectores). Sin esas respuestas, uno termina gastando esfuerzo en proteger lo que a nadie le interesa y dejando abierta la puerta que sí usarán.

Un ejemplo que ilustra por qué importa pensar en el atacante más barato: en 2016, la botnet Mirai infectó cientos de miles de cámaras y routers domésticos simplemente probando unas pocas decenas de contraseñas de fábrica por Telnet. No usó ninguna técnica sofisticada: aprovechó equipos que salían de fábrica con credenciales conocidas, sin forma de cambiarlas ni de actualizarse. La lección es doble: las vulnerabilidades más explotadas son las más tontas, y un producto sin mecanismo de actualización segura está condenado, porque sus defectos de hoy serán sus incidentes de mañana.

02 · Detectar daños y detectar mentiras

Integridad, autenticidad y firma digital

En el tema 42 usamos un CRC para comprobar que una imagen llegó sin daños. Ese es un problema de integridad accidental: el ruido o un error alteran algunos bits, y el CRC lo detecta. Pero frente a un atacante, el problema es otro: es autenticidad, saber que la imagen la hizo quien dice haberla hecho, y que nadie la modificó con intención. Son propiedades distintas, y se resuelven con herramientas distintas, que conviene no confundir:

La Parte 1 del programa de Python hace una demostración que conviene ver con los propios ojos: falsificar un CRC-32. Un atacante toma el firmware legítimo, cambia cuatro bytes del código por los suyos, y después calcula cuatro bytes de relleno que, agregados al final, hacen que el CRC de la imagen maliciosa sea exactamente igual al de la original: 0x09990583 en ambos casos. El cálculo es instantáneo, porque el CRC es una función lineal y matemáticamente invertible. Para el cargador del tema 42, la imagen maliciosa es perfecta. El hash criptográfico no se deja: el SHA-256 de la imagen original y el de la maliciosa no tienen nada en común, y no hay forma de elegir qué cambios producen un hash dado.

Y la propiedad de «avalancha» lo explica (Parte 2): cambiando un solo bit de una imagen de 4 KB, en promedio 128,1 de los 256 bits del SHA-256 cambian (el mínimo observado en 1000 pruebas fue 104; el máximo, 153): el resultado se comporta como un sorteo, sin patrones que el atacante pueda aprovechar. Con 256 bits, probar todas las posibilidades es imposible: 2²⁵⁶ ≈ 1,2 × 10⁷⁷; aun a 10¹² intentos por segundo, tomaría unos 10⁵⁷ años.

Clave compartida frente a clave pública

Un hash por sí solo no autentica: el atacante puede calcular el hash de su imagen y reemplazar el valor. Hay que atar el hash a un secreto. Hay dos formas, con una consecuencia muy distinta para una flota de equipos:

• HMAC (clave compartida): el fabricante calcula una etiqueta con una clave secreta, y el equipo la verifica con la misma clave. Es simple y rápido, pero hay un problema grave: la clave tiene que estar dentro de cada equipo. Quien extrae la clave de un solo equipo (con un ataque físico) puede firmar cualquier imagen para toda la flota. La Parte 3 lo muestra: con la clave extraída, el HMAC de la imagen maliciosa verifica.
• Firma digital (clave pública): el fabricante firma con una clave privada que nunca sale de su sistema, y el equipo verifica con la pública. La clave pública permite verificar pero no firmar: robar un equipo no da nada con qué falsificar imágenes. Es lo que se usa en el firmware actual. La Parte 3 lo ilustra con una firma de juguete (RSA con números de 62 bits, que no es segura y está solo para ver el mecanismo): el equipo, con su clave pública, verifica la imagen original, y rechaza tanto la imagen maliciosa como una firma inventada por el atacante.

En la práctica se usan ECDSA sobre la curva P-256 o Ed25519 (claves de 256 bits, firmas de 64 bytes), o RSA de 2048 bits o más (firmas de 256 bytes). Las curvas elípticas son las preferidas en microcontroladores por su menor tamaño y velocidad. La firma no se calcula sobre toda la imagen sino sobre su hash, y se escribe en el encabezado (tema 42). Nunca se programa la criptografía por cuenta propia: se usa una biblioteca probada (mbed TLS, TinyCrypt, wolfSSL, libsodium) o el acelerador criptográfico del chip. Programar la propia criptografía es el error de seguridad más frecuente y más costoso.

03 · Desde el primer instante

El arranque seguro y la cadena de confianza

Verificar la firma cuando llega la imagen no alcanza: un atacante con acceso físico puede modificar la flash después, por el puerto de depuración o con un programador. El arranque seguro (secure boot) verifica la firma en cada arranque, antes de ejecutar, de modo que lo que corra sea siempre lo que el fabricante firmó. Pero ¿quién verifica al verificador? Si el cargador que comprueba las firmas se pudiera reemplazar, un atacante reemplazaría el cargador por uno que acepte todo. La solución es una cadena de confianza: cada eslabón verifica al siguiente, y el primero es inmutable.

Cada eslabón cumple un papel preciso. La ROM de arranque es código grabado por el fabricante del chip en una memoria de solo lectura: nadie puede modificarlo, y por eso es la raíz de confianza. Esa ROM verifica la firma del cargador contra una clave pública cuyo hash está grabado en fusibles de un solo uso (OTP o eFuses: una vez programados, no se borran). El cargador, a su vez, lleva embebida una clave pública (o su hash) con la que verifica la aplicación. Y la aplicación solo se ejecuta si esa verificación tuvo éxito. Un atacante que modifique cualquier eslabón rompe la firma y el equipo no arranca; uno que no tenga la clave privada no puede firmar un reemplazo.

/* En el cargador: verificar ANTES de ejecutar, en cada arranque */
typedef enum { V_OK, V_ENCABEZADO, V_HASH, V_FIRMA, V_RETROCESO } Verificacion;

Verificacion verificar_imagen(uint32_t ranura_base, uint32_t tam_ranura) {
    const EncabezadoImagen *h = (const EncabezadoImagen *)ranura_base;           /* el encabezado de 42, ahora con firma */
    if (!encabezado_coherente(h, tam_ranura))                         return V_ENCABEZADO;   /* magia, producto, tamaño, enlace */

    uint8_t hash[32];
    sha256((const uint8_t *)(ranura_base + sizeof *h), h->tamano, hash);        /* hash de TODO el código (o acelerador de hardware) */
    if (memcmp_constante(hash, h->hash, 32) != 0)                     return V_HASH;         /* el contenido no es el que se firmó */

    if (!ecdsa_p256_verificar(CLAVE_PUBLICA, hash, h->firma))        return V_FIRMA;        /* firmado por quien tiene la clave privada */

    if (h->version_seguridad < contador_seguridad_leer())             return V_RETROCESO;    /* apartado siguiente */
    return V_OK;
}
/* La clave pública vive en la zona protegida del cargador (o su hash en OTP). Se usa una biblioteca probada, no criptografía propia. */

Tres precisiones de diseño que marcan la diferencia entre una verificación que protege y una que solo lo parece:

• Verificar en cada arranque, no solo al instalar. Si la verificación ocurre solo cuando llega la imagen (en la descarga), un atacante con acceso físico puede modificar la flash después, y el equipo ejecutará lo que quiera (es el clásico error «de tiempo de verificación a tiempo de uso»). El costo es tiempo de arranque: la Parte 5 estima, con supuestos explícitos (25 ciclos por byte para el hash y 15 millones de ciclos para verificar una firma ECDSA en software), unos 270 ms para una imagen de 256 KB a 80 MHz, 449 ms a 48 MHz y 128 ms a 168 MHz. Un acelerador de hash por hardware reduce mucho la parte del hash; la firma pesa lo mismo. Es un costo aceptable para casi todos los productos, y se puede acortar verificando solo el encabezado firmado y el hash en cada arranque cuando la flash está protegida.
• Ejecutar solo lo verificado. La verificación y la ejecución deben referirse a lo mismo: si se verifica una copia en RAM y se ejecuta otra en flash que puede cambiar entre medio, la comprobación no vale. Y la clave pública debe estar donde el atacante no pueda cambiarla (zona protegida contra escritura o OTP): una clave pública modificable es una puerta abierta.
• Comparar en tiempo constante (memcmp_constante, como la comparación del código en la cerradura del tema 27): una comparación que termina al primer byte distinto filtra, por su duración, cuántos bytes coinciden.

Los microcontroladores actuales ofrecen apoyo de hardware para esto, aunque los nombres y detalles varían por familia y hay que consultar la documentación de cada una: ROM de arranque con verificación de firma y claves en eFuses (por ejemplo, el arranque seguro del ESP32), niveles de protección de lectura y bloqueo del puerto de depuración (los niveles RDP de los STM32; APPROTECT en los nRF52), cifrado de la flash en el chip, zonas protegidas y, en los Cortex-M33, TrustZone, que separa un «mundo seguro» (claves, criptografía) de uno «no seguro» (la aplicación), de modo que un error en la aplicación no pueda leer las claves. Y no hace falta escribir el cargador desde cero: MCUboot es un cargador de código abierto que implementa firma (ECDSA, Ed25519, RSA), arranque de prueba con confirmación (el del tema 42) y protección contra el retroceso, y está portado a muchas familias.

04 · No volver al pasado

Protección contra el retroceso

La firma garantiza que una imagen es auténtica, no que sea reciente. Un atacante puede aprovecharlo: toma una versión vieja y legítima, firmada por el fabricante cuando era la última, con una vulnerabilidad que después se corrigió, y la instala en el equipo. La firma verifica perfectamente. Es el ataque de retroceso (rollback o downgrade), y obliga a que el equipo recuerde cuál es la versión mínima aceptable.

La solución usa un contador de versión de seguridad que solo puede crecer y que el atacante no puede bajar: se guarda en fusibles OTP o en una memoria con un contador monótono, no en la flash ordinaria. Cada imagen firmada lleva su versión de seguridad en el encabezado (cubierta por la firma, de modo que no se puede cambiar sin invalidarla). El cargador la compara con el contador y rechaza cualquier imagen con una versión menor. Cuando se confirma una imagen con una versión de seguridad mayor, el contador sube y no vuelve a bajar. La Parte 4 simula una secuencia de eventos:

Observá la distinción entre dos números de versión: la versión de funciones (1.1, 2.0, 2.1: la que ve el usuario) y la versión de seguridad (1, 2: la que cuenta el contador). Se separan a propósito. La vuelta atrás del tema 42 (de la 2.1 a la 2.0) debe poder funcionar, y como las dos tienen la misma versión de seguridad, el contador no la impide; en cambio volver a la 1.1, que tenía la vulnerabilidad, queda bloqueado. La versión de seguridad se sube solo cuando se corrige una vulnerabilidad (no con cada versión), precisamente para no cerrar la vuelta atrás sin necesidad.

El contador monótono tiene un costo: es irreversible. Los fusibles OTP tienen una cantidad finita de bits (algunos chips ofrecen decenas de incrementos), y subir el contador por error deja inutilizable la versión anterior. Se sube solo tras la confirmación de la nueva imagen, y con criterio.

05 · Lo que no debe salir del chip

Proteger el código, los datos y las claves

El arranque seguro protege la integridad (que corra lo firmado). Pero hay otro conjunto de amenazas que atacan la confidencialidad: leer lo que está dentro del equipo. Un atacante con un programador y un cable SWD puede, si el puerto de depuración está abierto, leer toda la flash: el código (y con él, el producto para clonarlo), las claves guardadas, los datos del usuario. Las defensas se apilan:

Algunas reglas que atraviesan todas las protecciones:

• Un secreto común a toda la flota es una bomba. Una clave (o una contraseña) idéntica en todos los equipos equivale a que cualquiera que extraiga una comprometa todas (lo que mostró la Parte 3 con el HMAC). Cada equipo debe tener sus propias credenciales, generadas e instaladas en la fábrica (provisionamiento), o derivadas de un secreto maestro y del número de serie del equipo.
• Nunca credenciales por defecto ni claves escritas en el código. Una clave dentro del firmware está en cada copia del firmware, y quien lo lea la tiene. Es el error de Mirai.
• Números aleatorios de calidad. Las claves, los nonces y los canarios (tema 31) necesitan un generador de números aleatorios por hardware (TRNG). Un generador predecible (por ejemplo, rand() con la semilla del reloj) vuelve inútil toda la criptografía que depende de él.
• Borrado seguro: las claves en RAM se borran cuando ya no se usan, con una escritura que el compilador no elimine (memset_s o una escritura volatile, como en el tema 27).
• Ataques físicos más finos: con equipo especializado, un atacante puede medir el consumo o el tiempo de ejecución para deducir una clave (ataques de canal lateral) o provocar fallas con un pico de tensión para saltarse una comprobación (inyección de fallas, glitching). Las defensas son específicas (comparaciones en tiempo constante, comprobaciones duplicadas, hardware con contramedidas) y justifican un elemento seguro cuando el activo vale mucho.

Una advertencia sobre la ofuscación: ocultar el código con trucos (nombres confusos, saltos innecesarios) no es seguridad: retrasa a un atacante, no lo detiene, y da una falsa sensación de protección. La seguridad se apoya en mecanismos con garantías (firmas, claves, hardware de protección) cuyo funcionamiento puede ser público: el principio de Kerckhoffs dice que un sistema debe ser seguro aunque todo salvo la clave sea conocido por el atacante.

06 · Menos puertas, mejor cerradas

Código seguro y la superficie de ataque

La criptografía más fuerte es inútil si el firmware tiene un desbordamiento de buffer que permite ejecutar código ajeno: las técnicas de los temas 31 y 39 (validar las entradas, límites siempre comprobados, canario, MPU) son también defensas de seguridad, porque un error de memoria es el primer escalón de un ataque remoto. Además, la seguridad pide una disciplina propia:

Un caso que sorprende a quienes empiezan: TLS necesita saber la hora. Para verificar el certificado de un servidor hay que comprobar que no venció, y un microcontrolador que arranca sin reloj de tiempo real no sabe qué día es. Hay equipos que resuelven la dificultad no verificando la fecha, o aceptando cualquier certificado, y con eso anulan la protección. La solución es tener una fuente de tiempo confiable (un RTC con batería o un servicio de tiempo autenticado) o validar el certificado por otro medio (fijar el certificado o la clave pública del servidor en el firmware: certificate pinning).

Y el eslabón que muchas veces se olvida es el propio mecanismo de actualización: es el camino más directo para tomar el control de todo el equipo, y por eso es el que más cuidado merece. Una actualización firmada, con verificación en cada arranque y protección contra el retroceso, convierte la mayor debilidad (una puerta que permite cambiar el programa) en la mayor fortaleza (la forma de corregir cualquier defecto de seguridad que se descubra después).

07 · El secreto que sostiene todo

Gestión de claves

Todo el esquema descansa en que la clave privada de firma no se filtre. Si se roba, el atacante puede firmar el firmware que quiera, y todos los equipos lo aceptarán: ninguna política del cargador lo detecta, porque la firma es auténtica (es el último escenario del laboratorio). Por eso la gestión de claves es la parte más importante, y la menos vistosa, de un firmware seguro:

El caso más duro es la revocación: un equipo ya fabricado, con una clave pública grabada en un fusible, no puede «olvidar» esa clave si se filtra la privada. Solo las claves previstas de antemano (varios huecos de claves, o una jerarquía) permiten la rotación. Es otra decisión que se toma antes de fabricar, como la estrategia de actualización del tema 42: un producto que sale con una sola clave y sin capacidad de cambiarla, si esa clave se compromete, queda sin remedio.

08 · Atacar tu propio producto

Verificación y diagnóstico

La seguridad se verifica con pruebas negativas: en lugar de comprobar que lo bueno funciona, se intenta hacer lo malo y se comprueba que se rechaza. Cada una de estas pruebas debe fallar de la manera prevista:

09 · Analogía con programación

Probar el modelo en Python

El programa reúne cinco demostraciones: la falsificación de un CRC-32 (el atacante modifica el código y calcula cuatro bytes de relleno que restauran el CRC original); el efecto avalancha de SHA-256 al cambiar un solo bit; la comparación entre un HMAC con clave compartida y una firma de juguete con clave pública; una política de versión de seguridad con contador monótono; y el costo de verificar una imagen en cada arranque con supuestos explícitos.

# Firmware seguro: un CRC se falsifica, un hash no; HMAC contra firma; la política contra el retroceso; y cuánto cuesta verificar en cada arranque.
import zlib, hashlib, hmac, random

# ---- Parte 1: falsificar un CRC-32 --------------------------------------------------------------------------------------
T = []
for n in range(256):
    c = n
    for _ in range(8): c = (c >> 1) ^ 0xEDB88320 if c & 1 else c >> 1
    T.append(c)
INDICE = {T[i] >> 24: i for i in range(256)}                   # el byte alto de cada entrada de la tabla es único

def forjar(datos, objetivo):
    """Devuelve 4 bytes que, agregados a 'datos', hacen que su CRC-32 valga 'objetivo'."""
    s = zlib.crc32(datos) ^ 0xFFFFFFFF                          # estado interno tras procesar 'datos'
    x, indices = objetivo ^ 0xFFFFFFFF, []
    for _ in range(4):                                          # se recorre el cálculo al revés, un byte por vez
        i = INDICE[x >> 24]; indices.append(i)
        x = ((x ^ T[i]) << 8) & 0xFFFFFFFF
    parche = bytearray()
    for i in reversed(indices):                                 # y se recorre hacia adelante para hallar los bytes
        parche.append((s & 0xFF) ^ i)
        s = (s >> 8) ^ T[i]
    return bytes(parche)

rnd = random.Random(7)
original = bytes(rnd.randrange(256) for _ in range(4096))       # el firmware legítimo
malicioso = bytearray(original); malicioso[100:104] = b"EVIL"   # el atacante cambia código
crc_legitimo = zlib.crc32(original)
parche = forjar(bytes(malicioso), crc_legitimo)
malicioso_forjado = bytes(malicioso) + parche
print("Parte 1: el atacante modifica el firmware y corrige el CRC con 4 bytes de relleno")
print(f"  CRC-32 del firmware legítimo : {crc_legitimo:#010x}")
print(f"  CRC-32 sin corregir          : {zlib.crc32(bytes(malicioso)):#010x}  (el cargador lo rechazaría)")
print(f"  CRC-32 del malicioso forjado : {zlib.crc32(malicioso_forjado):#010x}  (bytes de relleno: {parche.hex()}); coincide: {zlib.crc32(malicioso_forjado) == crc_legitimo}")
print(f"  SHA-256 del legítimo  : {hashlib.sha256(original).hexdigest()[:32]}...")
print(f"  SHA-256 del malicioso : {hashlib.sha256(malicioso_forjado).hexdigest()[:32]}...  (no se puede forjar a voluntad)")

# ---- Parte 2: el efecto avalancha de un hash -------------------------------------------------------------------------------
base = hashlib.sha256(original).digest()
cambios = []
for k in range(1000):
    d = bytearray(original); bit = rnd.randrange(len(d) * 8); d[bit // 8] ^= 1 << (bit % 8)
    h = hashlib.sha256(bytes(d)).digest()
    cambios.append(sum(bin(a ^ b).count("1") for a, b in zip(base, h)))
print()
print("Parte 2: cambiar 1 solo bit de una imagen de 4 KB, 1000 veces")
print(f"  bits distintos del SHA-256 (de 256): mínimo {min(cambios)}, promedio {sum(cambios) / len(cambios):.1f}, máximo {max(cambios)}")
print("  un hash se comporta como un sorteo: no hay forma de elegir qué cambios producen un hash dado (para un CRC, sí: Parte 1)")

# ---- Parte 3: HMAC (clave compartida) frente a una firma (clave privada y pública) -----------------------------------------
clave_flota = b"clave-de-toda-la-flota"
tag = hmac.new(clave_flota, original, hashlib.sha256).digest()
print()
print("Parte 3: autenticar una imagen")
print(f"  HMAC con la clave de la flota: verifica la imagen original: {hmac.compare_digest(tag, hmac.new(clave_flota, original, hashlib.sha256).digest())}")
print(f"  el mismo HMAC sobre la imagen maliciosa: {hmac.compare_digest(tag, hmac.new(clave_flota, malicioso_forjado, hashlib.sha256).digest())}")
extraida = clave_flota                                           # alguien extrae la clave de UN solo equipo
tag_falso = hmac.new(extraida, malicioso_forjado, hashlib.sha256).digest()
print(f"  con la clave extraída de un equipo, el atacante firma lo que quiera y el HMAC verifica: {hmac.compare_digest(tag_falso, hmac.new(clave_flota, malicioso_forjado, hashlib.sha256).digest())}")
print("  (el equipo necesita la misma clave para verificar que la que se usa para firmar: robar un equipo compromete toda la flota)")
# Firma de juguete (RSA con números chicos, SOLO para ver el mecanismo; no es seguro):
p, q = 2147483647, 2147483629
n, e = p * q, 65537
d = pow(e, -1, (p - 1) * (q - 1))                                # la clave privada: solo la tiene quien firma
def firmar(img): return pow(int.from_bytes(hashlib.sha256(img).digest(), "big") % n, d, n)
def verificar(img, firma): return pow(firma, e, n) == int.from_bytes(hashlib.sha256(img).digest(), "big") % n
firma = firmar(original)
print(f"  firma de juguete (RSA de {n.bit_length()} bits): el equipo guarda solo la clave PÚBLICA (n, e={e}); verifica el original: {verificar(original, firma)}")
print(f"  verifica la imagen maliciosa con esa firma: {verificar(malicioso_forjado, firma)}; con una firma inventada por el atacante: {verificar(malicioso_forjado, 123456789)}")
print("  la clave pública sirve para VERIFICAR pero no para FIRMAR: robar un equipo no permite firmar imágenes (en la práctica: ECDSA o Ed25519, claves de 256 bits o RSA de 2048 o más)")

# ---- Parte 4: política contra el retroceso ----------------------------------------------------------------------------------
print()
print("Parte 4: versión de seguridad frente a un contador monótono guardado en el equipo (fusibles u OTP)")
contador, instalada = 1, ("1.0", 1)
eventos = (("instalar 1.1 (seguridad 1)", ("1.1", 1)), ("instalar 2.0 (seguridad 2, corrige una vulnerabilidad)", ("2.0", 2)),
           ("el atacante instala la 1.1, FIRMADA y legítima, para explotar la vulnerabilidad", ("1.1", 1)),
           ("instalar 2.1 (seguridad 2)", ("2.1", 2)), ("la 2.1 no pasa la prueba: volver atrás a la 2.0 (seguridad 2)", ("2.0", 2)), ("volver atrás a la 1.1", ("1.1", 1)))
for texto, (ver, seg) in eventos:
    if seg < contador: decision = f"RECHAZADA (seguridad {seg} < contador {contador})"
    else:
        decision = "aceptada"; instalada = (ver, seg)
        if seg > contador: contador = seg; decision += f"; tras confirmar, el contador sube a {contador}"
    print(f"  {texto:<80} -> {decision}")

# ---- Parte 5: cuánto cuesta verificar en cada arranque ---------------------------------------------------------------------
print()
print("Parte 5: costo aproximado de verificar una imagen de 256 KB en cada arranque (SUPUESTOS: 25 ciclos por byte para SHA-256 en software; 15 millones de ciclos para verificar una firma ECDSA P-256)")
for mhz in (48, 80, 168):
    sha = 256 * 1024 * 25 / (mhz * 1e6) * 1000
    ecdsa = 15e6 / (mhz * 1e6) * 1000
    print(f"  núcleo a {mhz:>3} MHz: hash {sha:6.1f} ms + firma {ecdsa:6.1f} ms = {sha + ecdsa:6.1f} ms por arranque")

Resultado, parte 1: el firmware legítimo tiene el CRC-32 0x09990583; al cambiar 4 bytes, el CRC pasa a 0x0dac6e0a y el cargador del tema 42 lo rechazaría; pero con 4 bytes de relleno (1d6a8fb6), el CRC de la imagen maliciosa vuelve a ser 0x09990583: coincide. El SHA-256 de ambas es totalmente distinto. Parte 2: al cambiar 1 bit de una imagen de 4 KB, 1000 veces, el SHA-256 cambia en promedio 128,1 de sus 256 bits (de 104 a 153). Parte 3: el HMAC con la clave de la flota verifica la imagen original y rechaza la maliciosa, pero con la clave extraída de un solo equipo el atacante firma lo que quiere y verifica; con una firma de juguete (RSA de 62 bits) el equipo solo guarda la clave pública y verifica el original, y rechaza la imagen maliciosa y una firma inventada. Parte 4: con el contador en 1, se aceptan la 1.1 y la 2.0 (que sube el contador a 2); la 1.1 firmada que instala el atacante se rechaza (1 < 2); se acepta la 2.1 y la vuelta atrás a la 2.0 (la vuelta atrás legítima sigue funcionando); y volver a la 1.1 se rechaza. Parte 5: verificar 256 KB cuesta unos 449 ms a 48 MHz (136,5 de hash y 312,5 de firma), 269 ms a 80 MHz y 128 ms a 168 MHz.

Probá cambiar el objetivo del CRC en la Parte 1 a cualquier valor (forjar(datos, 0xDEADBEEF)) y verificá que siempre se puede lograr, o hacé que el atacante cambie el firmware en una posición distinta. La lección del programa es la distinción central del tema: un CRC protege contra la mala suerte, y solo una firma protege contra la mala intención. Y el RSA de juguete es solo para ver el mecanismo: con 62 bits se factoriza en segundos; en la práctica se usan curvas elípticas de 256 bits o RSA de 2048 bits o más, siempre con una biblioteca probada.

10 · Exploración interactiva

Tres políticas de arranque

El laboratorio compara tres políticas de un cargador frente a seis imágenes: una legítima, una dañada por ruido, una maliciosa con el CRC corregido, una vieja con una vulnerabilidad pero firmada, una firmada con otra clave y una firmada con la clave robada del fabricante. Las políticas son solo CRC (el cargador del tema 42), CRC + firma y CRC + firma + anti-retroceso. El equipo ya tiene el contador de seguridad en 2. Las celdas en rojo son errores: una imagen maliciosa aceptada, o una legítima rechazada.

—

Recorrido guiado

1. Elegí la imagen 1 (legítima y reciente): las tres políticas la aceptan. Es el comportamiento correcto, y la referencia para comparar las demás.
2. Elegí la imagen 2 (dañada por ruido): las tres la rechazan, hasta la de solo CRC. Es el caso para el que sirve el CRC, y por eso parece suficiente cuando uno solo prueba con errores accidentales.
3. Elegí la imagen 3 (maliciosa con el CRC corregido): la política de solo CRC la acepta (celda roja) y las otras dos la rechazan porque la firma no verifica. Es la demostración de que el CRC no autentica.
4. Elegí la imagen 4 (vieja, firmada, con una vulnerabilidad): solo la política con anti-retroceso la rechaza. «CRC + firma» la acepta, porque la firma es auténtica; la versión de seguridad 1 es menor que el contador 2.
5. Elegí la imagen 5 (firmada por el atacante con su propia clave): el CRC solo la acepta; las que verifican firma la rechazan, porque la clave no es la que el equipo tiene como confiable.
6. Elegí la imagen 6 (firmada con la clave robada del fabricante): las tres políticas la aceptan. Ningún mecanismo del cargador puede detectarla, porque la firma es auténtica. La defensa está fuera del cargador: proteger la clave en un HSM, poder revocarla y rotarla, y detectar el daño con el despliegue escalonado (tema 42).

11 · Método de trabajo

Método: diseñar con un enemigo

1. Hacé el modelo de amenazas: activos, atacantes (remoto, cercano, físico, cadena de suministro) y vectores. Decidí el nivel de protección en proporción a lo que se defiende.
2. Eliminá primero lo evidente: sin credenciales por defecto, sin claves en el código, sin interfaces que no se usan, sin puertos de depuración abiertos en producción.
3. Distinguí integridad de autenticidad: el CRC para el ruido, una firma para el atacante. Verificá la firma de toda imagen, y con un hash criptográfico, nunca con un CRC.
4. Usá firma asimétrica: el equipo solo tiene la clave pública. Con una biblioteca probada (MCUboot, mbed TLS, TinyCrypt), nunca criptografía propia.
5. Armá la cadena de confianza: una raíz inmutable (ROM y fusibles) que verifica el cargador, que verifica la aplicación, en cada arranque; con la clave pública en una zona protegida.
6. Agregá protección contra el retroceso: versión de seguridad firmada y contador monótono; subirla solo al corregir vulnerabilidades y tras confirmar.
7. Protegé el contenido: protección de lectura y cierre del puerto de depuración en producción, cifrado de la flash y de las actualizaciones si la propiedad intelectual lo justifica, y un elemento seguro si hay claves de valor.
8. Hacé que cada equipo sea único: credenciales por equipo, provisionadas en fábrica, y un generador aleatorio por hardware.
9. Gestioná las claves como un activo crítico: clave privada en un HSM, jerarquía, varias claves de verificación para poder rotar, separación de funciones en la firma y un plan para el compromiso.
10. Probá atacando: imágenes sin firma, modificadas, con CRC corregido, de otra clave y viejas; encabezados mentirosos; flash modificada en reposo; y verificá el estado de las protecciones en unidades de producción.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Ejercicios

1. Fuerza bruta

Un atacante quiere encontrar una imagen maliciosa con un SHA-256 determinado probando al azar, a razón de 10¹² intentos por segundo. ¿Cuántos años tarda en probar todas las posibilidades (2²⁵⁶)? ¿Y para un CRC-32 (2³² posibilidades), si no supiera la técnica de los 4 bytes?

2. Presupuesto de arranque

Una imagen de 128 KB se verifica en cada arranque con un núcleo a 48 MHz, con 25 ciclos por byte para el hash y 15 millones de ciclos para la firma. ¿Cuánto tarda cada parte y el total? Si el requisito es que el equipo arranque en menos de 400 ms, ¿se cumple?

3. El contador de seguridad

El contador del equipo vale 3. Llegan, firmadas por el fabricante, imágenes con estas versiones de seguridad: A (3), B (2), C (4). ¿Cuáles acepta? Si instala y confirma la C, ¿qué pasa después con la A?

4. Robar un equipo

Un atacante extrae las claves de un solo equipo de una flota de 100 000. ¿Qué puede hacer si la flota usa: (a) un HMAC con una clave común, (b) un HMAC con una clave distinta por equipo, (c) una firma con clave pública en el equipo?

5. Modelo de amenazas

Armá, en pocas líneas, el modelo de amenazas de dos productos: (a) un sensor de temperatura de un depósito, alimentado por pilas, que envía datos por LoRa; (b) la cerradura con teclado del tema 27 en una oficina. ¿Cuál es el activo principal, el atacante más probable y la defensa que no puede faltar?

6. El momento de la verificación

Un cargador verifica la firma de la imagen solo al recibirla por la red. Un atacante con acceso físico al equipo reescribe la flash con un programador, cambiando una instrucción. ¿Qué pasa? ¿Qué dos cambios lo evitan?

14 · Síntesis del bloque

Ideas para recordar

¿Listo para el bloque siguiente?

Antes de avanzar, hacé el modelo de amenazas de un producto tuyo en una hoja: tres activos, los atacantes posibles y la defensa más barata para cada combinación. Después respondé: ¿el cargador acepta una imagen con un CRC correcto y nada más?, ¿se puede volver a una versión vieja?, ¿el puerto de depuración está cerrado en producción?, ¿hay alguna clave o contraseña dentro del binario? Cada «sí» a la primera, tercera o cuarta es una puerta abierta.

En el próximo bloque pasamos de construir a encontrar los errores: la depuración y las pruebas. Empezamos con la depuración básica: LEDs, pines de prueba, salida por consola y registro de eventos, las herramientas que se usan cuando el equipo no hace lo que debe y no hay un depurador a mano.