Industrial IoT ist die Überwachung, Planung und Automatisierung von Engineering-Systemen für Industrieanlagen, Gebäude und Geschäftsgebäude. Sensoren verschiedener Parameter, Zähler und Regler erfassen Daten von diesen Objekten, z. B. Temperatur und Luftfeuchtigkeit im Serverraum, Wasserzähler in Mehrfamilienhäusern, Kohlendioxidgehalt in den Räumen. Controller verarbeiten diese Informationen und senden alles an die "Cloud".
Wiren Board stellt Linux-Controller für industrielles IoT her. Geräte sammeln Daten aus Ölquellen und Bankfilialen, überwachen das Mikroklima in Servern und Supermärkten. Controller integrieren sich in übergeordnete Systeme von Unternehmenspartnern. Systeme authentifizieren Geräte - sie verstehen, dass sie mit ihrem Sensor und nicht mit dem eines anderen sprechen, und autorisieren dann. In dieser Phase tritt ein Problem auf: Es gibt Tausende von Controllern, Hunderte von Kunden, aber kein einziges Integrationssystem. Einfache traditionelle Methoden wie Anmelde- / Kennwortpaare sind anfällig für Angriffe und unpraktisch in der Bereitstellung.
Daher entwickelte das Unternehmen die Authentifizierung in Top-Level-Systemen mithilfe von Hardwareschlüsseln - basierend auf einer standardmäßigen asymmetrischen Kryptografie unter Verwendung eines hardwaregeschützten Elements zum Speichern von Schlüsseln. Jetzt wird kein einheitliches Integrationssystem benötigt - Authentifizierung und Autorisierung sind geschützt und funktionieren sofort.
Evgeny Boger erklärt Ihnen, wie das geht: Wie sie den „Krypto-Chip“ ausgewählt haben, wie sie ihn mit Hardware und Linux verschraubt haben, wie gemeinsame Bibliotheken und Software dazu gebracht wurden, sich damit anzufreunden. Besonderes Augenmerk auf die Bereitstellung: die Einführung der Geräteinitialisierung in der Produktion, die Einführung der Unterstützung für verschiedene Top-Level-Software, auch in fremden und geschlossenen Systemen.
Über den Sprecher: Eugene Boger (
evgeny_boger ) - CTO und Mitbegründer von Wiren Board. Engagiert in eingebetteten Systemen und insbesondere in eingebettetem Linux.
Die Probleme
Zunächst einmal, was wir tun und woher dieses Problem kommt. Wir von Wiren Board entwerfen und fertigen Geräte in Russland. Früher hieß es M2M, heute jedoch - industrielles IoT. Dies ist die Automatisierung von gebäudetechnischen Systemen, Überwachung und Planung. Kurz gesagt sieht die gesamte Arbeit so aus: Sensoren verschiedener Parameter, Aktoren, Zähler und Steuerungen (Edge-Computing oder IoT-Gateway) erfassen unterschiedliche Daten von Objekten, verarbeiten sie, führen lokale Logik aus und sammeln sie dann in einem großen Versand-, Überwachungs- oder Steuerungssystem .
Wir haben im Gegensatz zu einigen Wettbewerbern kein ganzes Ökosystem. Wir stellen Geräte her, die sich in mehrere Spitzensysteme unserer Partner integrieren lassen. Es gibt viele Partnerunternehmen, die sich die Verantwortung teilen. Ohne gute technische Mittel wird die Integration nicht funktionieren - sie kann einfach nicht ausgehandelt werden.
Es gibt zwei einfache Lösungen, um diese Probleme zu lösen. Der erste besteht
darin, dem Kunden den Benutzernamen / das Passwort zu geben , wie es jeder tut, und der zweite besteht darin
, das "Geheimnis" am Arbeitsplatz zu
erzeugen und zu vernähen . Beide Optionen passten nicht zu uns - ich werde Ihnen sagen, warum.
Einfache lösungen
Die erste Lösung besteht darin, dem Client einen Benutzernamen und ein Kennwort zuzuweisen . Wir alle tun dies bis vor kurzem.
Um ein Gerät zu authentifizieren, das Daten an ein bestimmtes System sendet, können Sie einen geheimen Schlüssel erstellen - mit bedingtem Login / Passwort ("geheim"). Dies ist auf Controllern und auf einem Top-Level-System üblich, das Daten von mehreren Controllern sammelt.
Ein paar Benutzernamen / Passwörter (ein allgemeines "Geheimnis") müssen dem Kunden irgendwie mitgeteilt werden - der Firma oder der Person. Jemand muss ein geheimes Paar generieren, es per E-Mail senden und den Kunden anhand seiner Kontonummer authentifizieren. Dies ist das Standardverfahren - niedrige Technologie.
Problem . Es gibt viele solcher Systeme. Unser Kunde und er können Daten an das System unseres Partners senden. Dies ist eine komplexe Interaktion zwischen allen Beteiligten.
Neben dem Problem vieler Systeme gibt es noch andere.
- Schlechte Lieferung und Lieferung an den Kunden .
- Logins und Passwörter werden auf dem Server gespeichert . Wenn wir auch Hashes speichern, schützt uns dies ein wenig vor Lecks. Trotzdem entsteht ein unangenehmes Gefühl, wenn geheime Schlüssel für alle Client-Controller auf dem Server gespeichert werden. Einige von ihnen können sich mit kritischen Aufgaben befassen: Außenbeleuchtung, Überwachung von Ölplattformen.
- Synchronisation zwischen Diensten .
- Verlustwiederherstellung . Es ist nicht klar, was im Falle eines Verlusts zu tun ist, wenn der Client den Speicher des Controllers gelöscht hat - in welchen Speicher soll ich schreiben? Sie müssen es noch einmal wiederholen.
- Schutz gegen das Kopieren von Details . Es gibt kostenpflichtige Überwachungssysteme, die dem Kunden einen Service bieten und Abonnementgebühren erheben. Ich möchte nicht, dass der Endkunde das System durch uns umgehen kann - zahlen Sie nur einmal, sondern nutzen Sie zwei.
Die zweite Lösung besteht darin, ein „Geheimnis“ in der Produktion zu erzeugen und zu nähen . Dies ist eine Verbesserung gegenüber der vorherigen Lösung.
Das Schema lautet: Wir als Hersteller von Controllern generieren Benutzernamen und Passwörter für alle, nähen sie in unser System und geben sie in Geräte ein. Logins und Passwörter der Geräte können weder gelesen noch geändert werden. Dies ist besser als die vorherige Option, da keine Interaktion zwischen Personen erforderlich ist.
Die Probleme . Bis auf das erste bleiben alle Probleme bestehen, aber das Hauptproblem ist die
Synchronisation zwischen Diensten und dem Intranet . Es gibt viele Dienste und es ist nicht klar, wie sie synchronisiert werden sollen. Aus diesem Grund konnten wir die zweite Lösung nicht implementieren. Wir haben Kunden, die Geräte in geschlossenen Netzwerken einsetzen. Wir haben einen neuen Controller herausgebracht, ihn an einen Kunden verkauft und sein System ist geschlossen. Es ist eingerichtet, es funktioniert einmal und es ist schwierig, die "Geheimnisse" weiterzugeben. Chargenweise melden? In Organisationen ist alles kompliziert, obwohl technisch einfach.
Beide Lösungen passten nicht zu uns. Deshalb haben wir uns für einen anderen Weg entschieden. Vorher beschlossen sie jedoch, gemeinsame Ziele und Vorgaben zu skizzieren.
Aufgaben und Ziele
Erste gemeinsame Aufgaben.
Authentifizierung Auf diese Weise können Sie verstehen, wer mit dem übergeordneten System spricht und wer genau mit dem Versandsystem verbunden ist.
Bei der Authentifizierung werden keine Zugriffsrechte gewährt oder eingeschränkt, sondern es wird eine Art und Weise verstanden, wer mit uns spricht.
Die Aufgabe, Daten zu senden . Unsere Controller sind Linux-Computer, die für eine spezielle Aufgabe entwickelt wurden. Wir brauchen sie, um Daten an Top-Level-Systeme zu senden und eine VPN-Verbindung herzustellen. Gleichzeitig möchten wir, dass der Versand „out of the box“ funktioniert - ohne die Einstellungen und die Interaktion unserer Kunden und Endbenutzer des Systems mit uns und mit Kunden.
Andere Aufgaben . Dies ist eine zuverlässige Verbindung, Datenkanalverschlüsselung, aber ein separates Problem ist die
Autorisierung . Die Berechtigungsaufgabe ist mit externen Services verbunden und gliedert sich in drei Teile.
- Kostenloser Herstellerservice . Stellen Sie den Zugriff über die Seriennummer des Geräts bereit.
- Weiße Listen mit Seriennummern für den Service unserer Partner - verknüpfen Sie Einkäufe und Zugriffe auf das Kundenkonto.
- Lizenzen Gestatten oder verweigern Sie den Zugriff basierend auf den im Zertifikat angegebenen Optionen.
Ziele wollen wir erreichen, wenn wir Probleme lösen.
Ausstellung und Lieferung an den Kunden . Ohne die Beteiligung von Menschen - Informationen werden von Robotern in der Produktion vernäht.
Verlustwiederherstellung . Wir wollen, dass keine geheimen Details verloren gehen.
Lieferung von der Produktion bis zum Service . Wir wollen darauf verzichten, damit Sie den Diensten nichts liefern müssen. Beim Start neuer Geräte möchten wir nicht die Datenbanken aller Dienste aktualisieren, die diese Geräte authentifizieren sollen.
Speicherung auf dem Server . Es ist ratsam, dort überhaupt nichts aufzubewahren.
Synchronisation zwischen Diensten und Intranet . Es ist auch ratsam, nichts zu synchronisieren, da wir nichts speichern.
Schutz gegen das Kopieren von Details . Wir wollen etwas Geheimnisvolles, wofür das Geld genommen wird, es war unmöglich zu kopieren und kostenlos zu erhalten.
Die digitale Signatur eilt zur Rettung
Die elektronische digitale Signatur (EDS) ist eine Technologie, um die sich bei uns alles dreht.
Es ist wie eine gewöhnliche Signatur, nur digital. EDS ist leicht zu verifizieren, aber schwer zu fälschen. Die bekannten Wahrheiten der Kryptographie, die Jahrzehnte alt sind.
Eine elektronische Signatur kann von einer Nachricht gezählt werden, wenn Sie den geheimen privaten Schlüssel (Private Key) kennen. Wenn Sie den öffentlichen Schlüssel (public key) kennen, können Sie leicht überprüfen, ob die elektronische Signatur für die Nachricht korrekt ist. Der Name ist klar - die Öffentlichkeit informiert gewöhnlich alle, und das Geheimnis ist nur für den, der unterschreibt.
Alle Unterschriften und Schlüssel sind nur Zahlen.
In unserem Fall sind dies 32 Byte Daten, was mit mathematischer „Magie“ funktioniert. Math stellt sicher, dass die Signatur leicht zu überprüfen, aber schwer zu fälschen ist.
Wir verwenden die Signatur ECDSA-256 + SHA-256:
e = HASH(m) - die kryptografische Hash-Funktion konvertiert die Nachricht m irreversibel in die Zahl e;
private key (dA) - Zufallszahl;
public key (QA) - generiert aus einem privaten Schlüssel, aber nicht umgekehrt;
signature (r,s) = sign(private key, e) - Signatur;
verify(public key, signature, e) - Überprüfung der Signatur.
EDS-Authentifizierung. Erster Versuch
Was kann für unsere Aufgabe mit diesem kniffligen Mechanismus getan werden, der in die eine Richtung einfach und in die andere schwierig funktioniert?
Ausstellung und Lieferung an den Kunden . Wir generieren einen zufälligen privaten Schlüssel für jedes Gerät in der Produktion. Wir sagen es niemandem, weil wir ihn nicht einmal kennen und wir schreiben an das Gerät.
Lieferung von der Produktion bis zum Service . Als Nächstes verwenden wir nur den öffentlichen Schlüssel dieses Geräts für die Authentifizierung bei Diensten. Bei Diensten speichern wir nur eine Liste öffentlicher Schlüssel anstelle von Passwörtern.
Standardgesundheitsüberprüfungsalgorithmus:
- der Dienst sendet eine zufällige Nachricht
m an die Steuerung;
- Controller:
sign(private key, m) ;
- der Controller sendet eine Signatur an den Dienst;
- Dienst:
verify(public key, signature, m) .
Das einzige, was wir auf diese Weise entschieden haben, ist, dass wir
keine gemeinsamen "Geheimnisse" mehr in offener oder zwischengespeicherter Form
in unseren Diensten speichern . Das wollen wir nicht.
EDS-Authentifizierung. Zweiter Versuch
Wir wollen nichts bei Diensten speichern. Um dies zu erreichen, können wir unsere Geräte zwingen, ihre öffentlichen Schlüssel an den Dienst zu senden.
In der letzten Phase haben wir zwei Probleme gelöst. Die erste - wir haben
überprüft, ob sie den Schlüssel für den Service gegeben haben . Wir haben einen öffentlichen Schlüssel, das heißt, wir haben auch einen privaten Schlüssel erstellt. Das zweite - wir haben dafür gesorgt, dass das
Gerät einen privaten Schlüssel besitzt , der sich irgendwo auf dem USB-Stick befindet. Wenn das Gerät etwas signieren konnte, verfügt es über einen privaten Schlüssel.
Das Gerät sendet nun auch den öffentlichen Schlüssel an den Dienst. Wie kann man überprüfen, ob ihn niemand abgefangen hat, ob er nicht gefälscht hat und ob alles funktioniert?
Überprüfen des öffentlichen Schlüssels Wir erstellen uns einen weiteren öffentlichen Schlüssel. Er wird unser Schlüssel als Hersteller sein. Dies ist der Stammschlüssel "privater Stammschlüssel + öffentlicher Schlüssel". Mit diesem geheimen Stammschlüssel in der Produktion signieren wir den öffentlichen Schlüssel des Geräts und speichern diese Signatur auf dem Gerät. Das Gerät muss seinen öffentlichen Schlüssel und die Signatur seines öffentlichen Schlüssels an den Dienst senden. Jetzt kann der Dienst den öffentlichen Schlüssel des Geräts überprüfen. Wenn es mit dem privaten Root-Schlüssel signiert ist, haben wir diesen Schlüssel ausgegeben.
Nur der Hersteller - wir können eine Signatur auf dem Gerät erstellen und speichern, aber alles überprüfen.
Wir veröffentlichen den öffentlichen Schlüssel auf der Website im Bereich "Kontakte". Jeder kann es nehmen und den öffentlichen Schlüssel des Geräts überprüfen, das das Gerät an den Dienst gesendet hat. Anschließend können Sie überprüfen, ob das Gerät selbst über einen eigenen privaten Schlüssel verfügt.
Der allgemeine Algorithmus sieht so aus.
(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)?
Ergebnis des zweiten Versuchs
Wir haben das Problem mit der
Lieferung an den Kunden gelöst - die Informationen werden am Produktionsstandort zusammengenäht und
es muss nichts wiederhergestellt werden .
Es ist wichtig, dass wir das Problem der
Weitergabe von "Geheimnissen" an Top-Level-Dienste gelöst
haben , da auf dem Dienst nur der öffentliche Schlüssel des Herstellers gespeichert werden muss. Der gesamte Schlüssel ist 33 Bytes. Mit ihrer Hilfe und mathematischen Magie können Sie weiterhin eine Handshake-Verbindung herstellen und sicherstellen, dass das Gerät über den entsprechenden privaten Schlüssel verfügt.
Auf dem Server speichern wir nur den Herstellerschlüssel (root public key).
Wir haben keine
Synchronisation zwischen Diensten und dem Intranet , über das wir bereits gesprochen haben. Auch haben wir keinen
Schutz gegen das Kopieren von Details .
Das einzige, was wir vergessen haben, ist die
Authentifizierung . Das Gerät hat einen privaten Schlüssel gesendet, und wir haben überprüft, ob wir ihn ausgeführt und ausgestellt haben, und haben überprüft, ob das Gerät Eigentümer des Schlüssels ist. Wir wissen jedoch nicht, um was für ein Gerät es sich handelt, und stellen Tausende davon her.
Deshalb haben wir einen Trick namens "Zertifikat" angewendet.
Authentifizierung und Zertifikate
In diesem Schritt fügen wir in der ganzen mathematischen Magie mit Signaturen und ihren Überprüfungen
zusätzliche Informationen hinzu - ein Zertifikat . Dazu signieren wir im Werk nicht nur den öffentlichen Schlüssel (Device Public Key), sondern den Schlüssel mit zusätzlichen Informationen.
Zusätzliche Informationen in unserem Fall.
- Herstellungsdatum und Hersteller.
- Modell- und Hardwarekonfiguration.
- Die Seriennummer, mit der das Gerät authentifiziert werden kann.
- Optionen: Hardware und Software. Die verschiedenen Konfigurationen unterscheiden sich möglicherweise physisch nicht voneinander, das Zertifikat enthält jedoch Informationen darüber, wofür der Kunde bezahlt hat.
- Kundenname und Kontonummer.
Wir werden alle diese Informationen zusammen mit dem öffentlichen Schlüssel mit unserem Herstellerschlüssel - root public key - signieren. Danach gehen die Informationen zu den Diensten und sie können sicherstellen, dass sie korrekt sind. Da dies unsere und die Dienste unserer Partner sind, vertrauen sie uns.
Zielstatus
Informationen werden ebenfalls in der Fabrik genäht, und eine
Lieferung an die Dienste ist nicht erforderlich.
Auf dem Server speichern
wir nur den Herstellerschlüssel.
Verlustwiederherstellung . Wir nähen alle Informationen aus den Zertifikaten in den Flash-Speicher des Geräts. Theoretisch kann es versehentlich oder absichtlich gelöscht werden, aber diese Informationen im Zertifikat enthalten kein Geheimnis. Auch die Signatur selbst ist nicht geheim - es gibt einen öffentlichen Schlüssel und die Signatur mit unserem Schlüssel. Das einzige Geheimnis im Zertifikat ist das Verkaufsvolumen von Geräten mit unterschiedlichen Optionen.
Das Zertifikat kann im Werk gespeichert und an den Kunden gesendet werden, wenn er es verloren hat. Clients löschen selten speziell den Servicebereich des Speichers. In der Regel geschieht dies während der Wiederherstellung des Geräts: Das Gerät ist vom Client angekommen, wird vollständig initialisiert, alles wird gelöscht, es wird erneut heruntergeladen und das Zertifikat wird aus der werkseitigen Datenbank kopiert.
Wir bieten keine
Wiederherstellung nach Datenverlust , keinen Kopierschutz und keine
Synchronisierung zwischen Diensten .
Bei der Authentifizierung erhalten und überprüfen wir das Zertifikat. Wir verstehen, um was für ein Gerät es sich handelt - wir kennen Hersteller, Modell und Seriennummer, was er kann und was nicht.
Einloggen
Mit dem Zertifikat können Sie Informationen zur Autorisierung speichern.
Kostenloser Herstellerservice . Wenn Sie die Seriennummer des Geräts kennen, können Sie jedem Zugriff gewähren. In unseren Dienstleistungen geben wir Zugang zu allen unseren Stammkunden.
Weiße Listen mit Seriennummern . Für den Service unserer Partner können Sie eine Tabelle mit einer weißen Liste von Seriennummern erstellen: "Kunde Vasily hat bei uns zwei Controller mit solchen Seriennummern gekauft, die mit seinem Konto verknüpft sind."
Lizenzen Sie können etwas im Voraus verkaufen und dann den Zugriff
basierend auf den im Zertifikat angegebenen
Optionen zulassen oder verweigern - einem Controller mit einer Lizenz für System X.
Es gibt keine gemeinsame Basis zwischen Dienstleistern, Herstellern oder Systemherstellern. Alles funktioniert ausschließlich mit Informationen des Controllers, die von uns als Hersteller bei der Authentifizierung im System signiert werden.
Zwischenzertifikat
Ein weiteres technisches Problem, das wir unterwegs gelöst haben. In dem Schema, über das ich gerade gesprochen habe, gibt es ein Stammzertifikat des Herstellers - root private key. Es wird physisch jedes Mal benötigt, wenn Sie ein Gerät erstellen. Wenn es jedoch viele Geräte gibt, muss dieser Schlüssel für einen begrenzten Personenkreis ständig zugänglich sein. Das ist schlecht, denn wenn Sie es verlieren, müssen Sie die öffentlichen Schlüssel aller Dienste aktualisieren, und es sollte nicht zu Angreifern kommen. Dies sind große organisatorische Probleme. Aber es gibt eine Lösung.
Wir führen Zwischenschlüssel für eine Reihe von Geräten ein, deren Verlust nicht so unheimlich ist.
Wir haben das gleiche gemacht, nur die Kette ist länger.
Mit einem Herstellerzertifikat signieren wir den Zwischenschlüssel. Physikalisch handelt es sich um ein "Flash-Laufwerk", das dem Vorarbeiter im Werk für einen Tag übergeben wird. Hardware begrenzt die Anzahl der Geräte, die ein Schlüssel signieren kann. In der Mitte des Schemas haben wir ein Zwischenzertifikat hinzugefügt, ansonsten hat sich nichts geändert.
Sicherer Schlüsselspeicher
In all dem haben wir nicht genug
Schutz für den privaten Schlüssel des Geräts - dies ist immer noch eine Datei, die sich auf einem USB-Flash-Laufwerk befindet. Ein Angreifer kann es kopieren, verliert es jedoch höchstwahrscheinlich oder öffnet versehentlich den Zugriff.
Im Idealfall wäre es schön, den privaten Schlüssel des Geräts vor dem Kopieren zu schützen - legen Sie ihn in eine Blackbox.
Die Blackbox führt 4 Operationen aus:
- in sich selbst erzeugt ein Schlüssel auf Anfrage, gibt aber nicht;
- gibt den öffentlichen Schlüssel;
- Unterzeichnet eine Nachricht
- überprüft die Signatur.
Zum Überprüfen der Signatur benötigen Sie nur einen öffentlichen Schlüssel, sodass drei Vorgänge ausreichen.Nach meinem Verständnis sollte dies eine Hardwarelösung sein, die vorzugsweise vom Prozessor getrennt ist. Es gibt verschiedene Optionen, von denen die beste ein
spezieller Kryptoprozessor im SoC oder ein separater Chip ist.
Die erste Black-Box-Option, die wir geprüft haben, ist das
CAAM-Modul in den von uns verwendeten NXP i.mx 6, 7, 8-Prozessoren. Das Problem ist, dass es programmgesteuert im Boot-ROM des Prozessors implementiert ist.
Es kann Fehler enthalten, die durch andere Prozessorfunktionen gefunden und sogar ausgenutzt werden können. Vor einigen Jahren wurde in diesem Modul eine Lücke gefunden, die es ermöglichte, die Signaturüberprüfung beim Herunterladen von Firmware zu umgehen. Dies ist nicht die Funktionalität, die wir benötigen, aber das Sediment bleibt erhalten. Ein weiteres Problem ist, dass es schwierig ist, Prozessoren mit diesem Modul nach Russland zu importieren.
Deshalb haben wir einen separaten Chip genommen. Ich gebe ehrlich zu, ich habe damit gerechnet, dass wir uns etwas einfallen lassen, wenn wir es nicht nach Russland bringen können. Der Chip ist klein und kostet 1 US-Dollar. Aber alles ist gut
gelaufen - sie haben den
Microchip ATECC- Chip gefunden, der bereits alle Papiere hat.
Mikrochip ATECC608A
Dies ist ein separater kleiner Chip, der einen Cent kostet. Der Chip wird über I2C angeschlossen - zwei „Beine“ des Prozessors, die Sie auch mit anderen Peripheriegeräten teilen können. Der Chip hat eine Standard-Pinbelegung. Wir haben den Chip in den ersten Versionen des Geräts verwendet und ihn einfach mit demselben Protokoll und derselben Pinbelegung auf einen anderen Chip gelötet, da er Standard ist.
Der Chip kann mit einem solchen Chip das tun, was wir brauchen: Signaturen lesen, Schlüssel speichern und vieles mehr.
Eigenschaften
- 16 Schlüsselschlitze;
- kann ECSDSA-Signaturen, Hashes, MACs lesen und AES verschlüsseln, kann DH;
- hat einen Zufallszahlengenerator und kryptografische Zähler;
- Gehäuse: SOIC-8, DFN6;
- Protokolle: I2C, Single Wire;
- ~0.7$@1000pcs.
Wie man mit einer Mikroschaltung arbeitet
Es gibt eine anständige
Dokumentation dafür , aber unter der NDA. Wenn Sie sofort an gamma.spb.ru schreiben, wird es Ihnen in 2 Wochen mitgeteilt. Wenn in einem anderen Unternehmen - nach 3 Monaten. Wir haben zwei Unternehmen angeschrieben, und als wir alles erledigt hatten, antwortete uns ein anderer Microchip-Händler.
Es gibt nur wenige Appnotes und sie sind schlechter als der Durchschnitt. Es gibt
Software auf GitHub - eine Bibliothek mit HAL. Es ist lustig - die Dokumentation steht unter der NDA und die Software, die darauf geschrieben ist, ist auf GitHub. Die Software unterstützt kein Linux, aber Raspberry Pi und Atmel MK - das ist etwas anders. Die Entwickler glauben, dass es auf allen Geräten nur einen I2C-Bus gibt, zum Beispiel heißen die Beine wie beim Raspberry Pi.
Es gibt eine
Integration mit
OpenSSL - es funktioniert nicht gut, aber es funktioniert.
Es gibt keine Beispiele unter Linux und keine Arbeit mit
Personalisierung .
Chip-Anpassung
Personalisierung ist das größte Problem mit dem Chip.
Das Problem ist, dass der Chip viele Dinge kann. Es verfügt über 16 Steckplätze, in denen 16 Schlüssel gespeichert sind: Benutzerdaten oder öffentliche Schlüssel oder temporärer Speicher für andere Steckplätze - es gibt viele Optionen.
Sie müssen den Zugriff auf die Slots irgendwie einschränken, und es gibt auch viele Konfigurationsoptionen: Einschränken nach Kennwort, Authentifizierung in einem anderen Slot, Zugriffszeit auf die Fabriken.
In der Tabelle, die Art des Schlüssels, Lese- und Schreibzugriff, die Beziehung zwischen den Slots - SlotConfig, KeyConfig.In der Bitmaske (16 Bit) jedes von uns verwendeten Schlüssels gibt es überall unterschiedliche Zahlen.
Das Traurigste ist, dass die Konfigurationszone einmalig ist, wodurch die Funktionen der Slots festgelegt werden. Wir haben 50 Chips durcheinander gebracht, bevor wir alles richtig gemacht haben. Der Chip funktioniert erst
nach dem Sperren der Konfiguration . Separat gibt es eine
Sperre für einzelne SteckplätzeEs gibt keine Dokumentation in den Beispielen oder in der Software. Es gibt Dokumentation für einzelne Bits, aber dort ist alles kompliziert. In allen Beispielen von Microchip heißt es: "Laden Sie einen solchen Block herunter, und er funktioniert irgendwie für Sie, wie im Beispiel des Sendens von Daten an Amazon."
Es hat viel Zeit in Anspruch genommen, aber dabei haben sie ein cooles Dienstprogramm gemacht.
Dienstprogramm Atecc-util
Dies ist ein Konsolendienstprogramm, mit dem Sie die meisten Funktionen des Chips ausführen und ein wenig einfacher arbeiten können. Es ist
auf GitHub unter einer MIT-Lizenz verfügbar.
Das Dienstprogramm verwendet CryptoAuthLib. Sie weiß, wie man freundlicher mit der Konfigurationszone umgeht, sie weiß, wie man mit SHA, MAC, ECDSA, DH umgeht. Die Benutzeroberfläche ist batch-freundlich, da wir das Dienstprogramm ursprünglich für die Verwendung in Skripten erstellt haben. Die Tatsache, dass eine Person dies verursachen kann, ist ein Nebeneffekt. Das Dienstprogramm kann eine Liste mit Befehlen erstellen: "Personalisieren Sie zuerst diese Zone, und notieren Sie sich dann einen solchen Schlüssel."
Ein Beispiel für den Aufruf eines Dienstprogramms kann von Menschen gelesen werden.
atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump'
Das Dienstprogramm wurde unter Linux und unter AMD64 erstellt - es ist im Debian-Paket enthalten.
Andere Personalisierungstools
Wir haben eine Excel-Platte, um die Bits zu lesen. Wenn Sie uns einen NDA-Scan mit Microchip zeigen, geben wir ihn Ihnen.
Wir haben alles mit Tests abgedeckt, da es viele Optionen gibt, bei denen Sie ein Bit vergessen können und ein Servicebefehl Ihren privaten Schlüssel liest. Tests testen das reale Gerät. Sie wenden sich an den Mikrokreis und überprüfen die korrekte Konfiguration des Geräts: Kann dieser Steckplatz gelesen werden, kann eine solche Signatur erstellt werden?
Parallel zu den Bits haben wir eine Liste von Garantien erstellt, die dieses Gerät erfüllen sollte, und überprüft, wie alles funktioniert. Wir verwenden das
Fledermaus-Framework - eine sehr interessante Sache. Es sieht so aus.
Liste der Tests für ein Beispiel. Die oberen werden bestanden, die unteren nicht.Einstellungen in Geräten
Für die Aufgabe, über die ich spreche
, verwenden wir nur zwei Slots . In beiden speichern wir den privaten Schlüssel des Gerätes. Der Unterschied besteht darin, dass Ersteres mit einem
permanenten Zertifikat verbunden ist , das 1970 für 200 Jahre ausgestellt wurde.
Dies liegt an der Tatsache, dass die Zeit im IoT nicht immer synchronisiert ist. Bei der Zertifikatinfrastruktur wird die Gültigkeit eines Zertifikats überprüft. Wenn die Synchronisierung auf den Geräten unterbrochen ist, kann ein wichtiger Dienst fehlschlagen, z. B. VPN.
Ein Slot ist also unendlich - permanent . Sie wird einmal generiert und ändert sich während der gesamten Lebensdauer des Geräts nicht. Für diesen Schlüssel wird ein Zertifikat für 200 Jahre erstellt - für geschlossene Netzwerke.
Ein anderer Slot wird gerade aktualisiert. Die maximale Lebensdauer des Zertifikats beträgt ein Jahr. Dies geschieht nur für den Fall, dass etwas kompromittiert wird. Ein privater aktualisierbarer Geräteschlüssel wird generiert, wenn die Gültigkeitsdauer des Gerätezertifikats abläuft. Wird für die Authentifizierung in offenen Netzwerken verwendet und mindestens einmal im Monat zusammen mit einem Zertifikat aktualisiert.
Für Benutzer haben wir verschiedene Kombinationen generiert , darunter mehrere Steckplätze für private ECDSA-Schlüssel. Benutzer können ihren Schlüssel in einem separaten Slot generieren, wenn sie unserem privaten Schlüssel nicht vertrauen. Dafür müssen Sie nur Microchip vertrauen. Benutzer können Signaturen lesen, verschlüsseln - wir haben alles gegeben, was der Chip kann.
Bisher hat leider niemand davon Gebrauch gemacht, aber wir hoffen es.
Infrastruktur: Zwischenschlüssel
Ich habe bereits gesagt, dass wir irgendwann Zwischenzertifikate implementiert haben, um nicht mit einem Stammzertifikat zu glänzen, das nicht verloren gehen sollte. Er erscheint nie in einer Fabrik.
Physikalisch mittlere Zertifikate sind ein ATECC508A-Chip. Es unterscheidet sich geringfügig von 608, aber in 508 gibt es Funktionen, die sich für Schlüssel als nützlich erwiesen haben, aber in 608 ist es nicht mehr vorhanden.
Der Chip wird über einen USB-I2C-Adapter angeschlossen. Dies ist USBISP mit winziger USB-i2c-Firmware - ein Programmierer, der in eine USB-I2C-Bridge geflasht werden kann. Zwischenzertifikate signieren Gerätezertifikate mit ihrem privaten Schlüssel.
Zwei Merkmale der Mikroschaltung haben sich für uns als nützlich erwiesen.
Steckplatz für Hardware-Passwortschutz . Der Chip kann nur dann zum Lesen der Signatur programmiert werden, wenn zwei Bedingungen erfüllt sind:
- wenn das Gerät in einem Computer steckt;
- Passwort eingegeben.
Wir geben dem Vorarbeiter für die Produktion einen Zwischenschlüssel und ein Passwort für eine Reihe von Controllern. Dementsprechend müssen Sie sowohl den Schlüssel als auch das Passwort stehlen, um Zugriff zu erhalten. Wir haben diese Möglichkeit kostenlos, aber sie erhöht die Sicherheit des Systems.
Hardware-Limit für die Anzahl der Verwendungen . Der kryptografische Zähler im Inneren kann sich nur erhöhen. Wenn es einmal eine vorbestimmte Grenze erreicht, signiert die Mikroschaltung nichts anderes.
OpenSSL auf dem Client
Betrachten wir, wie alles auf dem Client funktioniert. Wir haben OpenSSL auf dem Controller. Wir haben nichts erfunden - das ist gewöhnliches TLS, gewöhnliche PKI. Wir brauchten zusätzlich eine Kundenbibliothek. In der überwiegenden Mehrheit der Linux-Software wird es für eine sichere Verbindung verwendet.
Wir haben den Code von Microchip genommen, ein wenig hinzugefügt und das neue OpenSSL unterstützt
1.1. Infolgedessen weiß er, wie man mit einem Hardwareschlüssel arbeitet - Hardware unterstützt Passwörter für private Schlüssel.
Es sieht ungefähr so aus.
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr
Dies ist ein Aufruf an reguläres OpenSSL und eine Anweisung zur Verwendung des entsprechenden Engine-Moduls. Hier wird der Schlüssel festgelegt: Adresse, Modell und die letzten beiden Bytes geben die Nummer des verwendeten Steckplatzes an. Alles wird übertragen, als wäre es eine Schlüsseldatei, aber es ist keine Datei - Sie müssen in das Gerät gehen.
SSL auf dem Server
Jedes SSL funktioniert auf dem Server, einschließlich OpenSSL. Es sind keine Änderungen und benutzerdefinierten Builds auf der Serverseite erforderlich. Auf dem Server muss lediglich
die Kette der Zertifikate (Gerätezertifikat + Zwischenzertifikat) überprüft und
unser auf der Website veröffentlichter
öffentlicher Schlüssel - Wiren Board ROOT CA - gespeichert werden.
Standard-TLS besagt, dass sich beide Parteien gegenseitig authentifizieren müssen. Theoretisch authentifiziert der Client - unser Controller - den Server. — 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.