Existe una gran frustración entre expertos en seguridad y legisladores debido a que los fabricantes de dispositivos (OEM) no implementan medidas de seguridad adecuadas. Al parecer, muchos OEM se resisten al esfuerzo y gasto continuos que implica crear y gestionar un equipo de seguridad para verificar y corregir informes de problemas, así como para comunicar sus acciones según los requisitos de diversas agencias de seguridad. Por su parte, los OEM probablemente prefieren un enfoque de seguridad único y final ('one and done'). Creo que tengo una solución para este conflicto. No es una solución perfecta, pero es un paso intermedio en la dirección correcta.
La solución es el particionamiento. Hemos descubierto que es posible lograr un fuerte aislamiento entre particiones de software para la arquitectura Arm Cortex-M con unidades de protección de memoria. Esto es factible sin un desperdicio excesivo de memoria o sobrecarga del procesador tanto para las arquitecturas v7M como v8M.
Las tareas en una partición no pueden acceder a los recursos de otra partición. Deben pasar a través de portales. Las tareas en particiones cliente envían mensajes protegidos (pmsgs) a los portales de los servidores. Los pmsgs contienen comandos y datos, que los servidores interpretan y devuelven resultados a través de los mismos portales. Los pmsgs incluyen niveles de privilegio del cliente para permitir que las aplicaciones implementen operaciones de menor privilegio, por ejemplo, en accesos a archivos.
Como tal, los portales de partición son lo único que conocen unas particiones de otras. Los datos y el código internos están ocultos. Esto permite que las particiones se detengan y reinicien individualmente para recuperarse de ataques maliciosos. Más adelante, también podrían actualizarse individualmente.
La arquitectura Cortex-M proporciona una barrera muy fuerte entre el modo no privilegiado (umode) y el modo privilegiado (pmode). Llamamos a esto la barrera pmode. Solo se puede penetrar desde umode mediante excepciones, siendo la principal la excepción SVC, que se utiliza para llamadas al sistema desde umode.
El código vulnerable se coloca en particiones umode aisladas, y el código crítico para la misión se coloca en particiones pmode donde se ejecuta en gran medida sin cambios, aunque está protegido por la barrera pmode y por el aislamiento de particiones.
Un hacker que accede a una partición umode queda en un entorno limitado: no puede ir más allá. Además, se imponen limitaciones en tiempo de ejecución, acceso a objetos, interrupciones y E/S a las particiones umode para evitar que el hacker cause daños al sistema desde una partición que ha penetrado.
Esta arquitectura protege por igual contra vulnerabilidades de día cero como contra vulnerabilidades conocidas sin parche. También admite el siloing de desarrollo y soporte para protegerse contra amenazas internas.
Ambas partes parecen estar a punto de entrar en guerra. Me pregunto si este medio paso podría ser preferible. Es totalmente posible que los dispositivos particionados puedan realizar sus funciones principales y proteger datos privados mientras están bajo ataque. También es posible que las funciones auxiliares puedan recuperarse de ataques. Hemos demostrado que este enfoque es factible y funciona. Al menos brindaría a los consumidores y otros usuarios más protección de la que tienen ahora.
El diagrama anterior ilustra los principios del particionamiento en Cortex-M. Muestra cómo una pila de red vulnerable y su controlador Ethernet se aíslan del resto del sistema en una partición umode. La aparente penetración de la barrera pmode por el portal de túnel es solo virtual: la ruta es en realidad a través de la excepción SVC.
Para obtener más información sobre el particionamiento, consulte nuestro libro electrónico gratuito 'Achieving Device Security'.
