Transcript Nyckelhantering, kryptobaserade protokoll och andra verktyg för

Att använda kryptering
Nyckelhantering och protokoll som
bygger på kryptering
1
Nyckelhantering
•
•
•
•
•
Nycklar måste genereras på säkert sätt
Nycklar måste distribueras på säkert sätt
Ägaren av en nyckel måste vara säkerställd
Nycklar måste förvaras säkert
Gamla nycklar måste förstöras på
kontrollerat sätt
2
Nyckelgenerering
• Attackmöjligheter för uttömmande sökning
för en nyckel avgörs dels av hur många
nyckelvärdena kan vara, dels av hur
sannolika de är
• Man måste använda så äkta slump som
möjligt och inte låta kännedom om tiden för
genereringen eller värdet för föregående
nycklar bli en ledtråd till nyckelns värde
3
Äkta slump???
• Sslumpgeneratorer i datorer är konstruerade för att
ge statistisk rektangulärfördelning, men inte för att
utesluta att man förutsäger vad nästa värde blir
utifrån kännedom om tidigare värden
• Tiden som slumpkälla ger liten sökrymd, om man
vet ungefär när nyckeln skapades
• Att kryptera eller enkelriktat transformera en kedja
av värden fungerar om fröet är tillräckligt svårt att
hitta med uttömmande sökning
4
Nyckelförvaring
• En dators lagringsutrymmen är sårbara för
attacker via säkerhetshål o s v
• En generell dator kan inte ha fast, granskad
programvara fri från möjligheter att läsa
nyckeln på dess förvaringsadress
• Ett aktivt kort eller en ”kod-dosa” är därför
säkrare än en app eller allmänt program för
kryptering och signering
5
Förstöring av gamla nycklar
• Om man slarvar med gamla nycklar
möjliggörs två typer av attacker:
– Läsning av gamla data, som fortfarande är
hemliga
– Förfalskning av dokument, som förvaras så att
genereringsdatum bara framgår av dokumentets
innehåll
6
Återstår två problem
• Att distribuera nycklar, så att endast avsedd
användare har deras värde
• Att säkerställa vem som har vilken nyckel,
så att man t ex inte luras att använda
nyckeln till ”man-in-the-middle” i stället för
till avsedd mottagare
7
Nyckeldistribution
• Säker första nyckel vid kontakt med en ny miljö
levereras via kurir (människa). Via nätet/dator ger
möjlighet att fuska!!!
• Dagens webbläsare levereras med vissa ”säkra”
nycklar, där falska värden förutsätts upptäckas
• När du en gång fått en säker nyckel, kan den
användas för att utbyta nya nycklar
• Om A delar en nyckel med B och B delar en
nyckel med C, kan A och C utbyta en nyckel via B
(förutsatt att båda litar på B)
8
Nyckelutbytesnycklar
Alice
K1
Alice,Bob,E(K1; K2)
Bob
K1
Alice
K1 K2
Alice,Bob,E(K2; M)
Bob
K1 K2
9
Nyckeldistributionscentral
• En kuriröverförd nyckel per medlem
• Centralen har alla medlemmars nycklar
• Mycket känslig punkt för både sekretesshot
och dataintegritetshot
• Centralen förmedlar nycklar vid nya
förbindelser mellan medlemmar
10
Nyckeldistributionscentral
Nyckeldistributionscentral {Ki}
Alice
KA
Bob
KB
11
Nyckeldistributionscentral 1
Nyckeldistributionscentral {Ki}
1: A, E(KA;A, B, KAB)
Alice
KA KAB
2: E(KB;A, B, KAB)
Bob
KB
12
Nyckeldistributionscentral 2
1: Req, A, B
Nyckeldistributionscentral {Ki}
KAB
2: E(KA;A, B, KAB)
Alice
KA
2: E(KB;A, B, KAB)
Bob
KB
13
Sessionsnycklar
Nyckeldistributionscentral {Ki}
Alice
KA KAB
A,B,E(KAB; KSession1)
Bob
KB KAB
14
Öppen nyckeldistribution
•
•
•
•
Varje användare har en hemlig parameter Xi
Det finns en enkelriktad funktion F
Varje användare publicerar F(Xi)=Yi
Det finns en enkelriktad funktion G sådan
att G(Xs,F(Xt))=G(Xt,F(Xs)) för alla s och t
• Användare s beräknar Kst=G(Xs,Yt) och
användare t beräknar Kts= G(Xt,Ys), som är
deras nyckel
15
Exempel: Diffie-Hellman
• En ”generator” g och ett mycket stort
primtal p väljs och publiceras
• Varje användare väljer ett hemligt x
• Alla användare publicerar y=gx modulo p
• För att skapa en nyckel delad med
användare i, tar du ditt hemliga x och det
offentliga yi och beräknar yix modulo p
• (ga)b= gab= gba= (gb)a
16
Öppen nyckeldistribution
Nyckelparametercentral {Yi}
1: YB
Alice
XA KAB
2: YA
3:A,B,E(KAB; KSession1)
Bob
XB KAB
17
Asymmetrisk kryptering
• Varje användare har ett nyckelpar, en publik nyckel e, en
hemlig nyckel d
• e är en enkelriktad funktion av d eller också har de
beräknats från en gemensam ”rot” och transformationen
från roten till e,d är enkelriktad
• Vid fallet med gemensam rot talar vi om lönndörrssystem
(engelska ”trapdoor”, som inte här betyder ”fallucka”)
• Det finns två enkelriktade funktioner f och g sådana att
g(d,f(e,x)=x
18
Publika nyckklar
Register för publika
nycklar {ei,ni}
1: eB,nB
Alice
dA,nA
2:A,B,E(eB; KSession1)
Bob
dB,nB
19
Nyckelregister, alltså???
• Ingen instans kan ha resurser för att hålla ett säkert
register för alla internet-anslutnas nycklar.
• Hur skulle kontrollen ske på garanterat säkert sätt
att nyckeln som anges tillhöra lilla webbutiken A
verkligen tillhör A?
• Ett sådant register fungerar inte heller på
huvuddomän-nivå.
• Så vi har lokala register eller frågar den anropade
direkt. Men kan vi lita på svaret?
20
Man-in-the-middle
• Alice vill kontakta Bob.
• Alice och Bob har ingen tidigare kontakt
• Eve sätter sig mitt emellan. Hon sänder sin öppna
nyckel till Alice, som skickar en sessionsnyckel
krypterad med Eves nyckel. Eve skickar en
sessionsnyckel till Bob med hans öppna nyckel
• Alla meddelanden mellan Alice och Bob
dekrypteras av Eve, krypteras om och sänds
vidare.
• Alice och Bob märker ingenting
21
Den centrala frågan: Vems är
nyckeln?
• Om du använder en symmetrisk nyckel, så ska
distributionen säkerställa vem du delar den med
• Om du får en publik nyckel, hur vet du säkert vem
som har motsvarande privata nyckel?
• Svar: Du har ett signerat meddelande med
innehållet ”Jag A garanterar att användare B har
publik nyckel X från tidpunkt y till tidpunkt z”
• Detta kallas (nyckel-)certifikat
• För att kontrollera certifikatets äkthet, behöver du
signerarens garanterat äkta publika nyckel...
22
CA
• Den som utfärdar nyckelcertifikat kallas
Certificate Authority, CA
• En CA kan vara organisationsintern, nationell,
internationell o. s. v.
• CA måste kontrollera identiteten för den
användare som har den privata nyckeln, innan
certifikatet utfärdas
• Detta kan antingen göras genom en ”tillitskedja”
eller utanför datorerna med papper och närvaro
23
PKI
• Standarder för att hantera publika nycklar
kallas PKI, Public Key Infrastructure
• Dessa standarder förutsätter existensen av
godkända CA och tillitskedjor
• Vi använder ofta asymmetrisk kryptering,
till exempel, i SSL/TLS, men verklig PKI
med tillit är svår att bygga upp
24
Protokoll, exempel
• IPSec
• SSL/TLS
• SSH
25
IPSec
• Ger möjlighet till kontroll av dataintegritet och
skydd av sekretess för själva paketinnehållet
• Bygger på att parametrar, som algoritmtyp,
nyckelvärde etc. redan utbytts och fått ID
(Security Association)
• Dataintegritet skyddas genom digital signatur eller
MAC
• Sekretesskydd består av kryptering
• Kräver DES CBC, stöder andra algoritmval
26
IPSec SA
• Skapas genom meddelanden i annan
särskild standard, IKEv2, Internet Key
Exchange
• Definierar vilka algoritmer som används
och vilka nycklar
• Använder Diffie-Hellman som default för
att sätta upp nyckel, men kan använda andra
utbytesalgoritmer också
27
SSL/TLS
• Placerat mellan ”normal” TCP och applikation
• Session inleds med handskakning, då symmetrisk
sessionsnyckel skapas och utbyts.
• Resten av sessionen krypteras med denna nyckel
• Stöder asymmetrisk kryptering och certifikat för
utbytet av sessionsnyckeln
• Stöder olika algoritmer, men har ingen som måste
finnas i alla implementationer
• Vilken algoritm m m som används bestäms under
handskakningen
28
SSH
• Ursprungligen ett UNIX-kompatibelt protokoll för
säker login mot ”remote services”
• Idag ett vanligt protokoll i allmänhet för t. ex.
kryptering av lösenord vid login, upprättande av
krypterad förbindelse o s v
• Använder asymmetrisk kryptering eller öppen
nyckeldistribution (Diffie-Hellman) och certifikat
för att skapa/utväxla nycklar vid login
29
Och vad är tunnling, VPN o s v?
• Tunnling dök upp som term då man började lägga
till kryptering av ett helt färdigt paket innan det
nådde nästa nivå i protokollstacken för
kommunikationen, utan att ändra protokollen i sig
i övrigt
• VPN blev ”försäljningsterm” för att man har
organisationsinterna nycklar och automatiskt
krypterar allt som kommuniceras mellan egna
enheter
30
Tillitskedjor och Single sign-on
• Antag att B delar en nyckel med A och en annan
med C, och både A och C litar på B
• B kan nu skicka en gemensam krypterad nyckel
till både A och C, samt meddela dem krypterat
vem som också har denna nyckel (C respektive A)
• Både A och C vet nu att meddelanden krypterade
med denna nyckel kommer säkert från C
respektive A, för B fuskar inte
• Kerberos bygger på detta
31
Kerberos
• Den centrala servern krypterar aktuell tid och en
sessionsnyckel K med den påstådda användarens
lösenord. Bara avsedd användare vet det
dekrypterande lösenordet och kan därmed få
sessionsnyckelns värde,. Tiden avslöjar försök att
återanvända gamla, knäckta nycklar
• Servern skapar också en biljett, som talar om för
begärd tjänst att användare A har nyckel K.
• Biljetten krypteras med tjänstens nyckel. Nu kan
också tjänsteservern få fram värdet på K.
32
Kerberos säkerhetslogik
• Biljetterna krypteras med en nyckel, som bara
avsedd mottagande del i Kerberos känner till.
• Biljetten innehåller användarens identitet,
sessionsnyckel, giltighetstid för nyckeln o s v.
• Den enhet som skapade biljetten förutsätts ha sänt
dels sessionsnyckeln, dels biljetten till den
användare, som nu anropar tjänsten
• Godkända anrop av tjänst kommer från
användaren, vars namn finns i biljetten, och åtföljs
av data krypterade med sessionsnyckeln i biljetten
33
Kerberos struktur
• Det finns fyra sorters aktörer: Användaren,
Kerberosservern, biljettservrar och tjänsteservrar.
• Kerberosservern kontrollerar användarens identitet
• Biljettservrar kontrollerar att användaren har en
giltig biljett från nivån ovanför, samt skapar
sessionsnycklar och utfärdar biljetter för nivån
under, förutsatt att användaren får anropa begärd
tjänst.
• Tjänsten är den som har skyddade data, men som
inte ska behöva göra egen användarautentisering
34
Tillitskedjan i Kerberos
• Tjänsteservrarna litar på att den som känner till biljettens
sessionsnyckel är den vars identitet står i biljetten,
eftersom biljettservrarna ser till detta.
• Biljettservrarna litar på att den som känner till
sessionsnyckeln i den biljett de får är den användare som
står i biljetten, eftersom Kerberosservern ser till detta
• Kerberos ser till att biljetter bara kan utnyttjas av den som
har korrekt lösenord och därför kan dekryptera
sessionsnyckeln.
• Så den som har giltig tjänstebiljett är den som vet rätt
värde för identitetens lösenord
35
Grunden för tillit i Kerberos
• Varje nyckel är känd av endast två parter.
• Mottagaren är den ena parten, och eftersom avsändaren
kunde skapa ett meddelande med denna nyckel, så är
tydligen avsändaren den andra av de två
• Pålitliga parter högre upp i strukturen ser till att
sessionsnycklar bara kan dekrypteras av rätt användare
(den vars identitet står i biljetten)
• Biljetter försäkrar vem denna användare är.
• Varje biljettutfärdande inleds med utväxling av tidsdata
och deras krypterade värde, så inspelade sessioner är
värdelösa för förfalskare
36
Så Kerberos är ett
krypteringsprotokoll?
• Kerberos i sig innehåller inget stöd för
fortsatt användning av sessionsnyckeln för
större datamängder
• Men självfallet hindrar inget parterna från
att använda den förhoppningsvis säkra
nyckel de nu ändå har fått genom Kerberos
37