El Seguro de Responsabilidad Civil para PSC (Prestadores de Servicios de Certificación) es uno de los temas vidriosos de la Ley 59/2003 de Firma Electrónica (en realidad lo era todavía más en el real decreto anterior).
Por un criterio arbitrario se impone un gasto a los PSC que no tiene contrapartida.
Todavía no he visto en ninguno de los prestadores de servicios de certificación que operan en España una sección del web que diga «Reclamaciones» con frases como las siguientes:
- «Si usted considera que ha sufrido un perjuicio como titular o suscritor de certificados emitidos por nuestra entidad, puede reclamar de la siguiente forma…»
- «Si usted considera que ha sufrido un perjuicio como tercero que confía en certificados emitidos por nuestra entidad, puede reclamar de la siguiente forma…»
Por lo cual, no sé de qué sirve, en realidad el seguro de responsabilidad civil. Y no digamos el Aval o el Seguro de Caución.
Porque, desde luego, para lo que no sirve es para responder de incumplimientos de la normativa, para lo cual existe otra vía de actuación, derivada de la tipificación de faltas y sanciones (que no pueden ser cubiertas por un seguro).
Todo es electrónico 
Pingback: El seguro de responsabilidad civil de los Prestadores de Servicios Electrónicos de Confianza | Todo es electrónico
Pingback: Alternativas al seguro de responsabilidad civil de los Prestadores de Servicios de Certificación. « Todo es electrónico
Pingback: El seguro de los PSC « Todo es electrónico
Pingback: El (escaso) negocio de los PSC « Todo es electrónico
Pingback: 1.000.000 de visitas « Todo es electrónico
Pingback: Bricks and Bits » Mi otro blog
Completamente de acuerdo con tus apreciaciones, excepto:
a. Actualmente no hay establecido legalmente ningun formato como obligatorio para la firma electronica ni en su aplicacion a la e-factura, ni en la aplicacion a otro tipo de documentos, razon por la cual, con independencia de que existan formatos estructurados para los que la seguridad seria practicamente absoluta (estoy pensando en sistemas basados en UBL para factura electronica o XMLDSIG, mas generalista), la ley ni establece ese tipo de distincion, ni todos los documentos a firmar pueden admitir este tipo de sistemas de estructuracion.
b. La busqueda de colisiones, precisamente los algoritmos de busqueda de colisiones han conseguido que partiendo de un original, y aplicando dichos algoritmos de modificacion, estructurar una busqueda de modo que la colision de ficheros no ocurra en el intento 2^128, sino en el intento 2^22….por eso se identifican como comprometidos los algoritmos (si bien no es menos ciertos que en entornos donde los documentos a firmar sean completamente estructurados (o aun mejor, en aquellos supuestos en los que la firma sea aplicada exlusivamente a un campo del documento), la validez de cualquier algoritmo de firma es indiscutible).
3º. Completamente de acuerdo con la apreciacion de que, en tanto la parte mas «debil» del sistema de firma digital corresponde al algoritmo de hash, se deberia calcular el hash previo a la firma con 2 algoritmos diferenciados de este modo la posilidad de colisiones seria practicamente nula.
Lo de «comprometido» creo que es un término incorrecto en este contexto. Se dice que una clave está comprometida cuando es conocida por un atacante.
Más que de un algoritmo comprometido, estaríamos hablando de un algoritmo cuya robustez criptográfica es más o menos buena en relación, en este caso, con la probabilidad de colisiones. En este sentido tenemos algoritmos muy buenos y otros menos buenos.
Tanto MD5 como SHA-1 son suficientemente buenos para documentos estructurados y menos buenos para ficheros con área de padding (zonas no significativas), como los ficheros gráficos.
En efecto, un gráfico se puede manipular para que, manteniendo su aspecto, sus valores binarios cambien (modificando la mencionada área de padding o los bits menos significativos de la imagen). Lo que mejora la probabilidad de encontrar una colisión.
Sin embargo los ficheros estructurados dan muy pocas oportunidades a la manipulación, si queremos que sea tan significativo el documento suplantador como el suplantado.
En este sentido, incluso un algoritmo como el veterano CRC-16 o el CRC-32 podría ser utilizado con garantías.
Siempre es posible encontrar colisiones por la definición del algoritmos de hash: el resultado, de tamaño fijo, se calcula sobre cualquier fichero, de cualquier tamaño. ¡Claro que hay colisiones! Lo que no ha mejorado significativamente es que se pueda predecir la modificación significativa que hay que aplicar a un fichero para que colisione con el original.
De modo que, en la práctica, los algoritmos MD4, MD5 y SHA-1 son excelentes y el margen de error perfectamente aceptable.
Y aún más si se utilizan dos algoritmos de forma combinada, porque los documentos que colisionan respecto de un algoritmo, no colisionan respecto del otro.
Sigo sin entender muy bien en qué consiste lo de entregar los certificados cruzados erróneamente.
Si la petición de certificado se sustenta en un PKCS#10, la CA firma el contenido de la petición donde van los datos aportados por el solicitante, eventualmente añadiendo algún atributo en alguna extensión.
Lo único que se me ocurre es que la CA extrajera del request la clave pública, cambiara todo el resto de datos, lo firmara y se lo entregara al solicitante cuya clave privada se asocia a esa misma pública.
Pero eso no se puede hacer por error.
Posiblemente no me he explicado bien… obviamente no es posible crear un certificado con los datos de otra empresa, pero si es posible entregar de forma erronea los certificados cruzados, es decir, la empresa A recibe el certificado de la empresa B (certificado emitido al apoderado de la empresa B, con el CIF de la empresa B etc…), es dificil que los usuarios de A no vean que ese no es el certificado que les corresponde (pero como decia el sabio, la diferencia entre el universo y la estupidez humana es que la segunda no tiene limites)…. y en este caso, es muy dificil por parte del prestador decir que actuó de forma diligente, pues:
A. Tiene una responsabilidad compartida con la empresa A (en tanto le suministra a dicha empresa un certificado que no le corresponde, mientras que la propia empresa deberia haber constatado que ese no era su certificado).
B. Tiene una responsabilidad clara y directa respecto a la empresa B, pues por la accion del prestador de servicios, y sin ningun tipo de consentimiento por parte de esta, ha hecho llegar a un tercero un certificado que permite la realizacion de todo tipo de operaciones en nombre de la empresa A (con plena validez juridica frente a terceros…y ojo en este punto,pues nos podriamos meter en un autentico vertedero judicial, en tanto se podrian declarar validos los contratos realizados con terceros de buena fe en nombre de la empresa B (en tanto el certificado era completamente valido), y en caso de impugnar el contrato… ¿que se impugna…?¿el certificado… que era completamente valido si nos atenemos a la normativa de la ley de firma electronica??¿el documento con él firmado… ??.. Esta claro que alguien de la empresa A tiene una responsabilidad clara y directa (siempre y cuando conociera el uso que estaba realizando del certificado) y siempre podremos interponer la correspondiente demanda … pero no menos clara es la responsabilidad del emisor del certificado…
Respecto a que no es cierto que hayan sido comprometidos los algoritmos de hash…
Discrepo en la afirmacion «improbable es que con esa rigidez de formato un atacante pueda encontrar un texto claro inteligible y con la información que le gusta al atacante»… no necesito para nada buscar un hash de un texto claro inteligible, lo unico que necesito es un «Documento» conformado por texto claro, imagenes, y codigo no visible que conforme el hash que yo necesito
Es todo cuestion de capacidad de proceso, si descubrimos la forma rapida de buscar colisiones tenemos automaticamente la posiblidad de crear falsificaciones de cualquier tipo de documento….al menos teniendo en cuenta el actual esquema utilizado para la firma electronica… segun el cual primero se calcula el hash de un documento y posteriormente se codifica con la clave privada dicho valor de hash, asi, dos documentos con identico valor de hash tienen identica firma. Teniendo en cuenta que lo que firmamos es un documento completo (y no solamente el texto en él visible), y suponiendo que disponemos de
a. Un algoritmo de hash comprometido en el sentido de que podemos buscar de forma mas o menos rapida colisiones para un hash dado.
b. Suficiente capacidad de proceso.
modificariamos el documento que pretendemos falsificar (la parte visible del mismo), y dejariamos a un programa la labor de «complementar» la parte no visible del documento para que el hash coincida con el que necesitamos en la firma del documento.
La teoria no difiere mucho de lo que se produciria en el caso de un algoritmo no comprometido (buscar documentos con un hash determinado), la diferencia es que en un algoritmo no comprometido encontrariamos una colision cada (p.ejm) 2^128 intentos (md4), mientras que en un algoritmo comprometido puede que esta cifra se reduzca a algo mas «asumible» como 2^22 intentos (incluso menor), en concreto md4 se considera completamente roto por la RSA pues ya en 1995 se podian encontrar colisiones a un hash dado con un pc en menos de 1 minuto.
En definitiva, puede que el algoritmo que conforma RSA o AES sea completamente valido e imposible su ruptura (hoy por hoy), pero en tanto el sistema de firma electronica se base en sistemas de codificacion de codigos hash, (y no en la codificacion del fichero completo), si el algoritmo de calculo de hash se ve comprometido, con disponer de un unico documento firmado electronicamente automaticamente podriamos generar cualquier documento valido para dicho certificado.
En realidad no es posible asociar un certificado a una clave privada diferente de la que procede la solicitud, ya que no cuadra la fórmula matemática que vincula la clave pública a la privada.
Por otro lado, el prestador no tiene ninguna responsabilidad si puede probar que actuó diligentemente.
Y, desde luego, no tiene ninguna responsabilidad en la robustez de los algoritmos.
De todas formas, aprovecho para añadir que los algoritmos que mencionas NO han sido «comprometidos». Es cierto que se ha demostrado matemáticamente que para algunos algoritmos la probabilidad de colisión de 2 piezas de texto claro diferentes que ofrecen el mismo valor de hash es mayor del que se suponía, pero eso no invalida el algoritmo y mucho menos en entornos de texto claro de formato rígido, ya que lo que sigue siendo improbable es que con esa rigidez de formato un atacante pueda encontrar un texto claro inteligible y con la información que le gusta al atacante, que pueda sustituir al texto claro original con el que se construó el hash, y del que se deriva la firma.
Pongamos el siguiente ejemplo….
La empresa A solicita a la FNMT el correspondiente certificado para la realizacion online de determinadas gestiones tributarias, ademas, aprovecha este mismo certificado para comenzar su proceso de adaptacion de sus sistemas a facturacion electronica.
La empresa B solicita el mismo dia un certificado para su empresa con finalidades identicas.
Tras los tramites pertinentes en la entidad de registro correspondiente, les son suministradas las claves y las direcciones para la descarga online de los certificados, pero por un error informatico, los certificados se han cruzado, y se ha indicado a la empresa A el acceso al certificado de la B y viceversa….
Como los administrativos de las empresas A y B son bastante descuidados, no se fijan en los datos incorporados a la hora de presentar los informes… y asi pasan 2 meses, ambas empresas firmando facturas sin validez legal alguna, y presentando informes a Hacienda en nombre de otra empresa…. pasado este tiempo alguien descubre el error….¿quien se hace cargo de los perjuicios causados???….
Si en lugar de empresas A y B fuesen 40 las empresas implicadas…¿podria hacerse cargo la entidad certificadora de los importes de las demandas de no mediar el seguro de responsabilidad contratado??????.
Otra cuestion seria la derivada de la seguridad en si de los propios certificados, es decir, asi como hemos podido comprobar que algoritmos como DES, MD4 y otros (incluso MD5) han sido comprometidos…¿que ocurriria si RSA o SHA1 se viera comprometido???…. si dicho compromiso fuera llevado a la practica (es decir, alguien utilizara dicha vulnerabilidad en el algoritmo para atacar un certificado y falsificar elementos de un documento sin cambiar con ello la validez de la firma (por poner un ejemplo)…. ¿Cubriria el seguro esta situacion…????…realmente habria que ver los terminos legales del propio seguro pero, tengo mis dudas de que ello sea asi.