Eftersom det dök upp en del påståenden och frågor i FRA-tråden om olika metoder (både bra och mindre genomtänkta) för att uppräthålla sin integritet eller uppnå en viss grad av anonymitet på internet så tänkte jag starta en tråd om just detta.

Jag tänkte börja med en genomgång av epostsäkerhet eftersom det är det jag jobbar med.

Grundläggande säkerhet
För att komma åt sin epost på mailservern så måste man authentifiera sig. Detta gör man med ett lösenord eller (mer ovanligt) med någon annan form av hemlighet, t.ex. ett certifikat. Det viktigaste är att lösenordet är och förblir hemligt, annars kan ju vem som hellst logga in och läsa/radera din epost. Förutom det uppenbara att inte skriva ner det eller tala om det för kompisen/flickvännen/pojkvännen/whatever så behöver man även se till att det inte kan snappas upp på vägen mellan din dator och servern. Detta gör man genom att se till så att förbindelsen med servern är krypterad.

Asymertrisk kryptering
Det finns huvudsakligen två metoder att kryptera en klient-server förbindelse; SSL (Socket Security Layer) och TLS (Transport Layer Security). Båda bygger på asymetrisk kryptering med en publik och en hemlig nyckel. Servern skickar dig den publika nyckeln så att du kan kryptera och behåller den hemliga nyckeln som behövs för dekryptering. Detta har ju den uppenbara nackdelen att kommunikationen blir enkelriktad; Du kan skicka krypterad data till servern, men den kan inte svara eftersom du inte kan dekryptera utan den hemliga nyckeln. Detta löser man genom att din dator slumpar fram en symetrisk sessionsnyckel som den skickar till servern. Denna nyckel används sedan av båda parter för att både kryptera och dekryptera den fortsatta förbindelsen. Sessionsnyckeln slängs sedan när du loggar ut.

Ömsesidig authentifiering
Men, även om förbindelsen är krypterad, hur vet jag att det verkligen är min mailserver jag pratar med? Någon kan ju ha kopplat in sig i mitten och skickar mig sin egen publika nyckel. Hur vet jag att det är rätt nyckel jag får från servern?
Jo, den publika nyckeln ingår i något som kallas för ett certifikat som dessutom innehåller en signering som bara kan skapas med den hemliga nyckeln. Visserligen kan man signera sitt eget certifikat med sin egen hemliga nyckel (det kallas för ett självsignerat certifikat), men det är det ingen större vits med eftersom den inte garanterar något annat än att utfärdaren har den hemliga nyckeln. Poängen är att certifikatet ska vara signerat av någon som båda parter litar på. En Ceritificate Authority. Företag som Thawte och Verisign tar betalt för att signera certifikat och de ser också till att certifikatet lämnas ut till rätt person/organisation. Hela deras affärsidé bygger på det.

Kryptering mellan slutanvändare
Allt jag har skrivit ovan gäller bara för kommunikation mellan din dator och mailservern. Men innan mailet hamnade på din mailserver så har det antagligen bollats fram och tillbaka mellan ett antal olika servrar. Dessa förbindelser är oftast inte krypterade. Dessutom så lagras ju mailet i klartext på servern, så om man ska skicka hemligheter till varandra med epost så måste man vidta fler åtgärder.
Genom att använda PGP så kan man skapa sig ett alldeles eget publikt/hemligt nyckelpar. Den publika delen laddar med sedan upp på en nyckelserver så att andra kan komma åt den. Om någon sedan vill skicka något känsligt mail till mig så laddar han/hon ner min publika nyckel från nyckelservern och krypterar mailet med den. Efter det så är det bara jag som kan dekryptera brevet. Även om någon skulle komma åt min privata nyckel så kan denne inte använda den utan att känna till lösenordet som den är krypterat med.

Fingeravtryck och pålitlighetsnät
Det finns inga Ceritificate Authorities för PGP. I stället använder man sig av den publika nyckels fingeravtryck. Det är en sträng om 40 tecken som är känneteckande för just den nyckeln. Om Kalle vill skicka ett krypterat mail till mig, men inte vet ifall nyckeln han har fått tag på verkligen är mig så kan han ringa mig och fråga "Är det här ditt PGP-fingeravtryck?". Jag kan också ha mitt PGP-fingeravtryck på mitt visitkort som jag ger honom när vi träffas.
När Kalle väl är säker på att det är min publika nyckel han har fått tag på, då kan han signera den med sin privata nyckel och skicka den till mig. Då blir jag glad, för då har min nyckel blivit mer värd. Då vet inte bara de som personligen har verifierat min nyckel, utan även Kalles kompisar att det verkligen är min nyckel. Då ingår jag i ett pålitlighetsnät.

Hur gör man?
Hur man gör för att kryptera förbindelsen mellan sitt epostprogram och sin mailserver är granska rättframt. Man går in under inställningarna i vilket mailprogram man nu använder och kryssar för att man vill använda SSL eller TLS. Använder man SSL så måste man också ändra portnumren för epostprotokollet. Om man kör IMAP så är det port 993 i stället för 143. Om man kör POP3 så är det port 995 i stället för 110. Har man tur så kan man även få till en krypterad förbindelse för utgående post (SMTP). Då är det port 465 i stället för 25 som gäller. Kör man TLS så behöver man inte byta portnummer.

Vill man använda PGP så är det lite mer avancerat. På Unix/Linux eller modern MacOS X använder man programmet GPG (Gnu Privacy Guard).

Genererar ett nytt nyckelpar. Den kommer att fråga vad man heter, vad man har för mailadress, hur länge nyckeln ska vara giltig osv.


Nu får man fram sin publika nyckel i ASCII-format (kallas för nyckelblock). Det är den här man ska ladda upp på t.ex. keyserver.pgp.com

Om någon vill hämta min publika nyckel så är det så här man skriver


PGP har en stor nackdel: Om man tappar bort sin privata nyckel är man kokt i bajs. Då kan man inte signera någon revocation request som nyckelservrarna kräver för att ta bort den publika nyckeln och man kan inte heller dekryptera de krypterade meddelanden man får från folk som tror att nyckeln fortfarande fungerar.

Andra sätt att vara säker är tex att använda SKype.
Samtal via Skype är krypterade från användare till användare inom skype med minst 128 bitars krypto.

Trillian är en trejeparts IM, som stöder alla de stora (MSN, ICQ mm)
Där kan man köra en kryptering användare till användare, med en SecureIM. Denna fungerar dock bara på IM som kör Oscar-protokoll (ICQ och AIM).
Den implementerar en 128-bit Blowfish kryptering.

Detta är enkla sätt att kryptera sina dagliga bestyr. Dock skyddar det bara mot ren avlysning, och inte mot tex Man-in-the-middle-attacker.

Här kan jag för den avancerade kryptoanvändaren ge ett tips: OpenSSL. Med detta verktyg kan du snabbt och lätt generera nycklar och certifikat av alla de slag. Du kan kryptera, dekryptera, signera, verifiera... kort och gott allt du har intresse av. Du kan bli din egen CA, du kan utfärda SSL certifikat till din webplats, du kan göra S/MIME certifikat till din epost... the works!

Nackdelen är att det är command line-baserat... men å andra sidan finns lathundar här och var på nätet.

Projekt-siten: http://www.openssl.org/
Binaries för Windows: http://www.openssl.org/related/binaries.html

/J

Jag har tänkt gå igenom hur OpenSSL m.m. fungerar i den här tråden också. Tålamod bara.

Idag har turen kommit till säkerhet på webben. Vilka servrar man surfar till går inte att dölja, men vad man matar in (postadress, lösenord, visakortsnummer etc) och vad man får tillbaka kan krypteras. Tyvärr så kan man som användare inte själv välja krypterat/okrypterat utan det är helt upp till serversidan att avgöra det.

Tekniken
Protokollet för att överföra data på webben heter HTTP (HyperText Transfer Protocol). Om man kör HTTP med SSL-kryptering så kallas det för HTTPS (HyperText Transfer Protocol - Secure). Som jag skrev i förra posten så erbjuder SSL inte bara trafikkryptering, utan också verifiering av servern genom signaturen i certifikatet.

Kontrollera status!
Varje gång man ska skriva in känsliga uppgifter i ett webformulär som t.ex. lösenord eller visakortsnummer så bör man kontrollera säkerhetsstatus för sidan. I Firefox så klickar man på det lilla hänglåset nere i högra hörnet.
Dår får man upp en statusruta som ser ut något i den här stilen. I den övre halvan av rutan står det ifall servern verkligen är rätt server och vem som garanterar det (i det här fallet Thawte Consulting cc). I den undre halvan av rutan står det ifall sidan är krypterad och vilket krypto som används.

Bra eller dåligt krypto?
På grund av amerikansk exportlagstiftning så finns det fortfarande väldigt dåliga krypton i bruk på webben. När DES (Digital Encryption Standard) klubbades fast 1976 så var det ett krav från NSA att nycklarna inte fick vara längre än 56 bitar för att man skulle kunna knäcka dem inom rimlig tid ifall det skulle behövas. 1999 lyckades Electronic Freedom Frontier knäcka en 56-bitars DES nyckel på mindre än 24 timmar. Därför skulle jag idag inte lita på något krypto med kortare nyckel än 100 bitar. Sidan i exemplet ovan använder sig av 256-bitars AES-krypto. Det är ett bra krypto som troligtvis kommer att vara oknäckbart under överskådlig framtid. Tyvärr så använder sig min internetbank av 128-bitars krypto, vilket jag anser vara ett gränsfall. Det bir dubbelt så svårt att knäcka ett krypto för varje bit man lägger till i nyckeln.
I äldre versioner av Firefox/Mozilla kunde man stänga av alltför dåliga krypton i instälningarna. Den möjligheten verkar dock ha försvunnit i senare versioner.

Kakor
Det är inte bara när man skriver in information i ett webformulär som man kan skicka känsligt data över webben. Data som du har matat in tidigare kan sparas i din webläsare i en så kallad "kaka". Denna information kan skickas till servern om och om igen utan att man vet om det. Därför är det en bra idé att ställa in sin webläsare att inte kasta kakor omkring sig hur som hellst. Att bara skicka kakor till siten de kom ifrån är en rimlig inställning. Samma sak att inte spara kakor mellan sessioner. Så här ser de inställningarna ut i min webläsare.

Det finns stora brister i skype's protokoll bland annat är det väldigt enklet att styra trafik till dit man vill (avlyssna).
Samt att skype numer ägs av ett företag som gjärna lämnar ut allehanda uppgifter till myndigheter så fort dom får besked att det är "lagligt".

Räkna inte heller med skyddsnivån i 128-bit SSL längre.
det finns skäl att ifrågasätta styrkan i SHA-1/md5

En riktig akilleshäl när det gäller trafiksäkerhet är trådlösa nätverk (wavelan). Radiovågor kan ju vem som hellst lyssna på. Det finns dock en del mer och mindre bra sätt att skydda sin wlan-trafik.

WEP
Wired Equivalent Privacy var det första försöket att skydda trafikdatat i trådlösa nät mot avlyssning. Tyvärr så lider WEP av den del grova designmissar som gör att man med dagens teknik kan knäcka WEP-kryptering på en vanlig PC innom några minuter. Dels så skickas delar av nyckeln (initialization vector) i klartext, dels så skickar basstationen ut challenges i klartext som klienterna sedan krypterar och skickar tillbaka. Detta gör att vem som hells lätt kan få tag på ett fullständigt pålägg, dvs ett och samma meddelande i både klartext och krypterad form. Något som gör det mycket lättare att hitta nyckeln.
Dessutom bygger WEP på strömkrypto vars integritet är beroende av att man inte återanvänder nycklar. WEP återanvänder kryptonycklar.

WPA
Wi-Fi Protected Access är ett försök att åtgärda bristerna i WEP men utan att släppa på kompatabiliteten med äldra hårdvara. WPA använder samma typ av strömkrypto (RC4) som WEP, men återanvänder inte kryptonycklar. En ny nyckel genereras för varje paket enligt en teknik som kallas TKIP (Temporal Key Integrity Protocol). Det finns två authentifieringsmodeller i WPA; PSK (Pre-Shared Key) och EAP (Extensible Authentication Protocol). PSK är samma modell som används i WEP och har samma svaghet; fullständigt pålägg. EAP å andra sidan bygger på att man använder en redan existerande (och fungerande) extern två authentifieringsmodell som t.ex. Radius eller Kerberos.

WPA2
Till slut lyckades man göra ganska rätt. I WPA2 har man bytt ut RC4 mot AES. Man har även infört ett säkrare sätt att överföra en PSK som inte ger en avlyssnare tillgång till pålägg.




Vad skulle det vara för skäl? Både SHA1 och MD5 är hash-funktioner. Hashfunktioner kommer alltid att ha kollisioner.

OpenSSL är ett programpaket för kryptering, signering, verifiering m.m. OpenSSL är OpenSource och finns att ladda ner från www.openssl.org. Om man kör någon form av modern Unix (Linux, Solaris, MacOS X eller någon form av BSD) så har man antagligen redan OpenSSL installerat eftersom det behövs av i stort sett alla program som använder sig av kryptering (Firefox, Thunderbird, OpenSSH m.fl.)
I SSL så kallas den privata nyckeln för 'nyckel' och den publika nyckeln för 'certifikat'. I själva verket är den publika nyckeln bara en del av certifikatet. I de flesta fall är det dessutom underförstått att man har en (privat) nyckel som hör till certifikatet när man pratar om certifikat.

Vilken typ av certifikat behöver jag?
Om man vill skapa ett eget certifikat så är det två saker man måste bestämma sig för först: Ska nyckeln vara krypterad med lösenord? Ska man signera sitt certifikat själv eller låta en Certificate Authoroty (CA) signera det åt mig?
Om det är ett personligt certifikat du vill skapa så bör absolut nycklen vara krypterad. Det gör att även om någon lyckas komma över din privata nyckel så har de ingen användning för den såvida de inte lyckas knäcka lösenordet. Om det däremot är ett tjänstecertifikat för t.ex. en webserver är det ingen mening med att kryptera nyckeln. Då måste man ju knappa in lösenordet för hand varje gång man startar webservern.
SSL bygger på en standard som heter x509. Det är en hierarkisk modell där bara någon högre upp kan signera din nyckel och därigenom intyga att du är du. Därför är självsignerade certifikat ganska poänglösa (såvida det inte är enbart krypteringsmöjligheterna man vill åt). Tyvärr så kostar det oftast pengar att få sitt certifikat signerat. Dessutom så brukar det vara en omständig process att övertyga en CA om att man är den man utger sig för att vara.

Skapa ett certifikat

Raden ovan skapar en 1024-bitars RSA-nyckel. Det är den privata nyckeln. Den ska hållas hemlig, men den behövs för att skapa certifikatet.


Raden ovan skapar ett självsignerat certifikat med okrypterad nyckel. Flaggan '-x509' gör certifikatet till ett självsignerat certifikat. Om man utelämnar den flaggan så kommer filen mycert.pem i stället att innehålla ett Certificate Request som man kan skicka till en CA för signering. Flaggan '-nodes' skapar en okrypterad nyckel. Om man utelämnar den så kommer openssl att fråga efter ett lösenord att kryptera nyckeln med.

Testa ett certifikat

Raden ovan startar en liten dum webserver på port 4433. Starta en webläsare och peka den på 'https://localhost:4433/' så får man se lite information om sitt certifikat, t.ex vilka krypteringsmetoder den stödjer osv.

Man kan också använda openssl på komandoraden för att få fram information ur ett certifikat


Att få sitt certifikat signerat
Hur man gör beror på vilken CA man anlitar. Huvudsakligen går det till så att man surfar iväg till deras websida och klickar runt lite. Har man hittat rätt så måste man fylla i namn, epostadress och gud vet vad innan man till sist kommer till ett formulär där man kan ladda upp eller klistra in sitt certificate request. Det ska se ut ungefär så här:

Har man gjort rätt så får man tillbaka ett block med sitt signerade certifikat, antingen direkt i browsern eller via epost. Det ser ut som ovan fast utan ordet REQUEST i begin- och end-raderna.

Notera att det bara är den publika delen (certifikatet) som vi har lämnat ut till Thawte, Verisign eller vilka det nu må vara. Den hemliga delen (nyckeln) är fortfarande hemlig.

Jag har en fundering på "Pålitlighetsnät". Är inte det egentligen en så kallad "contradiction in terms"?
Jag menar att en nyckel som sprids snarare mister sitt värde (att kunna skydda text) än att värdet ökar. Risken för missutnyttjande ökar ju fler som har tillgång.

/K

Nej, eftersom den publika nyckeln (som är den man sprider) bara kan kryptera text. Man kan inte dekryptera med den. Därför tjänar jag på att min publika nyckel sprids. Ju fler som känner till den, desto fler kan skicka hemliga meddelanden till mig som bara jag (som sitter med den privata nyckeln) kan dekryptera.

Den enda form av missnyttjande som jag kan komma på så här på rak arm är ifall spammers börja kryptera sina mail med min publika nyckel innan de skickar dem till mig. På det sättet kommer de runt alla spamfiltreringnsmetoder som går efter innehållet.

Det som pålitlighetsnät (web-of-trust) är till för är att garantera äktheten hos de publika nycklarna. När jag signerar Kalles publika nyckel så sätter jag en stämpel på den att jag har kollat att det verkligen är Kalles nyckel. Om du inte känner Kalle så har du ingen aning om ifall den nyckel som du har laddat ner från en nyckelserver verkligen är Kalles. Det står hans mailadress på den, men hur vet du att det är han som hara skapat den och att han sitter med den hemliga delen av nyckeln?
Det vet du inte, men du kan se på nyckeln att jag har signerat den. Om du då känner mig och litar på mig så kan du också lite på att det är Kalles nyckel som du har fått tag på.

Det finns folk som påpekar att pålitlighetsnät kan användas för att få fram information om folks sociala nätverk. Vem som hellst kan ladda ner min publika nyckel och kan därmed se att Kalle har signerat den. Därav kan de dra slutsatsen att jag känner Kalle.

Nu när jag har gått igenom OpenSSL så tänkte jag ta och propagera för några små bra-att-ha program som bygger på OpenSSL's krypteringsbibliotek.

SSH
Secure SHell är ett protokoll för att skapa en säker (krypterad och authentifierad) anslutning till en terminalserver. Man kan authentifiera sig (logga in) på flera olika sätt beroende på vilken mjukvara servern och klienten kör. Det vanligaste är med användarnamn/lösenord, men även RSA-nyckel eller ett tunnlat protokoll som GSSAPI fungerar. SSH kan även tunnla grafik (närmare bestämt X11-protokollet) vilket gör att man kan starta ett program på fjärrservern och få upp fönstret på sin egen skärm.
Enda nackdelen med SSH är att den inte har någon fastställd metod för att verifiera den publika nyckeln. När man ansluter till en server första gången kommer klienten att visa serverns nyckels fingeravtryck och fråga ifall det stämmer. Oftast har man tyvärr ingen aning. Det går att slå upp fingeravtryck i DNS, men det är sällan som den informationen finns.
De vanligaste klienterna är OpenSSH (för Unix och MacOS X) och PuTTY (Windows)

SCP
Secure CoPy är brorsa till SSH och använder samma protokoll, men för att överföra filer i stället för komandon. Den har samma fördelar och nackdelar som SSH. SCP är att föredra framför t.ex. FTP.
Om man kör Unix eller MacOS X ingår scp i OpenSSH. Kör man Windows finns programmet WinSCP

stunnel
stunnel fungerar som en SSL-krypterad tunnel runt ett annat protokoll (nästan vilket TCP/IP-baserat protokoll som hellst). Den kan antingen köras single-ended för att klistra på SSL-stöd på en server eller klient som inte stödjer det från början eller bouble-ended för att skapa en helt transparent krypterad kanal.

rsync
Egentligen hör inte rsync hit, men eftersom den kan använda SSH som databärare så tar jag med den i alla fall. Rsync används för att synkronisera två filstrukturer. Filer som finns i den ena men inte i den andra kopieras över. Filer som finns i båda och som är identiska hoppas över (vilket gör rsync mycket effektivare än vanlig kopiering). Hur den gör med filer som finns i båda filträden, men som inte är identiska är konfigurerbart, men default är att skriva över den fil som är äldst. Rsync kopierar bara filer åt ett håll åt gången.
I normalfallet så försöker kommandot 'rsync' koppla upp sig mot en rsync-server, men när man kör den över SSH så startar den en kopia av sig själv på fjärrmaskinen. Dessutom blir överföringen krypterad om man kör den över SSH.

För att få rsync att använda SSh skriver man så här:

Både scp och rsync har samma syntax för källa och mål. Om någon av dem innehåller ett kolon så antas det som står före kolonet vara namnet på fjärrdatorn. Om namnet på fjärrdatorn dessutom innehåller ett @-tecken så antas det som står före vara användarnamnet som man loggar in på fjärrdatorn med.

Tillägg till Eskils inlägg ovan. Om man vill köra X-tunnel i ssh på MacOS X för att kunna få med grafik från server (åtminstone i 10.4 och tidigare, har inte testat 10.5 mycket än) så måste man först skaffa sig biljetter med en vanlig terminal genom att köra ssh mot server, sedan startar man X-server-fönstret och skapar ännu en uppkoppling och där man man tunnla grafiken.

Det tog oss en dryg dag att komma på det i supporten, kanske kan glädja någon

Biljetter? Menar du kerberos-biljetter? I så fall tjuvstartar du. Jag har ju inte gått igenom Kerberos här än.
Det beror (antagligen) på att du inte kan skriva i filen .Xauthority på servern.

Innan jag åker på semester så tänkte jag att det är lika bra att jag tar mig an den trehövdade besten; Kerberos.

Kerberos
Kerberos är ett säkerhetssystem som började utvecklas av MIT under slutet av åttiotalet. Det designades från början för stora organisationer som företag och universitet som är geografiskt utspridda och därför är tvugna att kommunicera över ett opålitligt internet i stället för ett intranät. Det bygger på principen "trusted third party" för att verifiera äktheten av användare och tjänster. Kerberos använder sig enbart av symetrisk kryptering, vilket gör att alla som använder Kerberos behöver en i förväg delad nyckel. Det gör dock inte så mycket eftersom Kerberos är designat att användas innom en organisation. För användare är det lösenordet (eller lösenordshashen) som är nyckeln.

Realmer och principaler
Alla användare, datorer och tjänster som delar en nyckel med en Kerberos-server sägs vara med i en realm. En realm brukar oftast ha samma namn som domänen, men skrivs alltid med versaler för att undvika sammanblandning (exempel KTH.SE).
Varje unik användare eller tjänst har ett eget namn innom sin realm. Namn och realm tillsammans skrivs som eskil@KTH.SE och kallas för principal. Användare har oftast bara en identitet, men tjänster som körs på flera datorer har instanser, t.ex imap/mail.kth.se@KTH.SE. Användare har ibland särskilda principaler som ger dem utökade rättigheter (t.ex eskil/admin@KTH.SE). Det krävs att man anger ett annat lösenord än sitt vanliga för att uppnå dessa utökade rättigheter.

Problemet med symetriska nycklar
Till skillnad från asymetriska nycklar där man glatt kan publicera sin publika nyckel för vem som hellst så måste en symetrisk nyckel hållas hemlig. Problemet är att den måste vara känd för båda parter som ska komunicera med varandra. För användare så skapas nyckeln genom att mata in lösenordet och principalen i en matematisk envägsfunktion (hash-function). Det man får ut ser ut som gallimattias, men det är inget slumpdata, utan det blir samma gallimattias varje gång. Och viktigast av allt, det går inte att vända på funktionen och få tillbaka lösenordet.
När en användare går med i en realm så måste han/hon välja ett lösenord. Hashen av det lösenordet lagras sedan i en KDC (Key Distribution Center). Där lagras även nycklar för tjänster och datorer. Eftersom alla nycklar lagras på DKC:n så är både den fysiska och den virtuella säkerheten för den datorn mycket viktig.

Att inte lita på någon
Så hur vet man att den dator man pratar med verkligen är den KDC som jag tror att den är utan att skicka nycklar eller känsliga meddelanden i klartext? Metoden kallas för handskakning och går till så här:
klientdatorn skapar ett meddelande av slumpdata som den krypterar med sin nyckel och skickar till servern. Servern dekrypterar meddelandet med sin kopia av nyckeln, men eftersom meddelandet bara är slumpdata så kan den inte veta ifall den har lyckats eller inte. Därför så utför den en i förväg fastställd reversibel funktion på datat, t.ex. vänder det baklänges och krypterar det sedan igen och skickar tillbaka det till klienten. Klienten dekrypterar meddelandet och vänder på det igen. Om datat nu är samma som det var från början så vet klienten att servern verkligen har en fungerande kopia av nyckeln. Servern gör sedan samma sak åt andra hållet för att uppnå ömsesidig authentifiering. Förfarandet kallas pre-authentification.

Biljetter
För att använda Kerberos för att authentifiera sig och skydda kommunikationen med en viss tjänst (t.ex. en mailserver) så behöver man något som kallas för en biljett. Man kontaktar sin KDC och begär att få en biljett för en viss tjänst. Man får då tillbaka ett paket som är krypterat med (KDC:ns kopia av) användarens nyckel. När man har dekrypterat det paketet så får man en sessionsnyckel som man ska använda för att kryptera kommunikationen med den begärda tjänsten samt tjänstens principal. Dessutom så hittar man ytterligen ett krypterat paket, den här gången krypterat med (KDC:ns kopia av) tjänstens nyckel. Det paketet kan vi inte dekryptera eftersom vi inte har den nyckeln, men vi kan skicka den vidare till den server som vi vill prata med. När servern dekrypterar paketet så hittar den användarens principal, IP-nummer samt en kopia av samma sessionsnyckel som användaren fick. Om IP-nummer och användarprincipal stämmer så anser servern att användaren är authentifierad. Dessutom så har både användaren och servern ny varsin kopia av en sessionsnyckel så att de kan komunicera krypterat.

Biljett-automat-biljett
En av Kerberos starkaste kort är att den erbjuder single-sign-on; Man loggar in en gång och sedan får man automatiskt tillgång till de tjänster som man har rätt till utan att behöva skriva sitt lösenord fler gånger. Det uppnår man genom att med det lösenord som användaren matar in när han/hon loggar in skaffa en biljett-automat-biljett (Ticket-granting-ticket). Den fungerar precis som vanliga biljetter som är beskrivna ovan, men den ger användaren rätt att använda biljettautomaten (Ticket-granting-service). Så länge principal och IP-nummer stämmer och paketen är krypterade med rätt sessionsnyckel så kommer man att få de biljetter man ber om.

Biljettficka och giltighetstid
De biljetter som man har hämtat ut (inklusive biljett-automat-biljetten) sparar man i en biljettficka (Credentials cache) och återvinner dem vaje gång man kontaktar samma tjänst. Hur länge biljetterna gäller på/i varje biljett och eftersom klienten inte kan dekryptera biljetterna så går det inte heller att fuska med giltighetstiden.
Så här sin min biljettficka ut just nu. Den första biljetten är min biljett-automat-biljett.


Ytterligare egenskaper
Eftersändning
För fjärrinloggning med t.ex. ssh eller telnet så går det också att använda kerberos-authentifiering, men i det fallet så erbjuder Kerberos ytterligare en trevlig egenskap; Det går att ta med sig sina biljetter till den datorn man loggar in på. Det går till så att man med sin biljett-automat-biljett begär att få en ny biljett-automat-biljetten med ett annat IP-nummer som man sedan skickar med till den server som man loggar in på. Förfarandet är naturligtvis helt automatisk, man behöver bara säga till om att man vill ha biljetterna med sig.

Förnya biljetter
Biljetterna har en begränsad livslängd för att ingen ska hinna knäcka kryptot och få tillgång till en sessionsnyckel medan den är i användning. Det gör det också svårt att stjäla biljetter ur andra användares biljettfickor efter att de har loggat ut. Men det kan vara jobbigt när biljetterna går ut när man precis håller på att använda en tjänst. Därför går det att förnya biljetter. Man använder helt enkelt så att man begär en ny biljett-automat-biljett med sin gamla innan den har gått ut. Då får man en ny sessionsnyckel på köpet, så även om någon lyckas knäcka kryptot på den gamla biljetten så fungerar inte sessionsnyckeln längre.

Biljetter utan IP-nummer
Om man sitter bakom NAT så kommer ju IP-adressen i biljetten inte att stämma överens med den adress som anslutningen ser ut att komma ifrån. Det går att lösa genom att man hämtar ut biljetter utan IP-nummer. Eftersom detta tar bort ett lager säkerhet så kan biljetter utan IP-nummer inte eftersändas eller förnyas.

Namn ur mytologin
Namnet Kerberos härstammar från grekiska mytologin och hunden med tre huvuden, Cerberus, som vaktade ingången till dödsriket Hades. Förutom det uppenbara att Kerberos precis som Cerberus ska se till att ingen obehörig släpps in så valdes namnet därför att Kerberos är baserad på tre huvudprinciper; Authentication (att verifiera identitet), Authorization (att verifiera behörighet) och Auditing (att i efterhand kunna spåra vem som gjort vad).

Eftersom amerikansk exportpolitik ett lång tag gjorde det omöjligt att exportera/distribuera Kerberos utomlands så finns det en svensk implementation av Kerberos från KTH som bär namn efter dödsrikets väktare ur nordisk mytologi: Heimdal.

Active Directory
Microsoft använder Kerberos som säkerhetssystem i de nyare inkarnationerna av Active Directory. Dessvärre så har de infört en helt ny nomenklatur
Realm = AD
KDC = Domain Controller