HOOFDSTUK 3: Architecturale aspecten van beveiliging

Transcriptie

1 HOOFDSTUK 3: Architecturale aspecten van beveiliging noodzaak steeds grotere en meer publieke netwerken steeds meer de moeite voor kwaadwillige personen steeds meer persoonlijke gegevens aangekoppeld deelaspecten * geheimhouding informatie versleutelen tegen onbevoegden * authentisering afzender laten bewijzen wie hij is, voor data te sturen * niet-loochening bewijzen wie bericht gestuurd heeft * integriteitcontrole bericht onderweg niet gewijzigd 1. Cryptografie basisprincipes versleuteling versleuteling, encryptie, vercijfering van klare tekst in versleutelde tekst via algoritme (meestal publiek) en sleutel encryptie decryptie: (meestal geheim) terminologie cryptografie: vercijferen van berichten cryptoanalyse: kunst van kraken van encryptiemethoden cryptologie: geheel van cryptografie en cryptoanalyse 1

2 basiselementen en -methoden substitutie door S-box mapt x-bit op y-bit zorgt voor niet-lineariteit zorgt voor confusion transpositie door P-box permuteert symbolen zorgt voor diffusion substitutiemethoden kenmerken enkel substitutie -> elke letter/lettergroep veranderen door andere letter/lettergroep -> volgorde niet gewijzigd mono-alfabetische substitutie elke letter(groep) afbeelden op andere letter(groep) sleutel is rij letters in specifieke volgorde -> opmerking: onveilig door frequentie- en woordanalyse vb. Caesar-methode geheim in algoritme <-> maar 26 mogelijkheden => eens algoritme gekend eenvoudig te kraken transpositiemethoden kenmerken enkel transpositie -> symbolen zelf blijven behouden -> volgorde voorkomen verandert vb. kolomtranspositie ditiseenvoorbeeldvanvercijfering 'dvdieerntoafiovjirnenlcgeeeisbvr' praktische methoden vroeger: E en D eenvoudig en lange sleutel K nu: E en D zeer ingewikkeld <-> nog steeds S-boxen en P-boxen als basiselementen 2

3 2. Cryptografie met geheime sleutels Vernam cipher methode stream cipher encryptie en decryptie is XOR met sleutel encryptie en decryptie zijn identiek informatietheoretische onbreekbaarheid dus perfect veilig (<-> wel praktisch door brute force) bewezen door Shannon voorwaarden: 1. (want bitsgewijze XOR) <-> praktisch zeer moeilijk! 2. tekens sleutel volledig willekeurig <-> echte randomgetallen zeer moeilijk 3. elke sleutel maar 1 keer gebruiken, daarna vernietigen 4. maar twee kopijen per sleutel (zender en ontvanger) dus meerdere ontvangers => verschillende kanalen + sleutels gevolg: theoretisch onbreekbaar <-> praktisch onmogelijk Feistel ciphers block ciphers cleartext opdelen in blokken typisch bit versleuteling per blok typische structuur evolutie meer complexe iteratiestappen en minder nodig 3

4 Feistel ciphers < Feistel, IBM, begin 70 vercijfering en ontcijfering met zelfde implementatie (HW en SW) want implementatie moest toen in hardware (software te traag) => anders zeer duur voorbeelden DES, 3DES, AES, IDEA, (alle gebruikte) structuur iteratie voorbeeld encryptie/decryptie (2 iteraties) kenmerken algoritmen identiek volgorde iteratiesleutels identiek en omwisselen in postprocessing (na iteratie ) vrijheidsgraden grootte input blok grootte sleutel en sleutelgeneratie algoritme aantal iteraties functie (typisch eenvoudig te berekenen <-> moeilijk te inverteren) 4

5 Data Encryption Standard (DES) geschiedenis < IBM gepatenteerd overgenomen door overheid reden: wou geen privé organisatie met geheimen onduidelijke omstandigheden zeer veel gebruikt + veel variaties (zie verder) gekraakt door dure hardware (250k USD) en in < 3 dagen door deep cracker + door internetcomputers en in < 1 dag => kan standaard niet blijven gevolgen cipher block chaining en cipher feedback chaining 3DES ontwikkeling AES werking analoog aan Feistel Cipher = bit 56-bit 48-bit transposities om SW-implementaties te vertragen reden: extra complexiteit in SW verwisseling van 32-bit groepen in postprocessing(zie Feistel) 5

6 werking iteratie bepalen sleutel bit sleutel opsplitsen in 2x 28 bit 2. elke 28-bit groep roteren over aantal bits i.f.v. 3. transpositie op globale 56-bit resultaat 4. selectie van 48 bits 5. permutatie van 48 bits functie uitbreiding bevat transpositie + duplicering S-box opsplitsing 48-bit waarde in 8 x 6-bit elk doorgeven aan een S-box output 4-bit per box = 8 x 4-bit = 32 bit permutatie reden: extra complexiteit in SW 6

7 verbeteringen aan DES probleem DES originele tekst opgesplitst in 64-bit blokken alle blokken met zelfde sleutel versleuteld gevolg: mono-alfabetische substitutie met 64-bit tekens = 2^64 symbolen <-> 26 symbolen bij gewoon alfabet maar toch intrinsiek onveilig cipher block chaining elke blok combineren met vorige output via eerste blok combineren met willekeurige en openbare IV gevolgen contextafhankelijkheid: zelfde blok kan anders gecodeerd worden globale codering <-> mono-alfabetische => VEEL veiliger encryptie pas beginnen als vorige 64-bit klaar is toepassing: grote invoer (vb. bestanden) cipher feedback chaining GEEN omgekeerde iteratiesleutels! gevolgen byte per byte vercijfering transmissiefout 1 bit verminkt volledige blok toepassing: onregelmatige invoer (vb. keyboard) 7

8 variaties van DES Double DES (2DES) kenmerken #sleutels 2^56 naar 2^112 dus 2^56 keer veiliger? MAAR: meet-in-the-middle-attack mogelijke => maar 2 keer veiliger! meet-in-the-middle-attack stel aanvaller kent paar vb. header info van standaardberichten Triple DES (3DES) kan dus langs twee kanten vercijferen/ontcijferen 1. zoek sleutels en 2. vercijfer met alle mogelijkheden -> gesorteerde waarden 3. ontcijfer met alle mogelijkheden -> gesorteerde waarden 4. zoek gelijke waarden voor en indien dan misschien gevonden sleutels controleer met tweede paar indien nee, zoek verder opmerking: wel veel geheugen nodig! (orde ) of 2 sleutels <-> 3 sleutels want 112-bit voldoende voor commerciële toepassingen EDE-schema <-> EEE-schema want achterwaarts compatibel met standaard DES stel, dan alternatief: EEE met 168-bit sleutel (nog veiliger) 8

9 Advanced Encryption Standard (AES) geschiedenis nood aan opvolger (DES onveilig, 3DES traag, IDEA gepatenteerd) Request for Proposal in > verschillende sleutellengtes mogelijk (tot 256-bit) -> efficiente HW-implementatie nodig want HW terug belangrijker, door opkomst multimedia 20 algoritmen bekeken kandidaturen laten testen door concurrenten -> afvallers subset Rijndael als beste gekozen in 2001 < Daemen en Rijmen, KUL ZEER korte periode voor standaardisatie wegens sense of urgency toen veel commotie: te snel, daarom dit genomen <-> nu algemeen aanvaard als goede keuze kenmerken 128-bit (4x4 bytes = 4x4x8-bit) 128-bit, 192-bit en 256-bit 10 (AES-128), 12 (AES-192), 14 (AES-256) werking twee parallelle processen vercijferingsproces met 4 bouwblokken SubBytes, ShiftRows, MixColumns, AddRoundKey sleutelgeneratieproces sleuteluitbreiding en sleutelselectie (zie DES) cipher key chaining (cipher block chaining op sleutelniveau) zeer complex gebruik meer en meer maar minder dan verwacht traagheid v/d markt en 3DES volledig ontplooid markt kan geen downtime verdragen (vb. banken) nog niet gekraakt en veiligste tot op vandaag 9

10 basisstappen SubBytes niet-lineaire substitutiecodering (S-box) -> bytes vervangen via vaste look-up tabel -> tabel afgeleid uit speciale veeltermen met niet-lineaire eigenschappen ShiftRows transpositiecodering (P-box) -> op elke rij van matrix elementen cyclisch verschuiven gevolg: elke kolom van outputmatrix afhankelijk van ELKE kolom inputmatrix MixColumns transformatie op kolommen van matrix -> 4 kolombytes lineair transformeren met vaste veelterm AddRoundKey elke byte uit matrix XOR en met overeenkomstige byte uit iteratiesleutel 10

11 algemene werking 11

12 3. Cryptografie met publieke sleutels algemene principes probleem geheime sleutels = sleutelbeheer verdelen van sleutels onder personen <-> informatienetwerk zelf is onveilig gebruik publieke sleutels iedere gebruiker twee sleutels: en publieke vercijfersleutel -> laat anderen toe om berichten te sturen private ontcijfersleutel -> laat eigenaar toe ontvangen berichten te ontcijferen asymmetrische cryptografie 12

13 RSA (Rivest, Shamir, Adleman) algemeen zeer rekenintensief -> niet voor grote hoeveelheden data vaak voor uitwisselen van sessiesleutels PKCS = Public Key Cryptographic Standards definiëren hoe RSA te gebruiken (syntax) vb. in SSL, SSH, opbouw 1. kies twee grote priemgetallen en (> ) 2. bereken en 3. kies copriem met 4. kies zodat gebruik splits klare tekst op in stukken met voorbeeld kies en (priem) -> en kies (copriem met ) -> 13

14 4. Authentisering uitdagings-reactieprotocol (geheime sleutels) systeem 1. Alice stuurt identiteit en uitdaging naar Bob 2. Bob beantwoord uitdaging Alice + stuurt eigen uitdaging 3. Alice beantwoord uitdaging Bob spiegelaanval twee simultane sessies Bob beantwoord zijn eigen uit uitdaging! basisregels voor veilige authentisering initiatiefnemer eerst identiteit bewijzen verschillende sleutels gebruiken of dynamische sleutelcreatie disjuncte verzameling van uitdagingen gebruiken vb. even en oneven getallen 14

15 geheime sleuteluitwisseling met Diffie-Hellman systeem 1. Alice kiest 2 grote priemgetallen en (mogen publiek zijn) 2. Alice en Bob kiezen elk groot geheim getal en (groter dan 512-bit) 3. Alice stuurt naar Bob 4. Bob stuurt naar Alice 5. Bob berekent 6. Alice berekent 7. Gemeenschappelijke geheime sleutel veiligheid geen praktisch algoritme voor discrete logaritmen mod groot priemgetal dus of niet te bepalen uit en man-in-the-middle attack probleem: Bob weet niet of van Alice komt -> geen authentisering bij uitwisselen sleutels voor authentisering systeem sleutel: Eve kent beide en kan dus omzetten! oplossingen PKI gebruiken elektronische handtekening toevoegen beperkte tijdsduur sleutel: 15

16 key distribution center (geheime sleutels) principe instantie vertrouwd door alle gebruikers heeft met elke gebruiker eigen sleutel gemeen (,, ) zorgt voor authentisering en beheer sessiesleutels eenvoudig model probleem: afspeelaanval mogelijk = herhaaldelijk opnieuw afspelen van bericht 2 + dataverkeer mogelijk <-> dan niet meer van Alice want Bob zelf geen controle oplossingen toevoegen timestamp <-> synchronisatieproblemen of onveilig interval unieke ID aan bericht <-> grote administratie (eeuwig bewaren) authentisering in 2 richtingen -> Otway en Rees Otway en Rees authentiseringsprotocol bericht 2 geeft ook ID s mee zegt hoe gecodeerd bericht 3/4 zeker van KDC? ja, want: en zijn uitdagingen t.o.v. KDC <-> t.o.v. Bob/Alice moeten erbij, anders kan eender welke gestuurd worden opmerking: redundantie controle gelijkheid in KDC kan ook met enkel A en/of B 16

17 Kerberos situatie client Alice wil server Bob gebruiken AS: controleert gebruiker bij inloggen (vgl. KDC) -> heeft wachtwoord met iedereen gemeen i.p.v. sleutel TAS: geeft tickets voor identiteitsbewijs af voor gebruik bij servers systeem 1. Alice identificeert zich -> AS berekent zelf sleutel die Alice zal kunnen begrijpen heeft haar wachtwoord of hash ervan ook opgeslagen hash als sleutel gebruiken 2. AS stuurt sessiesleutel en bericht voor TAS door -> Alice typt wachtwoord in, berekent hash en ontcijfert bericht + vernietigd wachtwoord en hash verkeerd wachtwoord => verkeerde => geen ontcijfering 3. Alice stuurt bericht voor TAS door met request voor Bob incl. binnen sessie vercijferde timestamp tegen replay -> TAS kan identiteit Alice vertrouwen en genereert sessiesleutel voor Bobsessie 4. TAS stuurt Bobsessiesleutel en bericht voor Bob door naar Alice -> Alice kent nu Bobsessiesleutel 5. Alice stuurt bericht naar Bob door incl. binnen bobsessie vercijferde timestamp tegen replay en als challenge -> Bob kan identiteit Alice vertrouwen en doet increment timestamp als uitdaging 6. Bob stuurt challenge terug naar Alice -> Alice kan identiteit Bob vertrouwen 17

18 kenmerken authentisering moet niet herhaald worden bij tweede server Charles geen afspeelaanvallen mogelijk bij TAS zelfs binnen interval antwoord nooit begrepen door Eve ( onbekend) geen afspeelaanvallen mogelijk bij Bob wachtwoord Alice nooit buiten client authentisering met publieke-sleutelcryptografie 18

19 5. Elektronische handtekening noodzaak verifiëren identiteit afzender vermijden dat verzender bericht later loochend vermijden dat ontvanger zelf berichten maakt in naam van afzender handtekening met geheime sleutel systeem Centrale autoriteit die door iedereen wordt vertrouwd elke gebruiker heeft sleutel gemeen met CA alle berichten gaan via CA CA levert bewijsstukken indien nodig probleem iedereen moet CA vertrouwen CA kan alles volgen niet gedecentraliseerd handtekening met publieke sleutel architectuur publieke sleutel cryptografie met extra eigenschap OK voor RSA, maar niet triviaal! Certificate Authority levert echtheidscertificaten af = binden publieke sleutel aan een reële entiteit publiceert die certificaten vertrouwen in grondige controle nodig door iedereen <-> niet betrokken in communicatie zelf principe Alice verstuurt Bob berekent Bob berekent naar Bob (normale decryptie) -> identificatie Alice en niet loochening want Bob weet wegens certificaat dat echt van Alice is want is geheim, dus kan enkel van Alice zijn problemen steeds combinatie authentisering en geheimhouding lengte handtekening is even groot als lengte tekst 19

20 Digitale handtekening principe digitale handtekening toevoegen aan document <-> op bepaalde manier encrypteren dat het getekend is hash-functie/message digest -> eenvoudig te berekenen voor gegeven -> niet af te leiden uit -> in praktijk geen twee berichten en te vinden zodat systeem enkel message digest wordt versleuteld met geheel kan dan volledig publiek/privaat versleuteld worden (optioneel) 20