La Plataforma @firma es la solución tecnológica en la que se basa la implementación de la plataforma de validación y firma electrónica dhttps://www.google.eselMinisterio de Hacienda y Administraciones Públicas de España. Está basada en software libre y estándares abiertos.
El servicio de validación de certificados y firmas electrónicas de @firma es una plataforma de validación multi-CA desarrollada inicialmente por la Junta de Andalucía, y cedida al Ministerio de Administraciones Públicas (hoy Ministerio de Hacienda y Administraciones Públicas) con el objeto de fomentar y extender el desarrollo de la Administración Electrónica y la Sociedad de la Información.
El componente Cliente @firma, desarrollado por la Dirección General de Modernización Administrativa, Procedimiento e Impulso de la Administración Electrónica, perteneciente al Ministerio de Hacienda y Administraciones Públicas, es un módulo que se distribuye de forma independiente a la Plataforma y que permite a los usuarios realizar el proceso de firma digital de documentos en sus máquinas locales.
Cliente @firma
El Cliente @Firma es una herramienta de firma electrónica que se ejecuta en cliente (PC del usuario) basada en Java. Esto es así para evitar que la clave privada asociada a un certificado digital tenga que “salir” del contenedor del usuario (tarjeta, dispositivo USB o navegador) ubicado en su PC. Funciona bajo dos modalidades distintas:
- como applet de Java integrado en páginas web mediante comandos JavaScript.
- como aplicación de escritorio.
Este cliente de firma electrónica contiene las interfaces y componentes web necesarios para la realización de los siguientes procesos:
- Firma de formularios web.
- Firma de datos y ficheros.
- Multifirma masiva de datos y ficheros.
- Cofirma (CoSignature) → Multifirma al mismo nivel.
- Contrafirma (CounterSignature) → Multifirma en cascada.
Como complemento al Cliente @Firma, se encuentra un cliente de cifrado que permite realizar funciones de cifrado y descifrado de datos atendiendo a diferentes algoritmos y configuraciones.
Especificaciones técnicas
Características
- Funciona haciendo uso de certificados digitales reconocidos conforme el estándar ITU-T X.509 v3, emitidos por múltiples prestadores de servicios de certificación.
- Los algoritmos criptográficos soportados son:
- Formatos de firma posibles: CAdES-BES / EPES, XAdES-BES / EPES, PAdES-BES / EPES, CMS, OOXML, XMLDsig,PDF y ODF.
- Permite la generación de sobres digitales CMS y CAdES para la transmisión de documentos cifrados.
- Ofrece tres modos distintos de instalación: básica, media y completa; así permite ahorrar tiempo de descarga y espacio en disco a aquellos que no necesiten todas las características o formatos soportados por la aplicación.
- Existe un sistema para la incorporación de plugins a la aplicación del cliente de firma; como pueden ser diferentes formatos de firma adicionales que en un futuro se quieran agregar al cliente.
Requisitos mínimos para su funcionamiento
- Sistema operativo: Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, Windows Server 2012, Linux (Guadalinex, Ubuntu, Debian), MacOS X 10.5 y Sun Solaris / OpenSolaris 10.
- Navegador web: Firefox 2.0.20 o superior, Internet Explorer 5.5 o superior, Chrome 3.0 o superior y Apple Safari 10 o superior.
- JRE 1.5 update22 o superior.
- Certificados digitales instalados en el navegador web o sistema operativo, en tarjetas inteligentes (PKCS#11 / CSP) u otros almacenes de claves.
- Soporta Tarjetas en dispositivos criptográficos hardware como los HSM.
Liberación
El proyecto Cliente @Firma es una iniciativa alineada con la Ley 11/2007, de acceso electrónico de los ciudadanos a los Servicios Públicos, que favorece la reutilización de aplicaciones y la transferencia de tecnología. De acuerdo con estos principios, el 26 de octubre del 2010 se llevó a cabo la liberación del Cliente @firma en la forja del Centro de Transferencia de Tecnología bajo una licencia dual EUPL versión 1.1 y GNU GPL versión 3. La licencia dual ofrece la posibilidad de acogerse a los derechos que proporcionan una o ambas licencias, a su conveniencia, siempre que se cumplan las condiciones que cada una de ellas impone.
La documentación se publica bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 (CC BY-NC-SA 3.0).
El cliente está activamente mantenido por el Centro de Transferencia de Tecnología, que también alberga un entorno de desarrollo comunitario:
- Repositorio de código y documentación (SVN)
- Registro de bugs/consultas
- Listas de correo
- Foros
El B-Dienst (Beobachtungsdienst) fue una organización alemana de descifrado naval. Durante la Segunda Guerra Mundial, B-Dienst decodificó el código naval británico Cypher No. 3, proporcionando información para la Batalla del Atlántico, hasta que el Almirantazgobritánico introdujo el código de cifrado naval No. 5 el 10 de junio de 1943. B-Dienst también decodificó algunos códigos navales de la marina mercante.
B-Dienst (Marina)
Servicio Naval SIGINT de Alemania fue fundada casi por accidente durante la Primera Guerra Mundial. Operadores de radio del ejército alemán, encontrándose con poco que hacer después de que los ejércitos beligerantes se clavaron en la guerra de trincheras estática, comenzaron a buscar cualquier señal de que eran detectables. Ellos descubrieron que eran capaces de controlar el tráfico de la Marina Real de la Patrulla de Dover, la mayor parte en la clara. Esta información, pasó al Estado Mayor Naval en Berlín, que se dio cuenta de que un sistema de estaciones de vigilancia dedicados en Bélgica y Francia podría ser utilizado para fines de inteligencia. Un "Servicio de Observación"(Beobachtungsdienst o B-Dienst) fue creado para explotar esta oportunidad. Como la práctica de los mensajes de cifrado se hizo más común, el B-Dienst también desarrolló habilidades en el criptoanálisis. El servicio ha demostrado su valor al personal naval durante la guerra mediante el seguimiento de los escuadrones de cruceros británicos, salidas del convoy, y asistir en el avance de los invasores alemanes.
El final de la guerra y de la incautación y luego echar a pique de la flota casi puso fin a la marina alemana. Los recortes eliminaron la B-Dienst, pero a finales de 1919, los almirantes se dieron cuenta de que una organización de inteligencia efectiva era tan necesaria en tiempos de paz como en la guerra. El servicio, restablecido en virtud de su ex comandante Kapitänleutnant (capitán de corbeta) Martin Braune, tenía sólo seis empleados de la administración pública. Sin embargo, uno de ellos era Wilhelm Tranow, ex operador de radio naval y veterano de la guerra B-Dienst, que había demostrado su talento originalmente por romper un mensaje de alto secreto codificado enviado a su propio barco cuando sus oficiales tenían problemas para descifrarlo.
La falta de presupuesto, la rotación frecuente de sus comandantes oficial de la marina, y la falta de apoyo por parte del personal naval de nivel más alto significa que el B-Dienst luchaba por sobrevivir a los años de escasez de la década de 1920. Como medida de reducción de costos, en 1928 el servicio se trasladó a Kiel, donde tenía su sede con el Inspector de torpedos y minas, lo que limita aún más su influencia. La situación cambió en 1934, cuando una reorganización del alto mando naval trajo el B-Dienst regreso a Berlín como uno de los tres elementos de la Oficina de Comunicaciones e Inteligencia. El nombramiento de un nuevo jefe enérgico, Kapitänleutnant Heinz Bonatz, dio lugar a la incorporación de los hombres adicionales y puestos de escucha para el servicio y activar el B-Dienst para poner los equipos a bordo de los buques.
Wilhelm Tranow mantuvo ocupado durante los años 1930. Ahora la cabeza de la sección de criptoanálisis idioma Inglés nombrado lideró el ataque a los códigos y cifras de la Royal Navy, la solución de su código Naval de 5 dígitos en 1935 mediante la comparación de los mensajes codificados con los movimientos del buque mercante reportados en Informe Semanal del envío de Lloyd. El historiador David Kahn escribió más tarde "... (este) el éxito, y los atentados de 1937 en otros cuatro Inglés, cinco franceses, cuatro de Rusia y tres criptosistemas danesas ampliaron el B-Dienst. Los 30 hombres en su Central de Berlín en 1936 se convirtieron en 90 en el verano de 1939. " Monitoreo ejercicios navales extranjeras y experiencia en la Guerra Civil española añade más a la reputación de la B-Dienst.
Movilización en el inicio de la guerra se amplió el servicio. Durante los primeros académicos de tiempo y empresarios con conocimientos de idiomas fueron reclutados como oficiales de reserva, y se estableció un curso de capacitación de seis semanas. En pocos años, el B-Dienst se había expandido a más de 6.000 empleados. Una reorganización del Estado Mayor Naval en el comienzo de la guerra, seguido por una reorganización más con el nombramiento de Dönitz como Gran Almirante, dio lugar a la B-Dienst convirtiéndose en la tercera división de la cuarta rama del Comando de Guerra Marítima, la Seekriegsleitung ( es decir, 4 SKL / III, el nombre mencionado por TICOM).
La fuerte bombardeo de Berlín en noviembre de 1943, que dañó o destruyó muchas de las agencias militares y gubernamentales de Alemania, también destruyó la mayor parte de los registros del B-Dienst y los obligó a trasladarse a Eberswalde, un pequeño pueblo a unas 25 millas al noreste de Berlín. Obligado a pasar de nuevo por el avance ruso en la primavera de 1945, se dirigieron primero a Aurich, en el norte de Alemania, luego en la estación de radio naval en Neumünster, seguido rápidamente por un movimiento final a la Escuela de señales en Flensburg, donde TICOM atrapado con ellos en 17 de mayo XX.
En sus interrogatorios por parte de los aliados, el almirante Dönitz acredita el B-Dienst con que contribuye la mitad de la inteligencia operativa que la Kriegsmarine utilizado en la lucha contra la guerra. Fue un récord inigualable por cualquier otra agencia de inteligencia alemana.
El bombe era un dispositivo electromecánico usado por los criptólogos británicos para ayudar a descifrar las señales cifradas por la máquina alemana Enigma durante la Segunda Guerra Mundial. La Armada y el Ejército de los Estados Unidos produjeron máquinas con la misma especificación funcional, pero diseñadas de una manera diferente.
El diseño inicial del bombe fue producido en 1939 en el Government Code and Cypher School enBletchley Park por Alan Turing,1 con un importante refinamiento ideado por Gordon Welchman.2El diseño de ingeniería y la construcción fue el trabajo de Harold Keen de la British Tabulating Machine Company. Era un desarrollo substancial de un dispositivo que había sido diseñado en 1938 por el criptologista polaco Marian Rejewski del Biuro Szyfrów, y conocido como la Bomba criptológica (del polaco: "bomba kryptologiczna").
La función del bombe era descubrir algunos de los ajustes diarios de las máquinas Enigma en las varias redes militares alemanas: específicamente, el conjunto de rotores en uso y sus posiciones en la máquina; los ajustes de los anillos del alfabeto; y uno de los cableados delplugboard.
 
BREACH (un acrónimo de Reconocimiento de Browser y exfiltración mediante Compresión adaptable de hipertexto) es un exploit| de seguridad HTTPS cuando se utiliza la compresión HTTP. BREACH se construyó basándose en el exploit de seguridad CRIME. BREACH fue anunciado en la conferencia Black Hat de agosto 2013 por los investigadores de seguridad Angelo Prado, Neal Harris y Yoel Gluck.
Detalles
Si bien el ataque CRIME fue presentado como un ataque general que podría funcionar con eficacia contra un gran número de protocolos sólo exploits contra compresión de solicitudes SPDY y compresión TLS fueron demostradas y en gran medida mitigadas en navegadores y servidores. El exploit CRIME contra la compresión HTTP no se ha mitigado en absoluto, a pesar de que los autores del crimen han advertido que esta vulnerabilidad podría ser aún más extendida que SPDY y compresión TLS combinados.
BREACH es una instancia del ataque CRIME contra la compresión HTTP - el uso por muchos navegador web y servidores web de algoritmos de compresión gzip o DEFLATE a través de la opción de la codificación de contenido dentro de HTTP.2 Dado este oráculo de compresión, el resto del ataque BREACH sigue las mismas líneas generales que el exploit CRIME, mediante la realización de una búsqueda inicial de fuerza bruta ciega para adivinar unos pocos bytes, seguido por una búsqueda de divide-y-vencerás para expandir un acierto a una gran cantidad de contenido arbitraria.
BREACH explota la compresión en el protocolo HTTP subyacente. Por lo tanto, la desactivación de la compresión TLS no hace ninguna diferencia a BREACH, que todavía puede realizar un ataque de texto plano escogido en contra de la carga útil de HTTP.3
Mitigación
Como resultado, los clientes y los servidores están obligados, ya sea a desactivar la compresión HTTP por completo, reduciendo el rendimiento, o a adoptar soluciones elaboradas para tratar de frustrar BREACH en escenarios de ataque individuales, como el uso de protección de falsificación de petición en sitios cruzados (CSRF).4
Otro enfoque sugerido es desactivar la compresión HTTP cada vez que la cabecera indica una petición entre sitios cruzados, o cuando la cabecera no está presente.5Este enfoque permite una mitigación eficaz del ataque sin perder funcionalidad, sólo incurrir en una penalización de rendimiento en las solicitudes afectadas.
|
No hay comentarios:
Publicar un comentario