Grand opening EiPSI: Bruce Schneier y Whitfield Diffie en Eindhoven
Los próximos días 21 y 22 de abril se inaugura el nuevo grupo de investigación de la TUe sobre seguridad de la información y criptografía, llamado EiPSI. Para celebrarlo, se ha organizado un evento con charlas bastante interesantes sobre criptografía en la universidad, en las que estarán como reza el título Bruce Schneier (autor del famoso Applied Cryptography y de uno de los algoritmos propuestos para el estandar AES, Twofish ) y Whitfield Diffie, uno de los autores del famoso intercambio de claves Diffie-Hellman entre muchos otros.
Yo estaré allí el lunes y si me dejan en la empresa el martes también. Había que registrarse antes de este miércoles, pero como no me lee nadie que esté por aquí pues creo que tampoco pasa mucho por avisar tan tarde.
Se puede ver el programa aquí. Ya daré mis impresiones cuando llegue el momento ;-).
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.
Volviendo a la vida…
Después de una semana santa con visitas en la que no he parado un minuto, ahora intento volver a la rutina. El día 20 vino mi prima de visita, se fue el 25 y luego vino otra visita (tíos y abuela) que se fue el sábado por la mañana. Además el viernes noche salimos por Amsterdam por primera vez desde que llegué aquí y ayer había fiesta en una casa (y ganamos el concurso de cerveza 😀 ) ... Resultado: mucho turismo y fiestas, y bastante reventado.
Hace más de dos semanas que tengo un post a medias en borradores y nunca encuentro el momento de acabarlo, y así está el blog, abandonaico el pobre. A ver si en unos pocos días vuelvo con contenidos de verdad 😉
Al menos sabéis que estoy vivo 😆
PD: He actualizado la versión de wordpress que ya era hora... ahora tengo tags además de las categorías anteriores, así que empezaré a intentar taggear los posts
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.
Visita al FOSDEM 2008 ( Bruselas )
Como dije en el post anterior, hoy me he acercado al FOSDEM 2008 en Bruselas. He salido en tren a eso de las 8 de la mañana desde Eindhoven y he llegado al campus de la ULB pasadas las 11:30, así que no he podido asistir a algunas de las charlas que quería.
La primera charla a la que he asistido ha sido sobre la suspensión a RAM y a disco de Linux, dada por Stefan Seyfried de openSUSE . Ha durado media hora y ha comentado el state of the art y lo que deberíamos ver en un futuro próximo en el soporte de suspensión.
Después he dado una vuelta por los stands que hay ( OpenBSD y OpenSSH, Mozilla foundation, *BSD, OOo, fsfef, ... ) y he comido algo antes de meterme en la charla de la devRoom de CentOS y Fedora donde he asistido a una charla sobre las últimas novedades de lvm2: caching, nuevos comandos, nuevas opciones y algunas mejoras.
Ahora mismo estoy escribiendo este post desde una charla del OWASP sobre WebScarab-NG, un proxy HTTP al estilo paros proxy (y muchos otros) con spider, fuzzer y demás utilidades para realizar tests de penetración sobre aplicaciones web. Aunque no parece aportar mucho respecto al resto de proxies que conocía, ahora está empezando a mostrar funcionalidades para acceso a servicios web accediendo al fichero WSDL y demás... le echaré un ojo al programilla un día de estos.
Al acabar (que será cuando postee esto porque en esta sala no hay red) me acercaré a una otra charla corta sobre migración de Linux a FreeBSD a ver qué se cuentan. Y luego ya toca la closing talk y a coger el bus y hacia Eindhoven de nuevo... aunque posiblemente pase a comprarme alguna camiseta por los stands, de merchandising de OpenSSH o del propio FOSDEM.
FOSDEM: el evento europeo de ‘la comunidad’ SL y OS
Este fin de semana está teniendo lugar el FOSDEM en Bruselas. Para quien no lo conozca, como digo en el título es un evento sobre software libre y código abierto a nivel europeo que se realiza todos los años. En él tienen lugar charlas sobre diferentes proyectos de software libre, lenguajes de programación, distribuciones, etcétera.
En Linux Magazine están retransmitiendo las charlas principales vía streaming, y supuestamente estarán colgadas una vez terminado el evento para quien no haya podido verlas en directo. Yo por mi parte mañana me acercaré, si las líneas de trenes de aquí me lo permiten que parece ser que hay obras entre Eindhoven y Tilburg y debo pasar por ahí para ir a Bruselas.
On vacation…
Pues como dice el título, desde hoy hasta el próximo día 14 estaré de vacaciones... ahora mismo estoy en España, parto hacia Valencia en un rato y hacia Madrid esta noche, desde donde volaremos a Punta Cana como viaje final de carrera (aunque aun no he acabado, pero lo haré si todo va bien en septiembre, cuando presentaré el PFC).
Así pues, el blog estará abandonado estos días, y probablemente no de señales de vida hasta el día 15 cuando llegue a Holanda de nuevo.
Cuidad de esto por mi 😛
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.