En lettere løsning til sikker tilslutning af IoT-enheder til skyen

På trods af voksende bevidsthed om behovet for sikkerhed, finder udviklere for ofte sig selv at genveje i sikkerhed for at forbinde IoT-enheder til skyen. I mange tilfælde virker konflikterne mellem kompleksiteten af egnede sikkerhedsmekanismer, den begrænsede hukommelse og de behandlingsressourcer, der er tilgængelige i små batteridrevne IoT-enheder, og behovet for at sende produktet, uoverstigelige.

For at løse disse problemer og forenkle implementeringen af sikkerhedsfunktioner i IoT-enheder,Microchip-teknologi og Google samarbejdede om at skabe en tilgang, der kombinerer Microchips sikre hardwarefunktioner med en simpel datastruktur kaldet et JSON Web Token (JWT). Resultatet er en nem metode til at sikre gensidig godkendelse mellem IoT-enheder og Google Cloud IoT Core-tjenester.

Denne artikel beskriver IoT-enhedens sikkerhedstrussel og introducerer enheder, der i øjeblikket bruges til at imødegå denne trussel. Det identificerer sikkerhedshullerne, og hvordan udviklere og integrerede systemdesignere kan bruge JWT til at lukke dem.

Sikkerhedssårbarheden for IoT-enheder

Angreb på IoT-enheder kan tage mange former og er på ingen måde begrænset til IoT-implementeringer i stor skala. Selv det mindste IoT-netværk er et attraktivt mål for hackere, der ønsker at udnytte ressourcerne på mange individuelle enheder i botnets beregnet til distribueret denial of service (DDoS) -angreb og andre. Som et resultat står designere af enhver klasse af IoT-enheder uundgåeligt over for nødvendigheden af at beskytte deres systemer med robuste hardwarebaserede sikkerhedsmekanismer, der er i stand til at modvirke angreb.

For eksempel efterlader brugen af systemhukommelse eller flash til at gemme private nøgler, der bruges til kryptering og godkendelse, IoT-enheden sårbar. Værre er, hackere kan stjæle disse nøgler og bruge dem til at få adgang til IoT-netværket og tilknyttede virksomhedsressourcer.

Sikkerheds-IC'er

Specialiserede sikkerhedsanordninger såsom Microchip TechnologyCryptoMemory ogCryptoAuthentication IC'er har hardwarebaserede mekanismer til at beskytte private nøgler og andre hemmelige data. Integreret i disse enheder giver et EEPROM-array sikkert lager, der kun kan nås via kryptografisk sikre mekanismer, der er adgang til via enhedens SPI eller I² C serielt interface (figur 1). Som et resultat giver disse enheder en enkel metode til at tilføje sikker opbevaring og andre sikkerhedsfunktioner til ethvert design af IoT-enheder.

Figur 1: Microchip Technology hardware sikkerhedsenheder som f.eksAT88SC0204C CryptoMemory IC giver sikker opbevaring ved hjælp af integrerede kryptografiske mekanismer for at beskytte adgangen til EEPROM på chip. (Billedkilde: Microchip Technology)

Medlemmer af Microchip CryptoAuthentication-familien som f.eksATECC608A forbedre det sikre lagringsgrundlag med understøttelse af kryptografialgoritmer, der ofte bruges i sikre designs. Blandt hardwarefunktionerne har enheden hardwareacceleration til flere algoritmer, herunder:

• Asymmetriske kryptografialgoritmer:
  • FIPS186-3 elliptisk kurve digital signaturalgoritme (ECDSA)
  • FIPS SP800-56A elliptisk kurve Diffie-Hellman (ECDH)
  • NIST Standard P256 elliptisk kurve-kryptografi (ECC)
• Symmetriske kryptografi algoritmer:
  • SHA-256 hash-kryptografi
  • Hash-baseret beskedgodkendelseskode (HMAC) kryptografi
  • AES-128 kryptografi
  • AES-GCM (Galois felt multiplicere) kryptografi
• Nøgledivationsfunktioner (KDF'er):
  • Pseudorandom-funktion (PRF) KDF
  • HMAC-baseret ekstrakt-og-udvid KDF (HKDF)

For kryptografiskeksperter repræsenterer dette sæt kryptofunktioner en omfattende liste over mekanismer, der er nødvendige for at understøtte højere sikkerhedsprotokoller til godkendelse og sikker dataudveksling. For eksempel tilvejebringer KDF-kapaciteten vigtige mekanismer, der kræves til TLS-protokollen for transportlag til godkendelse af deltagere i en dataudvekslingssession, før udvekslingen overhovedet begynder.

I denne protokol begynder en TLS-session med, at en klient sender serveren en anmodning om at indlede en sikker session. Serveren reagerer med sit digitale certifikat, som klienten bruger til at bekræfte serverens identitet. Når klienten har godkendt serveren på denne måde, fortsætter sessionsopsætningen med, at klienten genererer en sessionsnøgle ved at bruge serverens offentlige nøgle til at kryptere en tilfældig værdi oprettet ved hjælp af en PRF KDF eller mere robust HDKF.

TLS-godkendelsesprotokollen er grundlæggende for internetsikkerhed. En hel industri af certifikatudbydere, kaldet certifikatmyndigheder (CA'er), har udviklet sig til at understøtte denne kritiske komponent af sikker kommunikation. Virksomheder erhverver pålidelige certifikater fra CA'er til at installere på deres egne servere for at understøtte standard TLS-servergodkendelsesprotokol beskrevet ovenfor.

For IoT-applikationer, hvor netværk forbinder bredt og dybt med virksomhedskilder, er denne form for envejsgodkendelse ikke nok til at sikre beskyttelse. For eksempel kunne hackere med falske certifikater repræsentere sig selv som legitime servere til IoT-enheder som en del af et bredere angreb.

På trods af risikoen kæmper IoT-udviklere ofte med at implementere TLS-gensidig godkendelsesprotokol, fordi de certifikater, nøgler og software, der er nødvendige for at implementere klientgodkendelse med TLS, kan overstige kapaciteten hos mange IoT-enheder. I samarbejde med Microchip Technology og Google har de skabt en alternativ tilgang, der kombinerer ATECC608A-funktioner med en simpel datastruktur kaldet JSON Web Token (JWT). Resultatet er en nem metode til at sikre gensidig godkendelse mellem IoT-enheder og Google Cloud IoT Core-tjenester.

JWT-baseret godkendelse

Specificeret i RFC 7519 er JWT en industristandardcontainer til information, kaldet krav, om den enhed, der forbereder og transmitterer JWT. Selve JWT-strukturen består af tre sektioner:

• Overskrift, som inkluderer JSON-navn: værdipar til navnet ("alg") på kryptografialgoritmen (f.eks. "EC256" til ECDSA ved hjælp af NIST P-256-kurven), der bruges til at underskrive tokenet og til typen ("typ ") af token (" JWT "for disse tokens)
• Nyttelast, som inkluderer JSON-navn: værdipar for hvert krav
• Signatur, der bruger algoritmen specificeret i headeren til at kode en hemmelig nøgle sammen med headeren og kravsættet, hver konverteret hver for sig til base64 URL-kodet repræsentation før kryptering

RFC 7519 giver stor fleksibilitet til at specificere krav i nyttelasten eller andre sektioner. Standarden tillader endda usikrede JWT'er, oprettet uden signatur eller kryptering, i hvilket tilfælde overskriften indeholder navnet: værdipar for algoritmen som {"alg": "none"}. For JWT'er, der bruges med Google Cloud IoT Core-tjenester, kræver Google signaturafsnittet samt en nyttelast med tre obligatoriske krav, herunder:

• "iat" - det "udstedte" tidspunkt, da tokenet blev oprettet i ISO 8601 UTC tidsstempelformat som sekunder siden 1970-01-01T00: 00: 00Z (for eksempel 1561896000 til 30. juni 2019 12:00:00 GMT )
• "exp" - UTC-tidsstempel, der specificerer tokenudløb med maksimalt 24 timer efter "iat" -værdi plus en ti-minutters frist for at tage højde for systemurets skævhed mellem forskellige klienter og servere (for eksempel 1561982400 for 1. juli 2019 12 : 00: 00 GMT)
• "aud" - en streng, der indeholder udviklerens Google Cloud-projekt-id

Googles skema for IoT-enhedsgodkendelse blander normal servergodkendelse baseret på TLS med IoT-enhedsgodkendelse ved hjælp af en JWT oprettet med disse relativt enkle krav. For at starte en ny session åbner en IoT-enhed et sikkert stik til serveren og godkender serveren ved hjælp af den samme TLS-protokol, der er beskrevet tidligere.

Det næste trin i denne proces er afhængig af Google IoT-skyens anvendelse af den lette MQTT-protokol (Message Queuing Telemetry Transport) til IoT-netværkstransaktioner. Ved hjælp af den sikre stikkontakt til den godkendte server logger IoT-enheden ind på serverens MQTT-hosttjenester ved hjælp af dens unikke JWT som loginadgangskode (liste 1).

Kopi
/* 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: Inkluderet i Microchip Technologysoftwareprøveopbevaringssted til Google Cloud Platform IoT Core giver et modul rutiner til generering af et dummy-brugernavn og JWT-objekt til brug som adgangskode til klientgodkendelse med en MQTT-vært. (Kildekilde: Microchip Technology)

Selvom IoT-enheden sender et brugernavn som en del af denne login-sekvens, bruges brugernavnet ikke til godkendelse. Derfor transmitteres et dummy-brugernavn (lister 2). I stedet fortsætter godkendelsen af IoT-enheden baseret på JWT sendt som loginadgangskoden. Da JWT-signaturen er en kombination af header, nyttelast og enhedens private nøgle, kan Google Cloud IoT Core-tjenester verificere, at JWT virkelig stammer fra en autoriseret enhed. Til denne verifikation bruger Google Cloud IoT-tjenester enhedens offentlige nøgle, der tidligere blev gemt i Google skyen af IoT-enhedsudvikleren ved hjælp af en nøglehåndteringsproces beskrevet nedenfor. I modsætning til brugen af TLS alene giver denne tilgang gensidig godkendelse gennem en hybrid tilgang, der fremskynder processen, samtidig med at kravene til IoT-enhedens ressourcer reduceres.

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

Liste 2: Tilvejebragt i prøveopbevaringsstedet til Microchip-softwaren, demonstrerer denne funktion brugen af et JWT-objekt som adgangskode, der autentificerer IoT-enheden til MQTT-serveren under den indledende tilslutningsfase. (Kildekilde: Microchip Technology)

Kritiske aktivatorer

Funktionerne i ATECC608A og dens forsyningskæde er de afgørende aktiver for denne tilgang. Selvom enhver MCU i sidste ende kunne generere en kryptografisk krypteret signatur fra JWT-headeren og nyttelasten, ville enhver tilgang udelukkende med software stadig være sårbar uden hardwarebaseret sikker nøgleopbevaring. Derudover kan processorens belastnings- og udførelsesforsinkelse, der kræves til en "kun software" -implementering, være uoverkommelig for mange ressourcebegrænsede IoT-enheder eller applikationer med strenge krav til responstid. Endelig ville udviklere uden omfattende erfaring inden for sikkerhedsalgoritmer og protokoller på højere niveau blive hårdt presset til at implementere den nødvendige softwarefunktionalitet. Microchip løser disse bekymringer med sit CryptoAuthLib-bibliotek (figur 2).

Figur 2: Fordi CryptoAuthLib bruger et hardware-abstraktionslag (HAL) til at adskille API-funktionerne og de primære primitiver fra den underliggende hardware, kan udviklere målrette deres software til en bred vifte af supportenheder. (Billedkilde: Microchip Technology)

Microchip CryptoAuthLib forenkler implementeringen af sikre IoT-funktioner såsom Google JWT-godkendelsesprotokol, hvilket reducerer komplekse sikkerhedshandlinger til et sæt funktionsopkald, der leveres via CryptoAuthLib-programmeringsgrænsefladen (API). Måske mest vigtig for IoT-udviklere, Microchip CryptoAuthLib-kernefunktionerne drager fuld fordel af Microchip crypto IC'er såsom ATECC608A for at fremskynde udførelsen af sikkerhedsfunktioner i et design. For eksempel bruger opkaldet til atca_jwt_finalize () i Listing 1 en tilgængelig kryptoenhed, såsom ATECC608A til at oprette JWT, der bruges som adgangskoden i Listing 2. I dette tilfælde accelererer ATECC608A kryptering af JWT-signaturen og læser designens private nøgle fra dens integrerede sikre lagring for at fuldføre den oprettelsesproces, der er beskrevet tidligere.

Selv med brug af sofistikeret software og sikkerhedsenheder kan IoT-enheder dog forblive sårbare på grund af metoder, der traditionelt er nødvendige for at administrere nøgler og certifikater. Tidligere skulle private nøgler genereres eksternt og indlæses i sikre lagerenheder under fremstilling, distribution eller endda implementering. Selv med brugen af hardwaresikkerhedsmoduler og sikre faciliteter repræsenterer den kortvarige eksistens af disse hemmeligheder uden for den eneste enhed, der "har brug for at kende" dem, en sikkerhedssvaghed, der kan føre til deres eksponering ved et uheld eller en hensigt. Ved at udnytte funktionerne i ATECC608A har Microchip og Google stort set elimineret denne traditionelle svaghed i sikkerhed.

I denne nye tilgang bruger Microchip ATECC608As evne til at generere nøglepar, uden at de private nøgler nogensinde forlader enheden (figur 3). Microchip underskriver derefter de enhedsgenererede offentlige nøgler med et mellemcertifikat, der blev leveret af kunden og lagret på en sikker server i Microchip-sikker facilitet. Endelig sender Microchip sikkert de offentlige nøgler til kundens konto i Google Cloud IoT Device Manager, som kan gemme op til tre offentlige nøgler til hver enhed til understøttelse af nøglerotationspolitikker. Når en IoT-enhed er implementeret, kan den bruge ATECC608A-sikkerhedsfunktioner til at oprette den JWT, der er brugt i den gensidige godkendelsesproces, der er beskrevet tidligere.

Figur 3: Microchip Technology og Google Cloud IoT-tjenester kombinerer for at forenkle tilvejebringelse af nøgler og certifikater, hvilket giver en beskyttet mekanisme designet til at hærde sikkerheden for IoT-applikationer. (Billedkilde: Google)

Dette samarbejde mellem Microchip og Google lader udviklere aflaste denne kritiske nøglehåndteringsproces fuldstændigt. For brugerdefinerede krav kan udviklere alligevel implementere deres egen nøglehåndteringsproces ved hjælp af CryptoAuthLib API-funktionen atcab_genkey (), som får ATECC608A til at generere et nøglepar, gemme den private nøgle i sin sikre opbevaring og returnere den tilknyttede offentlige nøgle.

For at udforske nøglegenerering og andre ATECC608A-sikkerhedsfunktioner kan udviklere hurtigt oprette et omfattende udviklingsmiljø bygget rundt mikrochippenSAM D21 Xplained Pro evalueringskit. Baseret på mikrochippenATSAMD21J18A 32-bit arm^® Cortex^® -M0 + MCU, SAM D21 Xplained Pro-kittet giver en komplet hardwareplatform understøttet af Microchip Advanced Software Framework (ASF) af drivere og kodemoduler.

Til evaluering af CryptoAuthentication-enheder inklusive ATECC608A kan udviklere simpelthen tilslutte enCryptoAuth XPRO-B tilføjelseskort til et af Xplained Pro-kortets to udvidelseshoveder. Microchip leverer eksempelsoftware til evaluering af CryptoAuthLib's sikkerhedsfunktionalitet med ATECC608A. Gå videre, kan udviklere tilslutte en mikrochipATWINC1500-XPRO Wi-Fi-tilføjelseskort til det andet overskrift for at køre Microchip-prøvesoftware, der demonstrerer den gensidige godkendelsesstrøm, der er beskrevet i denne artikel, inklusive både TLS-servergodkendelse og JWT-enhedsgodkendelse.

Konklusion

Selvom IoT-applikationssikkerhed bringer flere krav, ligger en kritisk udfordring ofte i implementeringen af gensidig godkendelse af IoT-enheder og skyressourcer. I ressourcebegrænsede IoT-systemer kan konventionelle protokoller overstige tilgængelige hukommelses- og behandlingsressourcer. Ved hjælp af Microchip Technology CryptoAuthLib-biblioteket og ATECC608A CryptoAuthentication IC kan udviklere implementere en mere effektiv tilgang baseret på JSON Web Tokens til sikker forbindelse mellem IoT-enheder og Google Cloud IoT-tjenester.