Verwenden eines Krypto-Chips für das sichere Booten Ihrer IoT-Geräte

Trotz aller Bemühungen können Entwickler IoT-Geräte (Internet der Dinge) dem Angriff durch den Code aussetzen, der eigentlich die Sicherheit gewährleisten soll. Bei solchen Angriffen ersetzen Hacker häufig die Firmware durch kompromittierten Code. Derartige Angriffe können durch sichere Boot-Methoden eingedämmt werden, aber deren wirksame Implementierung kann sehr komplex sein.

Daher brauchen Entwickler einfache Methoden, um sicheres Booten im Rahmen einer Gesamtstrategie für die Sicherheit von IoT-Geräten zu implementieren.

Dieser Artikel beschreibt kurz die Angriffsflächen, die IoT-Gerätedesigns bieten, und die Rolle grundlegender Sicherheitsverfahren, unter anderem gesicherte Schlüsselspeicher, Verschlüsselung und Authentifizierung. Anschließend wird ein Sicherheitschip vorgestellt, mit dem Entwickler sicheres Booten und andere Funktionen implementieren können, die im Rahmen einer Gesamtstrategie für die IoT-Gerätesicherheit benötigt werden.

Schwachstellen von IoT-Geräten

Für Hacker bieten IoT-Geräte unzählige Zugangspunkte, um die Geräte selbst, ihre Netzwerke und sogar ihre eigentlichen Anwendungen zu kompromittieren. Entwickler setzen eine Vielzahl von Techniken ein, um die Sicherheit von Netzwerken und Anwendungen zu verbessern. Doch dies ist bei IoT-Geräten wegen ihrer begrenzten Speicher- und Verarbeitungsressourcen nicht ganz einfach.

Zum Schutz der Daten werden von Entwicklern zwar Verschlüsselungsmethoden eingesetzt. Viele Geräte sind jedoch nicht mit sicheren Authentifizierungsfunktionen ausgestattet, um Hacker daran zu hindern, die Kommunikation abzufangen oder zu manipulieren, indem sie Autorisierungsserver, Gateways oder andere IoT-Geräte simulieren. In manchen Fällen bleiben auch Geräte, die gültige, aber schwache Authentifizierungsmethoden verwenden, anfällig für komplexe Exploits. Dabei werden ansonsten gültige Sicherheitsschlüssel, die für scheinbar private Kommunikationssitzungen genutzt werden, abgefangen und wiederverwendet.

Aktualisierung des IoT-Geräts

Eine noch schwerwiegendere Sicherheitslücke betrifft die Verwendung von Update-Funktionen „Over-the-Air“ (OTA), die zunehmend in IoT-Geräten eingesetzt werden. OTA-Updates sind ein wichtiges Feature auf dem schnelllebigen IoT-Markt. Um auf die sich ändernde Kundennachfrage zu reagieren, können Entwickler neue Funktionen implementieren (oder Fehler beheben), indem sie einfach die Firmware der eingesetzten Geräte aktualisieren. Bei einem typischen OTA-Aktualisierungsprozess sucht das IoT-Gerät regelmäßig nach Updates, lädt stets den neuen Code herunter, sobald dieser verfügbar ist, und führt eine Reihe von Systemaufrufen durch, um den Aktualisierungsprozess abzuschließen.

Bei einem IoT-Gerät, das auf der MCU SAM D21 von Microchip Technology basiert, enthält die Gerätefirmware beispielsweise einen OTA-Aktualisierungscode, der das Update-Image von einem vorgegebenen Endpunkt herunterlädt, den Erfolg des Prozesses überprüft und dann auf das neue Firmware-Set umschaltet (Listing 1). In diesem Codebeispiel aus dem Advanced Software Framework-Paket von Microchip wird nach der Initialisierung (m2m_ota_init()) der OTA-Firmware mittels Callback-Routine OtaUpdateCb() zu dem neuen Firmware-Satz (m2m_ota_switch_firmware()) hinübergewechselt, nachdem die OTA-Firmware das neue Code-Image heruntergeladen hat und ein System-Reset bewirkt, sodass die MCU mit der aktualisierten Firmware neu gestartet wird.

Kopieren

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

    if(u8OtaUpdateStatusType == DL_STATUS) {

        if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

            //switch to the upgraded firmware

            m2m_ota_switch_firmware();

        }

    }

    else if(u8OtaUpdateStatusType == SW_STATUS) {

        if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

            M2M_INFO("Now OTA successfully done");

            //start the host SW upgrade then system reset is required (Reinitialize the driver)

        }

    }

}

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

    case M2M_WIFI_REQ_DHCP_CONF:

    {

        //after successfully connection, start the over air upgrade

        m2m_ota_start_update(OTA_URL);

    }

    break;

    default:

    break;

}

int main (void)

{

    tstrWifiInitParam param;

    tstr1xAuthCredentials gstrCred1x    = AUTH_CREDENTIALS;

    nm_bsp_init();

    m2m_memset((uint8*)&param, 0, sizeof(param));

    param.pfAppWifiCb = wifi_event_cb;

    //Initialize the WINC Driver

    ret = m2m_wifi_init(&param);

    if (M2M_SUCCESS != ret)

    {

        M2M_ERR("Driver Init Failed <%d>\n",ret);

        while(1);

    }

    //Initialize the OTA module

    m2m_ota_init(OtaUpdateCb,NULL);

    //connect to AP that provide connection to the OTA server

    m2m_wifi_default_connect();

    while(1)

    {

        //Handle the app state machine plus the WINC event handler                                                                    

        while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

        }

    }

}

Listing 1: In diesem OTA-Codebeispiel aus dem Microchip Advanced Software Framework-Paket initiiert ein Wi-Fi-Ereignishandler-Callback wifi_event_cb() das OTA-Update m2m_ota_start_update(OTA_URL) über die angegebene URL und wechselt zur neuen Firmware m2m_ota_switch_firmware(), sobald die Aktualisierung erfolgreich abgeschlossen ist OtaUpdateCb(). (Codequelle: Microchip Technology)

Um zu überprüfen, ob der heruntergeladene Code gültig ist, haben sich Entwickler lange auf Codesignatur-Zertifikate gestützt, die von einer anerkannten Zertifizierungsstelle ausgestellt wurden. Dennoch bieten Schwachstellen bei der sicheren Datenspeicherung, der Implementierung von Validierungstechniken und dem Zertifikatsschutz Hackern verschiedene Möglichkeiten, die Kontrolle über ein IoT-Gerät zu übernehmen.

Bei herkömmlichen Sicherheitstechniken kann der geräteeigene Firmware-Aktualisierungsprozess so manipuliert werden, dass er den eigenen gültigen Code durch kompromittierten Code ersetzt. Nach dem Neustart nutzt der Hacker dann das Gerät, um tiefer in das IoT-Netzwerk, die IoT-Anwendung und sogar in die internen Ressourcen eines Unternehmens einzudringen.

In einem solchen Szenario ist die entscheidende Verteidigungsmaßnahme das sichere Booten des IoT-Geräts. Für Entwickler stellt die Implementierung von sicherem Booten jedoch mehrere Anforderungen an sichere Speicher-, Verschlüsselungs-, Authentifizierungs- und Codevalidierungsmechanismen.

Wenn sicheres Booten in die Software implementiert wird, ist der Update-Prozess weiterhin Angriffsmethoden ausgesetzt. Sie zielen darauf ab, sichere Schlüssel aus dem Gerätespeicher abzurufen, verschlüsselte Daten abzufangen, Authentifizierungsmechanismen zu fälschen und Code-Validierungsalgorithmen zu kompromittieren. In der Praxis fehlt den IoT-Designs in der Regel die zusätzliche Speicher- und Verarbeitungsleistung, die für eine Softwarelösung in diesen Fällen erforderlich wäre. Aber auch eine Implementierung in der Hardware kann nicht immer Sicherheit garantieren.

Um sicheres Booten in der Hardware zu implementieren, benötigten IoT-Geräte bis vor Kurzem noch eine Reihe von spezialisierten Bausteinen, die Komplexität und Kosten von Designs in die Höhe trieben. Doch selbst wenn Entwickler solche separaten Bausteine integrieren würden, könnten sich entschlossene Hacker leicht ein Muster des IoT-Zielgeräts beschaffen und die einzelnen Sicherheitsbausteine über ihre Bus- und Signalverbindung angreifen. Zur Umgehung dieser Schwachstellen bietet Microchip Technology mit dem ATECC608A eine Einzelchiplösung an, mit der Entwickler sicheres Booten implementieren können, ohne die zugrunde liegenden Geheimnisse oder Sicherheitsmechanismen offenzulegen.

Sicherheits-IC

Der ATECC608A ist ein 8-poliger Sicherheitsbaustein, der eine Host-MCU mit einer komplexen Reihe von Sicherheitsfunktionen über eine einfache serielle Schnittstelle unterstützt (Abbildung 1).

Abbildung 1: Der ATECC608A ist ein kryptographischer 8-Pin-Coprozessor mit sicherem hardwarebasiertem Schlüsselspeicher. (Bildquelle: Microchip Technology)

Das Gerät bietet eine vollständige hardwarebasierte Sicherheitslösung, die integrierte Krypto-Beschleuniger mit einem sicheren On-Chip-Speicher kombiniert und eine Vielzahl von Verschlüsselungsalgorithmen wie SHA-256, AES-128 und robuste elliptische Kurvenalgorithmen wie Elliptic Curve Digital Signature (ECDSA), Elliptic Curve Diffie-Hellman (ECDH) und NIST-Kurve P-256 unterstützt. Über diese Verschlüsselungsmechanismen hinaus unterstützt der Baustein TLS-Protokolle (Transport Layer Security) auf höherer Ebene, einschließlich TLS 1.3. Im Gegensatz zu früheren Bausteinen kann der ATECC608A Sitzungsschlüssel generieren und sicher speichern, wodurch eine häufige Quelle von Bedrohungen eingedämmt wird, die mit der TLS-Authentifizierung verbunden sind.

Diese Funktionen spielen eine fundamentale Rolle bei der Sicherung des Normalbetriebs von IoT-Geräten. Die Unterstützung von sicherem Boten im ATECC608A erweitert die Sicherheit auf den so grundlegenden Firmware-Aktualisierungsprozess. Hierbei validiert der ATECC608A den neuen Code-Satz und gibt eine Nachricht über Erfolg oder Misserfolg an die MCU zurück. An diesem Punkt kann die MCU – je nach geltender Sicherheitsrichtlinie – die Aktualisierung wiederholen, eine Warnmeldung an einen Endpunkt des Sicherheitsmonitors senden, den Prozess anhalten oder die Aktualisierung ignorieren und den ursprünglichen Code neu starten.

Hardwareintegration

Für den Entwickler stellt der ATECC608A relativ wenige zusätzliche Anforderungen, um einem MCU-basierten Design sicheres Booten und andere Sicherheitsfunktionen hinzuzufügen. Auf der Hardwareseite muss sich der Designer um maximal vier Anschlüsse kümmern: V_CC, GND, serieller Takteingang (SCL) und serielle Daten (SDA). Die restlichen vier Pins werden nicht verbunden. Abgesehen von dem Anschluss von V_CC an eine Versorgungsquelle von 2,0 V bis 5,5 V ist die einzig verbleibende Entscheidung die serielle Verbindung zur MCU.

Entwickler können die SCL- und SDA-Pins des Geräts für konventionelle I²C-Konnektivität an die MCU anschließen. Alternativ kann auch die Unterstützung des Bausteins für die 1-Wire-Schnittstelle von Microchip genutzt werden. Hierbei wird der SDA-Port des Bausteins mit einem GPIO-Pin der MCU verbunden. Für die Übertragung der logischen Werte 0 und 1 wird das 1-Wire-Timing-Protokoll von Microchip verwendet (Abbildung 2).

Abbildung 2: Im seriellen 1-Wire-Protokoll von Microchip signalisiert eine Sequenz von Signalübergängen mit bestimmter Dauer eine logische 0 oder eine logische 1. (Bildquelle: Microchip Technology)

In diesem Protokoll beginnt eine Übertragung des logischen Werts zwischen dem ATECC608A und der MCU mit einem Startimpuls (t_START) von bestimmter Dauer. Nach dem Startimpuls definiert das Protokoll eine logische 0 als den Zyklus eines Null-Sende-High-Impulses (t_ZHI), gefolgt von einem Null-Sende-Low-Impuls (t_ZLO) einer festgelegten Dauer. Analog dazu bedeutet ein anhaltender High-Pegel die Übertragung einer logischen 1.

In beiden Fällen erwartet das Protokoll, dass ein Signal innerhalb einer festgelegten Bitzeit (t_BIT) wieder abfällt. Der Baustein kann so programmiert werden, dass er automatisch in den Ruhemodus schaltet, wenn nach einer Reihe von Bitübertragungen die serielle Leitung nach einer festgelegten IO-Timeout-Dauer inaktiv wird. Um mit dem ATECC608A arbeiten zu können, müssen Entwickler sich jedoch selten mit den Timing-Details dieses Protokolls befassen: Microchip hat die wichtigsten Timing-Parameter so definiert, dass sie mit einem Standard-UART kompatibel sind, der mit 230,4 kBaud ausgeführt wird.

Gerätekonfiguration

Auf Geräteebene erfordert der ATECC608A minimale Konfigurationseinstellungen. Über die serielle I²C- oder 1-Wire-Schnittstelle können Entwickler Einstellungen wie die I²C-Adresse laden oder Funktionen wie den Selbsttest beim Wakeup oder Einschalten einrichten. Der Baustein bietet eine Konfigurationseinstellung, die besonders für IoT-Designs mit extrem niedrigem Stromverbrauch relevant sein kann.

Bei diesen Designs trägt der ATECC608A mit seinen Leerlauf- oder Ruhemodi – in der Regel die häufigsten Zustände in einem IoT-Design – relativ wenig zu dem gesamten Leistungsbudget bei. Im Leerlauf verbraucht das Gerät etwa 800 Mikroampere (μA), im Ruhemodus je nach Konfiguration 150 Nanoampere (nA) oder weniger. Wenn die MCU den Baustein „aufweckt“, um einen Sicherheitsprozess auszuführen, erreicht sein Stromverbrauch im aktiven Betrieb trotzdem nur 14 mA. Dennoch erfordern Designs mit sehr engen Leistungsbudgets möglicherweise einen noch geringeren aktiven Stromverbrauch.

Für solche Fälle bietet der Baustein eine Konfigurationsoption, mit der Entwickler drei verschiedene Betriebsmodi auswählen können, die den Stromverbrauch über die Ausführungsgeschwindigkeit steuern. So kann der aktive Stromverbrauch von 14 mA bei maximaler Ausführungsgeschwindigkeit auf 6 mA bzw. 3 mA mit entsprechend niedrigeren Ausführungsgeschwindigkeiten reduziert werden.

Abgesehen von verschiedenen Low-Level-Konfigurationselementen ist ein Sicherheitsbaustein wie der ATECC608A effektiver, wenn seine Sicherheitsinformationen bereits vor der Entwicklung an Ort und Stelle sind. Denn Fehler oder Exploits bei sicheren Schlüsseln und Zertifikaten, die während der Entwicklung eingeführt werden, können auch die besten Sicherheitsmaßnahmen zunichte machen. Um diese Problematik zu umgehen, lädt der vertrauenswürdige Bereitstellungsdienst von Microchip bereits im Herstellungsprozess die Sicherheitsdaten einschließlich Schlüssel und Zertifikate auf den Baustein.

Sind die sicheren Daten werkseitig in sicherer Umgebung erst einmal geladen, bleiben sie vor zufälliger oder beabsichtigter Offenlegung geschützt, selbst wenn der Baustein die normalen Handhabungsprozesse in der Lieferkette durchläuft. Der ATECC608A verfügt über eine spezielle Transportsicherungsfunktion: Der Baustein bleibt so lange deaktiviert, bis er mit einem bekannten Schlüssel, der von der entsprechenden Host-MCU übertragen wird, kryptografisch aktiviert wird.

Sobald der ATECC608A von der Host-MCU aktiviert wurde, generiert er nach dem Zufallsprinzip einen geheimen IO-Schutzschlüssel (IO Protection Key), den er der MCU mitteilt. Mit diesem Schlüssel wird die nachfolgende Kommunikation zwischen ATECC608A und MCU verschlüsselt. Dieser Mechanismus bietet eine zusätzliche Authentifizierungsmöglichkeit während des sicheren Bootvorgangs und anderer sicherer Prozesse.

Wenn Hacker den Validierungsprozess fälschen wollen, indem sie die Verbindung zum ATECC608A unterbrechen und ihr eigenes „Erfolgssignal“ an die MCU senden, würde dieser IO-Schutzschlüsselmechanismus veranlassen, dass die MCU das gefälschte Signal ignoriert. Selbst wenn es einem Hacker gelingt, einen ATECC608A-Baustein zu kompromittieren, und er versuchen würde, ihn in einem anderen System zu verwenden, würde der IO-Schutzschlüsselmechanismus dies verhindern.

Softwareintegration

Trotz seiner hochentwickelten Funktionen und Schutzmechanismen ist der ATECC608A einfach auf ein MCU-basiertes Design anzuwenden. Neben der Implementierung der oben erwähnten einfachen Hardwareschnittstelle und der erwähnten Konfigurationseinstellungen arbeiten Entwickler mit einer Anwendungsprogrammierschnittstelle (API), die die Details der Sicherheitsabläufe abstrahiert. Die kryptographische Authentifizierungsbibliothek von Microchip CryptoAuthLib bietet ein umfassendes Softwarepaket mit Definitionen, Strukturen und API-Aufrufen, die für die Nutzung der ATECC608A-Funktionen erforderlich sind. Diese Bibliothek dient als hardware-agnostische Schicht und arbeitet über die HAL-API (Hardware Abstraction Layer) und mit Treibern für bestimmte Hardware-Targets (Abbildung 3).

Abbildung 3: Die CryptoAuthLib-Bibliothek von Microchip stellt eine kryptographische Schicht zwischen einer Anwendung und der darunter liegenden Hardware bereit, auf die über eine Hardware-Abstraktionsschicht mit hardwarespezifischen Treibern zugegriffen wird. Sie ermöglicht die Portabilität zwischen verschiedenen Hardwaresätzen. (Bildquelle: Microchip Technology)

Entwickler verwenden CryptoAuthLib-API-Routinen wie io_protection_set_key() zum Erstellen eines IO-Schutzschlüssels und atcab_secureboot() zum Ausführen des Validierungsmechanismus des ATECC608A für das sichere Booten gegen den Code Digest oder die Signatur, die in den Aufrufparametern enthalten sind.

Obwohl die API-Befehle unkompliziert sind, können die für die Implementierung der Sicherheit erforderlichen spezifischen Setup-, Verwaltungs- und Ablaufschritte eine Herausforderung darstellen. Die Sicherheitsmechanismen, die Entwickler zu implementieren versuchen, können zu Verzögerungen führen, wenn wichtige Schritte fehlen oder nicht in der richtigen Reihenfolge ausgeführt werden.

Mit dem auf der MCU SAM D21 basierten Entwicklungskit ATSAMD21-XPRO von Microchip und der Zusatzkarte ATCRYPTOAUTH-XPRO-B, die den ATECC608A-Baustein enthält, können Entwickler schnell Erfahrungen mit diesen allgemeinen Mechanismen und den spezifischen Funktionen des ATECC608A sammeln. Microchip bietet ein umfassendes Softwarepaket für sicheres Booten an, das für die Ausführung mit dem ATSAMD21-XPRO und dem ATCRYPTOAUTH-XPRO-B ausgelegt ist. Als einfache Display-Schnittstelle für Beispielanwendungen dient das Board ATOLED1-XPRO von Mikrochip (Abbildung 4).

Abbildung 4: Entwickler können den Prozess des sicheren Bootens mit der Microchip-Software in kürzester Zeit auswerten. Die Versuchsanordnung besteht aus dem Entwicklungskit ATSAMD21-XPRO (mit MCU SAM D21) und den beiden Zusatzkarten ATCRYPTOAUTH-XPRO-B (mit ATECC608A) und ATOLED1-XPRO (als Display). (Bildquelle: Microchip Technology)

Im SAM-D21-Demopaket enthalten ist eine vollständige Routine für sicheres Booten zur Illustration der wichtigsten Software-Designmuster, die zum Einrichten, Ausführen und Überprüfen des Status einer Operation des sicheren Bootens verwendet werden (Listing 2). Mit dieser Hardwareplattform und dem Demo-Softwarepaket können Entwickler den Einsatz des ATECC608A für das Remote-Booten schnell evaluieren und die Beispielsoftware nach Bedarf an ihre eigenen Anforderungen anpassen.

Kopieren

/** \brief Handles secure boot functionality through initialization, execution,

 *         and de-initialization.

 *  \return ATCA_SUCCESS on success, otherwise an error code.

 */

ATCA_STATUS secure_boot_process(void)

{

    ATCA_STATUS status;

    secure_boot_parameters secure_boot_params;

    uint8_t secure_boot_mode;

    bool secure_boot_app_valid = false;

    /*Initialize secure boot */

    if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

    {

        return status;

    }

    do

    {

        .

        .

        .

        #if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

        .

        .

        .

        /*Get IO Protection Key*/

        if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

        {

            return status;

        }

        if ((status = atcab_secureboot_mac(secure_boot_mode,

                                           (const uint8_t*)&secure_boot_params.app_digest,

                                           (const uint8_t*)&secure_boot_params.memory_params.signature,

                                           (const uint8_t*)secure_boot_params.randomnum,

                                           (const uint8_t*)secure_boot_params.io_protection_key,

                                           &secure_boot_app_valid)) != ATCA_SUCCESS)

        {

            break;

        }

        #else

        if ((status = atcab_secureboot(secure_boot_mode,

                                       0,

                                       (const uint8_t*)&secure_boot_params.app_digest,

                                       (const uint8_t*)&secure_boot_params.memory_params.signature,

                                       NULL)) != ATCA_SUCCESS)

        {

            break;

        }

        secure_boot_app_valid = true;

        #endif

        /*Check whether the secure boot command executed successfully with the correct return mac  */

        if (!secure_boot_app_valid)

        {

            break;

        }

        .

        .

        .

    }

    while (0);

    /* De-initialize memory interface and release its resources*/

    secure_boot_deinit_memory(&secure_boot_params.memory_params);

    return status;

}

Listing 2: Dieser Ausschnitt aus dem SAMCH21-Demopaket von Microchip zeigt die wichtigsten Designmuster für sicheres Booten, einschließlich der Überprüfung auf einen IO-Schutzschlüssel (io_protection_get_key()) und Validierung der Firmware anhand seiner Digest-, Signatur- und anderen Parameter (atcab_secureboot_mac() oder atcab_secureboot()) je nach ausgewählter Konfiguration). (Codequelle: Microchip Technology)

Zusammenfassung

IoT-Geräte bieten Hackern, die kompromittierte Geräte als Zugang zu IoT-Netzwerken, Anwendungen und Unternehmensressourcen nutzen möchten, verschiedene Angriffsflächen. Unter den Sicherheitsmechanismen erweist sich sicheres Booten als entscheidende Komponente innerhalb einer umfassenden Sicherheitsstrategie. Die Implementierung von sicherem Booten bringt jedoch eigene Anforderungen mit sich, die das System angreifbar machen können, wenn sie nicht korrekt umgesetzt werden.

Mit dem Sicherheits-IC ATECC608A bietet Microchip Technology eine umfassende Lösung in einem Baustein an, der problemlos zu jedem MCU-basierten Design hinzugefügt werden kann. Mit dem ATECC608A können Entwickler die Sicherheit erheblich verbessern und einen sicheren Bootprozess in ihren IoT-Designs gewährleisten.