Manual de OpenSC

Las siguientes personas an aportado ideas, apoyo y/o información para el desarrollo de OpenSC

OpenSC no ha inventado la rueda ni escrito el código desde cero. Se ha usado código de otros proyectos, principalmente para desarrollar el interfaz con éstos. Los autores originales son:

La biblioteca básica de OpenSC es libopensc. Ofrece tanto funcionalidades básicas para la comunicación con las tarjetas inteligentes, como avanzadas, (eg. generar claves RSA en una tarjeta)

Para ello, libopensc está estructurado en diversas capas, a su vez implementadas mediante uno o más drivers. Estas capas son:

PC/SC Lite es una aplicación middleware que sirve para interactuar, por un lado con los drivers para lectores de tarjetas, y por otro con las aplicaciones que las manejan. OpenSC puede usar PC/SC Lite mediante el modulo lector pcsc, aunque soporta otras alternativas

PC/SC es un API estandard entre aplicaciones, como gestor de recursos para lectores de tarjetas inteligentes. Es muy popular en el entorno operativo Windows. La documentación está disponible en: http://www.pcscworkgroup.com/.

PC/SC Lite es la implementación del estandard PCSC para sistemas Linux, Unix, Windows y MacOS X, realizada por David Corcoran < corcoran@linuxnet.com>. La aplicación está disponible como software libre y gratuíto. Para descargar esta aplicación, refierase a la página web del Movimiento para el Uso de smart cards en Entornos Linux ( M.U.S.C.L.E ) http://www.linuxnet.com/.

Para instalar el soporte de OpenSC para pcsc-lite, es necesario instalar PCSCLite primero, y seguidamente configurar OpenSC especificando la ubicación de la instalación de PCSC

$ cd opensc-<version>
$ ./configure --with-pcsclite=/path/to/pcsclite
                                

OpenCT es una nueva aplicación para manejo de tarjetas inteligentes, lectores y terminales de acceso. OpenCT ha sido escrito desde cero , constituyendo un entorno muy ligero, e incluyendo todos los drivers. Está dispobible para sistemas Linux, pero si se desea su uso en otros entornos Unix o BSD, por favor consulte en la lista de correo de opensc-devel

OpenCT es software libre. El código fuente está disponible de manera gratuita. OpenCT es desarrollado conjuntamente con OpenSC y se recomienda su uso preferente para entornos Linux. OpenCT está disponible en la página web de OpenSC http://www.opensc.org/. Para dudas y consultas acudan a la lista de correo < opensc-devel@opensc.org>

Para compilar OpenSC con soporte OpenCT, es necesario tener instalado éste primero. La documentación de OpenCT está incluída en el código fuente, así como disponible en línea a través del enlace: http://www.opensc.org/files/doc/openct.html. Una vez instalado OpenCT, recompile OpenSC indicando la ubicación de las bibliotecas OpenCT

$ cd opensc-<version>
$ ./configure --with-openct=/path/to/openct
                                

CT-API es un estandard para manejadores de tarjetas inteligentes. Fué desarrollado en la década de los 80, para aplicaciones MS-Dos, y quizás no sea muy conocido en los ambientes multi-usuario y multi-tarea de la actualidad. Sin embargo, CT-API está muy extendido y muchos lectores proveen soporte para este estándard incluso bajo Linux.

OpenSC puede usar drivers CT-API directamente. No obstante su uso se reserva para aplicaciones de depuración y no se recomienda en instalaciones multi-usuario o con múltiples aplicaciones que usen el lector

El soporte CT-API en OpenSC no necesita párametros especiales a la hora de recompilar. Léase el fichero de configuración opensc.confpara saber como configurar el driver CT-API bajo OpenSC

Lea el fichero INSTALLpara ver las instrucciones de compilación. Si se está partiendo de una versión descargada del CVS, necesitará ejecutar previamente el script 'bootstrap' antes de ejecutar 'configure'. Del mismo modo, deberá tener versiones actualizadas de Autoconf, Automake, y Libtool

Ejecute "nmake -f makefile.mak" en el directorio opensc para compilar

Además de nmake, deberá tener perl y flex instalados para poder realizar la compilación

El fichero Makefile.mak no incorpora mecanismos para "make install", por lo que deberá realizar la instalación de manera manual

Esta opción añade funcionalidad extra (por ejemplo PKCS#11 hash y mecanismos de firmas pkcs#11 adicionales

Para no necesitar las librerías dinámicas: compilar OpenSSL estáticamente y substituír los ficheros gdi32.dll y libeay32.dll por los ficheros gdi32.lib t libeay32.lib, respectivamente, en los tres ficheros Makefile.mak anteriormente indicados

Actualmente, solo han sido portados a Windows: libopensc.dll, pkcs11-spy.dll, opensc-pkcs11.dll y la mayor parte de los ejecutables del directorio \tools y \tests. Estas bibliotecas han sido testeadas en Win98, WinNT, Win2000 y WinXP

Netscape parece mostrar más información acerca de sus módulos de seguridad que Mozilla. No obstante el soporte no ha sido testeado

Notas sobre threads en Linux y MacOS X: Netscape y Mozilla usan el parámetro CKF_OS_LOCKING_OK en la función C_Initialize(). Como resultado, el thread del navegador no termina cuando se cierra éste, y debe ser abortado manualmente. Esto es debido a que el navegador no invoca C_Finalize, que liberaría los locks, tal y como especifica el estandard

Por consiguiente OpenSC no utiliza los mecanismos de bloqueos de threads, incluso aunque sean solicitados. Esto parece funcionar en Mozilla, pero puede causar problemas en aplicaciones que utilicen múltiples hilos que accedan simultáneamente a la librería pkcs11

Si se desea utilizar los mecanismos de threading, recompilar con la opción -DPKCS11_THREAD_LOCKING. En Windows no se usan hilos, y por consiguiente este problema no existe, por lo que se usa el mecanismo de bloqueos del sistema

Para que el módulo funcione adecuadamente, es necesario activarlo: En el Menú "Cryptographic Modules" Seleccionar la tarjeta OpenSC, y pulsando en "Config", activar los botones "Enable this token" y "Publicly readable Certs"

Con esto se garantiza que Netscape utilizará la tarjeta cuando intente mostrar mensajes encriptados en el Netscape Messenger. Del mismo modo habilitar "Publicly readable Certs" evitará que Netscape nos pida el PIN cada vez que se acceda a una página que requiera autenticación del Cliente

El boton "RSA" NO DEBE ser activado. En caso contrario, Netscape intentará usar la tarjeta cada vez que vaya a generar claves públicas, y fallará (no todas las tarjetas soportan esta funcionalidad)

FIXME: Especificar versión de Netscape a la que se aplican estas instrucciones

OpenSSL es una potente utilidad que implementa los protocolos SSL, así como una biblioteca criptográfica de uso general. Entre sus características, se incluye la posibilidad de incluir "al vuelo" capacidades criptográficas adicionales (engines), como pueda ser la adicción de hardware criptográfico

OpenSC incluye dos "engines" para OpenSSL. Esto permite el uso de OpenSSL y sus diversas utilidades asociadas en combinación con las capacidades criptográficas de las tarjetas inteligentes

Para utilizar estas habilidades, es preciso cargar el "engine" dentro de OpenSSL, y luego utilizar de la manera habitual las aplicaciones. He aquí un ejemplo de utilización desde el comando openssl :

Ejemplo de cómo cargar el "engine" OpenSC

aj@simulacron:~$ openssl
OpenSSL> engine dynamic -pre
SO_PATH:/home/aj/opensc/lib/opensc/engine_opensc.so -pre ID:opensc
-pre LIST_ADD:1 -pre LOAD
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/home/aj/opensc/lib/opensc/engine_opensc.so
[Success]: ID:opensc
[Success]: LIST_ADD:1
[Success]: LOAD
Loaded: (opensc) opensc engine
OpenSSL> 
                                

Un comando OpenSSL típico puede ser la recuperación de un certificado: req -engine opensc -new -key key -keyform engine -out req.pem -text. Consulte la documentación de OpenSSL para detalles adicionales

- key Especifica el identificador de una clave en Hexadecimal. - por ejemplo "45" corresponde al la clave con ID="0x45"

OpenSC incluye dos "engines" para OpenSSL: engine_opensc.soy engine_pkcs11.so.

El módulo engine_opensc.so sólo funciona bajo OpenSC, y no funcionará cuando haya múltiples aplicaciones accediendo concurrentemente a la tarjeta, o existan en la tarjeta varios certificados. Pero en los casos simples: (una aplicación, una tarjeta, un certificado) es el módulo indicado por su simplicidad

El módulo engine_pkcs11.so es mucho mas genérico y flexible. funcionará en todos los casos, incluídos aquellos en que existan múltiples tarjetas, claves, certificados, con aplicaciones concurrentes. Además está basado en el estandard PKCS#11, por lo que no solo puede usar la biblioteca OpenSC (como hace por defecto), sino cualquier otra implementación de PKCS#11

Para cargar dicho "engine", ejecutar el comando:

aj@simulacron:~$ openssl
OpenSSL> engine dynamic -pre
SO_PATH:/home/aj/opensc/lib/opensc/engine_pkcs11.so -pre ID:pkcs11
-pre LIST_ADD:1 -pre LOAD -pre
MODULE_PATH:/home/aj/opensc/lib/pkcs11/opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/home/aj/opensc/lib/opensc/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:/home/aj/opensc/pkcs11/opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
OpenSSL> 
                                

Y luego proceda normalmente

Un comando típico OpenSSL puede ser la recuperación de un certificado: req -engine pkcs11 -new -key key -keyform engine -out req.pem -text. Consulte la documentación de OpenSSL para más detalles

key tiene el formato [slot_<slotNr>][-][id_<keyID>], donde

Ejemplos:

En sistemas Windows, solo está portado el módulo pkcs11. Al cargar dicho engine, utilize el nombre "engine_pkcs11" en lugar de "engine_pkcs11.so"

La versión 3.6.1p2 de OpenSSH necesita un parche para compilar con soporte OpenSC. Encontrará dicho parche en el directorio src/openssh

Para compilar OpenSSH, ejecute el comando "configure" de la siguiente manera: ./configure --with-opensc=/path/to/opensc

Necesitará tener certificados en su tarjeta: un par de claves no es suficiente. Descargue el certificado en formato OpenSSH con el comando: ssh-keygen -D reader [ : certificate ID ] > file

Reemplace reader con el número del lector que desea ( por defecto 0). El comando opensc-tool -lle proporcionará la lista de lectores disponibles. Añada el identificador del certificado en caso necesario ( por defecto ID=45 ). El comando pkcs11-tool -Ole indica la lista de certificados y sus identificadores

Una vez realizada la extracción del certificado, copielo al servidor e incluyalo en el fichero ~/.ssh/authorized_keystal y como se hace habitualmente

Para usar una tarjeta con OpenSSH, ejecute: ssh -I reader [ : certificate ID ]

Del mismo modo se puede usar la utilidad ssh-agent con OpenSC. para ello use el comando: ssh-add -s reader

El sistema PAM (Pluggable authentication modules) es el mecanismo por el que Linux, y otros sistemas Unix utilizan para los procedimientos de autentificación de usuarios. OpenSC incluye un módulo que permite añadir la autentificación mediante tarjetas inteligentes: "pam_opensc"

pam_opensc identifica las siguientes opciones:

Opciones Genéricas:

PKCS #11es el API estandard para el acceso a dispositivos criptográficos, tales como tarjetas inteligentes, modulos de seguridad hardware, etc... El API está definido mediante funciones como: C_GetSlotList(), C_OpenSession(), C_FindObjects(), C_Login(), C_Sign(), C_GenerateKeyPair(), ...

Algo de terminología básica de PKCS #11

PKCS#11 define que cada token tiene asociado dos PIN's (Personal Identification Number): el del usuario (User PIN) y el del administrador (Security Officer PIN). A pesar de ello muchas tarjetas soportan más de un PIN de usuario (eg PIN1 y PIN2 en tarjetas de telefonos móviles). La manera de resolver este problema es la de proveer de múltiples "slots virtuales" ( definidos en el apéndice D del estándard PKCS #11. Por ello cada lector simula uno o varios slots. Si se inserta una tarjeta, aparecerán tantos slots como PIN's disponibles. En cada slot aparecerá un token que contiene los objetos asociados a cada PIN. Es el equivalente a disponer de "varias tarjetas en una", cada una con su PIN

OpenSC puede trabajar simultáneamente con varias tarjetas, y no sabe a priori cuantos slots se crean por cada tarjeta. Por ello se crean por defecto 4 slots virtuales. Se puede cambiar dicho número en el parámetro "num_slots" del fichero /etc/opensc.conf

Para numerar los slots, OpenSC adopta el siguiente convenio: por cada PIN, sus claves, y certificados, se le asigna un slot virtual. Si hay más objetos son asignados al siguiente slot libre. Si quedan slots libres se crean en ellos slots adicionales marcados como vacíos donde pueden ser insertados tanto un nuevo PIN como sus objetos asociados. Si no se desea añadir nuevos objetos, la directiva "hide_empty_tokens" del fichero de configuración esconde los slots libres

Ejemplo. Sea un sistema con dos lectores. Sea una tarjeta con dos PINs. Cada PIN proteje una clave privada y un certificado. Además existen tres certificados raíz no asociados a dicho PIN. Si tenemos la configuracion num_slots=4 , hide_empty_tokens=false, e insertamos la tarjeta en el segundo lector, obtendremos lo siguiente:

Si se hubiera especificado "hide_empty_tokens=false", el slot 7 no contendría ningún token

Nota: si en el anterior ejemplo, la cadena de certificados contuviera algún certificado común, dicho certificado aparecería duplicado en los slots 4 y 5 (lo que causaría problemas si se intentara borrar. Este problema no está aún resuelto en OpenSC )

Otra cosa a recordar: OpenSC tiene prefijado el número máximo de slots virtuales a 8. por ello, si se selecciona "num_slots = 4" solo se podrán manejar dos lectores. O, por ejemplo, si se seleciona "num_slots = 3", los dos primeros lectores verán 3 slots, mientras que el tercero verá solo 2

OpenSC permite especificar el PIN y las claves como argumentos en la línea de comandos. Esta operación sólo es recomendable en casos de test o cuando se es el único usuario del sistema. En sistemas multiusuario, los otros usuarios pueden ejecutar comandos como "ps" o "top", y probablemente puedan ver los argumentos asociados al comando en ejecución. Del mismo modo, dichos comandos suelen quedar registrados en los archivos "history"

La solución pasa por usar un script, o en el caso del comando pkcs15-init, especificar los PINS y claves en un fichero, e indicar el nombre de éste con la opción "--options-file"

Pueden aparecer otros problemas en entornos multiusuario donde más de un usuario tenga acceso al lector:

Una solución puede ser crear un usuario/grupo "scard/scard" bajo el que se ejecuta el servidor pcscd y al que solo se puede acceder desde xdm. No es una solución perfecta, pero funciona en estaciones que solo disponen de un lector

En el caso de que las aplicaciones utilicen la biblioteca PKCS#11, el sistema garantiza acceso exclusivo una vez que se proporciona el PIN. Esta es la configuración por defecto. Si se desea que múltiples aplicaciones puedan trabajar a la vez con dicha biblioteca, es necesario especificar la opción "lock_login = false" en el fichero /etc/opensc.conf; pero en este caso la tarjeta quedará accesible por terceros

Las otras aplicaciones OpenSC no garantizan el acceso exclusivo

Muchas tarjetas incorporan una clave "de fábrica", que se usa para crear el sistema de ficheros inicial en la tarjeta. Una vez creado el sistema de ficheros se protege mediante PIN, con lo que dicha clave ya no es válida

Esto significa que los datos del usuario no son accesibles para nadie que posea la clave de fábrica, en el sentido de que no pueden ser accedidos o usados

No obstante, con dicha clave, otro usuario podría destruír el sistema de ficheros, borrando todo su contenido

En si mismo esto es positivo: en el caso de pérdida de tarjeta, los datos solo pueden ser destruídos, no leídos. Pero puede darse otro problema: los certificados pueden ser substituídos por otros falsos. Por consiguiente: sea muy cuidadoso cuando utilice las tarjetas en entornos hostiles, y proteja SIEMPRE los certificados con PIN

Aunque por sí mismos, los ficheros opensc.conf y xxx.profile no contienen información sensible, es muy importante garantizar que no son modificados

Algunos ejemplos de lo que se puede hacer modificando dichos ficheros:

Por defecto, el fichero de configuración y los ficheros profiles deberían ser propiedad del administrador, con permisos 644. Del mismo modo, el caché de certificados debería residir en el directorio $HOME del usuario con permisos 600. No obstante, si el directorio en el que se ejecutan tiene ficheros profile, estos toman precedencia sobre los del sistema

De lo anterior se deduce que no se puede proteger la tarjeta ante alguien que tenga permisos de root, que pueda cambiar los profiles, o que pueda modificar los ejecutables o supervisar las comunicaciones con las tarjetas

Toda la funcionalidad de OpenSC debería ser portada a Windows. Del mismo modo se debería implementar una biblioteca para que OpenSC actue como CryptoAPI Provider, implementar mecanismos de autenticación (login), y controles ActiveX para que Internet Explorer pueda realizar signados

Especifique el directorio de instalación para el módulo al ejecutar "configure": $ configure --with-plugin-dir= <directory>

Directorios típicos son /usr/lib/mozilla/plugins y /usr/lib/netscape/plugins.

Consulte el fichero INSTALL para instrucciones adicionales

Nota: este módulo necesita abrir ventanas de diálogo para introducir el PIN. Dichas ventanas se generan con la biblioteca libassuan, del proyecto Ägypten. Si no las tiene instaladas, deberá hacerlo antes de proceder a compilar OpenSC