Un reportaje publicado hoy por el diario La Nación denuncia que, en nuestro país, la "Firma digital solo funciona con el sistema Windows". Existe preocupación de que ello "roce con el principio de neutralidad tecnológica que apoya el Estado costarricense, el cual indica, en pocas palabras, que no se debe ni beneficiar ni perjudicar ninguna tecnología".Ante esto, es oportuno reiterar que la firma digital es un estándar abierto internacional, tecnológicamente neutro, que por ende no está ligado a ninguna clase de plataforma comercial de hardware o de software. En Costa Rica, el Sistema Nacional de Certificación Digital -a partir del cual se define el empleo de la firma digital en nuestro medio- se construyó a partir de estándares ISO que garantizan la neutralidad tecnológica.
Lo que ocurre es que, para usar la firma digital con una computadora en particular, el usuario requiere el dispositivo físico (y su correspondiente software) apropiado para su equipo. En estos momentos y por una decisión puramente estratégica, los primeros dispositivos que se ha introducido al mercado son los que corresponden al ambiente PC y al sistema operativo Windows. Esto es razonable porque, hasta ahora -nos guste o no- esa es la plataforma más difundida en el país, de modo que es la vía obvia para tratar de hacer llegar esta nueva tecnología a la mayor cantidad de usuarios posible. Pero de ninguna manera significa que la firma digital solo funcione con Windows, como alguien podría concluir equivocadamente. De hecho, si una persona decidiera traer del exterior (o comprar por Internet) un lector apropiado para su sistema Mac o Linux, no veo ninguna razón por la cual no podría solicitar su tarjeta de certificado digital y utilizarla sin problema alguno.
Se trata, pues, de una momentánea escasez en el país de dispositivos lectores para plataformas alternativas a Windows. No de alguna clase de deficiencia del sistema de firma digital en sí, tal y como lo hemos introducido en Costa Rica.
-----
Notas posteriores:
1) 1/2/2011: Luego de publicado este comentario, recibí un mensaje de Carmen Hernández, de la División de Servicios Tecnológicos del Banco Central de Costa Rica, en el cual hace la siguiente importante aclaración:
"Como encargada del proceso de homologación de dispositivos criptográficos de CA del SINPE, le comento que uno de los requerimientos que pedimos fue que los dispositivos tuvieran drivers para sistemas operativos Windows, Mac y Linux. Específicamente, en el documento de homologación les indicamos a los proveedores lo siguiente:2) 2/2/2011: "Central Directo soporta firma digital en sistema Mac", en La Nación de hoy.
'... los dispositivos criptográficos que participen de este proceso de homologación ofrezcan drivers tanto para plataformas de 32 como de 64 bits para los siguientes sistemas operativos:Realmente, en este momento los dispositivos que están en el mercado sí funcionan en los sistemas operativos en cuestión. Es lamentable que, porque algunos desarrolladores no hayan podido desarrollar sistemas que usan certificados digitales en Mac o Linux, ahora se diga que Firma Digital no respeta la neutralidad tecnológica. Vea Central Directo hay mucha gente que lo usa en Mac."
- Windows XP,
- Windows Vista
- Windows 7,
- Mac OS-X, 10.5 y superiores
- Linux (al menos una versión descargable en forma gratuita desde Internet).'
19 comentarios:
Sí, y habiendo tenido la opción de seleccionar otro aparato que sí tenga soporte (nótese que no estoy diciendo "más soporte"), la organización que estás defendiendo optó, a sabiendas, por un dispositivo que en ese momento no funcionaba con sistemas operativos que no fuesen de Microsoft.
*Eso* es impresentable, independientemente de cual sea la situación un par de años después.
Marcelo, creo que la nota posterior que añadí al comentario clarifica la situación.
Christian,
"De hecho, si una persona decidiera traer del exterior (o comprar por Internet) un lector apropiado para su sistema Mac o Linux, no veo ninguna razón por la cual no podría solicitar su tarjeta de certificado digital y utilizarla sin problema alguno."
Eso es falso. Resulta que el lector de tarjetas smartcard que se esta distribuyendo si funciona en Mac/Linux (hasta tiene driver open source). El problema es que la smartcard criptografica que se esta usando para implementar la administración de las llaves es de driver cerrado. Dicho de otra forma, no hay driver para la tarjeta (ni especificación para crearlo, hasta donde he podido averiguar).
Por otra parte, el proveedor cumplió con las expectativas de que el dispositivo criptografico tenga un driver para Linux/Mac, dado que están distribuyendo una biblioteca binaria de PKCS#11. Sin embargo dicho driver no es suficiente para que el smartcard en cuestión pueda ser usado por aplicaciones nativas de Mac, dado que la interface de software nativa para criptografia en Mac es tokend, no PKCS#11. Por otra parte el driver de Windows si es nativo (CryptoApi). Entonces a pesar que en el papel se cumplió con el requerimiento de un driver, en la práctica el mismo es casi que inútil. Para que quiero una firma que puede firmar correos si ningún software de correo para la plataforma puede usar el driver?
El caso de Linux es más complejo, por que en Linux no hay una interfaz de software standard para smartcards, por lo cual se podría decir que la biblioteca PCKS#11 es suficiente (aunque sería bueno un driver open source).
Si bien es cierto que la firma digital esta basada en estándares ISO, la implementación actual no permite abstraerse al nivel del estándar: no se permite extraer la llave pública y privada del dispositivo de token que está siendo distribuido para usarlo externamente. Por lo cual la carta de que la implementación actual es neutra tecnológicamente es una falacia.
Dompe, gracias por el comentario. Voy a transmitirlo a los técnicos del SNCD para ver si tienen una respuesta satisfactoria.
Don Christian y demás lectores:
Yo fácilmente encontré el código fuente del fabricante del lector de tarjetas. Con él pude compilar exitosamente un instalador para distribuciones basadas en Debian (como Ubuntu, Linux Mint y otras) tanto para 32 como 64 bits.
Sin embargo, al hacer pruebas de firma en el sitio del SNCD, éstas no fueron exitosas. Gracias a lo que menciona Dompe, ahora veo que lo que puede estar haciendo falta es el driver para el smartcard propiamente. Empezaré a investigar al respecto.
Asimismo, creo que por un asunto de evitar exclusiones, los drivers para Linux (aunque sea como código fuente del fabricante o elementos ya compilados, lo cual es facil y rápido de hacer) deberían incluirse en los CDs que provee el SNCD. Estos drivers son los mismos del fabricante y ocupan muy pero muy poco espacio. Sería una gran ventaja y una consideración para los usuarios, y administradores servidores Linux en el país.
Methos,
Si, como yo había mencionado existen drivers open source para el lector de tarjetas (de hecho el driver viene incluido nativamente en Mac, y en open-sc usado comúnmente en Linux). Para la tarjeta no vas a encontrar nada, y la única forma de hacerla funcionar es con la biblioteca binaria y las instrucciones correspondientes. Yo la obtuve gracias a que la solicité por correo al soporte técnico. Si me mandas un correo a ddompe en gmail yo te la pasó.
Del otro lado, el instalador para Mac si lo hacen disponible directamente (al menos el BAC), ver:
https://www.bac.net/bacsanjose/esp/banco/personas/FirmaDigital.html
Sobre el comentario que hace uno de los participantes indicando "...no se permite extraer la llave pública y privada del dispositivo de token que está siendo distribuido para usarlo externamente..."
Es importante señalar que la llave privada nunca debe abandonar el chip . Caso contrario, toda la fortaleza que brinda el utilizar un chip criptográfico no tendría sentido, pues otras personas o aplicaciones que pudieran acceder dicha llave privada, podrían crear firmas digitales usando la llave privada del dueño original, con lo cual se perdería la fortaleza del sistema y el no-repudio de transacciones.
El tokend es la interfaz nativa del sistema operativo Mac para lo que es el manejo de smartcards y por lo tanto es lo que utilizan las aplicaciones nativas de Mac tales como el navegador Safari o el Mail.
Todos los modelos de smartcards que han sido homologados por la CA SINPE, proveen dentro de su instalador para Mac, la interfaz tokend así como el módulo PKCS11. Así la smartcard pueda ser utilizada tanto en aplicaciones nativas del MacOS como en aplicaciones de terceros, tales como Firefox que utiliza PKCS11.
Para Linux tal como lo señalan, al no tener una interfaz de software estándar, lo que han provisto los fabricantes participantes de la homologación es la biblioteca PCKS#11.
Por lo tanto, cualquier usuario que tenga su smartcard y que utilice una Mac, dentro de sus instaladores debería tener el módulo tokend y también la librería PKCS#11. Y para los usuarios de Linux deberían tener la librería PKCS#11.
Realmente desconocemos cuál ha sido hasta el momento la estrategia de entrega de los drivers específicos para Mac y Linux, si los entregan todos junto con los de Windows cuando retiras la smartcard o si solo están disponibles a solicitud del cliente, ya que en la relación Cliente-Banco, la CA SINPE no interfiere.
Cabe aclarar que en lo que se refiere a los navegadores, no depende de si las tarjetas tienen o no drivers que los soporten, más bien es si el navegador soporta o no certificados digitales, por ejemplo, Chrome no los soporte. Además, en este tema es necesario que el desarrollador de las aplicaciones Web considere los navegadores para los cuales, la aplicación va a ser soportada. Esto porque cada navegador tiene sus particularidades, respecto al uso de certificados digitales y el desarrollo no es igual para cada navegador.
También es importante que se entienda que cuando hablamos de Firma Digital, estamos directamente hablando del No Repudio y por lo tanto no hay que perder de vista que la tarjeta es un dispositivo de seguridad, que contiene un chip criptográfico que cumple con certificaciones de seguridad tal como FIPS 140-2 nivel 3 y otros mecanismos para garantizar que la llave privada nunca abandone el dispositivo.
Así que lo que Dompe sugiere al final de su comentario, de extraer la llave privada del dispositivo es un imposible, pues no se estaría cumpliendo lo que nos pide la ley de Firma; en este aspecto, es más bien usted don Christian quien nos puede ilustrar.
Por otra parte como la palabra misma lo indica, la llave pública es pública y está contenida en el certificado digital de todas las personas y por lo tanto no haría falta extraerla de dispositivo. Aun así si se quisiera obtener la llave pública del dispositivo con los comandos apropiados la podría obtener, pues los drivers que se entregan exponen los comandos correspondientes.
Roysovick, y Carmen,
Es claro que por razones del estándar de seguridad _agregada_ del cripto-token, la llave no debe dejar el dispositivo. Lease "seguridad _agregada_", por que aún cuando la llave privada salga del dispositivo, la llave no deja de ser segura inherentemente dado que requiere un password para poder ser utilizada. El chip criptográfico de la tarjeta no representa ninguna fortaleza adicional sobre el sistema criptográfico existente en las computadoras, excepto que hace más difícil (no imposible) acceder a la llave privada. Algunas personas que haya trabajado en la fabricación del cripto-token probablemente puede tener la capacidad de "hackear" el token (sin mencionar a la NSA). La seguridad se encuentra entonces en la combinación de la llave privada con el password del usuario, con una seguridad agregada de que muy pocas personas pueden ser capaces de extraer la llave privada del token. Dicho de otra forma, el principio de no-repudio se basa en la fortaleza criptográfica del modelo matemático de las llaves, no en la ilusión de seguridad-por-oscuridad de un sistema de hardware hackeable (como la historia ha probado que son casi todos).
Dejando eso claro, no es que este alegando que se debe sacar la llave (esa seguridad extra esta bien), si no que a la falta de un driver disponible para el token en un sistema operativo común, la firma digital violaría la "neutralidad técnologica" (disculpando mi abuso del buzzword), dado que no se fundamenta solo en estándares criptográficos agnósticos al sistema operativo, pues estaría sujeta a poder usarse solo si existen los drivers para el sistema operativo dado. Pero esto es tema del pasado, parece ser que CA-Sinpe si ha hecho su tarea, solo que han habido algunos problemas de comunicación al público.
Carmen, yo recibí drivers para Mac pero solo contenía el modulo de PKCS#11, y a pesar de al menos 4 correos electrónicos con tres actores distintos involucrados en la firma digital no he conseguido un modulo de tokend. Usted seria tan amable de informarme donde está accesible dicho modulo para descargar?
Ya que tengo la atención del público, puedo preguntar algo más? El hecho de que el root CA de SINPE no fuera firmado por algún CA confiable de alto nivel fue a propósito? Me parece interesante que si uso mi firma digital en el correo electrónico, el 99% de los usuarios de correo del mundo van a recibir un mensaje como "No se puede confirmar la autenticidad de este correo" si su cliente de correo reconoce firmas digitales, a menos que hayan realizado el procedimiento manual de instalar los certificados de SINPE (cosa que no creo que mi mamá o papá puedan hacer). Se están realizando los tramites para que MS, Google, Mozilla, Apple, etc, incluyan el root CA de SINPE en su repositorio de top CA confiables?
Gracias
En la CCSS lo estamos implementando, actualmente estamos haciendo pruebas a lo interno solamente, sin embargo, ya tenemos claro que en Windows y en Linux, si funciona perfectamente.
Ahora bien, es una lástima que Doña Carmen indique que "Es lamentable que, porque algunos desarrolladores no hayan podido desarrollar sistemas que usan certificados digitales en Mac o Linux", pues en realidad, el Banco Central y el MICIT, con el POBRE soporte que dan a desarrolladores en la implementación de esta tecnología no comprenda que en realidad, este problema, es culpa de ellos mismos.
Así pues la CCSS ha tenido que ver como se las arregla para implementar Firma Digital a nivel de sistemas de información a como ha podido, sin el soporte de los que la han impulsado desde el inicio.
Para Dompe:
Sin querer entrar en polémica, debo indicarle que en su primer aporte al blog, usted indica textualmente "no se permite extraer la llave pública y privada del dispositivo de token", por tanto mi comentario sobre el no repudio iba dirigido a indicar, sin entrar en la parte matemática del asunto, en que si la llave privada es expuesta o extraíble (no por hackeo, sino por que esté implementada la función), su dueño original podría argumentar que no fue él quién firmó un documento, y por tanto, sería muy difícil probar el no-repudio de una transacción en un posible juicio al respecto.
Por supuesto que algunas personas podrían tener los recursos y conocimientos técnicos, y el tiempo para hackear un token FIPS nivel 2 o superior. No hay sistema infalible, como usted lo dice. El chiste de los controles de seguridad no es que sean infalibles, es qué tan difícil se hace en términos de conocimiento, esfuerzo, tiempo y dinero, el poder romperlos. Costo vs Beneficio para el hacker.
Ciertamente hay un password que proteje el token, eso es parte del diseño del aparato, igualmente existen dispositivos que se activan con huella digital. En ambos casos, si al usuario le ponen una pistola en la cabeza para que firme digitalmente, al igual que en el mundo físico, ni el password ni el diseño del chip cumpliendo el FIPS nivel 2 o superior, evitarán que la llave privada sea usada para iniciar un fraude, pero eso es un asunto probatorio, como dicen los abogados, no un elemento de que el chip permita, por diseño, el que la llave privada sea expuesta.
Ciertamente la fortaleza matemática que relaciona la llave pública y privada es una parte primordial de la fortaleza del sistema, y permite dar soporte al no-repudio desde el punto de vista tecnológico, pero este no fue el quid del comentario original con respecto a lo que usted indicó de que se permitiera a la llave privada salir del chip.
Finalmente, dicho esto, el que un chip permitiese que la llave privada saliera del mismo mediante alguna función, afecta el no repudio, en el sentido de que, de arranque, cualquier persona puede alegar que el chip no proporciona al menos un nivel de seguridad aceptable para garantizar que eso no suceda. Lo de la relación matemática de las llaves es también usado para el no repudio, por la relación entre las llaves, pero no por el cuestionamiento original que se hizo a su comentario, como ya expliqué.
Roysovick,
Entiendo tu comentario, y estoy totalmente de acuerdo con el escenario que estás exponiendo, el único malentendido es que estás asumiendo que el password de la llave reside en el token, lo cual puede que sea cierto o no, dependiendo de la implementación. En mi experiencia práctica con llaves de este tipo, el password es parte de la llave privada, no parte del dispositivo. Es decir, la llave privada no esta completa si no se le "anexa" (por verlo de alguna forma) el password.
Es decir, aún cuando alguien pudiese robar la llave privada (sea por hackeo o algún otro método), esa es "inservible" en tanto no sepa el password que completa la llave privada. Leasé "inservible" como un calificativo inversamente proporcional a la longitud y complejidad del password.
Buenas,
Es una lástima observar como no se aprovechan las oportunidades que la firma digital provee, al no hacerla utilizable en distintas plataformas, es por ello que Compr@RED 2.0 puede firmar documentos utilizando los certificados emitidos por SINPE Persona Física en Windows, Mac y Linux.
Favor observar como se firma una oferta electrónica en MAC en la siguiente dirección:
https://www.hacienda.go.cr/comprared/Comprared_Interoperable.pdf
Compr@RED 2 fue diseñado para ser interoperable desde el principio, gracias a un buen diseño.
Saludos,
Hayro,
Gracias por el link, la herramienta de firma que muestra se ve muy útil. De hecho parece proveer el 80% de la funcionalidad requerida para lo que se usa la firma digital.
Una pequeña corrección:el documento parece omitir el paso de agregar el keystore desde la smartcard e indicar el path hacia la libreria PKCS#11 para mac provisto por SINPE (que es el driver de la tarjeta). Si bien es cierto el _lector_ de tarjeta no necesita driver en casi cualquier OS moderno, insisto que la _tarjeta_ necesita el driver en la forma del modulo PKCS#11 (y parece que la gente suele confundirlos).
PD: Por cierto todavía no he logrado encontrar un driver tokend para la tarjeta a pesar de que se había mencionado que existe uno. Igual con esta aplicación DigiSigner parece que podré hacer casi todo lo que necesito.
Hola. Quisiera saber si quienes comentaron que estaban haciendo pruebas en linux pudieron implementar la firma digital. Hoy justamente se denunció en las listas de la RCSL este tema "Soporte Firma Digital recomienda Internet Explorer 8. Internet Explorer 8 es el ÚNICO navegador que cumple con los requerimientos de
seguridad de la Firma Digital" https://www.soportefirmadigital.com/sfd/
Carolina,
La firma si funciona en Linux, eso de la pagina de soporte de firma digital es simplemente publicidad de microsoft. Solamente el primer párrafo de la explicación que da tiene algo de sentido técnico, el resto es copy&paste de alguna página de marketing de IE8.
El argumento para decir que IE8 es el "único" que soporte "correctamente" firma digital es por la capacidad de evitar cachear el PIN en el browser con algunas APIs especificas del explorer. En mi limitado criterio de seguridad eso es irrelevante puesto que te estás protegiendo de tu propia maquina en la que estas "confiando"... si la maquina estuviera comprometida al punto que tratara de obtener tu pin, hay formas más simples de engañarte para obtenerlo que barrer el cache buscando el PIN...
Saludos.
Hola Dompe,
Ud. menciona varias veces el driver de la targeta IDProtect (de Athena)para Linux usada en CR. Sin embargo, yo no he sido capaz de encontrar tal driver. LO más cercano que he visto es el "IDProtect Client" ($119) http://idprotect-client.software.informer.com/
¿Nos puedes publicar el enlace al sitio adecuado?
Hola Dompe,
Ud. menciona varias veces el driver de la targeta IDProtect (de Athena)para Linux usada en CR. Sin embargo, yo no he sido capaz de encontrar tal driver. LO más cercano que he visto es el "IDProtect Client" ($119) http://idprotect-client.software.informer.com/
¿Nos puedes publicar el enlace al sitio adecuado?
Hola, instalar el controlador de IDProtect en GNU/Linux hoy en día es una realidad. Para que el módulo PKCS#11 funcione correctamente Requiere que exista un XML adecuado en /etc/Athena/, que lo genera el instalador deb o rpm del pintool. También hay algunas guías por internet para lograr esto.
Publicar un comentario