Control de acceso para dispositivo integrado

1

Desarrollamos un protocolo para el control remoto por computadora de un determinado tipo de juguete. Básicamente es una red de sensores y actores que generalmente está conectada a la PC del usuario a través de un puerto serie o USB. Ahora, algunos usuarios desean conectarse a través de Ethernet y queremos diseñar algún tipo de puerta de enlace en un dispositivo integrado.

Se espera que se use solo en redes LAN domésticas (por ejemplo, desde dispositivos móviles a través de un enrutador WiFi), pero estas no deben considerarse seguras y siempre existe la posibilidad de exponerse a Internet. Los riesgos involucrados son múltiples:

  • esos juguetes son caros y podrían ser destruidos por el abuso
  • el medio ambiente podría verse afectado por la alteración de las fuentes de alimentación del actor
  • los dispositivos son capaces de actualizaciones de firmware (no seguras) y pueden ser tomados o bloqueados
  • perturbación genérica de la operación de servicio
  • escuchas ilegales de datos privados

El dispositivo de puerta de enlace incrustada expondría algún tipo de servidor que acepta conexiones, que deben estar limitadas a las autorizadas. ¿Cómo hacer esto?

Después de la idea inicial de envolver nuestro protocolo serie en paquetes UDP (para baja latencia y baja sobrecarga), consideramos TCP para evitar lidiar con la pérdida de paquetes en redes inalámbricas. TLS es el siguiente paso lógico, que proporciona cifrado 1 . ¿Pero cómo realizar la autenticación y la autorización?

¿Es TLS aplicable en absoluto, cuando se usa en un contexto no web? No necesariamente tenemos nombres de host, ni siquiera acceso a Internet, y no sé cómo validar los certificados. No podemos usar una CA, por lo que nuestra PKI sería diferente y no sé qué agujeros de seguridad se introducen al administrar certificados manualmente. Probablemente ya sea un problema suficiente para que cada servidor, cada dispositivo, tenga su propio certificado generado de forma aleatoria. (También encontré estas dos preguntas relacionadas con problemas similares)

¿Algún tipo de proceso de emparejamiento (similar a Bluetooth o WPS) resolvería el problema con certificados sin validar? El dispositivo integrado estaría equipado con un simple botón para aceptar un cliente 2 , y el cliente recordará (¿"fijará"?) El certificado del servidor. Esta primera conexión sería susceptible a un ataque MITM, pero las conexiones subsiguientes no lo serían. ¿Eso suena viable y seguro? tengo dudas acerca de los planes de elaboración propia.

Una alternativa al emparejamiento que consideré sería un esquema de autorización de contraseña, donde el cliente envía una contraseña al servidor para obtener acceso. 3 Sin embargo, los usuarios tienden a elegir contraseñas débiles, y también yo no tengo idea de cómo (es decir, qué protocolo utilizar) enviar la contraseña a través de la conexión no segura (aún sin haber validado ningún certificado), evitando MITM o los ataques de reproducción.

Por favor, ayúdeme a encontrar una buena solución, ya sea respondiendo las preguntas anteriores o sugiriendo un enfoque completamente diferente que omití por completo. Nuestros principales objetivos / restricciones son:

  • buena facilidad de uso incluso para usuarios no técnicos, sin ningún mantenimiento administrativo
  • implementación sencilla con bibliotecas ampliamente disponibles para muchos lenguajes de programación
  • alto nivel de seguridad (si es necesario, ignorando la fase de configuración donde podría ser imposible)

1: Siempre que se usó con la configuración correcta, me reuní.
2: Supongo que no debemos olvidar una forma de eliminar clientes
3: Con la contraseña inicial asignada al azar a cada dispositivo e impresa en la parte inferior

    
pregunta Bergi 04.05.2017 - 04:27
fuente

1 respuesta

1

Esta es una pregunta bastante amplia, así que no puedo dar más que sugerencias. Primero en su nivel más bajo, la biblioteca SSL / TLS (OpenSSL) solo requiere que ambas partes involucradas en una comunicación tengan claves privadas y públicas y que cada una conozca la clave pública de la otra. Esa es la forma en que se usa, por ejemplo, en OpenSSH. Las infraestructuras PKI y CA y solo una forma de validar claves públicas para entidades que no se conocen entre sí.

En su caso de uso, podría usar una Autoridad de Certificación (privada) para validar los certificados para los dispositivos y, finalmente, los certificados para las PC cliente. Pero en caso de que una clave se haya comprometido, la renovación de un certificado sería difícil mientras no agregue mucha seguridad a un simple intercambio de claves públicas como lo hace OpenSSH.

Así que mi consejo sería:

  • encuentre / construya una forma aceptable de generar pares de claves aleatorias en los dispositivos y el software cliente. El punto positivo es que el dispositivo se ha vendido, el nuevo propietario puede instalar una nueva clave en él.
  • imagine y desarrolle una forma de intercambiar claves públicas entre un dispositivo y una PC. Algo así como transmitirlos en una ventana de tiempo seguida de un protocolo de acuerdo si se ha recibido una y solo una clave. Después de ese punto, la clave de igual se debe fijar en cada parte

De ahora en adelante, el dispositivo debería rechazar cualquier solicitud de conexión que no pueda demostrar el conocimiento de su clave de igual. Eso te permite:

  • confíe en la biblioteca de alta calidad de OpenSSL (o probablemente de LibreSSL).
  • permita que el propietario cambie las llaves de su dispositivo a voluntad si puede sospechar que su PC o dispositivo podría haber sido comprometido, o si por alguna razón el dispositivo o la PC perdieron su clave anterior (por ejemplo, la memoria del dispositivo). tuvo que ser reemplazado, o si el disco de la PC fallara
  • no requiere más de 2 botones (generar una nueva clave y comenzar una asociación) en el dispositivo o incluso un solo botón si una nueva asociación puede usar una nueva clave de forma consistente

Alternativamente, puede configurar un modo especial (activado por un botón en el dispositivo) en el que se aceptará cualquier certificado durante una ventana de tiempo y ese certificado se fijará para futuros intercambios, siempre que se haya recibido uno y solo uno. En ese modo, solo la conexión debería ser posible y no se procesaría ningún comando. Esta variante evita configurar un protocolo de intercambio de claves y simplemente confía en la capacidad de SSL para pasar certificados. Así que terminas en ambos lados con:

  • generación de un nuevo certificado autofirmado
  • en modo especial que permite el anclaje de un certificado de igual
  • todos los demás intercambios se basan en que el envío del certificado es el mismo que el certificado fijado

Sé que esto está lejos de ser una respuesta definitiva, pero podría permitir hacer preguntas más precisas aquí o en StackOverflow ...

    
respondido por el Serge Ballesta 04.05.2017 - 10:24
fuente

Lea otras preguntas en las etiquetas