Nuevo capítulo de la serie, el quinto si cuento correctamente. En esta ocasión vamos a hablar de la autentificación por medio de certificados digitales, y por extensión a las tarjetas de acceso, la mayoría de ellas funcionan con certificados.

Hace ya un tiempo escribí en otra serie de artículos una publicación parecida. Los tiempos han cambiado y desde luego muchas cosas son ahora diferentes, pero realmente la mayoría de los conceptos e ideas que se daban entonces, siguen siendo igualmente válidas. El artículo original lo tenéis AQUÍ. Vamos a hablar de cuestiones muy similares, aunque vamos a orientarlo a otros usos y a otras necesidades, y vamos a extender algunas cuestiones que entonces se tocaron.

Hemos hablado ya de sistemas de autentificación como usuarios y contraseñas o sistemas biométricos. ¿Pero qué nos podría ofrecer los certificados digitales? No es algo que somos ni algo que sabemos, es algo que tenemos. Un certificado digital soluciona dos de los mayores problemas existentes: El primero, por basarse en criptografía asimétrica, no expone nunca hacia el exterior la parte sensible de estos, la clave privada, con lo que elimina en principio los riesgos de que un servidor remoto se vea comprometido y puedan robar nuestras credenciales. El segundo, puede asegurar la inequivocidad de una persona si se toman las medidas adecuadas, y la estructura PKI funciona correctamente.

Vamos por tanto a analizar un poco los certificados digitales, sin entrar en detalles como los que publiqué hace ya algún año, y más adelante la funcionalidad de las SmartCards, tarjetas de acceso, tarjetas inteligentes o como las queramos llamar.


El Maravilloso Invento de la criptografía asimétrica

Allá por los años 1970, dos criptógrafos británicos tomando unas ideas locas de unas décadas anteriores, crearon un sistema que ellos mismos denominaron como encriptado sin secretos. Hasta el momento todos los cifrados y/o sistemas de codificación requerían en última instancia de una contraseña, un objeto, un procedimiento… que tenía que ser secreto y compartido por las diferentes partes que quisiesen poder desencriptar un mensaje dado. Así que la importancia era enorme. Crearon en secreto lo que algunos años más tarde pasaría a ser una de las piedras más importantes en la seguridad moderna: El Algoritmo RSA, que lo trajeron los amigos del MIT Ron Rivest (R), Adi Shamir (S) y Leonard Adleman (A).

En realidad el algoritmo RSA es muy sencillo matemáticamente hablando. Se basa simplemente en la complejidad computacional de factorizar el producto de dos números primos muy grandes. Si cogemos dos números primos, por ejemplo el 5 y el 7 y los multiplicamos, tenemos 35. Si quisiésemos descomponer el 35 en sus factores tendríamos en principio ir dividiendo el 35 desde el 2 hasta el 34 (en realidad hasta la raíz de 35). Par el 35 es muy simple, la raiz cuadrada de 35 es más o menos 6, con lo que con 5-6 divisiones serían suficientes para encontrar que los factores son el 5 y el 7.

Parece un juego de niños… ¿pero que pasaría con un número algo más grande? Uno fácil, el 2504902397, es un número tan solo de 32bits. ¿Quien es capaz de calcular sus factores? La raiz cuadrada es de 50049 aproximadamente, significa que tendríamos que realizar en el peor de los casos algo más de 50 mil divisiones. Como es el producto de dos números primos, sabemos que no van a existir más de 2 factores. ¿Quien es ahora el guapo que lo hace a mano?

Un equipo moderno es capaz de realizar miles-millones de operaciones por segundo, sería capaz de factorizar dicho número casi al instante. Pero ese número es sólo de 32Bits. Las claves RSA privadas a día de hoy suelen ser de 1024/2048/4096 bits. ¿Cuanto es esto? Pues imaginaros un número con más de 300 cifras para claves de 1024bits. Dicho número es tan grande, que los supercomputadores tardarían cientos de años en ser capaces de factorizarlo. El problema matemático de la factorización es bien conocido, y radica en que no existe un modo eficiente de factorizar un número, haciendo que la capacidad de computación necesaria sea tan ingente que no sea viable su cálculo.

Los cifrados asimétricos radican en estas premisas, imposibilitan el poder obtener en un tiempo asumible la clave privada. Pero lo que les hace realmente interesante es que no funcionan como los cifrados normales. Aquí no existe una clave, existen realmente 2. Una, es la que denominamos clave Privada, otra la que llamamos clave pública. No es así, pero imaginemos que los factores son la clave privada, mientras que el número resultante es la clave pública. Como no hay forma humana de factorizar la clave pública, jamás se podrá obtener la clave privada a través de ella.

Tenemos dos claves, esto parece complicar el esquema normal de una simple contraseña, pero a diferencia de los sistemas simétricos, en los sistemas asimétricos las claves están asociadas de tal modo que lo que se encripta con una, se tiene que desencriptar con la otra. Si se encripta con la privada, solo la pública puede desencriptarlo, y si se encripta con la pública, solo la privada puede desencriptarlo. Y esto es maravilloso, porque de este modo la clave privada jamás es necesario enviarla o dársela a nadie!! Por el contrario, lo único que tenemos que hacer es enviarles la clave pública, que es más, no nos importa que conozca toda la población mundial, no compromete en nada nuestra seguridad. Obviamente la clave privada es aquí lo importante, y lo único que tenemos que mantener a buen recaudo, pero podemos tenerla nosotros guardada, no la tenemos que compartir.

Bien, puse este «sencillo juego de niños» es en el que se sustenta a día de hoy prácticamente toda la seguridad digital. Hoy lo aplicaremos a certificados digitales y tarjetas criptográficas, pero su uso es extremadamente extenso por las grandes ventajas que aporta, y por supuesto su seguridad. Es más, si alguien quiere ser tremendamente millonario, solo tiene que lograr un algoritmo de factorización que sea capaz de resolver la factorización de cualquier número en tiempo polinomial sin recurrir a algoritmos cuánticos. Si tal algoritmo existiese, se rompería de un día para otro toda la seguridad actual, y podría existir, no hay aun demostración ni nada que nos diga que no existe.


La Firma Digital

Aunque la firma digital pude aplicarse igualmente a criptografía simétrica y asimétrica, por regla general siempre está asociada a esta última, aun cuando se realiza con una clave simétrica, esta por regla general es «generada» «intercambiada» previamente por un sistema asimétrico.

La idea de la firma digital es muy simple, es disponer de un mecanismo por el cual ser capaces tanto de darle legitimidad como integridad (no se ha modificado el contenido) a cualquier archivo digital. Gracias a la criptografía asimétrica, esto puede asegurarse de un modo relativamente simple.

Hemos visto por encima como funciona la criptografía asimétrica. Siguiendo ese mismo esquema, lo que nos interesaría ahora no es cifrar el contenido, nos interesa que cualquiera pueda leerlo, pero que también, quien lo lea, tenga la seguridad de que ese mensaje procede de nosotros y que no ha sido alterado. Recordar que en España es posible firmar documentos legales de forma digital con la misma validez que una firma manuscrita, es importante por ello que podamos asegurar estas dos premisas.

El esquema a usar es similar, pero en vez de usar un algoritmo de cifrado se usa un algoritmo de Firma. En su versión más simple podría ser por ejemplo un Hash.

En este ejemplo, Alicia redacta un mensaje que quiere darle legitimidad e integridad para enviárselo a Bobo. Alicia aplica a su mensaje un algoritmo de Firma, por simplificar imaginemos que aplica un Hash MD5 a su mensaje. Los hash como sabemos son funciones criptográficas de un solo sentido, cuya salida tiene una longitud fija, usados extensamente para dar integridad, dado que si se modificase aunque fuese una coma de dicho hash, el hash recalculado sería totalmente diferente.

Alicia por tanto calcula un hash MD5 a su mensaje, y acto seguido usa su clave privada para cifrar dicho hash. El resultado lo adjunto a su mensaje original, y lo envía a Bob. Bob por su parte, en cuanto llega el mensaje puede leerlo sin problema, no está cifrado. Pero quiere saber quien envió realmente el mensaje. Bob extrae la firma encriptada del mensaje y usa la clave pública de Alicia que tiene para desencriptarla. El resultado es un Hash MD5. Ahora Bob solo tiene que calcular de forma local el Hash MD6 del mensaje que ha leído y compararlo con el Hash ya desencriptado que venía adjunto. Si ambos Hash coinciden, Bob puede estar seguro que dicho mensaje fue enviado efectivamente por Alicia (dado que solo la clave pública de Alicia puede desencriptar la firma), y que no ha sido modificado (dado que el Hash coincide).

Una firma no encripta el contenido, aunque en cierto modo encripta el contenido de la firma, pero no el contenido que se quiere firmar. En la realidad no se usan directamente los Hash para crear la firma, sino algoritmos de firma que por lo general hacen todo el proceso de golpe, usan algún tipo de función Hasheada en un entorno de clave asimétrica. Así tenemos por ejemplo el algoritmo DSA.

La firma será parte imprescindible en los certificados digitales, es lo que les otorga legitimidad e integridad. Sin una firma válida y confiable, un certificado digital no vale para nada.


Certificados Digitales

Ya hable mucho sobre ello, pero hagamos un rápido repaso. Un certificado digital es algo así como un documento digital con cierta estructura que contiene diferentes datos identificativos sobre aquello para lo que se ha emitido. Dependiendo de la finalidad tendrá unos datos u otros. Si por ejemplo es un certificado personal es normal que incluya información como nombre, apellidos, correo electrónico, dirección… si es un certificado de un servidor datos como empresa a la que pertenece, dirección Web… pero además de ello, todos incluyen una serie de directivas que especifican la finalidad y uso que se le va a dar, y más importante, una clave pública que tiene asociada. Esta clave pública puede venir de un cifrado RSA, pero no es el único que usamos, cada vez se ha extendido más el uso de sistemas asimétricos basados en curvas elípticas.

Todos usamos a diario de forma transparente certificados digitales. Cada página web que esté bajo HTTPS usa uno, por ejemplo. Pero esta serie de artículos están destinados a la autentificación, no al cifrado de datos en sí que es la razón de ser de HTTPS (aunque también autentifica).

Desde el punto de vista de la autentificación, también los usamos cada día muchos de nosotros. Algunos los usamos en forma de tarjetas de acceso para el trabajo, otros para realizar gestiones con la administración local o central del estado. Nuestro propio DNIe contiene 2 certificados digitales, uno de ellos expresamente para ser usado para tales fines.

Desde el punto de vista de la seguridad, es uno de los sistemas más fiables que existen para identificarnos, ya sean en forma de certificados digitales puros y duros o de alguna clase de sistema asimétrico. Si los protocolos están bien implementados y las claves privadas están a buen recaudo.

Un certificado digital identifica a una entidad/individuo/empresa por los datos identificativos que contiene, pero es gracias a la firma del emisor de dicho certificado quien le da genuinidad. Cualquiera puede crear un certificado digital con datos identificativos de cualquier cosa/persona… es más, es muy sencillo «duplicar» el certificado de quien sea para intentar suplantar su identidad. Por sí solo, un certificado sin firmar o sin una firma válida no pude aportar ninguna prueba de su legitimidad para terceras personas.

Llegados a este punto, hay que decir que no sólo existe un «modelo» o infraestructura PKI de certificados. Actualmente existen dos modelos de infraestructuras de clave pública de forma mayoritaria, y aunque ambos se basan exactamente en los mismos principios y su funcionamiento es similar, su principal diferencia radica en el sistema de «confiabilidad» que cada uno usa: Certificados X.509 y «Certificados» PGP

-Certificado X.509

Los certificados X.509 son a día de hoy los más extendidos y en los que se basa en esencia la seguridad día-a-día de Internet, todas las Webs HTTPs y otros.

Aquí la clave es la firma. Un certificado, para darle dicha legitimidad/integridad se debe de firmar. ¿Quien firma un certificado de este tipo? Normalmente el emisor de dicho certificado, aunque un certificado puede también autofirmarse.

Un certificado firmado y emitido por una entidad cual sea, tendrá validez para nosotros siempre que reconozcamos dicha entidad como genuina y confiable. La firma procederá de una autoridad de certificación (CA en inglés) que a su vez puede depender (dicho CA está a su vez firmado por otro CA) de la firma de otra CA, así hasta llega a lo que conocemos como autoridades de certificación raíces (Root CA). Los certificados CA raíces no están firmados por otro certificado superior, sino que están firmados por ellos mismos.

Este sistema dependerá por tanto de lo que consideramos entidades de certificación raíces legítimas, ya que serán en última instancia los emisores globales de los certificados legítimos, ya sea emitidos directamente por ellos, o emitidos por autoridades de certificación delegadas/creadas por ellos mismos. Si no confiamos en un CA determinado, todos los certificados que procedan de él, para nosotros, no nos aportarán seguridad, legitimidad y no nos aportarán integridad. Del mismo modo nos pasaría a nosotros si queremos disponer de un certificado digital personal, sólo si el CA que lo firma es identificado y confiable para aquel que use nuestro certificado, podrá fiarse que somos quien decimos que somos.

A lo largo de los años, este trabajo ha recaído en los navegadores Webs, en los gestores de correo electrónico en… los cuales han ido creando y manteniendo una pequeña base de datos de lo que consideran autoridades de certificación confiables. Si creen que un CA es confiable, añaden el certificado raíz de dicho CA a su software y lo marcan como legítimo, de modo que si interaccionamos con cualquier certificado emitido por dicho CA con dicho software, el software que usamos lo tomará por legítimo.

Estas compañías/empresas usan sistemas extremadamente rigurosos a la hora de mantener dichos certificados en sus software, exigiendo niveles concreto de seguridad, políticas, auditorías constantes… y por supuesto tienen la última palabra y decisión de añadir/eliminar cualquier certificado que así estimen.

Esto tiene un impacto enorme en el usuario, ya que de la noche a la mañana miles, decena de miles…. de certificados digitales pueden verse inmediatamente como no confiables si dichas compañías estiman que la autoridad implicada ya no es confiable. Por supuesto, siempre podremos forzar e instalar un CA que consideremos confiable en el software que sea, y así poder dar validez a los certificados que emita, pero será para nosotros, si dicho CA no está reconocido por desarrolladores de software conocidos, su ámbito será reducido, válido sólo para nosotros, y en todo caso para aquellos que igualmente los hayan autorizado

-Certificado PGP

Ya he hablado de PGP también hace años. PGP/OpenGPG funciona de un modo muy similar al que usan los certificados X.509. Se usan igualmente las claves públicas/privadas para cifrar o firmar contenido. Obviamente existen multitud de diferencias entre ambos sistemas, pero lo que realmente hace diferente al sistema es lo que llamamos «cadena de verdad», es decir, quien realmente dice que un certificado o una clave pública es legítima. Podemos falsificar los datos de un certificado sin problema, en los certificados X.509 son en última instancia autoridades de certificación reconocidas las que nos dicen que el certificado es legítimo.

En sistema PGP/OpenGPG llegó entre otras cosas para evitar la centralización de estas entidades, eliminar el poder que a día de hoy mantienen los CA, y devolverle dicho poder a los propios usuarios. En PGP/OpenGPG la figura de CA desaparece, y son los propios y diferentes usuarios los que van firmando las claves públicas de otros usuarios en los cuales confían, generando así una cadena de confianza, y como el sistema es «universal», dichos certificados/claves públicas se almacenan por mayor comodidad en repositorios abiertos que cualquiera puede consultar, e incluso firmar cualquier clave pública que confían.

Un ejemplo sencillo. Creo un «certificado» GPG con mis datos. Lo he creado yo, podría usar mis datos o los de cualquiera, pero escojo usar los míos. El certificado lo publico en un repositorio para que cualquiera pueda acceder a mi clave pública, y con ella desencriptar o verificar las firmas que yo mismo hago con mi clave privada. ¿Como puede un tercero tener la seguridad que dicha clave privada es realmente mía?

Una opción, sería indicándole personalmente cual es el ID de mi clave antes de que la descargue del repositorio, o directamente se la podría enviar. Esto es útil pero poco práctico en gran escala. Pongamos ahora que mi clave pública lleva años usándose por amigos, familiares, conocidos… incluso a lo mejor alguna persona más famosilla en el mundillo. Todos ellos confían en mi clave pública, así que algunos de ellos firman mi clave pública con su clave privada, y dicha firma es visible.

La diferencia es simple. Con los certificados X.509 existe una firma única que damos por buena porque reconocemos el CA que la realiza. En PGP damos por bueno el certificado porque posee diferentes firmas de diferentes personas/entidades que creen o saben seguro que el certificado es válido, personas/entidades que a su vez pueden ser conocidos o no.

OpenGPG es un sistema mucho más democrático y en principio con menos… «mano negra». Pero esa también es su debilidad, con la facilidad de crear certificados GPG, es simple inundar los repositorios públicos con certificados falsos, haciendo que al final tengamos que pasar tiempo intentando adivinar cual de ellos pude ser legítimo, lo cual no siempre es sencillo. No obstante, gracias al correo electrónico que generalmente «enlazamos» a ella, nos sirve como identificador si lo que queremos es precisamente enviar un correo electrónico a dicha persona y que vaya cifrado y/o firmado.

En entornos más privados, no obstante, tanto GPG como los certificados X.509 son igualmente seguros y confiables, puesto que presuponemos que las claves públicas/certificados que manejamos son legítimas.

Clave Privada

Hemos hablado mucho de los certificados digitales, pero aun nada de la Clave Privada. La clave privada no es un dato que se incorpore a un certificado digital, no así la clave pública. Un certificado digital realmente es para uso de un tercero, para que puedan verificar nuestra identidad y obtener nuestros datos. La clave privada de dicho certificado, por otro lado, es para uso exclusivo del propietario del certificado, será dicha clave la que nos permitirá realizar firmas o realiza autentificaciones en los protocolos destinados para dicho fin. Sin la clave privada en nuestros dispositivos de un certificado dado, dicho certificado tiene la misma validez que para el resto del mundo, que el resto de certificados instalados en nuestro equipo.

La clave privada tiene un papel aun más importante. En el caso de las autoridades de certificación de certificados X.509, es la que permitirá emitir certificados firmados y confiables (siempre que dicho CA lo sea). Si la clave privada de un CA confiable cayese en malas manos, se podría duplicar el certificado del CA, y con él emitir todos los los certificados digitales fraudulentos que quisiésemos, y estos serían aceptados por navegadores, gestores de correos… la clave privada para los CA es el secreto mejor guardado, es de vital importancia que esté a muy buen recaudo. Por lo general, los CA raíces no emiten certificados finales por muchas cuestiones de seguridad, delegan dicha capacidad a otros CA inferiores que en el peor de los casos pueden revocar sin provocar un «apocalipsis» a un nivel mucho más importante.

Para el usuario, la clave privada normalmente está protegida en el mismo equipo, pero lista para usar por el navegador o la aplicación que sea. A veces bajo contraseña, pero la mayoría de las veces su uso es automático. Si no poseemos una copia de seguridad de la clave o del archivo que contiene tanto el certificado como la clave, no habrá forma de recuperarla. Es más, cuando se obtienen certificados confiables por parte de un CA que sea mínimamente serio, las políticas de obtención obligan que la clave privada sea creada en el propio dispositivo/equipo que realiza la solicitud, de forma que esta NO SEA NUNCA TRANSFERIDA por Internet. Lo ideal es que la clave privada esté siempre a buen recaudo, y si puede no estar en el propio equipo del usuario, mejor.

Hay que entender algo muy importante. Un certificado personal que sea confiable/verificable a nivel estatal como pueda ser el DNIe o los certificados Ceres, con su clave privada, tiene la misma validez que nuestro DNI físico, nuestra firma… podemos acceder a prácticamente cualquier servicio!! no es algo que vamos a querer que otros tengan o puedan tener.


Uso de Certificados Digitales

Una vez más, vamos a enfocarlo dentro de la autentificación, no del cifrado de datos/conexiones seguras.

En el mundo digital se llevan usando desde hace tiempo como el método más seguro de identificación. Los Certificados digitales están dentro de «Algo que tenemos» pero no está libre de problemas. Por un lado requerimos una buena infraestructura PKI para asegurar que los certificados son de quienes dicen son, y por otro lado está la cuestión de que dicho certificado no sea robado o usado por otra persona que no sea su legítimo dueño. A fin de cuenta, al ser «Algo que tenemos» es susceptible a sus problemas inherentes, pero eso lo veremos algo más tarde.

Usar un certificado digital puede ser desde una tarea sumamente simple si el sistema está bien implementado, a ser una tortura. Dependiendo de la aplicación que usemos, el certificado se usará de un modo o de otro. También hay que tener en cuenta que cualquier certificado no vale para cualquier tarea, los certificados marcan estas limitaciones o concretaciones, indicando el uso para el que fue emitido. Un certificado que fue emitido sólo para firmar, no debería de permitir la identificación en servidores TLS/SSL, el sistema debería de rechazar tal certificado.

Obtención

¿Como se pude obtener uno? Un certificado para uso propio, el cual no necesitamos que tenga un reconocimiento público, podemos crearlo cuando queramos con la finalidad que sea y con las propiedades que más nos gusten. En realidad es un certificado como cualquier otro, la única diferencia es que no estará firmado por un CA que sea confiable, y por ende cuando lo usemos, o mejor dicho cuando lo use la otra parte, tendrá que tener como confiable nuestro CA que lo ha emitido.

Existe multitud de software que permite crear los certificados que queramos. Windows tiene un administrador de certificados, OpenGPG tiene herramientas que permiten administrarlos, crearlos, modificarlos, OpenSSL es la suite posiblemente más conocida al respecto… En lo personal, hace años que encontré una aplicación multiplataforma, de código abierto, muy visual, sencilla y cómoda para quien no le gustan líneas de comandos, la recomiendo: XCA

¿Y que pasa si queremos un certificado confiable? Aquí la cosa se complica. Si queremos un certificado confiable tenemos que acudir a una autoridad de certificación que lo sea, y solicitar un certificado para el uso concreto que deseemos. El ejemplo más simple es cuando necesitamos un certificado para un servidor Web para permitir conexiones Seguras. A día de hoy gracias a Let’s Encrypt la cosa se ha hecho más sencilla y económica.

Pero existen multitud de certificados que podríamos necesitar. Por ejemplo certificados para firma de código, certificados para la firma/cifrado de correos electrónicos… y peor aun, en el caso que nos atañe, certificados de identificación y firma real. Dado que no existe un censo universal (menos mal), los certificados personales identificativos suelen tener un ámbito local, entendiendo por local un pueblo, una ciudad o incluso un país. Eso no quiere decir que el CA emisor no pueda ser confiable a nivel mundial.

En España, la forma más sencilla de obtener un certificado digital personal es simplemente no hacer nada. Nuestro DNIe ya los tiene, solo requerimos un lector de tarjetas, el PIN del DNIe y que los certificados estén en vigor. No obstante, no soy muy fan del DNIe, lo han complicado tanto que su uso resulta muchas veces torpe, lento, propenso a problemas… es cierto que Windows dispone de un Minidriver ya listo para usarse, y librerías PKCS#11, pero su uso es muy limitado. Su uso se restringe tan solo a la autentificación y a la firma, y el CA emisor, AC RAIZ DNIE, dependiendo de de la Dirección General de la POlicia, no es confiable desde un punto de vista externo. Esto quiere decir que por ejemplo no podríamos usarlo para autentificar/firmar correo electrónico por ejemplo (tiene sentido, el DNIe no posee información de nuestro correo electrónico), y que además para poder usarlo incluso en nuestros propios sistemas, tendremos que tener añadidos manualmente los certificados raíces e intermedios de este.

Tenemos por suerte otra opción, en España tenemos otra entidad de certificación, que emite certificados más laxos, con la misma validez que el DNIe desde el punto de vista de nuestras instituciones (con lo que podemos usarlo como queramos en la administración), y que además dicho CA está reconocido a nivel internacional como confiable, lo que implica que vayamos a donde vayamos nuestro certificado será para todos los efectos legítimo. Lleva funcionando bastante antes de la aparición del DNIe: La FNMT, la fábrica nacional de moneda y timbre, a través de la iniciativa CERES.

Cualquiera en España puede solicitar su certificado CERES. Lo primero es realizar la solicitud del certificado, conocido como el CSR (Certificate Signing Request), desde la propia página. En dicho proceso se completará un formulario de solicitud y el navegador generará una clave privada, que de aceptarse, completará el certificado una vez la solicitud sea aceptada. A partir de aquí, si se ha realizado por el modo tradicional será necesario acudir a un punto de la administración para identificarnos y solicitar la aceptación de la petición, para volver al mismo navegador Web que generó el CSR y poder así instalar en dicho navegador el certificado. También es posible realizar la solicitud de forma íntegra sin movernos de casa con el DNIe.

Los CSR son las piedras vehiculares por las que el 99% de las veces obtenemos nuestros certificados de otras entidades. El usuario rellena los datos identificativos con los que desea que se conforme el certificado, partiendo de una plantilla que por lo general la suministra el CA. Por seguridad, el CA no generará nunca la clave privada del usuario, esa es personal e intransferible, con lo que se suele generar en el lado del propio usuario, adjuntando al CSR por ende la clave pública de este. Dicho CSR es enviado al CA, que de aceptarlo, conforma el certificado por completo y lo firma, devolviéndolo al usuario, que es de suponer ya poseerá su clave privada.

Veamos para acabar un par de ejemplos de uso: El primero, el uso de un certificado digital para firmar y/o cifrar un correo, con un certificado confiable para Google que será capaz de verificar la firma.

Gmail permite incluso desencriptar los correos cifrados si se posee una cuenta empresarial, y se tienen los certificados correctamente instalados. Los mensajes cifrados en última instancia se adjuntan como archivos p7m, la firma dentro de el propio mensaje cifrado. Por el contrario si sólo se firma, la inmensa mayoría de gestores de correos la parsearán correctamente y lo identificarán como firma. Una firma que no se ha podido verificar no significa que no sea confiable necesariamente, sino que el proveedor o servicio o equipo que la intenta verificar puede que no posea el certificado del CA emisor como confiable. Gmail por ejemplo toma por confiable solo un pequeño puñado de CA.

Si tenemos un certificado instalado y visitamos cualquier sitio que requiera identificación por certificado, obtenemos algo similar a lo mostrado. El servidor se identifica ante nosotros siempre, DGT en el ejemplo, y permite seleccionar un certificado instalado para permitir o denegar el acceso.

El certificado mostrado no está firmado por una entidad reconocible para la DGT, ni posee el formato requerido para que permitan mi acceso al sistema, con lo que lanzará un error. Que un certificado proceda además por un CA confiable a nivel mundial, no quiere decir que cualquier sistema vaya a permitir el acceso a él, aunque dicho usuario pertenezca al sistema. El sistema puede requerir que el emisor del certificado, además de confiable, pertenezca a una lista muy corta, o como he dicho que el certificado incluya datos identificativos concretos.


Tarjetas de Acceso: (Inteligentes/Criptográficas)

Sin entrar en el mundo cuántico u otros sistemas de codificación exóticos que serían dignos de la ciencia ficción, la criptografía asimétrica es la base en los tiempos modernos de la seguridad. Pero no es perfecta ni mucho menos. Sus imperfecciones no se basan tanto en sus fallos de diseño, sino en el factor humano.

En un principio dijimos que podríamos definir un sistema «totalmente» segundo cuando lográsemos sumar algo que somos, algo que tenemos y algo que sabemos. Los sistemas asimétricos como puedan ser los certificados digitales, sin duda alguna es algo que tenemos, pero encontramos problemas:

Es algo que tenemos, no tenemos capacidad de memorizar claves privadas de 256bits (para curvas elípticas) y mucho menos claves de 2048bits (para RSA). Algo que tenemos, por ende, es algo que puede ser sustraído, olvidado, almacenado en un lugar inseguro. Un cifrado asimétrico puede ser totalmente seguro, pero si nuestra clave es expuesta, nos va a valer para poco.

Existen otros peligros bien consabidos que harán que en el futuro estos sistemas dejen de ser seguros: Computación cuántica. Los ordenadores cuánticos están empezando a ser viables, aunque posiblemente aun tengan que pasar décadas para que sean una realidad cuantitativa. Pero ese día llegará, y cuando llegue, teóricamente, muchos de los problemas de computación en los que se basa el paradigma de la criptografía asimétrica, dejarán de ser seguros. Por ahora estamos seguros, pero llegará el día que la computación cuántica pueda resolverlo literalmente al instante.

No podemos hacer nada para evitar que dentro de X años el mundo cuántico deje inservible la seguridad actual, pero sí podemos tomar medidas para evitar los problemas de sustracciones, pérdidas, olvidos… de claves privadas: Tarjetas criptográficas o tokens de seguridad.

Cualquiera que mire su cartera, tendrá dentro de ella muy posiblemente varias de estas. Algunas usarán criptografía asimétrica, otras usarán criptografía simétrica. Si tiene un chip, muy posiblemente sea una tarjeta criptográfica. No existe un estándar único, el estándar rige la comunicación entre las tarjetas y los lectores externos, pero lo que hay dentro de ellas, depende únicamente del fabricante.

A pesar que son muy variadas, todas más o menos se rigen por el mismo principio: Ser una caja negra, almacenar algún secreto y realizar algunas operaciones dentro de la propia tarjeta. Tarjetas de crédito?? Usan criptografía asímetrica/simétrica. La mayoría de tarjetas de acceso? Criptografía asimétrica. No hay que confundir este tipo de tarjetas con las que podemos denominar como «tarjetas de memoria». La mayoría de tarjetas de transporte, de hoteles… (ya tengan chip o por NFC) no suelen ser tarjetas criptográficas, sino tarjetas de memorias que lo hacen es almacenar en sus celdas internas información estructurada concreta, como por ejemplo los viajes que nos quedan, la habitación asignada y el código de apertura… eso no quita que el acceso a dicha memoria esté protegido, pero no son tarjetas criptográficas.

Otra característica que por lo general todas llevan consigo es la existencia de un PIN de acceso. Ya hemos hablado de ello. Las tarjetas criptográficas nos permiten almacenar en ellas certificados u otras credenciales, y llevarlas con nosotros allá donde las necesitemos. Eso nos quita la limitación de memorizar claves privadas enormes, y que esta sea portable, pero sin un PIN estaríamos igualmente vendidos, cualquiera podría usarla sin nuestro consentimiento si se apoderase de ella. Con un PIN esto se elimina, haciendo que las tarjetas criptográficas, ellas solas, cumplan con «Algo que tenemos» y «Algo que sabemos», por ende, infinitamente más seguro que cualquier contraseña o sistema que hayamos podido ver hasta ahora.

Dado que son demasiado extensas, vamos a centrar la atención en las tarjetas criptográficas «genéricas», por ejemplo la tarjeta CERES, tarjetas OpenGPG y tarjetas PIV (Personal Identity Verification). Sí, la misma fábrica de moneda y timbre que emite certificados CERES pone a disposición de quien lo quiera tarjetas criptográficas para almacenar y proteger los certificados digitales.

Por último y no menos importante, aunque el formato habitual sigue siendo una «tarjeta», hay que entender que a día de hoy las tarjetas se han sustituido realmente por un concepto más genérico llamado «Token». Una tarjeta de acceso puede ser un token si dicho token tiene la funcionalidad de actuar como una tarjeta, aunque no tenga un chip de contactos expuesto y tenga que ser leída por NFC o por USB (por ejemplo)

Tarjeta CERES

No es la más bonita del baile, asumémoslo, y tampoco es la más versátil. Pero a su favor hay que decir que lleva con nosotros mucho tiempo, que es muy interesante ver como el Estado pone a disposición de cualquiera una tarjeta criptográfica que puede llegar a ser extremadamente útil, a un precio bastante adecuado. Los años no ha hecho que evoluciones demasiado, pero también esto tiene una cierta lógica… la tarjeta CERES en principio se diseñó para los certificados CERES. Eso no quiere decir ni mucho menos que no pueda albergar otro tipo de certificados (con su clave privada correspondiente), pero siempre y cuando no exceda las prestaciones de dicha tarjeta.

La tarjeta CERES es capaz de almacenar hasta 10 certificados, pero solo trabaja con RSA y con claves de hasta 2048bits. Esto implica que no se pueden almacenar certificados de clave elíptica o certificados RSA de 3072/4096bits. En cuanto criptografía simétrica es capaz sólo de usar 3DES, y para Hashing SHA1. Se queda fuera el uso de SHA256 y AES.

No obstante, no es una mala opción. Es barata, y la mayoría de certificados cumplen los requisitos. Espero que no pase demasiado para que lancen una revisión de sus tarjetas. En lo personal las llevo usando desde hace muchos años y no he tenido grandes problemas.

La inmensa mayoría de este tipo de tarjetas se basan en el estándar PKCS#11, protocolos y normas para gestionar este tipo de hardware, no solo tarjetas criptográficas ojo, a estas las llamamos tarjeta porque tienen dicho formato, pero podría ser un pendrive, un colgante…

PKCS11, aunque sea un estándar, dado que fabricante hace las tarjetas como quiere, es el propio fabricante que por lo general debe de suministrar bibliotecas/driver PKCS11 para el uso de sus tarjetas. Eso implica que para poder usar dichas tarjetas requeriremos el software necesario para… «gestionarlas», y es donde los módulos PKCS11 tienen su razón de ser. Cabe mencionar el gran trabajo de los chicos de OpenSC de crea un software multiplataforma para intentar dar cabida al máximo número de tokens/tarjetas posibles.

Dicho esto, el uso de las tarjetas CERES no es complicado. Se requiere por un lado la tarjeta, el certificado completo que queramos usar (con su clave privada), un lector de tarjetas y el software de CERES, ya sea en forma independiente de módulo PKCS11 o del propio software que la entidad distribuye. Se configura inicialmente con el PIN deseado, se importan los certificados y listo, preparada para funcionar. Por suerte además, desde hace ya tiempo, Windows incorpora un Minidriver CERES (y DNIe también), lo que hace que el propio sistema sea capaz sin módulo PKCS11 el acceder a la propia tarjeta.

Recordar que el certificado CERES es válido para la firma y cifrado de correo electrónico, un plus a tener en cuenta.

pkcs11-tool.exe --module fnmt-pkcs11.dll -M
Using slot 0 with a present token (0x10000)
Supported mechanisms:
  RSA-PKCS, keySize={1024,2048}, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,2048}, decrypt, sign, verify
  RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, generate_key_pair

pkcs11-tool.exe --module fnmt-pkcs11.dll -L
Available slots:
Slot 0 (0x10000): ACS CCID USB Reader 0
  token label        : TC-FNMT v2
  token manufacturer : TC-FNMT2
  token model        :
  token flags        : login required, rng, token initialized, PIN initialized
  hardware version   : 17.67
  firmware version   : 4.48
  serial num         : xxxxxxxxxx0000
  pin min/max        : 4/16

pkcs11-tool.exe --module fnmt-pkcs11.dll -O
Using slot 0 with a present token (0x10000)
Certificate Object; type = X.509 cert
  label:      MI NOMBRE - MI DNIE
  subject:    DN: C=ES/serialNumber=MIDNI, SN=APELLIDOS, GN=NOMBRE, CN=APELLIDOS NOMBRE - DNI
  ID:         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Certificate Object; type = X.509 cert
  label:      MI NOMBRE2 - MI DNIE2
  subject:    DN: C=ES/serialNumber=MIDNI2, SN=APELLIDOS2, GN=NOMBRE2, CN=APELLIDOS2 NOMBRE2 - DNI2
  ID:         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...

Prueba de Firma:

pkcs11-tool.exe --id IDClavePrivada -s -p PIN_TARJETA -m RSA-PKCS --module fnmt-pkcs11.dll --input-file prueba_firma.txt --output-file prueba_firmada.txt
Using slot 0 with a present token (0x10000)
Using signature algorithm RSA-PKCS
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Tarjeta OpenGPG

Al igual que los certificados X.509 se movieron rápido para poder se almacenados de forma segura en tarjetas criptográficas, lo mismo sucedió con los certificados PGP. Su funcionamiento y finalidad es muy similar, aunque responde a sus propios estándares. Dado que en OpenGPG es habitual almacenar/tener diferentes claves para diferentes usos, las tarjetas OpenGPG se hacen también eco de ello, almacenando en ellas mismas las Claves que creamos que son necesarias.

Lo que logramos es lo mismo, es llevar con nosotros nuestras claves en algo que tenemos y protegidas por algo que sabemos. Al igual que sucediese con las tarjetas criptográficas basadas en PKCS11, las tarjetas OpenGPG requieren de su propio software para ser usadas, aunque usa otros protocolos desarrollados por OpenGPG. A día de hoy el software OpenGPG como PKCS11 está sumamente extendido en todo tipo de aplicaciones.

De nuevo, funcionamiento similar, uso parecido. El uso depende al final de las aplicaciones que queremos usar, del modelo que queramos escoger o el que nos obliguen a tener

Al igual que las tarjetas convencionales, una tarjeta OpenGPG puede ser una tarjeta, o una minitarjeta, o estar contenida en un token de seguridad, o en un dispositivo tipo Pendrive…

gpg --card-status
Reader ...........: ACS CCID USB Reader 0
Application ID ...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0000
Version ..........: 2.1
Manufacturer .....: N/A
Serial number ....: XXXXXXXX
Name of cardholder: Theliel
Language prefs ...: es
Sex ..............: hombre
URL of public key : hkps://pgp.rediris.es
Login data .......: Theliel
Signature PIN ....: no forzado
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 1
Signature key ....: 219A
8551 6BC9 CC2F C1BC  DDAF C3FB 5679 4699 44F1
      created ....: 2019-04-12 22:56:00
Encryption key....: E188 61CF 30EC 58D1 1833  E7F6 A979 81A8 1F48 923D
      created ....: 2019-04-12 22:39:20
Authentication key: AF46 FFDC 780B FE4A 5510  8591 49C7 3ACB 2734 2031
      created ....: 2019-04-12 22:54:37
General key info..: sub  rsa4096/C3FB5679469944F1 2019-04-12 Theliel <spam@theliel.es>
sec   rsa4096/0DF15BC22FD01DA4  creado: 2019-04-12  caduca: 2029-04-09
ssb>  rsa4096/A97981A81F48923D  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635
ssb>  rsa4096/49C73ACB27342031  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635
ssb>  rsa4096/C3FB5679469944F1  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635

Tarjetas PIV

Aunque es un invento americano, su uso está muy extendido. Son tarjetas/token criptográficos estructurados de modos muy concretos, usados como tarjetas de identificación personal. Desde un punto de vista funcional, se podría ver como algo similar a la tarjeta Ceres, aunque las tarjetas PIV están completamente estructuradas como digo. Estas tarjeats se consideran de alta seguridad, repito que son las usadas por el gobierno americano.

Las tarjetas PIV se dividen en diferentes slots o compartimentos, en los cuales se pueden insertar diferente tipo de información, desde certificados, claves privadas a incluso datos biométricos.

De forma genérica se usan 4 slots principales: Autentificación, Firma, Cifrado y Autentificación Directa. Cada uno de ellos almacena como es natural el certificado necesario, y por supuesto, su clave privada. En teoría la idea es que cada slot almacene un certificado específico para su función específica. Así el Slot para Autentificación debería de almacenar solo un certificado para dicho propósito, y no para firmar o para cifrar. Lo mismo sucede con los slots de firma o de cifrado. Por su parte el slot de autentificación directa es algo especial, ya que el uso de dicho certificado no requeriría la introducción de un PIN, sino que la clave privada almacenada se podría usar automáticamente. La utilidad de esta es simple… ese Slot podría contener un certificado de autentificación para puertas de acceso por medio de lectores de tarjetas, en las que solo hiciese falta introducir la tarjeta y sacarla. Si cada Slot contiene un certificado diferente con propósitos concretos, dicho certificado solo valdría para esas puertas, mientras que para seguridad avanzada se podría usar el otro.

Técnicamente, las tarjetas PIV no obligan a que el certificado almacenado en cada Slot tenga un propósito u otro. Es decir, si la tarjeta PIV es nuestra y la gestionamos nosotros, podríamos tener en el Slot de Autentificación directa un certificado de firma que no requiriese contraseña, o usar en el de firma un certificado de autentificación firma y cifrado. Serían los entornos donde se desplegase la infraestructura la que estaría preparada para leer en cada caso el certificado necesario. No pensar ahora a modo individual, pensar en un agente del gobierno. Pensar que se le otorga una tarjeta PIV que contiene 4 certificados diferenciados, y el agente los usa en las instalaciones incluso sin tener ni idea bien de como funciona la tarjeta, solo que tiene un PIN, que requiere introducirla para acceder a las instalaciones o introducirla cuando redacta un correo para que se cifre o….

Además de los 4 slots principales, las tarjetas PIV permiten almacenar datos biométricos, o incluso más de una decena slots para certificados u claves «viejos/revocados/retirados», que podrían ser necesarios para por ejemplo desencriptar o validar firmas de correos/documentos más viejos.

Todo esto hace que las tarjetas PIV puedan usarse de mil formas diferentes. Por ejemplo, con alguna modificación se podría usar como una «tarjeta CERES» en la que se podrían almacenar algo más de 20 certificados diferentes, o almacenar/usar certificados con claves más complejas si nuestra tarjeta PIV lo soporta.

De forma similar al resto de tarjetas, permiten por regla general su uso/gestión por PKCS11, aunque PIV usa en algunos procedimientos diferentes, y el fabricante de la tarjeta PIV así mismo debería de suministrar las herramientas necesarias para su correcto funcionamiento. Por supuesto, como otras tarjetas/token requiere de un PIN para la mayoría de procedimientos. Veamos mi tarjeta PIV de ejemplo leída por NFC. En mi caso no tengo actualmente ningún certificado en los slots principales, actualmente uso los slots «retirados» para uso diario. Como la infraestructura donde los uso no obliga a leerlos desde un slot concreto, los puedo usar como certificados/claves genéricas sin mayor problema.

Datos básicos:

pkcs15-tool.exe --list-info
Using reader with a card: ACS ACR122 0
PKCS#15 Card [Theliel]:
        Version        : 0
        Serial number  : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        Manufacturer ID: piv_II
        Flags          :

pkcs11-tool.exe -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,384}, hw, sign, other flags=0x1800000
  ECDH1-COFACTOR-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  ECDH1-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  RSA-X-509, keySize={1024,3072}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,3072}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,3072}, sign, verify
  MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
  RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify

En comparación con la tarjeta CERES, mi tarjeta PIV es capaz de realizar un inmenso número de operaciones adicionales, sin contar que es capaz de almacenar claves RSA de hasta 3072bits, claves elípticas de 256 y 384bits, derivaciones de claves… e incluso realizar Hash a datos de entrada:

pkcs11-tool.exe -m SHA-1 -h --input-file prueba_firma.txt
Using slot 0 with a present token (0x0)
Using digest algorithm SHA-1
¶+»úàs0¤YDd?hüçö

pkcs11-tool.exe -v -m SHA256 -h --input-file prueba_firma.txt
Using slot 0 with a present token (0x0)
Using digest algorithm SHA256
■Â¥Åä<6°»┐2yêoäSòv▄ïÄÉJ:ÔÁ║[╩

Se imprime «basura» por la codificación ASCII de la salida hexadecimal.

Podríamos realizar una lectura completa de la estructura de la tarjeta PIV también, gracias a las utilidades de OpenSC:

pkcs15-tool.exe -C -s
Using reader with a card: ACS ACR122 0
Card has 32 Data object(s).
        Path:db00          2.16.840.1.101.3.7.1.219.0  Size:   53  Card Capability Container
        Path:3000          2.16.840.1.101.3.7.2.48.0  Size:   61  Card Holder Unique Identifier
        Path:3010          2.16.840.1.101.3.7.2.48.2Data object read failed: File not found
        Path:0101          2.16.840.1.101.3.7.2.1.1Data object read failed: File not found
        Path:6010          2.16.840.1.101.3.7.2.96.16  AuthID:01   Cardholder Fingerprints
        Path:3001          2.16.840.1.101.3.7.2.48.1  AuthID:01   Printed Information
        Path:6030          2.16.840.1.101.3.7.2.96.48  AuthID:01   Cardholder Facial Image
        Path:0100          2.16.840.1.101.3.7.2.1.0Data object read failed: File not found
        Path:0102          2.16.840.1.101.3.7.2.1.2Data object read failed: File not found
        Path:0500          2.16.840.1.101.3.7.2.5.0Data object read failed: File not found
        Path:9000          2.16.840.1.101.3.7.2.144.0Data object read failed: File not found
        Path:6050          2.16.840.1.101.3.7.2.96.80  Size:   20  Discovery Object
        Path:6060          2.16.840.1.101.3.7.2.96.96  Size:   10  Key History Object
        Path:1015          2.16.840.1.101.3.7.2.16.21Data object read failed: File not found
        Path:1001          2.16.840.1.101.3.7.2.16.1  Size:  936  Retired X.509 Certificate for Key Management 1
        Path:1002          2.16.840.1.101.3.7.2.16.2  Size: 1703  Retired X.509 Certificate for Key Management 2
        Path:1003          2.16.840.1.101.3.7.2.16.3  Size: 1711  Retired X.509 Certificate for Key Management 3
        Path:1004          2.16.840.1.101.3.7.2.16.4  Size: 1914  Retired X.509 Certificate for Key Management 4
        Path:1005          2.16.840.1.101.3.7.2.16.5  Size: 1717  Retired X.509 Certificate for Key Management 5
        Path:1006          2.16.840.1.101.3.7.2.16.6Data object read failed: File not found
        Path:1007          2.16.840.1.101.3.7.2.16.7Data object read failed: File not found
        Path:1008          2.16.840.1.101.3.7.2.16.8Data object read failed: File not found
        Path:1009          2.16.840.1.101.3.7.2.16.9Data object read failed: File not found
        Path:100a          2.16.840.1.101.3.7.2.16.10Data object read failed: File not found
        Path:100b          2.16.840.1.101.3.7.2.16.11Data object read failed: File not found
        Path:100c          2.16.840.1.101.3.7.2.16.12Data object read failed: File not found
        Path:100d          2.16.840.1.101.3.7.2.16.13Data object read failed: File not found
        Path:100e          2.16.840.1.101.3.7.2.16.14Data object read failed: File not found
        Path:100f          2.16.840.1.101.3.7.2.16.15Data object read failed: File not found
        Path:1010          2.16.840.1.101.3.7.2.16.16Data object read failed: File not found
        Path:1011          2.16.840.1.101.3.7.2.16.17Data object read failed: File not found
        Path:1012          2.16.840.1.101.3.7.2.16.18Data object read failed: File not found

Conclusiones Finales

La criptografía asimétrica/simétrica y por extensión los certificados digitales, son a día de hoy posiblemente los fundamentos más sólidos a nivel práctico que disponemos para nuestra seguridad. Gracias a los principios RSA y más tarde a los algoritmos de curvas elípticas, podemos crear sistemas e infraestructuras realmente seguras.

Pero todo tiene su peligro. Recordar que un certificado digital puede poseer un valor increíblemente alto si tenemos en cuenta que, algunos de ellos, pueden usarse a todos los efectos de forma legal. Llevo años combatiendo contra gestorías, e informando a amigos/familiares/conocidos de los peligros que acarrear ceder nuestro certificado a ellos. Un gran número de personas, y cada vez más, delegan en gestorías la administración de todo sus papeleos, desde cualquier asunto fiscal (IRPF, IVA…), alquileres, facturaciones… esto me parece perfecto. El problema aparece cuando la INMENSA MAYORÍA de las gestoras solicitan al cliente que les proporcione su certificado digital personal para poder obrar en su nombre.

Esto es una barbaridad, es ilegal, es extremadamente peligroso. Ceder nuestro certificado a un tercero, además repito de ser ilegal, implica que ese tercero podría firmar cualquier documento con plena capacidad legal, podría acceder prácticamente a todos nuestros datos: Médicos, fiscales, financieros… y en la mayoría de los casos también operar sobre ellos. La excusa que las gestoras esgriman es que así el cliente no tiene que ir a las administraciones o preocuparse de presentar nada. En realidad esto no es cierto tampoco, porque la mayoría de los trámites se puede autorizar a un gestor para que nos los presenten, e irán presentados bajo SU NOMBRE y responsabilidad, aunque a nuestro nombre, y más importante, sin acceso a nuestro certificado digital.

Cada vez que explico esto a algún amigo termina con las manos en la cabeza. Sí, se ha entendido bien, cuando le damos nuestro certificado al gestor, le estamos entregando literalmente nuestra vida. El certificado digital es algo en extremo delicado que jamás se debería de ceder a nadie, podría ser cómodo en un momento dado dejarlo a un tercero, pero aun cuando dicho tercero fuese de plena y total confianza, no es algo que no haya que pensar y mucho. Y a un tercero que nos cobra por ello… en la vida.

Y la cosa puede ponerse peor… nada ni nadie nos asegura que aun cuando dicho gestor fuese honrado, su equipo fuese comprometido por una cuarta persona, ya fuese alguien de su entorno, ya fuese un hacker, ya fuese un ladrón que roba su equipo… JAMÁS, NUNCA, deis vuestro certificado a nadie, y menos a un gestor. Y quien ya haya caído en ello, es muy simple: Primero notificar al gestor que a partir de ahora todos los trámite los presentará a su nombre y en todo caso lo autorizaremos, y si tampoco es posible, presentaremos nosotros mismos los documentos. Y en segundo lugar, aunque nos asegure que ha borrado el certificado tampoco podemos creerlo, deberemos realizar una nueva solicitud, ya que al realizarla automáticamente se revocará el certificado anterior.

En otro orden de cosas, el uso de tarjetas criptográficas es igualmente recomendable para aquellos que hacen un uso habitual de sus certificados. Instalarlos en los equipos es peligroso por las razones ya expuestas. A día de hoy hay tarjetas criptográficas de todo tipo. La tarjeta CERES solo es una de muchas. Un lector de tarjetas parece algo incómodo para trabajar con los certificados, pero pensad que tenemos tarjetas/tokens que pueden conectarse por USB o por NFC incluso, la dejamos caer sobre el lector NFC, trabajamos normalmente (introducimos el PIN si se requiere) y la cogemos al acabar. Fácil, cómodo y seguro.

¿Podemos mejorar la seguridad aun más? Sí, aun podemos mejorarla algo más como veremos en capítulos siguientes. Con tarjetas/tokens criptográficos logramos usar «Algo que tenemos» y «Algo que sabemos», pero pronto podremos también usar «Algo que somos», y el uso de sistemas dobles. Al final se trata de lo mismo, poner capas que puedan ser en la medida de lo posible lo más transparente posible para el usuario, y que solucione las deficiencias de otros sistemas. El sistema perfecto no existe ni existirá, pero podemos acercarnos mucho a él.