ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Aplicaciones prácticas de la Criptografía y la Autentificación

Todo lo que hemos explicado anteriormente tiene un fin: Usarlo. Hasta ahora tan solo hemos visto la teoría que se esconde detrás de un algoritmo de cifrado de datos o un hash, que es un certificado o una firma digital. Comprendo que no es una parte muy lúdica para aquellos que les gusta la acción, pero en cambio es necesario la comprensión de este tipo de conceptos para poder usarlos. Y es que no son pocas las aplicaciones prácticas de todo lo que se ha explicado, de echo la seguridad actual de la red depende de ello. Así que vamos a ver como usamos realmente todo esto:

  • Encriptación de archivos en disco: Simple, Unidad completa, TPM, EFS, BitLocker.
  • SSL/TLS
  • OpenPGP/GPG
  • Correo Electrónico: S/MIME y GPG
  • Firmas

 

La idea es evidente, usar todo lo citado anteriormente para efectivamente cifrar y asegurar nuestros datos o nuestras comunicaciones. Aunque la idea principal es la misma siempre: “proteger”, cada elemento que deseemos proteger o autentificar empleará posiblemente un sistema diferente.

 

Encriptación de archivos en disco

Así, el punto de partida casi con toda seguridad sería la encriptación de archivos en nuestro propio disco duro. Es evidente que si tenemos información sensible en nuestro equipo, podemos desear que esta esté cifrada para que sea imposible su lectura. Imaginar equipos compartidos, o en entornos mucho más clásicos como el cifrado de datos de material secreto en empresas y similar. Evidentemente si nos referimos ya a la información sensible que puedan tener gobiernos, instituciones o grandes empresas, el uso es ya obligado, nadie quiere que alguien pueda acceder al sistema y robe información que esté desprotegida. Es mucho más eficiente tener la información sensible a buen recaudo.

Visto esto, no todos los modelos de cifrado de dato pueden ser deseables. Lo primero que habría que pensar sería que tipo de archivos se desea encriptar, y si se desea hacerlo de forma simétrica o asimétrica. La filosofía de nuevo difiere en lo que deseemos.

El uso más básico por ello sería el cifrado de archivos individuales. Si aplicamos la lógica de lo visto anteriormente, ¿que tipo de cifrado parecería más lógico aplicar aquí? Posiblemente el Cifrado simétrico. En estos entornos, no solemos necesitar que dicho archivo sea accedido por un millón de personas, todo lo contrario!! En el caso más simple tan solo nosotros deseamos tener acceso al original, luego el cifrado simétrico no parece ser una desventaja. Por otro lado el cifrado simétrico es mucho más rápido, y posiblemente en este caso los archivos a cifrar sean desde pequeños archivos a grandes archivos.

Si optamos por tanto por un sistema de cifrado simétrico podríamos pensar ahora mismo en AES-128 por ejemplo (o AES-192, AES-256). Como dijimos en su momento, no solo es importante seleccionar el algoritmo de cifrado, sino que en el caso del cifrado simétrico es imprescindible la elección de un modo de tratamiento de bloques efectivo, para evitar lo sucedido. entre otras cosas. lo que se pudo observar con las imágenes. De este modo poco a poco podemos ir haciendo una idea de lo que necesitamos, AES-192 y CBC. Esto no significa que no pudiese hacerse de otro modo. Se podría cifrar perfectamente un archivo con cifrado asimétrico o usar otros algoritmos de cifrado simétrico.

Una vez tenemos claras las necesidades tan solo nos restaría tener un software para realizar el cifrado y el descifrado. Actualmente existen cientos de miles de programas para ello, de pago y gratuitos. Algunos soportan un gran rango de algoritmos, otros son más restrictivos.

En nuestro caso vamos a usar de forma didáctica CrypTool. Amén de ver los diferentes resultados, el texto de este archivo y de todos los ejemplos que vamos a ver será siempre el mismo, con un tamaño de 161 bytes:

“Esto es un archivo de ejemplo para encriptar. Podría no ser un archivo de texto y ser un archivo binario, no hay límites en el contenido a cifrar ni en su tamaño”

Usando CrypTool, sería necesario crear primero u esquema de cifrado, después configurarlo y después aplicarlo:

Como vimos en otro capítulo, comenzando por un archivo de texto plano con el texto especificado, se pasa por un cifrado AES-192 CBC. En este punto el destino se guarda en un archivo llamado Cifrado.txt (que pertenece al módulo “Cifrado”) y otra salida se vuelve a pasar por AES-192 CBC (en este caso para desencriptar), obteniendo a la salida un archivo llamado Descifrado.txt. En teoría si el cifrado y descifrado es correcto, el archivo original llamado “A cifrar.txt” con el texto antes especificado, debería de coincidir con el archivo Descifrado.txt byte a byte. Antes de mostrar la salida de los datos, me gustaría explicar brevemente BASE64:

BASE64 es un sistema de codificación ampliamente usado sobre todo en la transmisión de datos. La idea es poder convertir cualquier tipo de dato en un texto plano. De este modo se puede dar una interpretación “escrita” de cualquier archivo binario si se desea. Básicamente 3 bytes binarios se convierte a 4 Bytes en BASE64. Se sacrifica tamaño, pero se gana en facilidad de manejo de los datos, dado que de este modo pueden tratarse como simples cadenas de texto. Quizás no sea la primera vez que lo exponemos aquí, pero sí que será usado. Si quiero mostrar el resultado encriptado del ejemplo anterior, me vería obligado a mostrarlo en hexadecimal, dado que no todos los valores hexadecimales tienen una correspondencia a carácter escrito. No obstante, si puedo convertir el archivo encriptado o el archivo desencriptado a Base64 y mostrar el contenido, contenido que puede posteriormente si se desea revertirlo a binario.

Terminado este paréntesis, en este ejemplo cabe destacar dos cosas. La primera es comprobar si el archivo de origen es igual al archivo final desencriptado. Si no fuese igual el cifrado no sirve. No obstante si verificamos el contenido del archivo “Descifrado.txt” se puede leer el mismo texto… aunque este no tiene 161 Bytes de tamaño, sino 176 Bytes, es decir 15 bytes más. ¿Que ha pasado?. Si comprobamos el archivo Desencriptado.txt en un editor hexadecimal, comprobamos que por una extraña razón, al final del archivo se le ha añadido 15 Bytes con el contenido ox00:

Como podemos ver, parece ser que no ha sido desencriptado correctamente. Si acudimos al archivo cifrado vemos que Cifrado.txt tiene una longitud también de 176 Bytes, luego el problema parece encontrarse en la codificación. ¿Que ha sucedido? El Padding. Recordemos que enun cifrado pro bloques, cuando no hay más datos para rellenar el bloque es necesario rellenarlo con otros datos. El Padding que fue configurado en CrypTool fue precisamente el relleno de ceros. El relleno de ceros es el más simple de comprender, pero no es el más eficaz, ya que a la hora de reconstruir el archivo original es imposible conocer cuantos bytes fueron añadidos, y por ello obtenemos el resultado anterior. Si se hubiese escogido un Padding mejor, podría haberse evitado esto.

¿De donde salen estos 15 Bytes más? Es simple. AES usa un tamaño de bloque de 128 Bits. 161 Bytes * 8 = 1288 Bits. Si los debemos de tomar en bloques de 128, nos deja con 10 bloques completos y 8 bits de pico. Por tanto es necesario rellenar el bloque de tan solo 8 bits para completar los 128: 128-8 = 120 Bits /8 = 15 Bytes. Es decir, para poder completar el último bloque es necesario incluir un padding de 15 Bytes.

Por otro lado, si mostramos el contenido binario del archivo Encriptado.txt (sin usar esta vez la conversión a Base64 y usando mejor una imagen), esto es lo que obtenemos:

A esto nos referíamos con que una conversión a BASE64 resulta muy útil. No podría aunque quisiese exponer el contenido de la derecha, es decir, el contenido interpretado del archivo binario. Las soluciones pasan por expresarlo en hexadecimal (la parte de la izquierda) o expresarlo en BASE64. Normalmente es mejor expresarlo en formato base64 por el motivo que he dado, a la hora de manejar en las comunicaciones los datos, es mejor que estos estén expresados como un texto plano. Así, el texto descifrado expresadoen base64 sería el siguiente:

 

RXN0byBlcyB1biBhcmNoaXZvIGRlIGVqZW1wbG8gcGFyYSBlbmNyaXB0YXI
uIFBvZHLtYSBubyBzZXIgdW4gYXJjaGl2byBkZSB0ZXh0byB5IHNlciB1bi
BhcmNoaXZvIGJpbmFyaW8sIG5vIGhheSBs7W1pdGVzIGVuIGVsIGNvbnRlb
mlkbyBhIGNpZnJhciBuaSBlbiBzdSB0YW1h8W8AAAAAAAAAAAAAAAAAAAA

Da igual que fuesen caracteres no imprimibles, al convertirlos a Base64 podrían ser representados en pantalla, y es por ello que esto se usa extensamente. Cuando hablemos del correo electrónico, Base64 será algo común.


Por otro lado no solo existen técnicas para cifrar un solo archivo. Se podría realizar la misma técnica explicada pero en vez de introducir un archivo de entrada, introducir 200 archivos, 1000 archivos… incluso una unidad completa. El cifrado individual de archivos se ha quedado un poco en desuso, y actualmente tan solo se usa para transmisión de archivos puntuales o material sensible esporádico. Esto ha ido evolucionando y la práctica más generalizada actualmente pasa por el cifrado de una unidad completa

Ahora no buscamos la protección de un archivo concreto, sino de todo lo que se encuentra en la unidad. Esto evidentemente otorga un índice de protección bastante alto, dado que todo lo que se realice en dicha unidad estará siempre protegido. Si dicha unidad fuese sustraída, nuestros datos se encontrarían completamente a salvo. En un primer momento podríamos pensar que este esquema sería exactamente igual que el anterior, pero no es así. La idea es que el contenido accedido se desencripte en el momento de acceder a dicho contenido, y sea encriptado en el momento que se realice alguna modificación. Es evidente que este tipo de esquemas podría reducir las prestaciones de un equipo, dado que se estaría encriptando y desencriptando constantemente. Actualmente existen algunas soluciones para realizar esto.

Existe multitud de software de terceros para permitir la encriptación de volúmenes completos, aunque vamos a centrarnos en herramientas que podemos encontrar ya en nuestro propio sistema: EFS o BitLocker. El problema con el cifrado completo de una unidad es como hacerlo. Realizar un cifrado completo de una unidad es facil, pero ¿como se gestiona para que se pueda hacer en tiempo real? Para nosotros es imprescindible que la tarea sea llevada a cabo de forma transparente.

Por un lado tenemos EFS, “Encryption File System” que está disponible en Windows desde Windows XP. Con EFS se encripta cada archivo que es escrito en el HDD y se desencripta cuando se requiere. EFS usa un sistema híbrido entre cifrado simétrico y cifrado asimétrico, cosa que veremos es muy común uusar. El sistema es simple, cada archivo se cifra con una key por medio de cifrado si métrico. Esta key será diferente a cada archivo, con lo que aun cuando un ataque pudiese recuperar la key de un archivo, esta no sería de mucho valor, dado que tan solo serviría para ese archivo. ¿Implica que el sistema guarda una base de datos con todas las keys, una por cada archivo? No, es más eficiente. Lo que se realiza es cifrar la key usada por cada archivo por medio de cifrado asimétrico, y una vez cifrada se adjunta al propio archivo. Es decir, cada archivo cifrado incluye la key usada para desencriptarlo, claro que antes hay que desencriptar la key por medio de la clave privada del cifrado asimétrico. Comprometer un cifrado asimétrico es mucho más complicado e imposible que el cifrado simétrico. En el peor de los casos en el que el archivo pudiese ser atacado o recobrada su Key, esto no pondría en peligro ni a la clave privada ni al resto de archivos.

Para realizar este sistema, Windows asocia a la sesión del usuario la clave privada requerida para desencriptar las keys individuales de cada archivo. A lo largo de los años, con la aparición de Windows Vista y Windows 7, el cifrado asimétrico RSA se ha sustituido por un sistema de Curva Elíptica, otra “matemática imposible” que tiene ventajas e inconvenientes respecto RSA, a fin de cuenta otro sistema de cifrado asimétrico. Por otro lado se ha permitido poder guardar una key maestra en un dispositivo extraible, desde un pendrive a una Smart Card.

Esto quiere decir que no hace falta recordar una Key (a menos de querer crear una de recuperación) para usar EFS. Para usar EFS tan solo basta con ir a las propiedades de un archivo o carpeta y marcar la opción cifrar. Cuando una carpeta o un archivo sea marcado como cifrado, desde nuestro punto de vista, mientras nuestra sesión esté activa dicho archivo será completamente accesible por nosotros del modo habitual. En cambio si se intentase acceder a dicho archivo desde otra sesión o desde otro equipo, dicho archivo/carpeta sería completamente inaccesible.

Un paso más allá se encuentra BitLocker, disponible tan solo en algunas ediciones de Windows Vista y Windows 7. BitLocker es un sistema análogo a EFS, aunque ambos pueden ser usado conjuntamente. BitLocker es un sistema que puede cifrar una unidad lógica. BitLocker no cifra archivos por así decirlo, sino la unidad lógica completa deseada por medio de AES en modo CBC, por ello es posible usar EFS en conjunción con él. BitLocker funciona no solo a nivel del propios OS, sino que también protege los sectores de inicio. Si Bitlocker detecta un cambio de bios o una modificación en cualquiera de sus elementos como el bootloader, este no desencriptará la unidad lógica, y por ende el sistema no arrancará de ninguna de las formas. Es una capa de encriptación que se coloca por encima del propio OS, siendo Bitlocker el primer elemento en procesarse en el arranque del sistema, como hemos dicho incluso antes de que el propio kernel de Windows sea cargado en memoria.

El método de funcionamiento es simple, nada mas arrancar el sistema, este verifica si todo el boot es correcto o ha sufrido alguna modificación. Si todo es correcto solicita la Key para poder permitir el acceso a la unidad lógica. Si detecta algún cambio en el boot, bloqueará el sistema y obligará a la introducción de una Key de conformidad que verifique los cambios efectuados en dicho Boot. Esto produce dos cuestiones interesantes: Que tipo de subsistema se arranca para que bitlocker se ejecute y como accede bitlocker a las keys.

Para poder usar BitLocker, el sistema debe de generar una partición de pequeño espacio que será la que arranque el sistema, dicha partición no podrá estar encriptada claro está, es tan solo como un subsistema para que bitlocker pueda trabajar de forma correcta. Pero queda el otro problema o ventaja. ¿Como se suministra la Key? En un principio BitLocker requería del uso de un TPM. En Windows 7 es posible usar BitLocker suministrando la key desde un pendrive externo.

¿TPM? TPM son las iniciales de Módulo de plataforma segura. Básicamente es un hardware criptográfico que tiene algunas funciones interesantes. En primer lugar actúa como un acelerador por hardware ya que en su hardware es posible computar hashes o firmas. Por otro lado permite que las creaciones de claves privadas y públicas sean generadas en su propio interior y que estas no sean jamás exportadas al exterior. Si se requiere la clave privada el usuario a través normalmente de un PIN dará acceso al módulo TPM de usarlas. A fin de cuenta es mucho más seguro que nuestra Key privada de nuestro equipo esté almacenada en un hardware que en cualquier otro medio. Incluso si el módulo TPM es sustraído, aunque en teoría sería “posible” de extraer las key del módulo TPM en la práctica esto es “imposible”, de ahí a su seguridad. De este modo el usuario no tiene que preocuparse de Keys, de tener que transportarlas ellos mismos.

Una vez que se habilita BitLocker y la partición es creada, el Hardware TPM se inicializa, se crean las claves necesarias y se comienza con el cifrado de la unidad lógica. Como he dicho en Windows 7 no es necesario por obligación el uso de un módulo TPM, pudiendo usar en su defecto (mucho más inseguro) un pendrive.

BitLocker en Windows 7 se le añadió la opción de poder proteger no solo una unidad del propio sistema, sino unidades extraibles. Una característica que se ha criticado a Microsoft en BitLocker es la no inclusión a sabiendas de algún tipo de puerta trasera que permitiese el acceso al sistema aun cuando fuese cifrado con BitLocker. Esto apareció no hace demasiado, donde autoridades inglesas denunciaban a Microsoft que BitLocker podría ser usado por pederastas en unidades externas para proteger pornografía infantil y otro tipo de contenidos, de modo que no fuese posible la recuperación de estos datos.

Para usar las características de BitLocker tan solo es necesario acudir al panel de control y acceder a BitLocker:

El almacenaje en Smart Card es una práctica muy común, suele ser seguro y además por regla general suelen poseer de hardware criptográfico propio, lo que hace de estos soportes ideales para muchas de estas tareas. Un ejemplo simple de Smart Card criptográfico es el propio DNI-e, el cual contiene los certificados y claves dentro de él.

Podemos decir sin lugar a duda que un Sistema Windows 7 empleando tecnologías como BitLocker y EFS conjuntamente con un módulo TPM supone un sistema muy seguro ante cualquier tipo de intento de robo de información. Esto no quiere decir que no sea posible atacar un sistema similar para acceder a él, pero sí que puede poner las cosas más que complicadas a cualquiera que lo intente.

 

SSL/TLS

SSL/TLS son protocolos de seguridad para permitir una conexión segura entre cliente y servidor. Esto es posible gracias a los sistemas criptográficos explicados: Cifrados Asimétricos, Simétricos y Hash. De forma generalizada casi nadie usa el término TLS, e indistintamente se hace eco de SSL para especificar tanto SSL como TLS. No obstante, SSL es un protocolo antiguo y que ha demostrado tener algunos fallos de seguridad, el cual fue sustituido por TLS. Aunque TLS no es compatible con SSL, TLS si tiene incluía una funcionalidad de poder usar SSL en caso de que la conexión TLS no sea posible por la razón que sea. Por ello apartir de ahora y para evitar palabrería, usaré TLS en todo momento. Actualmente SSL3 se considera seguro, aunque es mejor usar TLS 1.0/1.2 en la medida que sea posible.

TLS es usado en un sin fin de aplicaciones diferentes. Por ejemplo es usado para autentificar y/o cifrar contenido de cualquier web por medio de HTTPS, pero también es usado para asegurar (encriptar y autentificar) las conexiones de correo electrónico (que no es lo mismo que decir que se envía un correo cifrado, lo que se cifra es todo el contenido de la sesión, aunque incluya el propio correo, es muy diferente). Sea como sea, su función principal es garantizar una conexión segura entre dos puntos de la red cualquiera, sin preocuparse de que cualquier posible atacante pueda interceptar la comunicación o modificarla, cosa más que necesaria para transacciones bancarias, transmisión de datos personales, lectora de correo en redes no seguras…

TLS es un sistema híbrido, al igual que vimos con EFS. TLS se basa básicamente en encriptar el contenido de la conexión por medio de un cifrado simétrico a negociar, cuya key es transmitida desde el cliente al servidor encriptada gracias a la encriptación asimétrica. De este modo, de lograr interceptar o descifrar una comunicación, tan solo sería perjudicial para dicha conexión dado que cualquier otra conexión usaría una key diferente. Es decir, TLS se apoya en el uso de certificados digitales. Aunque esto es a groso modo el funcionamiento de TLS, cabe destacar que una sesión TLS tiene dos modos de funcionamiento. El primero y más extendido, tan solo se requiere la autentificación del servidor frente al cliente. En el segundo esquema, tanto el servidor como el cliente se deben de autentificar mutuamente. Vamos a ver los pasos que se realizan en una conexión TLS:

  1. El cliente solicita una conexión segura, y envía al servidor una lista de los cifrados y hash que el navegador soporta, así como un número aleatorio y la versión del protocolo que desea usar.
  2. El servidor responde con la versión de protocolo que se usará en relación con la recibida por el cliente, así como el método de cifrado y hash que se usará. Evidentemente el servidor seleccionará el cifrado, hash y versión de protocolo mayor que soporten ambos.
  3. El servidor envía a continuación su certificado al cliente. El cliente comprobará la validez del certificado, comprobando su firma y el CA correspondiente.
  4. El servidor solicita al cliente que envíe su certificado.
  5. El servidor indica que ha finalizado por su parte toda la negociación.
  6. El cliente envía su certificado al servidor, y este lo verificará comprobando su firma y el CA correspondiente.
  7. El cliente envía al servidor una prekey cifrada con la clave publica del servidor.
  8. El cliente firma (hash y encriptar con su clave privada) los mensajes de negociación previos. El servidor verificará esto con la clave pública del cliente.
  9. El cliente y el servidor generan la Key para el cifrado simétrico que van a usar gracias al número aleatorio generado al comienzo y a la prekey
  10. El cliente envía un mensaje de finalización cifrado conteniendo el hash de los mensajes de la negociación y otros datos.
  11. El servidor descifrará el mensaje y validará los hash
  12. El servidor enviará u mensaje de finalización cifrado conteniendo el hash de los mensajes de negociación y otros datos.
  13. El cliente descifrará el mensaje y los validará.

Lo que está en otro color es tan solo válido para aquellos sistemas en los que es indispensable la autentificación del cliente de cara al servidor. En el paso 8, el servidor garantizará que el certificado que ha recibido corresponde al cliente con el que está negociando la conexión segura. Si la clave pública obtenida del certificado del cliente puede descifrar la firma realizada por el cliente, autentifica al cliente como válido.

Si en cualquier paso una verificación es fallida, un hash no corresponde al que debería de corresponder o cualquier otra circunstancia, se supone que no se ha podido establecer una conexión segura y se aborta la negociación. En cambio, si se llega al paso número 13, a partir de ese momento toda la comunicación realizada entre cliente-servidor será una conexión autentificada y segura. Incluso los pasos del 10 al 13 son pasos de la negociación ya cifrados mediante cifrado simétrico. Aquí el uso que se le da al cifrado asimétrico es relativamente pequeño, tan solo es usado en la propia negociación.

Gracias a un Sniffer es posible verificar que este es efectivamente el esquema de uso de TLS:

En dicha imagen podemos ver los pasos que se han ido realizando. En este caso es una comunicación desde un cliente de mi red (192.168.2.2) a gmail (209.85.227.83). Asi, mi paso número 1 corresponde al paquete número 4 de la imagen: “Client Hello”. El paso número 2 al paquete 6 “Server Hello”. El paso número 3 y el número 5 son realizados en el paquete 7 con “Ciertificate” y “Server Hello Done”. En este caso no hay autentificación por parte del cliente. El paso número 7, 9 y 10 son realizados en el paquete número 9 con “Client Key Exchange”, “Change Cipher Spec” y Encrypted Handshake Message”, y los pasos 11, 12 y 13 en el paquete número 10 “Encrypted Handshake Message”, “Change Cipher Spec” y “Encrypted Handshake Message”. En sucesivos paquetes, todo el tráfico irá cifrado.

Si pasásemos a analizar cada uno de esos paquetes, podríamos ver con mucho más detalle cada paso realizado. Por ejemplo, el mensaje “Client Hello” en el cual el cliente especifica los cifrados disponibles y soportados por el navegador, así como el número aleatorio:

Como podemos ver prácticamente todos los algoritmos que han aparecido los hemos tratado. Dentro del cifrado asimétrico es usado RSA y EC (Curva Eclíptica). EC aquí se aplica a diferentes sistemas, por ejemplo ECDHE (Diffie-Hellman Exchange es un sistema de intercambio de claves para realizar un cifrado simétrico). Dentro de los cifrados simétricos podemos ver AES-128, AES-256, RC4-128, Tiple DES , Camella y SEED (estos dos últimos no se han visto). Para acabar, dentro de los Hash tenemos SHA y MD5. DSA por otro lado es un algoritmo de firma digital. Hay que tener en cuenta que TLS puede ser usado en un sin fin de aplicaciones diferentes, con lo que es normal ver en la lista de algoritmos soportados algunos que podrían no tener mucho sentido a priori en ellos

Y por parte del servidor podríamos ver igualmente tanto el certificado enviado como los ajustes seleccionados. El certificado no sería más que el certificado, la respuesta en este caso de Gmail ante nuestra petición sería:

Es decir, ante todas las sugerencias del cliente, el servidor opta por seleccionar el protocolo TLS 1.0 (dado que es el máximo que soporta el navegador) y responde que usará el conjunto de cifrado RSA para el cifrado asimétrico, AES-256 para el cifrado simétrico en modo CBC y los Hash serán SHA. Como hemos dicho, TLS es una negociación. Significa que estos datos dependerán del equipo del cliente y del equipo del servido. Posiblemente si realizamos una conexión a Gmail dede IE, la lista de cifrados sea diferente, quizás aparezca alguno más quizás alguno menos. TLS no deja de ser a fin de cuentas un estándar, si se requiere que un navegador fuese 100% compatible debería de ser compatible con el 100% de los cifrados y sistemas propuestos en el estándar, pero esto es la teoría, no la práctica. De todos modos la práctica dice que los servidores TLS más seguros usan por regla general RSA+AES-256+SHA, mientras que los más inseguros pueden usar aun DES o Triple DES como cifrado simétrico y MD4 o MD2 para el hash. Lo más normal es encontrar RSA como cifrado asimétrico y RC4 o AES como cifrado simétrico.

Vamos a comparar la petición realizada anteriormente con Firefox a Gmail con la que expondremos a continuación entre IE y Live:

En este caso de los 36 sistemas de cifrado soportado por Firefox, tan solo son 12 los soportados por IE. Y la respuesta de Live frente a esto:

Es decir, el servidor de Microsoft Live seleccioan como su mejor opción el uso de RSA con RC4-128 y MD5. Es decir, el sistema usado en TLS por parte de los servidores de MS para Live es mucho más inseguro. A fin de cuentas RC4 a resultado ser relativamente vulnerable, y MD5 es también más inseguro que SHA. Esto no quiere decir que no sea un sistema seguro, pero sí que es mucho menos seguro de la seguridad que puede ofrecernos Gmail.

TLS es un protocolo muy seguro. Normalmente no es posible comprometer este tipo de sistema, y cuando se ataca no se ataca normalmente a intentar descifrar las claves, sino algún fallo del propio protocolo. Hoy por hoy la mayoría de todas las comunicaciones sensibles hacen uso de una manera u otra de TLS. Se usa para cifrar el contenido en la web por medio de HTTPS, el correo por medio de SMTPS, túneles VPN…

Podríamos incluir aquí STARTTLS. En realidad STARTTLS es un protocolo que se ve en “Email Spoofing”. SSL/TLS usan puertos específicos en los servidores. Por ejemplo por regla general, las peticiones HTTP se realizan al puerto 80 de los servidores, mientras que las peticiones HTTPS (usando TLS) al puerto 443. En el correo pasa algo similar. Para el correo SMTP se suele mapear al puerto 25, y 995 para TLS. STARTTLS se propuso para poder realizar la conexión por el mismo puerto no seguro (25), y una vez realizada la conexión al servidor se realizaría el “cambio” a usar TLS. Cuando se usa TLS toda la comunicación íntegra es cifrada, con STARTTLS tan solo cuando se llama a este protocolo, siendo posible la conexión e incluso su uso de servidores de correo que usan STARTTLS, si no están configurados para requerir después del mensaje de “HELO” el cmando STARTTLS.

Desde mi punto de vista, todo contenido que pudiese ser de carácter personal debería de ir bajo conexiones seguras. Por desgracia muchos administradores no comportan esta filosofía, y tan solo se preocupan en todo caso de cifrar por medio de TLS las credenciales de acceso de un lugar, dejando desencriptado todo el contenido al que se está accediendo.

Esto lo veremos cuando tratemos el fascinante mundo del Sniffing en otros temas, no será tratado en Encriptación y Autentificación. Lo que si debe de quedar claro es que no por usar un sistema como TLS podemos asegurarnos de que todo está protegido, nada más lejos. Y esto es muy muy importante.

Que los certificados deban de estar firmados por autoridades CA reconocidas, no implica que estos no puedan ser usados en otro tipo de entornos en los que la firma de un CA “famoso” no es necesaria. Seamos francos, los certificados digitales suelen costar dinero, debes de acudir a un CA para que certifique tu identidad y te lo extienda. ¿Pero sería esto necesario para asegurar las comunicaciones dentro de una empresa? La respuesta es no. Un CA es necesario para dar validez a un certificado de manera global, pero cualquier usuario puede en cualquier momento crear un certificado de la clase que sea (Servidor SSL, Cliente SSL, Firma…) para el fin que necesite. Es evidente que si este certificado es expuesto al exterior y un tercero tiene que hacer uso de él, posiblemente su navegador le advierta del peligro que ello entraña, dado que casi con toda seguridad el navegador del usuario no pueda verificar la firma del CA, dado que el CA posiblemente no esté reconocido por su navegador como un CA válido. Es decir, lo que realmente dicta si un certificado es de confianza o no es a fin de cuentas la firma del CA. Si el navegador o el sistema tiene el certificado del CA reconocido como confiable, el certificado será igualmente confiable.

Esto implica que una empresa puede crear un certificado CA propio, y a partir de este crear los certificados que necesite para los propósitos que sean: Servidores Web, Certificados para los trabajadores para que puedan firmar o cifrar el correo, Certificados para el acceso a los equipos informáticos, Certificados para las Smart Card para el control de acceso a las instalaciones, Certificados para el cifrado de los datos de los equipos, Certificados para asegurar las conexiones VPN… Y todos ellos estarían firmados por el certificado raiz de la propia empresa. Si dichos certificados se usan fuera de la empresa, simplemente los sistemas exteriores o los navegadores, gestores de correos… no podrían simplemente poder validad el CA. Pero para la propia empresa, esto no sería jamás un problema, dado que sus sistemas tendría reconocido el certificado CA de esta como legítimo.

La creación de certificados para uso personal es realmente útil. Dado que pueden ser usados en un sin fin de utilidades, cuando queremos usarlos nosotros para nosotros no nos preocupa lo demás, no deseamos interaccionar con un tercero, simplemente asegurar nuestros sistemas. Esto es usado muchísimo, incluso en servidores Web particulares en los que no se desea comprar un certificado, dado que los precios pueden ser relativamente altos para un particular. ¿El problema? Como se ha dicho, los navegadores, gestores de correos y otros suelen verificarlos, y como se ha dicho, si el CA no lo tienen como un CA válido, aparecerá una pantalla de advertencia. Hay que tener en cuenta que estas pantallas de advertencias de seguridad de certificado no válido son para tomarse muy en serio, aceptar un certificado no válido maligno supondría que un tercero podría estar comprometiendo toda nuestra comunicación. Un ejemplo de advertencia de seguridad de certificado en Firefox sería tal que así:

Por alguna razón, Firefox nos advierte de que la página a la que se está accediendo tiene un error con el certificado. Si expandimos “Technical Details” nos reporta el por qué el acceso a dicha web ha sido bloqueado, en este caso porque el certificado está firmado por el mismo (luego no se puede verificar el CA) y porque el certificado pertenece en teoría a otra web, no al host 192.168.2.1. Aun así, si deseamos acceder de todos modos a dicha web, tan solo tendríamos que añadir una excepción, desplegando “I Understand The Risks” y añadiendo la excepción:

Esto permite almacenar en nuestro equipo certificados específicos de terceros, marcándolos como seguros. Muchas veces la otra opción es simplemente añadiendo a nuestra base de datos el certificado del CA, configurándolo para que pueda verificar cualquier certificado que hagamos uso que esté firmado por dicho CA. De lo contrario, lo normal es que las comunicaciones sean abortadas si se detecta que el certificado no es válido para nuestro sistema.

La mejor forma de crear certificados es posiblemente gracias a OpenSSL, aunque es una herramienta creada para ser usada por linea de comandos. Tiene la ventaja no obstante de ser altamente configurable. Para los que deseen no obstante realizar la creación en un entorno de escritorio, la mejor apuesta posiblemente sea usar IIS, el servidor web de Windows que es incluido en la mayoría de todas las versiones de Windows, aunque no instalado por defecto. A través de él es fácil y cómodo la creación e instalación de certificados.

 

PGP/GPG

PGP (Pretty Good Privacy) es un programa/sistema de clave pública usando el esquemas PKI que vimos en su momento. De echo el repositorio que se vio formaba parte de PGP/GPG. Por ello no hay mucho que decir a cuanto funcionamiento se refiere. Si bien hemos visto una aplicación directa de los Certificados digitales para SSL/TLS, con PGP/GPG vamos a hacer lo mismo. GPG en contra partida (Gnu Privacy Guard) es una alternativa libre a PGP. Tanto PGP como GPG cumplen con el estándar OpenPGP, lo cual hace a ambos interoperables mutuamente.

¿Pero que sentido tiene PGP/GPG cuando el mundo está rodeado cada vez más de los certificados digitales administrados por las grandes empresas? El espíritu y la filosofía son muy diferentes. Es cierto que la utilidad podría ser exactamente la misma, pero no hay que olvidar que los certificados digitales tal y como los concebimos ahora mismo están muy comercializados, es decir, no deja de se un negocio. Es cierto que cualquier usuario de forma particular puede crear un certificado digital para encriptar una comunicación o simplemente sus datos, pero de nuevo olvidamos que OpenPGP se crea en base a la comunidad Online, sin agencias, sin comercio, sin… con completa libertad de uso, donde la legitimidad de una clave pública radica en la confianza que depositan otros en ella.

En este apartado no se usará en ningún momento PGP, siempre gnuPGP. Aun tratándose de una aplicación de línea de comandos, es bastante descriptiva. Vamos a ver a groso modo como funciona y algununos ejercicios práctico de ello, presuponemos que GPG ya se encuentra instalado en el sistema.

 

-Creación de Keys

Es evidente que uno de los primeros pasos es crear las keys que se van a necesitar, aunque esto no es necesario si lo que deseamos es usar gpg para realizar un cifrado simétrico, lo cual también es completamente posible. La creación de Keys es un proceso simple y guiado, en rojo los comentarios

C:\Users\Theliel\Desktop>gpg –gen-key

Por favor seleccione tipo de clave deseado:
Se deben de generar dos par, uno para firmar y otro para cifrar

(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sólo firmar)
(4) RSA (sólo firmar)
Su elección: 1
En mi caso se opta por la opción 1, RSA para firmar y RSA para cifrar
las claves RSA pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (2048)
El tamaño de la clave, por defecto 2048 bits

El tamaño requerido es de 2048 bits
Por favor, especifique el período de validez de la clave.
0 = la clave nunca caduca
<n> = la clave caduca en n días
<n>w = la clave caduca en n semanas
<n>m = la clave caduca en n meses
<n>y = la clave caduca en n años
¿Validez de la clave (0)? 0
La clave nunca caduca
¿Es correcto? (s/n) s
Es necesario establecer una caducidad, en este caso nunca caduca

Necesita un identificador de usuario para identificar su clave. El programa
construye el identificador a partir del Nombre Real, Comentario y Dirección
de Correo Electrónico de esta forma:
“Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>”
Nuestros datos
Nombre y apellidos: Alma Oscura
Dirección de correo electrónico: theliel@almaoscura.com
Importante si deseamos posteriormente cifrar/firmar correo
Comentario: lección de gpg
Está usando el juego de caracteres `CP850′.
Ha seleccionado este ID de usuario:
“Alma Oscura (lección de gpg) <theliel@almaoscura.com>”

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? V
Necesita una frase contraseña para proteger su clave secreta.
Aquí nos solicitara la contraseña de paso para proteger la clave privada

Es necesario generar muchos bytes aleatorios. Es una buena idea realizar
alguna otra tarea (trabajar en otra ventana/consola, mover el ratón, usar
la red y los discos) durante la generación de números primos. Esto da al
generador de números aleatorios mayor oportunidad de recoger suficiente
entropía.
La entropía garantiza una buena clave generada aleatoriamente
………………+++++
…+++++++++++++++

gpg: clave F86191C9 marcada como de confianza absoluta
claves pública y secreta creadas y firmadas.
Creación completada de los dos pares de Keys
gpg: comprobando base de datos de confianza
gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias,
modelo de confianza PGP
gpg: nivel: 0 validez: 2 firmada: 0 confianza: 0-, 0q, 0n, 0m, 0f, 2u
gpg: siguiente comprobación de base de datos de confianza el: 2011-02-10
pub 2048R/F86191C9 2010-03-01
Huella de clave = 281E 9FBD AE6A 57FF EC65 D77F 57B5 75E8 F861 91C9
uid Alma Oscura (lección de gpg) <theliel@almaoscura.com>
sub 2048R/342B5359 2010-03-01

Nuestro par de claves queda completamente creado. La clave pública queda especificada con el ID F86191C9, mientras que la clave pública para firmar 342B5359. Una vez se ha completado el pequeño asistente, ya dispondremos de todo lo que necesitamos para realizar la tarea que deseemos. Por defecto, las claves creadas son firmadas por nosotros mismos, esto le da a las claves validez completa para nosotros mismos, así como cualquier clave que firmemos.

Después de la creación de las claves, lo normal es crear un certificado de revocación. Un certificado de revocación lo que nos permite es revocar nuestras clave completamente en caso de que esta haya sido perdida, comprometida… y lo que hace es marcar nuestras claves como no válidas. Dado que se requiere de nuestra propia clave privada para ello, lo normal es crearlo después de crear nuestras claves, y mantenerlo en lugar seguro. Cualquiera con nuestro certificado de revocación podría marcar nuestra clave pública como revocada:

C:\Users\Theliel\Desktop>gpg –gen-revoke -o revocar.txt almaos

sec 2048R/F86191C9 2010-03-01 Alma Oscura (lección de gpg) <theliel@almaoscura.com>

¿Crear un certificado de revocación para esta clave? (s/N) s
Por favor elija una razón para la revocación:
0 = No se dio ninguna razón
1 = La clave ha sido comprometida
2 = La clave ha sido reemplazada.
3 = La clave ya no está en uso
Q = Cancelar
(Probablemente quería seleccionar 1 aquí)
¿Su decisión? 0
Introduzca una descripción opcional; acábela con una línea vacía:
>
Razón para la revocación: No se dio ninguna razón
(No se dió descripción)
¿Es correcto? (s/N) s

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: “Alma Oscura (lección de gpg) <theliel@almaoscura.com>”
clave RSA de 2048 bits, ID F86191C9, creada el 2010-03-01

se fuerza salida con armadura ASCII.
Certificado de revocación creado.

“Armadura ASCII” es el término que llama GPG para formatear los datos en BASE64, que como ya dijimos su principal uso es poder interpretar en texto plato archivos binarios. Así pues, si abrimos el archivo de texto revocar.txt, lo que veremos será algo así:

—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.10 (MingW32)
Comment: A revocation certificate should follow

iQEfBCABAgAJBQJLjPn+Ah0AAAoJEFe1dej4YZHJKC0IAKurWg5Ft9ubYrxyASyL
ISEy5hSfVjslpVnT9qjwnMYPHYwCv7YbpHki6hGYowH3lFoYMaFl4QmrmqoIsiuV
OkrqekCPuGGt/kZCzkOh96lYYp8KWGfxBbjQyU17/yt9qLPlM0vEYNv6QHGKi/5K
flkPE0Y57rtC+Kz6WeCF6e8ao7yqfKJNkbvPLtpYTUzcrFzRiraBwNaIBuyRMod/
fmemqN+QkYf7PgVec0qLe8o5E+OBsHhFnwbYf0jQDmj2ehGpTlwLi2H02Ppfu1Wq
w6/DO33haTvFgXw1UwO4sgWACvO9bhGy711CJBFo4zto6jwHLxf/CIDNOJPTuY0S
Fcc=
=2B98
—–END PGP PUBLIC KEY BLOCK—–

Evidentemente esta clave ha sido creada tan solo para estos fines, luego no me importa publicar el certificado de revocación. Con él, cualquier persona podría revocar dicha key.


-Edición de Keys

Otra acción común es la edición de Keys. Esto tiene como objetivo por ejemplo añadir una identidad nueva a nuestras claves, modificar la expiración, modificar la contraseña de paso… es decir administrar nuestras keys. Para ello tan solo se requierer el comando “gpg –edit-key [CLAVE]” donde “clave” es cualquier identificativo de la Key que deseamos modificar. Por ejemplo podríamos poner el ID de nuestra clave, el correo electrónico, el nomre o apelllidos… cualquier dato es suficiente:

C:\Users\Theliel\Desktop>gpg –edit-key almaos
“almaos” es reconocido por almaoscura.com, que es una key presente

Clave secreta disponible.
especifica que la key a editar disponemos la clave privada

pub 2048R/F86191C9 creado: 2010-03-01 caduca: nunca uso: SC
confianza: absoluta validez: absoluta
sub 2048R/342B5359 creado: 2010-03-01 caduca: nunca uso: E
[ absoluta ] (1). Alma Oscura (lección de gpg) <theliel@almaoscura.com>

Orden> showpref
showpref muestra el orden de preferencias de los algoritmos criptográficos
para simétrico se usará AES256, para Hash SHA256, para compresión ZLIB

[ absoluta ] (1). Alma Oscura (lección de gpg) <theliel@almaoscura.com>
Cifrado: AES256, AES192, AES, CAST5, 3DES, IDEA
Resumen: SHA256, SHA1, SHA384, SHA512, SHA224
Compresión: ZLIB, BZIP2, ZIP, Sin comprimir
Características: MDC, Sevidor de claves no-modificar

Orden>

Con “help” tendremos una lista extensa de todas las posibilidades. Lo más común es la gestión de los identificadores, cambio de contraseña de paso..

 

-Encriptación/Desencriptación:

Como herramientas criptográficas, gpg puede usarse perfectamente para cifrar cualquier archivo o contenido con cifrado simétrico o asimétrico. Hacerlo es simple:

Cifrado simétrico usando AES256: “gpg -c –cipher-alg AES256 -o test_cifrado.txt test.txt”
-c especifica cifrado simétrico, –cipher-alg el algoritmo de cifrado simétrico, -o el archivo de salida, “test.txt” el archivo origen. Nos solicitará una contraseña y nada más

Cifrado asimétrico usando la key pública de AlmaOscura: “gpg -er almaosc –armor -o test_cifrado_a.txt test.txt”
-er especifica encriptación para un destino concreto (con lo que tenemos que tener su clave pública), -armor fuerza la salida en BASE64

Descifrar cualquier contenido: “gpg -d -o test_d test_cifrado.txt”
automáticamente la pantalla nos dirá como se ha cifrado. Si es cifrado simétrico necesitamos la clave, si es asimetrico tener la clave privada y la contraseña de paso:

C:\Users\Theliel\Desktop>gpg -d -o test_d test_cifrado_a.txt

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: “Alma Oscura (lección de gpg) <theliel@almaoscura.com>”
clave RSA de 2048 bits, ID 342B5359, creada el 2010-03-01(ID de clave primaria F86191C9)

gpg: cifrado con clave $s de $u bits, ID $s, creada el $s
“Alma Oscura (lección de gpg) <theliel@almaoscura.com>”

C:\Users\Theliel\Desktop>

 

-Envío o recepción de Keys a un repositorio

Para acabar, otra función igualmente importante es poder exportar nuestras claves públicas para que todos puedan tener acceso a ellas. Una vez realizado, nuestras keys serán enviadas a uns ervidor público, y de este a otras réplicas a lo largo de todo el mundo, para aque así pueda cualquier persona del mundo poder enviarnos un mensaje cifrado o firmado hacia nosotros:

gpg –keyserver gpg.mit.edu –send-key theliel@almaoscura.com

Del mismo modo, si se especifica –recv-key en vez de enviar al servidor la key especificada, se obtiene de él la clave pública especificada, necesaria si deseamos cifrar un mensaje para dicha persona o enviar un correo seguro o…

Aunque existen muchas más posibilidades para GPG, enumerarlas una tras otra todas las opciones sería realmente poco práctico, dado que para ello está el manual de usuario de GPG, y aquí no pretendemos crear un manual de uso de GPG, sino comprender como funciona GPG y como poderlo usar, sobre todo en el siguiente punto, “Correo electrónico”

 

Correo Electrónico

Si TLS/SSL es la aplicación práctica predominante al uso de certificados digitales o firmas, el correo electrónico sería la segunda aplicación práctica más usada. La idea de cifrar y/o firmar el correo es lo más lógico. En todo momento hemos estado hablando de A envía un mensaje a B. En realidad el correo electrónico es esto a groso modo. Luego no es extraño que existan funciones más que extendidas para poder realizar este tipo de prácticas. Cuando hablamos de TLS/SSL dijimos que muchos proveedores de correo electrónico usan estos protocolos para evitar que un tercero pueda leer el correo. Esto es cierto, pero esto no significa que el correo en sí esté cifrado. Por ejemplo, si envío un correo sin cifrar por medio de gmail que usa para SMTP TLS, el correo se envía de forma cifrada desde el origen (mi ordenador) hasta el destino (el servidor de Gmail). Cualquier usuario que acceda al correo podrá leerlo. SSL/TLS no garantiza de modo alguno que el mensaje sea leído únicamente por el destinatario concreto, simplemente que el envío (o recepción en caso de IMAP o POP) se realiza de forma encriptada.

A día de hoy existe un estándar mayoritario, soportado por prácticamente todos los gestores de correo electrónico llamado S/MIME. S/MIME nos permite poder cifrar o firmar mensajes de correo electrónico si disponemos de un certificado para ello. Recordemos que no todos los certificados valen para todo, tendremos que tener un certificado que nos permita firmar y/o cifrar correo. En el caso concreto del DNI-e, nos permite por ejemplo tan solo firmar, dado que nuestro DNI-e no se le asocia ningún correo electrónico. En caso de los certificados CERES si que se le añade la opción de firmar o cifrar.

Para poder firmar un correo no se requiere nada en realidad, tan solo disponer de un certificado que permita la firma de correo y la clave privada de él evidentemente. En cambio para poder cifrar un mensaje lo que se requiere es la clave pública del destinatario, con lo que se depende de que este tenga o no tenga un certificado y que sea válido. Es una pena no obstante que el DNI-e expedido en españa no tenga la opción a la hora de expedirlo de asociarlo a un correo electrónico. Supongo que es solo cuestión de tiempo que esto se permita.

Del mismo modo que podemos usar S/MIME para firmar o cifrar mensajes por medio de certificados, dependiendo de la versión que tengamos de GPG podremos hacer lo mismo o necesitaremos tener instalado en nuestro gestor de correo alguna aplicación (addon) para hacerlo, es el caso de EnigMail para Thunderbird. Su funcionalidad es prácticamente la misma a la de S/MIME, lo que sucede es que en este caso no se trabajará con certificados, sino con el administrador de claves de GPG.

Vamos a ver algunos ejemplos de cifrado y firma a través de S/MIMI y a través de EnigMail. No hay que decir que es posible tan solo firmar, firmar y encriptar o tan solo encriptar.

 

-S/MIME

Usando Thunderbird, es muy fácil configurarlo para que por defecto se firme todos los correos redactados por una cuenta concreta. Tan solo es necesario especificar el certificado que será usado por dicha cuenta:

Una vez se han especificado los certificados a usar, tan solo es necesario redactar el correo deseado y en S/MIME seleccionar firmar. El mensaje se enviará sin problema alguno. La firma no deja de ser un archivo adjunto. Dependiendo de como sea abierto el correo, este nos verificará o no la firma adjunta. Por ejemplo, si el correo se abre con gmail, este tan solo verá que existe un archivo adjunto, si se abre con Thunderbird, directamente intentará verificar la firma del origen, con lo que el equipo deberá de tener los certificados pertinentes. Si es un mensaje tan solo firmado, la extensión será P7S, y P7M si el mensaje está cifrado o cifrado y firmado, siendo el adjunto en este caso el cuerpo del mensaje o cualquier adjunto que también contenga.

Si vemos el mensaje desde el punto de vista de gmail, tendremos algo así:

En cambio, de cara a un gestor de correo, lo que tendríamos sería algo así (No es el mismo correo):

En este caso, se puede ver en la esquina superior izquierda dos iconos. El primero significa que existe una firma, pero no se ha podido verificar. El segundo que el mensaje está cifrado. En pantalla, el texto “probando probando” es mostrado automáticamente ya desencriptado. ¿Por qué existe un error en la firma en este caso? Porque fue firmado por un remitente (correo electrónico) que no coincide con el correo electrónico especificado en el mismo certificado. Esto sucede si por ejemplo firmamos un correo enviado por otra cuenta con el certificado que poseemos pero que en dicho certificado lo creamos para otro correo. En cambio, el cifrado es válido, dado que para cifrar tan solo se requiere el certificado, la clave pública del destinatario, claro que tan solo el destinatario, que posee la clave privada, puede desencriptarlo.

Las claves privadas de los certificados almacenados en el propio sistema no suelen estar protegidas por una clave de paso, en cambio los certificados almacenados en una Smart Card como el propio DNI-e suelen estar protegidos por un PIN que es necesario introducir correctamente para tener acceso a nuestra clave privada.

Debería ser posible desencriptar cualquier archivo p7m directamente con OpenSSL especificando la key:

“openssl smime -decrypt -in smime.p7m -recip my.pem”

Siendo my.pem el certificado con la clave privada exportado y smime.p7m el mensaje cifrado/firmado

 

-GPG

El procedimiento en realidad es exactamente igual que el visto para S/MIME. Lo primero es asociar nuestras claves a la cuenta que desamos, al igual que se hizo para asociar a una cuenta los certificados correspondientes:

Y la recepción o envío de este tipo de correos es exactamente igual que con un certificado. Al firmar el correo lo normal será introducir la clave de paso para desproteger la clave privada y con ella poder realizar la firma:

A diferencia de S/MIME, PGP/MIME no cifra los mensajes o los firma adjuntando al correo el mensaje cifrado, sino que directamente suele cifrar el mensaje. Si nuestro gestor de correos reconoce que está firmado y/o cifrado por OpenPGP, nos mostrará el mensaje o nos dará un error de apertura, no obstante si no reconoce el formato o es abierto desde cualquier gestor online, lo normal es encontrar como es ya costumbre el mensaje y/o contenido en BASE64. Para el mensaja enterior sería:

—–BEGIN PGP MESSAGE—–
Version: GnuPG v1.4.10 (MingW32)

hQIMA0n/

fXfs2GxwARAAyJCLgdeCtg8f53jwWPSc+MZuJ15Kw/9dUEacIP79+WZl
xY8YdFf6pgkwL1Xov9P1k9vlwMN7uwYLa/g5TjUxqatoURxO+tHO6kVzFIGWn9W8
1KB/dxJWib4u98ACV0CIVC0waYyhB2XiHmrZR/TZYqEvwHHJx1l4I6t2Z2QPaahm
vdiTxOUwDixQI26qoNoUYRUei6yovKiJbviV0Sr6oItjU5XVxOVcyrpcGwTuOT34
kWig+u+CFv5rC6my2BtX1C/Aq/LC0YvIjTBce8fFNL84B5V71dgEmJhCNXSlAm23
pJ8zfltVq+ZVXV2koCKLvEoPytpyy+u/RiIUS30J/hrW1OdAdX3RVDh54h/7ODZu
z2YFjxbWQdiTWsENgpVVZ4KiA6irSz6Hc+fpJZMlUCHDG6UgSkY4Qx53c0Aj7paz
dxE/aQbGxxuZkqsKFOo6UhNfhN9aj2a5+IN5uI3vcKWlwBGQ1iCXgn4CVN6vUf5S
Kd9NV2sutZTxgOhN58xekYSLY459RPuZSHCQz42TWuku9UVhTiclg98RzSti1auY
9v+NJZtgJn5Ug9odJv7yJ4Opa0kqpFH3bbgO2dloflgpZMDnSzvbouxxl79ecjV7
IoxL8Vml4+2W3WTWw81Qh4/p9ShFOXdUhsAQxd3Q+W4ub84yrVBdcPZZLQ/R/VPS
wQ4B3yCR6PyfWR8U3ovO6TUHvPXQQdO32EInaXu4HJJkNdGf4phTk3/r8ichctbN
t2/yM4GkaVLamxSAWe5gOXfc+OtWap8W/fIsqzChrKmiQwcvO7B4ZCeEZrJ3Fjnq
8Nfr97vFFjDCdGA0gjcUyZiLUrfoljEETTxGQ5/dWYXyw5lo/yhBH+CQaG+woSDl
7BNERdn8TtTxX3BUMx40eIJgbW/nkefj7+ZRiclJ1ecmpkWuNSjWcj7USEMB4yUI
ZjNeJH0hqsbCezyaYBfArtgZ2XAeW9juNOUcdt+dHkWVZtcb6BqgbABzZ1Y4oFXV
GOqZcp0tXPrDCUNuupEDiTdnJOQvF7gaOr5q7o2Brznmzs4inh6xvjEuhMoSjmui
yh41jAKMkpb2L3abUbaPgHWCMCWO0GjEtXkDlXVebT37X0W1cK9g4yQTT8Slkuop
UQmQFD+8CI35wXDQJqjZ9/Oj5x2iDYiL2czkOiYvOxbuB9+hoDFqMSYQeQkOFzLn
MkmDL7PBoN5zDLzlpJj1SbZxN7GmcLxO+RSmmCnHxZdHfzkeuP5VSUsNkHBJs7iH
P4ZK002DLRoJw0OygcTdWkfuq7dcUkT8JHbpUtDLV7A=
=wSZC
—–END PGP MESSAGE—–

En realidad, ese mismo “texto” podría ser procesado directamente por GPG por linea de comandos para desencriptar y verificar la firma. Si copiamos dicho texto a un documento txt por ejemplo y procesamos gpg de la siguiente forma:

C:\Users\Theliel\Desktop>gpg -d 1.txt

Necesita una frase contraseña para desbloquear la clave secreta
del usuario: “Pepito Grillo <theliel@almaoscura.com>”
clave RSA de 4096 bits, ID XXXXXXXX, creada el 2008-07-16(ID de clave primaria XXXXXXX)

gpg: cifrado con clave $s de $u bits, ID $s, creada el $s
“Pepito Grillo <theliel@almaoscura.com>”

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

prueba

gpg: Firmado el 03/02/10 15:10:00 usando clave RSA ID XXXXXXXX
gpg: Firma correcta de “Pepito Grillo <theliel@almaoscura.com>”
gpg: alias “Pepito Grillo <theliel@almaoscura.com>”

 

Y efectivamente, “Prueba” era el texto del mensaje. Del mismo modo, al desencriptar el mensaje, se puede verificar que este estaba también firmado, y que la firma es válida. Esto quiere decir que el uso de PGP/MIME en realidad no es más que una interfaz sencilla para poder encriptar y cifrar el contenido que sea necesario.

 

Gracias tanto a PGP/MIME o S/MIME es simple y eficaz poder firmar o enviar archivos cifrados. Aunque es cierto que no es una práctica muy común el hacerlo, sí que es una práctica completamente recomendada si se desea evitar el eMail Spoofing o ataques para interceptar el contenido de los correos. En el tema de Sniffing, veremos la importancia de esto, tanto de usar TLS/SSL como el cifrado o firma de mensajes. Lo que puede parecer desde un punto de vista doméstico algo sin importancia, si que la tiene si los usuarios supiesen en realidad los peligros que entraña Internet simplemente por el desconocimiento de las propias tecnologías.

 

Firmas

Para acabar con las aplicaciones prácticas (aunque no son ni mucho menos las únicas), vamos a hablar del firmado de aplicaciones. En realidad, no es más que una extensión a la firma que ya hemos visto en los correos electrónicos o las firmas usadas por GPG para archivos. Lo cierto es que cada vez más programas permiten la firma de los documentos. Con la llegada del DNI-e, del cual hablaremos un poco al final de este capítulo, muchos trámites burocráticos son posibles hacerlo simplemente con el DNI-e. Esto es debido a la posibilidad que tenemos de firmar documentos ya no solo con nuestra firma manuscrita, sino también a los certificados digitales de firma que nuestro DNI-e posee.

Con el tiempo, veremos cada vez más programas que permiten el firmado de documentos. El correo electrónico tan solo es una de esas aplicaciones, pero no la única. Vamos a ver por ejemplo lo sencillo que podría ser dar validez legal a un documento Word o PDF. Y digo validez legal porque si realizamos una firma con nuestro DNI-e, es igual como hemos dicho como si firmamos con nuestra firma manuscrita cualquier documento. Recordar el término de “No Repudio”.

Para documentos PDF tan solo se debe acudir a la función “Firmar” y selccionar el tipo de firma, si queremos que sea incrustrada o simplemente certificar el documento. En Office, esto se hace de forma análoga a través del menú: “Colocar Firma”. En un caso o en el otro, en el momento que se accede al formulario de firma se nos mostrará la lista de certificados disponibles para ello, si tenemos el DNI-E en su lector podremos acceder a nusetros certificados de él. En caso de ser un certificado instalado en el sistema podremos seleccionarlo igualmente:

En el desplegable tan solo tendremos que seleccionar el certificado que deseamos utilizar, en este caso he optado por el certificado de Firma de mi DNI-e. Por seguridad, el software del DNI-e pide una segunda confirmación cada vez que el certificado de firma va a utilizarse, especificando la peligrosidad de ello. Peligrosidad que es exactamente la misma que puede tener nuestra firma en un papel. Nadie firmaría un papel sin leerlo. Esto es exactamente igual. En Acrobat, al terminar el proceso se colocará de forma visible (o no) nuestra firma, exactamente igual que en Word o en la mayoría de los programas que permitan realizar firmas.

 

 

DNI Electrónico

Para acabar vamos a dedicarle algunas palabras al DNI-e, expedido aquí en esta España nuestra, que empezó hace ya unos años a imponerse. Se ha hablado mucho del DNI-e y de todas las supuestas maravillas que es posible hacer con él. Del mismo modo no han sido pocos los que lo han criticado. ¿Qué hay de verdad en todo ello?

El DNI-e es una iniciativa pionera y hay que verla como tal. Ello implica que no podemos esperar que todas las maravillas que promete puedan ser visibles en el poco tiempo que lleva en funcionamiento. Si bien es cierto que el sistema de funcionamiento del DNI-e no es más que un par de certificados para validar nuestra identidad, no es facil de un día a otro tener toda la infraestructura necesaria para que estos certificados sean realmente útiles de cara a la burocracia.

La idea principal del DNI-e es sin duda el poder realizar cualquier trámite con la administración de forma remota. A fin de cuenta la necesidad de personalización física en una entidad o administración es para garantizar la identidad de dicha persona. En cambio, lo cierto es que para el 99% de todos los trámites no sería necesario movernos de la pantalla de nuestro ordenador si existiese una forma que garantice nuestra identidad. Y ese es el Alma del DNI-e. Es por ello por el que se incluyen dos certificados, uno para autentificación y otro para firma, que son los dos tipos de certificados que podríamos necesitar a la hora de hacer cualquier gestión a través de internet.

El problema es que las instituciones, administraciones y otros tienen que adaptarse a este nuevo modelo. A esto surge otro problema, que cada cual usa el sistema que más le place. Esto se refleja en problema con los navegadores a fin de cuentas. Todos estas gestiones son posibles gracias a conexiones TLS mutuamente autentificadas y, en caso de ser necesario, la firma de algún documento del que se requiera validez legal. Luego un peso importante recae en los navegadores, en los protocolos TLS/HTTPS… en como esas comunicaciones son realizadas. Al no existir un consenso de como realizar las comprobaciones, de si es mejor usar JAVA o si es mejor usar PHP, o si es mejor usar… provoca lo que son las mayores quejas de todo el sistema: “Me funciona con IE, pero no con Firefox” “Me funciona con Firefox, pero no con IE”, “A la tercera que intento funciona, pero las otras dos veces nada…”. Esto son errores comunes para cualquiera que haya intentado realizar trámites por el DNI-e.

No obstante, con el paso de los días, cada vez son más las instituciones que quedan recogidas para hacer uso del DNI-e. Es solo cuestión de tiempo que prácticamente todas las gestiones burocráticas sean posible realizarlas sin movernos del asiento, simplemente identificándonos ante la administración con nuestros certificados. Actualmente es posible realizar gestiones como el acceso a la banca electrónica, permiso por puntos, matrículas de la universidad, certificaciones estatales, becas, oposiciones, SAS, vida laboral…

 

El DNI-e no es más que una Smart Card de las que hemos estado hablando, una tarjeta de plástico con un microprocesador criptográfico, similar en parte a lo dijimos quera un módulo TPM. Dicho procesador criptográfico posee funciones para generar números aleatorios, generar claves RSA por sí mismo, generar Hash, almacenar certificados, realizar cifrado Triple DES… las especificaciones completas pueden encontrarse en la web del DNI-e, tan solo hay que conocer que dicho procesador criptográfico es un ST19wl34

Básicamente es una tarjeta de memoria que costa de tres zonas independientes: 6KB RAM, 224KB ROM, 34KB FLASH. Lo que sucede que cada una de dichas zonas de memoria está protegida por un Firewall interno con reglas de acceso a cada una de ellas, y además cada zona de memoria puede particionarse. Es decir, se pueden crear “reglas” en el firewall interno de modo que tan solo ante ciertas operaciones y ciertas validaciones, se permita el acceso a ciertas particiones de la zona de memoria que sea. De las tres zonas de memoria podemos inferior que en los 224KB destinados a la ROM se encuentra el “sistema operativo” del DNIe, llamado amigablemente DNIe v1.1. En los 34KB de la memoria flash se encontrarían los datos de nuestra propia tarjeta, es decir nombre, apellidos, dni, certificados, claves… y evidentemente la memoria RAM para las operaciones en activa que pueda necesitar.

Evidentemente la memoria flash está particionada en diferentes regiones de seguridad. Tan solo podemos hacer una idea de como es ello en relación a los datos aportados por la propia administración:

ZONA PÚBLICA: Accesible en lectura sin restricciones, contenido:

  • Certificado CA intermedia emisora.
  • Claves Diffie-Hellman.
  • Certificado x509 de componente.

ZONA PRIVADA: Accesible en lectura por el ciudadano, mediante la utilización de la Clave Personal de Acceso o PIN, conteniendo:

  • Certificado de Firma (No Repudio).
  • Certificado de Autenticación (Digital Signature).

ZONA DE SEGURIDAD: Accesible en lectura por el ciudadano, en los Puntos de Actualización del DNIe.

  • Datos de filiación del ciudadano (los mismos que están en el soporte físico).
  • Imagen de la fotografía.
  • Imagen de la firma manuscrita.

DATOS CRIPTOGRÁFICOS: Claves de ciudadano

  • Clave RSA pública de autenticación (Digital Signature).
  • Clave RSA pública de no repudio(ContentCommitment).
  • Clave RSA privada de autenticación (Digital Signature).
  • Clave RSA privada de firma (ContentCommitment).
  • Patrón de impresión dactilar.
  • Clave Pública de root CA para certificados card-verificables.
  • Claves Diffie-Hellman.

DATOS DE GESTIÓN:

  • Traza de fabricación.
  • Número de serie del soporte.

De estos datos podemos imaginar que la flash está dividida en cuatro partes. Una de ella de acceso no restringido, donde se encontrarían el Certificado de la CA intermedia (no el certificado CA raiz), que sería en este caso “AC DNIE 003″, el certificado raiz CA recae sobre “AC RAIZ DNIE”. En la misma zona se encontrarían las claves DH. DH es un algoritmo usado para comenzar a intercambiar claves. Por último se encuentra el certificado x509 de componentes, que se refiere a algunos de nuestros datos, como lo es Nombre y apellidos, DNI o equipo de expedición.

La segunda zona de la memoria es usada para almacenar los dos certificados que posee, el certificado de firma y el de autentificación, que aunque los dos pueden ser usados para firmar, tan solo el de firma tiene habilitada la función de “No repudio”, la cual ya hemos hablado de ella, lo cual hace que una firma digital con él tenga el mismo valor que un documento firmado manuscrito.

En la zona de seguridad tan solo se encontrarían los datos expuestos, los datos de la persona física, imagen de la fotografía, la firma.

Quedaría por pensar donde se encuentran alojados los datos criptográficos. Por su seguridad, podríamos pensar que se encontrarían en una zona especial del mismo procesador criptográfico, pero esto no es así. Luego podemos pensar que se encuentran en una zona de memoria Flash, la cual tiene unas reglas de acceso muy limitadas. Por ejemplo, una zona de memoria marcada tan solo para lectura interna. Es decir, los datos almacenados en ella tan solo pueden ser leído por el mismo OS de la propia Smart Card, sin que existe posiblidad de lectura desde el exterior. Si nos damos cuenta, las tres zonas de memoria anteriormente especificadas pueden ser extraídas o modificadas desde el exterior. En cambio, estas zonas de memoria no. Tan solo existirá seguramente un protocolo configurado en el propios OS del DNIe para generar, borrar, crear, eliminar nuevas claves, pero nunca para extraerlas.En esta zona especial se encontraría la información más sensible, comenzando por las claves privadas de los propios certificados.

El resto del hardware del DNI-e son algunos módulos aceleradores para las operaciones criptográficas y una memoria ROM que incluyen librerías y software ya creado por ST para ser usado por el OS introducido en la ROM de usuario. Posee a parte algún generador de números aleatorios y el resto es prácticamente electrónica pura y dura.

Visto así, es más fácil comprender que es en realidad el chip de nuestro DNIe, que no es algo tan raro o tan complicado de comprender. Por supuesto, esto tan solo es todo especulativo, dado que tan solo podemos imaginar en función de los datos que han sido publicados. Quizás sería posible desgranar un poco más el DNIe y ver realmente como está diseñado, los comandos APDU de acceso… pero requeriría paciencia y tiempo, y tampoco este capítulo trata sobre ello, tan solo un repaso general de lo que es el DNIe y de como funciona.

 

Para terminar todo este capítulo, recordar que la tecnología está para usarse. Un sistema usado responsablemente y sabiendo de que se trata, otorga un índice de seguridad muy muy alto. No implica que tengamos que ser neuróticos en cuanto a seguridad se refiere, pero como veremos en otros temas como el Sniffing, Spoofing… nunca puedes fiarte de quien pueda estar al otro lado, y mucho menos de las intenciones que puede tener. A quien esto le parezca desmesurado, que se comience a preguntar por qué hay tantos problemas de seguridad a día de hoy.