Meedenken gevraagd bij AES (crypto) vraagstuk

[Eagle Creek]

Beste Tweakers,

Hieronder een voorbeeldvraag van een schoolopdracht, waar ik jullie hulp bij vraag.

Een IoT-device van de afdeling Ruimtelijk Beheer verstuurt elke minuut vertrouwelijke meetwaarden in een frame met een omvang van 1600 bytes. De toepassing vereist dat dit frame met minimale vertraging verstuurd wordt.
Voor de vertrouwelijkheidsbescherming wordt de data in blokken van 128 bit ge-XOR-ed met een vaste shared secret key van 128 bit. De ontwikkelaars kozen hiervoor in plaats van AES omdat bleek dat de eenvoudige hardware van het IoT-device 100ms moet rekenen per AES-encryptie van één blok van 128 bit. Dit zou te veel vertraging opleveren in de toepassing.

3a. Leg uit waarom de gebruikte encryptie niet veilig is. Gebruik in je uitleg de woorden diffusion en confusion.

3b. Leg uit op welke wijze AES in deze situatie waarschijnlijk toch toe te passen is.

De redenatie die ik tot zover kan maken.

3a.
Confusion = Relatie tussen key en ciphertekst. Bij het aanpassen van 1 bit van de key, verandert elke bit van de ciphertekst met een kans van ten minste 50%.
Diffusion = Relatie tussen plaintext en ciphertekst. Bij het aanpassen van 1 bit van de plaintext, verandert elke bit van de ciphertekst met een kans van minstens 50%.

Door uitsluitend gebruik te maken van XOR voldoet de bescherming niet aan het principe van diffusion. Dit omdat het aanpassen van 1 bit aan de plaintext, ook alleen die bit zal laten veranderen aan de cipertext. De overige bits worden immers niet aangeraakt. Dit maakt het mogelijk om een aanval uit te voeren door waarden van de ciphertext aan te passen en te achterhalen welke bits in de plaintext worden geraakt.

Door uitsluitend gebruik te maken van een vaste shared key die slechts voor elk datablok ge-XOR-ed wordt, voldoet de bescherming niet aan het principe van confusion. Door een bit in de key te veranderen, verandert alleen dat bit van de plaintext waarmee wordt ge-XOR-ed en niet de overige bits. Wanneer eenmalig gebruik gemaakt zou worden van een secret key van 128 bit om één datablok van 128 te vercijferen, zou dit wel veilig zijn omdat in dit geval de key net zolang is als de plaintext en slechts eenmalig wordt gebruikt. Door dezelfde key vaker te gebruiken met een XOR wordt een aanval vereenvoudigd.


3b.
Help.. ik weet niet waar ik moet beginnen.

AES werkt óok met blokken van 128 bit. En ondersteunt desgewenst een sleutellengte van 128 bit.

AES maakt gebruik van een combinatie van sleuteloptelling (andere sleutel per vercijfferingsronde), substitutie en shift en mix waardoor de principes wel worden geborgd. Doordat AES bij elke ronde een andere sleutel genereert, is er een ingwikkelde relatie tussen key en cipher en wordt volstaan aan het principe van confusion.

Er is sprake van een vaste en bekende substitutietabel en door het gebruik van deze tabel door meerdere rondes, wordt voldaan aan het principe van diffusion waarbij de relatie tussen clear tekst en ciphertekst nauwelijks nog te achterhalen zijn.

Er bestaan verschilende modi, waaronder ECB, CBC en CTR (bv GCM). ECB zien we als niet veilig, CBC wel maar is lastig te paralelliseren en CTR heeft een snelheidsvoordeel omdat de counter vooraf bekend is.

Dat laatste is ook het enige waarom ik zou kunnen bedenken waarom AES wél in aanmerking zou komen maar of dat sneller is dan de XOR betwijfel ik.. Of heb ik hier dan ook wél het antwoord te pakken? De theorie zegt namelijk dat CTR alleen nog een XOR doet met voorberekende codes. Daarmee zou het dus inderdaad even snel zijn als het in het voorbeeld genoemde alternatief > het is voor vercijfering uitsluitend een XOR en en de voorberekening kan plaats vinden op een rustiger moment voor de processor.

[ Voor 4% gewijzigd door Eagle Creek op 08-04-2021 18:45 ]

[F_J_K]

Zonder enige theoretische kennis (althans in deze eeuw): Bij 3a kan je ook al aanvallen zonder wijzigingen. Als er bekende termen (zoals start, stop van het bericht) zijn ben je er al. En ook als niet kan je waarschijnlijk aan de frequentie van vaker voorkomende waarden wat.

Klassiek voorbeeld, de aanhef of groet van berichten in vorige eeuwen. Zodra je die weet kan je de shared key terugrekenen.

Ik denk dat je er met 3b zo bent ja. Door vooraf door te rekenen zit je de facto bijna met een “one time pad”.

offtopic:
of zet er een separaat device tussen voor de versleuteling, VPN bijvoorbeeld,

Overigens, nav. TR’s, huiswerk an sich is niet verboden, alleen ligt de lat wat hoger qua wanneer het -mee-denken is. Lijkt me hier ok..

[Eagle Creek]

Bedankt voor 't meedenken!

[Groentjuh]

Bij AES gebruik je ook blokken van 128 bit en kun je een sleutel van 128 bit gebruiken. Je hebt bij AES ook nog een IV, die willekeurigheid toevoegt aan het te versleutelen bericht.

[D-dark]

Niet echt mijn fort maar ik waag een poging

1600-byte (te verzenden data)
200-bits (te verzenden data) -> (1600 /
1,5625 te verzenden berichten -> (200 / 128)
2- te verzenden berichten, naar boven afgerond
100 ms rekentijd per bericht
200 ms totaal (2 * 100)

Dat levert nog genoeg tijd op om een nieuwe sleutel te genereren en die met een nieuw bericht geëncrypted met de oude sleutel te delen met de ontvangende partij voordat de volgende verzending moet plaatsvinden.

Andere optie is om in plaats van een vaste sleutel een stuk of 1000 verschillende encryptie sleutels te gebruiken die bij beide partijen bekend zijn en die op volgorde aftewerken en aan het einde opnieuw te beginnen,

[OnTracK]

Het lijkt me dat ze bij 3b op zoek zijn naar het antwoord: genereer per bericht random 128bits in plaats van een pre-shared key, XOR daar de data mee, encrypt die 128bit random data met AES en stuur die mee.