Firma Digital (in) Segura

¡Hola!

En el día de hoy vamos a cambiar de tercio hablando de una de las aplicaciones prácticas que la tecnología ha llevado a nuestros hogares / empresas para facilitarnos la vida, la firma electrónica. Esta firma está contemplada en nuestra legislación bajo la Ley 59/2003 de firma electrónica (que tenéis aquí) y cuyo mayor impacto es equiparar la firma manuscrita con la firma digital. Ahora bien existen distintos tipos de firma que la ley contempla:

1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante.

2. La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control.

3. Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.

4. La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel.

Esto es, tenemos 3 tipos de firma. La 1) que es la más sencilla garantizará el no-repudio. La 2) garantizará el no-repudio y la integridad del documento firmado, esto es, que no ha sido alterado por terceras partes. La 3) que garantiza a través de dispositivos seguros de creación de firma todo lo anterior haciendo a esta firma equiparable a la manuscrita en términos jurídicos y legales.

Claro está si se aprovecha el marco legal que esta Ley nos brinda esto puede facilitar trámites a ciudadanos y ahorrar chorros de tinta a las empresas, el Gobierno sabiendo esto enmarcó la factura electrónica dentro del Plan Avanza y presentó el portal Factura-e donde se explica lo que es una factura digital y se proporcionan utilidades a las pymes para que trabajen con ella, ejemplos de facturas electrónicas, etc. Una de las aplicaciones generadas por el ministerio es Facturae, que pinta así:

Interfaz de FacturaE

Incluye tu propio gestor de facturas, envío de las mismas desde servidores SMTP con SSL, listado de servidores OCSP para validar certificados X.509, etc. Parece una buena aplicación, ¿no creéis?

En el mismo marco este verano el Ministerio de Industria, Comercio y Turismo lanzó la EcoFirma, otra aplicación de firma digital de extrema sencillez que acerca la firma digital a ciudadanos y pymes, permitiendo firmar casi cualquier tipo de archivo, desde .doc a imágenes pasando por PDF a los que se pueden incrustar marcas de agua, etc. EcoFirma tiene el siguiente interfaz:

EcoFirma, tan sencillo como esto.

Puede importar certificados de nuestros exploradores habituales (IE, Mozilla) facilitándonos enormemente los procesos de firma y validación de otras firmas.

Todo esto está muy bien pero no puedo evitar lanzarme unas cuantas preguntas, y es aquí cuando viene el verdadero motivo de esta entrada, ¿las firmas que realiza el software que provee el ministerior, son firmas reconocidas? Supongamos que utilizamos los certificados de nuestro DNI electrónico (si tenéis curiosidad por todas las cosas que lleváis en la cartera cuando tenés dentro el DNI electrónico echad un ojo aquí) para firmar un archivo, estos son certificados reconocidos tal como marca la Ley, ¿es el software un dispositivo seguro de creación de firmas? Indagando sobre ello vemos que en Kriptópolis ya se hicieron la misma pregunta, llegando a conclusiones negativas. Repasemos la Ley:

2. Un dispositivo de creación de firma es un programa o sistema informático que sirve para aplicar los datos de creación de firma.

3. Un dispositivo seguro de creación de firma es un dispositivo de creación de firma que ofrece, al menos, las siguientes garantías:

a) Que los datos utilizados para la generación de firma pueden producirse sólo una vez y asegura razonablemente su secreto.

b) Que existe una seguridad razonable de que los datos utilizados para la generación de firma no pueden ser derivados de los de verificación de firma o de la propia firma y de que la firma está protegida contra la falsificación con la tecnología existente en cada momento.

c) Que los datos de creación de firma pueden ser protegidos de forma fiable por el firmante contra su utilización por terceros.

d) Que el dispositivo utilizado no altera los datos o el documento que deba firmarse ni impide que éste se muestre al firmante antes del proceso de firma.

Luego SI, el software (un programa informático) puede considerarse un dispositivo seguro. Ahora bien, ¿quien me lo garantiza?, ¿los estándares internacionales?, ¿como se que no hay gato encerrado?. Simple y llanamente: no lo se y no podré saberlo. En última instancia siempre hay que confiar en alguien, el estado, las autoridades de certificación, la Ley. En mi opinión un software NUNCA debería estar considerado un dispositivo seguro, una combinación Sotware + Hardware SI, ¿por qué? Por que una appliance siempre será una combinación más robusta que código y más código (Maria José Caro de INTECO ofreció una ponencia sobre la seguridad de estos dispositivos bastante interesante). Más robusta y más cara claro, de ahí que se haya optado por la vía cómoda.

Lector de DNI Electronico

En un proceso judicial estas dudas que aquí nos surgen pueden ser indicadas a los jueces quienes inevitablemente tendrán que apoyarse en Peritos para que una firma electrónica no sea impugnada. Esto podría ser un grave problema si no fuese por que la Ley recoge que las partes pueden acordar previamente el sistema de firma electrónica a utilizar, si ese acuerdo se alcanza (y firma) no habrá apelación que valga. Ahora bien, ¿cuantos de vosotros habéis revisado los sistemas de factura electrónica de vuestros proveedores de telecomunicaciones, internet, banca, etc.?, ¿está el ciudadano indefenso viéndose obligado a aceptar y confiar en sistemas que desconoce? Parece que en parte, Si.

Una pequeña reflexión de fin de semana.

Salu2!

Secure Survey

En los últimos días me vino a la cabeza un interrogante sobre las numerosas encuestas que circulan por Internet, ¿cuan fiables son estas encuestas? Siempre acabo dando con la misma respuesta, “depende”. Pero nunca le había dado un par de vueltas, nunca hasta hoy. De todas formas parece que soy el único que se hace este tipo de preguntas (será el trabajo, que se yo), por que la práctica totalidad de medios de televisión y prensa del mundo despliegan estas encuestas incorporándolas a la versión escrita de sus periódicos, programas de radio y televisión. Esto puede ser un gran problema de credibilidad ya que aparecen al lado de otras en teoría “más fiables” como las que realiza el CIS dando lugar a la errónea suposición de que ambas tienen resultados con la misma confianza (cualquiera que sea esta).

Tras un pequeño vistazo a algunos medios digitales he podido encontrarme las siguientes cosas, corresponden al código con que se realizan las peticiones y se almacenan los votos:

onsubmit="javascript:{if ( hasCookie('haVotado') ) {alert('Tu voto ya ha sido registrado'); return false;} 

else {return true};}"

En este caso si el método ‘has cookie’ devuelve “true” votas, sino no. Delega el voto en un control sobre la cookie. En este otro caso:

OAS_version = 10;

OAS_rn = '001234567890'; OAS_rns = '1234567890';

OAS_rn = new String (Math.random()); OAS_rns = OAS_rn.substring (2, 11);

function OAS_NORMAL(pos) {

document.write('

 '!' + pos + OAS_query + '" TARGET=_top>'); 

Se hace la petición al servidor de aplicaciones (OAS = Oracle Application Server) a partir de una cadena que se almacena en la Cookie, en la misma se “ofusca” incrustando un valor aleatorio de semilla conocida a la petición. La construcción de esa cadena es perfectamente visible en el código javascript, luego todo es pasado en el GET y algunos atributos quedan ocultos en el POST que lee los valores de la Cookie:

Luego parece que esta encuesta también es manipulable, conociendo el mecanismo que genera las peticiones y con un http Fuzzer (como el que incorpora Acunetix) podemos generar votos automáticamente.

Indagando un poco más he encontrado encuestas que incluían CAPTCHA, pero este mecanismo tampoco es infalible como vimos aquí, luego, ¿Qué nos queda? Incluso para dar un servicio de apariencia tan sencilla como este es necesario un conjunto de medidas de seguridad donde por sí sola ninguna nos puede proporcionar confianza de que el voto no ha sido manipulado / generado automáticamente, no obstante en conjunto el riesgo se “mitiga”. Algunas de las que a mí se me ocurren son:

- No incluir en código JavaScript los métodos de comprobación de origen, es visible.

- No verificar el origen a partir de información depositada en el cliente, esta información puede ser manipulada.

- Incluir CAPTCHA.

- Incluir un mecanismo para verificar el origen por token (secreto) + IP + credenciales que identifiquen al equipo, para garantizar la integridad del origen de la petición (podemos utilizar hash también). Estas comprobaciones se harán en el servidor.

Bueno, en un entorno ideal se podría utilizar incluso la firma digital de los usuarios (¿DNI electrónico?) para realizar una encuesta. Claro está que para saber que opina la gente con respecto al partidazo del Atleti no aplica, pero para un referendum,,, quizás si.

Esto es todo por hoy, cuidado donde votáis y cual es el origen de vuestras encuestas :)

Salu2!

Visual Basic 2008: Security Features

La vuelta de las vacas este año ha sido un poco más dura de lo habitual, es de esas veces donde desconectas del mundo de la Seguridad al 99% y olvidas casi casi a lo que te dedicas haciendo que el dia de vuelta te apetezca realizar Ctrl + Alt + Sup mental. Mientras que el año pasado aproveché para realizar “experimentos” de diversa índole en esta ocasión he tenido otras tareas. Por razones familiares tuve que crear una pequeña aplicación Cliente – Servidor para una clínica.

Haciendo flash—back recordé la agilidad con la que allá por el 2000 me desenvolvía en Visual Basic 5.0 y me dije, ¿Cuánto habrá podido cambiar? Y me decidí a bajarme el Visual Studio Express Edition, concretamente el Visual Basic (que ya va por la versión 9.0). Lo cierto es que no me llevé muchas sorpresas, en su esencia sigue siendo tremendamente cómodo, intuitivo y ágil. Eso sí, hay muchas novedades y utilidades para aplicar Seguridad desde los albores de un proyecto:

Permisos de aplicación: UAC

Dentro del explorador de soluciones en las propiedades del proyecto podemos cambiar los privilegios que requiera la aplicación así como las posibles llamadas al UAC. Como es obvio debemos tratar de trabajar con los menores de los permisos, así evitaremos por ejemplo que ante un “crash” de nuestra aplicación tiremos el sistema.

Código XML con el que definimos la seguridad UAC de la aplicación

Seguridad ClickONCE

Las aplicaciones que desarrollamos en VB se apoyan en la infraestructura .NET Framework y estarán sujetas a restricciones de código. Dentro de las propiedades del proyecto también podremos habilitar o deshabilitar restricciones según los permisos que requiera nuestro código, esto puede incluir transferencia de ficheros, cuadros de diálogo, permisos de impresión, generación de sockets, etc. etc.

Configurando permisos ClickONCE

Firma de Código: Generación de certificados

Es cierto, podremos garantizar a nuestros clientes que el software distribuido es nuestro a través de la firma digital. Para ello disponemos de una utilidad de generación de certificados que en cierta forma me recuerda al PGP y que a buen seguro aumentará la confianza a nuestros clientes:

Acceso a BBDD

También me ha llamado la atención la gestión de BBDD que hay disponible, si bien a priori podemos tirar “solo” de Microsoft Access y SQL Server (en el Wizard de Agregar Conexión), próximamente disponemos de opciones de autenticación de usuario al realizar las consultas, restringido eso sí a usuarios de SQL Server o de Windows (supongo que se podrán utilizar usuarios de Dominio, pero no lo he probado). También podremos crear y cifrar BBDD basadas en SQL Compact Server así como incluir o no en los argumentos de nuestras cadenas de conexión y consultas SQL el usuario y password con el que nos conectamos (no recomendable ya que viajará en claro).

Agregamos la cadena de conexión a nuestra BBDD

Creamos nuestra BBDD con el cifrado que permita la plataforma host.

Login Form

Todavía recuerdo esos viejos días en que independientemente del texto que introdujeras en el TextBox debías mostrar asteriscos para que ataques por shoulder surfing no fuesen un problema (algo que todavía no está limado del todo en plataformas como el Iphone [^^!]), en la última versión de VB tenemos los formularios predefinidos más comunes disponibles a un par de clicks (Proyecto à Agregar), entre ellos el Login Form, una gozada :D (que por supuesto he usado).

Formulario por defecto para hacer "Login"

Y tras haber trasteado con esta plataforma y tener casi terminada mi aplicación no he utilizado ni visto mucho más, aunque a buen seguro habrá muchas más opciones, solo hace falta explorar un poquito. La esencia de Visual Basic no ha variado un ápice en estos 9 años, sin embargo el abanico de facilidades no ha dejado de crecer (incluso para nosotros).

Salu2 y,,, ¡cuidado con la vuelta!

El cartero siempre llama dos veces (o más)

Hay muchas curiosidades en el mundo del correo electrónico, hay vida más allá de los protocolos POP3, SMTP y de Outlook, Lotus Notes y cia. Últimamente parece que están surgiendo con fuerza de nuevo, podíamos leer hace unos días que la primera aparición de la “@” data de 1536, y surgía en un tratado comercial enviado desde Sevilla a Italia. El premio Príncipe de Asturias va a ser entregado al inventor del correo electrónico, Raymond S.Tomlynson, quien creó el primer e-mail de la historia: “QWERTYUIOP” ¿os suena? Posteriormente se definieron las RFC 5322 y 5321 para el protocolo SMTP y el e-mail estándar surgiendo más curiosidades como que no podemos mandar un correo a un usuario cuyo nombre supere los 64 caracteres o a un dominio de más de 255 caracteres.

Parece que algo tan sencillo como el correo electrónico no puede tener mucho más que sacar, pero nos equivocamos. Es posible hacer muchas travesuras con la forma de expresar una dirección de correo, es incluso posible enviar un correo a todoesseguro@192.168.0.1 si es que esa fuera la IP de mi servidor de correo, también se pueden utilizar las comillas para definir el nombre o código de usuario dentro de una organización. Por ejemplo si hubiéramos capturado el código de usuario de un miembro de la organización gigasoft y fuese por ejemplo G1234, podríamos mandar un correo a “G1234”@gigasoft.com con muchas garantías de su correcta entrega (seguro que se os ha puesto cara de Daniel el travieso con esto último) pero no es todo.

Se pueden crear “filtros” de nombre de usuario, hay toda una RFC 5228 dedicada a este tema, donde como curiosidad diré que hace referencia a otra RFC 2119 para interpretar correctamente el significado de MUST, SHALL, MAY, etc. Algo que recuerda a las clases de inglés del instituto :D. Estos filtros se aplican en la parte local, exactamente aquí:

:user "+" :detail "@" :domain

\-----------------/

:local-part

Y lo que es más curioso, muchos webmails permiten utilizarlos, así por ejemplo gmail tiene su “+” mientras que Yahoo se vale del guioncito “-“. Esto es muy útil ya que añadimos una etiqueta a nuestra dirección de correo, supongamos que nos damos de alta en una página de prestigio internacional, llamémosla todoesseguro.com, y que nuestro correo electrónico es giga@gmail.com, podrían tramitar el alta indicando giga+todoesseguro@gmail.com. Así si recibo un correo de todoesseguro.com hacia giga@gmail.com puedo tener la certeza de que estoy recibiendo SPAM y el remitente no es de confianza, por lo que tendré que investigar un poquito :)

Por que de entre las cosas fáciles que hay en el mundo de la Seguridad Informática si lo más sencillo es hacer un escáner de puertos, lo siguiente es hacer e-mail spoofing. Hace unos días mi colega Rosillo, viejo inspirador de entradas como el Rosillo Project fue victima de correos a sí mismo valiéndose de alguna de las técnicas que El Maligno publicaba en su serie “Enviar a un amigo”. Esto que bien puede pasar por una inocente broma puede generar ataques por Ingeniería Social si no nos andamos por cuidado, sobretodo en las fechas que nos encontramos y activando las temibles “autorespuestas”.

¿Temibles?, me explico, dentro de unos días cuando media España se vaya de vacaciones y la otra se quede aquí conmigo en Madrid (no es broma, yo también me iré ;-) ) muchos de nosotros configuraremos algo como esto:

Eso está muy bien, hay que dejar los cabos atados antes de irnos pero, ¿a qué precio?, ¿Quién no está subscrito a una lista de correo?, ¿sabemos lo que ocurrirá cuando nos llegue un correo de un foro?, si, efectivamente todo el mundo sabrá que te has ido y además a quien tiene que recurrir en tu ausencia. Además es probable que “repartas” información como tu usuario, servidor de correo, actividad que realizas, etc. Tal como le ha pasado a toda esta gente.

¿Consejos? Tener mucho cuidado con qué se pone en los mensajes de autorespuesta, no habilitarlo si no es necesario y si trabajamos en una gran compañía como cliente quizás puede ser una medida de seguridad interesante notificar a los responsables de Correo Electrónico que los mensajes de “autorespuesta” no salgan hacia Internet (al menos fuera del Departamento Comercial).

Parece mentira que algo tan sencillo de tanto juego, y eso que no hemos hablado del Correo Electrónico Seguro, supongo que por eso tiene su premio :)

Salu2!

Corolario al PGP: Firma Digital

Como corolario a lo visto anteriormente en el PGP , y adentrándonos más en materia legal, la Ley 59/2003, de 19 de Diciembre de Firma Electrónica introduce algunos conceptos de especial relevancia sobretodo en los trámites con administraciones públicas, en tratados comerciales por Internet, etc. Destaco especialmente:

Artículo 3: Firma electrónica, y documentos firmados electrónicamente.

1. La firma electrónica es el conjunto de datos en forma electrónica, consignados junto a otros o asociados con ellos, que pueden ser utilizados como medio de identificación del firmante.
2. La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control.
3. Se considera firma electrónica reconocida la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma.
4. La firma electrónica reconocida tendrá respecto de los datos consignados en forma electrónica el mismo valor que la firma manuscrita en relación con los consignados en papel.
5. Se considera documento electrónico el redactado en soporte electrónico que incorpore datos que estén firmados electrónicamente.

Como vemos se hace mención específica a la firma digital que preserva la identificación del firmante (demuestra su autenticidad, preserva el no repudio) y la firma electrónica avanzada que añade el atributo de integridad a lo firmado, es decir se asegura que el documento electrónico no ha sido modificado, de igual forma parece dar más importancia a los medios o sistemas con los que el firmante hace uso de la firma digital, y que esos medios o sistemas no hayan sido manipulados o tergiversados por terceros. Finalmente el punto cuatro le proporciona equiparación legal a la firma electrónica reconocida con la firma manuscrita. ¿Qué se precisa para que una firma electrónica esté reconocida? La ley lo especifica así:

“Con ello se aclara que no basta con la firma electrónica avanzada para la equiparación con la firma manuscrita; es preciso que la firma electrónica avanzada esté basada en un certificado reconocido y haya sido creada por un dispositivo seguro de creación.”

Aquí es donde entran en juego certificados digitales, entidades de certificación:

Artículo 6. Concepto de certificado electrónico y de firmante.

1. Un certificado electrónico es un documento firmado electrónicamente por un prestador de servicios de certificación que vincula unos datos de verificación de firma a un firmante y confirma su identidad.
2. El firmante es la persona que posee un dispositivo de creación de firma y que actúa en nombre propio o en nombre de una persona física o jurídica a la que representa.

Y lo que es más importante, ¿en qué casos se puede suspender un certificado digital y por tanto considerarse no válido?

Artículo 9. Suspensión de la vigencia de los certificados electrónicos.

1. 1. Los prestadores de servicios de certificación suspenderán la vigencia de los certificados electrónicos expedidos si concurre alguna de las siguientes causas:
   a) Solicitud del firmante, la persona física o jurídica representada por éste, un tercero autorizado o la persona física solicitante de un certificado electrónico de persona
   jurídica.
   b) Resolución judicial o administrativa que lo ordene.
   c) La existencia de dudas fundadas acerca de la concurrencia de las causas de extinción de la vigencia de los certificados contempladas en los párrafos c) y g) del artículo 8.1.
   d) Cualquier otra causa lícita prevista en la declaración de prácticas de certificación.
2. La suspensión de la vigencia de un certificado electrónico surtirá efectos desde que se incluya en el servicio de consulta sobre la vigencia de los certificados del prestador de servicios de certificación.
   
   ….

La extinción o suspensión de la vigencia de un certificado también hará que una firma electrónica sea no reconocida. Como imaginareis la casuística por detrás de la ley puede ser muy amplia, por tanto será de gran ayuda contar con un buen abogado / perito informático que nos apoye a la hora de presentarnos en un litigio, sobretodo para que no nos pase como al Cracker de Pontevedra.

Saludos legalmente inseguros!