Eine sichere Lösung, die IoT-Geräte mit der Cloud verbindet

　　Obwohl sich die Menschen zunehmend der Notwendigkeit von Sicherheit bewusst werden, finden sich Entwickler oft dabei, Abkürzungen zu nehmen, um IoT-Geräte mit der Cloud zu verbinden. In vielen Fällen scheint der Konflikt zwischen der Komplexität geeigneter Sicherheitsmechanismen, dem begrenzten Speicher und den Rechenressourcen in mikrobatteriebetriebenen IoT-Geräten und der Nachfrage nach dem Transport von Produkten unüberwindbar.

　　Um diese Probleme anzugehen und die Implementierung von Sicherheitsfunktionen in IoT-Geräten zu vereinfachen, haben Microchip Technology und Google gemeinsam eine Methode entwickelt, die die sicheren Hardwarefunktionen von Microchip mit einer einfachen Datenstruktur namens JSON Web Token (JWT) kombiniert. Das Ergebnis ist eine einfache Möglichkeit, eine gegenseitige Authentifizierung zwischen IoT-Geräten und Google Cloud IoT-Kerndiensten sicherzustellen.

　　Dieser Artikel stellt Sicherheitsbedrohungen für IoT-Geräte vor und stellt die derzeit verwendeten Geräte vor, um diese Bedrohungen zu bekämpfen. Es wird Sicherheitslücken identifizieren und wie Entwickler und Entwickler von eingebetteten Systemen JWT nutzen, um diese abzuschalten.

　　Sicherheitslücken in IoT-Geräten

　　Angriffe auf IoT-Geräte können viele Formen annehmen und sind keineswegs auf großflächige IoT-Installationen beschränkt. Für Hacker, die Ressourcen vieler einzelner Geräte in Botnets, die für verteilte Denial-of-Service-(DDoS)-Angriffe verwendet werden, ausnutzen wollen, ist selbst das kleinste IoT ein attraktives Ziel. Daher müssen Designer aller IoT-Geräte zwangsläufig ihre Systeme durch robuste, hardwarebasierte Sicherheitsmechanismen schützen, um Angriffe zu verhindern.

　　Zum Beispiel macht die Nutzung von Systemspeicher oder Flash-Speicher zur Speicherung privater Schlüssel für Verschlüsselung und Authentifizierung IoT-Geräte anfällig für Angriffe. Noch schlimmer ist, dass Hacker diese Schlüssel stehlen und nutzen können, um auf IoT-Netzwerke und zusätzliche Firmenressourcen zuzugreifen.

　　Sicherheits-IC

　　Dedizierte Sicherheitsgeräte wie die CryptoMemory- und CryptoAuthentication-ICs von Microchip Technology verfügen über Hardwarefunktionen, die auf Mechanismen zum Schutz privater Schlüssel und anderer geheimer Daten basieren. EEPROM-Arrays sind in diese Geräte integriert und bieten sichere Speicher- und Verschlüsselungssicherheitsmechanismen, die nur über die SPI- oder I2C-Seriellschnittstelle des Geräts zugänglich sind (siehe Abbildung 1). Daher bieten diese Geräte eine einfache Möglichkeit, sichere Speicher- und andere Sicherheitsfunktionen zu jedem IoT-Gerätedesign hinzuzufügen.

　　Abbildung 1: Hardware-Sicherheitsgeräte von Microchip Technology (wie AT88SC0204C CryptoMemory IC) bieten sicheren Speicher und verwenden integrierte Verschlüsselungsmechanismen, um den Zugriff auf On-Chip-EEPROMs zu schützen. (Bild: Mikrochip-Technologie)

　　Mitglieder der Microchip CryptoAuthentication-Reihe (wie ATECC608A) verbessern die Grundlage sicherer Speicherung und unterstützen Verschlüsselungsalgorithmen, die häufig im Sicherheitsdesign verwendet werden. Zu den Hardware-Funktionen gehört die Hardwarebeschleunigung verschiedener Algorithmen, darunter:

　　Asymmetrischer Verschlüsselungsalgorithmus:

　　FIPS186-3 Elliptische Kurven-Digitalsignaturalgorithmus (ECDSA)

　　FIPS SP800-56A Elliptische Kurve Diffie-Hellman (ECDH)

　　NIST-Standard P256 Elliptische Kurvenverschlüsselung (ECC)

　　Symmetrischer Verschlüsselungsalgorithmus:

　　SHA-256 Hashcode

　　Hash-basierte Nachrichten-Authentifizierungscode-(HMAC)-Kryptographie

　　AES-128 Kryptographie

　　AES-GCM (Galois-Feldmultiplikation) Kryptographie

　　Schlüsselherleitungsfunktion (KDF):

　　Pseudozufallsfunktion (PRF) KDF

　　HMAC-basierte Extraktion – und ausweitende KDF (HKDF)

　　Für Krypto-Experten stellt dieser Satz von Verschlüsselungsfunktionen eine umfassende Liste von Mechanismen dar, die zur Unterstützung höherwertiger Sicherheitsprotokolle benötigt werden. Authentifizierung und sicherer Datenaustausch. Zum Beispiel stellt die KDF-Funktion die grundlegenden Mechanismen bereit, die für Transport Layer Security (TLS)-Protokolle erforderlich sind, um Teilnehmer an Datenaustauschsitzungen vor dem Austausch oder überhaupt zu verifizieren.

　　In diesem Protokoll senden TLS-Sitzungen Anfragen von Clients an den Server, um eine sichere Sitzung zu initiieren. Der Server antwortet mit seinem digitalen Zertifikat, das der Client verwendet, um die Identität des Servers zu bestätigen. Nachdem der Client den Server auf diese Weise überprüft hat, generieren die Sitzungseinstellungen weiterhin Sessionschlüssel mit dem öffentlichen Schlüssel des Servers, um einige zufällige Werte zu verschlüsseln, die mit PRF KDF oder dem leistungsfähigeren HDKF erstellt wurden.

　　Das TLS-Authentifizierungsprotokoll bildet die Grundlage der Internetsicherheit. Die gesamte Zertifikatsanbieterbranche, bekannt als Certificate Authority (CA), hat sich zu einer Schlüsselkomponente für sichere Kommunikation entwickelt. Das Unternehmen erhält ein vertrauenswürdiges Zertifikat von der CA, um es auf seinen eigenen Servern zu installieren, das das bereits erwähnte Standard-TLS-Server-Authentifizierungsprotokoll unterstützt.

　　Bei IoT-Anwendungen sind Netzwerke weit und tief mit Unternehmen verbunden, und eine solche Einwegauthentifizierung reicht nicht aus, um Schutz zu garantieren. Zum Beispiel könnten Hacker mit betrügerischen Zertifikaten sich als legitime Server für IoT-Geräte im Rahmen eines umfassenderen Angriffs präsentieren.

　　Trotz der Risiken haben IoT-Entwickler oft Schwierigkeiten, gegenseitige TLS-Authentifizierungsprotokolle umzusetzen, da Zertifikate, Schlüssel und Software, die für die Client-Authentifizierung mit TLS erforderlich sind, die Fähigkeiten vieler IoT-Geräte übersteigen können. Durch Zusammenarbeit haben Microchip Technology und Google einen alternativen Ansatz entwickelt, der ATECC608A Funktionalität mit einer einfachen Datenstruktur namens JSON Web Token (JWT) kombiniert. Das Ergebnis ist eine einfache Möglichkeit, eine gegenseitige Authentifizierung zwischen IoT-Geräten und Google Cloud IoT-Kerndiensten sicherzustellen.

　　Authentifizierung basierend auf JWT

　　RFC 7519 legt fest, dass JWT ein branchenüblicher Container für Informationen über die Einrichtung ist, die JWT vorbereitet und überträgt, bekannt als Claim. Die JWT-Struktur selbst besteht aus drei Teilen:

　　Titel, einschließlich des JSON-Namens: der Name des kryptographischen Algorithmus ("alg") (zum Beispiel verwendet ECDSAs "EC256" die NIST P-256-Kurve) für das Signieren von Token und Tokentypen ("typ") (das "JWT" dieser Token)

　　Nutzlast, einschließlich des JSON-Namens: Wertpaares für jeden Anspruch

　　Signatur: Es verwendet den im Header angegebenen Algorithmus, um den Schlüssel, den Header und die Deklarationsmenge zu kodieren, die jeweils einzeln in die Base64-URL-Codierung vor der Verschlüsselung umgewandelt werden

　　RFC 7519 bietet große Flexibilität bei der Spezifizierung von Schäden in Nutzlasten oder anderen Teilen. Der Standard erlaubt sogar unsichere JWTs, die ohne Signatur oder Verschlüsselung erstellt wurden, wobei der Header den Namen des Algorithmus enthält: Wertpaar {{alg":"none"}. Für JWTs, die mit Google Cloud IoT-Kerndiensten verwendet werden, benötigt Google einen Signaturabschnitt und eine Nutzlast mit drei verpflichtenden Deklarationen, darunter:

　　"iat" – Die "Ausgabezeit" beim Erstellen des Tokens im ISO 8601 UTC-Zeitstempelformat, die Anzahl der Sekunden seit 1970-01-01T00:00:00Z (zum Beispiel 1561896000 00:00 GMT am 30. Juni 2019)

　　"exp" – Der UTC-Zeitstempel, der die Ablaufzeit des Tokens angibt und bis zu 24 Stunden den "IAT"-Wert plus eine 10-minütige Schonfrist überschreitet, um unterschiedliche Systemtaktverzerrungen zwischen Client und Server zu beheben (z. B. 1. Juli 2019 1561982400, GMT 00:00 00:00)

　　"aud" – ein String, der die Google-Cloud-Projekt-ID des Entwicklers enthält

　　< p> Googles IoT-Geräteauthentifizierungslösung kombiniert konventionelle TLS-basierte Server-Authentifizierung mit JWT, das mit diesen relativ einfachen Deklarationen für die IoT-Geräteauthentifizierung erstellt wurde. Um eine neue Sitzung zu starten, öffnet das IoT-Gerät einen sicheren Socket zum Server und authentifiziert den Server mit demselben zuvor beschriebenen TLS-Protokoll.

　　Der nächste Schritt in diesem Prozess basiert auf dem Lightweight Message Queue Telemetry Transmission (MQTT)-Protokoll von Google IoT Cloud für IoT-Netzwerktransaktionen. Mit einem sicheren Socket zu einem authentifizierten Server verwendet das IoT-Gerät sein eindeutiges JWT als Login-Passwort, um sich beim MQTT-Hostdienst auf diesem Server anzumelden (Inventory 1).

　　Obwohl IoT-Geräte im Rahmen dieser Anmeldesequenz Benutzernamen senden, werden Benutzernamen nicht für die Authentifizierung verwendet. Daher wurde ein virtueller Benutzername (Listing 2) übertragen. Stattdessen basiert die IoT-Geräteauthentifizierung auf JWT, das als Anmeldepasswort gesendet wird. Da JWT-Signaturen eine Kombination aus Headern, Payloads und privaten Geräteschlüsseln sind, können Google Cloud IoT-Kerndienste überprüfen, ob JWT tatsächlich von autorisierten Geräten stammt. Für diese Verifikation verwendet Google Cloud IoT Services öffentliche Geräteschlüssel, die zuvor von IoT-Geräteentwicklern im Google Cloud unter Verwendung des unten beschriebenen Schlüsselverwaltungsprozesses gespeichert wurden. Im Vergleich zur reinen Nutzung von TLS bietet dieser Ansatz eine gegenseitige Authentifizierung durch einen hybriden Ansatz, der Prozesse beschleunigt und gleichzeitig den Ressourcenbedarf für IoT-Geräte reduziert.

　　Wichtige Ermöglicher

　　ATECC608A und die Funktionalität seiner Lieferkette sind entscheidende Treiber dieses Ansatzes. Während jedes MCU schließlich verschlüsselte Verschlüsselungssignaturen aus JWT-Headern und Payloads erzeugen kann, ist jede reine Softwaremethode ohne hardwarebasierte Sicherheitsspeicherung weiterhin anfällig für Angriffe. Zusätzlich können für viele ressourcenbegrenzte IoT-Geräte oder Anwendungen mit strengen Anforderungen an Antwortzeiten die Prozessorlast und Ausführungslatenz für eine "reine Software"-Implementierung verboten sein. Schließlich ist es ohne umfangreiche Sicherheitsalgorithmen und fortgeschrittenere Protokollerfahrung für Entwickler schwierig, die erforderlichen Softwarefunktionen umzusetzen. Microchip adressiert diese Probleme über seine CryptoAuthLib-Bibliothek (Abbildung 2).

　　Abbildung 2: Da CryptoAuthLib die Hardware-Abstraktionsschicht (HAL) nutzt, um API-Funktionen und Kernprimitive von der zugrundeliegenden Hardware zu trennen, können Entwickler ihre Software für verschiedene unterstützende Geräte positionieren. (Bild: Mikrochip-Technologie)

　　Microchip CryptoAuthLib vereinfacht die Implementierung sicherer IoT-Funktionen, wie zum Beispiel des Google JWT-Authentifizierungsprotokolls, und reduziert komplexe Sicherheitsoperationen auf eine Reihe von Funktionsaufrufen, die über die CryptoAuthLib Application Programming Interface (API) bereitgestellt werden. Für IoT-Entwickler ist vielleicht die wichtigste Kernfunktion Microchip CryptoAuthLib, die Microchip-Verschlüsselungs-ICs wie ATECC608A voll nutzt, um die Ausführung von Sicherheitsfunktionen im Design zu beschleunigen. Zum Beispiel verwendet in Listing 1 ein Aufruf zu atca_jwt_finalize() verfügbare Verschlüsselungsgeräte (wie ATECC608A), um ein JWT für das Passwort in Listing 2 zu erstellen. In diesem Fall beschleunigen ATECC608A die Verschlüsselung der JWT-Signaturen, lesen das Design vom integrierten Secure Storage Key bis zum Abschluss des zuvor beschriebenen Signaturerstellungsprozesses.

　　Dennoch bleiben IoT-Geräte selbst mit komplexer Software und Sicherheitsgeräten aufgrund traditioneller Methoden zur Verwaltung von Schlüsseln und Zertifikaten anfällig für Angriffe. Früher mussten private Schlüssel extern generiert und während der Fertigung, Verteilung oder sogar Bereitstellung auf sichere Speichergeräte geladen werden. Selbst bei Verwendung von Hardware-Sicherheitsmodulen und Sicherheitseinrichtungen stellen kurzzeitig existierende Geheimnisse jenseits des einzigen Geräts-"Need-to-know" Sicherheitslücken dar, die versehentlich oder absichtlich offengelegt werden könnten. Durch die Nutzung ATECC608A Fähigkeiten haben Microchip und Google traditionelle Sicherheitslücken weitgehend beseitigt.

　　In diesem neuen Ansatz nutzt Microchip die Fähigkeit des ATECC608A, Schlüsselpaare zu erzeugen, ohne das Gerät mit einem privaten Schlüssel zu hinterlassen (Abbildung 3). Microchip verwendet dann ein Zwischenzertifikat, um den vom Gerät erzeugten öffentlichen Schlüssel zu signieren, der vom Kunden bereitgestellt und auf einem sicheren Server innerhalb der Sicherheitseinrichtungen von Microchip gespeichert wird. Schließlich überträgt Microchip den öffentlichen Schlüssel sicher an das Kundenkonto im Google Cloud IoT Device Manager, der bis zu drei öffentliche Schlüssel pro Gerät speichern kann, um Schlüsselrotationsrichtlinien zu unterstützen. Nach der Einführung können IoT-Geräte ATECC608A Sicherheitsfunktionen nutzen, um JWTs zu erstellen, die im zuvor beschriebenen gegenseitigen Authentifizierungsprozess verwendet werden.

　　Abbildung 3: Die Kombination aus Microchip-Technologie und Google Cloud IoT-Diensten vereinfacht die Konfiguration von Schlüsseln und Zertifikaten und bietet einen geschützten Mechanismus, der die Sicherheit von IoT-Anwendungen stärkt. (Bild: Google)

　　Diese Zusammenarbeit zwischen Microchip und Google ermöglicht es Entwicklern, diesen kritischen Schlüsselverwaltungsprozess vollständig zu entlasten. Für individuelle Anforderungen können Entwickler die CryptoAuthLib API-Funktion atcab_genkey() verwenden, um ihren eigenen Schlüsselverwaltungsprozess zu implementieren, der dazu führt, dass ATECC608A Schlüsselpaare generieren, private Schlüssel in ihrem sicheren Speicher speichern und den zugehörigen öffentlichen Schlüssel zurückgeben. /p>

　　Um Schlüsselgenerierung und andere ATECC608A Sicherheitsfunktionen zu erkunden, können Entwickler schnell eine umfassende Entwicklungsumgebung rund um das Microchip SAM D21 Xplained Pro Bewertungskit aufbauen. Basierend auf Microchip ATSAMD21J18A 32-Bit-Arm Cortex-M0 ® ®+ MCU bietet das SAM D21 Xplained Pro Kit einen vollständigen Hardware-Plattformtreiber und Codemodul, der vom Advanced Software Framework (ASF) von Microchip unterstützt wird.

　　Um CryptoAuthentication-Geräte, einschließlich ATECC608A, zu bewerten, können Entwickler einfach das CryptoAuth XPRO-B-Add-on-Board in einen der beiden Erweiterungsköpfe der Xplained Pro-Platine einfügen. Microchip bietet Beispielsoftware zur Bewertung der Sicherheitsmerkmale von CryptoAuthLib und ATECC608A. Darüber hinaus können Entwickler das Microchip ATWINC1500-XPRO Wi-Fi-Add-on-Board in einen anderen Header einfügen, um Microchip-Beispielsoftware auszuführen, die den in diesem Artikel beschriebenen gegenseitigen Authentifizierungsprozess demonstriert, einschließlich TLS-Server-Authentifizierung und JWT-Geräteauthentifizierung.

　　Fazit

　　Obwohl IoT-Anwendungssicherheit mehrere Anforderungen mit sich bringt, liegt die größte Herausforderung oft in der Implementierung gegenseitiger Authentifizierung für IoT-Geräte und Cloud-Ressourcen. In ressourcenbegrenzten IoT-Systemen können traditionelle Protokolle den verfügbaren Speicher und die Rechenressourcen übersteigen. Mit der CryptoAuthLib-Bibliothek und ATECC608A CryptoAuthentication-IC von Microchip Technology können Entwickler einen effizienteren Ansatz auf Basis von JSON Web Tokens implementieren, um IoT-Geräte sicher mit Google Cloud IoT-Diensten zu verbinden.