Smart lock, una mirada paranoica

Hola GT Me gustaría ofrecer a la comunidad mi visión sobre las cerraduras inteligentes, una visión del investigador de seguridad y lo paranoico. Este artículo nació como un intento de dar un comentario detallado en respuesta a este artículo Dooris Clever Lock . Pero al final, el comentario se distrajo demasiado del artículo en sí, y decidí finalizarlo y presentarlo de forma independiente.

No soy conservador en materia de progreso. Creo que IoT es algo muy prometedor, estoy esperando autos sin conductores, creo en la electrónica portátil y desde la implantación de etiquetas NFC, solo me detiene la falta de características adicionales realmente interesantes que potencialmente recibiría. Es por eso que me alegro cuando las cosas obtienen el adjetivo "inteligente". Pero no solo la tecnología debe ser inteligente, sino también su desarrollador (bueno, el usuario, preferiblemente, también).

Después de una breve introducción, expresaré de inmediato la tesis principal: una cerradura inteligente no debería poder abrir un departamento. Ahí tienes. Además, en principio, no debería ser mecánicamente imposible, y no una prohibición de software.

Argumento 1. No confío en el desarrollador

No siento nada personal para Alexander, pero ¿puede garantizar que no haya ningún marcador que le permita abrir la cerradura? Puede ser un marcador de software que "atrapa" un "vehículo de todo terreno todo terreno" especial o un marcador de hardware, por ejemplo, en interruptores de láminas. Lo peor de todo, podría ser un error banal en el mundo real. El propio autor menciona

"Además, Dooris puede bloquear la puerta por error mientras está abierta, si la abres de cierta manera mientras la tocas".

Desde el punto de vista del castillo, según tengo entendido, no es particularmente importante en qué dirección girar, por lo que potencialmente se puede leer la frase anterior y como "... está mal abrir la puerta mientras está cerrada ...". Para convencer de que no hay marcadores en el código, el autor sugiere publicar el código fuente. Pido disculpas, tal vez me quede atrás de la vida, pero en el momento en que era programador, la tarea de comparar las fuentes y el archivo binario era extremadamente difícil. Estoy en silencio porque el archivo binario de la cerradura todavía necesita ser sacado. ¿Es este el único firmware? ¿Hay solo un controlador dentro de la cerradura? ¿Tiene un gestor de arranque? ¿Pero no puedes reflash por el aire?

Argumento 2. El desarrollador puede estar equivocado

Y no necesariamente el desarrollador de una cerradura electrónica. De hecho, este argumento es una modificación del anterior. Los programadores de controladores inalámbricos también son personas, y Ping of Death, aunque fue hace mucho tiempo, no es ficción. No quisiera que la puerta se abriera solo por el hecho de que alguien pasó con un teléfono inteligente, cuyo nombre bluetooth comienza con un número .

Argumento 3. No confío en la gobernanza de Internet

Si el castillo se puede controlar a través de Internet, entonces el vector de ataques aumenta muchas veces. ¿Dónde está este servidor? Si los desarrolladores tienen un servidor centralizado, pueden abrir mi candado con una probabilidad del 99%. Si el servidor se eleva desde el cliente, los dos primeros argumentos ya se aplican a este servidor.

Que hacer

Usted critica - ofrece. Como una cerradura no puede abrir una puerta, ¿qué puede hacer? Para mí personalmente, un problema común con la cerradura es que no puedo recordar, pero ¿la cerré? Por lo tanto, en el bloqueo inteligente, veo principalmente la funcionalidad para monitorear el cierre a través de Internet. Para que en cualquier momento pueda mirar un sitio especial donde todo está bien, la puerta está cerrada. Y si esto no es así, podría notarlo rápidamente.

Pero esto no es tan simple: yo, como paranoico, no quiero que nadie descubra si mi puerta está abierta o no. Criptografía FTW. La familia de protocolos "entrega de bits al almacenamiento" me parece perfecta. Esta familia de esquemas de protocolo le permite confirmar cualquier dato sin revelarlo directamente.

Además, mencionaría otra función. Una oportunidad para cerrar la cerradura. Funcionalidad bastante controvertida. En realidad, su único uso es que por la mañana se fueron y no cerraron la puerta, miraron el sitio web o la aplicación y se enteraron, cerraron la cerradura. Pero la presencia de dicha funcionalidad agrega muchos problemas.

Alguien puede cerrar la puerta en su lugar (todos esos 3 argumentos que estaban arriba). Saliste a tirar la basura y ahora te paras en las mismas zapatillas afuera. Cuanto más confiable sea la protección, más inconveniente será su uso. Veo algo como este escenario: en la cerradura puede establecer la combinación de código en la forma de bloqueos de combinación. Solo el envío de dicha combinación cerrará la puerta, y después de cerrar la combinación se reiniciará.

Además, al motor, en general, no le importa en qué dirección rotar. Además, la rotación en sentido antihorario no siempre cierra la puerta. Resulta que "programáticamente", si la puerta se puede cerrar, entonces, potencialmente, se puede abrir. Aquí, la solución es la siguiente: en la etapa de configuración, el usuario bloquea físicamente la rotación de la cerradura en uno de los lados (a la manera de un destornillador de trinquete). Pero entonces será difícil abrir tal cerradura con una llave.

En general, una función bastante controvertida, que, aunque puede ayudar, es potencialmente difícil de implementar.

En este artículo traté de presentar mi visión de un castillo inteligente, e invito a quienes deseen debatir en los comentarios.