Header Ads Widget

Ticker

6/recent/ticker-posts

OAuth 2.0: por qué es vital para la seguridad de IoT


 En este artículo explicaremos por qué OAuth 2.0 es vital para la seguridad de IoT. Internet es fundamentalmente un lugar inseguro. Para cada servicio, cada API, hay usuarios a los que nada les encantaría más que romper las distintas capas de seguridad que ha creado.

Esto tampoco es una preocupación menor: solo en los EE. UU., Las violaciones de seguridad cuestan a las empresas más de $ 445 mil millones de dólares anuales . A medida que crece el Internet de las cosas (IoT), este número solo aumentará.

El problema es que nuestras consideraciones con respecto a la seguridad son para los servicios web y las API modernos; rara vez, si es que alguna vez, hablamos sobre la próxima ola de pequeños dispositivos IoT conectados y desconectados que pronto harán de esto una preocupación aún mayor.

Desde el refrigerador conectado hasta el reloj inteligente, el IoT abarca muchos dispositivos nuevos habilitados para la web que llegan al mercado. Mientras diseñamos nuevas infraestructuras de API, Jacob Ideskog cree que "la IoT nos va a afectar mucho si no hacemos nada al respecto".

Afortunadamente, existe una gran solución con el nombre de OAuth. OAuth 2.0 es una de las soluciones de autorización abierta más poderosas disponibles para los desarrolladores de API en la actualidad. Vamos a discutir OAuth 2.0, cómo funciona y qué lo hace tan poderoso para proteger el vasto Internet de las cosas.

Esta publicación se inspiró en una charla de Jacob Ideskog en la Cumbre de la Plataforma 2016:

¿Qué es OAuth 2.0?

OAuth 2.0 es un estándar abierto de autenticación y autorización basado en tokens para comunicaciones por Internet. La solución, propuesta por primera vez en 2007 en forma de borrador por varios desarrolladores de Twitter y Ma.gnolia, fue codificada en el borrador final de OAuth Core 1.0 en diciembre de ese año. OAuth se publicó oficialmente como RFC 5849 en 2010 y, desde entonces, todas las aplicaciones de Twitter, así como muchas aplicaciones en la web, han requerido el uso de OAuth.

OAuth 2.0 es la nueva evolución del marco que se publicó por primera vez como RFC 6749 junto con una definición de uso de token de portador en RFC 6750.

¿Qué hace OAuth?

Si bien, por definición, OAuth es un estándar abierto de autenticación y autorización, OAuth por sí mismo no proporciona ningún protocolo de autenticación . En cambio, simplemente proporciona un marco para las decisiones y los mecanismos de autenticación.

“OAuth no hace nada por la autenticación. Entonces, para resolver esto para la web, necesitamos agregar algún tipo de servidor de autenticación en la imagen ".

Dicho esto, funciona de forma nativa como un protocolo de autorización , o para ser más precisos, como un protocolo de delegación . Considere los cuatro actores de OAuth para comprender cómo logra esto:

  • Propietario del recurso (RO) : El propietario del recurso es la entidad que controla los datos expuestos por la API y, como sugiere el nombre, es el propietario designado.
  • Servidor de autorización (AS) : el servicio de token de seguridad (STS) que emite, controla y revoca tokens en el sistema OAuth. También llamado servidor OAuth.
  • Cliente : la aplicación, sitio web u otro sistema que solicita datos en nombre del propietario del recurso.
  • Resource Server (RS) : el servicio que expone y almacena / envía los datos; el RS es típicamente la API.

OAuth proporciona acceso delegado a los recursos de la siguiente manera. A continuación, se muestra un flujo fundamental en OAuth 2.0 conocido como flujo implícito :

  • El Cliente solicita acceso a un recurso. Lo hace poniéndose en contacto con el servidor de autorización.
  • El servidor de autorización responde a esta solicitud con una solicitud de devolución de datos, es decir, el nombre de usuario y la contraseña.
  • El servidor de autorización pasa estos datos a una solución de autenticación, que luego responde al servidor de autorización con una aprobación o una denegación.
  • Con una aprobación, el servidor de autorización permite al cliente acceder al servidor de recursos.

Cabe señalar que OAuth 2.0 admite una variedad de tipos de tokens . Los tokens de WS-Security , los tokens de JWT , los tokens heredados , los tokens personalizados y más se pueden configurar e implementar en una implementación de OAuth 2.0.

Lea también: Cómo controlar la identidad del usuario dentro de microservicios

Rasgos únicos de IoT que afectan la seguridad

Ahora que entendemos OAuth 2.0 y el flujo de trabajo básico, ¿qué significa para proteger el Internet de las cosas (IoT) ? Bueno, IoT tiene algunas advertencias únicas que deben tenerse en cuenta. Ideskog señala que los dispositivos de IoT suelen ser:

  • Alimentado por batería : los dispositivos de IoT a menudo son pequeños y cumplen una función particular, a diferencia de los recursos de servidor que tienen plataformas masivas basadas en cálculos y un flujo de energía consistente y desinfectado.
  • Asíncronos : están parcial o completamente fuera de línea, conectándose solo de forma asíncrona a través de dispositivos concentradores o cuando sea necesario para la funcionalidad.
  • Lean : por último, los dispositivos de IoT generalmente tienen capacidades de cálculo limitadas y dependen de dispositivos y servidores centrales para esta funcionalidad de procesamiento.

A pesar de todas estas advertencias, los dispositivos de IoT son objetivos extremadamente atractivos para los atacantes debido a sus funciones de uso único conocidas y a su seguridad relativamente laxa .

Relacionado: Intercambio de datos en IoT

Prueba de posesión

Debido a todas estas advertencias, el flujo de trabajo de OAuth es sorprendentemente diferente; de ​​hecho, estamos utilizando una metodología llamada Prueba de posesión . Considere un escenario de atención médica , en el que un médico debe acceder a un dispositivo EKG IoT. Dado que el dispositivo de IoT no puede realizar el mismo proceso de autenticación que un dispositivo de cliente completo, necesitamos hacer un poco de redirección.

El comienzo es normal. El cliente envía una solicitud de acceso al servidor de autorización. Desde aquí, el servidor de autorización se pone en contacto con el servidor de autenticación, que solicita al cliente los datos de autenticación. Cuando se proporciona esto, el servidor de autenticación se autentica en el servidor de autorización, que emite un código de autorización al cliente:

authorization_code = XYZ

A partir de aquí, nos desviamos del flujo de trabajo estándar de OAuth. El código de autorización es una prueba de uso único de que el usuario está autenticado, y este código se puede usar para contactar más a ese dispositivo de IoT como un dispositivo autorizado. El código no es algo que se pueda usar para acceder directamente a los datos como lo son otros tokens OAuth, es simplemente una prueba de que somos quienes decimos ser y que hemos sido autenticados y autorizados.

Luego, el Cliente genera una clave (aunque esta clave también se puede generar en el lado del servidor) para comenzar el proceso de conexión con el dispositivo IoT, enviando un paquete de datos que se parece a esto:

Client_id = device123
Client_secret = supersecret
Scope = read_ekg
Audience = ekg_device_ABC
authorization _code = XYZ
Key = a_shortlived_key

Con los datos en la mano, el servidor de autorización ahora responde a este paquete proporcionando un access_tokenuna referencia a los datos almacenados en la memoria del servidor de autorización para que sirva como prueba de posesión de autenticación y autorización:

Access_token = oddfbmd-dnndjv…

Este es el paso final: el cliente ahora está total y verdaderamente autenticado. Con esto access_token, el cliente puede iniciar una sesión en el dispositivo IoT. El dispositivo IoT lo examinará access_tokeny lo pasará al servidor de autorización (si es un dispositivo conectado) y solicitará una verificación para confiar en el dispositivo. Cuando el servidor de autorización acepta la verificación, pasa una nueva clave al dispositivo de IoT, que luego la devuelve al cliente, estableciendo una conexión confiable.

Flujo desconectado

¿Qué sucede si un dispositivo no puede solicitar la verificación al servidor de autorización debido a limitaciones de energía o de cálculo? En este caso, podemos usar algo llamado Flujo desconectado . Un punto clave para Disconnected Flow es, a diferencia de otras soluciones OAuth 2.0, que evita TLS (Transport Layer Security) debido a que el servidor de recursos es un dispositivo desconectado con conectividad intermitente y capacidad de procesamiento y comunicación limitada.

En este caso, en realidad estamos cambiando un poco las partes. La máquina de EKG es ahora el cliente, y otro dispositivo de IoT, un tubo de ensayo, es el servidor de recursos. Primero, la máquina de EKG autentica y autoriza de la misma manera que antes:

Client_id = ekg_device_ABC
Client_secret = supersecret
Scope = read_result
Audience = connected_tbie_123
Token = original_token
...…
Key = a_shortlived_key

Una vez que el servidor de autorización lo recibe, el servidor responde no con el token de acceso en la estructura anterior, sino con un access_token en JWT (o JSON Web Token). Este token es un token por valor, lo que significa que contiene los datos que se le envían y la respuesta. Mientras que nuestra primera cadena hacía referencia a una ubicación de memoria en el servidor de autorización, el JWT tiene todos los datos en una sola cadena de clave.

Desde aquí, el JWT se puede convertir a otros formatos para facilitar la lectura con el tubo de ensayo. Por diseño, el tubo de ensayo está diseñado para confiar en el servidor de autorización en un proceso llamado preaprovisionamiento . Debido a esto, cuando enviamos el token del Cliente en JWT (o cualquier formato que se haya elegido), el tubo confía implícitamente en la clave siempre que se haya originado en el Servidor de autorización y comience una sesión conectada con el Cliente.

Ideskog señala que técnicamente habría 2 tipos de tokens involucrados en el flujo anterior: un JWT firmado contendría un token cifrado (JWE), que tiene una clave que luego se usa para el canal de comunicación. El JWS (comúnmente llamado JWT) no está necesariamente encriptado y generalmente está en texto sin formato y firmado.
Relacionado: Desacople la identidad de usuario del diseño de API para crear microservicios escalables

Fallo de autorización de valor real

Para ver exactamente por qué todo esto es tan importante, considere algunas fallas de autorización del mundo real . Una de las fallas más visibles se conoce como The Snappening, una filtración de más de 90,000 fotos privadas y 9,000 videos privados de la aplicación Snapchat.

La mayor parte de la culpa del Snappening provino de los usuarios que utilizan aplicaciones de terceros no autorizadas para guardar Snaps. Estas aplicaciones de terceros no utilizaron soluciones OAuth, lo que significa que cuando los usuarios de acceso remoto intentaron usar la URL de Snapchat sin documentar en la que se basaba la aplicación de terceros, pudieron falsificar como usuarios autorizados y recuperar contenido sin la asignación de tokens adecuada.

Este es un gran ejemplo de OAuth 2.0 frente a ninguna implementación, ya que tenemos esencialmente una aplicación de "control" (Snapchat asegurada por OAuth) y una aplicación de "prueba" (las aplicaciones no autorizadas vinculadas a la API no documentada). Con una integración de autorización incorrecta, se permitió que el contenido se filtrara a través de un sistema inseguro con relativa facilidad. Si la aplicación de terceros hubiera implementado correctamente un esquema de autorización, esto nunca habría sucedido.

Sin embargo, este problema solo es relevante para cosas que no son de IoT: es solo una aplicación para compartir fotos, ¿verdad? Equivocado. Considere ahora esta misma falla de seguridad para algo como un botón de IoT que activa elementos comerciales de reemplazo. Atacar este dispositivo puede resultar en ataques man-in-the-middle para capturar direcciones de servidores de procesamiento de pedidos e incluso falsificar pedidos por una suma de miles o cientos de miles de dólares.

OAuth incrusta la confianza en el IoT

La aplicación de OAuth al IoT lo hace realmente extensible y personalizable. Con OAuth, podemos construir sistemas basados ​​en la confianza que utilizan recursos y protocolos de comunicación fundamentalmente seguros. OAuth, por diseño, se trata de confianza .

Esta confianza es clave para asegurar la IoT. Para los dispositivos conectados, la Prueba de posesión puede resolver la mayoría de los problemas de seguridad. Para entornos restringidos por conectividad o potencia de cálculo de procesamiento, los dispositivos se pueden proteger mediante un aprovisionamiento previo que es independiente de TLS y no requiere que el dispositivo esté en línea en todo momento.

Cabe señalar que JWT, JWS y JWE son herramientas útiles, pero todas funcionan con JSON. Para entornos de procesamiento inferior, se pueden usar tokens binarios hermanos como CWT , CWS y CWE, ya que se adaptan bien a la construcción de dispositivos de alcance limitado y de bajo consumo .

Conclusión

Esto no es un juego, aunque tener una seguridad laxa puede ser conveniente para la innovación y la experimentación, cuando se trata de IoT, este es un enfoque peligroso. Los dispositivos de IoT pueden tener poca potencia y ser de un solo uso, pero, como red, son poderosos.

Recuerde que una red es tan segura como la suma de sus partes y el punto de entrada más débil a su ecosistema. No asegurar un dispositivo IoT y adoptar un sistema de seguridad basado en la seguridad heredada puede resultar en un único dispositivo IoT que incluya todos los dispositivos conectados a él.

OAuth 2.0 puede ser de gran ayuda para resolver estos problemas.

Publicar un comentario

0 Comentarios