Procesadores más seguros: ¿cómo?

17/03/2022 Isaac 1142 Views 0 Comments

Las vulnerabilidades de hardware, especialmente las que afectan a los procesadores, se han transformado en un serio problema para la seguridad. Además, se han vuelto numerosas, porque la seguridad rara vez es una prioridad en la etapa de diseño del hardware. Esto es así, en parte, porque la seguridad se ha visto hasta ahora como algo que se debe manejar desde el lado del software.

Pese a los problemas de vulnerabilidades, como Meltdown o Spectre, los diseñadores rara vez se ven presionados por el mercado para que diseñen procesadores más seguros. En cambio, existen muchas buenas prácticas que se podrían llevar a cabo…

ÍNDICE:

Importancia de la seguridad en el lado del hardware

ciberseguridad

Los motivos por los que los diseñadores deberían destinar más recursos temporales y de inversión a la seguridad son demasiado numerosos y de peso como para ignorarlos:

Las máquinas manejan datos muy relevantes en todo el mundo, desde transacciones bancarias, hasta datos confidenciales y/o gubernamentales, información privada personal y datos médicos, etc. Con el IoT, la cantidad de dispositivos que podrían verse comprometidos por problemas en los procesadores se dispara. Se estima que en 2025 se llegue a unos 75.44 mil millones de dispositivos conectados.
La creciente crispación y tensiones geopolíticas entre países. Muchos aprovechan la ciberguerra para atacar a sus contrincantes, causando daños severos o pérdidas económicas muy relevantes.
El crecimiento de los ciberdelincuentes y las amenazas también son un síntoma que debería alertar para crear sistemas más seguros a todos los niveles, también en el lado del hardware.

Para luchar contra estos ataques de canal lateral se necesitan dos estrategias principales: eliminar o reducir la filtración de información y tratar de eliminar la relación entre la información filtrada y los datos secretos, es decir, que no haya correlación para paliar el efecto de la filtración.

Soluciones para la creación de procesadores seguros

Secure Processor de AMD y ARM Trust Zone

Para mejorar la seguridad de los procesadores se pueden comenzar a explotar algunas soluciones dentro del propio procesador y también en su entorno. Soluciones que van más allá de un simple parche del microcódigo o firmware, y que comienzan por la «mesa de dibujo», en la etapa del diseño de la CPU:

Pantallas con blindaje: para disminuir las emisiones electromagnéticas (véase ataques DPA / DEMA) y reduciendo la susceptibilidad (véase TEMPEST). Esto se consigue mediante el acondicionamiento y filtración de las líneas eléctricas. Otra alternativa, que resulta compleja de implementar en la práctica, sería hacer que todas las instrucciones se ejecuten empleando la misma cantidad de energía (mismo path). Pero, como sabes, las distintas instrucciones son dispares en este sentido…
Ruido y timing controlado: se puede emplear ruido en el canal o retrasos aleatorios para disuadir los ataques basados en tiempo. Aunque esta medida no es del todo fiable, ya que se puede compensar esos retrasos realizando algunas mediciones. También se podría usar software que sea isócrono, es decir, que se ejecute en una cantidad constante de ciclos de reloj independientemente del valor secreto, haciendo imposibles los ataques de sincronización. El problema es que en la práctica esto no se puede hacer de forma sencilla, ya que incluso las diferentes instrucciones de la ISA se ejecutan números de ciclos de reloj dispares.
Caché predecible: para evitar ciertos ataques que recuperan datos de la memoria caché, se podría hacer que se acceda a la información de una manera predecible, siempre con un patrón fijo. Por ejemplo, se puede evitar las búsquedas de tablas dependientes de datos, ya que eso podría reelar en qué parte de la tabla de búsqueda se accedió a un cierto valor.
Modelos de amenazas a la seguridad: al igual que durante el desarrollo de software se toman molestias para conocer los vectores de ataque posibles, permitiendo escribir código preventivo de vulnerabilidades, en el hardware también se debería hacer lo mismo. Pero para eso se necesita destinar tiempo y recursos a comprender cómo se puede atacar o manipular el procesador para blindar el diseño. También existe software específico para tratar de detectar este tipo de debilidades durante la etapa de diseño.
HRoT (Hardware Root of Trust): generalmente se supone que los procesadores son intrínsecamente seguros, pero debería ser prioridad asegurar esta parte más incluso que el software, dado lo complicado que resulta parchear sus vulnerabilidades, y en algunos casos ni siquiera se puede solucionar mediante parches de firmware o microcódigo. Para asegurar el hardware, se debería:
- Realizar la autenticación del dispositivo de hardware para garantizar que no ha sido manipulado.
- Implementar funciones por hardware para asegurar que las imágenes de arranque no han sido manipuladas (como el Secure Boot, MCUBoot, etc.), así como asegurar que la secuencia se realiza sin interrupciones extrañas.
- Proporcionar memoria OTP (One-Time Programmable) para el almacenamiento seguro de claves para el cifrado.
- Mecanismos para asegurar que la máquina puede ponerse en un estado conocido y confiable.
- Integración de motores de cifrado y generadores de números aleatorios.
- Mejor aislamiento de procesos y cifrado de datos que podrían ser potenciales objetivos de side-channel attacks.
- Invertir más recursos a la hora de diseñar sistemas complejos que puedan dejar agujeros de seguridad, como SMT.
Physically Unclonable Functions (PUF): estas funciones físicamente no-clonables debería ser una parte esencial de los sistemas de cifrado y como huella digital de los procesadores, ya que se crea de forma manual durante la fabricación. No habría dos procesadores iguales.
Actualizar firmware por OTA: aportar parches de seguridad de forma rápida para el firmware es también una ventaja. De esa forma se garantiza que el firmware estará siempre en su versión más reciente. Incluso se podría usar un sistema para invalidar versiones de firmware antiguas.
Procesadores centinela dedicados: implementar más soluciones de seguridad por hardware dedicadas, actuando junto con el procesador host. Este tipo de chips, como el Dover CoreGuard, pueden diferenciar entre instrucciones buenas y malas, verificar la legitimidad, e identificar si un proceso se está ejecutando bien o si es una infracción. Además, estos procesadores deben estar aislados, sin acceso desde el procesador host, para que sea inexpugnable.

En conclusión, se debería entender que los procesadores por sí solos no son seguros, se deben implementar soluciones combinadas desde el lado del software y el hardware. Las futuras máquinas deberían ser más inteligentes y con funciones de protección built-in para evitar la ejecución de código malicioso.

Soluciones específicas: TimeCache

Chip RISC-V

Un equipo de investigadores de la Universidad de Rochester también ha desarrollado un método para bloquear los ataques de canal lateral sin afectar al rendimiento. Se trata de TimeCache, un enfoque de seguridad del sistema que te protegería de ataques tipo Spectre o Evict+Reload sin el considerable impacto habitual que tendrían las contramedidas habituales.

Como sabes, este tipo de vulnerabilidades tienen su base en el hardware, sin embargo, los parches se basan en microcódigo y software, con el correspondiente impacto en el rendimiento. Las respectivas vulnerabilidades van haciendo necesario agregar parches que van lapidando el rendimiento poco a poco.

Divya Ojha y Sandhya Dwarkadas, los creadores de TimeCache, creen que su desarrollo es la respuesta. Ofrecen una protección perfecta que no implica pérdidas de rendimiento notables, ya que siguen permitiendo que los procesos puedan usar toda la capacidad en una caché compartida.

Se probó este concepto usando un simulador de la arquitectura GEM5. Y las pruebas demostraron eficacia contra ataques contra claves de GnuPG con algoritmo de seguridad RSA. Además, las pruebas de rendimiento en el benchmark usando la referencia SPEC2006 y PARSEC, revelaron que la sobrecarga alcanzó solo un promedio del 1.13%.

TimeCache implementa un sistema que incorpora un conocimiento del acceso previo a una línea de cache, de modo que el primer acceso a un proceso dado a la caché se retrasará. Dicho de otro modo, no habría forma de inferir si otro proceso que se está ejecutando en el mismo sistema ha solicitado los mismos datos primero.

De ese modo, los procesos no podrán beneficiarse de otros datos almacenados que hayan sido introducidos en la caché por otros procesos. Y es algo que funciona en todos los niveles de la memoria caché, sin necesidad de limitar el número de dominios de seguridad. También protegería contra estos ataques independientemente de si se están ejecutando en el mismo núcleo de la CPU, en otro núcleo diferente, o como hiperproceso.

El problema de TimeCache es que se necesitan modificaciones en el hardware. No se puede implementar del lado del software o con un simple parche. Se deberá agregar:

1 bit de seguridad por cada línea de la memoria caché, por contexto de hardware y que se denominas-bit.
Una marca de tiempo por línea de caché.
Un registro de desplazamiento adicional.
Y un bloque lógico par ala comparación en paralelo de la marca de tiempo.

Esto implica mayor complejidad y unos gastos en cuanto a superficie en el silicio (por ejemplo, para la Last Level Cache o LLC, el número de s-bits podría ser realmente significativo, dada su mayor capacidad). Sin embargo, aportarían mayor seguridad en centros de datos o en equipos que manejan información sensible.

TimeCache y RISC-V

TimeCache está bajo la mirada de multitud de desarrolladores de arquitecturas de código abierto que permiten su evaluación de forma rápida al ser soluciones no patentadas, como es el caso de algunos diseños de RISC-V. Por tanto, es muy probable que se comience a ver antes en este tipo de diseños que en chips propietarios.

Mi opinión

Personalmente, yo implementaría un sistema similar al de las etiquetas de fiabilidad de Europa, o como Google Scorecards para el código abierto, pero para etiquetar SW/HW según la seguridad. Esto tendría dos efectos importantes:

Obligaría a los desarrolladores a preocuparse más por la seguridad de sus productos si desean conseguir una buena imagen ante los potenciales clientes.
Permitiría a los usuarios realizar compras más inteligentes, evitando aquellos productos que no ofrezcan la misma seguridad.

¿Problema de esto? Evidentemente las grandes corporaciones no se van a consentir a ello, ya que les podría perjudicar. ¿Te imaginas un sistema de etiquetado para CPUs en la era de Metldown, Spectre, y demás vulnerabilidades? Intel hubiese tenido serios problemas de imagen, más aún de los que ya tuvo…