Cadena de firmware y actualizaciones firmadas

Una actualización firmada lleva una firma digital hecha con una llave privada que el fabricante guarda en un módulo de seguridad. El dispositivo trae grabada la llave pública correspondiente en su raíz de confianza y comprueba la firma antes de escribir en memoria. Si la firma no coincide, no se instala.

Que el portal de descargas solo reciba paquetes firmados es una buena medida, pero no sustituye la verificación en el dispositivo: el paquete viaja por correo, por memorias y por redes de terceros hasta llegar a la subestación.

La política separa las llaves: la de producción vive en un HSM y firma lo que sale a clientes; las de pruebas solo firman paquetes del banco de pruebas. Una llave de pruebas que firma un paquete de producción es un hallazgo aunque el dispositivo acepte la firma, porque esas llaves se manejan con menos controles.

Abre el registro de firma y mira la llave de cada paquete frente a su destino.

Un dispositivo lleva un contador de versión y rechaza paquetes de versión menor, aunque la firma sea válida. Es la protección contra retroceso: sin ella, alguien podría presentar un paquete viejo, auténtico pero con una vulnerabilidad ya conocida.

Lee el registro de la herramienta de carga del dispositivo y fíjate en qué paquete se rechazó y por qué razón, no por la firma.

Una regla de dos personas solo vale si se puede comprobar. El registro de firma guarda cuántas personas aprobaron cada paquete. Cuenta los paquetes publicados con destino producción que salieron con un solo aprobador, sin contar los del banco de pruebas.

Ya está en el portal de clientes y algunos técnicos pueden haberlo descargado. No se trata de esconderlo ni de culpar a alguien: se trata de contener el daño con lo que existe y dejar la cadena en regla.