Autenticación de hardware del dispositivo Linux en sistemas de nivel superior

Industrial IoT es monitoreo, programación y automatización de sistemas de ingeniería de instalaciones industriales, edificios, instalaciones comerciales. Los sensores de varios parámetros, medidores y controladores recopilan datos de estos objetos, por ejemplo, temperatura y humedad en la sala de servidores, medidores de agua en edificios de apartamentos, el nivel de dióxido de carbono en las habitaciones. Los controladores procesan esta información y envían todo a la "nube".

Wiren Board fabrica controladores de Linux para IoT industrial. Los dispositivos recopilan datos de pozos petroleros y sucursales bancarias, monitorean el microclima en servidores y supermercados. Los controladores se integran con los sistemas de nivel superior de los socios de la compañía. Los sistemas autentican dispositivos: entienden que están hablando con su sensor y no con el de otra persona, y luego lo autorizan. En esta etapa, surge un problema: hay miles de controladores, cientos de clientes, pero no hay un único sistema de integración. Los métodos tradicionales simples, como los pares de inicio de sesión / contraseña, son vulnerables a los ataques e incómodos de implementar.



Por lo tanto, la compañía desarrolló la autenticación en sistemas de nivel superior utilizando claves de hardware, basadas en criptografía asimétrica estándar utilizando un elemento protegido por hardware para almacenar claves. Ahora no se necesita un sistema de integración unificado: la autenticación y la autorización están protegidas y funcionan de inmediato. Evgeny Boger le dirá cómo hacer esto: cómo eligieron el "chip de cifrado", cómo lo atornillaron al hardware y Linux, cómo se hicieron las bibliotecas y el software comunes para ser amigos de él. Especial énfasis en la implementación: la introducción de la inicialización del dispositivo en producción, la introducción de soporte para varios software de nivel superior, incluso en el de otra persona y cerrado.

Sobre el orador: Eugene Boger ( evgeny_boger ) - CTO y cofundador de Wiren Board. Comprometido en sistemas embebidos y, especialmente, Linux embebido.

Los problemas

Para empezar, qué estamos haciendo y de dónde vino este problema. En Wiren Board diseñamos y fabricamos equipos en Rusia. Solía ​​llamarse M2M, pero ahora - IoT industrial. Esta es la automatización de sistemas de ingeniería de edificios, monitoreo y programación. Brevemente, todo el trabajo se ve así: los sensores de varios parámetros, actuadores, contadores y controladores (edge-computing o IoT-gateway) recopilan diferentes datos de los objetos, los procesan, ejecutan la lógica local y luego los reúnen en un gran sistema de despacho, monitoreo o control .



No tenemos un ecosistema completo, a diferencia de algunos competidores. Fabricamos equipos que se integran con varios sistemas de alto nivel de nuestros socios. Hay muchas empresas asociadas y comparten la responsabilidad. Sin buenos medios técnicos, la integración no funcionará, simplemente no se puede negociar.

Hay dos soluciones simples para resolver estos problemas. El primero es dar el nombre de usuario / contraseña al cliente , como todos lo hacen, y el segundo es generar y coser el "secreto" en el lugar de trabajo . Ambas opciones no nos convenían. Te diré por qué.

Soluciones simples

La primera solución es emitir un nombre de usuario y contraseña para el cliente . Todos lo hacemos hasta hace poco.

Para autenticar un dispositivo que envía datos a algún sistema, puede crear una clave secreta: inicio de sesión / contraseña condicional ("secreto"). Será común en los controladores y en un sistema de nivel superior que recopila datos de varios controladores.

Un par de nombre de usuario / contraseña (un "secreto" común) debe de alguna manera ser entregado al cliente, la empresa o la persona. Alguien debe generar un par secreto, enviarlo por correo electrónico, autenticar al cliente por número de cuenta. Este es el procedimiento estándar: baja tecnología.

Problema Es que tenemos muchos de esos sistemas. Nuestro cliente, y él puede enviar datos al sistema de nuestro socio. Esta es una interacción compleja entre todas las partes involucradas.

Además del problema de muchos sistemas, hay otros.

• Mala entrega y entrega al cliente .
  
• Los inicios de sesión y las contraseñas se almacenan en el servidor . Si también almacenamos hashes, esto nos protegerá un poco de las fugas. Pero aun así, surge una sensación desagradable cuando las claves secretas para todos los controladores de clientes se almacenan en el servidor. Algunos de ellos pueden ocuparse de tareas críticas: iluminación exterior, monitoreo de plataformas petroleras.
  
• Sincronización entre servicios .
  
• Recuperación de pérdidas . No está claro qué hacer en caso de pérdida, cuando el cliente borró la memoria del controlador, ¿en qué memoria debo escribir? Tienes que repetirlo de nuevo.
  
• Protección contra copia de detalles . Existen sistemas de monitoreo pagados que brindan al cliente un servicio y cobran tarifas de suscripción. No quiero que el cliente final pueda evitar el sistema de alguna manera: pague una vez, pero use dos.
  

La segunda solución es generar y coser un "secreto" en la producción . Esta es una mejora con respecto a la solución anterior.

El esquema es este: nosotros, como fabricante de controladores, pregeneramos nombres de usuario y contraseñas para todos, los cosemos en nuestro sistema y los ingresamos en el equipo. Los inicios de sesión y las contraseñas del equipo no se pueden leer ni modificar. Esto es mejor que la opción anterior, ya que no requiere interacción entre las personas.

Los problemas Todos los problemas persisten, excepto el primero, pero el principal es la sincronización entre los servicios y la intranet . Hay muchos servicios y no está claro cómo sincronizarlos; debido a esto, no pudimos implementar la segunda solución. Tenemos clientes que usan equipos en sus redes cerradas. Lanzamos un nuevo controlador, lo vendimos a un cliente y su sistema está cerrado. Está configurado, funciona una vez y es difícil transmitir aún más los "secretos". ¿Informar en lotes? Todo es complicado en las organizaciones, aunque técnicamente simple.

Ambas soluciones no nos convenían. Por lo tanto, decidimos tomar un camino diferente. Pero antes de eso decidieron esbozar metas y objetivos comunes.

Tareas y objetivos

Primeras tareas comunes.

Autenticación Esta es una forma de entender quién está hablando con el sistema de nivel superior, quién se conecta exactamente al sistema de despacho.

La autenticación no es otorgar o delimitar los derechos de acceso, sino una forma de entender quién nos está hablando.

La tarea de enviar datos . Nuestros controladores son computadoras Linux diseñadas para una tarea especial. Los necesitamos para enviar datos a sistemas de nivel superior, conectarse a través de VPN. Al mismo tiempo, queremos que el envío funcione de forma inmediata, sin la configuración ni la interacción de nuestros clientes y usuarios finales del sistema con nosotros y con los clientes.

Otras tareas Esta es una conexión confiable, encriptación del canal de datos, pero un problema separado es la autorización . La tarea de autorización está asociada con servicios externos y se divide en tres partes.

• Servicio de fabricante gratuito . Proporcionar acceso por número de serie del dispositivo.
  
• Listas blancas de números de serie para el servicio de nuestros socios: enlace de compras y accesos a la cuenta del cliente.
  
• Licencias Permitir o denegar el acceso según las opciones especificadas en el certificado.
  

Los objetivos son lo que queremos lograr cuando resolvemos problemas.

Emisión y entrega al cliente . Sin la participación de las personas: los robots cosen la información en la producción.

Recuperación de pérdidas . Queremos que no haya pérdida de detalles secretos en absoluto.

Entrega de producción a servicios . Queremos prescindir de él, para que no necesite entregar nada a los servicios. Al lanzar nuevos equipos, no queremos actualizar las bases de datos de todos los servicios que deberían autenticar estos dispositivos.

Almacenamiento en el servidor . Es aconsejable no almacenar nada allí en absoluto.

Sincronización entre servicios e intranet . También es aconsejable no sincronizar nada, porque no almacenaremos nada.

Protección contra copia de detalles . Queremos algo secreto, por el cual se toma el dinero, fue imposible copiar y recibir de forma gratuita.

Firma digital se apresura al rescate

La firma digital electrónica (EDS) es una tecnología en torno a la cual todo funciona para nosotros.

Es como una firma ordinaria, solo digital. EDS es fácil de verificar, pero difícil de falsificar. Las verdades familiares de la criptografía, que tienen décadas de antigüedad.

Una firma electrónica es algo que un mensaje puede contar si conoce la clave privada secreta (clave privada). Si conoce la clave pública (clave pública), es fácil verificar que la firma electrónica del mensaje sea correcta. El nombre es claro: el público está acostumbrado a informar a todos, y el secreto es solo para quien firma.

Todas las firmas y claves son solo números.

En nuestro caso, se trata de 32 bytes de datos, que funciona en "magia" matemática. Math garantiza que la firma sea fácil de verificar, pero difícil de falsificar.

Utilizamos la firma ECDSA-256 + SHA-256:

• e = HASH(m) : la función hash criptográfica convierte irreversiblemente el mensaje m en el número e;
  
• private key (dA) - número aleatorio;
  
• public key (QA) : generada a partir de una clave privada, pero no viceversa;
  
• signature (r,s) = sign(private key, e) - firma;
  
• verify(public key, signature, e) - verificación de la firma.
  

Autenticación EDS. Primer intento

¿Qué se puede hacer para nuestra tarea utilizando este mecanismo complicado, que funciona en una dirección simple y en la otra difícil?

Emisión y entrega al cliente . Generamos una clave privada aleatoria para cada dispositivo en la producción. No se lo decimos a nadie, porque ni siquiera lo conocemos, y escribimos en el dispositivo.

Entrega de producción a servicios . A continuación, usamos solo la clave pública de este dispositivo para la autenticación en los servicios. En los servicios, solo almacenamos una lista de claves públicas en lugar de contraseñas.

Algoritmo de comprobación de estado estándar:

• el servicio envía un mensaje aleatorio m al controlador;
  
• controlador: sign(private key, m) ;
  
• el controlador envía una firma al servicio;
  
• servicio: verify(public key, signature, m) .
  

Lo único que decidimos de esta manera es que ya no almacenamos "secretos" comunes en nuestros servicios en forma abierta o en caché. Esto no es lo que queremos.

Autenticación EDS. Segundo intento

No queremos almacenar algo en los servicios. Para lograr esto, podemos obligar a nuestros dispositivos a enviar sus claves públicas al servicio.

En la última etapa, resolvimos dos problemas. El primero: comprobamos que dieron la clave del servicio . Tenemos una clave pública, lo que significa que también creamos una clave privada. El segundo: nos aseguramos de que el dispositivo posee una clave privada , que se encuentra en algún lugar de la unidad flash USB. Si el dispositivo puede firmar algo, entonces tiene una clave privada.

Ahora el dispositivo también enviará la clave pública al servicio. ¿Cómo comprobar que nadie lo interceptó, que no lo fingió y que todo funciona?

Comprobando la clave pública . Nos creamos otra clave pública. Será nuestra clave como fabricante. Esta es la clave raíz "clave privada raíz + clave pública". Con esta clave secreta raíz en producción, firmaremos la clave pública del dispositivo y almacenaremos esta firma en el dispositivo. El dispositivo debe enviar su clave pública y la firma de su clave pública al servicio. Ahora el servicio puede verificar la clave pública del dispositivo. Si está firmado con la clave privada raíz, emitimos esta clave.

Solo el fabricante: podemos crear y almacenar una firma en el dispositivo, pero verificamos todo.

Publicamos la clave pública en el sitio en la sección "Contactos". Cualquiera puede tomarlo y verificar la clave pública del dispositivo que envió el dispositivo al servicio. Luego puede verificar que el dispositivo tenga su propia clave privada.

El algoritmo general se ve así.

• (once) random root private key ;
  
• factory: random device private key ;
  
• factory: sign(root private key, device public key) = signature_1 ;
  
• device->service: device public key + signature_1 ;
  
• service: verify(root public key, signature_1, device public key)?
  

Resultado del segundo intento

Resolvimos el problema con la entrega al cliente: la información se cose en el sitio de producción y no es necesario restaurar nada .

Es importante que resolvamos el problema de entregar "secretos" a los servicios de nivel superior , porque todo lo que se necesita almacenar en el servicio es la clave pública del fabricante. La clave completa es de 33 bytes. Con su ayuda y magia matemática, puede continuar haciendo una conexión de protocolo de enlace y verificar que el dispositivo tenga la clave privada correspondiente.

En el servidor solo almacenamos la clave del fabricante (clave pública raíz).

No tenemos sincronización entre los servicios y la intranet , de la que ya hemos hablado. Además, no tenemos protección contra la copia de detalles .

Lo único que olvidamos es la autenticación . El dispositivo envió una clave privada, y verificamos que lo hicimos y lo emitimos, y verificamos que el dispositivo lo posee. Pero no sabemos qué tipo de dispositivo es este, y producimos miles de ellos.

Por lo tanto, aplicamos un truco llamado "Certificado".

Autenticación y Certificados

En este paso, en toda la magia matemática con firmas y sus cheques, agregamos información adicional: un certificado . Para hacer esto, firmamos en la fábrica no solo la clave pública (clave pública del dispositivo), sino también la clave con información adicional.

Información adicional en nuestro caso.

• Fecha de fabricación y fabricante.
  
• Modelo y configuración de hardware.
  
• El número de serie mediante el cual se puede autenticar el dispositivo.
  
• Opciones: hardware y software. Las diferentes configuraciones pueden no diferir físicamente entre sí, pero el certificado contendrá información sobre lo que pagó el cliente.
  
• Nombre del cliente y número de cuenta.
  

Firmaremos toda esta información junto con la clave pública con nuestra clave de productor: clave pública raíz. Después de eso, la información irá a los servicios y podrán asegurarse de que sea correcta. Dado que estos son nuestros servicios y los de nuestros socios, confían en nosotros.

Estado del objetivo

La información también se cose en la fábrica y no es necesaria la entrega a los servicios. En el servidor almacenamos solo la clave del fabricante.

Recuperación de pérdidas . Cosemos toda la información de los certificados en la memoria flash del dispositivo. Teóricamente, se puede eliminar accidental o intencionalmente, pero no hay nada secreto en esta información en el certificado. Incluso la firma en sí no es secreta: hay una clave pública y la firma con nuestra clave. El único secreto en el certificado son los volúmenes de ventas de dispositivos con diferentes opciones.

El certificado puede almacenarse en la fábrica y enviarse al cliente si lo pierde. Los clientes rara vez borran específicamente el área de servicio de la memoria. Por lo general, hacemos esto durante el procedimiento de recuperación del dispositivo: el dispositivo llegó del cliente, se pasó por completo a través de la inicialización, todo se borra, se descarga nuevamente y el certificado se copia de la base de datos de fábrica.

No tenemos recuperación de pérdidas, protección de copia y sincronización entre servicios .

En la etapa de autenticación, recibimos y verificamos el certificado. Entendemos qué tipo de dispositivo es: conocemos el fabricante, el modelo y el número de serie, qué puede y qué no puede hacer.

Iniciar sesión

El certificado le permite almacenar información para su autorización.

Servicio de fabricante gratuito . Conociendo el número de serie del dispositivo, puede dar acceso a todos. En nuestros servicios damos acceso a todos nuestros clientes base.

Listas blancas de números de serie . Para el servicio de nuestros socios, puede crear una tabla con una lista blanca de números de serie: "El cliente Vasily nos compró dos controladores con dichos números de serie asociados con su cuenta"

Licencias Puede vender algo por adelantado y luego permitir o denegar el acceso según las opciones especificadas en el certificado: un controlador con licencia para el sistema X.

No existe una base común entre servicios, fabricante o fabricante de sistemas. Todo funciona exclusivamente con la información del controlador que firmamos nosotros, como fabricante, cuando se autentica en el sistema.

Certificado Intermedio

Otro problema técnico que resolvimos en el camino. En el esquema del que acabo de hablar, hay un certificado raíz del fabricante: clave privada raíz. Se necesita físicamente cada vez que crea un dispositivo. Pero si hay muchos dispositivos, entonces esta clave necesita acceso constante para un círculo limitado de personas. Esto es malo, porque si lo pierde, tendrá que actualizar las claves públicas en todos los servicios, y no debería llegar a los atacantes. Estos son grandes problemas de organización. Pero hay una solución.

Introducimos claves intermedias para un lote de dispositivos que no dan tanto miedo de perder.

Hicimos lo mismo, solo que la cadena es más larga.



Con un certificado de fabricante, firmamos la clave intermedia. Físicamente, esta es una "unidad flash", que se entrega al capataz en la fábrica por un día. El hardware limita la cantidad de dispositivos que una clave puede firmar. En el medio del esquema, agregamos un certificado intermedio, de lo contrario, nada cambió.

Almacén de claves seguro

En todo esto, no tenemos suficiente protección para la clave privada del dispositivo ; este sigue siendo un archivo que se encuentra en una unidad flash USB. Un atacante puede copiarlo, pero lo más probable es que lo pierda o abra accidentalmente el acceso.

En el caso ideal, sería bueno proteger la copia de la clave privada del dispositivo; póngala en un cuadro negro.

La caja negra realiza 4 operaciones:

• dentro de sí mismo genera una clave a pedido, pero no da;
  
• da la clave pública;
  
• Firma un mensaje
  
• Verifica la firma.
  

Para verificar la firma, solo necesita una clave pública, por lo que tres operaciones son suficientes.

En mi opinión, esta debería ser una solución de hardware, preferiblemente separada del procesador. Hay varias opciones, la mejor de las cuales es un procesador criptográfico especial dentro del SoC o como un chip separado.

La primera opción de recuadro negro que revisamos es el módulo CAAM en los procesadores NXP i.mx 6, 7, 8 que utilizamos. El problema es que se implementa mediante programación en la ROM de arranque del procesador.

Puede contener errores que se pueden encontrar e incluso explotar a través de otras funciones del procesador. Hace un par de años, se encontró un agujero en este módulo que hizo posible omitir la verificación de firma al descargar el firmware. Esta no es la funcionalidad que necesitamos, pero el sedimento permanece. Otro problema es que es difícil importar procesadores con este módulo a Rusia; requieren completar el papeleo.

Por lo tanto, tomamos un chip por separado. Admito honestamente, conté con el hecho de que si no podemos traerlo a Rusia, se nos ocurrirá algo: el chip es pequeño, cuesta $ 1. Pero todo salió bien: encontraron el chip Microchip ATECC , que ya tiene todos los documentos.

Microchip ATECC608A

Este es un chip pequeño separado que cuesta un centavo. El chip está conectado a través de I2C, dos "patas" del procesador, que también puede compartir con otros periféricos. El chip tiene un pinout estándar. Usamos el chip en las primeras versiones del equipo y simplemente lo soldamos encima de otro chip con el mismo protocolo y pinout, porque es estándar.

El chip puede hacer lo que necesitamos de dicho chip: leer firmas, almacenar claves y mucho más.



Caracteristicas

• 16 ranuras para teclas;
  
• puede leer firmas ECSDSA, hashes, MAC y cifrar AES, puede DH;
  
• tiene un generador de números aleatorios y contadores criptográficos;
  
• Cajas: SOIC-8, DFN6;
  
• protocolos: I2C, cable simple;
  
• ~0.7$@1000pcs.
  

Cómo trabajar con un microcircuito

Hay documentación decente para ello , pero bajo la NDA. Si escribe inmediatamente a gamma.spb.ru, se lo darán en 2 semanas. Si está en otra empresa, después de 3 meses. Escribimos a dos compañías, y cuando lo hicimos todo, otro distribuidor de Microchip nos respondió.

Hay pocas notas y son peores que el promedio. Hay software en GitHub , una biblioteca con HAL. Es divertido: la documentación está bajo el NDA, y el software que está escrito está en GitHub. El software no es compatible con Linux, pero es compatible con Raspberry Pi y Atmel MK, esto es un poco diferente. Los desarrolladores creen que en todos los equipos solo hay un bus I2C, por ejemplo, las patas se llaman como en la Raspberry Pi.

Hay integración con OpenSSL , no funciona bien, pero lo hace. No hay ejemplos en Linux ni trabajo con personalización .

Personalización de chip

La personalización es el mayor dolor de cabeza con el chip.

El problema es que el chip puede hacer muchas cosas. Tiene 16 ranuras en las que se almacenan 16 claves: datos de usuario o claves públicas, o almacenamiento temporal para otras ranuras: hay muchas opciones.

Debe restringir de alguna manera el acceso a las ranuras, y también hay muchas opciones de configuración: restringir por contraseña, por autenticación en otra ranura, en el momento del acceso a las fábricas.


En la tabla, el tipo de clave, acceso de lectura y escritura, la relación entre las ranuras: SlotConfig, KeyConfig.

En la máscara de bits (16 bits) de cada clave que usamos, hay diferentes números en todas partes.

Lo más triste es que la zona de configuración es única, lo que establece las funciones de las ranuras. Arruinamos 50 fichas antes de hacer todo bien. El chip solo funciona después de bloquear la configuración . Por separado, hay un bloqueo para ranuras individuales

No hay documentación en los ejemplos o en el software. Hay documentación para bits individuales, pero todo es complicado allí. En todos los ejemplos de Microchip está escrito: "Descargue ese bloque, y de alguna manera funcionará para usted, como en el ejemplo del envío de datos a Amazon".

Tomó mucho tiempo, pero en el proceso hicieron una gran utilidad.

Utilidad Atecc-util

Esta es una utilidad de consola que puede realizar la mayoría de las funciones del chip y le permite trabajar un poco más fácilmente. Está disponible en GitHub bajo una licencia MIT.

La utilidad usa CryptoAuthLib. Ella sabe cómo trabajar de manera más amigable con la zona de configuración, sabe cómo trabajar con SHA, MAC, ECDSA, DH. La interfaz es fácil de usar porque, en primer lugar, creamos la utilidad para usar en scripts. El hecho de que una persona pueda causarlo es una característica secundaria. La utilidad puede hacer una lista, un plan de comandos: "Primero, personalice esta zona, luego escriba dicha clave".

Un ejemplo de llamar a una utilidad es bastante legible para los humanos.

 atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump' 

La utilidad está construida bajo Linux, bajo AMD64, está en el paquete Debian.

Otras herramientas de personalización

Tenemos una placa Excel para leer los bits. Si nos muestra un escaneo NDA con Microchip, se lo daremos.



Cubrimos todo con pruebas, ya que hay muchas opciones cuando puede olvidar un bit y algún comando de servicio leerá su clave privada. Las pruebas prueban el dispositivo real. Se dirigen al microcircuito y verifican la configuración correcta en el dispositivo: ¿se puede leer esta ranura, se puede hacer tal firma?

Paralelamente a los bits, creamos una lista de garantías que este dispositivo debería satisfacer y verificamos cómo funciona todo. Usamos el marco de murciélagos , algo muy interesante. Se ve así.


Lista de pruebas para un ejemplo. Los superiores se pasan, pero los inferiores no.

Configuraciones en dispositivos

Para nosotros, usamos solo dos espacios para la tarea de la que estoy hablando. En ambos almacenamos la clave privada del dispositivo. La diferencia es que el primero está asociado con un certificado permanente , que se emitió en 1970 por 200 años.

Esto se debe al hecho de que en IoT el tiempo no siempre está sincronizado. La infraestructura del certificado implica verificar la validez de un certificado. Si se interrumpe la sincronización en los dispositivos, puede fallar algún servicio vital, por ejemplo, VPN.

Por lo tanto, una ranura es infinita, permanente . Se genera una vez y no cambia durante la vida útil del dispositivo. Para esta clave, se genera un certificado por 200 años, para redes cerradas.

Se está actualizando otra ranura. La vida útil máxima del certificado es de un año. Esto se hace en caso de que algo se vea comprometido. Se genera una clave privada de dispositivo actualizable a medida que expira el período de validez del certificado del dispositivo. Se utiliza para la autenticación en redes abiertas, se actualiza una vez al mes o menos, junto con un certificado.

Para los usuarios, generamos varias combinaciones , incluidas varias ranuras para claves privadas ECDSA. Los usuarios pueden generar su clave en una ranura separada si no confían en nuestra clave privada. Para esto solo necesita confiar en Microchip. Los usuarios pueden leer firmas, encriptar; dimos todo lo que el chip puede hacer.

Hasta ahora, desafortunadamente, nadie lo ha usado, pero esperamos que sí.

Infraestructura: claves intermedias

Ya dije que en algún momento implementamos certificados intermedios para no brillar con un certificado raíz que no debería perderse. Nunca aparece en una fábrica.



Los certificados físicamente intermedios son un chip ATECC508A. Difiere ligeramente de 608, pero en 508 hay una funcionalidad útil para las teclas, pero en 608 ya no está allí.

El chip está conectado a través de un adaptador USB-I2C. Este es USBISP con firmware tiny-usb-i2c, un programador que se puede instalar en un puente USB-I2C. Los certificados intermedios firman certificados de dispositivo con su clave privada.

Dos características del microcircuito nos resultaron útiles.

Ranura de protección de contraseña de hardware . El chip se puede programar para leer la firma solo si se cumplen dos condiciones:

• cuando el dispositivo está atascado en una computadora;
  
• contraseña ingresada
  

Le damos al capataz de producción una clave y contraseña intermedias para varios controladores. En consecuencia, debe robar tanto la clave como la contraseña para obtener acceso. Tenemos esta oportunidad de forma gratuita, pero mejora la seguridad del sistema.

Límite de hardware en la cantidad de usos . El contador criptográfico en el interior solo puede aumentar. Cuando alcanza un límite predeterminado una vez, el microcircuito no firma nada más.

OpenSSL en el cliente

Consideremos cómo funciona todo en el cliente. Tenemos OpenSSL en el controlador. No inventamos nada: esto es TLS ordinario, PKI ordinario. Además, necesitábamos una biblioteca cliente. En la gran mayoría del software de Linux, se usa para una conexión segura.

Tomamos el código de Microchip, lo agregamos un poco, admitimos el nuevo OpenSSL
1.1. Como resultado, él sabe cómo trabajar con una clave de hardware: el hardware admite contraseñas para claves privadas.

Se ve algo como esto.

 openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr 

Esta es una llamada a OpenSSL regular y una instrucción para usar el módulo de motor apropiado. La clave se establece aquí: dirección, modelo y los dos últimos bytes es el número de la ranura que se utiliza. Todo se transmite como si fuera un archivo clave, pero no es un archivo: debe ingresar al dispositivo.

SSL en el servidor

Cualquier SSL funciona en el servidor, incluido OpenSSL. No se necesitan modificaciones ni compilaciones personalizadas en el lado del servidor. Todo lo que se necesita en el servidor es poder verificar la cadena del paquete de certificados (dispositivo cert + certificado intermedio) y almacenar nuestra clave pública , que publicamos en el sitio - Wiren Board ROOT CA.

El TLS estándar dice que ambas partes deben autenticarse mutuamente. — — . — handshake.

: . , . letsencrypt SSL, , .

, — MQTT.

MQTT: mosquitto

IBM. .

Mosquitto — , , Linux. , OpenSSL engine ( ) «keyfile», . , 20 .

bundle.



.

 mosquitto_sub -h mqtt.wirenboard.com -p 8884 -cert /etc/ssl/device/device_bundle.crt.pem --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --capath /etc/ssl/certs/ -t /# -v 

. — -cert . bundle- — . --key . .

, --capath , . SSL-, letsencrypt.

.

 root@wirenboard-AXXVJI62:~# cat /etc/mosquitto/conf.d/bridge-hw.conf connection wb_devices_cloud.wirenboard-AXXVJI62 address contactless.ru:8884 bridge_capath /etc/ssl/certs/ bridge_certfile /etc/ssl/device/device_bundle.crt.pem bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00 notifications true notification_topic /client/wirenboard-AXXVJI62/bridge_status topic/# both 1 ""/dient/wirenboard-AXXVJI62 

Mosquito- .

Mosquitto — .

 per _listener_settings true listener 8884 0.0.0.0 cafile/etc/mosquitto/certs/WirenBoard_Root_CA.crt certfile /etc/letsencrypt/live/contactless.ru/fullchain.pem keyfile/etc/letsencrypt/live/contactless.ru/privkey.pem require.certificate true use_identity_as_username true password_file /etc/mosquitto/passwd.conf allow_anonymous false acl_file /etc/mosquitto/ad.conf :~$ cat /etc/mosquitto/acl.conf pattern write /client/%u/# pattern read /client/%u/# 

— .

• Root CA letsencrypt- — . .
  
• Mosquitto. username MQTT.
  
• , , , (CN) wirenboard-AXXVJI62, , .
  
• per_listener_settings: , / (>1.5.5).
  

MQTT- Wiren Board IoT Cloud Platform.

Openvpn

OpenVPN , , . , .

OpenVPN , . , : bundle, , engine.

 openvpn --capath /etc/ssl/certs/ --cert /etc/ssl/device/device_bundle.crt.pem --key engine:ateccx08:ATECCx08:00:04:C0:00 

letsencrypt.

 ca /etc/openvpn/WirenBoard_Root_CA.crt cert /etc/letsencrypt/live/vpn1.wirenboard.com/fullchain.pem key /etc/letsencrypt/live/vpn1.wirenboard.com/privkey.pem 

— . - .

Nginx

. Nginx , , , SSL. nginx web-, reverse-proxy. — nginx.

nginx , HTTP-, . , : Common Name, , . , 400.

 ssl_client_certificate WirenBoard_Root_CA.crt; ssl_verify_client on; 

nginx . — , HTTP. Linux- nginx , SSL, , OpenSSL.

wget , bash , HTTP- TLS . 10 .

 server { listen 8080; location / { proxy_pass https://example.com; proxy_ssl_name example.com; proxy_ssl_server_name on; proxy_ssl_certificate/etc/ssl/device/device_bundle.crt.pem; proxy_ssl_certificate_key engine:ateccx08;ATECCx08:00:04:C0:00; } } 

Wiren Board 6 , . , .

web- cloud.wirenboard.com OpenVPN . Grafana InfluxDB, MQTT. saymon.info — (MQTT) .

, - , , Grafana, MQTT-, , , . — .

, , : — OpenSSL , — . !

InoThings Conf 2019 . YouTube- 2019 . Telegram. , , IoT.