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.
ProVerif bajo Mac OS X ( ProVerif under Mac OS X )
Note: You can find an english version of these instructions in the extended version of this entry, by clicking on 'Lee el resto de esta entrada'.
Escribo esta rápida nota sobre cómo instalar ProVerif en Mac OS X entre otras cosas porque he visto que alguien andaba buscando instrucciones. ProVerif es una utilidad para verificar protocolos criptográficos basada en el uso de spi-calculus y cláusulas de Horn, en la que se especifica un modelo del protocolo criptográfico y las metas del mismo ( s es secreto, o se ha autenticado A con B, ...).
Para instalarlo en Mac OS X lo primero que necesitamos es Ocaml. Vamos a download y bajamos el código fuente. Una vez hecho la instalación se resume en lo siguiente (tras haber descomprimido el tar.gz del código fuente):
$ cd ocaml-3.10.2
$ ./configure
$ ls
$ make world
$ make opt
$ sudo make install
El siguiente paso es situarse en la carpeta de ProVerif y ejecutar el archivo build:
$ cd ../proverif1.14pl4
$ ls
$ ./build
Si no obtienes ningún error, ya tienes compilado ProVerif. Puedes comprobar que funciona utilizando la utilidad analyzer con alguno de los ejemplos en examples:
$ ./analyzer examples/auth/needham
[... output omitted]
RESULT goal reachable: end:x_6,y_7
Y para aprender sobre ProVerif puedes mirar las transparencias de la asignatura Verification Of Security Protocols.
BlackHat DC 2008: Presentaciones online
Aunque hace una semana ya tuve posibilidad de acceder a algunas de las presentaciones de la Black Hat DC 2008 debido a que uno de mis jefes estuvo allí dando una charla, no quise publicar nada hasta hoy que me he dado cuenta de que las transparencias ya estaban online en los archivos.
Hay una serie de presentaciones sobre embedded devices que se dieron durante el segundo día, entre ellas una de Side Channel Analysis, otra sobre seguridad física ( Security Failures in Secure Devices ), análisis forense en Cisco IOS ... Otra que también puede resultar interesante es la dedicada a dipositivos de control de acceso biométricos o basados en tokens.
Además estuvo la tan comentada charla sobre cracking de A5/1 (cifrado de GSM), y otras más típicas como seguridad en oracle, cosillas sobre overflows, dtrace aplicado a ingeniería inversa, CSRF y alguna cosa más.
Desde luego una buena fuente de información si se tiene algo de tiempo y ganas 🙂
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.
Nuevo cuatrimestre, nuevas clases… y proyecto
El lunes pasado comenzó el segundo cuatrimestre y ya tengo nuevos frentes en los que lidiar en clase. Este cuatrimestre voy a hacer dos asignaturas y el PFC, con lo cual a finales de julio probablemente habrá concluido mi carrera a la espera de presentar el PFC en Valencia por septiembre.
Las asignaturas que tengo este nuevo cuatrimestre pintan interesantes, aunque parece que tengan una carga matemática importante y que me van a mandar unos cuantos trabajitos semanales para ir haciendo:
- Cryptography 2: se divide en dos partes, protocolos y sistemas. En la primera parte Berry Schoenmakers nos dará nociones sobre protocolos criptográficos incluyendo pruebas de su seguridad y concluirá con un examen parcial. En la segunda parte, Benne de Weger (el mismo de las colisiones en MD5 ) hablará de criptosistemas: PKI, Single sign-on, SSL, Kerberos, etc. y concluiremos la asignatura con dos papers.
- Verification of Security Protocols: en esta asignatura aprenderemos a verificar la seguridad de protocolos de comunicación que empleen criptografía, ya sea con métodos manuales o utilizando herramientas como proVerif. Tiene trabajos (70%) y examen final (30%).
En los enlaces se pueden encontrar las notas de clase y/o transparencias, si no ahora conforme vaya avanzando el curso.
Finalmente, ya he empezado el proyecto en la empresa Riscure en temas relacionados con smart cards y side channel analysis aunque de momento no he avanzado demasiado. Ahora tengo dos semanitas de vacaciones para irme de viaje final de carrera con la gente de Valencia, y luego vuelta al trabajo de nuevo.
FireGPG: GnuPG en tu Firefox
Hace un par de días estuve buscando cómo podía integrar GPG con Firefox y/o Gmail para poder cifrar/firmar correos desde el navegador sin tener que irme a copiar el texto a un archivo, cifrar/firmar el texto y luego copiarlo a Gmail cada vez.
Al poco de empezar encontré una extensión de Firefox llamanda FireGPG que necesita de GPG instalado y te permite utilizar las funciones de GPG desde Firefox. Se integra perfectamente en Gmail añadiendo botones de Firmar, Cifrar, Firmar y Enviar, Cifrar y Enviar, ... y verificando las firmas recibidas de manera automática.
Además añade una opción al botón derecho que te permite cifrar,firmar y verificar firmas de selecciones y contenidos de los formularios, importar y exportar firmas, y abrir una ventana de un editor propio para realizar allí las acciones que desees.
Es bastante cómodo y resuelve a la perfección el problema de usar GPG desde un Webmail 🙂
Presentaciones de 24C3
Javi comentó hace unos días sobre una de las presentaciones del congreso 24C3 sobre smart cards (gracias 😉 ). Ayer noche estuve echando un ojo a las otras presentaciones y algunas me resultaron interesantes.
Hoy les he estado echando un ojo y viendo alguno de los videos porque no me encuentro muy bien para leer ni programar con lo del proyecto, y además tenía parte de la mañana ocupada con una entrevista con un profesor para comentar un trabajo de una asignatura y que me dijera la nota.
Estas son las presentaciones que he visto por el momento, sea el video o solo el PDF:
- Inside de Mac OS X kernel: en esta presentación lucy presenta (valga la redundancia) las características más importantes de XNU, el kernel de Mac OS X, dejando claro qué hay de BSD, de Mach y de microkernel (uh?) en éste. Muestra el diseño del kernel (sus bloques principales y su situación [userspace/kernelspace] , el área de memoria que recibe cada proceso, los conceptos que aporta Mach, etc.) . Me ha parecido interesante, en el video se ve mejor pues hay cosas (algunas animaciones y tal) que no salen en el PDF.
- Mifare security: Se presentan las características del chip RFID Mifare de NXP Semiconductors (formerly Philips :P) y su cifrado propietario, en base a un estudio via ingeniería inversa de dicho chip. Por aquí se ha hablado mucho estos días de Mifare y de la tarjeta OV Chipkaart, que es una tarjeta para transporte público que se está implementando y que han conseguido clonar hace poco de forma que pueden realizar viajes infinitos pagando una tarjeta de dos :roll:. Está interesante la charla, aunque aun estoy a mitad ahora mismo 🙂
- Smartcard protocol sniffing: esta es la que comentaba Javi en el otro post, muestra cómo realizar sniffing de la comunicación entre la smart card y el terminal, viendo las APDUs que circulan y demás. Solo he leído la presentación, pero personalmente no me ha aportado demasiado porque ya vi algún circuito de este estilo; de todas formas es interesante si no se conoce nada del tema.
Además de esto, he bajado la que habla de kernel exploitation, embedded devices, replay attacks on payment cards, windows post-exploitation y puede que alguno más. Si alguno de ellos lo encuentro especialmente interesante o tengo algo que comentar lo haré en unos días 🙂
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 🙂