Hardware Hacking, Row Hammer y Light Eater

En la actualidad, en el mundo de la seguridad recibimos continuamente anuncios de vulnerabilidades de software y sus correspondientes actualizaciones de seguridad. Prácticamente no pasa un solo día en el que no aparezca una nueva vulnerabilidad. La gran mayoría de estas vulnerabilidades aprovechan fallos en la implementación del software para obtener por ejemplo ejecutar código, elevar privilegios, superar mecanismos de validación, obtener información, etc.

Es obvio que en el mundo de la seguridad la atención se centra las potenciales vulnerabilidades en el software, y no falta razón. No obstante, el problema radica en la creencia firme de que los dispositivos hardware que ejecutan el mismo son perfecta y completamente seguros. Nada más alejado de la realidad; el hardware está formado por multitud de bloques de circuitos interconectados que interactúan de una forma muy compleja, y es fundamental que se tenga en cuenta la seguridad en el diseño y ensamblado de los componentes.

Dentro de la cadena de fabricación de, por ejemplo, la placa base de un ordenador personal cualquiera, se emplean distintos chipset de distintos fabricantes y características, como la BIOS, los controladores de memoria, los chipset de bridge, controladores ATA, etc. Y qué decir de cuando a esa misma placa conectamos distintos dispositivos, todos ellos con sus propios componentes. Es fácil hacerse una idea de la complejidad que puede alcanzar un sistema aparentemente convencional. Por lo que, para poder “controlar” la seguridad a este nivel se deberían llevar medidas de control y verificación hasta los propios fabricantes de los dispositivos o los que los ensamblen equipos.

[Read more…]

Publicado informe de estado del arte de “Seguridad en Internet de las Cosas”

Hace unos días el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-CV) publicó un informe de “Seguridad en Internet de las cosas”, en el que podemos encontrar una guía sobre el estado del arte de seguridad sobre este tipo de dispositivos cada vez más extendidos en la red.

Básicamente, el término IoT (Internet of Things) se atribuye a un conjunto muy grande de dispositivos conectados a Internet y no son ordenadores convencionales. Pero, ¿por qué llamarlo Internet de las Cosas? Éste término se acuñó cuando el número de dispositivos superó al número personas conectadas a Internet, por lo que ya no se podía asumir que Internet estaba formado por personas interconectadas a través de sus dispositivos, sino que realmente existen dispositivos “autónomos” conectados a la red. No nos alertemos; no estamos ante una rebelión de las máquinas (todo se andará), sino de dispositivos desatendidos que se conectan a Internet con alguna finalidad como puede ser compartir información, o facilitar acceso remoto al dispositivo.

Estos dispositivos comprenden relojes, neveras, hornos, coches, sistemas de control domótico, wearables, sistemas de control de tráfico, etc. Todos hemos visto u oído hablar, e incluso disponemos de dispositivos de este tipo, pero la mayoría no somos conscientes de las implicaciones de seguridad y los riesgos potenciales a los que se enfrentan estos dispositivos, y en consecuencia las personas y organizaciones que los empleen.

Los dispositivos IoT técnicamente no son tan distintos como parece en comparación con sistemas que históricamente han poblado la red de redes, sin embargo, existen diferencias sustanciales que hacen que sea necesario un análisis pormenorizado de los riesgos o ataques que les pueden afectar.

Uno de los puntos más importantes de estas diferencias es que en general los dispositivos IoT son dispositivos empotrados, que son menos complejos que por ejemplo un ordenador personal. Esto es debido a que están diseñados con una funcionalidad específica y no con un propósito general. Se trata de sistemas más heterogéneos puesto que los fabricantes implementan sus propias soluciones, descartando en muchos casos un sistema operativo global o común como sucede con los PCs o smartphones. Esto dificulta en gran medida el establecimiento de políticas de seguridad o la gestión de actualizaciones.

Otro punto fundamental es que, en la mayoría de los casos, el problema no está en las capacidades del dispositivo, sino en las decisiones tomadas por los fabricantes respecto a las configuraciones por defecto de los mismos. En general, los dispositivos IoT no disponen de interfaz de usuario o controles, por lo que tienen que facilitar acceso a sus interfaces de administración mediante otros medios menos amigables para el usuario, por lo que la gran mayoría de ellos (los usuarios) no serán capaces de modificar la configuración de su dispositivo. Este hecho, sumado a que los fabricantes no suelen establecer una configuración de seguridad por defecto adecuada, hace que los dispositivos posiblemente mantengan una configuración potencialmente insegura.

El último de los casos a tener en cuenta es su ubicación física; estos dispositivos normalmente se encuentran altamente distribuidos, por lo que es posible que sistemas “críticos” ya no estén protegidos en un centro de proceso de datos. Este hecho hace que sean más difíciles de proteger, ya que puede ser muy sencillo obtener acceso físico a ellos, lo que entraña uno de los riesgos potenciales más graves de seguridad.

A modo de resumen, el informe publicado por CSIRT-CV aborda los siguientes apartados principales:

  • Alcance y objetivos del informe: Entorno y ámbito actuales, así como la finalidad del propio informe.
  • Riesgos asociados: Identificación de los riesgos potenciales que afectan a estos dispositivos, distinguiéndolos claramente del resto de los que se encuentran conectados a la red.
  • Vectores de ataque a las IoT: Posibles ataques o vulnerabilidades aprovechables que se podrían aprovechar para comprometer este tipo de dispositivos.
  • Recopilación de incidentes: Casos reales de incidentes de seguridad relacionados con IoT.
  • Prevención y salvaguardas: Listado de buenas prácticas para mejorar la seguridad en el uso de este tipo de dispositivos.

En la actualidad, el número de dispositivos IoT que empleamos va en aumento y se espera que la tendencia se acentúe los próximos años, especialmente los wearables, de los que no paran de surgir nuevos tipos y clases. Del mismo modo, algunos dispositivos de este tipo se están integrando en el ámbito corporativo. Este hecho supone un avance y a la vez un reto para las empresas ya que a pesar de la evolución y las ventajas puede que aportar, existe una elevada preocupación por las amenazas de seguridad que conlleva.

Por ello, debemos ser conscientes de la existencia de “Internet de las Cosas”, así como de la problemática y las recomendaciones de seguridad que se requieren para que su uso sea un avance global y no un retroceso en la seguridad, confidencialidad y libertad de las personas y organizaciones. Si el tema os ha resultado interesante os recomendamos encarecidamente la lectura de dicho informe, que os permitirá ampliar vuestros conocimientos en la materia.

El informe de “Seguridad en Internet de las Cosas” se encuentra disponible en este enlace [PDF], dentro del portal web de CSIRT-CV, y también desde su sección de descargas.

Si no tenéis nada que hacer, esta es una buena lectura para las navidades :)

Fundamentos sobre Certificados Digitales – Guía de uso seguro de Certificados Digitales

Recientemente, el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-cv), ha publicado una “Guía de uso seguro de Certificados Digitales”, esta guía vino precedida por una campaña de concienciación emitida en redes sociales. Formada por una serie de consejos de seguridad diarios, relacionados con el uso de certificados digitales. A este respecto, y dado que esta serie de entradas en Security Art Work dedicada a Fundamentos de Certificados Digitales está perfectamente alineada con los temas tratados en la guía, he considerado introducir la guía dentro de la misma serie.

Es importante destacar que, quizás un poco como contrapunto a los temas tratados en cada una de las entradas precedentes de la serie, la guía tiene una audiencia con menos orientación técnica que la que abarcan el resto de entradas, más cargadas de contenido técnico más enfocado a profesionales de TI y entendidos en la materia. Sin embargo, esto no debe desmotivar a este colectivo más avanzado, ya que posiblemente se tengan ciertos conocimientos sobre el uso de certificados digitales, aunque posiblemente no en todos los ámbitos tratados en la guía. Dicho lo propio, pasamos a la presentación de la misma.

El objetivo principal de la guía es informar y concienciar respecto del uso seguro de certificados digitales en la vida cotidiana, y su audiencia objetivo son el conjunto de los ciudadanos y empleados públicos. Dentro de ella, se facilitan conocimientos básicos de uso de certificados en las principales aplicaciones de uso habitual que tengan requerimientos específicos respecto a privacidad de la información, así como que requieran asegurar la autenticidad del remitente o tercero con el que contactamos. Todo ello tratando de ser lo más sencillo posible en las explicaciones, orientadas a su público objetivo. Destacar además que está estructurada como una guía de referencia, facilitando el acceso a los contenidos que se requieran en cada situación de forma sencilla y clara.

A modo de resumen de contenido, la guía da soluciones y recomendaciones específicas respecto a los siguientes puntos principales:

  • El DNI Electrónico: Hace unos años se produjo una modernización profunda del Documento Nacional de Identidad Español, desde entonces se ha convertido en el certificado digital obligatorio del que disponemos todos los Españoles, y que la gran mayoría desconoce.
  • Certificados de Persona Física o Empleado Público: Se trata de certificados digitales identificativos de propósito general y son emitidos por Autoridades de Certificación de confianza. Permiten identificar a su propietario telemáticamente, así como cifrar comunicaciones digitales.
  • Uso de Certificados Digitales en correo electrónico: Se incluye un dedicado al correo electrónico, el medio de comunicación de uso más difundido en Internet. Del mismo modo que cualquier medio de comunicación digital que transmite datos por redes públicas requiere que se tengan en cuenta los requisitos de seguridad pertinentes; y como suele ser habitual, centrados en la confidencialidad de la información compartida, así como la autenticidad de la misma.
  • Navegación Segura: Del mismo modo que se puede emitir un certificado digital para una persona se puede emitir un certificado para un sitio web. En este caso, el certificado garantiza identificar inequívocamente al sitio web al que nos conectamos y a su vez implementa cifrado en todas las comunicaciones entre cliente y servidor. Por tanto, se debe verificar sin lugar a la calidad y fiabilidad del certificado cuando conectamos a un sitio web que por ejemplo, maneje información sensible.
  • Firma de código: Esta capacidad permite firmar código fuente de las aplicaciones que vamos a instalar en nuestros equipos. Cuando un código no está firmado o no está firmado por una entidad de confianza corremos el riesgo de que se haya modificado fraudulentamente, y muy posiblemente pueda ejecutar acciones maliciosas en nuestros ordenadores. Cada vez que instalemos un programa deberíamos asegurar su origen, integridad y su legitimidad.
  • Firma de documentos digitales: Cuando se firma un documento digital, dicha firma tiene la misma validez que una firma manuscrita; además asegura que el documento firmado no ha sido alterado o modificado. Del mismo modo, es fundamental poder identificar la legitimidad de la firma implementada en cualquier documento.

Por último, se incluye información adicional sobre la solicitud y gestión de certificados con la Agencia de Tecnología y Certificación Electrónica de la Comunidad Valenciana (ACCV), que es una Autoridad de Certificación de reconocida confianza y opera dentro de la Comunidad Valenciana, facilitando certificados digitales reconocidos gratuitos para los ciudadanos.

Como conclusión y en mi humilde opinión, me gustaría hacer un pequeño análisis de la situación actual respecto al uso de esta tecnología. En muchas ocasiones me gusta emplear la frase “Los certificados digitales, esos grandes desconocidos…”, y esa es por desgracia la realidad, y es que la mayoría de los usuarios de medios tecnológicos e internet los usan en su vida diaria, aunque no sean conscientes. Los certificados digitales están cada día más extendidos en los servicios TI; empleándose comúnmente para asegurar la confidencialidad, autenticidad y trazabilidad de la información en la red.

Los certificados son un mecanismo muy potente y muy seguro; pero como suele pasar en la gran mayoría de los casos, por seguro que sea, si se hace un uso negligente de los mismos pueden conllevar muchos más riesgos que beneficios. No seamos alarmistas, el objetivo de la guía no es ni mucho menos asustar a la audiencia, sino ayudar a poder emplear estos mecanismos de forma segura y para ello la mejor base es conocer los riesgos a los que nos enfrentamos, pero siempre desde una óptica de confianza. De ese modo los certificados nos podrán ayudar a aprovechar todas las ventajas y servicios que nos ofrece la sociedad de la información en la actualidad con total seguridad.

La “Guía de uso seguro de Certificados Digitales” se encuentra disponible en este enlace, dentro del portal Web de CSIRT-cv, y también desde la sección de descargas de dicho portal.

Personalmente, como siempre agradecido por vuestra atención y recordaros que estamos a vuestra disposición desde Security Art Work.

Un saludo a todos. Os deseo un feliz y seguro verano.

Fundamentos sobre Certificados Digitales – El estándar X.509 y estructura de certificados (II)

Siguiendo con la entrada anterior, que hablaba del estándar X.509 que define la estructura del certificado; nos quedaba pendiente revisar los campos fundamentales que componen el bloque de tbsCertificate, dentro de la estructura de X.509.

Este bloque contiene la información fundamental de la PKI, como emisor, suscriptor, caducidades, etc. Se detallan los campos más relevantes a continuación:

  • Version: Especifica la versión del protocolo X.509 con la que se ha construido el certificado, por ejemplo, si el certificado contuviera extensiones este campo debería contener inequívocamente el valor ‘3’.
  • Serial Number (Número de Serie): Se trata de un número entero positivo que puede asignar la CA y que le permitirá identificar el certificado digital. Por lo tanto este identificador deberá ser único para cada certificado dentro de una cadena de confianza. Lo habitual es que se trate de números de módulo largo, lo que asciende a 20 octetos.
  • Signature Algorithm Identifier (Identificador del Algoritmo de Firma): Este campo contiene necesariamente el algoritmo de cifrado empleado para generar la firma del suscriptor. Debe ser necesariamente el mismo que el que se emplea en la firma de validación de la cadena de confianza. Adicionalmente se consideran extensiones opcionales para este campo, que dependerán directamente del algoritmo de cifrado empleado.
  • Issuer (Emisor): Este campo contiene información respecto a la Autoridad de Certificación que ha emitido el certificado digital, fundamentalmente del certificado de CA subordinada que se ha empleado para generar el certificado final. Concretamente cuenta con estos campos (para facilitar la legibilidad de la entrada nos centramos en los de mayor importancia y de uso más extendido):
    • country: País donde su ubica la CA.
    • organization: Nombre establecido para la CA.
    • organizational unit: Campo definido para la unidad organizativa del certificado, se suele definir con un identificador de la finalidad del certificado o el departamento encargado de generarlo.
    • state or province name: Nombre de estado o provincia, dependiendo de la organización del país en el que se ubica la CA.
    • common name (CN): Se define como nombre común, y se define normalmente como el common name del subject del certificado de subordinada que se ha empleado para firmar el certificado.
    • Locality: Ciudad donde se ubica la CA.
    • NOTA: Los campos title, surname, given name, initials, pseudonym o generation qualifier, se definen también para el campo de emisor, aunque no se suelen emplear cuando quien emite el certificado es una CA (como podéis ver carecen de sentido para una entidad jurídica).
  • Validity: Se trata de un campo fundamental dentro del mecanismo de uso de una PKI. Es el tiempo que se compromete la Autoridad de Certificación a disponer de información sobre la validez del certificado, lo que se traduce en consecuencia que este campo establece la vida útil del certificado. Se puede codificar empleando dos mecanismos UTCTime y GeneralizedTime.
  • Subject (Suscriptor): Campo que incluye los datos del suscriptor (o usuario final) del certificado, por lo que va directamente asociado a la clave pública contenida en el mismo certificado. Del mismo modo que en el caso anterior, nos centramos en los campos fundamentales y de uso más extendido, habiendo una especificación muy extensa de posibles campos para este punto:
    • Common name: Nombre asignado al certificado en concreto, depende mucho del tipo de certificado que se trate, por ejemplo en un certificado SSL lo habitual es incluir el nombre del dominio que emplea el certificado, en caso de certificados de firma suele emplearse el nombre completo de la persona.
    • Serial number: Número de serie identificativo que se emplea para identificar inequívocamente un certificado emitido, este número debe ser único para cada certificado dentro de una CA.
    • GivenName: Nombre propio de la persona en el caso de certificados personales.
    • SurName: Apellidos de la persona para certificados personales.
    • Organization unit: Puede hacer referencia al uso del certificado, o a la finalidad de la rama de la jerarquía de certificación empleada (o CA subordinada).
    • Organization: Este caso es común al campo Issuer, ya que se suele poner el identificador de la CA emisora.
    • Country: País de emisión del certificado.
  • Subject Public Key Info: Campo definido para contener la clave pública del certificado, así como para identificar el algoritmo de cifrado empleado para su generación.

Para finalizar con la descripción de la estructura de un certificado empleando X.509, pasamos a detallar las principales extensiones empleadas en los certificados comerciales. Es importante destacar que estos campos son completamente opcionales. Son los siguientes:

  • Authority Key Identifier: Campo que se emplea para identificar inequívocamente a la autoridad de certificación.
  • Subject Key Identifier: Campo que se emplea para identificar inequívocamente al suscriptor.
  • Key Usage: Especifica cuales son los usos válidos para el certificado, como por ejemplo si se puede emplear para firmar o para cifrar.
  • Certificate Policies: Define la ubicación e identificación de la Política de Certificado definida para la subordinada que ha generado el certificado (Más información sobre Políticas de Certificación y Declaraciones de Prácticas de Certificación en esta entrada y en esta otra, ambas pertenecientes a esta serie).
  • Basic Constraints: Incluye información muy importante como si el certificado es de CA, lo que permitiría que el certificado se empleara para firmar otros certificados.
  • CRL Distribution Points: En esta extensión se detalla la ruta del enlace donde se pueden obtener las Listas de Revocación de Certificados (CRL) correspondientes a la subordinada que emite el certificado final, de este modo se puede automatizar la consulta de las mismas cuando se consulta el certificado.
  • Authority Information Access: Del mismo modo que en el caso anterior, en esta extensión se mantiene la ruta de acceso al servicio de validación OCSP de la CA, facilitando también la automatización de la validación pudiendo obtener dicha información del propio certificado.

Con esto ya hemos revisado la estructura y principales campos de la implementación X.509 de certificados digitales. Gracias por leernos, espero que la entrada os haya resultado de utilidad, espero vuestros comentarios.

Enlaces adicionales:
http://www.ietf.org/rfc/rfc5280.txt

Fundamentos sobre Certificados Digitales – El estándar X.509 y estructura de certificados

En esta entrada, dentro de nuestra serie dedicada a Certificados Digitales, nos vamos a centrar en la estructura e implementación de los certificados.

Creo que antes de comenzar es preciso realizar una aclaración, sé que hemos estado hablando continuamente de certificados, la tecnología criptográfica que emplean, la gestión que realizan de ellos las autoridades de certificación, los dispositivos hardware para gestión de claves criptográficas, etc. Por otra parte, también hemos hablado de el establecimiento, normativa y responsabilidades de una CA, así como de los servicios que prestan. Sin embargo, aún no hemos hablado de la implementación de los certificados, es decir, como se construyen y que formatos estructurales tienen. Este punto es el objeto de la presente entrada.

Para definir y establecer el contenido y estructura que debe tener un certificado digital se establece el estándar conocido normalmente como X.509, aunque su nombre completo es “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, definido por el “Network Working Group” y definido en la RFC 5280. El estándar surgió originalmente en el año 1988, aunque la última versión vigente, X.509 v3, se aprobó en 2008.

La principal motivación de la definición de este estándar es la implementación de una Infraestructura de Clave Pública (en adelante PKI). Este hecho es fundamental, y es lo que distingue inequívocamente una clave criptográfica de un certificado digital. Las claves definidas por RSA únicamente son secuencias que permiten realizar el cifrado y descifrado de información, sin embargo el estándar X.509 establece parámetros para identificar al propietario del certificado, a su emisor (la autoridad de Certificación), fechas de emisión, caducidad, etc. Lo que nos lleva a pensar que sin este estándar nos resultaría imposible usar los certificados para, por ejemplo, firmar un documento electrónico.

Adicionalmente, este estándar también marca las directivas para la implementación de los mecanismos de validación que permiten a los usuarios de los certificados comprobar su validez en cualquier momento (más información sobre mecanismos de validación en anteriores entradas de este blog). Además, considera los conceptos de validación, rutas de certificación, revocación, etc. Esto nos da a entender que sin la definición de este estándar sería imposible establecer y operar una PKI.

Nos vamos a centrar en la especificación de la estructura y campos de un certificado digital, que se define fundamentalmente en el apartado 4 de la RFC. De forma gráfica, se muestra la estructura del certificado en la siguiente ilustración, diferenciando los campos que han sido incluidos a lo largo de las modificaciones incluidas en las diferentes versiones de X.509:

En la figura se muestra un orden de campos destinado a identificar los cambios en las versiones, sin embargo, estos campos se organizan categóricamente en tres grupos principales, que son los siguientes:

  • tbsCertificate: Este campo contiene la información de emisor, sujeto, y periodo de validez así como información adicional de interés.
  • signatureAlgorithm: Este campo contiene la información para identificar inequívocamente el algoritmo criptográfico que ha empleado la CA para firmar el certificado, además contiene campos opcionales que serán empleados dependiendo del tipo de algoritmo criptográfico empleado.
  • signatureValue: Este campo contiene, como su nombre indica, el contenido de la firma del certificado, este campo es el que asegura mediante la firma de la CA que toda la información contenida en el campo tbsCertificate es legítima. Lo que supone básicamente que implementa la cadena de confianza del certificado (más información sobre cadena de confianza esta entrada anterior dentro de Fundamentos de Certificados Digitales).
  • Extensiones: Las extensiones son un conjunto de campos y parámetros opcionales que se pueden añadir al certificado, aunque no son imprescindibles. Estos puntos se añadieron en la versión 3 de X.509. Repasaremos las de mayor uso e importancia en la presente entrada.

Con esto es todo en esta entrada, en breve una nueva entrada con un detalle completo de los campos fundamentales de tbsCertificate. Muchas gracias por seguirnos, como siempre quedo a la espera de vuestros comentarios.

Fundamentos sobre certificados digitales – Declaración de Prácticas de Certificación (II)

Siguiendo con la entrada relacionada con las Declaraciones de Políticas de Certificación, nos queda pendiente detallar el contenido de la RFC 3647.

El documento está estructurado en distintos puntos, en los que se describe la finalidad del mismo, definiciones y comparativas con el estándar anterior (RFC 2527), entre otros. El punto más importante de la misma, y sobre el cual deberíamos centrar nuestra atención es el que describe la especificación de la estructura que debe seguir una CPS; el apartado 4. Se pasa a detallar a continuación los puntos principales de la especificación, junto a una pequeña descripción de los mismos:

  • 1 – Introducción: En este punto se describen principalmente los datos de la CA, datos concretos de identificación del documento, implicados en la infraestructura de la PKI, condiciones de uso de los certificados, etc.
  • 2 – Publicación de información y repositorio de certificados: Se detalla información respecto al repositorio de información y certificados; dicha información abarca su ubicación, frecuencia de actualización, controles de acceso aplicados, etc.
  • 3 – Identificación y Autenticación: Se debe describir el mecanismo empleado para la identificación de los usuarios y los certificados; así como las restricciones aplicables. Adicionalmente se establecen los mecanismos de validación inicial, con validación se entienden las comprobaciones previas a realizar antes de expedir, renovar o revocar un certificado digital, sea del tipo que sea, para asegurar la identidad del suscriptor.
  • 4 – Ciclo de Vida de los Certificados: En este punto se detallan todas las medidas o tratamientos establecidos para el tratamiento de los certificados digitales en cualquier punto de su vida; desde la emisión, renovación, revocación, modificación, comprobación de estado, etc.
  • 5 – Controles de Seguridad Física, Gestión y Operaciones: En este apartado se detallan las medidas de seguridad aplicadas en el entorno de la CA, concretamente se establecen las siguientes categorías:
    • Controles de Seguridad Física
    • Controles sobre Procedimientos
    • Controles de Seguridad del Personal
    • Controles de Registro de Seguridad
    • Controles sobre Archivo de Información
    • Cambio de Clave
    • Controles en caso de Compromiso de la Clave y Recuperación ante Desastres
    • Finalización de la Actividad de la CA

  • 6 – Controles de Seguridad Técnica: En este punto pasamos de centrarnos en controles del entorno de la CA, ahora se realiza una especificación formal de las acciones o medidas tomadas durante el tratamiento de la claves, dispositivos criptográficos empleados, etc.
  • 7 – Certificados, OCSP y CRL: Se establece el perfil del certificado, con perfil de certificado entendemos que se establece exactamente que campos debe contener el mismo, así como que campos son variables dependiendo del suscriptor. Así mismo se establecen los requisitos y configuración de los servidores de validación OCSP y CRL (estos mecanismos se describieron en detalle en otra entrada de la serie, concretamente en la que se refiere a Mecanismos de Validación de Certificados).
  • 8 – Auditorías de Cumplimiento: En este caso, se describen las prácticas de auditorías de cumplimiento que se han establecido para la CA, las condiciones y periodos en los que se realizará la auditoría, así como la cualificación del personal encargado de su realización.
  • 9 – Requisitos Comerciales y Legales: Por último, este punto agrupa desde requisitos legales y comerciales. Lo que incluye desde tasas por la emisión de certificados, medidas concretas sobre datos de carácter personal, responsabilidad financiera en caso de desastre, etc.

Como se puede ver, y como para más de uno que esté familiarizado con la gestión de seguridad de la información, esta especificación tiene en cuenta muchos puntos en común con estándares generalistas de seguridad como ISO 27001; aunque se incluyen más requisitos concretos y propios del tipo de actividad (como la gestión del ciclo de vida del certificado). Hay que entender que una CA es un entorno de muy alta criticidad, ya que si se vulnerara una clave de la misma, podría afectar a gran cantidad de personas o organizaciones; pudiendo llegar a graves perjuicios económicos en las mismas.

Con esto es todo para esta entrada, a modo de ampliación de información os dejo un enlace a una CPS de una Autoridad de Certificación Nacional, la cual se ha construido siguiendo los estándares marcados por la RFC 3467.

Más sobre certificado digital e infraestructura de PKI en próximas entradas. Como siempre, muchas gracias por leernos.

CPS Agencia de Certificación de la Comunidad Valenciana (ACCV) – http://www.accv.es/fileadmin/Archivos/Practicas_de_certificacion/ACCV-CPS-V3.0.pdf

Fundamentos sobre certificados digitales – Declaración de Prácticas de Certificación

En esta entrada dentro de la serie de Fundamentos sobre Certificados Digitales nos vamos a centrar en uno de los requisitos fundamentales a tener en cuenta por cualquier Autoridad de Certificación (CA). Este requisito no es una opción, sino una obligación establecida para cualquier normativa o legislación aplicable relativa a la generación y tratamiento de certificados digitales. Estamos hablando de las Declaraciones de Prácticas de Certificación y de las Políticas de Certificación. Como siempre, vayamos paso a paso.

Una Declaración de Prácticas de Certificación (CPS) es un documento propio de cada CA en el que se declaran y establecen un conjunto de compromisos que adquiere la entidad respecto las prácticas para la gestión del ciclo de vida de los certificados digitales que emite, así como un conjunto de medidas de seguridad del entorno. Este documento es en sí un compromiso adquirido, que se referencia al mismo en todos los certificados emitidos en un campo establecido a tal efecto (en próximas entradas detallaremos la estructura estándar de los certificados).

Por otro lado, una Política de Certificación (CP) es del mismo modo un conjunto de compromisos adquiridos por la CA con los usuarios de sus certificados, aunque en este caso, este documento únicamente hace referencia a un tipo concreto de certificados dentro de la jerarquía. Por tanto la Política de Certificación únicamente afecta a una tipología concreta de certificado de CA Subordinada (este concepto se explica de forma detallada en otra de las entradas de esta serie, concretamente la que hace referencia a Cadena de Confianza). Este mecanismo le facilita a la CA la capacidad de establecer unas directivas de certificación globales y comunes mediante la Declaración de Prácticas de Certificación, así como la posibilidad de establecer requisitos concretos para tipos de certificado concreto cuando proceda.

Es importante destacar que en ningún caso es una obligación la implementación de Políticas de Certificación, por lo que se deja a elección de la CA su implementación en base a sus requisitos y necesidades.

El siguiente punto a abordar será, evidentemente, establecer o identificar los contenidos y requisitos que deben cumplir estos documentos. A este respecto, y comenzando por el ámbito Español, la Ley de Firma Electrónica (Ley Orgánica 59/2003) en uno de sus artículos menciona la obligación de construir y mantener publicada en un medio gratuito una Declaración de Prácticas de Certificación. Se puede obtener más información de la presente ley en pasadas entradas de esta serie Ley de Firma Electrónica I y II. Según dicho texto, el documento que debe cumplir al menos con los siguientes requisitos:

  • Obligaciones del Prestador de Servicios de Certificación (CA) respecto a los datos de creación y verificación de la firma o certificados expedidos.
  • Condiciones para la solicitud, expedición, uso, suspensión y extinción dela vigencia de los certificados.
  • Medidas de seguridad técnica y organizativa.

  • Roles y responsabilidades del personal implicado en el servicio.
  • Condiciones y acceso a mecanismos de información sobre la vigencia de los certificados.

Como último punto determinante, se establece que las Declaraciones de Prácticas de Certificación tendrán validez como Documento de Seguridad en el ámbito de la Ley Orgánica de Protección de Datos de Carácter Personal (Ley Orgánica 15/1999). Sin embargo, y como a más de uno le puede haber parecido, esta especificación es muy generalista, por lo que para alguien que no tenga experiencia en la confección de este tipo de documentos dentro del ámbito de la constitución de una CA puede llegar a ser muy complicado y ambiguo.

Adicionalmente a los requisitos legales establecidos en España, a nivel internacional se han establecido distintos estándares destinados a establecer requisitos mínimos de calidad y seguridad en la implementación y operación de una Infraestructura de Clave Pública (PKI), así como del establecimiento de una CA. Para el caso que nos ocupa, la confección de una Declaración de Prácticas de Certificación, se han establecido diversos estándares, se destacan los siguientes:

  • RFC 3467 y RFC 2527: Estos documentos llamados RFC, establecen una guía estricta de los puntos que debe contener una Declaración de Prácticas de Certificación. El primero de ellos, la RFC 3467, se incluye dentro del denominado “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”, propuesto por el “Network Working Group”. Relata con un elevado nivel de detalle los contenidos y estructura que debe tener el documento, y se considera un estándar internacional para la construcción de CPS. El segundo de ellos (RFC 2527) es una versión anterior de la RFC 3467, de los que únicamente se identifican algunas modificaciones.
  • WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria: Del mismo modo que en el caso anterior, la especifiación establece un guión cerrado para los contenidos de una Declaración de Prácticas de Certificación, aunque en este caso se ha establecido por organismos distintos. Concretamente, los responsables de esta especificación son dos organismos estatales en primer lugar el “Canadian Institute of Chartered Accountants” (CICA), y en segundo lugar el “American Institute of Certified Public Accountants” (AICPA). A su vez, es importante destacar que estos organismos son responsables del estándar Webtrust, que marca directivas para la implantación de controles en las CA que regulan desde el ciclo de vida de los certificados digitales hasta las medidas de seguridad a aplicar en su entorno; entre otros puntos.

Nos vamos a centrar en la especificación establecida por la RFC 3467, que en mi humilde opinión, es la de uso más extendido en lo que a CPS se refiere. Dado que se trata de una especificación muy detallada y concreta, se va a abordar a grandes rasgos; así como finalmente, y con el fin de completar la información de esta entrada, se propondrá la lectura (o al menos el repaso), de un ejemplo real de Declaración de Política de Certificación. La especificación de la RFC 3467 se encuentra publicada en el siguiente enlace:

http://www.ietf.org/rfc/rfc3647.txt

En la próxima entrada detallaremos a grandes rasgos el contenido de la RFC, así como mostraremos un ejemplo real de CPS. Muchas gracias por leernos.

Fundamentos sobre Certificados Digitales: Normativa y Legislación propia de Autoridades de Certificación en España (2ª parte)

Seguimos con el análisis de la Ley de Firma electrónica que nos quedó pendiente de la anterior entrada de esta serie (Entrada previa: “Fundamentos sobre Certificados Digitales: Normativa y Legislación propia de Autoridades de Certificación en España (1ª parte)”).

Pasando ya al Título III, está centrado en la regulación de la actividad de los prestadores de servicios de certificación digital, distinguiendo entre las obligaciones requeridas para las autoridades de certificación consideradas reconocidas y las que no; así como la responsabilidad aplicable en cada caso.

El primero de los puntos destacables de este título lo constituyen las obligaciones propias de este tipo de entidades. Se detalla cada uno de los puntos de interés junto a un pequeño resumen a continuación:

  • Protección de Datos de Personales: Los prestadores de servicios de certificación están obligados a cumplir con los requisitos necesarios en amparo de la Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal (en adelante LOPD), así como a su reglamento de desarrollo (Real Decreto 1720/2007) dentro de sus atribuciones y funciones como CA. Adicionalmente, se complementa lo contenido en esta legislación con algunos matices:
    • Los datos de carácter personal que se recopilarán para la emisión del certificado, sea cual sea el nivel de seguridad requerido por la LOPD, se deberán recopilar solicitando el consentimiento expreso al afectado.
    • En ningún caso se incluirán dentro del propio certificado datos especialmente protegidos por la LOPD (Artículo 7 de la misma).
  • Obligaciones de los prestadores de servicios de certificación: En este artículo se fijan las obligaciones comunes a todas las CA, se detallan algunas de ellas a continuación:
    • No almacenar ni copiar cualquier dato relacionado con los certificados expedidos.
    • Facilitar de forma gratuita al solicitante una información mínima previamente a la expedición del certificado (Como las obligaciones del firmante, las condiciones de uso del certificado, etc.).
    • Mantener un directorio actualizado con todos los certificados expedidos, así como su estado de vigencia.
    • Mantener disponible un mecanismo de Validación de Certificados.
  • Declaración de Prácticas de Certificación (DPC): Todo prestador de servicios de certificación deberá emitir una Declaración de Prácticas de Certificación. La declaración de prácticas de certificación debe estar publicada en un medio gratuito y a disposición pública, así como se considerará el documento de seguridad de la CA de acuerdo a lo dispuesto en la LOPD. Así mismo, se detalla el contenido indispensable que debe incluir la DPC, como por ejemplo las obligaciones asumidas con los datos empleados para la creación, las condiciones de uso de los certificados, los mecanismos de validación publicados, etc. La estructura habitual de las declaraciones de prácticas de certificación serán objeto de próximas entradas de esta serie.
  • Obligaciones de los prestadores de servicios de certificación reconocidos: Adicionalmente a los requisitos comunes a todas las los prestadores de servicios de certificación nacionales, se añaden los siguientes requisitos:
    • Demostrar fiabilidad para prestar servicios de certificación.
    • Mantener un registro con fecha y hora exactas de expedición de certificados, así como para su extinción o suspensión.
    • Emplear personal cualificado en seguridad y gestión de servicios de de certificación electrónica.
    • Emplear dispositivos y sistemas criptográficos fiables para los procesos de certificación que soporten.
    • Tomar medidas contra la falsificación de certificados, asegurando la confidencialidad de la información durante todo el proceso de generación y entrega de los mismos.
    • Mantener en un medio seguro todos los datos y documentación requeridos para la generación y gestión de los certificados, así como las Declaraciones de Prácticas de Certificación vigentes en cada momento en un plazo mínimo de 15 años desde su expedición.
    • Emplear sistemas seguros para almacenar los certificados reconocidos, de modo que se pueda certificar su autenticidad si fuera necesario, impidiendo accesos y modificaciones no autorizadas.
    • Por último, todos los prestadores de servicios de certificación reconocidos deberán suscribir un seguro de responsabilidad civil por una cuantía de cómo mínimo 3 millones de euros, para afrontar el riesgo de daños y perjuicios que puedan ser causados por los certificados expedidos.
  • Cese de actividad: Cuando un prestador de servicios de certificación decida cesar su actividad deberá notificarlo a todos los suscriptores (personas físicas o jurídicas) que posean un certificado expedido por dicha entidad. Adicionalmente, y para los certificados que aún tengan vigencia, puede ofrecer transferir su gestión a otro prestador de servicios, siempre con el consentimiento expreso del suscriptor. Se deberá realizar la comunicación de cese con al menos dos meses de antelación. En caso de que no se acuerde una transferencia de certificados, será el Ministerio de Ciencia y Tecnología el encargado de mantener mecanismos de validación de certificados necesarios hasta que expiren.

El segundo gran punto del título hace referencia a la responsabilidad de los prestadores de servicios de certificación. Se resumen brevemente los puntos considerados:

    Responsabilidad de los Prestadores de Servicios: Principalmente, y como resumen, los prestadores de servicio responderán de todos los daños y perjuicios que puedan causar mientras ejercen su actividad. Concretamente, también se les insta a cubrir los daños causados a los suscriptores o terceros por la ausencia o indisponibilidad de los mecanismos de validación de certificados requeridos.
    Limitaciones en la responsabilidad de los Prestadores de Servicio: En este artículo se exime de la responsabilidad al prestador de servicios en casos concretos como, por ejemplo, si cuando se emite el certificado no se ha facilitado información real o completa, o cuando el suscriptor gestiona negligentemente el certificado.

El siguiente punto a tratar es el Título IV, y hace referencia a los dispositivos de creación, y verificación de firma; así como la propia certificación de los propios prestadores de servicios de certificación y la propia certificación de los dispositivos.

En esencia, se requiere el uso de dispositivos criptográficos seguros; este punto se trató en mayor detalle en otra entrada de esta serie “Fundamentos sobre certificados digitales (V) – Dispositivos físicos para gestión y custodia de claves”; donde se tuvieron en cuenta requisitos más restrictivos a los impuestos en esta ley, como los propuestos por el estándar FIPS-130.

Respecto a la certificación de entidades, especifica que la certificación es completamente voluntaria, y deberá llevarse a cabo por una entidad de certificación reconocida. Esta certificación no se requiere, pero puede servir al prestador de servicios para demostrar buenas prácticas aplicadas en la gestión de los certificados digitales.

El Título V hace referencia a la supervisión y control. En este punto se establece que todo prestador de servicios de certificación será controlado directamente por el Ministerio de Ciencia y Tecnología, de modo que podrá realizar las inspecciones necesarias para poder ejercer dicho control. Del mismo modo, y si lo considerara oportuno, el ministerio podría recurrir a terceros independientes y técnicamente cualificados para asistirles en dichas revisiones.

Adicionalmente, el título establece la obligación de informar y colaborar del prestador de servicios de certificación con el Ministerio de Ciencia y Tecnología con toda la información y colaboración necesarias para el desempeño de sus funciones (acceso total a instalaciones, información y documentación).

Por último, el Título VI hace referencia a infracciones y sanciones, estableciendo una clasificación como muy graves, graves y leves; fijando cuantías de las sanciones para cada una de estas tipificaciones. No se entra en detalle de esta sección por considerarse menos relevante para la finalidad del artículo, se refiere a la propia ley para más información.

Para finalizar y como aclaración, en ningún caso la intención de la presente entrada es contener todas las regulaciones incluidas en la Ley de Firma Electrónica, sino dar una idea de cuáles son los principales requisitos y normativa destinada a regular este tipo de actividad en España, así como informar a los usuarios de los servicios de las fuentes de información a su disposición y las obligaciones del prestador de servicio y suscriptor. En caso de que se desee implementar y certificar una Autoridad de Certificación, se refiere directamente al texto literal de la ley. Muchas gracias por leernos como siempre, próximamente nuevas entradas.

Enlaces de Complementarios:
Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal
Real Decreto 1720/2007 de Desarrollo de la Ley Orgánica de Protección de Datos de Carácter Personal

Fundamentos sobre Certificados Digitales: Legislación propia de Autoridades de Certificación en España (1ª parte)

Ya hemos recorrido gran parte de los puntos fundamentales a tener en cuenta para la constitución e implementación de una Autoridad de Certificación (en adelante CA), y a pesar de que una CA es básicamente técnica, es fundamental tener en cuenta cuáles son los requisitos legales y normativos propios para cada uno de los tipos y usos previstos. Así como para implantar y certificar el nivel de confianza objetivo.

Si existen unos requisitos fundamentales e ineludibles para establecer una CA en España, son los establecidos por la Ley de Firma Electrónica. Daremos un repaso a su contenido destacando los puntos de mayor importancia o interés para los usuarios o para cualquiera que esté considerando crear una Autoridad de Certificación en España.

Es evidente que en cada país se establecerán requisitos distintos, basados en legislación o normativa propia en cada caso, así como existen estándares aceptados internacionalmente y por las compañías. En España, la ley establece los requisitos y regula el cumplimiento de los mismos es La Ley 59/2003, denominada Ley de Firma Electrónica. Esta ley surge como una modificación de una ley previa para el uso de Certificados Digitales y gestión de Autoridades de Certificación (Real Decreto Ley 14/1999).

Dentro de los puntos clave del texto vigente es que incluye, como cambio de mayor trascendencia respecto al texto anterior, otorgar la misma validez funcional a la firma electrónica y la firma manuscrita. Este hecho es determinante, ya que es un incentivo para el uso de la firma electrónica para la realización de trámites oficiales, así como abre la posibilidad del establecimiento de contratos, obligaciones y compromisos validados empleando firma digital. Para que se pueda considerar dicha equivalencia, la ley especifica qué únicamente será equivalente a una firma manuscrita un certificado reconocido, así como establece los requisitos para que un certificado se considere reconocido. Por lo que este tipo de certificados deben haber sido expedidos garantizando una serie de requisitos específicos de contenido, tratamiento de los mismos, las garantías prestadas por la CA que los emite y la jerarquía de certificación a la que pertenezca (Más información en: “Fundamentos sobre certificados digitales (III): Cadena de confianza”).

Otro punto fundamental de la ley es la regulación del uso del DNI Electrónico, fijando el marco para su uso. Gracias a esta ley, hoy el DNI Electrónico se puede emplear para realizar trámites con la administración, así como para poder firmar cualquier documento digital; en esencia, el DNI electrónico implementa y contiene un certificado digital de persona física reconocido.

Por último, y antes de comenzar con un resumen de los puntos más importantes de su contenido, en esta revisión del texto legislativo se consideran también certificados de persona jurídica, sin hacer perder valor a los certificados de persona física que puedan emplear como representantes de una entidad.
Es importante destacar que en el análisis de la legislación se referirá a la Autoridad de Certificación indistintamente como CA o prestador de servicios de certificación, así como se referirá a los propietarios de los certificados como suscriptores o como solicitantes si aún no han obtenido el certificado.

Una vez introducidos en la temática y siendo conscientes de la finalidad y principales modificaciones establecidas por la Ley, se procede a detallar los requisitos fundamentales de la misma siguiendo su estructura. La ley se distribuye en 6 títulos principales, que se resumen a continuación:

  • Título I: Disposiciones Generales
  • Título II: Certificados Electrónicos
  • Título III: Prestación de Servicios de Certificación
  • Título IV: Dispositivos de Firma Electrónica y Sistemas de Certificación de Prestadores de Servicios de Firma Electrónica y Dispositivos de Firma Electrónica
  • Título V: Supervisión y Control
  • Título VI: Infracciones y Sanciones

Se va a proceder a resumir los puntos de fundamentales o de mayor interés contenidos en cada uno los títulos de la Ley con el fin de ilustrar a grandes rasgos sus requisitos.

En el Título I, se describe el ámbito y objeto de aplicación de la ley; así como el contexto de interacción entre CA y administraciones públicas y los medios de acceso de la administración en estos casos. El ámbito de esta ley regula el uso de la firma electrónica, su validez jurídica y a los prestadores de servicios de certificación que desempeñen su actividad en España. En este título se aprovecha también para definir términos como firma electrónica y sus variantes, como la firma electrónica reconocida. Otra definición de importancia es la de documento electrónico, que se define como un documento firmado digitalmente; detallando los soportes y formatos aceptados jurídicamente. Adicionalmente, en el presente título se detalla el uso de certificados en administraciones públicas, así como las condiciones generales para la prestación de servicios de certificación en territorio Español.

Pasando al Título II, se establece quien puede ser titular de un certificado digital, así como se establecen detalles sobre su vigencia; por otro lado, en su segundo apartado se detalla la regulación de certificados reconocidos como un subconjunto de mayor confianza sobre todos, y en su tercera se fijan las características del DNI Electrónico. Entrando en detalle, se distingue entre certificado digital y firmante, siendo este último la persona que posee el dispositivo de firma, y actúa en nombre propio o representación de una persona o entidad jurídica.

Uno de los puntos más importantes del título son las especificaciones concretas respecto a los certificados digitales de persona jurídica, entrando en detalles como quién los puede solicitar, quién es la persona física responsable de su custodia, así como el método para establecer limitaciones sobre su uso. Adicionalmente, se detallan los motivos para la extinción de la vigencia o suspensión de la vigencia de un certificado, así como las circunstancias que deben producirse o los organismos que lo pueden solicitar. Se entiende como extinción de la vigencia una retirada del certificado forzada, teniendo en cuenta factores como órdenes judiciales, uso indebido, caducidad o constancia de que se haya podido vulnerar el certificado. La vigencia máxima para un certificado digital amparado por la presente ley será de 4 años, y se deberá ajustar dicha duración según el uso previsto y la tecnología empleada (como por ejemplo los algoritmos criptográficos empleados, más información en otra entrada de esta serie: “Fundamentos sobre certificados digitales (VI) – Algoritmos Criptográficos”). En cualquier caso el prestador de servicios deberá dar constancia de la revocación del certificado en los medios a su disposición, de modo que cualquier tercero pueda estar al tanto de su estado (Más información en: “Fundamentos sobre certificados digitales (IV): Mecanismos de validación de certificados”).

El segundo de los puntos más importantes es el establecimiento de los requisitos necesarios para considerar un certificado como reconocido. A grandes rasgos, un certificado digital reconocido deberá cumplir las siguientes condiciones:

  • Debe ser un certificado emitido por una CA que cumpla con todos los requisitos de la Ley que nos ocupa.
  • El certificado deberá contener al menos cierta información, entre la que destaca un código identificativo único, la identificación del prestador de servicios que lo expide, acceso al mecanismo de validación del certificado, o fecha de inicio y final de la validez del certificado.

Además, se definen las comprobaciones que debe realizar la CA antes de emitir un certificado reconocido, así como las acciones a llevar a cabo para validar la identidad y circunstancias de los suscriptores de los certificados. Por ejemplo se debe imponer la obligación de que el suscriptor se persone físicamente y se realice una validación de su Documento Nacional de Identidad para la emisión del certificado. La validación de los suscriptores será objeto de futuras entradas de esta serie.

El último punto de este título hace referencia al DNI Electrónico, estableciendo su validez como certificado de confianza; lo que implica la obligación de cualquier entidad pública o privada a aceptar la validez de los datos personales que en él constan, de la identidad del remitente, así como la integridad del mensaje firmado con el mismo.

Espero que la entrada os esté resultando interesante, próximamente seguimos con la segunda parte de la misma, en la que se finalizará la revisión de los puntos más importantes de la Ley de Firma Electrónica. ¡Gracias por leernos!

Enlaces de Complementarios:
Ley 59/2003 de Firma Digital
Real Decreto Ley 14/1999 de Firma Electrónica

Fundamentos sobre certificados digitales (VI) – Algoritmos Criptográficos

En nuestra entrada respecto a certificados digitales de este mes, nos vamos a centrar en un punto crítico dentro de la infraestructura de una PKI. Este tema se ha ido comentando leve y superficialmente en anteriores entradas; sin embargo, se trata de uno de los puntos más importantes que está afecta directamente con los propios a la construcción de los propios certificados y tiene una dependencia directa con la robustez de los mismos; este punto es el referente a algoritmos criptográficos.

Como introducción y a modo de repaso, un certificado digital no es ni más ni menos que un par de claves de criptografía asimétrica que, empleando las propiedades de las mismas, permiten identificar inequívocamente a una persona, entidad o website (en el caso de certificados SSL). Más información y detalle de esto en la entrada Fundamentos sobre certificados digitales I y II.

Las claves criptográficas se generan empleando algoritmos criptográficos, lo que propicia como ya se comentó, que cada clave empleada y cualquier información cifrada están directamente relacionadas mediante una relación matemática. Esto significa que siempre se conoce el método para obtener la clave privada correspondiente a una clave pública y viceversa (disponiendo de mensajes cifrados con las mismas). Entonces, ¿que impide a un tercero obtener la clave privada de alguien?, ¿cómo se puede asegurar la identidad de alguien únicamente basándonos en que posea una clave privada que aparentemente no es segura?

Los algoritmos de cifrado aprovechan operaciones que son sencillas de aplicar y que son extremadamente complejas de deshacer. Entiendo que este hecho es difícil de comprender, pero está directamente relacionado con la tecnología de cómputo actual y los métodos numéricos a nuestra disposición. Me explico: aunque el cómputo sea conocido y realizable, el hecho determinante es si se dispone de un método de resolución lineal y los mismos están implementados en hardware. Sin embargo, en los algoritmos de cifrado se aprovecha el hecho de que, con la tecnología y conocimiento existente en el momento en el que se diseñan, el tiempo de cómputo necesario para realizar las operaciones que permiten obtener una de las claves basándonos en la otra es, con mucho, más complejo que el necesario para generarlas y más largo que la propia vida del certificado.

Evidentemente y como más de uno ya habrá pensado, este hecho es relativo. Como es bien sabido, la tecnología avanza a pasos agigantados año tras año, y evidentemente no se disponía de la misma potencia de cálculo hace 20 años que ahora, ni se dispondrá de la misma potencia de cálculo ahora que dentro de 20. Del mismo modo, es posible que en el tiempo, se descubran métodos para resolver cómputo relacionado con el algoritmo de una forma más eficiente. Los hechos relatados hacen que un algoritmo que se considera seguro en un momento pueda dejar de serlo pasado un tiempo.

Un ejemplo conocido de este hecho es el algoritmo DES, que no se emplea para generación de claves asimétricas, pero sí para cifrado. En este caso, el algoritmo DES genera una clave, que es la que se emplea en el cifrado y el descifrado de la información.

El algoritmo DES surgió oficialmente el año 1975 y llegó a ser un estándar de facto de cifrado. De forma sencilla y omitiendo algunos detalles, el algoritmo DES es básicamente un algoritmo de cifrado por bloques: se ejecutan 16 fases idénticas de proceso denominadas rondas y en cada una de ellas se ejecuta la misma función (función de Feistel). Desde finales de los 70 hasta principios de los 90 aparecieron distintos grupos de investigadores que propusieron vulnerabilidades teóricas del algoritmo basadas en su criptoanálisis y se propusieron diversos modelos de máquinas para poder descifrar una clave DES en un tiempo razonable. Dichas máquinas eran inviables económica y técnicamente en los primeros años pero fueron yendo viables poco a poco conforme pasaban los mismos. Finalmente se demostró una de las vulnerabilidades del algoritmo en 1998, cuando se diseñó y construyó una máquina de propósito específico que fue capaz de obtener una clave DES basándose en datos cifrados en 2 días, sin desmerecer el trabajo de criptoanálisis realizado, fue la tecnología disponible en el momento para descifrar el algoritmo ya que, si el trabajo se realizó en dos días en 1998, ello implica que con la potencia de cálculo actual se descifraría la información en mucho menos tiempo.

Una vez puestos en contexto y pasando directamente a la materia que nos ocupa, si existe un algoritmo determinante en el uso de la criptografía en firma y certificado digital es el algoritmo RSA. El algoritmo se describe, de forma breve, como un algoritmo de clave asimétrica por bloques, y su robustez se basa en la complejidad computacional que requiere realizar una descomposición en factores primos de un número exponencialmente grande. Una descomposición de factores primos consiste en obtener de un número el conjunto de números primos que multiplicados de por sí dan dicho número. Este problema con números pequeños es sencillo de solucionar; más de uno se habrá acordado de sus tiempos en el colegio realizando descomposiciones en factores primos de números de dos y tres cifras. Sin embargo, este mismo problema con un número de cientos de cifras es muy complejo de resolver.

Un par de claves RSA, pública y privada, están formadas por dos partes diferenciadas denominadas módulo (n) y exponente (ec y ed). El módulo es común a ambas claves y el exponente es distinto en cada caso, empleándose el exponente de cifrado en la clave pública y el exponente de descifrado en la privada. Dichas partes tienen un propósito distinto dentro del cifrado y descifrado de la información.

Para la generación del módulo de las claves se deben seleccionar un par de números primos, la complejidad del cifrado dependerá directamente de la longitud de dichos números, por lo que por motivos de seguridad deberán seleccionarse aleatoriamente y deberán tener una longitud mínima.

Por otra parte, el cálculo de los exponentes se realiza basándose en relaciones matemáticas basadas en la función de Euler de los dos números primos originales. Estas relaciones permiten que ambos exponentes y el módulo cumplan con su función para el cifrado y descifrado.

Una vez se dispone de ambas claves, se puede realizar el cifrado y descifrado de la firma o información a enviar, para ello voy a recurrir a un sencillo ejemplo. Teniendo un mensaje M, el mismo se convierte mediante un protocolo pre acordado y reversible en un número entero m, sobre el que se implementará el cifrado. Dadas dos claves, una pública pub(n,ec), formadas por su módulo y exponente de cifrado y una clave privada priv(n,ed), formadas por su módulo y exponente de descifrado; el cifrado se aplicará con la siguiente fórmula:

c=m^(ec) mod(n)

Siendo c el mensaje cifrado que se podría transmitir sin riesgos. Se calcula la potencia del mensaje por el exponente de cifrado y se calcula el resto de su división por el módulo de la clave (dicha operación se denomina módulo, valga la redundancia). Ese último valor es el mensaje cifrado. Por su lado el descifrado se realiza del siguiente modo:

c=m^(ed) mod(n)

Una vez recibido y descifrado el mensaje con un método semejante al del cifrado, se volvería a aplicar el protocolo pre acordado para obtener el mensaje original M a partir de su número entero equivalente m. Esta relación es posible gracias a las propiedades matemáticas que se mencionan en la creación de los exponentes.

Como es obvio, el objetivo de un atacante que quiera suplantar la identidad de alguien empleando su certificado digital será obtener el exponente de descifrado dado que el módulo de la clave es común con la clave pública. Dado que los exponentes se calculan empleando los números primos originales que constituyen el módulo, para romper el cifrado se deberá factorizar el módulo para encontrarlos. Al ser el método de cifrado público, una vez obtenidos dichos números se podría generar ambas claves.

Como se ha podido observar las operaciones que se realizan en el cifrado y descifrado son relativamente simples, un detalle importante para la viabilidad de uso de un protocolo; del mismo modo, y a pesar de que no se ha entrado en detalles, las operaciones necesarias para obtener las claves RSA son más complejas que las de cifrado y descifrado, pero son exponencialmente más sencillas que las asociadas a la operación inversa, que requiere la factorización de números muy grandes.

La longitud de la clave RSA será por tanto la suma de las longitudes de módulo y cualquiera de los exponentes. Esta longitud se establece en bits y la seguridad del cifrado es directamente proporcional a la longitud de su clave, ya que la clave será más larga cuando más grande sea el número a factorizar. Lo habitual y recomendable en la actualidad es emplear claves de 2048 bits de longitud (lo que se traduce en emplear números primos de unas 617 cifras aproximadamente para calcular el módulo). Como es obvio, estos criterios se revisarán con el paso del tiempo y dependerán de la potencia de cómputo, así como de las vulnerabilidades o métodos que se puedan aplicar en el protocolo.

El método criptográfico empleado es fundamental para implantar criptografía de clave pública o cualquier otro método de cifrado, ya que determina específicamente la robustez del sistema implementado.

Con esto es todo, espero haber podido daros un poco de idea de qué es la criptografía y como funciona, así como cómo se aplica en certificados y firmas digitales. Espero que la entrada no haya resultado demasiado extensa ni demasiado compleja, ya que se trata de una materia que entiendo que para muchos puede ser algo aburrida. Muchas gracias por leernos como siempre, próximamente más entregas de esta serie.