Fault injection: Ataque a RSA-CRT
Después de mucho tiempo en el letargo, volvemos a la carga con un ejemplo de inyección de fallos en el algoritmo RSA empleando el Teorema Chino del Resto ( Chinese Remainder Theorem ). Este teorema permite que si tenemos un par de ecuaciones tal que
Con p y q primos, se pueda calcular x ( mod p·q ) a partir de ellos y dos resultados auxiliares.
Por ello, el algoritmo RSA se puede dividir de una potencia modular con un módulo enorme a dos operaciones modulares de módulos de tamaño aproximadamente la mitad del primero. Con esto se consigue una mejora de rendimiento, lo cual es fundamental en aplicaciones con recursos limitados como smart cards. Además, los resultados auxuliares pueden ser precalculados, con lo cual se pueden cargar en la tarjeta al mismo tiempo que la clave y reducir la carga.
Sin embargo, en estos entornos es posible inyectar fallos tal y como expliqué en esta entrada. ¿Y qué tiene esto que ver con las implementaciones de RSA usando el CRT? Como vamos a ver, mucho 🙂
Smart cards: Ataques de inyección de fallos
Volvemos una vez más a las smart cards, analizando esta vez los ataques de tipo fault injection, que se basan en introducir fallos intencionadamente para hacer fallar la tarjeta de forma que se pueda aprovechar. Puesto que las tarjetas reciben TODO lo que necesitan para funcionar desde el exterior ( alimentación y reloj básicamente ), un atacante puede modificar cualquiera de esas entradas modificando un lector de tarjetas (o su driver ) para ello.
Por una parte, variaciones en la tensión de alimentación (aka power glitching ) pueden hacer que el procesador malinterprete instrucciones o datos, o incluso se las salte. Por ejemplo, si bajamos repentinamente la tensión puede darse el caso que un bit con valor '1' llegue con un valor por debajo del umbral de decisión, de forma que se lea como un '0'. Así se consigue producir un valor incorrecto o conseguir que se ejecute un salto condicional cuando no debería.
Además, podemos conseguir resultados similares variando el reloj externo, haciendo que el micro lea valores de memoria incorrectamente o ejecute instrucciones de forma instantánea.
Por otra parte, existen otros métodos como variar la temperatura del chip de forma que quede fuera de los umbrales de funcionamiento definidos por el fabricante, mediante radiación electromagnética o utilizando fuentes de luz ya sea Laser, rayos X o incluso luz blanca, aunque estos últimos ataques son invasivos pues hay que abrir el chip para llegar a introducir la luz en el punto exacto.
Del tema de inyección mediante laser nos hablaron un poco en una visita a Brightsight, donde nos enseñaron los aparatos que usan (tenían varios laseres de distintas potencias y calidades) para atacar las smart cards una vez han eliminado el epoxy que protege el chip.
Para protegerse de este tipo de ataques lo habitual es realizar los cálculos de forma redundante y comprobar que el resultado es lo mismo, y de la misma manera cada vez que se escribe en EEPROM tratar de leer el valor escrito como comprobación. Además podemos usar valores true=0xAA y false=0xFF en lugar de 0x00 para false y cualquier otra cosa para true como es habitual; así si nos cambian un solo bit no pasa de true a false, sino a un estado indefinido en el que podemos tomar protecciones como borrar directamente datos sensibles de la tarjeta (claves criptográficas, información de autenticación, etc...).
Por otra parte, muchos fabricantes incluyen sensores de luz, de frecuencia, temperatura y demás en sus chips como medida de protección. De esta forma, si la frecuencia o temperatura se sale de determinados márgenes pueden suponer que es un ataque y tomar medidas al respecto. Eso sí, el atacante siempre tiene el control del reloj y la alimentación, así que puede monitorizar el consumo de potencia y si ve un patrón que puede corresponder al inicio de un ciclo de borrado de la memoria puede desactivar el chip.
En la próxima entrega, intentaré explicar un ataque sencillo a RSA implementado con el teorema del residuo chino ( RSA-CRT ) mediante fault injection, explicando primero qué es eso de RSA-CRT claro.
Protecciones contra Side Channel Analysis
Volvemos a la carga con el tema de SCA. Después de ver qué es eso del Side channel analysis y analizar los análisis de consumo de potencia en los dos posts anteriores, esta vez vamos a comentar un poco las medidas más usuales para hacer frente a este tipo de análisis, y más concretamente contra power analysis.
El análisis simple, en el que tomamos una o unas pocas tramas y mediante algún tipo de inspección (normalmente visual y poco más) de ésta intentamos obtener la clave es fácil de resolver mediante la eliminación de dependencias con la clave en el algoritmo. Por ejemplo, como vimos en el caso del ataque a RSA, haciendo que se calculen todos las posibilidades y haciendo la elección después.
En el caso de análisis de potencia diferencial, lo que debemos hacer es intentar reducir CUALQUIER relación del consumo de potencia con los datos o la clave, debido a que tras adquirir muchas trazas se realiza una medida de la relación de éstas con las trazas para decidir qué clave es la buena (usualmente esta medida es un cálculo de la correlación entre las trazas medidas y los consumos hipotéticos). Así pues, para tratar de reducir dicha correlación tenemos dos estrategias principales:
- Hiding : Como su nombre indica, se trata de ocultar de alguna forma estas relaciones.
- Masking : en este tipo de protecciones lo que se hace es enmascarar el cálculo de las operaciones conflictivas utilizando valores aleatorios, para luego obtener a partir de este cálculo con distribución uniforme el valor real.
Dentro de los métodos de ocultación podemos encontrar diversas técnicas. Una de ellas es introducir retardos aleatorios en ciertos puntos del algoritmo, con lo que se consigue que las trazas de consumo de potencia no estén perfectamente alineadas y se reduce la correlación con los valores hipotéticos de consumo.
Otra técnica comentada con frecuencia consiste en añadir ruido en amplitud al consumo de potencia. Puesto que estamos buscando cierta señal útil dentro de la medida (aquella parte relacionada con los datos y/o la clave), siempre podemos añadir más potencia de forma aleatoria, por ejemplo activando subsistemas inactivos en el chip, como conversores AD/DA, interrupciones, etcétera.
También se suele usar el hecho de que muchos de los procesos llevados a cabo en un algoritmo de cifrado se pueden realizar de forma paralela, con lo cual en software podríamos reordenarlos sin problemas o incluso si tenemos multithreading realizarlos en paralelo (y si tuviesemos varios cores o un sistema multiprocesador... pero hablamos de smart cards y dispositivos embebidos). Por ejemplo, hablando de DES podríamos hacer las búsquedas en las S-box de forma aleatoria empezando con un número aleatorio e incrementar el número cada vez, empezando por la primera cuando lleguemos a la última.
Para acabar con las medidas de ocultación (que conozco) , podríamos realizar varias implementaciones alternativas de ciertas partes del algoritmo e ir alternando entre ellas en cada cifrado eligiendo cuál usar de forma aleatoria.
En cuanto a medidas de masking, hay que ver cada algoritmo por su parte. Los algoritmos como DES o AES que realizan búsquedas en tablas (las famosas sbox se suelen implementar como tablas en software), se suelen tomar valores aleatorios y realizar una nueva tabla equivalente que tenga en cuenta dicho valor aleatorio, y luego hacer el acceso a memoria tomando el valor aleatorio. Por ejemplo, tomamos m aleatorio, y hacemos una tabla S' tal que S'[i+m]=S'[i]+m. Ahora, cuando tenemos que hacer el acceso, lo hacemos a la posición i+m de la tabla y posteriormente hacemos la resta del valor m al resultado tras la búsqueda en la tabla.
Para algoritmos como RSA, se suele hacer con un exponente aleatorio que tras el descifrado o la firma del documento se invierte, volviendo al valor inicial. Creo que ya lo comenté en el primer post sobre SCA.
Evidentemente, cuantas más medidas añadamos más difícil será romper la implementación con este tipo de técnicas, pero hay que buscar un compromiso entre la mejora en seguridad y el empeoramiento de las prestaciones. El objetivo será pues desarrollar un sistema con una seguridad y prestaciones aceptables combinando varias de estas medidas.
Ataques a smart cards: Side channel analysis (II)
En este post volvemos al tema de las smart cards, continuando con los ataques de tipo side channel analysis. En el post anterior vimos qué es eso del side channel y qué tipos había, así como analizamos un ataque a RSA basado en el tiempo de ejecución de una potencia realizada con el método de cuadrados repetidos ( repeat squaring ).
En este post vamos a hablar un poco del análisis de potencia ( power analysis ), en qué se basa y cómo funciona. No voy a poner ningún ejemplo concreto aquí, aunque al final enlazo a una página con ejemplos para matlab/octave.
Bases del análisis de potencia
Los ataques mediante análisis de la potencia consumida se basan en que, en un microcontrolador o microprocesado, la potencia consumida por el dispositivo depende de:
- La instrucción ejecutada
- Los datos tratados en dicha instrucción
Así pues, si la potencia consumida depende de los operandos de la instrucción, es lógico pensar que analizando dicha potencia consumida en un proceso conocido pero con unos datos desconocidos ( clave? ) podríamos llegar a obtener estos datos desconocidos.
Medida de la potencia consumida en smart cards
Como ya conocemos, la alimentación y el reloj de una smart card es proporcionada por el lector mediante sus pines externos. Por tanto, es sencillo introducir elementos en esa red de alimentación para poder calcular el consumo de potencia del dispositivo durante su operación.
El circuito más sencillo que se nos puede ocurrir es introducir una pequeña resistencia en serie con la línea de Vcc o de GND del dispositivo, por ejemplo de 1 ó 50 Ohmios. De esta forma, la corriente que fluye por la resistencia es la misma que la que fluye por el dispositivo, y realizando una medida de la tensión caída en dicha resistencia tenemos un valor proporcional al consumo de potencia del dispositivo.
Otra opciones más avanzadas incluyen el uso de circuitos estabilizados con la intención de que el circuito de medida afecte en la menor manera posible al dispositivo que se está analizando.
Análisis de potencia simple (SPA)
El análisis de potencia simple, o SPA de sus siglas en inglés, se basa en la inspección de una o unas pocas trazas de la potencia consumida por el dispositivo bajo estudio. De esta forma resulta sencillo obtener información sobre qué operación está realizando el dispositivo mediante la observación de patrones conocidos en las trazas.
Por ejemplo, la observación comentada en el post anterior sobre RSA se podría realizar con una de estas trazas directamente, mientras que con DES o AES probablemente no seríamos capaces de deducir ninguna clave. Lo que sí seríamos capaces es de determinar que se está realizando un cifrado DES debido a la aparición de 16 patrones similares que denotan las 16 rondas de cifrado/descifrado de DES.
Análisis de potencia diferencial (DPA)
Esta modalidad del análisis de potencia requiere la adquisición de muchas trazas de la potencia consumida por el dispositivo. Básicamente el procedimiento es el siguiente:
- Adquirir trazas de potencia del dispositivo
- Escoger un resultado intermedio del cifrado para atacarlo
- Calcular todos los posibles valores del resultado intermedio
- Obtener una estimación del consumo de potencia en base a dichos valores
- Calcular mediante alguna función de medida la clave más probable
Como ejemplo, en el punto 2 podríamos escoger los valores de salida de la primera S-box de AES ( o el componente SubBytes que es lo mismo) en la primera ronda de ejecución, y para cada valor del primer byte de la clave, k, combinado con el primer byte de datos,d, obtener el valor S[ k XOR d].
A partir de aquí se aplica el modelo de consumo elegido, que puede ser tan simple como LSB del valor o un poco más elaborado como el peso hamming del mismo, HW(S[ k XOR d]).
Finalmente se realiza la comparación mediante algún operador estadístico como puede ser la correlación de las trazas con el consumo estimado, o la diferencia de las medias como se explicaba en el paper original de Paul Kocher y otros. Todas estas funciones de medida tienen la propiedad de que a mayor resultado, más probable es la clave. Por tanto, buscando el máximo de la comparación encontraremos el valor del resultado intermedio, y de ahí el de la clave.
También tienen la propiedad de que a mayor número de trazas, más fácil encontrar el valor correcto de la clave; así pues, el número de trazas necesario para romper una implementación puede ser usado como indicativo de la seguridad de las protecciones implementadas en la misma, de las cuales hablaré un poco más adelante.
No voy a decir más sobre esto, pero existen libros completos sobre el tema de análisis de potencia, así que voy a dejar simplemente la referencia a un libro y a su web. El libro se llama Power Analysis Attacks, de la editorial Springer, y en su web se pueden obtener trazas en un workspace para matlab y/o octave, además de un ejemplo guiado de ataque.
Ataques a smart cards: side channel analysis (I)
Volvemos a darle un poquito al tema de las smart cards ;-). Antes de continuar, sería recomendable que quien no conozca prácticamente nada sobre smart cards lea los posts anteriores al respecto:
- Introducción
- Normas y comunicación
- Clasificación de ataques
Pese a que hay mucha información al respecto en Internet y en libros, no sé si la hay en español así que espero que siga resultando útil/interesante a la gente :-).
En este post vamos a ahondar un poco más en uno de los ataques más famosos sobre smart cards. Se trata del llamado Side Channel Analysis o SCA ( en español supongo que se traduciría como análisis de canales adyacentes o algo similar) que consiste en analizar datos procedentes de la smart card por canales alternativos.
Como ya vimos, una smart card se comunica con el exterior únicamente mediante una interfaz serie a través de uno de sus contactos. En cambio, como cualquier dispositivo electrónico, estas tarjetas 'sufren' algunos fenómenos físicos que permiten obtener información. Veamos los principales canales utilizados:
- Información temporal: realizando mediciones de lo que tardan distintas operaciones.
- Consumo: midiendo el consumo de potencia del dispositivo también es posible determinar qué está haciendo.
- Radiaciones electromagnéticas: como todos sabemos, cualquier movimiento de electrones genera un campo electromagnético, y nuestras tarjetitas no iban a ser menos.
En este primer post sobre side channel analysis vamos a ver un ejemplo de información temporal que nos puede ayudar a romper un algoritmo considerado seguro como RSA debido a una 'mala' implementación. Para ello primero (en la página extendida para no alargar mucho la portada) explicaré brevemente cómo funciona RSA, la implementación base que usaremos y luego el problema que tiene y cómo podríamos solucionarlo.
Smart cards: clasificación de ataques
Seguimos con la serie de smart cards. Tras introducir el tema y hablar de los estándares al respecto, la idea inicial era seguir explicando la evolución de los SOs para estas tarjetitas (que es muy similar a lo que pasó con computadoras y ordenadores personales 😉 ) e introducir JavaCard, pero creo que resultará más interesante meternos en posibles ataques a este tipo de dispositivos seguros.
En este primer post sobre ataques vamos a definir una clasificación de los ataques y nombrar los más comunes, y en unos días dedicaré algún post a varios de estos ataques.
Antes de la clasificación, definiremos un par de conceptos que como no sé cómo traducir al español (no encuentro una traducción que me guste) nombraré en inglés:
- Se dice que un dispositivo es tamper-resistant cuando no se pueden realizar modificaciones del dispositvo ( to tamper with the device ) de manera no autorizada.
- Se dice que un dispositivo es tamper-evident cuando deja señales de que ha sido modificado de manera no autorizada.
En base a estos conceptos, vamos a definir los ataques como invasivos y no invasivos. Un ataque no invasivo no modifica el dispositivo, y por tanto es capaz de violar las propiedades de tamper-resistance y tamper-evidence. En cambio, un ataque invasivo deja evidencias del mismo, por tanto únicamente viola la propiedad de tamper-resistance.
Dentro de ataques de tipo no invasivo podemos encontrar:
- Ataques lógicos, explotando fallos en el software o los protocolos empleados
- Ataques de tipo Side channel analysis (¿análisis del canal adyacente?) que se basan en analizar fugas de información por canales diferentes al bus serie de comunicación de las tarjetas ( consumo de potencia, radiación EM, tiempos...).
- Ataques con fault injection, que introducen fallos en la tarjeta ( modificando la alimentación, el reloj...).
En cuanto a ataques invasivos nombramos los siguientes:
- probing, consistente en conectar agujas de medida sobre algunas líneas de la tarjeta, por ejemplo el bus de datos.
- fibbing, realizado con un focus ion beam (FIB), de ahí el nombre. Permite observar y realizar cambios en la tarjeta, añadiendo puntos de conexión, cables, etc.
- Ingeniería inversa óptica, para reconocer las partes del circuito e incluso con algunas técnicas obtener el contenido de la memoria.
- Algunos tipos de fault injection son invasivos.
Obviamente, los ataques dependen mucho del tipo de atacante. Cualquiera con pocos medios (un lector de tarjetas y poco más) puede intentar estudiar el protocolo e inducir fallos lógicos, mientras que para realizar side channel analysis se necesita equipamiento algo más caro, y para los ataques invasivos generalmente se necesita equipamiento muy especializado.
Existen laboratorios que realizan este tipo de ataques para sus clientes, por ejemplo aquí en Holanda Riscure (donde voy a hacer el PFC finalmente) y Brighsight (que visitaremos el 29 de enero) realizan este tipo de análisis de seguridad, ambos en Delft.
Además, Riscure (que es el que conozco un poco) realiza análisis de Set Top Boxes para PayTV, analizó el sistema IPTV de Microsoft y está acreditado por Mastercard para realizar auditorías mediante el programa de certificación CAST.
Esto es todo de la descripción, próximamente algún ejemplo de Side Channel Analysis y enlaces a documentos interesantes al respecto 🙂
Smart cards: normas y comunicación con el terminal
Vamos a seguir comentando un poquito más acerca de las smart cards, las tarjetas inteligentes de las que empecé a hablar hace casi un mes. En este post voy a comentar algo que en principio no tiene mucho que ver con la seguridad de los sistemas con estas tarjetas, pero que conviene conocer: los estándares que definen las características de estas tarjetas y la forma de comunicarse con el exterior.
El estándar actual de smart cards (de contacto, para RFID hay otros estándar) es la familia ISO 7816, que define básicamente todo lo que se pueda imaginar relacionado con las tarjetas:
- 7816-1: Carcaterísticas físicas
- 7816-2: Dimensiones y contactos de las tarjetas
- 7816-3: Señales eléctricas y protocolos de transmisión.
- 7816-4:Conjunto de comandos estándar
- ...
Hay más, hasta 15 según la wikipedia, pero aquí simplemente voy a comentar ciertas características y el formato de los mensajes.
Smart cards: Introducción
Puesto que este cuatrimestre estoy haciendo una asignatura basada al 90% en smart cards, aprovecho para contar aquí algunas cosillas de las mismas que tal vez resulten de interés :). En este primer artículo veremos qué es exactamente una smart card, comentando sus principales bloques funcionales y para qué se pueden utilizar. Más adelante comentaré algunas peculiaridades de la programación de smart cards usando la plataforma JavaCard.
Arquitectura típica de una smart card
Básicamente una smart card es un computador embedido en un pequeño chip, capaz de almacenar y procesar de forma segura datos. Generalmente se divide en varios tipos de smart cards, en función de sus posibilidades:
- Tarjetas de memoria: almacenan datos que pueden ser leídos a posteriori, posiblemente con cierto control de acceso o con mecanismos de memoria destructiva ( write-only ). Toda la funcionalidad de estas tarjetas está en una memoria ROM, de forma que siempre responden de la misma forma a una instrucción (leyendo la dirección de memoria correspondiente).
- Tarjetas con microprocesador: Además de almacenar información, estas tarjetas incorporan un microprocesador para el tratamiento de dicha información mediante el software correspondiente.
A veces se incluye (vease tarjetas inteligentes en wikipedia) otro tipo de tarjetas llamado tarjetas criptográficas, que incluye además un coprocesador criptográfico capaz de realizar cifrado utilizando por ejemplo RSA, DES o triple DES. Sin embargo yo este tipo lo incluiría en el grupo de tarjetas con microprocesador.
Aquí me centraré en las tarjetas con microprocesador, puesto que las podemos programar y son capaces de ofrecer funciones de seguridad bastante interesantes. Generalmente estas tarjetas llevan 3 tipos de memoria:
- ROM: Incluye el sistema operativo de la tarjeta.
- EEPROM: El disco duro de estas tarjetas.
- RAM:Espacio de trabajo donde encontramos la pila, variables temporales como claves criptográficas válidas durante la sesión actual, etc.
Según los datos que yo tengo de la asignatura HW & OS Security , una tarjeta actual típica puede tener unos 512 bytes de RAM, 16K de ROM y 64K de EEPROM. En principio se usaban SO propietarios y cada tarjeta se programaba con su propia API en C, pero actualmente existen sistemas como JavaCard que ofrecen una API común que los fabricantes pueden implementar en sus tarjetas. Más adelante veremos cómo realizar aplicaciones básicas con JavaCard ;).
Aplicaciones de las smart cards
Para finalizar con este post introductorio simplemente voy a comentar algunas de las aplicaciones comunes de las smart cards.
- Firma digital: Puesto que las tarjetas son capaces de realizar funciones criptográficas, pueden utilizarse para firmar documentos digitalmente. Simplemente se almacenan en la tarjeta las claves criptográficas correspondientes al usuario (clave privada RSA por ejemplo) y cuando se le pasa un documento a la tarjeta ésta lo firma. El problema que puede surgir aquí es que realmente no sabemos lo que se está mandando a la tarjeta para firmarlo, así que habría que autenticar de alguna forma el terminal usado.
- Dinero electrónico: Se pueden utilizar estas tarjetas como monedero electrónico. Por ejemplo, en Holanda tienen el sistema Chipknip.
- TV de pago: televisiones como Digital+ utilizan este tipo de tarjeta para identificar al usuario. La tarjeta se introduce en el decodificador y con ella se tiene acceso al contenido de pago, mediante claves de cifrado contenidas en la tarjeta.