Authentification du dongle matériel du périphérique Linux sur les systèmes de niveau supérieur

L'IoT industriel surveille, planifie et automatise les systèmes d'ingénierie des installations industrielles, des bâtiments et des installations commerciales. Des capteurs de divers paramètres, compteurs et contrôleurs collectent des données de ces objets, par exemple, la température et l'humidité dans la salle des serveurs, les relevés des compteurs d'eau dans les immeubles à appartements, le niveau de dioxyde de carbone dans les chambres. Les contrôleurs traitent ces informations et envoient tout au "cloud".

Wiren Board fabrique des contrôleurs Linux pour l'IoT industriel. Les appareils collectent les données des puits de pétrole et des succursales bancaires, surveillent le microclimat des serveurs et des supermarchés. Les contrôleurs s'intègrent aux systèmes de haut niveau des entreprises partenaires. Les systèmes authentifient les appareils - ils comprennent qu'ils parlent avec leur capteur, et non avec quelqu'un d'autre, puis ils autorisent. À ce stade, un problème se pose - il y a des milliers de contrôleurs, des centaines de clients, mais il n'y a pas de système d'intégration unique. Les méthodes traditionnelles simples, telles que les paires login / mot de passe, sont vulnérables aux attaques et peu pratiques à déployer.



Par conséquent, la société a développé une authentification dans les systèmes de haut niveau à l'aide de clés matérielles - basée sur une cryptographie asymétrique standard utilisant un élément protégé par le matériel pour stocker les clés. Désormais, un système d'intégration unifié n'est plus nécessaire - l'authentification et l'autorisation sont protégées et fonctionnent dès le départ. Evgeny Boger vous expliquera comment procéder: comment ils ont choisi la «puce cryptographique», comment ils l'ont vissée au matériel et à Linux, comment les bibliothèques et les logiciels communs ont été créés pour être amis avec elle. Accent particulier sur le déploiement: introduction de l'initialisation des appareils en production, introduction de la prise en charge de divers logiciels de haut niveau, y compris chez quelqu'un d'autre et fermé.

À propos de l'orateur: Eugene Boger ( evgeny_boger ) - CTO et co-fondateur de Wiren Board. Engagé dans des systèmes embarqués et, en particulier, Linux embarqué.

Les problèmes

Pour commencer, ce que nous faisons et d'où vient ce problème. Chez Wiren Board, nous concevons et fabriquons des équipements en Russie. Il s'appelait auparavant M2M, mais maintenant - IoT industriel. Il s'agit de l'automatisation des systèmes d'ingénierie du bâtiment, de la surveillance et de la planification. En bref, tout le travail ressemble à ceci: capteurs de divers paramètres, actionneurs, compteurs et contrôleurs (edge-computing ou IoT-gateway) collectent différentes données des objets, les traitent, exécutent la logique locale, puis les rassemblent dans un grand système de répartition, de surveillance ou de contrôle .



Nous n'avons pas tout un écosystème, contrairement à certains concurrents. Nous fabriquons des équipements qui s'intègrent à plusieurs systèmes de haut niveau de nos partenaires. Il existe de nombreuses entreprises partenaires et elles partagent la responsabilité. Sans de bons moyens techniques, l'intégration ne fonctionnera pas - elle ne peut tout simplement pas être négociée.

Il existe deux solutions simples pour résoudre ces problèmes. La première consiste à donner le nom d'utilisateur / mot de passe au client , comme tout le monde le fait, et la seconde consiste à générer et à coudre le «secret» sur le lieu de travail . Les deux options ne nous convenaient pas - je vais vous dire pourquoi.

Solutions simples

La première solution consiste à attribuer un nom d'utilisateur et un mot de passe au client . Nous le faisons tous jusqu'à récemment.

Pour authentifier un appareil qui envoie des données à un système, vous pouvez créer une clé secrète - conditionnellement identifiant / mot de passe ("secret"). Elle sera courante sur les contrôleurs et sur un système de niveau supérieur qui collecte les données de plusieurs contrôleurs.

Un couple de nom d'utilisateur / mot de passe (un «secret» commun) doit en quelque sorte être donné au client - l'entreprise ou la personne. Quelqu'un doit générer une paire secrète, l'envoyer par e-mail, authentifier le client par son numéro de compte. Il s'agit de la procédure standard - faible technologie.

Problème . C'est que nous avons beaucoup de tels systèmes. Notre client, et il peut envoyer des données au système de notre partenaire. Il s'agit d'une interaction complexe entre toutes les parties concernées.

En plus du problème de nombreux systèmes, il y en a d'autres.

• Mauvaise livraison et livraison au client .
  
• Les identifiants et mots de passe sont stockés sur le serveur . Si nous stockons également des hachages, cela nous protégera un peu des fuites. Mais même ainsi, un sentiment désagréable apparaît lorsque les clés secrètes de tous les contrôleurs clients sont stockées sur le serveur. Certains d'entre eux peuvent effectuer des tâches critiques: éclairage extérieur, surveillance des plates-formes pétrolières.
  
• Synchronisation entre services .
  
• Récupération des pertes . On ne sait pas quoi faire en cas de perte, lorsque le client a effacé la mémoire du contrôleur - dans quelle mémoire dois-je écrire? Vous devez le répéter encore une fois.
  
• Protection contre la copie des détails . Il existe des systèmes de surveillance payants qui fournissent au client un service et facturent des frais d'abonnement. Je ne veux pas que le client final puisse contourner le système par notre intermédiaire - payez une fois, mais utilisez-en deux.
  

La deuxième solution est de générer et de recoudre un «secret» de production . Il s'agit d'une amélioration par rapport à la solution précédente.

Le schéma est le suivant: nous, en tant que fabricant de contrôleurs, pré-générons des noms d'utilisateur et des mots de passe pour tout le monde, les cousons dans notre système et les entrons dans l'équipement. Les identifiants et mots de passe de l'équipement ne peuvent être ni lus ni modifiés. C'est mieux que l'option précédente, car elle ne nécessite pas d'interaction entre les personnes.

Les problèmes . Tous les problèmes subsistent, sauf le premier, mais le principal est la synchronisation entre les services et l'intranet . Il y a beaucoup de services et on ne sait pas comment les synchroniser - pour cette raison, nous n'avons pas pu implémenter la deuxième solution. Nous avons des clients qui utilisent des équipements dans leurs réseaux fermés. Nous avons sorti un nouveau contrôleur, l'avons vendu à un client et son système est fermé. Il est mis en place, il fonctionne une fois, et il est difficile de transmettre davantage les «secrets». Signaler par lots? Tout est compliqué dans les organisations, bien que techniquement simple.

Les deux solutions ne nous convenaient pas. Par conséquent, nous avons décidé de prendre un chemin différent. Mais avant cela, ils ont décidé de définir des buts et objectifs communs.

Tâches et objectifs

Premières tâches courantes.

Authentification C'est un moyen de comprendre qui parle au système de niveau supérieur, qui se connecte exactement au système de répartition.

L'authentification n'est pas l'octroi ou la délimitation de droits d'accès, mais une façon de comprendre qui nous parle.

La tâche d'envoyer des données . Nos contrôleurs sont des ordinateurs Linux conçus pour une tâche spéciale. Nous avons besoin d'eux pour envoyer des données à des systèmes de haut niveau, se connecter via VPN. Dans le même temps, nous voulons que la répartition fonctionne «prête à l'emploi» - sans les paramètres et l'interaction de nos clients et utilisateurs finaux du système avec nous et avec les clients.

Autres tâches . Il s'agit d'une connexion fiable, du cryptage du canal de données, mais un autre problème est l' autorisation . La tâche d'autorisation est associée à des services externes et est divisée en trois parties.

• Service constructeur gratuit . Fournissez l'accès par le numéro de série de l'appareil.
  
• Listes blanches de numéros de série pour le service de nos partenaires - liez les achats et les accès au compte du client.
  
• Licences Autorisez ou refusez l'accès en fonction des options spécifiées dans le certificat.
  

Les objectifs sont ce que nous voulons atteindre lorsque nous résolvons des problèmes.

Délivrance et livraison au client . Sans la participation des gens - l'information est cousue par des robots en production.

Récupération des pertes . Nous voulons qu'il n'y ait aucune perte de détails secrets.

Livraison de la production aux services . Nous voulons nous en passer, pour que vous n'ayez rien à livrer aux services. Lors du lancement de nouveaux équipements, nous ne souhaitons pas mettre à jour les bases de données de tous les services qui devraient authentifier ces appareils.

Stockage sur le serveur . Il est conseillé de ne rien y stocker du tout.

Synchronisation entre les services et l'intranet . Il est également conseillé de ne rien synchroniser - car nous ne stockerons rien.

Protection contre la copie des détails . Nous voulons quelque chose de secret, pour lequel l'argent est pris, il était impossible de copier et de recevoir gratuitement.

La signature numérique se précipite à la rescousse

La signature numérique électronique (EDS) est une technologie autour de laquelle tout fonctionne pour nous.

C’est comme une signature ordinaire, uniquement numérique. EDS est facile à vérifier, mais difficile à simuler. Les vérités familières de la cryptographie, vieilles de plusieurs décennies.

Une signature électronique est quelque chose qui peut être compté par un message si vous connaissez la clé privée secrète (clé privée). Si vous connaissez la clé publique (clé publique), il est facile de vérifier que la signature électronique du message est correcte. Le nom est clair - le public a coutume d'informer tout le monde, et le secret n'est que pour celui qui signe.

Toutes les signatures et clés ne sont que des chiffres.

Dans notre cas, il s'agit de 32 octets de données, ce qui fonctionne sur la «magie» mathématique. Les mathématiques garantissent que la signature est facile à vérifier, mais difficile à simuler.

Nous utilisons la signature ECDSA-256 + SHA-256:

• e = HASH(m) - la fonction de hachage cryptographique convertit irréversiblement le message m en nombre e;
  
• private key (dA) - nombre aléatoire;
  
• public key (QA) - générée à partir d'une clé privée, mais pas l'inverse;
  
• signature (r,s) = sign(private key, e) - signature;
  
• verify(public key, signature, e) - vérification de la signature.
  

Authentification EDS. Première tentative

Que peut-on faire pour notre tâche en utilisant ce mécanisme délicat, qui fonctionne dans un sens simplement et dans l'autre difficile?

Délivrance et livraison au client . Nous générons une clé privée aléatoire pour chaque appareil de la production. Nous ne le disons à personne, car nous ne le connaissons même pas, et nous écrivons sur l'appareil.

Livraison de la production aux services . Ensuite, nous utilisons uniquement la clé publique de cet appareil pour l'authentification sur les services. Sur les services, nous stockons uniquement une liste de clés publiques au lieu de mots de passe.

Algorithme de contrôle de santé standard:

• le service envoie un message aléatoire m au contrôleur;
  
• contrôleur: sign(private key, m) ;
  
• le contrôleur envoie une signature au service;
  
• service: verify(public key, signature, m) .
  

La seule chose que nous avons décidé de cette manière est que nous ne stockons plus de "secrets" communs sur nos services sous forme ouverte ou en cache. Ce n'est pas ce que nous voulons.

Authentification EDS. Deuxième tentative

Nous ne voulons pas stocker quelque chose sur les services. Pour ce faire, nous pouvons forcer nos appareils à envoyer leurs clés publiques au service.

À la dernière étape, nous avons résolu deux problèmes. Le premier - nous avons vérifié qu'ils avaient donné la clé du service . Nous avons une clé publique, ce qui signifie que nous avons également créé une clé privée. La seconde - nous nous sommes assurés que l' appareil possède une clé privée , qui se trouve quelque part sur le lecteur flash USB. Si l'appareil peut signer quelque chose, il possède une clé privée.

Maintenant, l'appareil enverra également la clé publique au service. Comment vérifier que personne ne l'a intercepté, ne l'a pas simulé et que tout fonctionne?

Vérification de la clé publique . Nous nous créons une autre clé publique. Il sera notre clé en tant que fabricant. Il s'agit de la clé racine "clé privée racine + clé publique". Avec cette clé secrète racine en production, nous signerons la clé publique de l'appareil et nous enregistrerons cette signature sur l'appareil. L'appareil doit envoyer sa clé publique et la signature de sa clé publique au service. Le service peut désormais vérifier la clé publique de l'appareil. S'il est signé avec la clé privée racine, nous avons émis cette clé.

Seul le fabricant - nous pouvons créer et stocker une signature sur l'appareil, mais tout vérifier.

Nous publions la clé publique sur le site dans la rubrique "Contacts". Tout le monde peut le prendre et vérifier la clé publique de l'appareil qui a envoyé l'appareil au service. Ensuite, vous pouvez vérifier que l'appareil lui-même possède sa propre clé privée.

L'algorithme général ressemble à ceci.

• (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)?
  

Résultat de la deuxième tentative

Nous avons résolu le problème de la livraison au client - les informations sont cousues sur le site de production et rien n'a besoin d'être restauré .

Il est important que nous ayons résolu le problème de la fourniture de «secrets» aux services de haut niveau , car tout ce qui doit être stocké sur le service est la clé publique du fabricant. La clé entière fait 33 octets. Avec leur aide et leur magie mathématique, vous pouvez continuer à établir une connexion de prise de contact et vérifier que l'appareil possède la clé privée correspondante.

Sur le serveur, nous stockons uniquement la clé du fabricant (clé publique racine).

Nous n'avons pas de synchronisation entre les services et l'intranet , dont nous avons déjà parlé. De plus, nous n'avons aucune protection contre la copie de détails .

La seule chose que nous avons oubliée est l' authentification . L'appareil a envoyé une clé privée, et nous avons vérifié que nous l'avons fait et délivré, et vérifié que l'appareil en est le propriétaire. Mais nous ne savons pas de quel type d'appareil il s'agit et nous en produisons des milliers.

Par conséquent, nous avons appliqué une astuce appelée «Certificat».

Authentification et certificats

À cette étape, dans toute la magie mathématique avec les signatures et leurs contrôles, nous ajoutons des informations supplémentaires - un certificat . Pour ce faire, nous signons en usine non seulement la clé publique (clé publique de l'appareil), mais la clé avec des informations supplémentaires.

Informations supplémentaires dans notre cas.

• Date de fabrication et fabricant.
  
• Configuration du modèle et du matériel.
  
• Numéro de série par lequel l'appareil peut être authentifié.
  
• Options: matériel et logiciel. Différentes configurations peuvent ne pas différer physiquement les unes des autres, mais le certificat contiendra des informations sur ce que le client a payé.
  
• Nom du client et numéro de compte.
  

Nous signerons toutes ces informations avec la clé publique avec notre clé de producteur - clé publique racine. Après cela, les informations iront aux services et ils pourront s'assurer qu'ils sont corrects. Comme ce sont nos services et ceux de nos partenaires, ils nous font confiance.

Statut de l'objectif

Les informations sont également cousues à l'usine et la livraison aux services n'est pas nécessaire. Sur le serveur, nous stockons uniquement la clé du fabricant.

Récupération des pertes . Nous cousons toutes les informations des certificats dans la mémoire flash de l'appareil. Théoriquement, il peut être supprimé accidentellement ou intentionnellement, mais il n'y a rien de secret dans ces informations dans le certificat. Même la signature elle-même n'est pas secrète - il y a une clé publique et la signature avec notre clé. Le seul secret du certificat est le volume des ventes d'appareils avec différentes options.

Le certificat peut être stocké en usine et envoyé au client s'il l'a perdu. Les clients effacent rarement spécifiquement la zone de service de la mémoire. Habituellement, nous le faisons pendant la procédure de récupération de l'appareil: l'appareil est arrivé du client, il est complètement passé par l'initialisation, tout est effacé, il est téléchargé à nouveau et le certificat est copié de la base de données d'usine.

Nous n'avons pas de récupération de perte, de protection contre la copie et de synchronisation entre les services .

Au stade de l'authentification, nous recevons et vérifions le certificat. Nous savons de quel type d'appareil il s'agit - nous connaissons le fabricant, le modèle et le numéro de série, ce qu'il peut et ne peut pas.

Se connecter

Le certificat vous permet de stocker des informations pour autorisation.

Service constructeur gratuit . Connaissant le numéro de série de l'appareil, vous pouvez donner accès à tout le monde. Dans nos services, nous donnons accès à tous nos clients de base.

Listes blanches de numéros de série . Pour le service de nos partenaires, vous pouvez créer un tableau avec une liste blanche de numéros de série: «Le client Vasily nous a acheté deux contrôleurs avec de tels numéros de série associés à son compte»

Licences Vous pouvez vendre quelque chose à l'avance, puis autoriser ou refuser l'accès en fonction des options spécifiées dans le certificat - un contrôleur avec une licence pour le système X.

Il n'y a pas de base commune entre les services, fabricant ou fabricant de systèmes. Tout fonctionne exclusivement sur les informations du contrôleur qui sont signées par nous, en tant que fabricant, lors de l'authentification dans le système.

Certificat intermédiaire

Un autre problème technique que nous avons résolu sur la route. Dans le schéma dont je viens de parler, il existe un certificat racine du fabricant - clé privée racine. Il est physiquement nécessaire à chaque fois que vous créez un appareil. Mais s'il existe de nombreux appareils, cette clé nécessite un accès constant pour un cercle limité de personnes. C'est mauvais, car si vous le perdez, vous devrez mettre à jour les clés publiques sur tous les services, et cela ne devrait pas arriver aux attaquants. Ce sont de gros problèmes d'organisation. Mais il y a une solution.

Nous introduisons des clés intermédiaires dans un lot d'appareils qui ne sont pas si effrayants à perdre.

Nous avons fait de même, seule la chaîne est plus longue.



Avec un certificat constructeur, nous signons la clé intermédiaire. Physiquement, il s'agit d'un "lecteur flash", qui est remis au contremaître à l'usine pendant une journée. Le matériel limite le nombre d'appareils qu'une clé peut signer. Au milieu du schéma, nous avons ajouté un certificat intermédiaire, sinon rien n'a changé.

Magasin de clés sécurisé

Dans tout cela, nous n'avons pas suffisamment de protection pour la clé privée de l'appareil - c'est toujours un fichier qui se trouve sur une clé USB. Un attaquant peut le copier, mais très probablement il le perdra ou ouvrira accidentellement l'accès.

Dans le cas idéal, il serait bon de protéger la clé privée de l'appareil contre la copie - mettez-la dans une boîte noire.

La boîte noire effectue 4 opérations:

• à l'intérieur de lui-même génère une clé sur demande, mais ne donne pas;
  
• donne la clé publique;
  
• Signe un message
  
• vérifie la signature.
  

Pour vérifier la signature, vous n'avez besoin que d'une clé publique, donc trois opérations suffisent.

À ma connaissance, cela devrait être une solution matérielle, de préférence distincte du processeur. Il existe plusieurs options, dont la meilleure est un processeur cryptographique spécial à l'intérieur du SoC ou en tant que puce distincte.

La première option de boîte noire que nous avons examinée est le module CAAM dans les processeurs NXP i.mx 6, 7, 8 que nous utilisons. Le problème est qu'il est implémenté par programme dans la ROM de démarrage du processeur.

Il peut contenir des bogues qui peuvent être trouvés et même exploités via d'autres fonctionnalités du processeur. Il y a quelques années, un trou a été découvert dans ce module qui permettait de contourner la vérification de signature lors du téléchargement du firmware. Ce n'est pas la fonctionnalité dont nous avons besoin, mais les sédiments restent. Un autre problème est qu'il est difficile d'importer des processeurs avec ce module en Russie; ils nécessitent de remplir des documents.

Par conséquent, nous avons pris une puce distincte. J'avoue honnêtement, je comptais sur le fait que si nous ne pouvons pas l'apporter en Russie, nous trouverons quelque chose - la puce est petite, elle coûte 1 $. Mais tout s'est bien passé - ils ont trouvé la puce Microchip ATECC , qui a déjà tous les papiers.

Microchip ATECC608A

Il s'agit d'une petite puce séparée qui coûte un sou. La puce est connectée via I2C - deux «jambes» du processeur, que vous pouvez également partager avec d'autres périphériques. La puce a un brochage standard. Nous avons utilisé la puce dans les premières versions de l'équipement et l'avons simplement soudée sur une autre puce avec le même protocole et le même brochage, car elle est standard.

La puce peut faire ce dont nous avons besoin: lire les signatures, stocker les clés et bien plus encore.



CARACTÉRISTIQUES

• 16 emplacements pour clés;
  
• peut lire les signatures ECSDSA, hachages, MAC et crypter AES, peut DH;
  
• possède un générateur de nombres aléatoires et des compteurs cryptographiques;
  
• Boîtiers: SOIC-8, DFN6;
  
• protocoles: I2C, monofil;
  
• ~0,7$@1000pcs.
  

Comment travailler avec un microcircuit

Il existe une documentation décente pour cela , mais sous la NDA. Si vous écrivez immédiatement à gamma.spb.ru, ils vous le donneront dans 2 semaines. Si dans une autre entreprise - après 3 mois. Nous avons écrit à deux sociétés, et lorsque nous avons tout fait, un autre revendeur Microchip nous a répondu.

Il y a peu d'appendices et ils sont pires que la moyenne. Il existe un logiciel sur GitHub - une bibliothèque avec HAL. C'est drôle - la documentation est sous le NDA, et le logiciel qui y est écrit est sur GitHub. Le logiciel ne prend pas en charge Linux, mais prend en charge le Raspberry Pi et Atmel MK - c'est un peu différent. Les développeurs estiment que sur tous les équipements, il n'y a qu'un seul bus I2C, par exemple, les jambes sont appelées comme sur le Raspberry Pi.

Il y a intégration avec OpenSSL - cela ne fonctionne pas bien, mais c'est le cas. Il n'y a aucun exemple sous Linux et aucun travail avec la personnalisation .

Personnalisation de la puce

La personnalisation est le plus gros casse-tête avec la puce.

Le problème est que la puce peut faire beaucoup de choses. Il dispose de 16 emplacements dans lesquels 16 clés sont stockées: données utilisateur ou clés publiques, ou stockage temporaire pour d'autres emplacements - il existe de nombreuses options.

Vous devez en quelque sorte restreindre l'accès aux emplacements, et il existe également de nombreuses options de configuration: restreindre par mot de passe, par authentification dans un autre emplacement, au moment de l'accès aux usines.


Dans le tableau, le type de clé, l'accès en lecture et en écriture, la relation entre les emplacements - SlotConfig, KeyConfig.

Dans le masque de bits (16 bits) de chaque clé que nous utilisons, il y a des nombres différents partout.

Le plus triste est que la zone de configuration est unique, ce qui définit les fonctions des emplacements. Nous avons raté 50 jetons avant de tout faire correctement. La puce ne fonctionne qu'après verrouillage de la configuration . Séparément, il y a un verrou pour les emplacements individuels

Il n'y a pas de documentation dans les exemples ou dans le logiciel. Il y a de la documentation pour des bits individuels, mais tout y est compliqué. Dans tous les exemples de Microchip, il est écrit: «Téléchargez un tel bloc, et cela fonctionnera en quelque sorte pour vous, comme dans l'exemple d'envoi de données à Amazon.»

Cela a pris beaucoup de temps, mais dans le processus, ils ont fait un utilitaire cool.

Utilitaire Atecc-util

Il s'agit d'un utilitaire de console qui peut exécuter la plupart des fonctions de la puce et vous permet de travailler un peu plus facilement. Il est disponible sur GitHub sous une licence MIT.

L'utilitaire utilise CryptoAuthLib. Elle sait travailler plus amicalement avec la zone de configuration, elle sait travailler avec SHA, MAC, ECDSA, DH. L'interface est conviviale par lots, car nous avons créé l'utilitaire pour une utilisation dans les scripts en premier lieu. Le fait qu'une personne puisse la provoquer est une caractéristique secondaire. L'utilitaire peut faire une liste - un plan de commandes: "Tout d'abord, personnalisez cette zone, puis notez une telle clé."

Un exemple d'appel d'un utilitaire est tout à fait lisible par l'homme.

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

L'utilitaire est construit sous Linux, sous AMD64 - il est dans le paquet Debian.

Autres outils de personnalisation

Nous avons une plaque Excel pour lire les bits. Si vous nous montrez un scan NDA avec Microchip, nous vous le donnerons.



Nous avons tout couvert avec des tests, car il existe de nombreuses options lorsque vous pouvez oublier un bit et qu'une commande de service lira votre clé privée. Les tests testent le véritable appareil. Ils se tournent vers le microcircuit et vérifient la configuration correcte sur l'appareil: peut-on lire cet emplacement, peut-on faire une telle signature?

Parallèlement aux bits, nous avons créé une liste de garanties que cet appareil doit satisfaire et vérifié le fonctionnement de tout. Nous utilisons le cadre des chauves - souris - une chose très intéressante. Cela ressemble à ceci.


Liste de tests pour un exemple. Les supérieurs sont passés, mais les inférieurs ne le sont pas.

Paramètres dans les appareils

Pour nous, nous n'utilisons que deux emplacements pour la tâche dont je parle. Dans les deux, nous stockons la clé privée de l'appareil. La différence est que le premier est associé à un certificat permanent , délivré en 1970 pour 200 ans.

Cela est dû au fait que dans IoT, le temps n'est pas toujours synchronisé. L'infrastructure de certificat implique de vérifier la validité d'un certificat. Si la synchronisation sur les appareils est interrompue, certains services vitaux peuvent échouer, par exemple VPN.

Par conséquent, un emplacement est infini - permanent . Il est généré une fois et ne change pas pendant la durée de vie de l'appareil. Pour cette clé, un certificat est généré pendant 200 ans - pour les réseaux fermés.

Un autre emplacement est en cours de mise à jour. La durée de vie maximale d'un certificat est d'un an. Cela se fait au cas où quelque chose est compromis. Une clé d'appareil pouvant être mise à jour privée est générée lorsque la période de validité du certificat d'appareil expire. Utilisé pour l'authentification dans les réseaux ouverts, mis à jour une fois par mois ou moins, avec un certificat.

Pour les utilisateurs, nous avons généré diverses combinaisons , dont plusieurs emplacements pour les clés ECDSA privées. Les utilisateurs peuvent générer leur clé dans un emplacement séparé s'ils ne font pas confiance à notre clé privée. Pour cela, vous ne devez faire confiance qu'à Microchip. Les utilisateurs peuvent lire les signatures, chiffrer - nous avons donné tout ce que la puce peut faire.

Jusqu'à présent, malheureusement, personne n'a utilisé, mais nous l'espérons.

Infrastructure: clés intermédiaires

J'ai déjà dit qu'à un moment donné, nous avons implémenté des certificats intermédiaires afin de ne pas briller avec un certificat racine qui ne devrait pas être perdu. Il n'apparaît jamais dans une usine.



Les certificats physiquement intermédiaires sont une puce ATECC508A. Il diffère légèrement du 608, mais en 508, il existe des fonctionnalités utiles pour les touches, mais en 608, il n'est plus là.

La puce est connectée via un adaptateur USB-I2C. Il s'agit d'USBISP avec un micrologiciel USB-i2c minuscule - un programmeur qui peut être flashé dans un pont USB-I2C. Les certificats intermédiaires signent les certificats d'appareil avec leur clé privée.

Deux caractéristiques du microcircuit se sont avérées utiles pour nous.

Emplacement de protection par mot de passe matériel . La puce ne peut être programmée pour lire la signature que si deux conditions sont remplies:

• lorsque l'appareil est coincé dans un ordinateur;
  
• mot de passe saisi.
  

Nous remettons au contremaître à la production une clé intermédiaire et un mot de passe pour plusieurs contrôleurs. En conséquence, vous devez voler à la fois la clé et le mot de passe pour y accéder. Nous avons eu cette opportunité gratuitement, mais cela améliore la sécurité du système.

Limite matérielle du nombre d'utilisations . Le compteur cryptographique à l'intérieur ne peut qu'augmenter. Lorsqu'il atteint une fois une limite prédéterminée, le microcircuit ne signe rien d'autre.

OpenSSL sur le client

Voyons comment tout fonctionne sur le client. Nous avons OpenSSL sur le contrôleur. Nous n'avons rien inventé - c'est TLS ordinaire, PKI ordinaire. Nous avions également besoin d'une bibliothèque cliente. Dans la grande majorité des logiciels Linux, il est utilisé pour une connexion sécurisée.

Nous avons pris le code de Microchip, l'avons ajouté un peu, pris en charge le nouveau OpenSSL
1.1. Par conséquent, il sait comment travailler avec une clé matérielle - le matériel prend en charge les mots de passe pour les clés privées.

Cela ressemble à ceci.

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

Il s'agit d'un appel à OpenSSL standard et d'une instruction d'utilisation du module moteur approprié. La clé est définie ici: adresse, modèle et les deux derniers octets sont le numéro de l'emplacement utilisé. Tout est transmis comme s'il s'agissait d'un fichier clé, mais ce n'est pas un fichier - vous devez entrer dans l'appareil.

SSL sur le serveur

Tout SSL fonctionne sur le serveur, y compris OpenSSL. Aucune modification et builds personnalisés côté serveur ne sont nécessaires. Tout ce qui est nécessaire sur le serveur est de pouvoir vérifier la chaîne du bundle de certificats (certificat de périphérique + certificat intermédiaire), et stocker notre clé publique , que nous avons publiée sur le site - Wiren Board ROOT CA.

TLS standard indique que les deux parties doivent s'authentifier mutuellement. — — . — 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.