IoT-beveiligingsbeginselen - deel 1: Cryptografie gebruiken

Noot van de redactie: Deze meerdelige serie biedt praktische richtlijnen om ontwikkelaars te helpen ervoor te zorgen dat vanaf het begin de beste praktijken worden gevolgd. Hier bespreekt deel 1 de cryptografische algoritmen die aan veilige ontwerpen ten grondslag liggen. Deel 2 bespreekt de rol van private sleutels, sleutelbeheer en veilige opslag in veilige systemen. In deel 3 wordt ingegaan op de mechanismen die in veilige processoren zijn ingebouwd om bedreigingen tegen te gaan die erop gericht zijn de uitvoering van systeem- en toepassingssoftware op ivd-apparaten te ondermijnen. Deel 4 identificeert en toont hoe beveiligingsmechanismen in geavanceerde processoren kunnen worden toegepast om de isolatie te helpen waarborgen die nodig is om aanvallen op de runtime-omgeving van ivd-apparaten te beperken. In deel 5 wordt beschreven hoe de beveiliging van het ivd zich uitstrekt van ivd-apparaten tot beveiligingsmaatregelen op hoger niveau die worden gebruikt om die apparaten te verbinden met ivd-cloudbronnen

De snel groeiende afhankelijkheid van ivd-toepassingen in industriële, medische, transport- en andere kritieke toepassingen heeft het veiligheidslandschap drastisch veranderd. In tegenstelling tot eerdere bedrijfsapplicaties met direct beschikbare middelen voor het verwerken van beveiligingsalgoritmen, zijn IoT-toepassingen op bedrijfsniveau kwetsbaar voor een groeiend aantal bedreigingen die zich richten op steeds groter wordende netwerken van IoT-apparaten met beperkte middelen. In hun haast om in te spelen op de snel opkomende mogelijkheden van het ivd, zetten organisaties maar al te vaak ivd-apparaten in die functioneel niet in staat zijn om elementaire beveiligingsmaatregelen te ondersteunen voor de bescherming van opgeslagen gegevens en de bescherming van de uitwisseling van gegevens en commando's over kwetsbare netwerken.

Hoe ver ontwikkelaars moeten gaan om een ontwerp veilig te stellen, hangt natuurlijk af van meerdere factoren. Elke toepassing wordt geconfronteerd met een eigen reeks bedreigingen en vereist een passende beoordeling van de risico's van die bedreigingen. Omdat verbonden apparaten aan een ongewoon aantal bedreigingen worden blootgesteld, zal elk ivd-apparaat op zijn minst een aantal minimale veiligheidsmaatregelen vereisen.

Voor sommigen lijkt het implementeren van robuuste beveiligingsmaatregelen voor een eenvoudig IoT-apparaat misschien een geval van overengineering, maar zelfs eenvoudige temperatuursensoren die onvoldoende bescherming bieden, kunnen hackers een toegangspunt bieden tot bedrijfsnetwerken ^[1]. De beveiliging van het ivd wordt namelijk voortdurend geconfronteerd met uitdagingen als gevolg van de combinatie van alomtegenwoordige connectiviteit die wordt geboden door ivd-toepassingen en de apparaten met beperkte middelen die aan deze toepassingen ten grondslag liggen. Zelfs in ontwerpen van ivd-apparaten met voldoende middelen om cryptografie-algoritmen in software uit te voeren, kunnen toepassingen kwetsbaar blijven door subtiele fouten in de uitvoering van die algoritmen.

Dit artikel beschrijft de basisklassen van cryptografische algoritmen en gaat in op hun rol in de beveiliging. Vervolgens wordt getoond hoe ontwikkelaars kunnen profiteren van processoren en gespecialiseerde apparatuur van Maxim Integrated, Microchip Technology en Texas Instruments, diezijn ontworpen om deze algoritmen te versnellen, verschillende aspecten van beveiliging te verbeteren en tegelijkertijd de implementatie ervan te vereenvoudigen.

De verschillende soorten cryptografische algoritmen en hun rol

Cryptografische algoritmen vallen uiteen in drie grote categorieën die betrekking hebben op de fundamentele veiligheidsprincipes van vertrouwelijkheid, authenticatie (de bron van het bericht verifiëren), onweerlegbaarheid (bewijzen dat de afzender een gecodeerd of ondertekend bericht heeft opgesteld), en integriteit:

• Symmetrische-sleutelalgoritmen, waarbij het algoritme of het cijfer dezelfde geheime sleutel gebruikt om een voor mensen leesbaar bericht (klare tekst) te versleutelen tot een beschermde versie (versleutelde tekst), en later om de versleutelde tekst weer te ontsleutelen tot klare tekst. Symmetrische sleutelcijfers worden gewoonlijk gebruikt om de vertrouwelijkheid te waarborgen. Bekende symmetrische cryptografie-algoritmen zijn onder meer:
  • Triple DES (Data Encryption Standard), ook bekend als 3DES, of officieel door het U.S. National Institute of Standards and Technology (NIST) het Triple Data Encryption Algorithm (TDEA) genoemd.
  • Advanced Encryption Standard (AES)^[2] algoritmen, zoals AES-256, die 256-bits sleutels gebruikt.
• Asymmetrische-sleutelalgoritmen, waarbij het cijfer een gepaarde reeks particuliere en openbare sleutels gebruikt om een bericht te versleutelen en te ontsleutelen, meestal als onderdeel van uitgebreidere beveiligingsprotocollen voor sleutelovereenkomsten en digitale handtekeningen. Asymmetrische cijfers worden meestal gebruikt om vertrouwelijkheid, authenticatie of onweerlegbaarheid te garanderen. Cryptografie-algoritmen met openbare sleutel omvatten:
  • Algoritmen die gebruik maken van eindige veld cryptografie (FFC), waaronder:
    • Digitaal handtekeningalgoritme (DSA) van de Federal Information Processing Standard (FIPS)
    • Internet Engineering Task Force (IETF) Diffie-Hellman (DH)^[3] sleuteluitwisseling
  • Algoritmen die gebruik maken van integer factorization cryptography (IFC), inclusief:
    • RSA (Rivest-Shamir-Adleman)^[4] algoritme
  • Algoritmen die gebruik maken van elliptische-curve cryptografie (ECC), waaronder:
    • Elliptische Curve Diffie-Hellman (ECDH)^[5] sleuteluitwisseling
    • Elliptic Curve Digital Signature Algorithm (ECDSA)^[6]
• Hash-algoritmen, waarbij het algoritme een oorspronkelijk bericht herleidt tot een veel kleinere, unieke waarde van vaste lengte, ook wel hash, digest of handtekening genoemd. Deze eenrichtingsconversiefuncties spelen een cruciale rol bij de verificatie dat het bericht niet is gewijzigd (integriteit) en worden toegepast in talrijke protocollen waarbij onder meer gebruik wordt gemaakt van een berichtauthenticatiecode (MAC), een gecodeerde-hash berichtauthenticatiecode (HMAC), of sleutelafleidingsfuncties (KDF). Cryptografische hash-algoritmen omvatten:
  • MD5 (message digest 5)
  • Secure Hash Algorithms (SHA)^[7] zoals SHA-256, dat een 256-bit hashwaarde voor een bericht genereert.

Zoals elk doeltreffend crypto-algoritme, zijn de bovengenoemde algoritmen ontworpen met een veelvoud aan kritieke vereisten die ver buiten het bestek van dit korte artikel liggen. Vanuit een breed perspectief moeten op sleutels gebaseerde algoritmen echter cijfertekst genereren die vrijwel onmogelijk (of althans economisch onhaalbaar) te ontcijferen is zonder de sleutel. Hash-algoritmen moeten snel hashes genereren, waarbij ze dezelfde hash produceren voor hetzelfde ingevoerde bericht, maar een duidelijk verschillende hash genereren voor zelfs maar een kleine verandering in het ingevoerde bericht, terwijl ze nooit dezelfde hash-waarde produceren voor twee verschillende berichten, en nooit het oorspronkelijke bericht produceren gegeven een bepaalde hash-waarde.

Hoewel de details van deze en andere crypto-algoritmen sterk uiteenlopen, berusten zij alle op een reeks manipulaties op laag niveau, transformaties en andere wiskundige bewerkingen die zijn ontworpen om aan deze algemene doelstellingen te voldoen. Het AES-cijfer bijvoorbeeld converteert klare tekst in cijfertekst door middel van een reeks "rondes" die unieke "rondesleutels" bevatten die zijn afgeleid van de oorspronkelijke geheime sleutel van de gebruiker (lijst 1).

Kopieer
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)]) 
begin 
   byte  state[4,Nb]
 
  state = in
 
   AddRoundKey(state, w[0, Nb-1])
 
    for round = 1 step 1 to Nr–1
        SubBytes(state)
        ShiftRows(state)
        MixColumns(state)
        AddRoundKey(state, w[round*Nb, (round+1)*Nb-1]) 
    end for 
 
    SubBytes(state)
    ShiftRows(state)
    AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1]) 
 
    out = state
end

Listing 1: Deze pseudocode beschrijft de opeenvolgingen van bewerkingen die betrokken zijn bij de vercijfering van berichten, waarbij klare tekst (in) wordt omgezet in vercijferde tekst (out) met gebruikmaking van een reeks waarden (w) die zijn afgeleid van de particuliere sleutel van de verzender. (Code bron: NIST)

Binnen een ronde vervangt de SubBytes()-transformatie elke byte met behulp van een substitutietabel (S-box), die zelf het resultaat is van een reeks transformaties (figuur 1).

Figuur 1: In het AES-cijfer vervangt de SubBytes()-stap elke byte met behulp van een substitutietabel (S-Box). (Afbeelding bron: NIST)

In de volgende stap in de reeks verschuift de transformatie ShiftRows() bytes in de laatste drie rijen, elk met een verschillend aantal bytes (Figuur 2).

Figuur 2: De ShiftRows()-stap in de uitvoeringssequentie van het AES-cijfer verschuift rijen met toenemende offsets. (Afbeelding bron: NIST)

In de laatste stappen van de reeks past MixColumns() een transformatie toe op elke kolom die elke byte in de kolom vervangt door de resultaten van een polynoom, terwijl AddRoundKey() het resultaat transformeert door een bitwise XOR-bewerking uit te voeren op elke kolom met een voor dat doel gecreëerde ronde sleutel.

Het totale aantal rondes varieert met de sleutelgrootte. AES-128, dat gebruik maakt van een 128-bit sleutel, vereist 10 rondes, terwijl AES-192 (sleutelgrootte 192 bits) en AES-256 (256 bits) respectievelijk 12 en 14 rondes vereisen. Ontcijfering volgt hetzelfde patroon, waarbij de processtappen en hun afzonderlijke transformaties worden omgekeerd.

Recentere cijfers zoals ECDH, gebruikt voor sleuteluitwisseling, en ECDSA, gebruikt voor digitale handtekeningen, berusten op complexere wiskunde zoals de elliptische algebraïsche krommestructuren die in grote lijnen door de formule worden gedefinieerd:

Vergelijking 1

Met een zorgvuldige keuze van de krommeparameters a en b en het gebruik van bijkomende beperkingen, vertonen de krommen nuttige cryptografische eigenschappen (ook dit valt buiten het bestek van dit artikel). Hoewel het concept eenvoudig is, is de specifieke reeks parameters van cruciaal belang: Een slechte selectie van curveparameters kan resulteren in curves die kwetsbaar blijven voor geavanceerde aanvallen. Om deze mogelijkheid uit te sluiten biedt het NIST een standaardreeks van cryptografisch robuuste krommen, waaronder P-192, P-224, P-256, en andere met toenemende sterkte. De namen van de krommen komen overeen met de bitlengte van het priemgetal p van de elementen in het onderliggende priemveld van de kromme.

Een ontwikkelaar kan deze eigenschappen met ECDSA gebruiken om een bericht te ondertekenen met een overeengekomen kromme en de ontvanger de openbare sleutel en de handtekening te verstrekken - een getallenpaar met de aanduidingen r en s. Het eigenlijke ondertekeningsproces omvat de volgende stappen:

• Uitgaande van een punt op de kromme, het basispunt G(x,y) genoemd, creëert het algoritme een openbare sleutel Q(x,y) door het basispunt te vermenigvuldigen met de privé-sleutel(d) van de ontwikkelaar modulo p:

Vergelijking 2

• Een ander coördinaatpunt (x1,y1) wordt gecreëerd met een willekeurig getal k in het bereik [1 ... n-1]:

Vergelijking 3

• H(m), de SHA hash van bericht m, wordt gegenereerd
• Met behulp van de modulo inverse van het willekeurige getal k, k-1, worden de uiteindelijke r- en s-componenten van de digitale handtekening als volgt gegenereerd:

Vergelijking 4

Vergelijking 5

Het eindresultaat is een uitwisseling waarbij het bericht wordt geauthenticeerd, de integriteit ervan wordt bevestigd en onweerlegbaarheid wordt gegarandeerd.

Hoe cryptografie-algoritmen te implementeren

De les die uit deze weliswaar oppervlakkige blik op deze algoritmen kan worden getrokken, is dat cryptografische algoritmen berusten op een opeenvolging van wiskundige bewerkingen die zo zijn ontworpen dat pogingen om de resultaten te compromitteren zo rekenintensief zijn dat het onmogelijk - of onpraktisch - is om ze snel genoeg te voltooien om nuttig te zijn voor de dader. Bovendien wijst zelfs een vluchtige inspectie van elk algoritme erop dat een ivd-apparaat met beperkte middelen waarschijnlijk weinig kans zal maken om een software-implementatie van het algoritme uit te voeren zonder mogelijk de primaire functionele vereisten van het apparaat in gevaar te brengen. Tenslotte betekenen de precieze details van het algoritme, die verder gaan dan de hier getoonde stappen, dat zelfs een subtiele codeerfout of een kleine verkeerde interpretatie van de norm kan leiden tot beveiligingslekken, of zelfs tot het volledig mislukken van het cryptografisch proces.

Fouten in algoritme-implementaties kunnen zelfs voorkomen in de grootste ontwikkelingsorganisaties, en in toepassingen die kritisch afhankelijk zijn van die algoritmen. Zo is een bekende kwetsbaarheid in een spelconsole ontstaan doordat in de door het bedrijf gebouwde implementatie van ECDSA een constante waarde van k werd gebruikt, in plaats van een willekeurige waarde voor het soort berekening dat in vergelijking 3 wordt weergegeven. Daardoor zouden hackers de geheime sleutel d kunnen afleiden. Het gebruik van een foute toevalsgenerator voor het creëren van k leidde tot een soortgelijk misbruik dat resulteerde in een groot Bitcoin-verlies.

Dankzij op hardware gebaseerde cryptografische mogelijkheden die in processoren en speciale beveiligingsIC's zijn ingebouwd, kunnen ontwikkelaars de complexe details van de uitvoering van cryptografische algoritmen grotendeels negeren en zich in plaats daarvan richten op de voordelen van het gebruik van deze mogelijkheden om hun toepassingen te beveiligen. Deze apparaten voegen een extra beveiligingslaag toe door de gegevensstromen en -operaties in het apparaat te integreren, waardoor een veel voorkomende aanvalsvorm waarbij externe bussen worden gecontroleerd op tekenen van bevoorrechte informatie, wordt uitgeschakeld. Een op hardware gebaseerde oplossing biedt niet alleen een betrouwbare implementatie van een bepaald algoritme, maar stelt ontwikkelaars ook in staat veiligheid in hun ontwerpen in te bouwen zonder fundamentele eisen zoals responsvertraging en algemene prestaties in het gedrang te brengen.

Crypto-versnellers die in deze apparaten zijn ingebouwd, ontlasten de hoofdprocessor van de uitvoering van cryptografie, zodat deze de primaire functie van het ontwerp kan uitvoeren. Hardwarematige crypto-ondersteuning wordt steeds vaker toegepast in processoren. Tegelijkertijd vereist niet elke toepassing de volledige kracht van de veiligheidsmaatregelen die door de hierboven beschreven algoritmen worden ondersteund. Ontwikkelaars kunnen inderdaad een breed scala van versnelde crypto-algoritmen en combinaties van algoritmen vinden in processoren zoals de volgende:

• Maxim Integrated's MAX32631 32-bit microcontroller, die AES- en DSA-codes ondersteunt
• Maxim Integrated's MAX32520 32-bit MCU, die AES-, SHA- en ECDSA-algoritmen ondersteunt
• De PIC 24F XLP 16-bit microcontroller-familieleden van Microchip Technology, waarbij apparaten zoals de PIC24FJ256GA406 AES- en 3DES-ciphers ondersteunen
• De 32-bit PIC 32MZ MCU- en de 32-bit SAM9X60 MPU-familieleden van Microchip Technology, waarbij apparaten zoals de PIC32MZ2048EFM144 en de SAM9X60T AES- en 3DES-ciphers, alsmede SHA- en HMAC-hashfuncties ondersteunen
• De SimpleLink MCU-familie van Texas Instruments, zoals de CC1312R en CC2652R draadloze MCU's, die cijfers als AES, ECDH en ECDSA, alsmede SHA hash-functies ondersteunen

Andere beveiligingsapparatuur, zoals de Maxim Integrated DS28E38 en de Microchip Technology ATECC608A integreren crypto-versnellers en aanverwante functionaliteit die nodig is om authenticatieprotocollen te versnellen. Onder hun brede cryptomogelijkheden ondersteunen deze apparaten de eerder beschreven ECDSA-bewerking. In een IoT-apparaat of slimme randapparatuur kan een hostprocessor authenticatie-IC's zoals deze gebruiken om snel ECDSA P-256 digitale handtekeningen te maken om naar een ander apparaat te sturen of de ECDSA P-256 handtekeningen van andere apparaten te authenticeren.

Voor beveiliging geschikte processoren en gespecialiseerde apparaten worden doorgaans gebouwd met een breed, op hardware gebaseerd beveiligingsraamwerk dat extra beveiligingsfunctionaliteit biedt, zoals kwalitatief hoogwaardige willekeurige getallengeneratoren. Veel apparaten die dit niveau van mogelijkheden bieden, maken gebruik van willekeurige ruisbronnen die inherent zijn aan halfgeleiderontwerpen om de entropie te maximaliseren die nodig is in echte willekeurige getallengeneratoren (TRNG's). Zoals in het eerder genoemde Bitcoin-voorbeeld wordt gesuggereerd, zijn dit soort TRNG's een essentiële factor voor de goede werking van cryptografische algoritmen.

Geïntegreerde ondersteuning voor de veilige opslag van privé-sleutels en andere geheime gegevens is een van de belangrijkste mogelijkheden van veilige ontwerpen. Andere architecturale kenmerken die met deze en soortgelijke processoren beschikbaar zijn, bieden een nog dieper niveau van beveiligingsondersteuning.

Ondanks al hun mogelijkheden helpen processoren met geïntegreerde crypto-versnellers en aanverwante functies de ontwikkeling van veilige ontwerpen te vereenvoudigen door gebruik te maken van eenvoudige API-bibliotheken (Application Programming Interface). Dankzij intuïtieve API-functieaanroepen kunnen ontwikkelaars veiligheidsimplementaties abstraheren en vertrouwen op de API om toegang te krijgen tot de onderliggende hardwarefunctionaliteit. Ontwikkelaars kunnen bijvoorbeeld de Maxim Integrated MAX32520-KIT evaluatiekit voor de MAX32520 MCU gebruiken in combinatie met de Maxim Integrated Micros software development kit (SDK) om snel veilige IoT-apparaten te bouwen. Samen met de bijbehorende stuurprogramma's en middleware bevat de SDK van Maxim Integrated Micros voorbeeldfuncties die de basisontwerppatronen demonstreren die nodig zijn om berichten te coderen (AES128_ECB_enc()) en te decoderen (AES128_ECB_dec ())) met het AES-cijfer (Listing 2).

Kopieer
int AES128_ECB_enc(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "00000000000000000000000000000000";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_EncryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Encrypt(&cipher_req);
    }
    const char *_expected = "322FD6E503395CDB89A77AC53D2B954F";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
 
}
 
int AES128_ECB_dec(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "322FD6E503395CDB89A77AC53D2B954F";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_DecryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Decrypt(&cipher_req);
    }
    const char *_expected = "00000000000000000000000000000000";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
}

Listing 2: Ontwikkelaars kunnen voorbeeldcode in het distributiepakket van Maxim Integrated Micros SDK bekijken om basisontwerppatronen te leren die nodig zijn om AES-encryptie (AES128_ECB_enc()) en -decryptie (AES128_ECB_dec ()) uit te voeren met behulp van de geïntegreerde cryptografiefuncties van de MAX32520 MCU. (Bron code: Maxim Integrated)

Authenticatieprotocollen

Robuuste implementaties van cryptografische algoritmen zijn bijzonder belangrijk om een veilige basis te leggen voor protocollen op hoger niveau die in toepassingen worden gebruikt. Protocollen van een hoger niveau, zoals Transport Layer Security (TLS), voeren hun operaties gewoonlijk uit met behulp van een gedefinieerde reeks cryptografische algoritmen, een zogeheten cipher suite. In TLS helpen algoritmen uit een overeengekomen codeersuite de authenticatie en vertrouwelijkheid te waarborgen in communicatiesessies tussen een client van een ivd-apparaat en een hostserver. TLS 1.2[8] doorloopt een specifieke opeenvolging van transacties om over parameters te onderhandelen, authenticatie uit te voeren en sessiesleutels uit te wisselen alvorens tot gegevensuitwisseling over te gaan (figuur 3).

Figuur 3: Het TLS 1.2 protocol voor het tot stand brengen van een sessie maakt gebruik van een aantal algoritmen uit een overeengekomen codeersuite voor authenticatie, sleuteluitwisseling en voortdurende gegevensuitwisseling. (Bron afbeelding: Texas Instruments)

Authenticatie wordt gewaarborgd door de identiteit van de server (en facultatief de client) vast te stellen door verificatie van beveiligingscertificaten, die de respectieve openbare sleutel voor elke deelnemer bevatten. Hier zendt elke deelnemer een bericht dat met zijn privé-sleutel is versleuteld. Omdat de ontvangen openbare sleutel alleen een bericht kan ontcijferen dat met de bijbehorende particuliere sleutel is versleuteld, kan elke deelnemer bevestigen dat de verstrekker van een certificaat daadwerkelijk eigenaar is van dat certificaat.

In de volgende TLS-fase voeren de deelnemers een reeks transacties uit om een gedeelde sessiesleutel te creëren. Deze gedeelde sessiesleutel wordt vervolgens gebruikt om het eigenlijke berichtenverkeer te versleutelen, waardoor de vertrouwelijkheid van de berichtenuitwisselingen voor die sessie wordt gewaarborgd.

Meerdere protocolopties stellen ontwikkelaars in staat dit generieke TLS-sessiecreatieproces te verfijnen, soms ten koste van de algemene veiligheid. Bovendien kunnen ontwikkelaars tijdens het proces van parameteruitwisseling een andere cipher suite gebruiken door een geschikte combinatie te kiezen van TLS 1.2-ondersteunde algoritmen voor elke fase van het protocol, waaronder:

• Sleutelinstelling: RSA, DH, ECDH
• Authenticatie: RSA, DSA, ECDSA
• Ciphers: 3DES, AES
• Bericht authenticatie: SHA

De laatste versie van TLS, TLS 1.3[9], voegt extra veiligheid toe door eerst sleuteluitwisseling uit te voeren om het proces van het tot stand brengen van een sessie beter te beschermen. Meer fundamenteel is TLS 1.3 grotendeels afgestapt van de TLS 1.2-sleutelreeks ten gunste van robuustere algoritmen, waaronder het gebruik van de op HMAC gebaseerde "extract-and-expand Key Derivation Function" (HKDF), en geauthenticeerde encryptie met geassocieerde gegevens (AEAD)-algoritmen. AEAD-algoritmen voorzien in de brede behoefte om de authenticiteit, integriteit en vertrouwelijkheid van berichten te waarborgen. Deze algoritmen doen dit door het versleutelde bericht te combineren met een MAC die in serie (figuur 4, links), parallel (figuur 4, rechts), of in een combinatie van beide kan worden gegenereerd.

Figuur 4: AEAD voorziet in authenticatie en vertrouwelijkheid door een MAC bij de cijfertekst te voegen, onder meer met gebruikmaking van de methoden encrypt-then-MAC (links) en encrypt-and-MAC (rechts), waarbij het MAC respectievelijk in serie of parallel wordt berekend. (Bron afbeelding: Wikipedia)

Verhoging van de veiligheidssterkte

Deze evolutie van cryptografische algoritmen en bijbehorende protocollen volgt de voortdurende wedloop tussen cryptografiedeskundigen die vastbesloten zijn de veiligheid te versterken en degenen die even vastbesloten zijn de veiligheid te verslaan. Zo hebben deskundigen in een poging om de veiligheid te verhogen ECDSA gecreëerd als een ECC-variant van DSA, zelf een variant van vroegere cijfers. Het resultaat is dat ECDSA dezelfde beveiligingssterkte kan bereiken als DSA, maar met een veel kleinere sleutelgrootte.

In de cryptografie wordt de beveiligingssterkte van een algoritme gedefinieerd in termen van x bits en de verwachting dat een aanval ongeveer ^2x zou vereisen om de private sleutel die aan het algoritme ten grondslag ligt, af te leiden. In deze termen gedefinieerd, kunnen de verschillende klassen algoritmen aanzienlijk verschillende sleutellengtes vereisen om een vergelijkbaar veiligheidsniveau te bereiken (tabel 1).

Tabel 1: Verschillende klassen cryptografie-algoritmen kunnen aanzienlijk verschillende sleutelgrootten vereisen voor de openbare sleutels (L) of de particuliere sleutels (N, k, f) om vergelijkbare niveaus van beveiligingssterkte te bereiken. (Afbeelding bron: NIST)

In deze tabel van NIST komen de parameters L en N van het FFC-algoritme overeen met de grootte van respectievelijk de openbare sleutel en de particuliere sleutel. Voor IFC- en ECC-algoritmen komen respectievelijk k en f overeen met de sleutelgrootte. NIST merkt op dat algoritmen met een beveiligingssterkte van £ 80 (oranje achtergrond in de tabel) niet langer zijn goedgekeurd voor de bescherming van overheidsinformatie, terwijl andere (gele achtergrond) nog niet in de NIST-normen zijn opgenomen wegens efficiëntieoverwegingen.

Deze verschuiving naar een hogere beveiligingssterkte blijft de evolutie in cijfers en aanbevolen cijfersuites aandrijven. Zo heeft de Commercial National Security Algorithm (CNSA) Suite van het U.S. National Security Agency (NSA) de vroegere NSA Suite B vervangen door aanbevelingen voor het gebruik van robuustere parameters die nodig zijn om als top secret gerubriceerde informatie te beschermen (tabel 2).

Tabel 2: De door de NSA aanbevolen CNSA Suite bevat cryptografie-algoritmen met aanbevelingen voor minimumniveaus van beveiligingssterkte die vereist zijn om zeer gevoelige informatie te beschermen. (Afbeelding bron: DigiKey, van NSA gegevens)

In de toekomst zal de beschikbaarheid van kwantumcomputers een dramatische discontinuïteit teweegbrengen in de beveiliging in het algemeen, en de cryptografie-algoritmen in het bijzonder.

Conclusie

IoT-apparaten en andere aangesloten ontwerpen worden geconfronteerd met een groeiend aantal bedreigingen die steeds robuustere beveiligingsmethoden vereisen die gebaseerd zijn op een breed scala van cryptografische algoritmen. Deze algoritmen, die zo zijn ontworpen dat het kraken van de beveiliging een onpraktisch voorstel wordt, berusten op een reeks transformaties en wiskundige bewerkingen om klare tekst te versleutelen tot versleutelde tekst en versleutelde tekst weer te ontcijferen tot klare tekst. Zoals aangetoond is het mogelijk om hardware-gebaseerde implementaties van deze algoritmen te gebruiken, zodat ontwikkelaars gemakkelijker een sterke beveiliging in een ontwerp kunnen inbouwen zonder de primaire vereisten voor functionaliteit en prestaties in het gedrang te brengen.

Referenties (meest Engelstalig):

1. Hoe een aquarium hielp een casino te hacken
2. FIPS PUB 197: de officiële AES-norm
3. IETF RFC 3526 (DH)
4. NIST SP 800-56B Rev. 1 (DOI) (RSA)
5. NIST SP 800-56A (ECDH)
6. FIPS Pub 186-4 (digitale handtekening)
7. FIPS PUB 180-4: Veilige Hash Standaard (SHS)
8. IETF RFC 5246 (TLS 1.2)
9. IETF RFC 8446 (TLS 1.3)