Bootstrapping Seguro de Dispositivos IoT
¿Que es el Bootstrapping?
Según el Internet Engineering Task Force (IETF), el proceso de Bootstrapping se define como cualquier proceso que tiene lugar antes de que un dispositivo pueda volverse operativo.
Pero ¿cuales son los principales procesos implicados?
Pues básicamente estaríamos hablando de tres:
Procesos de fabricación: Que como no puede ser de otra manera, comprende todos los procesos implicados hasta la distribución del dispositivo.
Bootstrapping de credenciales: Que ocurrirá durante el arranque inicial, ya sea la primera vez o después de un reinicio del dispositivo.
Operación de servicio: Momento en el cual el dispositivo ya cumple con todos los requisitos y dispone de la información necesaria para operar el servicio para el cual fue configurado.
¿Cuales son los aspectos mas importantes a tener en cuenta?
Como todo, si entramos en detalle podríamos enumerar gran cantidad, pero como antes nos centraremos en tres:
Autenticidad: Garantizando que el dispositivo es quien debe ser y que se comunicara con el servicio correcto.
Integridad: Evitando que el firmware o los datos tratados por el dispositivos sean accesibles y/o modificados sin autorización.
Confidencialidad: Procurando que desde el arranque inicial, cualquier comunicación que se deba realizar con otros sistemas, se realice mediante un protocolo seguro.
¿Que soluciones existen en el mercado?
Pues teniendo en cuenta solo las de acceso libre y mas utilizadas, vamos a ver de forma rápida alguna de ellas:
Lightweight Machine-to-Machine (LwM2M)
Introduce un enfoque cliente-servidor para realizar el arranque. En el paso de aprovisionamiento, el servidor es responsable de proporcionar las credenciales esenciales al cliente. Luego, el dispositivo cliente realiza el paso de registro con uno o más servidores LwM2M. El estándar presenta cuatro enfoques de arranque:
Factory Bootstrap: el fabricante integra la información de arranque necesaria en el dispositivo IoT antes de su implementación.
Smart card Bootstrap: la información de arranque necesaria se recupera de una tarjeta inteligente.
Client Initiated Bootstrap: el cliente es responsable de recuperar la información necesaria del servidor de arranque pre-configurado.
Server Initiated Bootstrap: el servidor configura automáticamente los dispositivos IoT una vez que se conectan a la red del usuario.
Open Connectivity Foundation (OCF)
Define la fase de aprovisionamiento del dispositivo, denominada Owner Transfer Methods (OTM). En este paso, la herramienta de incorporación (dispositivo del usuario) y el objeto IoT comparten la información necesaria para establecer un canal de comunicación seguro. El OTM adoptado puede ser específico de cada fabricante o puede ser una implementación de una técnica existente.
El estándar especifica los siguientes OTM:
Just Works: el dispositivo realiza un intercambio de claves Diffie-Hellman no autenticado que da como resultado el establecimiento de una clave de sesión simétrica.
Random PIN: el objeto IoT genera un número de identificación personal (PIN) de 40 bits que debe ingresarse en el dispositivo de incorporación.
Manufacturer Certificate: el fabricante incorpora un certificado digital en el objeto de IoT que se utiliza posteriormente para autenticar el dispositivo.
Vendor Specific: el proveedor es responsable de implementar su propio método de transferencia de acuerdo con sus necesidades.
Wi-Fi Alliance Device Provisioning Protocol
El protocolo de aprovisionamiento de dispositivos (DPP) de Wi-Fi Alliance [14] se utiliza para el establecimiento de una conectividad segura y sencilla para los dispositivos asociados. El proceso de asociación en DPP se denomina Aprovisionamiento e introduce dos roles: Configurador y Afiliado. El primer rol representa el dispositivo confiable del usuario que realiza el aprovisionamiento con el objeto de IoT, denominado Enrollee. Este procedimiento consta de tres fases que deben ejecutarse de forma secuencial:
Bootstrapping: el objetivo de esta fase es permitir que el inscrito comparta de forma segura su información de bootstrapping con el configurador. El afiliado debe transferir estos parámetros, como la clave pública ECDH, a través de un canal auxiliar. La transferencia puede realizarse mediante un escáner de código QR en el configurador o una tecnología de comunicación de campo cercano (NFC).
Autenticación: El primer objetivo de esta fase es permitir que el configurador comparta su clave pública con el inscrito en caso de que el intercambio de arranque en el paso anterior fuera unidireccional (del inscrito al configurador). Esta fase puede ser iniciada por los dos roles y permite la autenticación de la clave pública del respondedor por parte del iniciador. La autenticación mutua en las claves públicas DH podría ser posible si el intercambio de arranque en el canal auxiliar fuera bidireccional.
Configuración: El objetivo de esta fase es permitir compartir de forma segura los parámetros de configuración entre el configurador y el inscrito. Estos parámetros pueden incluir el identificador de conjunto de servicios (SSID) y la fase de paso del punto de acceso Wi-Fi.
Fast IDentity Online Alliance (FIDO)
La Fast IDentity Online (FIDO) Alliance [15] describe un enfoque de arranque, conocido como Device Onboarding, que instala claves secretas y datos de configuración en el objeto de IoT. Este protocolo facilita la implementación segura y la interacción del dispositivo con una plataforma IoT. El protocolo de incorporación de FIDO introduce cuatro funciones:
The manufacturer: esta función realiza el protocolo de inicialización del dispositivo (DI) que inserta las credenciales integradas de FIDO en el objeto de IoT durante el proceso de fabricación. Crea el Comprobante de Propiedad (OV) que es la información de identificación del futuro propietario. Por lo tanto, sólo los usuarios que tengan el OV correcto pueden realizar el proceso de incorporación.
The device: esta función representa el objeto de IoT que debe tener un entorno operativo restringido (ROE) para almacenar de forma segura las credenciales criptográficas y ejecutar las operaciones FIDO. El ROE es un entorno de ejecución confiable que garantiza la confidencialidad e integridad de los cálculos que se realizan en su interior.
The owner: este rol representa al usuario que posee un OV válido para realizar el proceso de incorporación. La transferencia del bono del fabricante al propietario no está especificada en la norma.
The rendez-vous server: esta función representa el servidor de autenticación que autentica por separado al propietario y al dispositivo. Posteriormente, este servidor proporciona al dispositivo la dirección IP del propietario para poder realizar el proceso de autenticación final.
Conclusiones
Como se puede ver cada una de estas soluciones aporta un método, proceso o tecnología que intenta cumplir con los factores comentados al principio del articulo. Ninguna es mejor que otra, solo ofrecen capacidades similares con medios distintos, por lo que el secreto del éxito de nuestro proyecto residirá en elegir la que se ajuste mejor a nuestras necesidades, aunque incluso la solución se encuentre en la combinación de mas de una de estas tecnologías.
Por supuesto siempre tenemos la posibilidad de basándonos en los principios básicos de la seguridad, en este caso de la seguridad IoT, de construir una solución que cumpla con nuestras necesidades y forma segura, en el siguiente enlace puede ver un vídeo demostrativo sobre una solución básica adhoc, que he construido como prueba de concepto.
Referencias
Dejo algunos enlaces para los que deseen investigar un poco sobre el tema:
O. Garcia-Morchon, S. Kumar, and M. Sethi, “Internet of things (iot) security: State of the art and challenges,” Internet Requests for Comments, RFC Editor, RFC 8576, 2019. - https://www.rfc-editor.org/rfc/rfc8576.html
Sethi, M., Sarikaya, B., Garcia-Carrillo, D.: Secure IoT Bootstrapping: A Survey. Internet-Draft draft-sarikaya-t2trg-sbootstrapping-11 (Feb 2021), https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping-11
L. F. Rahman, T. Ozcelebi, and J. Lukkien, “Understanding iot systems: a life cycle approach,” Procedia computer science, vol. 130, pp. 1057–1062, 2018. - https://www.sciencedirect.com/science/article/pii/S1877050918305106?ref=pdf_download&fr=RR-2&rr=8abfdbd4c97a1a7c
Lindgren, A., Ahlgren, B.: OMA Lightweight M2M for Management of Information Centric Networks. Internet-Draft draft-lindgren-icnrg-lwm2m4icn-00 (Nov 2017), https://datatracker.ietf.org/doc/html/draft-lindgren-icnrg-lwm2m4icn-00
Open Connectivity Foundation, I.: Ocf security specification (2017), https://openconnectivity.org/specs/OCF_Security_Specification_v1.0.0.pdf
Alliance, W.F.: Device provisioning protocol specification v3.0 - https://www.wi-fi.org/system/files/Wi-Fi_Easy_Connect_Specification_v3.0.pdf
Cooper, G., Behm, B., Chakraborty, A., Kommalapati, H., Mandyam, G., ARM, H.T., Bartsch, W.: Fido device onboard specification 1.1 (2021) - https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-RD-v1.1-20211214/FIDO-device-onboard-spec-v1.1-rd-20211214.pdf