Secret Key kryptering – teknikker og problemer INTRODUKTION TIL KRYPTERING

SECRET KEY KRYPTERING Forudsætninger Begge parter har en hemmelig nøgle Begge parter har den samme nøgle Nøglen kan benyttes på til kryptering og dekryptering

SECRET KEY KRYPTERING Problemstillinger Fortrolighed (confidentiality) Verifikation (authentication) Integritet (integrity) Ikke-benægtelse (non-repudiation)

SECRET KEY KRYPTERING - FORTROLIGHED Vi vil gerne sikre os, at kun personer med den hemmelige nøgle kan afkode beskeden Dette gøres ved at anvende en ”stærk” krypterings- metode, f.eks. DES/AES Disse krypteringer kan ikke angribes med krypto- analyse, kun ved at prøve alle mulige nøgler af

SECRET KEY KRYPTERING - VERIFIKATION Vi vil gerne sikre os, at det er den rette modtager, der sidder i den anden ende af kommunikationen Hvad karakteriserer den rette modtager? Den rette modtager har også den hemmelige nøgle Hvordan kan vi verificere dette, uden at sende selve nøglen frem og tilbage…?

SECRET KEY KRYPTERING - VERIFIKATION Verifikation kan udføres ved at give modtageren en ”udfordring” Afsenderen beder modtageren om at kryptere en given klartekst, f.eks. et tal Modtageren foretager krypteringen, og sender resultatet tilbage til afsenderen Hvis resultatet er det samme som modtageren selv ville kryptere klarteksten til, er modtageren verificeret

SECRET KEY KRYPTERING - VERIFIKATION Problemer med verifikation Vi kan ikke vide, om modtageren vitterligt er ”den rette”, kun at modtageren har nøglen (som måske er stjålet) Hvis en part gerne vil simulere at han har nøglen, kan det (i teorien) gøres ved at observere og kopiere de udfordringer og svar, som sendes frem og tilbage ”Man in the middle” angreb

SECRET KEY KRYPTERING - VERIFIKATION A3ER 35424A3AR 23112BB19 …… ……

SECRET KEY KRYPTERING - VERIFIKATION Problemer med verifikation Hvordan kan man undgå man-in-the-middle angreb? Vælg udfordringen fra en meget stor mængde af mulige udfordringer, f.eks. alle tal mellem 0 og 10 9 Bør i praksis aldrig sende den samme udfordring to gange Modtager kan verificere afsender på samme måde

SECRET KEY KRYPTERING - INTEGRITET Vi vil gerne sikre os, at den besked modtageren modtager, rent faktisk er den samme som afsenderen afsendte Kan en krypteret besked ændres…? Ja, men ikke nødvendigvis til noget meningsfuldt Vi kan medsende en ”integritetkode” sammen med beskeden

SECRET KEY KRYPTERING - INTEGRITET En integritetskode er et kort stykke data, der opfylder disse betingelser Udregnes på basis af beskeden og nøglen Den mindste ændring af beskeden (én bit) skal resultere i en ny integritetskode De udregnede integritetskoder skal fordele sig jævnt over de mulige integritetskoder

SECRET KEY KRYPTERING - INTEGRITET

SECRET KEY KRYPTERING – IKKE-BENÆGTELSE Vi vil gerne sikre os, at modtageren ikke kan benægte at have modtaget beskeden (selv om han vitterligt har modtaget den) Hvorfor dog det…? Kan være relevant i forhold til jura, f.eks. en besked omkring handel med aktier eller lignende

SECRET KEY KRYPTERING – IKKE-BENÆGTELSE Mulig strategi: Modtageren sender en kvittering på hver modtaget besked Kvitteringen selv er krypteret med den hemmelige nøgle Dermed må det jo være den rette modtager, som har kvitteret, eller….?

SECRET KEY KRYPTERING – IKKE-BENÆGTELSE …eller også kan afsenderen selv have fabrikeret kvitteringen, da afsenderen jo også kender den hemmelige nøgle  Det viser sig, at det ikke er muligt at realisere beviselig ikke-benægtelse med hemmelige nøgler

SECRET KEY KRYPTERING – IKKE-BENÆGTELSE …eller også kan afsenderen selv have fabrikeret kvitteringen, da afsenderen jo også kender den hemmelige nøgle  Det viser sig, at det ikke er muligt at realisere beviselig ikke-benægtelse med hemmelige nøgler

SECRET KEY KRYPTERING - PROBLEMER Indtil videre har vi kun set på kommunikation mellem to parter Secret key kryptering har visse problemer, men kan fungere rimeligt Hvad hvis vi har tre parter, der gerne vil kommunikere ”alle til alle”

SECRET KEY KRYPTERING - PROBLEMER

Kan vi tillade, at alle tre parter har samme nøgle…? Hvad hvis det er 1000 parter (f.eks. i et firma)…? Vi kan generelt ikke tillade, at en nøgle deles af mere end et enkelt afsender-modtager par Bo + Lis -> nøgle A Bo + John -> nøgle B Lis + John -> nøgle C

SECRET KEY KRYPTERING - PROBLEMER Generelt; N parter giver brug for N*(N-1)/ parter -> ca nøgler Meget stort antal nøgler, og hvor skal vi få alle de nøgler fra? Kan vi på nogen måde reducere antallet af nøgler?

SECRET KEY KRYPTERING - PROBLEMER Vi kan benytte en Troværdig Tredjepart (TTP) Afsender sender ikke beskeder direkte til modtageren, men i stedet via TTP Fordel: Alle parter skal kun have én nøgle, nemlig til kommunikation med TTP N parter; N nøgler

SECRET KEY KRYPTERING - PROBLEMER TTP er stadig en omstændelig løsning. Meget arbejde med at holde styr på nøgler Dobbeltarbejde – hver besked skal krypteres og dekrypteres to gange Hvornår er TTP troværdig nok…? Hvor sårbar er TTP overfor angreb…?

SECRET KEY KRYPTERING - KONKLUSION Secret key kryptering er i teorien glimrende, men der er problemer i praksis Hvordan udveksles nøgler? Hvordan verificeres modtager? Hvordan håndteres mange-til-mange kommunikation? Mange af disse problemer kan løses ved at benytte Public Key kryptering