Tarjetas inteligentes y PKCS

Introducción a las tarjetas inteligentes y PKCS

La primera patente sobre tarjetas inteligentes data de 1970. Se considera que

una tarjeta es inteligente si incorpora algún tipo de procesador y hardware con

propiedades especiales y específicas. Normalmente proporcionan algún

servicio de seguridad a una entidad externa. Existen otros dispositivos con

funcionalidades similares pero las tarjetas inteligentes son las más extendidas.

El aspecto físico y lógico que tiene un chip genérico puede verse en la figura

13.

Ver las conexiones de reloj (CLK), corriente (Vcc), toma de tierra (GND),

entrada/salida (I/O) y reset. La gran característica es que son capaces de aislar

la información que contienen y las operaciones del mundo exterior. Su

hardware interior es capaz de ejecutar operaciones a petición de un agente

externo y devolver el resultado, según el sistema operativo del que se le haya

dotado. Las características generales de las smart-card están definidas en los Figura 13. Aspecto de un chip electrónico

estándares ISO 7816-1 hasta el 7816-11 y entre otras muchas tienen un modo

de transmisión de la información, según el 3:

• T=0, a nivel de byte

• T=1, a nivel de bloque

y unos formatos de instrucción (APDU) según el 4. Este trabajo se centrará en

el subconjunto de las tarjetas criptográficas y más concretamente en el DNIe,

aunque existen otras muchas como la tarjetas Siemens CardOS, Cryptoflex, o

la tarjeta OpenPGP. Existen también otros dispositivos que van por USB y no

necesitan lector, son los Tokens USB, como Aladdin eToken PRO. Estos y

muchos se basan en el estándar PKCS#11.

PKCS es el acrónimo de Public-Key Cryptography Standards y son una serie

de estándares publicados por los Laboratorios RSA. Los más importantes son:

-PKCS#1 v2.1. Estándar del algoritmo de clave pública RSA

-PKCS#3 v1.4. Estándar de intercambio de claves Diffe-Hellman

-PKCS#7 v1.5. Estándar de sintaxis del mensaje criptográfico, base

del S/MIME

-PKCS#10 v1.7. Estándar de formato de un CSR

-PKCS#11 v2.20. Estándar de interfaz de dispositivo criptográfico

-PKCS#12 v1.0. Estándar de formato de los archivos de certificado

-PKCS#13 en desarrollo, sobre la criptografía de curvas elípticas

-PKCS#14 en desarrollo, sobre la generación de números pseudo-

aleatorios

-PKCS#15 v1.1. Estándar de formato de información de dispositivo

criptográfico

PKCS#11 define un API genérico en lenguaje ANSI C para el acceso a

dispositivos electrónicos con procesador criptográfico y capaces de manejar

objetos tales como claves RSA, certificados x.509, claves simétricas etc. Este

API suele denominarse Cryptographic Token Interface (Cryptoki) y no es más

que una declaración formal de cómo deben ser las cabeceras de las funciones,

los parámetros que reciben y devuelven y las estructuras de datos que

manejan. El listado de funciones y todo lo demás puede consultarse en la

página de RSA. La idea es que sea cual sea el dispositivo que se vaya a

manipular, el interfaz de programación sea el mismo. Según la política del

desarrollador del chip se implementarán unas funciones u otras que realizarán

peticiones al sistema operativo que domine el chip; esto puede entenderse

pensando el DNIe, el cual no está hecho para poder exportar la clave privada,

por ejemplo.

Una aplicación que utiliza una librería Cryptoki es capaz de realizar

operaciones con claves privadas sin necesidad de conocer el valor de la misma

Como puede verse en la figura 14, esta capa de abstracción la consigue

dividiendo su espacio de memoria en TOKENS genéricos (que responden a

cualquier tipo de dispositivo criptográfico, como por ejemplo tarjetas)

contenidos en un SLOT. Cada Token contiene un número de OBJETOS con

características muy concretas, los cuales se pueden crear, destruir, modificar.

Sobre cada uno de ellos podrán realizar unas ciertas operaciones según los

MECANISMOS (algoritmos criptográficos) soportados, en lo que dure una Figura 14. Funcionamiento de un dispositivo PKCS#11

SESIÓN de usuario. Un objeto es una secuencia de Atributo-Valor que podría parecerse a la figura 15: Atributo Valor OBJECT_CLASS PRIVATE_KEY KEY_TYPE RSA TOKEN YES EXTRACTABLE NO LABEL PEPE_PRIVATE_KEY PRIVATE_EXPONENT 8124564... MODULUS 7234035054...

Donde se puede ver un ejemplo de una clave privada RSA marcada como de

NO lectura, por lo que las operaciones con ella sólo puede hacerlas dentro del

chip.

Cada objeto puede tener una política de protección distinta e incluso dentro de

un mismo chip se pueden crear varios PIN's, para varios usuarios, aunque esta

posibilidad no la contempla el PKCS#11, sino el PKCS#15. Del mismo modo se

puede hacer que las operaciones a realizar tengan su política propia, para que

por ejemplo las claves públicas pueda leerlas cualquiera.

En general, si una aplicación quiere realizar una operación no tendrá más que

especificar cuál (de todas las proveídas por la librería Cryptoki del dispositivo),

con qué clave (identificador) y sobre qué información. El dispositivo realizará

las operaciones con su procesador y devolverá el resultado a la aplicación Figura 15. Objeto PKCS#11

Si por ejemplo se va a firmar un formulario con el DNIe a través de Internet con

firefox, tal y como se representa en la figura 16, el navegador sólo necesita

conocer el identificador de la clave de firma y la función de la librería Cryptoki

que realiza la petición al sistema operativo del DNIe, y enviar el documento al

chip para que lo firme. El sistema operativo de la tarjeta devolverá la firma en la

dirección de memoria especificada.

El estándar PKCS#11 se centra sobretodo en el desempeño de las

operaciones criptográficas y, además no proporciona un formato de

almacenamiento estándar de la información, ni tampoco contempla la

presencia de varios usuarios. Para ello se publicó el estándar PKCS#15, cuya Figura 16. PKCS#11 e Internet

idea fundamental es proveer compatibilidad entre chips, aplicaciones y drivers,

manteniendo la consistencia con anteriores estándares. Este estándar define

un sistema de ficheros genérico para dispositivos criptográficos, que será

accesible independientemente de los anteriores 3 elementos y según ciertos

privilegios de usuario. Este sistema de ficheros es relativamente pequeño y

proporciona una total independencia. Los tipos de ficheros contenidos en un

dispositivo criptográfico están bien definidos y tienen cierta jerarquía. El listado

con todos los detalles igualmente puede consultarse en la norma, pero algunos

de estos ficheros pueden ser:

• MF. Fichero Maestro o raíz

• EF. Fichero Elemental

• PrKDF. Contiene información acerca de claves privadas

• SKDF. Contiene información acerca de claves secretas (cifrado simétrico)

• CDF. Contiene información acerca de certificados

En la figura 17 se ve cómo el estándar PKCS#15 proporciona un nivel distinto