Raspberry Pi actualizó su software oficial de secure boot y provisioning en fábrica, rpi-sb-provisioner, con una versión 2.3 enfocada en dos frentes: permitir armar imágenes de sistema operativo más complejas y desplegar Raspberry Pi Connect a escala en flotas de equipos.
El upgrade se apoya en el nuevo soporte de identidad de dispositivo dentro de Raspberry Pi Connect for Organisations, la variante para empresas del servicio de conexión remota. Con 2.3, cada Pi puede recibir una identidad inmutable durante el flasheo y quedar automáticamente atado a la cuenta corporativa de la organización.
¿Qué cambia en la forma de armar las imágenes?
Las versiones previas del rpi-sb-provisioner asumían que se trabajaba con una imagen tipo Raspberry Pi OS creada con pi-gen. Ese supuesto quedó corto: la comunidad pedía layouts más complejos y un flujo más ergonómico para construir imágenes propias.
La respuesta es Image Description Provisioning (IDP), un mecanismo introducido dentro de rpi-image-gen que ahora se integra directamente en rpi-sb-provisioner 2.3. IDP transforma la herramienta de un provisioner de función fija a un sistema programable, capaz de aceptar layouts arbitrarios de partición, tipos de sistema de archivos y una lista amplia de atributos configurables.
IDP también funciona con sistemas operativos que no se hayan creado con rpi-image-gen. Como resume la propia Raspberry Pi: si podés describirlo, podés provisionarlo.
¿Cómo funciona rpi-fw-crypto y qué protege?
El otro cambio de fondo es la llegada de rpi-fw-crypto, un mecanismo para usar criptografía asimétrica sin exponer la clave privada única que rpi-sb-provisioner escribe dentro del silicio del Pi. La versión 2.3 lo aprovecha en dos capas concretas:
- En el servidor de provisioning: para cifrar y "bindear" el material de firma —un archivo PEM o el PIN de un HSM— al servidor específico que provisiona. Si alguien roba el disco del servidor, no obtiene una clave utilizable en otra máquina.
- En los dispositivos provisionados: como uno de los materiales que alimentan el cálculo de la clave de cifrado de disco completo (FDE), ya sea a través del entorno de autenticación pre-boot que provee Raspberry Pi o de uno construido con rpi-image-gen.
En términos prácticos, el Pi puede terminar con un disco cifrado con una llave derivada del hardware sin necesidad de mantener un secreto en claro dentro del filesystem, un paso que hasta ahora exigía scripting a mano para cada flota.
¿Qué gana el integrador industrial?
Para el integrador —el actor real al que apunta esta release— la 2.3 cierra tres frentes que antes obligaban a soluciones a medida:
1. Identidad de dispositivo controlada por la organización, no por el fabricante que arma la imagen. 2. Imágenes arbitrarias con layouts personalizados, sin forkear pi-gen ni mantener flujos paralelos de firma. 3. FDE con clave derivada del hardware integrada al flujo estándar, útil para dispositivos que salen del laboratorio hacia entornos físicamente expuestos.
Todo esto queda documentado en el release oficial del proyecto en GitHub. El pack aplica a los modelos actuales de Raspberry Pi con soporte de secure boot en el bootloader, incluidos Pi 4, Pi 5 y variantes CM4/CM5, que son la base habitual de deployments industriales en Chile y la región.
