Raíz de confianza para IoT y otras tendencias de seguridad de IoT

El tema de la seguridad de la información es cada vez más relevante cada año. El centro de seguridad de la información ocupa el primer lugar en la calificación y el segundo en el número de suscriptores. Sin embargo, los materiales se dedican principalmente a diversas redes, web, nube y otras tecnologías tradicionalmente consideradas en el contexto de la seguridad. Y casi no se aplica a aplicaciones integradas, especialmente con recursos limitados. Mientras que el número de este último es más que órdenes de magnitud. En este artículo, veremos algunas de las características y tendencias en la seguridad de Internet de las cosas que tienen su origen en el modelo de desarrollo y distribución.


El desarrollo para aplicaciones integradas siempre ha tenido ciertas características, además, de tal manera que la mayoría de los programadores "comunes" ni siquiera piensan en ello, y el concepto de QA y el proceso de prueba en muchos casos son fundamentalmente diferentes de lo que generalmente se entiende.

Uno de los temas favoritos y discutidos periódicamente en el gran canal de TI en Telegram Embedded Group es “¿por qué nadie entiende a los desarrolladores integrados y paga tan poco? (en el contexto de los programadores "ordinarios") :) Un

sistema integrado es un sistema que funcionará al integrarse directamente en el dispositivo que controla. Un par de fotos para mayor claridad:



la imagen de la izquierda está tomada de un artículo de Wikipedia sobre sistemas integrados, es un ejemplo de un sistema complejo grande. A la derecha hay una foto de la revisión de la casa inteligente Redmond, aquí todo es mucho más simple y compacto, de hecho, todo el dispositivo está hecho en un chip con un enlace mínimo. Es importante que ambos dispositivos funcionen como dispositivos completos (una computadora de una sola placa aún necesita una carcasa y algunos periféricos).

Como regla general, una empresa fabricante produce dispositivos terminados, que principalmente incluyen hardware, y el software, como regla, está incluido y funciona solo en este hardware. Casi nadie tendría la idea de comprar un teléfono inteligente "desnudo" sin software, y luego instalarlo en el sistema operativo y las aplicaciones necesarias, todo debería funcionar de inmediato. Como resultado, los desarrolladores a menudo realizan todo el espectro de tareas para el desarrollo de dispositivos, tanto de software como de hardware.

Otra característica del desarrollo para sistemas embebidos es que casi siempre tienen muchos menos recursos, tanto en potencia informática y memoria, canal de datos, como consumo. La mayoría de las tecnologías familiares para muchos son imposibles de ejecutar en tales sistemas, incluso el sistema operativo no está en todas partes. Es necesario encajar en los recursos disponibles y, a menudo, ahorrar significativamente. Esto también afecta la seguridad: muchos estándares del Gran Mundo no son compatibles o se admiten con restricciones.

C sigue siendo el lenguaje más utilizado para desarrollar sistemas embebidos. Tiene una serie de deficiencias en el trabajo con memoria que afectan directamente la seguridad. Para resolverlos, se desarrolló Rust , está ganando popularidad (en primer lugar de sus idiomas favoritosen StackOverflow durante varios años, superando incluso a Python y Kotlin, especialmente popular recientemente), pero aún lejos del líder en aplicabilidad en embebido debido a los sistemas y bibliotecas compatibles. Los lenguajes de nivel superior son raros para los sistemas integrados y es probable que permanezcan tan pronto.

Una característica importante del desarrollo de sistemas embebidos es la limitación de las capacidades de hardware de la plataforma y el SDK suministrados por el fabricante. Es simplemente imposible o extremadamente costoso implementar muchas tecnologías por su cuenta desde cero para un solo proyecto. Por lo tanto, es imperativo que el fabricante del chip admita tecnologías de seguridad de vanguardia. Hasta hace poco, se prestaba mucha atención a esto. Por ejemplo, si el hardware AES apareció hace mucho tiempo en casi todos, entonces muchas personas aún no saben cómo admitir TLS / DTLS. La pregunta es cómo lograr esto. Recientemente escribí sobre el nuevo SDK de Nordic Zephyr que resuelve este problema al integrarse con un gran proyecto respaldado por la Fundación Linux. Este es un enfoque. A continuación consideraremos otros.

Como parte de la consideración de la seguridad de los sistemas integrados, es necesario tener en cuenta un grupo de aplicaciones que se ajustan a los requisitos de las normas de seguridad funcional: medicina, automoción, equipos ferroviarios, automatización industrial. Estas son aplicaciones que afectan directamente la vida y la salud de una persona, así como para sistemas que no se pueden detener (por ejemplo, un reactor nuclear). Aquí todo está claramente regulado en todas las etapas de desarrollo y se tiene en cuenta el potencial de falla y el efecto sobre el funcionamiento del sistema en su conjunto. El desarrollo se lleva a cabo en soluciones especializadas de hardware y software, que en el futuro también deben ser certificadas. Como resultado, resulta largo y costoso. Por lo tanto, aquellos que comienzan el desarrollo no lo piensan si no hay estándares vinculantes.

Recomendamos una serie de artículos sobre seguridad funcional para su revisión .

Además del problema de desarrollo, es importante prestar atención a las condiciones de funcionamiento de los sistemas.

Como regla general, las grandes empresas, los fabricantes de servicios en la nube se preocupan por la seguridad de sus servicios por varias razones:

• Se dedican directamente al desarrollo y al apoyo del funcionamiento del servicio.
• Tienen un contacto mucho más cercano entre desarrolladores e ingenieros de soporte.
• Los ingenieros pueden acceder directamente al equipo, incluso en las nubes
• Los amplios canales de transmisión de datos y la alta capacidad computacional del equipo permiten el uso de sistemas de monitoreo y detección de actividad anormal.

Los dispositivos de Internet de las cosas funcionan exactamente de la manera opuesta:

• Como regla general, son propiedad del cliente final, y los ingenieros del cliente final, las competencias, que en la mayoría de los casos son inferiores por razones objetivas, participan en la configuración y el soporte.
• Los recursos de cada dispositivo son limitados, tanto en términos de rendimiento como de transferencia de datos. Como resultado, un sistema para monitorear y detectar actividad anormal es prácticamente imposible en este caso.

Para mayor claridad, daré una tabla comparativa. Inmediatamente haga una reserva que:

• Hay muchas opciones de entrega de software y soporte. Solo se dan grupos generales con fines ilustrativos.
• La cantidad de dispositivos de Internet de las cosas es difícil de estimar con precisión, ya que todos entienden algo diferente, y tampoco hay buenas estadísticas sobre ellos.

	Servidores y soluciones en la nube (SaaS y similares)	Dispositivos de usuario (PC, teléfonos inteligentes, etc.)	Internet de las Cosas
¿Quién se está desarrollando?	proveedor de soluciones	-	-
/ ?
/?
		—
			,
	()		( )
	(Amazon, Google)	2019 : ~266 K, ~1.37	9

Como resultado, periódicamente ocurren situaciones en las que los dispositivos fueron pirateados, y no se sabe nada de esto por razones objetivas. Desafortunadamente, esta situación no es infrecuente y puede durar meses y, a veces, años.

Los hacks más famosos de sistemas embebidos en los últimos años:

• Mirai botnet en 2016, trabajando principalmente en videocámaras. Según diversas estimaciones, el número de dispositivos infectados superó los 380 mil . Su sucesor Satori en 2018 ya capturó 700 mil dispositivos, centrándose principalmente en mineros de criptomonedas.
• KRACK llegó a WPA2 Wi-Fi en 2017 (casi todos los dispositivos Wi-Fi en los últimos 15 años) y su heredero Kr00k , con más de mil millones de dispositivos en 2019.
• En 2018, Bleedingbit llegó a los chips BLE de Texas Instruments. Oficialmente, solo unos pocos modelos de puntos de acceso que usaban la familia CC26xx se vieron afectados, y el problema en sí mismo se resolvió en la nueva versión de la pila. Sin embargo, en este caso, no se tiene en cuenta que estos chips se utilizan en un número mucho mayor de dispositivos (el segundo mayor productor de BLE en el mundo, el 16% de 3.900 millones para 2018).

La mayoría de los fabricantes de hardware lanzan parches para sus dispositivos. Sin embargo, estas correcciones aún deben aplicarse en los dispositivos mismos, lo cual es difícil o, en algunos casos, imposible para los dispositivos de Internet de las cosas. Como resultado, una parte importante de los dispositivos sigue siendo potencialmente vulnerable. Y es posible que nunca se enteren de esto debido a la falta de control y la debida atención a este problema.

En consecuencia, es necesario utilizar enfoques fundamentalmente diferentes para evitar vulnerabilidades y eliminar las consecuencias para los dispositivos de Internet de las cosas. La seguridad debe residir en la plataforma misma desde la etapa misma de su diseño y llevarse a cabo en todas las etapas de desarrollo y operación del dispositivo final, pero al mismo tiempo debe ser simple y económica para una implementación masiva (al menos con respecto a la seguridad funcional y la ETE de procesadores potentes).

ARM en 2017 habló sobre la seguridad de los sistemas integrados basados ​​en CryptoCell y Cortex-M33, sin embargo, las muestras en serie de chips en el M33 aparecieron solo el año pasado. La tecnología presentada se llama Platform Security Architecture (PSA).


La esencia de la idea era separar partes críticas del sistema (claves, derechos, firmware) de componentes potencialmente pirateables, tanto hardware como software, para sistemas donde la implementación completa de TEE es imposible o difícil. La tecnología se centra principalmente en Cortex-M, pero es compatible con todas las familias Cortex-A / -R / -M.



Básicamente considere 4 etapas de protección de dispositivos de Internet de las cosas. Considérelos en secuencia a medida que surgen durante el funcionamiento del dispositivo.

Arranque seguro

• Se verifica que el firmware es original, no se ha cambiado y no se puede degradar.

Actualización segura de firmware por aire (Secure FOTA)

• Solo se pueden descargar actualizaciones autenticadas y verificadas.
• ( )

API

• , .
• «» API.
• —

• (MITM)

Para proteger el dispositivo, se propone identificar / verificar los datos que llegan a cada etapa. El concepto se basa en la idea de la raíz de la confianza (Root-of-Trust, RoT). La conclusión es que un cierto identificador (clave) está cosido en el dispositivo y se está llevando a cabo un procedimiento de hardware para verificar que la clave sea única para la plataforma actual y el código ejecutable. En el futuro, todas las bibliotecas importantes usan RoT para su propio trabajo.


Por lo general, esto ocurre en 3 etapas principales:

1. Proporcionar confianza: la inclusión de la raíz de confianza en la etapa de producción en la estructura del chip. El
   identificador de chip inmutable y la raíz de confianza del hardware proporcionan seguridad básica e identificación única del dispositivo.
2. :
   ,
3. :
   , 2 .

La solución más común en el mercado es TrustZone de ARM. Se ha escrito mucho sobre su implementación en Habré, ya que la tecnología en sí se introdujo durante mucho tiempo. Lo más claro en mi opinión se resumió en una de las últimas publicaciones .

En el contexto de este artículo, vale la pena señalar que TrustZone anterior era el privilegio de los procesadores de alto rendimiento de la familia Cortex-A. Y durante el año pasado, casi todos los fabricantes de sistemas inalámbricos basados ​​en cristal han lanzado soluciones basadas en Cortex-M ; el más popular es Cortex-M33 .

Hablando de seguridad de la información, vale la pena recordar el sistema de criterios generales(Criterios comunes), adoptados tanto a nivel internacional como a nivel nacional. Le permite determinar el nivel de confianza Nivel de garantía de evaluación (EAL) de 1 a 7 (EAL1 - EAL7), una cifra más alta indica un mayor nivel de seguridad. Para comprender, la mayoría de los sistemas operativos Windows tienen un nivel EAL4 o EAL4 + , LInux / Unix, EAL5 básicamente tienen tarjetas inteligentes (banca, transporte, incluso sin contacto), EAL6 le permite usar la solución en situaciones de alto riesgo, EAL7 en situaciones de riesgo extremo, por ejemplo, para redes unidireccionales (diodos de datos).

En abril de este año, el Cortex-M33 y M35P fueron certificados a EAL6 +. Este es un nivel muy alto que le permite aplicar soluciones en situaciones de alto riesgo.

ARM TrustZone Cryptocell en el nuevo Cortex-M33 / M23 proporciona almacenamiento seguro de claves (incluido uno con un identificador de hardware único), verificación de firmware, tanto durante la descarga como la actualización por aire, aceleración de cifrado de hardware AES, SHA, ChaCha, ECC, en incluso con DMA (como resultado, todos los datos en Flash y RAM se pueden cifrar), generadores de números aleatorios (TRNG, PRNG).


Es interesante observar que CryptoCell le permite tener varias raíces de confianza para diversas tareas (por ejemplo, incorporar un RoT adicional para un cliente que desea integrar una solución masiva del mercado en su sistema de TI cerrado, por ejemplo, un banco sin estar vinculado al RoT principal del fabricante), así como la depuración segura (Secure Debug) con derechos de autorización.

La serie 300 de CryptoCell está dirigida específicamente a dispositivos de Internet de las cosas de baja potencia. El consumo del nuevo M33 es aproximadamente un 20-40% más bajo que el del M4, dada la pérdida en el consumo de energía para el trabajo de TrustZone del 20%, tenemos el mismo nivel de consumo o menor que ahora. Como resultado, podemos decir que la seguridad del hardware ha llegado al segmento de presupuesto más masivo con el Cortex-M33 / M23 y en el futuro cercano la cantidad de productos basados ​​en ellos solo aumentará.

Las alternativas de TrustZone incluyen OpenTitan patrocinado por Google. Sin embargo, aún no está muy extendido y centrado en otras aplicaciones que no sean dispositivos finales de Internet de las cosas.

Vale la pena señalar que la implementación de hardware de la raíz de la confianza no es una panacea y también puede ser hackeada. Un ejemplo es la historia reciente con Intel . Es importante mencionar que en este caso se encontró un error en la ROM y se usó una clave para todas las generaciones de conjuntos de chips, por lo tanto, puede reproducirse. E incluso tal implementación complica en gran medida el hack.

Considere las 5 etapas de la evolución de la implementación de Root-of-Trust en los módulos de comunicación celular uBlox , desarrollado en colaboración con el Grupo Kudelski. Esto es interesante desde el punto de vista de la tarea, ya que sus soluciones difieren significativamente de los enfoques de otras compañías. Los módulos celulares Cat-M Nb-IoT / LTE pertenecen a las clases de transición entre la 4ta y 5ta generación de LTE y están dirigidos a redes LPWAN de baja potencia. En la mayoría de los casos, los dispositivos deberían funcionar durante años sin intervención humana. Las soluciones modernas le permiten trabajar de 7 a 10 años con una batería (batería). La vida media del dispositivo a menudo alcanza los 15 años. Durante este tiempo, los requisitos de seguridad pueden cambiar significativamente, aparecerán nuevas amenazas. Los dispositivos deberían funcionar de manera estable sin intervención humana durante toda la vida útil. En consecuencia, es necesario proteger dichos dispositivos teniendo en cuenta la duración y la naturaleza de su trabajo.


Como puede ver en la estructura, con cada próxima generación, la raíz de la confianza cambia su posición. Este es un punto clave que afecta la seguridad de la solución en su conjunto.

Las opciones 1 y 3 se consideran poco confiables de acuerdo con uBlox / Kudelski debido a la implementación de software de RoT y al pirateo más probable. Incluso para el caso de hacer la raíz de la confianza en el eSIM externo (eUICC), que proporciona protección suficiente para las aplicaciones bancarias de EAL4 de nivel de entrada (las claves en eUICC no se pueden leer o cambiar para que no sea visible desde el exterior). Sin embargo, este enfoque conlleva fallas y vulnerabilidades potenciales derivadas del hecho de que la comunicación con un componente externo puede ser interceptada y potencialmente distorsionada, la complejidad de la interacción en las etapas iniciales de la inicialización del sistema (verificación del gestor de arranque), así comoMecanismo de programación complicado debido a los limitados recursos de chip en UICC. Además, el módulo externo puede ser reemplazado o eliminado del sistema (simplemente cambiando la tarjeta SIM) y dejando así todo el sistema sin una raíz de confianza.

Por lo tanto, la ruta de desarrollo adicional es integrar la raíz de confianza en el área protegida del chip. Este enfoque es consistente con ARM TrustZone CryptoCell Composition.

La versión con la implementación de Root-of-Trust en un sistema operativo seguro es la más común en el mercado y proporciona un nivel de seguridad suficiente para la mayoría de las tareas. La solución más común en el mercado es ARM TrustZone (más arriba), pero sin CryptoCell, que almacena las claves en un área protegida.

La solución con protección integrada dentro del chipset, a la que prácticamente no hay acceso desde el exterior, tiene la mayor protección. La solución actual utiliza el elemento de seguridad incorporado (Elemento seguro), certificado de acuerdo con el nivel EAL5 + . Esto permite la certificación de Criterios comunes para todo el dispositivo en su conjunto, y también le permite colocar funciones de la tarjeta SIM y perfiles de Operador de red móvil (MNO) dentro del dispositivo. Esto corresponde al nivel actual de seguridad.

La próxima generación del chipset uBlox está en desarrollo, donde Secure Element se integrará en el silicio del chipset del módem. Esto reduce aún más la superficie de ataque y mejora la seguridad al más alto nivel. Se implementará a través de iUICC(Tarjeta de circuito integrado universal integrada): la próxima generación de UICC, en la que todo el código y el identificador SIM se ubicarán dentro del sistema en un chip, el estándar aún no se ha completado.

Recomendaciones:

• Cada vez más fabricantes de componentes electrónicos desarrollan y producen dispositivos con la seguridad en mente, comenzando desde las primeras etapas de desarrollo.
• Las empresas de punto final obtienen herramientas de administración de seguridad de forma inmediata. Atraer expertos en la etapa de desarrollo de herramientas le permite evitar errores, así como reducir significativamente el costo de la solución en su conjunto.
• El precio de las nuevas soluciones a menudo se acerca a las soluciones actuales, pero ofrece un nivel de protección fundamentalmente diferente, que también simplifica enormemente la transición.
• El creciente número de dispositivos que proporcionan un nuevo nivel de seguridad es solo cuestión de tiempo.
• En las nuevas soluciones de elementos seguros, UICC se transfiere dentro del chip del chip para aumentar la seguridad y obstaculizar los ataques.
• Las soluciones modernas proporcionan niveles de seguridad de hasta EAL6 + suficientes para su uso en situaciones de alto riesgo.
• Las soluciones del nivel EAL7 están en desarrollo, sin embargo, utilizan tecnologías sin un estándar finalmente aprobado, por lo tanto, el término para su disponibilidad en el mercado no está definido.