Eine einfachere Lösung für sichere Verbindungen von IoT-Geräten mit der Cloud

Von Stephen Evanczuk

Zur Verfügung gestellt von Nordamerikanische Fachredakteure von Digi-Key

Obwohl sich die Entwickler immer mehr der Notwendigkeit von Sicherheitsmaßnahmen bewusst werden, ertappen sie sich oft bei „Abkürzungen“, wenn es um Sicherheitsmaßnahmen bei der Verbindung von IoT-Geräten mit der Cloud geht. In vielen Fällen scheinen die Konflikte zwischen der Komplexität geeigneter Sicherheitsmechanismen, dem Mangel an Arbeitsspeicher und verfügbaren Ressourcen in den von winzigen Batterien betriebenen IoT-Geräten und dem Druck, ein Produkt ausliefern zu müssen, unüberwindlich zu sein.

Um dieses Problem zu lösen und die Implementierung von Sicherheitsfunktionen in IoT-Geräten zu erleichtern, haben Microchip Technology und Google zusammen einen Ansatz entwickelt, der die Fähigkeiten der sicheren Hardware von Microchip mit einer einfachen, als JSON Web Token (JWT) bezeichneten Datenstruktur verbindet. Das Ergebnis ist eine einfache Methode, die die gegenseitige Authentifizierung zwischen IoT-Geräten und den Google-Cloud-IoT-Core-Diensten sicherstellt.

In diesem Artikel werden die Sicherheitsbedrohungen für IoT-Geräte und die derzeit verwendeten Bauelemente beschrieben, mit denen diesen Bedrohungen begegnet wird. Es werden die Sicherheitslücken dargestellt und die Möglichkeit, wie Entwickler und Konstrukteure von eingebetteten Systemen diese mithilfe von JWT schließen können.

Die Schwachstellen von IoT-Geräten

Angriffe auf IoT-Geräte können in vielen Formen auftreten und sind keineswegs auf großflächige Bereitstellungen von IoT-Geräten beschränkt. Selbst das kleinste IoT-Netzwerk ist ein attraktives Ziel für Hacker, die die Ressourcen vieler industrieller Geräte für Botnets abzweigen möchten, um sie für DDoS-Angriffe (Distributed Denial of Service) und anderes zu missbrauchen. Somit stehen Konstrukteure jeder Klasse von IoT-Geräten unweigerlich vor der Notwendigkeit, ihr System mit robusten hardwarebasierten Mechanismen zu schützen, die in der Lage sind, diese Angriffe abzuwehren.

Wenn z. B. Systemspeicher oder Flash-Speicher zum Speichern von privaten Schlüsseln für Verschlüsselung und Authentifizierung genutzt wird, bleibt das IoT-Gerät angreifbar. Schlimmer noch: Hacker können diese Schlüssel stehlen und sich mit ihnen Zugriff auf das IoT-Netzwerk und darüber auf Firmenressourcen verschaffen.

Sicherheits-ICs

Spezielle Sicherheitsbauelemente wie die CryptoMemory- und CryptoAuthentication-ICs von Microchip Technology bieten hardwarebasierte Mechanismen zum Schutz von privaten Schlüsseln und anderen vertraulichen Daten. Ein in diesen Bausteinen eingebautes EEPROM-Array bietet einen sicheren Speicher, auf den nur mithilfe von kryptografisch gesicherten Mechanismen über die serielle SPI- oder I2C-Schnittstelle des Bausteins zugegriffen werden kann (Abbildung 1). Daher bieten diese Bausteine eine einfache Möglichkeit, zusätzlichen sicheren Speicher und weitere Sicherheitsfunktionen in ein beliebiges IoT-Gerät einzubauen.

Diagramm des CryptoMemory-ICs AT88SC0204C von Microchip

Abbildung 1: Bausteine mit Hardware-Sicherheit von Microchip Technology wie der CryptoMemory-IC AT88SC0204C bieten sicheren Speicher, wobei der Zugriff auf das On-Chip-EEPROM durch integrierte kryptografische Mechanismen geschützt ist. (Bildquelle: Microchip Technology)

Bei bestimmten Modellen aus der CryptoAuthentication-Produktfamilie von Microchip, z. B. beim ATECC608A, wird das Fundament des sicheren Speichers durch die Unterstützung von in neueren Produkten eingesetzten kryptografischen Algorithmen erweitert. Außer seinen Hardwarefunktionen bietet dieser Baustein Hardwarebeschleunigung für verschiedene Algorithmen. Dazu gehören:

  • Asymmetrische kryptografische Algorithmen:
    • FIPS186-3 Elliptic Curve Digital Signature Algorithm (ECDSA)
    • FIPS SP800-56A Elliptic Curve Diffie-Hellman (ECDH)
    • NIST Standard P256 Elliptic Curve Cryptography (ECC)
  • Symmetrische kryptografische Algorithmen:
    • SHA-256 Hash Cryptography
    • Hash-based Message Authentication Code (HMAC) Cryptography
    • AES-128 Cryptography
    • AES-GCM (Galois Counter Mode) Cryptography
  • Schlüsselableitungsfunktionen (Key Derivation Functions, KDFs):
    • Schlüsselableitungsfunktion mit Pseudo-Zufallszahlen (Pseudorandom Function (PRF) KDF)
    • HMAC-based Extract-and-Expand KDF (HKDF)

Dieser Satz von Kryptofunktionen stellt für Kryptografieexperten eine umfassende Liste von Mechanismen zur Unterstützung von Sicherheitsprotokollen auf höherer Ebene zur Authentifizierung und zum sicheren Datenaustausch dar. KDF stellt beispielsweise die wesentlichen Mechanismen für das TLS-Protokoll (Transport Layer Security) zur Authentifizierung von Teilnehmern an Datenaustauschsitzungen vor Beginn des eigentlichen Austauschs bereit.

In diesem Protokoll beginnt eine TLS-Sitzung damit, dass ein Client an den Server eine Aufforderung zur Einleitung einer sicheren Sitzung sendet. Der Server sendet als Antwort sein digitales Zertifikat, das dem Client die Identität des Servers bestätigt. Nachdem der Client den Server auf diese Weise authentifiziert hat, wird die Einrichtung der Sitzung dadurch fortgesetzt, dass der Client einen Sitzungsschlüssel generiert, indem er eine mithilfe einer PRF KDF oder einer robusteren HDKF generierte Zufallszahl mit dem öffentlichen Schlüssel des Servers verschlüsselt.

Das Authentifizierungsprotokoll TLS ist eine Grundlage der Internetsicherheit. Um diese wichtige Komponente der sicheren Kommunikation herum ist eine ganze Branche von als Zertifizierungsstellen (Certificate Authorities, CAs) bezeichneten Zertifikatanbietern entstanden. Unternehmen erwerben von den Zertifizierungsstellen vertrauenswürdige Zertifikate und installieren diese auf ihren eigenen Servern, sodass sie das oben beschriebene Standard-Serverauthentifizierungsprotokoll TLS unterstützen.

Für IoT-Anwendungen kann diese Art der einseitigen Authentifizierung keinen ausreichenden Schutz gewährleisten, wenn Netzwerke in der Breite und in der Tiefe mit Firmenquellen vernetzt sind. Hacker könnten sich beispielsweise mithilfe von gefälschten Zertifikaten als Teil eines breiten Angriffs den IoT-Geräten als legitime Server präsentieren.

Trotz dieses Risikos tun sich IoT-Entwickler bei der Implementierung des TLS-Protokolls zur gegenseitigen Authentifizierung schwer, da die zur Implementierung der Client-Authentifizierung mit TLS erforderlichen Zertifikate und Schlüssel sowie die Software die Fähigkeiten vieler IoT-Geräte übersteigen. Microchip Technology und Google haben nun gemeinsam einen alternativen Ansatz entwickelt, der die Fähigkeiten des ATECC608A mit einer als JSON Web Token (JWT) bezeichneten einfachen Datenstruktur verbindet. Das Ergebnis ist eine einfache Methode, die die gegenseitige Authentifizierung zwischen IoT-Geräten und den Google-Cloud-IoT-Core-Diensten sicherstellt.

JWT-basierte Authentifizierung

Das in RFC 7519 spezifizierte JWT ist ein Standard-Container für als „Claims“ bezeichnete Informationen über die Entität, die das JWT vorbereitet und überträgt. Die JWT-Struktur selbst besteht aus drei Abschnitten:

  • Der Header („Header“), der JSON-Paare Name:Wert (name:value) für den Namen ("alg") des kryptografischen Algorithmus, mit dem das Token signiert wird (beispielsweise "EC256" für ECDSA unter Verwendung der P-256-Kurve nach NIST), und für den Typ ("typ") von Token (in diesem Falle "JWT") enthält
  • Die Nutzdaten („Payload“), darunter JSON-Paare „Name:Wert“ für jeden Claim
  • Die Signatur („Signature“), für die der im Header angegebene Algorithmus einen geheimen Schlüssel einschließlich des Headers und des Claim-Sets codiert, wobei jeder Bestandteil vor der Verschlüsselung einzeln in eine URL-codierte base64-Darstellung überführt wird

RFC 7519 erlaubt für die Angabe von Claims in den Nutzdaten oder in anderen Abschnitten eine große Flexibilität. Der Standard lässt sogar nicht gesicherte JWTs zu, die ohne Signatur und Verschlüsselung erstellt wurden. In diesem Fall muss der Header als Paar Name:Wert die Angaben {"alg":"none"} enthalten. Für JWTs, die für die Google-Cloud-IoT-Core-Dienste verwendet werden, schreibt Google den Abschnitt Signatur (Signature) sowie Nutzdaten (Payload) mit drei obligatorischen Claims vor, die Folgendes enthalten müssen:

  • "iat" – den Zeitpunkt der Herausgabe ("issued at"), zu dem das Token erstellt wurde, als UTC-Zeitstempel nach ISO 8601 als Sekunden seit dem 1.1.19701970-01-01T00:00:00Z (z. B. 1561896000 für den 30.Juni 2019, 12:00:00 GMT)
  • "exp“ – den UTC-Zeitstempel, der den Ablauf des Tokens längstens 24 Stunden nach "iat“ zuzüglich einer „Gnadenfrist“ von 10 Minuten für Abweichungen der Systemzeit zwischen verschiedenen Clients und Servern (z. B. 1561982400 für den 1.Juli 2019, 12:00:00 GMT) festlegt
  • "aud" – eine Zeichenkette mit der Google-Cloud-Project-ID des Entwicklers

Googles Schema für die Authentifizierung von IoT-Geräten mischt die normale Server-Authentifizierung über TLS mit der Authentifizierung von IoT-Geräten mit einem JWT, das mit diesen relativ einfachen Claims erstellt wurde. Ein IoT-Gerät, das eine neue Sitzung beginnen möchte, öffnet einen sicheren Socket zum Server und authentifiziert den Server mithilfe des oben beschriebenen TLS-Protokolls.

Der nächste Schritt dieses Vorgangs beruht auf dem von der Google IoT Cloud verwendeten abgespeckten MQTT-Protokoll (Message Queueing Telemetry für IoT-Netzwerktransaktionen. Über den sicheren Socket zum authentifizierten Server meldet sich das IoT-Gerät beim MQTT-Host-Dienst an und verwendet dabei sein eindeutiges JWT als Anmeldekennwort (Listing 1).

Kopieren
/* Populate the buffer with the username */
int config_get_client_username(char* buf, size_t buflen)
{
    if(buf && buflen)
    {
        int rv = snprintf(buf, buflen, "unused");
 
        if(0 < rv && rv < buflen)
        {
            buf[rv] = 0;
            return 0;
        }
    }
    return -1;
}
 
/* Populate the buffer with the user's password */
int config_get_client_password(char* buf, size_t buflen)
{
    int rv = -1;
 
    if(buf && buflen)
    {
        atca_jwt_t jwt;
        
        uint32_t ts = time_utils_get_utc();
 
        rv = atcab_init(&cfg_ateccx08a_i2c_default);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        /* Build the JWT */
        rv = atca_jwt_init(&jwt, buf, buflen);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))
        {
            return rv;
        }
 
        rv = atca_jwt_finalize(&jwt, 0);
 
        atcab_release();
    }
    return rv;
}

Listing 1: Ein Modul aus dem Verzeichnis mit Softwarebeispielen von Microchip Technology für Google Cloud Platform IoT Core stellt Routinen zur Generierung eines Dummy-Benutzernamens und eines JWT-Objekts als Kennwort für die Client-Authentifizierung mit einem MQTT-Host bereit. (Codequelle: Microchip Technology)

Obwohl das IoT-Gerät einen Benutzernamen als Teil der Anmeldesequenz sendet, wird dieser nicht zur Authentifizierung verwendet. Daher wird ein Dummy-Benutzername übertragen (Listing 2). Die Authentifizierung des IoT-Geräts wird stattdessen über das als Anmeldekennwort gesendete JWT fortgeführt. Da die JWT-Signatur eine Kombination aus Header, Nutzdaten und dem privaten Schlüssel des Geräts ist, können die Google-Cloud-IoT-Core-Dienste überprüfen, ob das JWT tatsächlich von einem autorisierten Gerät stammt. Für diese Überprüfung verwenden die Google-Cloud-IoT-Dienste den öffentlichen Schlüssel des Geräts, der vorher vom Entwickler des IoT-Geräts mithilfe des oben beschriebenen Schlüsselverwaltungsprozesses in der Google-Cloud gespeichert wurde. Im Gegensatz zur alleinigen Verwendung von TLS bietet dieser Ansatz eine gegenseitige Authentifizierung über ein hybrides Verfahren, das den Vorgang beschleunigt und dabei den Ressourcenbedarf reduziert.

Kopieren
/* Connect the MQTT Client to the host */
static int client_connect(void* pCtx)
{
    MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;
    struct _g_client_context* ctx = (struct _g_client_context*)pCtx;
    size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;
 
    mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;
    mqtt_options.cleansession = 1;
 
    /* Client ID String */
    mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];
    if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Username String */
    mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);
    if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Password String */
    mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);
    if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    return MQTTConnect(&ctx->mqtt_client, &mqtt_options);
}

Listing 2: Diese Funktion aus dem Verzeichnis für Softwarebeispiele von Microchip veranschaulicht die Verwendung eines JWT-Objekts als Kennwort zur Authentifizierung des IoT-Geräts bei einem MQTT-Server zu Beginn der Verbindungsphase. (Codequelle: Microchip Technology)

Kritische Voraussetzungen

Die Fähigkeiten des ATECC608A und seiner Lieferkette sind die kritischen Voraussetzungen für diesen Ansatz. Obwohl eigentlich jede MCU aus dem Header und den Nutzdaten des JWT eine kryptografisch verschlüsselte Signatur generieren könnte, wäre jeder nur auf Software beruhender Ansatz ohne Speicher mit hardwarebasierter Sicherheit angreifbar. Darüber hinaus könnten die bei einer „Nur-Software“-Implementierung auftretenden Verzögerungen des Prozessors beim Laden und Ausführen für viele IoT-Geräte mit beschränkten Ressourcen oder für Anwendungen, die eine kurze Antwortzeit verlangen, nicht tragbar sein. Schließlich wären Entwickler ohne lange Erfahrung mit Sicherheitsalgorithmen und Protokollen auf höherer Ebene möglicherweise mit der Implementierung der benötigten Softwarefunktionalität überfordert. Microchip widmet sich diesen Problemen mit seiner CryptoAuthLib-Bibliothek (Abbildung 2).

Diagramm: Hardware-Abstraktionsebene (HAL) von CryptoAuthLib

Abbildung 2: Da CryptoAuthLib die API-Funktionen und die Kernfunktionen mit einer Hardware-Abstraktionsebene (HAL) von der zugrunde liegenden Hardware trennt, kann damit Software entwickelt werden, die ein breites Spektrum von Geräten unterstützt. (Bildquelle: Microchip Technology)

CryptoAuthLib von Microchip vereinfacht die Implementierung von sicheren IoT-Funktionen, z. B. des JWT-Authentifizierungsprotokolls von Google, und reduziert dabei komplexe Sicherheitsoperationen auf einen Satz von Funktionsaufrufen über die CryptoAuthLib-API. Am Wichtigsten für IoT-Entwickler ist vielleicht die Tatsache, dass die Kernfunktionen der CryptoAuthLib-Bibliothek von Microchip in vollem Umfang von den Crypto-ICs von Microchip, z. B vom ATECC608A, bei der Beschleunigung der Sicherheitsfunktionen des betreffenden Geräts profitieren. Beim Aufruf von atca_jwt_finalize() in Listing 1 wird beispielsweise ein verfügbares Crypto-Bauelement wie der ATECC608A zum Erstellen eines in Listing 2 als Kennwort verwendeten JWT verwendet. In diesem Fall beschleunigt der ATECC608A die Verschlüsselung der JWT-Signatur durch Auslesen des privaten Schlüssels des Geräts aus dem integrierten sicheren Speicher, um die oben beschriebene Erstellung der Signatur durchzuführen.

Trotz intelligenter Software und Sicherheitskomponenten können in IoT-Geräten Sicherheitslücken aufgrund der üblicherweise erforderlichen Verwaltungsmethoden für Schlüssel und Zertifikate auftreten. In der Vergangenheit mussten private Schlüssel extern geniert und bei der Herstellung oder bei der Auslieferung oder sogar erst bei der Bereitstellung in den sicheren Speicher geladen werden. Auch wenn in Hardware implementierte Sicherheitsmodule und Sicherheitsgeräte verwendet werden, stellt die vorübergehende Existenz dieser geheimen Daten außerhalb des Geräts, das sie „kennen muss“, eine Sicherheitslücke dar, die eine versehentliche oder absichtliche Offenlegung ermöglicht. Durch die Einbindung der Fähigkeiten des ATECC608A haben Microchip und Google diese traditionelle Sicherheitslücke im Wesentlichen beseitigt.

Bei diesem neuen Ansatz nutzt Microchip die Möglichkeit des ATECC608A, Schlüsselpaare zu genieren, ohne dass der private Schlüssel jemals das Gerät verlässt (Abbildung 3). Microchip signiert dann die im Gerät generierten öffentlichen Schlüssel mit einem vom Kunden zur Verfügung gestellten Zwischenzertifikat, das auf einem sicheren Server innerhalb der Sicherheitseinrichtungen von Microchip gespeichert wird. Schließlich übermittelt Microchip die öffentlichen Schlüssel sicher auf das Konto des Kunden im Google Cloud IoT Device Manager, auf dem bis zu drei öffentliche Schlüssel pro Gerät gespeichert werden können. So werden Rotationsrichtlinien für Schlüssel unterstützt. Ein IoT-Gerät kann unmittelbar nach der Bereitstellung mithilfe der Sicherheitsfunktionen des ATECC608A das oben beschriebene JWT für die gegenseitige Authentifizierung erstellen.

Diagramm: Microchip Technology und Google-Cloud-IoT-Dienste (zum Vergrößern klicken)

Abbildung 3: Microchip Technology und Google-Cloud-IoT-Dienste vereinfachen gemeinsam die Bereitstellung von Schlüsseln und Zertifikaten und stellen damit einen geschützten Mechanismus zur Härtung der Sicherheit für IoT-Anwendungen zur Verfügung. (Bildquelle: Google)

Durch die Zusammenarbeit zwischen Microchip und Google wird den Entwicklern die kritische Schlüsselverwaltung komplett abgenommen. Bei speziellen Anforderungen können die Entwickler trotzdem eine eigene Schlüsselverwaltung implementieren, wobei sie die Funktion atcab_genkey() aus der CryptoAuthLib-API verwenden, die den ATECC608A veranlasst, ein Schlüsselpaar zu generieren, den privaten Schlüssel im sicheren Speicher ablegt und den dazugehörigen öffentlichen Schlüssel zurückgibt.

Zum Erkunden der Generierung von Schlüsseln und anderer Sicherheitsfunktionen des ATECC608A kann schnell mithilfe des Evaluierungskits SAM D21 Xplained Pro von Microchip eine umfassende Entwicklungsumgebung aufgebaut werden. Auf Grundlage der 32-Bit-Arm®-Cortex®-M0+-MCU ATSAMD21J18A bietet das Entwicklungkit SAM D21 Xplained Pro eine vollständige Hardwareplattform, die vom Advanced Software Framework (ASF) mit Treibern und Codemodulen von Microchip unterstützt wird.

Zur Evaluierung der CryptoAuthentication-Bauelemente einschließlich des ATECC608A kann einfach die Zusatzkarte CryptoAuth XPRO-B in eine der beiden Erweiterungssteckleisten der Xplained Pro-Platine eingesetzt werden. Microchip stellt Beispielsoftware zur Evaluierung der Sicherheitsfunktionen der CryptoAuthLib mit dem ATECC608A zur Verfügung. Es kann sogar eine WiFi-Zusatzplatine ATWINC1500-XPRO von Microchip auf die andere Steckleiste aufgesetzt werden, auf der die Beispielsoftware von Microchip ausgeführt werden kann, die den Ablauf der in diesem Artikel beschriebenen gegenseitigen Authentifizierung mit TLS-Serverauthentifizierung und JWT-Geräteauthentifizierung veranschaulicht.

Fazit

Die Sicherheit für IoT-Anwendungen bringt zwar neue Anforderungen, aber die wichtigste Herausforderung liegt in der Implementierung der gegenseitigen Authentifizierung von IoT-Geräten und Cloud-Ressourcen. In IoT-Systemen mit begrenzten Ressourcen können herkömmliche Protokolle den verfügbaren Arbeitsspeicher und die Verarbeitungsressourcen überfordern. Mit der CryptoAuthLib-Bibliothek von Microchip Technology und dem CryptoAuthentication-IC ATECC608A kann ein effizienterer Ansatz zur sicheren Verbindung von IoT-Geräten mit Google-Cloud-IoT-Diensten umgesetzt werden.

Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der Digi-Key Electronics oder offiziellen Politik der Digi-Key Electronics wider.

Über den Autor

Stephen Evanczuk

Stephen Evanczuk hat mehr als 20 Jahre Erfahrung im Schreiben für und über die Elektronikindustrie zu einem breiten Spektrum von Themen wie Hardware, Software, Systeme und Anwendungen einschließlich des IoT. Er promoviertein Neurowissenschaften über neuronale Netzwerke und arbeitete in der Luft- und Raumfahrtindustrie an massiv verteilten sicheren Systemen und Methoden zur Beschleunigung von Algorithmen. Derzeit, wenn er nicht gerade Artikel über Technologie und Ingenieurwesen schreibt, arbeitet er an Anwendungen des tiefen Lernens (Deep Learning) zu Erkennungs- und Empfehlungssystemen.

Über den Verlag

Nordamerikanische Fachredakteure von Digi-Key