Transport Layer Security (TLS) es un protocolo que proporciona comunicaciones seguras a través de Internet. Habitualmente se utilizan para la navegación web de páginas seguras, o para correos electrónicos, pero se está utilizando cada vez más en IoT, justamente con el objetivo de evitar ataques.

TLS proporciona cifrado de datos, integridad de datos y Autenticación.

Esto significa que cuando utilizamos TLS, podemos estar seguros que:

  • Nadie ha leído nuestros mensajes.
  • Nadie ha modificado nuestros mensajes.
  • Nos estamos comunicando con los dispositivos previstos.

Cuando un dispositivo IoT (por ejemplo, un Tracker) envía mensajes con información sensible (por ejemplo, la localización) a una plataforma IoT, aparecen las siguientes incógnitas:

  1. ¿Cómo sabemos que nadie ha leído el mensaje con la ubicación del dispositivo?
  2. ¿Cómo sabemos que nadie ha modificado el mensaje con la ubicación del dispositivo?
  3. ¿Cómo sabemos que el dispositivo es realmente quien dice ser?
  4. ¿Cómo sabe el dispositivo que se esta comunicando con la Plataforma correcta?

Podemos responder estas preguntas por medio del uso de:

  • Cifrado de los Mensajes: esto hace que el contenido de los mensajes sea ilegible para terceros. (Responde el Punto1).
  • Firmado de los Mensajes: Esto permite que quienes participan de la comunicación sepan que con quien se están comunicando es efectivamente quien dice ser, a la vez que asegura la integridad de los mensajes. (Responde los puntos 2, 3, y 4).

Tanto el Cifrado de los mensajes como la Firma de éstos requiere el uso de llaves. Estas llaves son números (comúnmente de 128 bits) que se combinan con los mensajes por medio de Algoritmos (RSA, etc.).

Claves Simétricas y Asimétricas (Claves Públicas y Privadas)

Las Claves Simétricas se utilizan para cifrar o firmar el mensaje, y la misma clave se utiliza para descifrar el mensaje. El problema con este tipo de disposición de llaves es que cualquiera que tenga acceso a la misma puede leer el mensaje.

Con las claves Asimétricas (públicas y privadas), se utilizan dos claves que están relacionadas matemáticamente (pertenecen como un par de claves), pero son diferentes. Esto significa que un mensaje cifrado con una clave pública no se puede descifrar con la misma clave pública. Para descifrar el mensaje se necesita la clave privada.

TLS utiliza cifrado Asimétrico (llaves Públicas y Privadas) para el cifrado e integridad de los datos. Las llaves Públicas pueden hacerse disponibles a cualquiera (de ahí su nombre). Entonces, ¿Cómo saber si una Clave Pública pertenece a la entidad que la reclama? Aquí es donde entran en juego los Certificados.

Certificados

Un certificado digital proporciona un vínculo entre una clave pública y una entidad (empresa, nombre de dominio, etc.) que ha sido verificada (firmada) por un tercero de confianza (una Autoridad de Certificación).

Los certificados digitales son emitidos por Autoridades Certificadoras (CA) reconocidas. Para obtener el Certificado Digital se debe cumplir un proceso (completar un formulario), agregar nuestras claves Públicas y enviar todo a la Autoridad de Certificación. Este Proceso se denomina “Solicitud de Certificado” o CSR.

La autoridad certificadora realiza algunas comprobaciones (depende de la autoridad) y devuelve las claves incluidas en un certificado.

El certificado está firmado por la autoridad certificadora emisora , y ésta es la que garantiza las claves.

Una vez completado este proceso y obtenido el Certificado, podremos distribuir nuestra Clave Pública por medio del Certificado. De esta manera, el receptor puede verificar la firma en el Certificado, y si verifica satisfactoriamente, puede confiar en nuestras claves públicas.

Tipos de Certificados Digitales

Cuando intentamos comprar un certificado para un Web Server o para un Broker MQTT, nos encontramos con dos tipos principales:

  • Certificados de validación de dominio (DVC)
  • Certificados de validación extendida (EVC)

La diferencia entre los dos tipos de Certificados es el grado de confianza en el certificado, cosa que depende de la rigurosidad del proceso de certificación. El nivel de cifrado que proporcionan es idéntico.

Un certificado validado por dominio (DV) es un certificado digital X.509 que se usa típicamente para la seguridad de la capa de transporte (TLS) donde la identidad del solicitante ha sido validada demostrando cierto control sobre un dominio DNS. Este proceso de validación normalmente está completamente automatizado, lo que los convierte en la forma de certificado más económico.

Un certificado de validación extendida (EV) es un certificado que acredita la entidad legal que controla el sitio web, el Broker MQTT o el paquete de software. La obtención de un certificado EV requiere la verificación de la entidad solicitante por una autoridad de certificación (CA).
Por lo general, son más costosos que los certificados validados por dominio, ya que implican una validación manual.

Restricciones de uso de certificados: comodines y SAN

Generalmente, un certificado es válido para su uso en un único nombre de dominio completo (FQDN). Se trata de un certificado comprado para su uso en www.mydomain.com que no se puede usar en mail.mydomain.com o www.otherdomain.com.

Sin embargo, si se necesitan proteger varios subdominios, así como el nombre de dominio principal, puede comprarse un certificado Wildcard.
Un certificado Wildcard cubre todos los subdominios bajo un nombre de dominio en particular.

Por ejemplo, se puede utilizar un certificado Wildcard para *.mydomain.com en:

  • mail. mydomain.com
  • www. mydomain.com
  • ftp. mydomain.com

No se puede utilizar para proteger mydomain.com y myotherdomain.com.

Para cubrir varios nombres de dominio diferentes en un solo certificado, debe comprar un certificado con SAN.
Estos generalmente permiten proteger 4 nombres de dominio adicionales además del nombre de dominio principal. Por ejemplo, se podría usar el mismo certificado en:

  • www.mydomain.com
  • www.mydomain.org
  • www.mydomain.net
  • www.mydomain.co
  • www.mydomain.co.uk

Certificados Comerciales vs. Certificados Auto-firmados

Es posible crear nuestros propios certificados (Auto-Firmados) y calves de cifrado con herramientas Open Source. Estos certificados y claves son tan seguras como los comerciales, pero en algunas aplicaciones resulta conveniente utilizar los Certificados Comerciales (por ejemplo, para un Sitio Web). En general, cuando se necesite un soporte generalizado de los certificados en dispositivos comerciales, es conveniente utilizar un certificado comercial, ya que las principales entidades certificadoras comerciales están soportadas por la mayoría de los navegadores Web y Sistemas Operativos del mercado.

Por el contrario, en sistemas IoT, normalmente se utilizan certificados Auto-Firmados, sobre todo para los dispositivos clientes.

Codificaciones de certificados y extensiones de archivos

Los certificados se pueden codificar como:

  • Archivos binarios
  • Archivos ASCII (base64)

Las extensiones de archivo comunes en uso son:

  • .DER
  • .PEM (correo electrónico con privacidad mejorada)
  • .CRT
  • .CERT

Nota: No existe una correlación real entre la extensión del archivo y su codificación.

Flujo de mensajería al momento del establecimiento de una conexión TLS con Autenticación de Servidor (1-Way TLS)

Por defecto, TLS implementa la autenticación del Servidor (por medio del Certificado), y la autenticación del Cliente queda para la capa de aplicación (normalmente, por medio de Usuario y Contraseña o Token). El flujo de intercambio de mensajería para establecer una comunicación de este tipo es como se describe a continuación:

  1. El cliente envía un mensaje ClientHello proponiendo opciones SSL.
  2. El servidor responde con el mensaje ServerHello seleccionando las opciones de SSL.
  3. El servidor envía un mensaje de certificado, que contiene el certificado del servidor.
  4. El servidor concluye su parte de la negociación con el mensaje ServerHelloDone.
  5. El cliente envía información de la clave de sesión (cifrada con la clave pública del servidor) en el mensaje ClientKeyExchange.
  6. El cliente envía el mensaje ChangeCipherSpec para activar las opciones negociadas para todos los mensajes futuros que enviará.
  7. El cliente envía el mensaje Finalizado para que el servidor compruebe las opciones recién activadas.
  8. El servidor envía el mensaje ChangeCipherSpec para activar las opciones negociadas para todos los mensajes futuros que enviará.
  9. El servidor envía el mensaje Finalizado para permitir que el cliente verifique las opciones recién activadas.

Flujo de mensajería al momento del establecimiento de una conexión TLS con Autenticación mutua (2-Way TLS)

En la autenticación mutua, tanto el cliente como el servidor se autentican entre sí a través de certificados digitales. Los pasos son los siguientes:

  1. El cliente envía un mensaje ClientHello proponiendo opciones SSL.
  2. El servidor responde con el mensaje ServerHello seleccionando las opciones de SSL.
  3. El servidor envía un mensaje de certificado, que contiene el certificado del servidor.
  4. El servidor solicita el certificado del cliente en el mensaje CertificateRequest, de modo que la conexión se pueda autenticar mutuamente.
  5. El servidor concluye su parte de la negociación con el mensaje ServerHelloDone.
  6. El cliente responde con el mensaje Certificado, que contiene el certificado del cliente.
  7. El cliente envía información de la clave de sesión (cifrada con la clave pública del servidor) en el mensaje ClientKeyExchange.
  8. El cliente envía un mensaje CertificateVerify para que el servidor sepa que es el propietario del certificado enviado.
  9. El cliente envía el mensaje ChangeCipherSpec para activar las opciones negociadas para todos los mensajes futuros que enviará.
  10. El cliente envía el mensaje Finalizado para que el servidor compruebe las opciones recién activadas.
  11. El servidor envía el mensaje ChangeCipherSpec para activar las opciones negociadas para todos los mensajes futuros que enviará.
  12. El servidor envía el mensaje Finalizado para permitir que el cliente verifique las opciones recién activadas.

Referencias

SSL and SSL Certificates Explained For Beginners: http://www.steves-internet-guide.com/ssl-certificates-explained/

An Introduction to Mutual SSL Authentication: https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication