EIT060 Datasäkerhet - Projekt 2 Jacob Ferm, dt08jf0 Johan Paulsson, dt08jp8 Erik Söderqvist, dt08es8 Magnus Johansson, dt08mj9 26 februari 2011
Innehåll 1 Introduktion 1 2 SSL 1 2.1 Anslutningsprocessen......................... 1 2.2 Säkerhet................................ 2 3 Certifikat 2 3.1 CA - Certifikatauktoritet...................... 2 3.2 Autentisering............................. 3 4 Beskrivning av Outstandning Journal Delivery System (OJDS) 3 5 Säkerhetsanalys av OJDS 3 5.1 Spoofing attack............................ 4 5.2 Avlyssningsattack.......................... 4 5.3 Man-in-the-middle attack...................... 4 5.4 Förfalskade certifikat......................... 5 5.5 Denial of Service-attack....................... 5 5.6 Utomjordingar strålar upp servern till deras rymdskepp..... 6 5.7 Den mänskliga faktorn........................ 6 5.8 Sammanfattning........................... 6
1 Introduktion Denna projektrapport behandlar ämnet SSL och autentisering med certifikat.vi beskriver kortfattat grunderna i SSL samt hur en typisk anslutning fungerar. Autentisering med hjälp av certifikat behandlas även kortfattat under den första delen av rapporten. Den andra delen av rapporten inleds med en beskrivning av system som vi har implementerat. Därefter följer en säkerhetsevaluering av detta system där vi går igenom olika typer av attacker som system kan utsättas för. 2 SSL SSL, Secure Socket Layer, är ett protokoll som skapats för att möjligöra krypterat utbyte av information mellan två enheter. SSL uppfanns eftersom det saknades funktioner för säkert utbyte av information i nätverksmodellen. Protokollet arbetar mellan TCP-lagret och applikations-lagret i nätverksmodellen men det är valfritt för processer om de vill använda den extra säkerheten. Här tillhandahåller protokollet funktioner för kryptering. SSL kan också användas för att autentisera parter med varandra, förutsatt att de har en gemensam betrodd tredje part. Dess placering i nätverksmodellen ovanför TCP-lagret innebär att protokollet inte behöver hantera garanterad leverans av data eftersom detta redan görs i TCP-lagret. SSL-lagret består av två lager, SSL Record Layer och SSL Handshake Layer. Record-lagret tar hand om fragmentering och kryptering av data från överliggande lager. Den kryptering som används bestämms i Handshake-lagret. SSL används bland annat i HTTPS-protokollet som möjliggör säker kommunikation över World Wide Web samt i SMTP som används för e- post. 2.1 Anslutningsprocessen Klienten börjar med att skicka ett Client Hello-meddelande till servern för att starta handskakningen. Meddelandet innehåller först ett 28 byte stort pseudoslumptal som används senare för att beräkna Master Secret: Meddelandet innehåller även vilka olika kryptering och kompression som klienten har implementerat. Servern svarar med sitt eget Server Hello-meddelande som även det innehåller ett 28 byte stort pseudoslumptal. Servern skickar även med vilken krypterings- och kompressions-algoritm som ska användas. Servern kan även skicka sitt certifikat samt begära certifikat från klienten. En annan valfri del i meddelandet är Server Key Exchange som användes i vissa implementationer. Slutligen avslutas meddelandet med Serer Hello Done. Klienten svarar sedan med ett meddelande som innehåller Client Key Exchange, Change Cipher Spec och Finished. Meddelandet kan även innehålla information om certifikat och servern har krävt det. Innehållet i Client Key Exchange beror på vilken sorts krypteringsalgoritm som ska användas. Change Cipher Spec låter servern veta att följande meddelanden kommer krypteras enligt den algoritm som tidigare valts. Meddelandet avslutas med Finished. Servern svarar ett eget Change Cipher Spec och avslutar med Finished. Handskakningen är sedan avklarad och säker kommunikation kan nu ske. 1
2.2 Säkerhet SSL skapades för att TCP saknade vissa säkerhetsfunktioner så som krypterad autentisering, integritet- och konfidentialitetsskydd. Genom att kryptera överföringen av information ger SSL ett skydd mot avlyssning av förbindelsen. SSL skyddar mot Replay-attacker tack vare dess användning av pseudoslumptal vid handskakningen. Eftersom Finish-meddelandet innehåller ett hash-värde av den tidigare handskakningen autentiserar både servern och klienten sig för att undvika Man-in-the-middle-attacker. Genom att kräva att starka krypteringsalgoritmer måste vara implementerade för att kunna använda SSL skyddar man sig mot att klienten försöker använda äldre och möjligtvis knäckta krypteringsalgoritmer. 3 Certifikat Digitala certifikat är elektroniska dokument som används för att bekräfta en användares identitet på internet. I ett certifikat binds en pubilk nyckel ihop med en användares uppgifter som t.ex. namn och adress. 3.1 CA - Certifikatauktoritet Digitala certifikat skapas av en certifikatauktoritet (CA). Denna CA måste sedan vara betrodd av båda parter i t.ex. en banktransaktion mellan bank och användare. Varje CA sparar information så som den publika nyckeln och personuppgifter för att dessa sedan skall kunna användas i transaktioner. Alla parter som har cerifikat utgivna av samma CA litar på varandra. De största utgivarna av digitala certifikat är VeriSign Inc och GoDaddy. De har 47.5% respektive 23.4% av marknaden. Dagens webbläsare har integrerat ett antal betrodda CA som alltid går att lita på. Om en webbsida skulle använda ett certifikat som inte är signerat av någon av webbläsarens betrodda CA får användaren direkt en varning om att denne besöker en sida vars identitet inte kan verifieras. VeriSign har introducerat fem olika klasser av certifikat. Klass 1. för privatpersoner. Menat att från början användas för e-post. Klass 2. för organisationer som vill styrka sin identitet. Klass 3. för servrar och mjukvarusignering där självständig verifiering och kontroll av identitet behövs. Klass 4. för transaktioner mellan företag online. Klass 5. för privat organisationer eller statlig säkerhet. Figur 1 är en skärmdump från Nordeas webbsida. Det gröna fältet som visas innan webbadressen visar att hemsidan använder ett certifikat som är utgivet av ett CA som är betrott av webbläsaren. Om man klickar på det gröna fältet kommer det upp mer information om certifikatet vilket också syns på bilden. Informationensfönstret innehåller bland annat vad för typ av kryptering som används, mer detaljerad information om vem certifikatet är utgivet till och vilken klass certifikatet tillhör. 2
Figur 1: Skärmdump från Nordea. 3.2 Autentisering Autentisering kan ske på följande sätt då en användare ansluter till en webbplats som påstår sig ha ett utfärdat certifikat. Webbläsaren börjar med att ta emot den publika nycklen som webplatsen i fråga tillhandahåller. Webbläsaren skickar då en förfrågan till certifikatauktoriteten om denna nyckeln verkligen tillhör denna webbplats. Dock skulle en förfalskad webbplats också kunnat använda den riktiga nyckeln då denna är publik. Däremot vet inte den förfalskade sidan den privata nycklen som krävs för att dekryptera informationen som skickas. 4 Beskrivning av Outstandning Journal Delivery System (OJDS) OJDS är ett journalsystem som är implementerat i java och består av två program, en klient och en server. Fokus av systemet är att bevara konfidentialiteten av journalerna. Skriv- och läsrättigheter av journalerna måste därför kontrolleras för att ingen obehörig ska få access till dem. Autentisering sker med hjälp av certifikat som är signerade av en certifikatauktoritet som både klienten och servern litar på. Då en användare måste ha användare måste ha tillgång till en keystore och nycklen till denna keystore sker en tvåfaktorsautentisering. Anslutningen mellan klienten och servern sker med hjälp av SSL-protokollet vilket krypterar informationen som skickar mellan dem för att säkerställa att ingen obehörig tar del av journalerna. SSL används även för att autentisera parterna för varandra. 5 Säkerhetsanalys av OJDS Vi analyserar här journalsystemet OJDS som vi har implementerat. Vi listar upp olika typer av attacker och förklarar hur dem går till när ett system blir utsatt 3
för dem. Om systemet kan försvara sig mot den specifika attacken förklarar vi hur och om systemet inte har något skydd mot just den attacken så ger vi förslag på hur det hade kunnat gå att förhindra det intrånget. 5.1 Spoofing attack En spoofing attack innebär att en intet ont anande användare luras till att använda en falsk klient som ser ut precis som den riktiga. Denna klient kan därmed spara ner till exempel användarnamn och matchande lösenord som användaren skriver in. I vårt system finns inget direkt skydd mot denna typ av attacker. Om nu en användare skulle utsättas för en falsk klient skulle detta program kunna kopiera den keystore och lösenord som användes. Denna information skulle sedan kunna vidarebefordras till den som utför attacken. Ett sätt att försvara sig mot detta är att göra användarna medvetna om att det finns risk för spoofing attacker. 5.2 Avlyssningsattack Under en avlyssningsattack befinners sig den som attackerar mellan klienten och servern och avlyssnar trafiken som skickas mellan dem. Om meddelandena inte är krypterade kan attackeraren läsa allting i klartext vilket inte är acceptabelt om informationen är hemlig. Detta kan lösas genom att kryptera informationen så att attackeraren inte lika lätt kan se vad som skickas mellan dem. Detta skyddar dock inte mot trafikanalys då attackeraren istället avläser när meddelanden skickas och hur stora de är för att försöka avläsa någon hemlig information. I vårt system skyddas användarna från denna typen av attack genom att kryptera information som skickas mellan servern och klienten med hjälp av SSL-protokollet. 5.3 Man-in-the-middle attack Denna typ av attack som även kallas bucket-brigade attack är en form av avlyssningsattack. Den fungerar som så att en hacker till exempel kommer i mellan två kommunicerande parter. Hackern kan därifrån kontrollera och manipulera all information som skickas mellan parterna utan att dem har någon som helst aning om detta. Ett exempel på hur detta kan gå till är att vi har två parter som vill kommunicera, Alice och Bob. Också har vi en hacker Mallory. Till att börja med frågar Alice om Bobs publika nyckel. Om Mallory snappar upp denna nyckeln så kan en man-in-the-middle attack inledas. Mallory skickar ett ett falskt meddelande till Alice med sin publika nyckel som Alice då tror kommer från Bob. Alice använder nu Mallorys nyckel för att kryptera ett meddelande som hon sedan skickar till Bob. Återigen fångar Mallory detta meddelande och kan dekryptera det och läsa eller vad hon nu vill göra med det och sedan vidarebefordra till Bob. Nedan följer en enkel bild på hur detta kan se ut. I handshake-fasen i vårt system väljs vilken typ av kryptering som används. Detta är helt beroende på vad det finns för tillgängliga krypteringsmöjligtheter på den dator vilken klientprogrammet körs på. Vi antar att servern alltid ska ha tillgång till krypteringsalgoritmer som fungerar mot avlyssningsattacker. Dock 4
Figur 2: Illustration av man-in-the-middle attack. är det inte helt säkert att klienten har det, på skoldatorerna väljs dock alltid Diffie-Hellman i handshake-fasen. De kan därför vara viktigt att upplysa eventuella användare om att de behöver se till så att klienterna har tillgång till bra krypertingsmöjligheter för att försvara sig mot avlyssningsattacker. 5.4 Förfalskade certifikat Certifikatförfalskning innebär att hackare knäcker ett giltigt certifikats privata nycklar och på så sätt kan skapa sig ett eget CA. Detta CA kan sedan användas för att utfärda certifikat till vem som helst utan någon som helst säkerhetskontroll. CA skapade med MD5 och SHA-1 kryptering var standard fram till 2008 då en grupp säkerhetsforskare lyckades knäcka detta med hjälp av ett antal Playstation 3. Efter detta slutade bland andra Verisign att utfärda certifikat skapade med MD5. Redan utgivna certifikat återkallades dock inte vilket har resulterat i t.ex. Nordea från exemplet tidigare i texten fortfarande använder denna knäckta algoritm. Vårt system använder MD5 och SHA-1 vilket innebär att det teoretiskt sett kan utsättas för certifikatsförfalskning för att få tillgång till hemlig information. Det saknas i dagsläget bra alternativ för att skydda sig mot denna typ av attack. Dock har nyligen SHA-2 börjat användas inom USAs myndigheter. Det pågår även en tävling för nästa generations SHA kryptering. Vinnaren presenteras 2012. 5.5 Denial of Service-attack En DoS-attack är då attackeraren utnyttjar svagheter i servern eller försöker överbelasta den för att förhindra legitima användare från att få åtkomst till servern. En DoS-attack attack som utnyttjar svagheter i servern försöker få programmet att krascha genom att till exempel skicka oväntade meddelanden som servern inte kan hantera. Överbelastning sker ofta genom en så kallad DDoSattack där stora nätverk av datorer försöker ansluta till servern. Vårt system är extremt sårbart mot denna typen av attacker. Servernprogrammet krascha väldigt lätt om rätt kommandon inte anges eller om det blir något fel i autentiseringen. Servern klarar heller inte av att hantera filer som inte följer den mall vi skapat vilekt betyder att även en legitim användare skulle kunna råka krascha servern. Servern klarar av att hantera flera anslutningar 5
Figur 3: Illustration av en DDoS-attack. åt gången men det finns inget direkt skydd mot medvetna belastningsattacker. Svagheterna i servern hade gått att åtgärda om mer tid hade lagts till impementationen men eftersom det inte var huvudprioriteten med projektet anser vi att det räcker att vi är medvetna om det. 5.6 Utomjordingar strålar upp servern till deras rymdskepp Om utomjordingar kommer och strålar upp servern så har vi ingen kryptering på databasen som skulle kunna stoppa dem från att läsa journalerna. Detta anser vi vara en väldigt orealistisk händelse så vi har valt att inte implementera något skydd för detta. Foliehattar på servern är ett sätt att skydda sig mot detta om vi hade lagt mer tid på implementeringen, det är trots allt svårt att göra foliehattar. 5.7 Den mänskliga faktorn En viss utbildning hade krävts för att användarna ska kunna använda OJDS utan att krascha servern. En speciell mall på journalen måste användas för att servern ska godta den och spara ner den, i annat fall finns det en risk att servern kraschar. Det finns inga begränsningar på skrivrättigheterna på journaler, så alla som har skrivrättigheter har möjlighet att ändra all information och även ta bort innehållet i en journal. Vi har gjort så för att vi litar på att doktorer och sjukskötare som blivit autentiserade inte skulle göra så. 5.8 Sammanfattning 6