Een eenvoudigere oplossing voor het veilig verbinden van IoT-apparaten met de cloud

Ondanks een groeiend bewustzijn van de noodzaak van beveiliging kiezen ontwikkelaars nog te vaak voor de makkelijkste weg bij het verbinden van IoT-apparaten met de cloud. In veel gevallen lijken de conflicten tussen de complexiteit van geschikte beveiligingsmechanismen, het beperkte geheugen en de beschikbare verwerkingshulpmiddelen in minuscule batterijgevoede ivd-apparaten, en de noodzaak om het product te verzenden, onoverkomelijk.

Om deze problemen aan te pakken en de implementatie van beveiligingsfuncties in ivd-apparaten te vereenvoudigen, hebben Microchiptechnologie en Google samengewerkt om een aanpak te creëren die de veilige hardwaremogelijkheden van de Microchip combineert met een eenvoudige gegevensstructuur die een JSON Web Token (JWT) wordt genoemd. Het resultaat is een eenvoudige methode om te zorgen voor wederzijdse authenticatie tussen ivd-toestellen en Google Cloud IoT Core diensten.

In dit artikel wordt de bedreiging van de veiligheid van het ivd-apparaat beschreven en worden apparaten geïntroduceerd die momenteel worden gebruikt om die bedreiging tegen te gaan. Het zal de veiligheidshiaten identificeren en hoe ontwikkelaars en ingebedde systeemontwerpers JWT kunnen gebruiken om deze te dichten.

De kwetsbaarheid van de beveiliging van ivd-apparaten

Aanvallen op ivd-apparaten kunnen vele vormen aannemen en beperken zich geenszins tot grootschalige ivd-implementaties. Zelfs het kleinste ivd-netwerk is een aantrekkelijk doelwit voor hackers die de middelen van veel individuele apparaten in botnets voor gedistribueerde denial of service (DDoS)-aanvallen en andere aanvallen willen gebruiken. Als gevolg daarvan worden ontwerpers van elke klasse van ivd-apparatuur onvermijdelijk geconfronteerd met de noodzaak om hun systemen te beschermen met robuuste, op hardware gebaseerde beveiligingsmechanismen die in staat zijn om aanvallen tegen te gaan.

Het gebruik van het systeemgeheugen of de flash om privé-sleutels op te slaan die voor encryptie en authenticatie worden gebruikt, maakt het ivd-apparaat bijvoorbeeld kwetsbaar. Erger nog, hackers kunnen die sleutels stelen en gebruiken om toegang te krijgen tot het ivd-netwerk en de aangesloten bedrijfsmiddelen.

Beveiligings-IC's

Gespecialiseerde beveiligingsapparaten zoals Microchip Technologie's CryptoMemory en CryptoAuthenticatie IC's zijn voorzien van hardware-gebaseerde mechanismen om privé-sleutels en andere geheime gegevens te beschermen. Als gevolg daarvan bieden deze apparaten een eenvoudige methode om veilige opslag en andere beveiligingsfuncties toe te voegen aan elk ontwerp van een ivd-apparaat.

Figuur 1: Microchiptechnologie hardware beveiligingsapparaten zoals de AT88SC0204C CryptoMemory IC zorgen voor veilige opslag, met behulp van geïntegreerde cryptografische mechanismen om de toegang tot on-chip EEPROM te beschermen. (Bron afbeelding: Microchip Technology)

Leden van de Microchip CryptoAuthentication familie zoals de ATECC608A verbeteren die veilige opslag basis met ondersteuning voor cryptografie algoritmen die vaak gebruikt worden in veilige ontwerpen. Onder zijn hardware-eigenschappen, kenmerkt het apparaat hardwareversnelling voor veelvoudige algoritmen met inbegrip van:

• Asymmetrische cryptografische algoritmen:
  • FIPS186-3 elliptische curve digitaal handtekeningalgoritme (ECDSA)
  • FIPS SP800-56A elliptische curve Diffie-Hellman (ECDH)
  • NIST Standaard P256 elliptische curvecryptografie (ECC)
• Symmetrische cryptografie-algoritmen:
  • SHA-256 hasjcryptografie
  • Hash-based message authentication code (HMAC) cryptografie
  • AES-128 cryptografie
  • AES-GCM (Galoisveld vermenigvuldigen) cryptografie
• Belangrijkste afleidingsfuncties (KDF's):
  • Pseudorandom-functie (PRF) KDF
  • HMAC-gebaseerde extract-and-expand KDF (HKDF)

Voor cryptografiedeskundigen vertegenwoordigt deze set van crypto-functies een uitgebreide lijst van mechanismen die nodig zijn om beveiligingsprotocollen op een hoger niveau voor authenticatie en veilige gegevensuitwisseling te ondersteunen. De KDF-capaciteit biedt bijvoorbeeld essentiële mechanismen die nodig zijn voor het transportlaagbeveiligingsprotocol (TLS) voor de authenticatie van deelnemers aan een gegevensuitwisselingssessie voordat die uitwisseling zelfs maar begint.

In dit protocol begint een TLS-sessie met een client die de server een verzoek stuurt om een beveiligde sessie te starten. De server reageert met een digitaal certificaat, waarmee de client de identiteit van de server bevestigt. Nadat de client de server op deze manier heeft geverifieerd, gaat de sessie-instelling verder met het genereren van een sessiesleutel door gebruik te maken van de publieke sleutel van de server om een willekeurige waarde te versleutelen die is gecreëerd met behulp van een PRF KDF of een meer robuuste HDKF.

Het TLS-authenticatieprotocol is fundamenteel voor de veiligheid van het internet. Een hele industrie van certificaataanbieders, de zogenaamde certificate authorities (CA's), is geëvolueerd om deze kritische component van beveiligde communicatie te ondersteunen. Bedrijven verwerven vertrouwde certificaten van CA's om op hun eigen servers te installeren ter ondersteuning van het hierboven beschreven standaard TLS-serververificatieprotocol.

Voor ivd-toepassingen, waarbij netwerken breed en diep in verbinding staan met bedrijfsbronnen, is dit soort eenrichtingsauthenticatie niet voldoende om bescherming te garanderen. Zo zouden hackers met frauduleuze certificaten zich kunnen voordoen als legitieme servers voor ivd-apparaten als onderdeel van een bredere aanval.

Ondanks het risico, hebben ivd-ontwikkelaars vaak moeite om het TLS protocol voor wederzijdse authenticatie te implementeren omdat de certificaten, sleutels en software die nodig zijn om de cliëntauthenticatie met TLS te implementeren, de mogelijkheden van veel ivd-apparaten kunnen overtreffen. Door samen te werken hebben Microchip Technologie en Google een alternatieve aanpak gecreëerd die de ATECC608A-mogelijkheden combineert met een eenvoudige datastructuur die een JSON Web Token (JWT) wordt genoemd. Het resultaat is een eenvoudige methode om te zorgen voor wederzijdse authenticatie tussen ivd-toestellen en Google Cloud IoT Core diensten.

JWT-gebaseerde authenticatie

Gespecificeerd in RFC 7519, is de JWT een industriestandaard container voor informatie, genaamd claims, over de entiteit die de JWT voorbereidt en verzendt. De JWT-structuur zelf bestaat uit drie delen:

• Koptekst, die JSON-naam bevat: waardeparen voor de naam ("alg") van het cryptografiealgoritme (bijvoorbeeld "EC256" voor ECDSA met behulp van de NIST P-256-curve) die wordt gebruikt om de penning te ondertekenen en voor het type ("type") van de penning ("JWT" voor deze penningen)
• Laadvermogen, inclusief JSON naam:waardeparen voor elke claim
• Handtekening, die het in de header gespecificeerde algoritme gebruikt om een geheime sleutel te coderen, samen met de header en de claimset, elk afzonderlijk geconverteerd naar een basis64 URL-gecodeerde representatie vóór de codering.

RFC 7519 biedt een grote mate van flexibiliteit voor het specificeren van claims in het laadvermogen of andere secties. De standaard laat zelfs onbeveiligde JWT's toe, aangemaakt zonder handtekening of encryptie, in welk geval de header de naam:waardepaar voor het algoritme zou bevatten als {"alg": "geen"}. Voor JWT's gebruikt met Google Cloud IoT Core diensten, Google vereist de handtekening sectie en een payload met drie verplichte claims, waaronder:

• "iat" - het "afgegeven" tijdstip waarop de penning in ISO 8601 UTC-tijdstempelformaat als seconden werd aangemaakt sinds 1970-01-01T00:00:00Z (bijvoorbeeld 1561896000 voor 30 juni 2019 12:00:00 GMT).
• "exp" - het UTC-tijdstempel dat de vervaldatum aangeeft met een maximum van 24 uur na de "iat"-waarde plus een aflossingsvrije periode van tien minuten om rekening te houden met de scheefheid van de systeemklok tussen verschillende clients en servers (bijvoorbeeld 1561982400 voor 1 juli 2019 12:00:00 PM GMT).
• "aud" - een string met het Google Cloud project ID van de ontwikkelaar...

Google's schema voor ivd-authenticatie combineert normale serverauthenticatie op basis van TLS met ivd-authenticatie met behulp van een JWT dat is gemaakt met deze relatief eenvoudige claims. Om een nieuwe sessie te starten, opent een ivd-apparaat een beveiligde socket naar de server en authentiseert het de server met behulp van hetzelfde TLS-protocol dat eerder is beschreven.

De volgende stap in dit proces is het gebruik van de Google ivd-wolk van het lichte protocol voor telemetrietransport (MQTT) in de wachtrij voor ivd-netwerktransacties. Met behulp van de beveiligde socket naar de geauthenticeerde server "logt" het ivd-apparaat in op de MQTT-hostdiensten van die server, met behulp van zijn unieke JWT als login-wachtwoord (Listing 1).

/* 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;
}

Lijst 1: In de Microchip Technologie software sample repository voor Google Cloud Platform IoT Core, biedt een module routines voor het genereren van een dummy gebruikersnaam en JWT object voor gebruik als het wachtwoord voor client-authenticatie met een MQTT-host. (Codebron: Microchip Technology)

Hoewel het ivd-apparaat een gebruikersnaam stuurt als onderdeel van deze aanmeldingsreeks, wordt de gebruikersnaam niet gebruikt voor de authenticatie. Bijgevolg wordt een dummy gebruikersnaam doorgegeven (Lijst 2). In plaats daarvan wordt de authenticatie van het ivd-apparaat uitgevoerd op basis van het JWT dat als login-wachtwoord wordt verzonden. Omdat de JWT handtekening een combinatie is van de header, de payload en de private key van het apparaat, kunnen de Google Cloud IoT Core diensten verifiëren dat de JWT echt afkomstig is van een geautoriseerd apparaat. Voor deze verificatie maakt Google Cloud IoT-services gebruik van de openbare sleutel van het apparaat die eerder door de ontwikkelaar van het ivd-apparaat in de Google-cloud werd opgeslagen met behulp van een sleutelbeheerproces dat hieronder wordt beschreven. In tegenstelling tot het gebruik van TLS alleen, biedt deze aanpak wederzijdse authenticatie door middel van een hybride aanpak die het proces versnelt en tegelijkertijd de behoefte aan middelen voor het ivd-apparaat vermindert.

/* 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);
}

Lijst 2: Deze functie demonstreert het gebruik van een JWT-object als wachtwoord dat het ivd-apparaat authentiek maakt voor de MQTT-server tijdens de eerste verbindingsfase. (Codebron: Microchip Technology)

Kritische enablers

De capaciteiten van de ATECC608A en zijn toeleveringsketen zijn de kritische voorwaarden voor deze aanpak. Hoewel elke MCU uiteindelijk een cryptografisch versleutelde handtekening zou kunnen genereren uit de JWT header en payload, zou elke aanpak die alleen met software wordt uitgevoerd nog steeds kwetsbaar zijn zonder hardwarematige beveiligde sleutelopslag. Bovendien kan de processorbelasting en de uitvoeringsvertraging die nodig zijn voor een "software only"-implementatie, onbetaalbaar zijn voor veel ivd-apparaten of -toepassingen met een beperkte hoeveelheid middelen en een korte reactietijd. Tot slot zouden ontwikkelaars zonder uitgebreide ervaring met beveiligingsalgoritmen en protocollen op een hoger niveau moeilijk de vereiste softwarefunctionaliteit kunnen implementeren. De microchip pakt deze zorgen aan met zijn CryptoAuthLib-bibliotheek (figuur 2).

Cijfer 2: Omdat de CryptoAuthLib gebruik maakt van een hardware-abstractielaag (HAL) om de API-functies en kernprimitieven te scheiden van de onderliggende hardware, kunnen ontwikkelaars hun software richten op een breed scala aan ondersteuningsapparaten. (Bron afbeelding: Microchip Technology)

De Microchip CryptoAuthLib vereenvoudigt de implementatie van veilige ivd-functies zoals het Google JWT-authenticatieprotocol, waardoor complexe beveiligingsoperaties worden gereduceerd tot een reeks functie-aanroepen die via de CryptoAuthLib applicatie-programmeerinterface (API) worden aangeboden. Misschien wel het meest belangrijk voor ivd-ontwikkelaars, de Microchip CryptoAuthLib kernfuncties maken optimaal gebruik van Microchip crypto IC's zoals de ATECC608A om de uitvoering van de veiligheidskenmerken in een ontwerp te versnellen. Bijvoorbeeld, de oproep om atca_jwt_finalize() in Listing 1 gebruikt een beschikbaar crypto apparaat zoals de ATECC608A om de JWT te maken die gebruikt wordt als het wachtwoord in Listing 2. In dit geval versnelt de ATECC608A de encryptie van de JWT-handtekening, waarbij de privé-sleutel van het ontwerp uit de geïntegreerde beveiligde opslag wordt gelezen om het eerder beschreven proces voor het aanmaken van de handtekening te voltooien.

Zelfs met het gebruik van geavanceerde software en beveiligingsapparatuur kunnen ivd-apparaten echter kwetsbaar blijven als gevolg van methoden die van oudsher nodig zijn voor het beheer van sleutels en certificaten. In het verleden moesten privé-sleutels extern worden gegenereerd en in beveiligde opslagapparaten worden geladen tijdens de productie, de distributie of zelfs de inzet. Zelfs met het gebruik van hardware veiligheidsmodules en veilige faciliteiten, vertegenwoordigt het vluchtige bestaan van deze geheimen buiten het enige apparaat dat ze "moet weten" een veiligheidszwakte die kan leiden tot hun blootstelling per ongeluk of met opzet. Door gebruik te maken van de mogelijkheden van de ATECC608A hebben Microchip en Google deze traditionele zwakte in de beveiliging grotendeels geëlimineerd.

In deze nieuwe aanpak gebruikt de Microchip de mogelijkheid van de ATECC608A om sleutelparen te genereren zonder dat de privé-sleutels het apparaat ooit verlaten (Figuur 3). Microchip ondertekent vervolgens het apparaat gegenereerde publieke sleutels met een tussenliggend certificaat dat door de klant is verstrekt en dat is opgeslagen op een beveiligde server binnen de beveiligde microchipfaciliteit. Tot slot stuurt Microchip de publieke sleutels veilig door naar de account van de klant in Google Cloud IoT Device Manager, die tot drie publieke sleutels voor elk apparaat kan opslaan om het sleutelrotatiebeleid te ondersteunen. Eenmaal uitgerold kan een ivd-apparaat de ATECC608A-beveiligingsfuncties gebruiken om het JWT te creëren dat wordt gebruikt in het eerder beschreven proces van wederzijdse authenticatie.

Figuur 3: Microchiptechnologie en Google Cloud IoT diensten combineren om de levering van sleutels en certificaten te vereenvoudigen, en bieden een beschermd mechanisme dat is ontworpen om de beveiliging van ivd-toepassingen te verharden. (Bron afbeelding: Google)

Door deze samenwerking tussen Microchip en Google kunnen ontwikkelaars dit cruciale sleutelbeheerproces volledig uit handen nemen. Voor aangepaste eisen kunnen ontwikkelaars niettemin hun eigen sleutelbeheerproces implementeren, met behulp van de CryptoAuthLib API-functie atcab_genkey(), waardoor de ATECC608A een sleutelpaar genereert, de privé-sleutel in zijn beveiligde opslag opslaat en de bijbehorende publieke sleutel terugstuurt.

Om de belangrijkste generatie en andere ATECC608A beveiligingsmogelijkheden te verkennen, kunnen ontwikkelaars snel een uitgebreide ontwikkelomgeving opzetten rond de Microchip SAM D21 Xplained Pro evaluatiekit. Gebaseerd op de Microchip ATSAMD21J18A 32-bit Arm^® Cortex^®-M0+ MCU, biedt de SAM D21 Xplained Pro kit een compleet hardware platform dat wordt ondersteund door het Microchip Advanced Software Framework (ASF) van drivers en code modules.

Voor het evalueren van CryptoAuthenticatie apparaten inclusief de ATECC608A, kunnen ontwikkelaars eenvoudigweg een CryptoAuth XPRO-B add-on bord in een van de twee uitbreidingsheaders van het Xplained Pro bord steken. Microchip biedt voorbeeldsoftware voor het evalueren van de beveiligingsfunctionaliteit van de CryptoAuthLib met de ATECC608A. Verder kunnen ontwikkelaars een Microchip ATWINC1500-XPRO Wi-Fi add-on board aansluiten op de andere header om Microchip-voorbeeld software te draaien die de wederzijdse authenticatiestroom zoals beschreven in dit artikel aantoont, inclusief zowel TLS-server authenticatie als JWT-apparaatauthenticatie.

Conclusie

Hoewel de beveiliging van ivd-toepassingen meerdere vereisten met zich meebrengt, ligt een kritieke uitdaging vaak in het implementeren van wederzijdse authenticatie voor ivd-apparaten en cloudresources. In ivd-systemen met beperkte middelen kunnen conventionele protocollen het beschikbare geheugen en de beschikbare verwerkingsbronnen overstijgen. Met behulp van de CryptoAuthLib-bibliotheek van de Microchiptechnologie en het CryptoAuthentication IC van ATECC608A kunnen ontwikkelaars een efficiëntere aanpak implementeren op basis van JSON-webmunten voor het veilig verbinden van ivd-toestellen met Google Cloud IoT-services.