Beveiliging van e-mail Cursus informatiebeveiliging Eric Laermans – Tom Dhaene.

Presentatie over: "Beveiliging van e-mail Cursus informatiebeveiliging Eric Laermans – Tom Dhaene."— Transcript van de presentatie:

1 Beveiliging van e-mail
Cursus informatiebeveiliging Eric Laermans – Tom Dhaene

2 Beveiliging op applicatielaag
mogelijke indringer router router laptop modem server router router Appl Appl Programma Transp Transp Netw Netw Netw Netw Netw Netw Data Data Data Data Data Data Data Fys Fys Fys Fys Fys Fys Fys draadloos Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

3 Beveiliging op applicatielaag
Beveiliging op applicatieniveau voordelen bericht beveiligd over volledig informatiekanaal alleen beveiliging nodig tegen indringers op eindpunten client en server mogelijkheid voor beveiligde opslag nadelen vraagt het meest interactie van de gebruiker Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

4 PGP (Pretty Good Privacy)
gebaseerd op werk van Phil Zimmermann beperkt aantal basisinstructies te gebruiken op niveau van “command prompt” of via GUI onafhankelijk van onderliggend besturingssysteem Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

5 PGP (Pretty Good Privacy)
bestaat in verscheidene versies GnuPG (onder GPL) of commerciële producten te integreren in gestandardiseerd in OpenPGP IETF Proposed Standard (RFC 2440) zie ook boek H p. 592 vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

6 PGP PGP gebruikt gekende beveiligingsmechanismen
vertrouwde algoritmen: o.a. 3-DES, AES, voor symmetrische encryptie o.a. RSA, DSA, ElGamal (Diffie-Hellman) voor asymmetrische encryptie en digitale handtekening MD5, SHA-1, SHA-2,… als hashfunctie beschikbare algoritmen afhankelijk van gebruikte implementatie met alle compatibiliteitsproblemen die hieruit kunnen voortvloeien laat toe hiermee vertrouwelijkheid en authenticatie te realiseren Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

7 PGP: functies PGP creëren van een sleutelpaar
gebruik voor authenticatie/vertrouwelijkheid beheer van publieke sleutels Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

8 Creëren van een sleutelpaar
PGP: sleutelpaar Creëren van een sleutelpaar vertrouwelijke en publieke sleutel 1 sleutelpaar voor digitale handtekening hoofdsleutel (“master key”) 1 sleutelpaar voor encryptie nevensleutel (“subkey”) mogelijk extra nevensleutels toe te voegen hierbij meegegeven identiteit (naam en adres) geldigheidsduur van sleutelpaar wachtzin (“passphrase”) ter bescherming van vertrouwelijke sleutel (wordt versleuteld opgeslagen) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

9 Gebruik voor authenticatie
PGP: authenticatie Gebruik voor authenticatie afzender: afzender maakt bericht aan genereert hashwaarde voor bericht met SHA-1 (160 bits) of ander hashalgoritme hashwaarde wordt versleuteld (door RSA of ElGamal) met vertrouwelijke sleutel van afzender en toegevoegd aan oorspronkelijk bericht (bericht wordt gecomprimeerd met ZIP) (bericht wordt omgezet naar radix-64-formaat) Voor de generatie van de digitale handtekening wordt gebruik gemaakt van de PKCS#1-v1.5-formattering. De compressie van het bericht laat toe opslagruimte (bij opslag op schijf) of bandbreedte (bij versturing per ) te besparen. Het is niet altijd even nuttig en kan hier uitgeschakeld worden. De omzetting naar radix-64-formaat (3 bytes worden omgezet naar 4 leesbare karakters). Dit vermijdt conversieproblemen die kunnen optreden bij bepaalde programma’s als binaire data worden doorgestuurd. Ook dit element is optioneel. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

10 PGP: authenticatie afzender Alice compressie facultatief
leesbaar bericht leesbaar bericht compressie facultatief Hash vertrouwelijke sleutel Alice →R64 hash- fie verstuurd bericht Hash encr. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

11 Gebruik voor authenticatie
PGP: authenticatie Gebruik voor authenticatie ontvanger: (bericht wordt omgezet van radix-64-formaat) (bericht wordt gedecomprimeerd) ontvanger gebruikt publieke sleutel van afzender om versleutelde hashwaarde te ontcijferen (door RSA of ElGamal) ontvanger herberekent hashwaarde van bericht en vergelijkt met ontcijferde hashwaarde: als er overeenkomst is, blijkt het bericht authentiek Het basisschema voor authenticatie verschilt lichtjes als DSA gebruikt wordt, in die zin dat de digitale handtekening gegenereerd wordt m.b.v. DSA i.p.v. met de combinatie van een hashfunctie met een asymmetrisch encryptiealgoritme. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

12 PGP: authenticatie ontvanger Bob hash- indien decompr. fie gebruikt
leesbaar bericht indien gebruikt door afzender decompr. Hash publieke sleutel Alice R64→ vergelijk ontvangen bericht decr. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

13 PGP: vertrouwelijkheid
Gebruik voor vertrouwelijkheid afzender: maakt bericht aan en genereert random sessiesleutel, alleen voor dit bericht te gebruiken (comprimeert bericht met ZIP) versleutelt bericht met sessiesleutel, m.b.v. gekozen symmetrisch encryptiealgoritme (AES, 3-DES,…) sessiesleutel wordt met publieke sleutel van ontvanger versleuteld m.b.v. asymmetrisch encryptiealgoritme (RSA of ElGamal) en dan aan bericht gehecht (bericht wordt omgezet naar radix-64-formaat) De generatie van de random sessiesleutel is vrij complex en berust op een generator van random getallen (op basis van door de gebruiker aangeslagen toetsen en de tijdstippen van deze toetsaanslagen) en een cryptografische generator van pseudorandom getallen (zie ook boek H15, appendix C, p. 479vv.). Voor de encryptie met publieke sleutel wordt gebruik gemaakt van de PKCS#1-v1.5-formattering. Opnieuw zijn de compressiestap en de omzetting naar radix-64-formaat facultatief. De compressie is hier echter een stuk nuttiger dan bij authenticatie, vooral als men gewone of gestructureerde tekst wenst door te sturen. Na compressie zal de redundantie in het bericht een stuk kleiner zijn, zodat cryptanalyse een stuk moeilijker wordt. Voor de symmetrische encryptie wordt CFB-mode (cipher feedback) gebruikt. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

14 PGP: vertrouwelijkheid
afzender Alice publieke sleutel Bob verstuurd bericht geheime sessiesleutel leesbaar bericht asymm. encr. compressie →R64 versleut. sessiesl. symm. encr. versleuteld bericht facultatief facultatief Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

15 PGP: vertrouwelijkheid
Gebruik voor vertrouwelijkheid ontvanger: (bericht wordt omgezet van radix-64-formaat) gebruikt eigen vertrouwelijke sleutel om sessiesleutel te decrypteren m.b.v. geschikt asymmetrisch encryptiealgoritme (RSA of ElGamal) decrypteert bericht met meegekregen sessiesleutel m.b.v. door afzender gekozen symmetrisch encryptiealgoritme (AES, 3-DES,…) (bericht wordt gedecomprimeerd) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

16 PGP: vertrouwelijkheid
ontvanger Bob vertrouwelijke sleutel Bob ontvangen bericht geheime sessiesleutel leesbaar bericht asymm. decr. R64→ decompr. versleut. sessiesl. symm. decr. versleuteld bericht indien gebruikt door afzender indien gebruikt door afzender Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

17 PGP: vertrouwelijkheid en authenticatie
Gebruik voor vertrouwelijkheid én authenticatie afzender: eerst authenticatie toevoegen (digitale handtekening) zonder compressie of omzetting naar radix-64-formaat dan vertrouwelijkheid getekend bericht wordt dus versleuteld ontvanger eerst versleuteld bericht decrypteren dan authenticiteit verifiëren Compressie en omzetting naar radix-64-formaat zijn wel nog mogelijk in de stap waarin het getekende bericht vertrouwelijk gemaakt wordt. De omzetting naar radix-64-formaat heeft alleen zin net voor het bericht verstuurd wordt. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

18 PGP: sleutelidentificatie
Probleem bij asymmetrische decryptie weten welke sleutel gebruikt moet worden afzender/ontvanger hebben immers vrijheid meer dan 1 sleutelpaar te gebruiken mogelijke oplossingen verzend publieke sleutel met bericht onhandig, gezien lengten van publieke sleutels sleutelidenteit (“key-ID”), uniek voor elke publieke sleutel bij 1 bepaalde gebruiker moeilijkheid link tussen sleutel en identiteit te beheren Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

19 PGP: sleutelidentificatie
Sleutelidentificatie in PGP 64 minst significante bits van publieke sleutels 264 (≈1,8×1019) mogelijke sleutels waarschijnlijkheid van 2 identieke sleutelidentiteiten gering gemakkelijk juiste publieke sleutel terug te vinden zeer gemakkelijk te beheren Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

20 PGP: structuur bericht
onderdeel voor sessiesleutel K-ID(KUB) KS EKUB tijdsstempel H K-ID(KUA) digitale handtekening 2 eerste bytes H(bericht) H(bericht) EKRA (ZIP) EKS (R64) bestandsnaam tijdsstempel Dit is de structuur van een geauthentiseerd en vertrouwelijk bericht dat van A naar B verstuurd wordt. De tijdsstempel binnen het bericht bevat het tijdstip van aanmaak van het bericht. De digitale handtekening van het bericht (voor authenticatie) bestaat uit: de (versleutelde) hashwaarde van de data van het bericht (incl. tijdsstempel van de digitale handtekening): H(bericht), 160 bits indien m.b.v. SHA-1 gegenereerd, en versleuteld met de vertrouwelijke sleutel van de afzender (A) de 2 eerste bytes van de (onversleutelde) hashwaarde, als snelle controle of wel de juiste publieke sleutel gebruikt bij de decryptie van de versleutelde hashwaarde door de ontvanger (B) identificatie voor de publieke sleutel van de afzender: K-ID(KUA) tijdsstempel met het tijdstip van aanmaak van de digitale handtekening Voor de vertrouwelijkheid is een onderdeel nodig voor de sessiesleutel: sessiesleutel KS, versleuteld met publieke sleutel van ontvanger (KUB) een identificatie voor de publieke sleutel van de afzender: K-ID(KUB) De (facultatieve) compressie (ZIP) gaat over zowel de digitale handtekening als het bericht zelf. De symmetrische versleuteling slaat eveneens op het (gecomprimeerde) geheel van digitale handtekening en bericht. Tenslotte geschiedt de (facultatieve) omzetting naar radix-64-formaat over de drie onderdelen (onderdeel voor de sessiesleutel, digitale handtekening en bericht zelf). bericht data H Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

21 PGP: sleutelopslag Sleutelopslag in PGP
opslag in twee sleutelringen (“key rings”) ring voor vertrouwelijke sleutels (“private-key ring”) vereist speciale opslag onverantwoord vertrouwelijke sleutels onversleuteld op te slaan ring voor publieke sleutels (“public-key ring”) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

22 Ring voor vertrouwelijke sleutels
PGP: sleutelopslag Ring voor vertrouwelijke sleutels bevat voor elke sleutel volgende informatie tijdsstempel: tijdstip van aanmaak van sleutelpaar sleutelidentificatie (voor bijhorende publieke sleutel) de bijhorende publieke sleutel de vertrouwelijke sleutel versleuteld m.b.v. symmetrische encryptie (AES, 3-DES,…) wachtzin (“passphrase”) om te ontsleutelen een identificatie van de gebruiker ( adres of andere) Deze ring bevat normaal alleen sleutelparen die tot de eigenaar van de sleutelring behoren. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

23 Bij generatie sleutelpaar
PGP: sleutelopslag Bij generatie sleutelpaar wachtzin hash- fie geëncrypteerde vertrouwelijke sleutel vertrouwelijke sleutel symm. encr. Bij het genereren van een nieuw sleutelpaar zal PGP aan de gebruiker vragen een wachtzin (“passphrase”; een soort verbeterd wachtwoord) in te geven. Via een hashfunctie (SHA-1) wordt een tijdelijke geheime sleutel afgeleid uit deze wachtzin. De gegenereerde vertrouwelijke sleutel wordt dan versleuteld m.b.v. een symmetrisch encryptiealgoritme (AES, 3-DES,…) en de tijdelijke geheime sleutel, tot de geëncrypteerde vertrouwelijke sleutel, die dan in de ring voor vertrouwelijke sleutels kan opgeslagen worden. De wachtzin en de tijdelijke geheime sleutel worden NIET opgeslagen. De wachtzin kan een kwetsbaar punt zijn in het PGP-schema (een zorgvuldige keuze is aangewezen). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

24 Bij gebruik vertrouwelijke sleutel
PGP: sleutelopslag Bij gebruik vertrouwelijke sleutel wachtzin hash- fie geëncrypteerde vertrouwelijke sleutel vertrouwelijke sleutel symm. decr. Telkens de vertrouwelijke sleutel nodig is, wordt de geëncrypteerde vertrouwelijke sleutel uit de ring voor vertrouwelijke sleutels gedecrypteerd m.b.v. dezelfde tijdelijke geheime sleutel (afgeleid uit de gekozen wachtzin die de gebruiker dient te onthouden) en hetzelfde encryptiealgoritme dat gebruikt werd bij de generatie van het sleutelpaar. De vertrouwelijke sleutel is nodig telkens men een bericht wenst te tekenen, of een ontvangen vertrouwelijk bericht te ontcijferen. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

25 Ring voor publieke sleutels
PGP: sleutelopslag Ring voor publieke sleutels bevat voor elke sleutel volgende informatie tijdsstempel: tijdstip van aanmaak van sleutel sleutelidentificatie de publieke sleutel een identificatie van de gebruiker ( adres of andere) informatie over het vertrouwen in deze publieke sleutel digitale handtekeningen van deze sleutel (door andere gebruikers) mate voor vertrouwen in deze digitale handtekeningen zie ook verder In deze ring worden publieke sleutels opgeslagen die behoren tot andere gebruikers, die de eigenaar van deze ring kent. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

26 Probleem van vertrouwen in publieke sleutels
PGP: sleutelbeheer Probleem van vertrouwen in publieke sleutels met welke zekerheid kennen we de eigenaars van publieke sleutels in onze ring voor publieke sleutels? klassiek probleem van sleutelbeheer Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

27 Mogelijke oplossingen
PGP: sleutelbeheer Mogelijke oplossingen fysische uitwisseling van publieke sleutel OK voor personen die men kent, vertrouwt en met wie men voldoende regelmatig fysisch contact heeft onhandig voor bv. collega in de VS verificatie via parallel kanaal (telefoon, fax, brief,…) genereer hashwaarde van publieke sleutel: “vingerafdruk” van deze sleutel (in hexadecimaal formaat) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

28 Mogelijke oplossingen (vervolg)
PGP: sleutelbeheer Mogelijke oplossingen (vervolg) bekomen publieke sleutel van B via vertrouwde derde D D genereert een certificaat (digitale handtekening met zijn vertrouwelijke sleutel) van publieke sleutel van B, samen met creatietijdstip, geldigheidsduur en identificatie van B vereist voldoende vertrouwen in handtekening van D certificaat kan ook via WWW beschikbaar gemaakt worden bekomen publieke sleutel van B via vertrouwde CA In deze beide gevallen moet men wel al beschikken over de publieke sleutels van andere gebruikers (de derde partij D of de CA). Deze kunnen eventueel via een andere weg bekomen zijn. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

29 PGP: sleutelbeheer Vertrouwen in PGP
deel van informatie opgeslagen in ring voor publieke sleutels deelaspecten vertrouwen in eigenaar van publieke sleutel (bepaald door gebruiker) vertrouwen in digitale handtekening van een publieke sleutel (berekend door PGP) vertrouwen in paar eigenaar/publieke sleutel (berekend door PGP) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

30 Vertrouwen in eigenaar van publieke sleutel
PGP: sleutelbeheer Vertrouwen in eigenaar van publieke sleutel verschillende niveaus maximaal vertrouwen: sleutel aanwezig in ring voor vertrouwelijke sleutels altijd te betrouwen om andere sleutels te tekenen meestal te betrouwen om andere sleutels te tekenen meestal niet te betrouwen om andere sleutels te tekenen onbekende gebruiker meer ver- trouwen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

31 Vertrouwen in digitale handtekening van een publieke sleutel
PGP: sleutelbeheer Vertrouwen in digitale handtekening van een publieke sleutel opzoeken door PGP in ring voor publieke sleutels van vertrouwensniveau in eigenaar van sleutel die gebruikt werd voor handtekening indien niet gevonden: toekennen van niveau “onbekende gebruiker” Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

32 Vertrouwen in paar eigenaar/publieke sleutel
PGP: sleutelbeheer Vertrouwen in paar eigenaar/publieke sleutel geregeld berekend door PGP op basis van digitale handtekeningen voor dit paar verschillende niveaus volledig vertrouwen gedeeltelijk vertrouwen geen vertrouwen onbekend vertrouwen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

33 Vertrouwen in paar eigenaar/publieke sleutel
PGP: sleutelbeheer Vertrouwen in paar eigenaar/publieke sleutel volledig vertrouwen als paar getekend is door sleutel waarin men maximaal vertrouwen heeft als paar getekend is door X sleutels die altijd te betrouwen zijn om andere sleutels te tekenen als paar getekend is door Y (Y>X) sleutels die meestal te betrouwen zijn om andere sleutels te tekenen of een combinatie van beide voorgaanden Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

34 Herroepen van publieke sleutel
PGP: sleutelbeheer Herroepen van publieke sleutel als een vertrouwelijke sleutel waarschijnlijk gecompromitteerd is maak een sleutelherroepingscertificaat (“key revocation certificate”) aan getekend door eigenaar van gecompromitteerde sleutel zo snel mogelijk te verspreiden beperkte efficiëntie (zoals meeste herroepingstechnieken) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

35 S/MIME S/MIME Secure Multipurpose Internet Mail Extension
extensie van standaard MIME-formaat voor met beveiligingselementen steunt op technologie van RSA Data Security zie ook boek H. 18.2, p. 611vv. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

36 S/MIME: MIME MIME formaat voor inhoud van e-mail
opvangen van beperkingen van RFC 822: standaard basisformaat voor tekst SMTP (Simple Mail Transfer Protocol): standaardprotocol voor transfer van s Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

37 S/MIME: MIME MIME RFC 822 bericht bestaat uit:
enkele lijnen voor headers <sleutelwoord>: <argumenten> lange lijnen kunnen over verschillende regels uitgeschreven worden onbeperkte tekst (“body”), gescheiden van headers door blanco lijn Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

38 S/MIME: RFC 822 Voorbeeld: sleutelwoorden argumenten
From: To: Subject: Punteninbrengpakket Geachte professor, mevrouw, mijnheer … headerlijnen blanco lijn tekst Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

39 Problemen met SMTP/RFC 822
S/MIME: SMTP/RFC 822 Problemen met SMTP/RFC 822 ondersteunt slechts 7-bit ASCII overdracht binaire bestanden vereist een ad-hoc conversie naar tekst (bv. UUencode in Unix) niet-standaard implementaties van SMTP veroorzaken wijzigingen in verstuurde berichten … doel van MIME: oplossen problemen met behoud van compatibiliteit met RFC-822-implementaties Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

40 S/MIME: MIME MIME-specificatie definitie van 5 nieuwe header-velden
te includeren in header voor RFC 822 bevatten informatie over inhoud van het bericht definitie van aantal inhoudsformaten ondersteuning van multimedia definitie van encoderingen voor transfer laten conversie toe naar formaat dat niet gewijzigd wordt door systeem Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

41 S/MIME: MIME Nieuwe header-velden MIME-Version: 1.0
Content-Type: beschrijving van inhoud, wat ontvanger toelaat te weten hoe inhoud te verwerken Content-Transfer-Encoding: type transformatie gebruikt om inhoud te representeren in vorm aanvaardbaar voor transfer Content-ID Content-Description Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

42 S/MIME: MIME MIME Content-Types enkele voorbeelden (type/subtype)
text/plain: standaard tekst (ASCII of ISO 8559) multipart/mixed: parameter boundary=“…” (scheiding van verschillende onderdelen van ) application/octet-stream: algemene binaire data (bytes van 8 bits) Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

43 S/MIME: MIME Voorbeeld: From: Peter.Janssens@UGent.be
To: Subject: Punteninbrengpakket Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_=_next_part_ _=_" --_=_next_part_ _=_ Content-Type: text/plain; charset=US-ASCII Geachte professor, mevrouw, mijnheer… Content-Type: text/plain … <tekst> --_=_next_part_ _=_-- Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

44 S/MIME: functionaliteit
S/MIME-functies Enveloped data: versleutelde inhoud en geëncrypteerde sleutels voor 1 of meer ontvangers Signed data: digitale handtekening van inhoud (inhoud en handtekening geëncodeerd in base64) Clear-signed data: digitale handtekening van inhoud (alleen handtekening geëncodeerd in base64) Signed and enveloped data: combinatie van encryptie en digitale handtekening Het verschil tussen “signed data” en “clear-signed data” is dat een ontvanger die geen S/MIME-functionaliteit ondersteunt alleen de laatste soort berichten kan lezen. De functie “Enveloped data” realiseert vertrouwelijkheid, terwijl de functies “Signed data” en “Clear-signed data” authenticatie en (gedeeltelijk) data-integriteit realiseren. De functie “Signed and enveloped data” laat toe beide types beveiligingsfuncties te realiseren. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

45 S/MIME: ondersteunde algoritmen
S/MIME: algoritmen S/MIME: ondersteunde algoritmen hashfunctie SHA-1 (verplicht), MD5 (aangeraden) signatuurschema DSS (verplicht), RSA (aangeraden) sleuteluitwisseling DH/ElGamal (verplicht), RSA (aangeraden) symmetrische encryptie/decryptie 3-DES (aangeraden/verplicht) en RC2/40 (aangeraden) De ondersteuning van RC2/40 (RC2 met 40 bits) is een gevolg van vroegere exportregelingen van de VS op sterke cryptografie en kan in de praktijk beter niet gebruikt worden. Als de afzender informatie heeft over de door de ontvanger ondersteunde algoritmen, kan hij deze informatie opslaan en zal hij er rekening mee houden voor de te versturen s. Bovendien zal hij de keuze moeten maken of zwakke encryptie aanvaardbaar is als dit het enige is wat de ontvanger ondersteunt (zie ook boek p ). Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

46 New Content-(sub)types
S/MIME: berichten New Content-(sub)types Multipart/signed Application/pkcs7-mime s/mime-parameter: signedData envelopedData degenerate signedData Application/pkcs7-signature Application/pkcs10-mime PKCS (Public Key Cryptography Standards) is een reeks specificaties van RSA Laboratories voor asymmetrische cryptografie. Hierbij staan PKCS-1 voor RSA-encryptie, PKCS-7 voor de syntax van cryptografische berichten en PKCS-10 voor de syntax van certificatieaanvragen. “Multipart/signed” staat voor een “clear-signed” bericht in twee delen: het getekende bericht en de digitale handtekening. “Application/pkcs7-mime” met de parameter “signedData” geeft een getekende S/MIME-entiteit aan. “Application/pkcs7-mime” met de parameter “envelopedData” geeft een versleutelde S/MIME-entiteit aan. “Application/pkcs7-mime” met de parameter “degenerate signedData” geeft een S/MIME-entiteit aan die alleen certificaten voor publieke sleutels bevat. “Application/pkcs7-signature” slaat op het deel van een “multipart/signed”-bericht dat de digitale handtekening bevat. “Application/pkcs10-mime” slaat op een bericht waarin de registratie van een certificaat aangevraagd wordt. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

47 Te beveiligen MIME-entiteit
S/MIME: berichten Te beveiligen MIME-entiteit volledig bericht met uitzondering van de RFC-822-headers of bij “multipart”-bericht: 1 of meer onderdelen van bericht Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

48 Algemene werkwijze S/MIME
S/MIME: berichten Algemene werkwijze S/MIME MIME bericht volgens gewone MIME-regels opgesteld samen met beveiligingsinformatie (identificatie algoritmen, certificaten,…) verwerkt volgens S/MIME tot PKCS-object PKCS-object behandeld als berichtinhoud en in MIME verpakt (met geschikte headers) (deel)bericht moet naar canonische vorm geconverteerd worden De conversie naar canonische vorm is belangrijk opdat het eenduidig zou zijn wat exact getekend werd. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

49 S/MIME: envelopedData
Aanmaak genereer sessiesleutel voor symmetrische encryptie encrypteer sessiesleutel voor elke ontvanger voor elke ontvanger: maak “RecipientInfo” aan met: identificatie van certificaat van ontvanger identificatie van encryptiealgoritme voor sessiesleutel geëncrypteerde sessiesleutel Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

50 S/MIME: envelopedData
Aanmaak versleutel bericht met sessiesleutel RecipientInfo+versleutelde inhoud = envelopedData encodeer de envelopedData in base64 Hiermee wordt de vertrouwelijkheid van het bericht gegarandeerd. De sessiesleutel wordt voor elke ontvanger van het bericht versleuteld met diens publieke sleutel (vertrouwelijkheidsfunctie in een asymmetrisch encryptiealgoritme). De conversie naar base64 (3  8bits voorgesteld als 4  6 bits) is nodig om te vermijden dat het bericht gewijzigd wordt door het transfersysteem. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

51 S/MIME: signedData Aanmaak selecteer hashfunctie (SHA-1 of MD5)
bereken hashwaarde van te tekenen bericht encrypteer hashwaarde maak “SignerInfo” aan met: certificaat van afzender identificatie van hashfunctie en encryptiealgoritme geëncrypteerde hashwaarde (= digitale handtekening) identificatie hashfunctie + te tekenen bericht + SignerInfo + … = signedData encodeer de signedData in base64 Als DSS gebruikt wordt i.p.v. RSA zal de digitale handtekening niet aangebracht worden door een encryptie van de hashwaarde, maar door toepassing van DSA. De principiële werking is echter zeer gelijkaardig (berekening van hashwaarde en gebruik van de vertrouwelijke sleutel van de afzender voor het genereren van de digitale handtekening). De hashwaarde wordt versleuteld met de vertrouwelijke sleutel van de afzender (authenticatiefunctie in een asymmetrisch encryptiealgoritme). De signedData kan ook een verzameling certificaten bevatten om de nodige ketting van certificaten te realiseren tot een vertrouwde CA (“root CA”) voor beide afzender en ontvanger. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

52 S/MIME: Multipart/signed
“Clear signing” bericht wordt zonder speciale encodering verstuurd leesbaar voor ontvanger met MIME-capaciteit, maar niet in staat S/MIME te verwerken bericht bestaat uit 2 onderdelen te tekenen inhoud (maar mag niet gewijzigd worden door transfer) afgesplitste digitale handtekening zelfde procedure als voor signedData, behalve dat veld voor getekend bericht leeg blijft heeft type Application/pkcs7-signature Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

53 S/MIME: Application/pkcs10-mime
Aanvraag voor registratie van certificaten aanvraag bij CA bevat certificationRequestInfo bevat naam van te certifiëren gebruiker bevat representatie van publieke sleutel van gebruiker identificatie van asymmetrisch encryptiealgoritme digitale handtekening van certificationRequestInfo getekend met vertrouwelijke sleutel van afzender Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

54 S/MIME: degenerate signedData
Gebruik voor bericht met alleen certificaten of met CRL zelfde procedure als voor signedData met berichtinhoud leeg met signerInfo-veld leeg Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

55 Gebruik van X.509v3-certificaten
S/MIME: certificaten Gebruik van X.509v3-certificaten certificaten getekend door CA zoals in X.509 gebruikers of beheerders van S/MIME configureren van lijst met vertrouwde sleutels en CRL’s lokale verantwoordelijkheid voor beheer van certificaten nodig voor verificatie van handtekeningen en voor encryptie van berichten Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

56 S/MIME: extensies Extensies in S/MIME
RFC 2634: Enhanced Security Services for S/MIME “signed receipts” kan aangevraagd worden binnen “signedData”-object laat afzender toe te beschikken over bewijs dat ontvanger bericht wel degelijk ontvangen heeft “security labels” beveiligingsinformatie over gevoeligheid van door S/MIME versleutelde inhoud te gebruiken voor autorisatie of toegangscontrole Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

57 S/MIME: extensies Extensies in S/MIME “secure mailing lists”
nuttig voor s naar groot aantal ontvangers vereist afzonderlijke beveiliging voor elke ontvanger uitbesteden van taak aan (vertrouwde) “Mail List Agents” (MLAs) die de ontvangerspecifieke verwerking afhandelen Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans

58 S/MIME: extensies Extensies in S/MIME “signing certificates”-attribuut
normaal zijn in S/MIME gebruikte certificaten niet aan bericht gebonden door handtekening risico van kwaadaardige subsitutie van het certificaat vervanging door ongeldig certificaat vervanging door ander geldig certificaat met zelfde publieke sleutel maar met andere beperkingen op certificaat zorgt voor nieuw attribuut in de getekende attributen van het “SignerInfo”-object bindt certificaat aan bericht Het risico van de substitutie van een certificaat door een ander geldig certificaat is alleen mogelijk als beide certificaten op dezelfde publieke sleutel slaan, maar bv. een andere geldigheidsduur zouden hebben. In dit geval kan een aanvaller een oud certificaat vervangen door een nieuw en hiervan gebruik maken in een “replay”-aanval. Het hergebruik van dezelfde publieke sleutel voor twee verschillende certificaten is natuurlijk ten zeerste af te raden. Informatiebeveiliging Vakgroep Informatietechnologie – IBCN – Eric Laermans