Key Management 31. januar, 2009 Jakob I. Pagter
Basale problemer Forringelse af fortrolighed: Jo oftere og jo længere tid en nøgle bruges, desto mindre bliver sikkerheden Nøgler slides!! Reel autenticitet: Hvem tilhører den enkelte nøgle faktisk hvem snakker man med 2
Tidens tand Ethvert stykke hemmeligt data har en større risiko for at blive afsløret, jo længere tid det eksisterer, og jo oftere det bliver brugt. => Krypteringsalgoritmen kan ikke antages at være hemmelig, krypto-sikkerhed kan kun baseres på at nøglerne er hemmelige. => Ingen nøgle bør have ubegrænset levetid, og hvis levetiden er lang, bør den ikke bruges for ofte. 3
Nøglehierarkier Alice vil gerne opretholde sikker kommunikation med Bob. Vi antager et øjeblik at vi kan etablere (evt. ved håndkraft) en delt nøgle K ab. Dårlig ide bare at bruge K ab til alt data. I stedet bruges den som nøglekrypteringsnøgle, til at udveksle en sessionsnøgle K ses med kort levetid. 4
Sessionsnøgle K ab K ab E Kab (K ses ) E Kses (data) Med god fysisk sikkerhed til opbevaring af, kan dette være OK for en statisk, lukket gruppe af brugere. Når K ab en sjælden gang skal skiftes ud, kan det klares med håndkraft. 5
Hvem er hvem? K ab???? 6
Autentisk nøgleudveksling Nøglehierarkier K ab K ab K ab Kab K ab 7
To typer infrastruktur Secret-key-baseret Public-key-baseret 8
Key Distribution Centers (KDC) Secret-key-baseret Alle har KDC s hemmelige nøgle Man henvender sig og får en sessionsnøgle (sendes krypteret under KDC s nøgle) Systemer der bruges i praksis er fx Kerberos 9
KDC: eksempel KDC Ka, Kb, Kc, K a A: vil tale med B E Ka (K ses ) E Kb (Kses) K b E Kses (data) 10
KDC: problemer Eksemplet her er stærkt forenklet,for at vise princippet. Der er ikke gjort noget for at parterne kan checke at de taler med den rigtige, hvad med replay f.eks.? Men uanset dette, basale problemer med KDC løsningen: Man er nødt til at stole fuldstændigt på KDC, kan i princippet dekryptere alt. Hvis KDC er nede, er det hele nede. KDC løsninger ikke ret almindelige (længere). Oftest bruges public-keyteknikker i stedet. 11
Certificerings Autoriteter (CA) Public-key krypto Certifikater 12
CA: session keys Forslag? Enveloping allerede en del af public-key teknikkerne 13
Autentisk nøgledistribution Jeg Jeg er er B, B, min min offentlige offentlige nøgle nøgle er: er: pk pk B C sk C sk B E pkc E pkb (M) (M) 14
Simpel løsning: telefonbog? Der vedligeholdes en database over alle brugeres offentlige nøgler (public key s) Ok for små grupper Dårlig for store og dynamiske grupper 15
Certifikat Et certifikat, Cert A, består fundamentalt set af Ejerens ID: ID A Ejerens public-key: pk A En digital signatur fra en betroet tredjepart: CA certificerings autoriteten: S skca (ID A,pk A ) CA har også public-key par: (pk CA, sk CA ) Alle brugere har pk CA og kan derfor verificere certifikatet 16
Alice og Bob i CA-land CA pk CA, sk CA (pk A,sk A ) pk CA pk A + ID A Cert A = ID A + pk A + S skca (pk A +ID A ) pkca S ska (besked) + Cert A 17
Certifikat-intuition Man kan tænke på certifikatet som en kvittering CA udsteder til A efter at han har registreret sig som bruger. CertA er en meddelelse fra CA, der siger: jeg har talt med A, overbevist mig om at det virkelig var A jeg talte med, og det her var den offentlige nøgle han viste mig. 18
CA egenskaber Fortrolighed: sessions keys enveloping Autenticitet: Certifikat fra CA Bemærk: Alice og Bob behøver kun kende CA ens public-key, pk CA, ikke hinandens! 19
CA vs. KDC Den nødvendige tillid til en CA er anderledes end for en KDC: Man stoler på at CA en ikke udsteder certifikater under falske forudsætninger. Man CA en er ikke i stand til at dekryptere folks data, eller forfalske underskrifter Selvom CA en er midlertidigt nede, er kommunikation stadig mulig 20
Hvordan finder Alice og Bob et fælles certifikat?! Der findes mange CA er i verden I DK fx. TDC (det offentlige OCES signatursystem), eller PBS (homebanking) Internationalt: VeriSign, AT&T, etc. Etc. Kan folk med certifikater fra forskellige CA er kommunikere? CA1 kan udstede certifikat til CA2! 21
Certifikat-kæder En ordnet liste af certifikater, udstedt af CA1, CA2, CA1 autentificerer bruger A s offentlige nøgle. CA2 autentificerer CA1 s offentlige nøgle, etc.. Indtil den sidste, hvor CAn autentificerer CAn-1 s nøgle Hvis to brugere har certifikatkæder der overlapper mindst ét sted, kan de verificere hinandens nøgler 22
Certifikat-kæder: walk-through CA2 CA3 CA4 CA1 CertA CA1 CertCA1 CA2 CertCA2 CA3 CertCA3 CA4 CertCA3 CA4 Alice CertA CA1, CertCA1 CA2, CertCA2 CA3, CertCA3 CA4 S ska (besked) 23 Bob
CA egenskaber Fortrolighed: sessions keys enveloping Autenticitet: Certifikat fra CA Certifikatkæder Direkte fælles CA ikke nødvendig 24
Hvor kommer CA ens nøgle fra?! Cert CA4 hvor kommer det fra?! Vi står tilbage med det oprindelige problem: udveksling af nøgler 25
Rod-certifikat Principielt et almindeligt certifikat Underskrevet af CA en selv (pk CA,sk CA ) ID CA S skca (ID CA +pk CA ) 26
Hvor kommer rod-certifikatet fra? Internet browsere: i praksis kommer de fleste browsere med præinstallerede offentlige nøgler, i form af rodcertifikater: Distribution evt. understøttet af fingerprints Hash af public-key via en anden kanal 27
CA egenskaber Fortrolighed: sessions keys enveloping Autenticitet: Certifikat fra CA Certifikatkæder Direkte fælles CA ikke nødvendig Antagelser: (Præ-)installerede rod-certifikater 28
Hvordan bindes Alice sammen hendes nøgle? Den betroede tredjepart siger: Dette er Alices (ID Alice ) public-key Hvordan kan CA en vide det? Manuelle procedurer Fx fremmøde + forevisning af pas 29
CA egenskaber Fortrolighed: sessions keys enveloping Autenticitet: Certifikat fra CA Certifikatkæder Direkte fælles CA ikke nødvendig Antagelser: (Præ-)installerede rod-certifikater Passende procedure for udstedelse af certifikater 30
Hvad nu hvis en nøgle kompromitteres Tyveri, glemme password, Løsninger: Revokering (helst vha. on-line service) Gyldighedsperiode (ellers er do. uhåndterligt) 31
Hvordan holder vi styr på alt dette? Navn på certifikat ejer Navn på CA der udstedte certifikatet Metode anvendt af CA til at verificere ID på ejeren (flere muligheder) Udstedelses dato Gyldighedsperiode Rettigheder for certifikatejer Algoritme(r) anvendt af certifikat ejer Algoritme(r) anvendt af CA Offentlig nøgle for certifikat ejer CA ens underskrift Prædefineret format 32
X.509 De-facto standard for certificater Ufleksibel Standard opdateret flere gange Kompatibilitetsproblemer 33
Infrastruktur for nøglehåndtering Problemer ifht. levetid og autenticitet af nøgler Løses vha. sessionsnøgler og nøglehierarkier KDC (secret-key) CA (public-key) Sund praksis hver nøgle har et fast rolle og funktion nøgler bør ikke have flere funktioner: det åbner mulighed for at en angriber kunne narre systemet til at blande funktionerne sammen 34
Fundamental begrænsning Alle nøglehierarkier må ende et sted Nøgler som ikke er beskyttet kryptografisk Derfor: fysisk beskyttelse 35
Basalt problem Al kryptografisk sikkerhed er baseret på nøgler som ikke er kryptografisk beskyttet I stedet må disse nøgler beskyttes fysisk 36
Løsninger Passwords noget du ved Hardware noget du har Biometri noget du er 37
Password Et password er en sekvens af tegn som kun ejeren og systemet kender, fx QWERTY 8676 Kis#1erT$ 38
Angreb/aspekter Aspekt Valg af password Brug af password Ejers opbevaring Systemets opbevaring Angreb Gætte password Se password under brug Stjæle password fra ejer Stjæle fra systemet 39
Valg af password Nøglerum: lange passwords = mange muligheder 4-cifret PIN-kode: 10.000 muligheder Unix password: 2 52 Praktisk begrænsning Maksimalt huske 12 under stress 40
Passphrases Længde er ikke nok - kvalitet er afgørende Passphrases: Kursus i sikkerhed nummer 1 er Top-dollar Kis#1erT$ Ligeså godt som tilfældigt valgte strenge! 41
At gætte et password Forsøg (mere eller mindre intelligent) at logge på pagter indtil det lykkes Efter 3 forsøg blokeres kontoen?! Godt hvis angriberens mål er at logge ind Skidt hvis målet er at forhindre dig (og evt. andre) i at logge ind 42
Stjæle password under transmission Kikke folk over skulderen Phishing Spyware (Banker.hnq) Falsk hardware Lytte på netværk Løsninger involverer (sjovt nok) Crypto Hardware Biometri 43
At stjæle et password fra brugeren Hvis det er skrevet ned? En lap i affaldsspanden PIN-kode-husker Social engineering 44
Social engineering 336 studenter blev pr. mail bedt om at udlevere deres password for at validere password-databasen 138 returnerede deres password!!!! Mere (mindre?) sofistikerede metoder: Ringe til firmaet Benjamin : Jeg er sikkerhedschef hos IBM, jeres software har et problem (måske endda Benjamin s skyld), jeg skal bruge dit password 45
Social engineering modtræk? En af de bedste måder at bryde ind i systemer Information og uddannelse Teknik: Hardware Biometri 46
At stjæle password fra systemet Password-databasen i klartekst En udbredt metode er at gemme en kompliceret funktion af passwordet og ikke passwordet selv Men, pga. dårligt valgte passwords fejler dette også ofte 47
Password-DB vha. envejsfunktioner Tabel med indgange: u, user f(pw u ) Hvor f er en funktion som er let at beregne men svær at invertere Dvs. tabellen giver ingen direkte information om passwords 48
Dictionary attack Envejs-funktionen er kendt Tag en ordbog over sandsynlige passwords, pw Beregn f(pw) indtil der findes match Op til 25% succes-rate i praksis passphrases 49
Passwords - overblik Aspekt Angreb Modtræk Valg Gætte Dictionary Passphrases Brug Spyware, lytte på netværk, Træning Hardware, biometri, krypto Brugeropbevaring Social engineering Træning Systemopbevaring Stjæle DB Dictionary Envejsfunktioner Passphrases 50
Sikre sikkerheden Kan identifikationsmekanismen omgås? Kan man få adgang til nøgle ad omveje? Passwords :/ Beskyttelse af privat RSA-nøgle h(pw) = SHA 1 (SHA 1 (...SHA 1 (pw)...)) Hardware god beskyttelse 51
Hardware Ikke kun: øget fysisk beskyttelse mod afsløring af nøgle Men også: netop én kopi af nøgle Off-line angreb Besværliggøre kopiering Sikre opdagelse af kopiering 52
Chip-kort Som fx magnetkort, med CPU, RAM, I/O, sågar RSA co-processor Fx Dankortet, SIM-kort til mobiltelefoner, Fysisk indbrud svært! 53
Analyse af strømforbrug Naiv implementation af RSA-kryptering Scanne bits i nøgle: Hvis 0, så et forløb af instruktioner Hvis 1, så et andet Meget stor forskel i strømforbrug ved de to Aflæs strømforbrug => private-key i klartekst! 54
Tamper resistance Amerikansk standard: FIPS Skal kunne detektere Nedfrysning Rystelser Eksplosioner Magnetfelter 55
IBM 4758 (4764) Evalueret til højeste FIPSlevel Typisk brugt af banker Ingen kendte angreb (Der var tidligere et angreb baseret på en fejl i API et) 56
Autenticitet igen igen Scenario: RSA private-key i IBM4758, som kun kan tilgås hvis man har smart-card og kender PIN-koden til dette Instruer vha. downloadet software systemet om at underskrive et dokument Hvad skrives faktisk under?! 57
Hardware - overblik Beskyttelse Fortrolighed Bevis for brud på do. Angreb Dårlige API er Uforudsete sideeffekter Kontrol over både hardware og software? 58
Biometri Traditionelt: Menneske-menneske Baseret på underskrifter, fotos, etc. Her: Menneske-maskine Baseret på biologiske kendetegn BornholmsTrafikken 59
Generel løsning Funktion fra individ til data Baseret på særlige biologiske karakteristika Database herover (evt. match-on-card) Indrullering Fysisk egenskab scannes Biometriske data gemmes Identifikation Match mod database (fx politiet) Autentifikation Match mod specifikke biometriske data (egne) 60
Falske negative og positive Falsk negativ: du afvises selvom du rettelig er i systemet Falsk positiv: du godkendes selvom du ikke er i systemet Den konkrete anvendelse afgør hvad der er acceptabelt 61
Teknologier Iris-scanning Fingeraftryk Ansigtsform Håndgeometri Tale 62
Fordele og ulemper Du har altid dig selv med Privacy-problemer Beskyttelse af system Fysisk forandring af individet Bemærk: Dit fingeraftryk er ikke en signatur! Godt som element i såkaldt 2-faktor autentifikation 63
Nøglehåndtering - overblik Ubeskyttet nøgle Password (ved) Hardware (har) Biometri (er) 64