Firmware over the air (FOTA) es un nombre general para realizar actualizaciones de SW de forma remota.
Supongamos que tengo un microcontrolador con memoria RW y un cargador de arranque.
¿Cuál es la forma correcta de hacer actualizaciones de SW de forma segura (a través de Bluetooth o incluso un medio de comunicación no seguro)?
Necesitas suficiente almacenamiento para mantener la versión anterior al instalar la nueva, y cambiar para iniciar desde la nueva versión después de que se complete la instalación debe ser una operación atómica, para que el sistema no pueda dejar el sistema sin poder iniciarlo. fallo de alimentación a mitad del proceso.
TL;DR:
En su sistema de distribución:
En el dispositivo:
Primero, generas un par de llaves en tu sistema de compilación. Tendrás claves públicas y privadas. Coloque la clave pública en el firmware original de los dispositivos enviados. Esta es la versión inicial. Mantenga la clave privada en un almacenamiento seguro, idealmente dentro de una computadora desconectada (sin acceso a la red).
Cuando lanza una actualización, debe usar la clave privada creada anteriormente para firmar el paquete de actualización. Puede agregar el paquete a un archivo zip, junto con un archivo de texto que contenga la firma que generó anteriormente. Envía el archivo al microcontrolador.
Después de recibir el archivo zip, el microcontrolador descomprimirá la firma y la actualización, ejecutará una comprobación de firma y comparará la firma resultante con la firma en el archivo zip. Si son iguales, la integridad del paquete está asegurada y te conoce (y no a otra persona) que creó el paquete.
Si no tiene suficiente memoria para descomprimir y verificar, debe crear un formato de archivo especial que contenga la firma y la actualización. Incluso puede implementar SHA256HMAC en un microcontrolador.
Como dijo Mike Scott, después de enviar la actualización, debe implementar algún proceso para reemplazar de forma automática el firmware actual por el nuevo. He visto un sistema que crea dos particiones en el almacenamiento y uso una para el firmware actual y otra para las actualizaciones. Después de aplicar y verificar la actualización, se establece un indicador en el cargador de arranque para indicar qué partición se debe cargar. Y puede cambiar el cargador de arranque para indicar qué partición cargará durante el arranque.
Insistiría en un factor secundario de algún tipo. Dicha autenticación se hereda al empujar un cable en la unidad para que parpadee manualmente, pero falta en OTA. Desea asegurarse de que el dispositivo se debe actualizar antes de permitir que se actualice. Pocos esquemas completamente digitales han demostrado ser sólidos todavía, por lo que (paranoico) me gusta retroceder a la seguridad física.
Aquí hay algunos factores de autenticación simples que pueden funcionar:
Un secreto compartido presentado en el momento de la actualización, utilizado para autenticar al propietario del dispositivo. Por ejemplo, puede imprimir un código en la parte inferior del dispositivo, siempre que no esté disponible digitalmente de forma remota. Puedes usar algún tipo de cosa de sal y hachís para verificarlo sin revelarlo.
Un botón o interruptor físico para ingresar al "modo de actualización". Esto solo permite un cambio de firmware después de la activación, evitando que los atacantes remotos apliquen nuevas imágenes. Esta es probablemente la opción más segura, pero requiere hardware, todo es menos que hardware barato.
Un interruptor lógico de algún tipo. Por ejemplo, una regla que establece que los usuarios solo pueden actualizar el firmware dentro de los 90 segundos de encendido. if(sys_millis()>90000)return go_to_hell(); Esto significa que tiene que apagar y encender el dispositivo para desbloquearlo, algo que puede ser difícil / imposible para que un atacante remoto lo saque. O tal vez tenga que enchufar y desenchufar algo conectado al dispositivo 3 veces seguidas para desbloquearlo. En muchos casos, estos factores pueden implementarse exclusivamente en software en un diseño existente.
todos estos métodos de autenticación servirán para evitar actualizaciones no autorizadas. En lo que respecta a la seguridad de su código real o claves de cifrado, eso es más una cuestión de stackoverflow. No necesita para cifrar (o incluso firmar) el firmware si publica hashes para permitir que el usuario se valide automáticamente y autorice al usuario (y solo al usuario) a actualizar el código.
Tenga en cuenta que aún puede enviar actualizaciones OTA completas, pero hacer que almacene internamente la nueva imagen y espere a que el usuario se autentique antes de parpadear; quizás utilizando un led parpadeante o simplemente un correo electrónico para notificar a los usuarios que las actualizaciones están listas.
Lea otras preguntas en las etiquetas public-key-infrastructure encryption digital-signature embedded-system software-engineering