Los datos se han comparado con productos básicos como el petróleo o el oro. En este mundo conectado, cada vez más datos de calidad potenciarán el proceso inteligente de toma de decisiones de las máquinas implementadas en una fábrica o de varios dispositivos implementados en nuestras casas. Pero hay un gran desafío por delante: ¿cómo se pueden entregar de forma segura y confiable la calidad y los datos confiables? Los líderes de la industria para dispositivos integrados de gama baja están trabajando arduamente para llevar las mejores prácticas de seguridad de hardware y software ampliamente disponibles en dispositivos de gama alta a estos dispositivos de microcontroladores. Los recursos limitados en microcontroladores, y con tantos sistemas operativos y pilas de soluciones, conducen a un panorama complejo y desafiante para la seguridad integrada.
Podemos clasificar los escenarios de protección de datos de la siguiente manera;
Los datos en reposoDatos en tránsitoDatos en uso
En Weeve, estamos desarrollando soluciones personalizadas para la seguridad de datos para dispositivos IoT basados en microcontroladores.
Protegemos los datos en reposo está utilizando una solución de almacenamiento confiable. Estos datos contienen activos criptográficos como claves o algunos activos digitales como monedas virtuales, etc. datos en tránsito, Hemos desarrollado Weeve MQTTS, una publicación-suscripción ligera y segura basada en el protocolo MQTT diseñado para dispositivos de gama baja. Esta es una alternativa a MQTT sobre TLS, que consume más recursos de energía en el borde. datos en uso Abordamos la integridad del proceso que se ejecuta en un dispositivo IoT. Este proceso podría estar recopilando datos útiles usando sensores o ejecutando un paso de procesamiento de datos o incluso ejecutando una lógica de negocios en el caso de un dispositivo actuador. Detectar y prevenir las vulnerabilidades de software del proceso es la clave aquí. Estamos desarrollando Testimonio de la semana, una aplicación de certificación de control en tiempo real, que es el tema de esta serie de blogs.
Antes de presentar Weeve Testimony, aquí hay un poco de antecedentes técnicos de los problemas que estamos resolviendo y las tecnologías utilizadas en nuestra solución.
Problemas de vulnerabilidad del programa C
Casi todo el software y firmware integrados de bajo nivel se desarrolla en el lenguaje de programación C. La falta de verificaciones de límites adecuadas de C para la memoria asignada prevista es una fuente de grandes amenazas de seguridad. Además del desbordamiento del búfer, el programa C sufre de desbordamiento de enteros, vulnerabilidad de formato de cadena, sobrescritura de la dirección de retorno, etc. También hay una nueva clase de amenazas de seguridad para un programa C, como return-to-libc, y más programación general orientada al retorno (ROP) que es muy efectiva contra las técnicas de mitigación comunes, como la Prevención de ejecución de datos y la firma de código. La revisión adecuada del código con herramientas de seguridad de aplicaciones estáticas y dinámicas puede reducir la gravedad de tales vulnerabilidades. Existen otras técnicas en la cadena de herramientas, como la protección contra aplastamiento de la pila, en el hardware mismo, como el conjunto de bits NX para segmentos de datos, durante el tiempo de ejecución, como las aleatorizaciones de diseño de espacio de direcciones (ASLR). Pero el programa todavía está lejos de ser una garantía justa y libre de vulnerabilidad. En el contexto de los dispositivos de gama baja basados en microcontroladores, la técnica de mitigación más efectiva de ASLR no se implementa debido a la practicidad para evitar tener un cargador de tiempo de ejecución.
Nuestro enfoque para mitigar las vulnerabilidades del programa C
Para abordar los problemas de vulnerabilidad del programa C, asumimos que siempre habrá fallas de seguridad en el programa y, por lo tanto, nos aventuramos a detectarlos en tiempo de ejecución. Visualizamos la existencia de un proceso de protección aislado más privilegiado que inspecciona y testifica el comportamiento de un programa C en ejecución (el firmware de MCU). El proceso de protección debe estar aislado y tener más privilegios que el firmware normal porque si es parte del mismo proceso o nivel de privilegio similar al firmware normal, el pirata informático podrá piratear el proceso de protección y explotar la misma vulnerabilidad en el firmware normal . También imaginamos la necesidad de una entidad de certificación remota que conozca de antemano (utilizando nuestra herramienta de creación de perfiles) todas las instantáneas de ejecución válidas de la ejecución normal del firmware, y testifique periódicamente de estas instantáneas. Se requiere un servidor remoto para la certificación para que el sistema general sea más resistente a los ataques, en lugar de depender de un proceso de protección aislado. El servidor remoto también le permite al administrador de la flota de dispositivos conocer el estado de integridad de los dispositivos.
¿Arm TrustZone y por qué lo usamos?
Gracias a Arm Trustzone, podemos diseñar dicho sistema. TrustZone es una tecnología de seguridad asistida por hardware que ayuda a la compartimentación de todo el sistema en dos partes. El componente menos privilegiado, conocido como el "Mundo Normal", es donde se ejecuta el firmware de la aplicación de propósito general y la lógica empresarial. El "mundo seguro" privilegiado tiene una base de computación mínima (por lo que debería tener menos errores) y no se puede acceder directamente desde el "mundo normal" de propósito general, a excepción de una selección de llamadas de servicio permitidas.
Arm Trustzone, cortesía de Arm Inc.
En resumen, todo nuestro mecanismo de seguridad del proceso es que se extrae la información de la ruta de ejecución del flujo de control total de un programa, y luego esta información se valida durante el tiempo de ejecución con un proceso de protección aislado altamente seguro que se ejecuta en Trusted Execution Environment (Arm Trustzone ) Esta aplicación confiable de guardia también actúa como un cliente de certificación remota y envía el diagrama de flujo de control ejecutado actualmente a un servidor de certificación remoto a pedido. Weeve Testimony protege el firmware de la aplicación que se ejecuta en el mundo normal. Para la protección del proceso de protección, que es Testimony Trusted Application, confiamos en la garantía de seguridad proporcionada por la tecnología Arm TrustZone.
La visión de Weeve del producto Testimony es integrar el producto de certificación remota de firmware en tiempo de ejecución descrito anteriormente con una infraestructura digital de economía de datos basada en . Esta publicación de blog describe la Certificación remota Weeve Testimony y los componentes del lado del Cliente en particular. Creemos en el poder fundamental de la descentralización, pero Testimony también se puede utilizar en otras implementaciones de casos de uso de IoT sin un componente .
¡Aquí, nos sumergiremos en algunos detalles técnicos! Una familiaridad con el proceso de construcción del código C y el conjunto de instrucciones de ensamblaje del brazo es beneficiosa para comprender completamente el material posterior.
Preparación del firmware consciente del testimonio
Paso 1. La herramienta de instrumento Weeve, Testimony Patcher, analiza una imagen binaria mundial de firmware normal. La herramienta reemplaza todas las instrucciones de ensamblaje ARM del flujo de control con una instrucción BL (BL corresponde a una llamada a función en el ensamblaje ARM). La dirección de destino de esta instrucción BL es una rutina escrita en el ensamblaje ARM. Todas las rutinas de ensamblaje dependen del tipo de instrucción de flujo de control que está reemplazando, en otras palabras, cada tipo de instrucción de flujo de control de ensamblaje ARM tiene una rutina. Estas rutinas se llaman trampolines. La herramienta también genera una tabla con registros como una tupla {sourceAddress, originalDestinationAddress}. Dado que modificamos todos los destinos de flujo de control en el firmware original, esta tabla contiene información crucial sobre las direcciones de destino de flujo de control originales. Esta tabla será utilizada por los trampolines. Esta tabla de ramificación de flujo de control se genera en forma de un archivo C-source.
Infraestructura de instrumentación de testimonio de Weeve
Paso 2. Necesitamos construir nuevamente el firmware para que la tabla de ramificación de flujo de control generada en el Paso 1 pueda vincularse con el firmware mundial normal y esté disponible en tiempo de ejecución. Ahora este firmware está protegido por Weeve Testimony y está listo para descargarse en el dispositivo.
Paso 3. La aplicación de confianza Weeve Testimony también debe actualizarse al dispositivo. Tenga en cuenta que Weeve Testimony Trusted es independiente del proceso de instrumentación y firmware mundial. Si el firmware del mundo normal está corregido por errores y el usuario lo actualiza de forma remota, no es necesario cambiar la aplicación de confianza Testimony.
En la siguiente y última parte, veremos la integridad del flujo de control de Weeve Testimony en acción en el tiempo de ejecución y cómo permite que toda la certificación remota de dispositivos de extremo a extremo.
Esperamos que haya disfrutado de una discusión de alto nivel sobre las vulnerabilidades de seguridad en la cadena de suministro de datos y IOT, y nuestra solución propuesta: Testimonio de Weeve. Testimony es un proceso de protección que garantiza la ejecución del firmware de MCU, lo que demuestra que su dispositivo no es manipulado y confiable. Esta solución confiable de primera milla es crítica para habilitar la economía de máquinas y datos.