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

En primer lugar, supongamos que realizamos una firma mediante RSA-CRT en un dispositivo embebido. Entonces, el dispositivo calcula mediante el cálculo de y , y realiza la combinación apropiada para obtener . Esto se hace mediante la fórmula , donde a y b son los resultados antes mencionados que se calculan mediante las siguientes fórmulas:

a= 0 (mod p), a=1 (mod q)

b=1 (mod p), b=0 (mod q)

Así pues, supongamos que ahora realizamos un ataque mediante glitching e introducimos un fallo en el cálculo de , de forma que ya no cumple . Entonces, obviamente el resultado es incorrecto, pero... ¿podemos aprovecharlo?

Poniendo todas las ecuaciones que tenemos juntas, vemos que la diferencia entre el valor correcto c, y el valor en el que hemos inducido nuestro fallo, c', cumple lo siguiente:

Por tanto, si calculamos el máximo común divisor de c-c' y n=p·q, este caso nos daría el valor de q ya que es el único factor común entre ambos, pues c-c' es múltiplo de q pero no de p. Este cálculo se puede hacer de forma eficiente mediante el algoritmo de Euclides.

Así pues, mediante un poco de matemáticas y una inyección de un fallo en un resultado resulta muy sencillo obtener la clave RSA. Esto deja clara la necesidad de proteger los dispositivos embebidos ante este tipo de ataques.

Este ejemplo ha sido sacado de las notas de Henk Van Tilburg para Cryptography 1 .

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.

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.

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:

1. Adquirir trazas de potencia del dispositivo
2. Escoger un resultado intermedio del cifrado para atacarlo
3. Calcular todos los posibles valores del resultado intermedio
4. Obtener una estimación del consumo de potencia en base a dichos valores
5. 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.

- 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.

El algoritmo RSA

RSA es un algoritmo de cifrado de clave pública que basa su fortaleza en la dificultad computacional de factorizar grandes números comparada con la sencillez de realizar un producto entre esos factores.

La generación de claves RSA es como sigue:

• Elección de dos números primos de tamaño similar, p y q (y no es conveniente que estén demasiado cerca).
• Cálculo de n=p·q.
• Elección de un valor e arbitrario. Se usa mucho 65536, también conocido como F4.
• Cálculo de d tal que e·d=1 (mod phi(n) ). Aquí phi(n) es el totient de Euler, que indica la cantidad de números coprimos (es decir, sin factores comunes) con n entre 1 y n-1. En este caso, es conocido que phi(n)=(p-1)(q-1) (si alguien está interesado seguro que puede encontrar una demostración ).

A partir de aquí, la clave pública consta del módulo n y del valor del exponente público e, y la clave privada del módulo n y del exponente privado d. Ni que decir tiene que d no debe ser conocido más que por el propietario de la clave y que p y q deberían eliminarse o mantenerse en lugar seguro .

El cifrado de un mensaje m en RSA se realiza como c= m^e ( mod n ), y el descifrado como m'=c^d = m^(d·e) = m (mod n) debido al teorema de Euler.

No me voy a extender más con RSA, quien esté interesado en más detalles no le resultará excesivamente complicados encontrarlos.

Implementación de la exponenciación modular con productos y cuadrados

Para explicar esto voy a hacer uso de un pequeño ejemplo ya que seguro que resulta más sencillo. Vamos a ver cómo realizaríamos el cálculo 2^17 (mod 19) de forma sencilla sin tener que recurrir a números enormes (como 2^17 ).

En primer lugar, reescribimos la potencia tal que: 2^17= 2^16·2 = (2^8)^2 · 2 = ... = ((((2^2)^2)^2)^2)·2. En segundo lugar, realizamos cada cálculo intermedio módulo 19:

2^2 = 4
2^4 = (2^2)^2 = 4^2 = 16
2^8 = (((2^2)^2)^2 = 16^2 = 256 = 9
2^16 = 9^2 = 81 = 5
2^17 = 2·5 = 10

Si alguien no se fía y tiene Mathematica que ponga PowerMod[2,17,19], o en Matlab mod(2^17,19) .

Viendo lo de arriba quizás no os diga nada, pero resulta que si pasas 17 a binario tienes 10001, y si se compara con lo anterior se ve que cuando el exponente tiene un 1 en binario, se hace un cuadrado y una multiplicación, y cuando tiene un 0 se hace un cuadrado solamente.

Así pues, el algoritmo sería algo como:

s=x
for i in 1 to n
s=s^2 (mod N)
if( di == 1 )
s= s*x;
end for
return(s)

Donde d=(d0,d1,d2,...,dn) es la representación binaria de d, con d0 el bit de mayor peso y siempre igual a 1.

Problema de esta implementación

Claramente, esta implementación tiene el problema de que dependiendo de si el bit de la clave es 1 o 0 se va a realizar un cuadrado o un cuadrado más una multiplicación, con lo cual habilita un análisis de tiempos. Así pues, si medimos el consumo de potencia o la radiación electromagnética y comparamos el tiempo de los distintos picos que aparecen correspondientes al cifrado RSA es posible determinar qué bits de la clave son 0 y qué bits son 1.

He estado mirando por ahí a ver si encontraba imágenes al respecto y no he encontrado nada (o no estoy en muy buenas condiciones para buscar), así que os remito a las transparencias de Erik Poll sobre el tema en la página 32 si estáis interesados.

Posibles contra medidas

Es obvio que para evitar este ataque habría que intentar que la clave no estuviera tan relacionada con el tiempo de ejecución. Una posible idea sería realizar el cálculo completo siempre y elegir el resultado en función del bit de la clave, de forma que siempre se realizaran las mismas operaciones.

Otra opción es realizar la multiplicación exponencial con grupos de bits en lugar de bit a bit, precalculando los factores de ponderación necesarios para cada resultado. De esta forma se dificulta la recuperación de la clave, aunque no sé hasta qué punto... lo que si sé es que si miras una traza de consumo realizada con esta técnica es difícil determinar cuando los dos bits eran 00, 01, 10 o 11 al menos a simple vista como en el caso expuesto.

Otra opción ante el timing analysis es lo que llaman RSA Blinding, aunque no ante este ataque en concreto. Se basa en calcular un valor aleatorio r para cada texto cifrado recibido, calcular su inversa, y realizar el descifrado como (r^e·c)^d (mod n). De esta forma se tiene r·m (mod n), y multiplicando por la inversa de r obtenemos m.

Como he dicho, esto no sirve de nada si se realiza la potencia de la forma expuesta, pero sirve como protección ante otros tipos de análisis de tiempos que funcionan incluso sin usar esta implementación.

PD: Si has llegado aquí mereces un permio Otro día más sobre SCA, concretamente Power Analysis

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

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.

En primer lugar, las smart card tienen actualmente 5 contactos usados, como se puede ver en la siguiente imagen:

Anteriormente el contacto C6 de la imagen era para programar la EEPROM mediante una tensión de programación  (Vpp) bastante más elevada que la de alimentación, Vcc.

Se puede observar que la tarjeta no tiene alimentación propia, ni siquiera reloj propio, sino que todo ello le es proporcionado por el terminal/lector.  Esto es importante porque puede llevar implicaciones de seguridad como veremos más adelante. Además, se ve que se trata de una interfaz de comunicación serie bit a bit a través del pin I/O.

En cuanto a la comunicación entre terminal y tarjeta, el terminal activa la tarjeta mediante un proceso definido en ISO 7816-3: activa las líneas tierra, tensión, reloj y reset. A esto la tarjeta responde con un ATR (Answer To Reset) y se da por iniciada la comunicación.

Cualquier comunicación SIEMPRE es iniciada por el terminal, enviando comandos a la tarjeta, y ésta realiza los cálculos o acciones que deba realizar y responde.  Estos comandos son las llamadas APDU, Application Protocol Data Unit. La trama APDU de tipo comando consta de los siguientes campos:

• CLA : Byte de clase
• INS : Byte de instrucción
• P1,P2: Parámetros
• Lc : tamaño del bloque de datos
• Bloque de datos
• Le : Tamaño de la respuesta esperada

Los 4 primeros son obligatorio, mientras que los relacionados con los datos y la respuesta esperadas son opcionales. A partir del byte de instrucción, la tarjeta sabe qué es lo que se le pide y responde con una APDU de respuesta, que consta de los campos:

• Datos
• SW1 y SW2: Palabra de estado, dónde se codifica el estado de la operación (correcta, error criptográfico, error general...).

Una vez más, los datos son opcionales pero el código de estado es obligatorio.

Mediante este sencillo mecanismo se comunican hoy en día todas las smart cards disponibles.  Con esto ya sabemos cómo se le ordena a una smart card que realice una acción determinada y en qué formato viajan esos datos.  En próximos posts hablaremos de la evolución de los SO para smart cards, una pequeña introducción a Java Card y de ataques que se suelen realizar a este tipo de dispositivos... aunque no necesariamente en este orden, seguramente primero de ataques que es más interesante .

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.