Introduktion til Kryptering

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…?


• 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


• 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


35424 35424

A3ERA3ER

35424 A3AR

23112 BB19

… …

… …


• 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 109

• 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


• 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 – 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


• 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….?


• …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


• …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”



• 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


• Generelt; N parter giver brug for N*(N-1)/2

• 1.000 parter -> ca. 500.000 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?


• 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


• 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

Documents

Introduktion til Kryptering