Att använda kryptering. Nyckelhantering och protokoll som bygger på kryptering

Transkript

1 Att använda kryptering Nyckelhantering och protokoll som bygger på kryptering 1

2 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

3 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 Använda så äkta slump som möjligt! Låt inte 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

4 Äkta slump??? Slumpgeneratorer i datorer är konstruerade för att ge statistisk rektangulärfördelning, inte för att hindra att man förutsäger nästa värde 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 bara om kedjans frö inte kan hittas med uttömmande sökning 4

5 Nyckelförvaring En normal dators lagringsutrymmen är sårbara för attacker via säkerhetshål, trojaner, medvetet inlagda bakdörrar o s v 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

6 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

7 Å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-themiddle i stället för till avsedd mottagare 7

8 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

9 Nyckelutbytesnycklar Alice Alice,Bob,E(K 1 ; K 2 ) Bob K 1 K 1 Alice Alice,Bob,E(K 2 ; M) Bob K 1 K 1 K 2 K 2 9

10 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

11 Nyckeldistributionscentral Nyckeldistributionscentral {K i } Alice K A Bob K B 11

12 Nyckeldistributionscentral 1 Nyckeldistributionscentral {K i } Alice 1: A, E(K A ;A, B, K AB ) 2: E(K B ;A, B, K AB ) Bob K A K AB K B 12

13 Nyckeldistributionscentral 2 1: Req, A, B Alice K A Nyckeldistributionscentral {K i } 2: E(K A ;A, B, K AB ) K AB 2: E(K B ;A, B, K AB ) Bob K B 13

14 Sessionsnycklar Nyckeldistributionscentral {K i } Alice A,B,E(K AB ; K Session1 ) Bob K A K AB K B K AB 14

15 Öppen nyckeldistribution Varje användare har en hemlig parameter X i Det finns en enkelriktad funktion F Varje användare publicerar F(X i )=Y i Det finns en enkelriktad funktion G sådan att G(X s,f(x t ))=G(X t,f(x s )) för alla s och t Användare s beräknar K st =G(X s,y t ) och användare t beräknar K ts = G(X t,y s ), som är deras nyckel 15

16 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=g x modulo p För att skapa en nyckel delad med användare i, tar du ditt hemliga x och det offentliga y i och beräknar y i x modulo p (g a ) b = g ab = g ba = (g b ) a 16

17 Öppen nyckeldistribution Nyckelparametercentral {Y i } 1: Y B 2: Y A Alice 3:A,B,E(K AB ; K Session1 ) Bob X A K AB X B K AB 17

18 Asymmetrisk kryptering Varje användare har ett nyckelpar, en publik nyckel e, en hemlig nyckel d e är en enkelriktad funktion av d eller så har de beräknats med en enkelriktad transformation från en gemensam rot 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

19 Publika nycklar Register för publika nycklar {e i,n i } 1: e B,n B Alice d A,n A 2:A,B,E(e B ; K Session1 ) Bob d B,n B 19

20 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

21 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

22 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

23 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

24 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 PKI med tillit är svår att bygga upp 24

25 Protokoll, exempel IPSec SSL/TLS SSH 25

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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 Anrop av tjänst, som påstås komma från användaren, vars namn finns i biljetten, och som åtföljs av data krypterade med sessionsnyckeln i biljetten är då godkända 33

34 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änstesevern är den som har skyddade data, men som inte ska behöva göra egen användarautentisering 34

35 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

36 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

37 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