Säkerhetsorienterat system för webbaserad åtkomst till en P2P-backuplagring JOHN ERIKSSON

Transkript

1 Säkerhetsorienterat system för webbaserad åtkomst till en P2P-backuplagring JOHN ERIKSSON Examensarbete Stockholm, Sverige 2009

2 Säkerhetsorienterat system för webbaserad åtkomst till en P2P-backuplagring JOHN ERIKSSON Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2009 Handledare på CSC var Mads Dam Examinator var Johan Håstad TRITA-CSC-E 2009:122 ISRN-KTH/CSC/E--09/122--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Referat Säkerhetsorienterat system för webbaserad åtkomst till en P2P-backuplagring Nätverksbaserade system används allt oftare för att göra säkerhetskopior idag. BaQup är ett nyutvecklat system för att göra säkra och lagringseffektiva säkerhetskopior över Internet. System som BaQup har en stor fördel om den säkerhetskopierade datan kan kommas åt genom ett webbaserat system. Sådana system måste konstrueras med hänsyn till säkerhet och skalbarhet. Denna rapport beskriver en konstruktion av ett system för webbaserad åtkomst till BaQup-systemet. Den resulterande prototypen är en användbar utökning av BaQup-systemet, byggd för säkerhet och skalbarhet. SSL-protokollet spelar en stor roll i bevarandet av datas integritet och konfidentialitet vid överföringar. Prototypen har funktioner för att ladda ner existerande säkerhetskopior, göra nya säkerhetskopior genom att ladda upp filer och lista lagringsplatser samt säkerhetskopierade filer. Abstract Security-oriented System for Web Based Access to a P2P Backup Storage Network based systems are increasingly being used to backup data today. BaQup is a newly-developed system for making secure and storageefficient backups through the Internet. Systems like BaQup have a big advantage if the backed up data can be received through a web based system. Such systems need to be designed with security and scalability in mind. This report describes the design and implementation of a system for web based access to the BaQup system. The resulting prototype is a useful extention to the BaQup system, built for security and scalability. The SSL protocol plays an important part in ensuring data confidentiality and integrity during transfer. The prototype contains functionality for downloading existing backups, making new backups by uploading files as well as listing storage locations and backuped files.

4 Innehåll 1 Inledning Bakgrund BaQup Problemformulering Begrepp och definitioner Metod Problemdiskussion Bakgrund Datasäkerhet Konfidentialitet Integritet Tillgänglighet Hot och attacker Vanliga hot Säkerhetspolicies och -mekanismer Kryptografi RSA: Rivest, Shamir, Adleman SHA-1: Secure Hash Algorithm DES: Data Encryption Standard AES: Advanced Encryption Standard SSL: Secure Sockets Layer Certifikat PHP: Hypertext Preprocessor Nätverksbaserad säkerhetskopiering Ett återkalleligt säkerhetskopieringssytem pstore: Ett säkert peer-to-peer-säkerhetskopieringssystem Säkerhetskopiering av nycklar BaQup Grundläggande uppbyggnad BaQup-klienten Core-servern

5 3.4 Säkerhetskopiering Säkerhetsmekanismer Kryptering av data Verifiering av core-servern Verifiering av andra BaQup-klienter Användarnamn och lösenord Klientens säkerhetsprocedur BaQup-klientens funktioner Nätverksprotokoll Systemets arkitektur Specificerade krav Funktionalitet Säkerhet Skalbarhet och prestanda Avgränsningar Arkitektur Uppdelning i lager Kommunikation mellan lager Hårdvara Mjukvara Operativsystem Presentationslager Mellanlager Hantering av sessioner Användare av systemet Systemets skalbarhet Flera samtidiga kommandon Timeout Minneshantering Säkerhet Säkerhetspolicy Hotkällor Sårbarheter Säkerhetsmekanismer Kommunikation mellan användaren och presentationslagret Kommunikation mellan presentationslagret och mellanlagret Kommunikation mellan mellanlagret och core-servern Kommunikation mellan mellanlagret och vänklienter Autenticering av presentationslagret Autenticering av mellanlagret Autenticering av core-servern Autenticering av vänklienter

6 5.4.9 XSS-attacker på presentationslagret Systemintrång på mellanlagret Systemintrång på presentationslagret Risk Riskanalys Beskrivning av prototypen Presentationslagret Grundläggande uppbyggnad Sessions-id Kommunikation med mellanlager Hantering av inloggning Filer Konfiguration av webbserver Mellanlagret Grundläggande uppbyggnad Trådhantering Hantering av aktiva sessioner Kommandon Klasser Filer Prototypens gränssnitt Inloggning Listning av vänner Listning av arkiv Listning av filer Nerladdning av fil Uppladdning av fil Teknisk information Utloggning Rekommendationer 49 Litteraturförteckning 50

7 Kapitel 1 Inledning Detta kapitel ger en kort inledning och bakgrund till detta examensarbete i datalogi på CSC, KTH. 1.1 Bakgrund Säkerhetskopiering (eng. backup) innebär att göra kopior av data i förebyggande syfte. Om originalet skulle förstöras kan datan återställas till det tillstånd då den senaste säkerhetskopian gjordes. Att säkerhetskopiera data man inte vill förlora är mycket viktigt. På datorer lagras data oftast på hårddiskar. Hårddiskar kan gå sönder, och även om det oftast går att återskapa data från en kraschad hårddisk kostar det mycket både i form av tid och pengar. Oavsett vilket lagringsmedia man använder finns också en risk att t.ex. datorn blir stulen, att man råkar ut för sabotage eller att man av misstag tar bort filer. Säkerhetskopior lagrades länge typiskt på magnetband, som har en stor lagringskapacitet och låg kostnad men relativt hög åtkomsttid. Vid en hårddiskkrasch kunde datan återskapas från magnetbanden. Hårddiskarna har med tiden blivit billigare i förhållande till storleken och att säkerhetskopiera till en annan hårddisk blev ett allt populärare alternativ till magnetbanden. Om hårddisken kraschar återskapar man datan från den andra hårddisken. En lösning som automatiskt säkerhetskopierar allt innehåll på hårddisken till en annan är RAID (Redundant Array of Independent Disks). Med RAID kan två identiska hårddiskar installeras i en dator, och datan lagras sedan automatiskt på båda hårddiskarna. Användaren upplever det dock som en enda hårddisk. Med tiden har olika lagringsmedia blivit populära för säkerhetskopior: CD- och DVD-skivor, USB-minnen och olika typer av minneskort. Informationsmängden som kan lagras på sådana medier är begränsad och en säkerhetskopiering kräver manuell hantering av själva mediet. Detta kan leda till att användaren inte orkar göra säkerhetskopior tillräckligt ofta. Med ovanstående säkerhetskopieringsmetoder förvaras säkerhetskopian typiskt 1

8 KAPITEL 1. INLEDNING i nära anslutning till originaldatan. Detta skyddar bra mot hårddiskkrascher, men dåligt mot stölder, sabotage, bränder o.s.v. Idealiskt bör säkerhetskopian försvaras långt från originaldatan. Med hjälp av nätverk och speciellt Internet är detta möjligt. Nätverksbaserade säkerhetskopieringssystem är ett snabbt växande område. Sådana system kan säkerhetskopiera data till en eller flera servrar som befinner sig på långt avstånd från originaldatan. Lagringsplatsen för säkerhetskopiorna kan vara t.ex. hos en vän eller hos ett företag som erbjuder lagringsplats mot betalning. För att undvika att obehöriga läser känslig information kan datan krypteras innan den skickas iväg. Nätverksbaserade säkerhetskopieringssytem har också möjlighet att automatiskt säkerhetskopiera data, utan manuellt arbete från användaren. Detta kan göras genom att ett program körs i bakgrunden på datorn och regelbundet säkerhetskopierar data enligt användarens inställningar. 1.2 BaQup BaQup är ett nyutvecklat system för säkerhetskopiering, skapat av företaget Byteactive AB. Den som vill använda systemet installerar ett program (BaQup-klienten) på sin dator. Programmet gör sedan regelbundet säkerhetskopior till andra datorer, över Internet. Säkerhetskopieringen kan göras antingen till andra datorer med samma program installerat eller till en speciell serverversion av programmet, som drivs av en extern part som tar betalt för tjänsten. I klienten har man en lista över sina vänner, d.v.s. andra klienter som man kan använda som lagringsutrymme för sina säkerhetskopior. Säkerhetskopieringen utförs med s.k. dedupliceringsteknik, vilket innebär att data delas upp i segment, där redan skickade segment inte behöver skickas igen. Detta innebär t.ex. att om en användare har samma fil på två olika ställen behöver den bara lagras en gång på den mottagande datorn. Detsamma gäller om två olika användare har varsin kopia av samma fil. Detta kan spara stora mängder utrymme på lagringssidan och även stora mängder bandbredd, då man kan undvika att skicka onödig data. Dessutom kan datan både komprimeras och krypteras på klientsidan, vilket sparar ytterligare utrymme och gör att känslig data kan lagras på en icke-betrodd server. I dagsläget krävs att klientprogrammet installeras på en dator för att tidigare säkerhetskopierade filer ska kunna återställas. Det finns dock ett naturligt behov av att kunna komma åt sina säkerhetskopierade filer utan att installera programmet. Det kan handla om att man vill komma åt en fil från en dator på vilken man inte har rättigheter att installera nya program, eller från en dator med ett operativsystem som inte stöds av programmet. 2

9 KAPITEL 1. INLEDNING 1.3 Problemformulering Examensarbetets mål är att ta fram en prototyp till ett system för webbaserad åtkomst till BaQup-systemet. Systemet ska ha funktionalitet för att logga in med sitt användarnamn och lösenord, lista sina vänner, lista sina säkerhetskopierade filer, ladda ner sina säkerhetskopierade filer samt ladda upp nya filer som säkerhetskopior. Säkerhet är en viktig del i systemet. Utan det rätta användarnamnet och lösenordet ska ingen via detta system kunna få åtkomst till säkerhetskopierade filer eller information om dem, som t.ex. filnamn. En annan viktig del är skalbarhet. I takt med att användarantalet av systemet ökar ska det vara möjligt att sätta in extra resurser, som t.ex. nya datorer, så att systemet fungerar smidigt trots ökande belastning. 1.4 Begrepp och definitioner Denna del definierar och beskriver några av de begrepp som används i rapporten. BaQup Namnet på det system för säkerhetskopiering som utvecklats av Byteactive. Innehåller två huvudkomponenter: BaQupklienten och core-servern. BaQup-klienten Programvaran som installeras hos en användare och som används för att göra säkerhetskopior och ta emot säkerhetskopior från andra klienter. Byteactive Ett svenskt start-up-företag som utvecklat produkten BaQup. Core-servern En central server som används av alla BaQup-klienter. Används bl.a. för att hämta certifikat som autenticerar användare av BaQup-klienterna. Vän En användare av BaQup-systemet som en viss BaQup-klient kommunicerar med för att antingen säkerhetskopiera filer eller ta emot säkerhetskopior. Begreppet används både om användaren och själva klienten. 1.5 Metod Arbetet med examensarbetet delades upp i flera faser. Den första bestod av inläsning om relaterade arbeten. Inläsningen bestod främst av datasäkerhetsrelaterade rapporter och böcker. I synnerhet studerades rapporter som handlade om säkerhetsfrågor vid utveckling av webbapplikationer. Den andra delen av arbetet bestod av studier av BaQup-systemet och planering av det tänkta webbsystemets uppbyggnad och arkitektur. 3

10 KAPITEL 1. INLEDNING Den avslutande delen bestod av implementering av den framtagna arkitekturen, där först ett mellanlager utvecklades och slutligen ett presentationslager. 1.6 Problemdiskussion Examensarbetets mål är att ta fram ett webbaserat gränssnitt till ett befintligt säkerhetskopieringssystem. Ett webbaserat gränssnitt kan konstrueras på olika sätt. Det finns ett antal språk och tekniker för att konstruera dynamiska webbsidor: PHP, ASP, JSP m.fl. Systemet kan konstrueras i något av de språken och drivas som en tjänst på en server. Själva implementationen körs då på servern och endast det bearbetade resultatet skickas till användaren, som en webbsida. Olika språk har olika för- och nackdelar, men i princip är valet av språk inte särskilt viktigt. Systemet kan teoretiskt sett implementeras i sin helhet med något av de ovanstående språken, men vanligare är att dela upp lösningen i ett presentations- och ett mellanlager. Mellanlagret sköter då logiken i systemet och presentationslagret hanterar presentationen av data för användaren. Kommunikationen mellan presentations- och mellanlagret kan hanteras på olika sätt. I Java finns möjlighet att använda RMI (Remote Method Invocation) för att anropa metoder på mellanlagret direkt från presentationslagret, förutsatt att mellanlagret skrivs i Java. RMI tar då hand om dataöverföringen och stora delar av felhanteringen vid kommunikationen. En annan lösning är att använda SSL-sockets för kommunikationen med mellanlagret. Mellanlagret kan då skrivas i valfritt språk med stöd för SSL-sockets, och presentationslagret behöver inte skrivas i JSP. En helt annat alternativ till att använda någon av ovanstående tekniker är att skapa systemet som ett inbäddat program, som kan köras direkt i webbläsaren. En sådan lösning kan skapas t.ex. i Java (som en applet) eller Flash. En stor fördel med en sådan lösning är att inga extra servrar måste drivas och administreras hela implementationen körs lokalt på klientdatorn. Säkerhetsmässigt finns också fördelen att användarnamn och lösenord inte måste passera ett nytt lager. Systemet blir automatiskt mycket skalbart då ingen last placeras på något mellanlager. Klienten får dock en ökad last då den måste hantera kryptering och dekryptering av data och liknande. Det finns också flera nackdelar med en sådan lösning. Datorn som ska komma åt webbsystemet måste ha en viss programvara installerad (t.ex. Java eller Flash). Detta blir framförallt en nackdel på ställen där användaren inte har möjlighet att installera sådana program, t.ex. på ett Internetcafé eller en lånad dator. Om programmen inte redan finns installerade kan datorn inte använda systemet. Det kan också vara svårt eller omöjligt att installera sådan funktionalitet på mer simpla plattformar som mobiltelefoner och liknande. Systemet riskerar också att bli ganska stort och därmed ta en viss tid att ladda ner till klienten. Nackdelarna med en klient som körs lokalt i webbläsaren ansågs större än fördelarna och därför valdes en serverlösning för projektet. 4

11 Kapitel 2 Bakgrund Detta kapitel innehåller korta bakgrundsbeskrivningar av de metoder och tekniker som används i detta examensarbete. 2.1 Datasäkerhet Datasäkerhet är ett centralt område för detta examensarbete. Här introduceras några begrepp och vanliga hot inom datasäkerheten. Datasäkerhet kan delas in i tre huvudområden: konfidentialitet, integritet och tillgänglighet Konfidentialitet Konfidentialitet är att dölja information eller resurser [4]. En metod för att uppnå konfidentialitet är kryptografi. Kryptografin gör data oläsbar för alla som inte har tillgång till den kryptografiska nyckeln. I de flesta operativsystem finns möjlighet att sätta rättigheter på filer, vilket gör att en användare måste autenticera sig för att få läsa filen. Datan kan då ofta läsas genom att kringgå operativsystemets säkerhetsmekanismer. Till exempel kan datan läsas genom att starta datorn med ett annat operativsystem som tillåter direkt åtkomst till filerna Integritet Integritet handlar om data eller resursers trovärdighet [4]. Det är ofta viktigt att förhindra att data förändras av en attackerare eller av misstag. Integritetsmekanismer kan delas upp i förhindringsmekanismer och detekteringsmekanismer. De förstnämnda försöker förhindra att data ändras genom att blockera försök till att ändra datan. De senare försöker inte förhindra att integriteten kränks, de rapporterar bara att datan inte längre är trovärdig. 5

12 KAPITEL 2. BAKGRUND Tillgänglighet Tillgänglighet handlar om möjligheten att använda informationen eller resursen [4]. En attackerare som lyckas begränsa tillgången till ett system kan orsaka stor skada. En attack som försöker begränsa ett systems tillgänglighet kallas DoS-attack (efter eng. Denial of Service) Hot och attacker Ett hot är en potentiell kränkning av säkerheten [4]. Det räcker med att kränkningen skulle kunna inträffa för att det ska vara ett hot. Ett försök att kränka säkerheten kallas för en attack. Genom konfidentialitet, integritet och tillgänglighet försöker man hindra att säkerheten kränks. Hot kan delas in i fyra typer: disclosure (otillåten åtkomst av information), deception (accepterande av falsk data), disruption (avbrott eller hindrande av korrekt körning) och usurpation (otillåten kontroll av någon del av ett system). De vanligaste hoten passar in på någon av dessa typer Vanliga hot Snooping innebär en otillåten passiv avlyssning av information och är en form av disclosure [4]. Snooping kan typiskt ske när information överförs mellan två datorer över Internet, då informationen kan passera ett stort antal routrar. Modifikation innebär en otillåten förändring av information [4]. Modifikation kan passa in i tre olika typer av hot. Målet med attacken kan vara deception, då ett system kan fås att utföra en annan handling p.g.a. modifikationen, eller då inkorrekt information accepteras som korrekt. Spoofing innebär att någon eller något utger sig för att vara något annat och är både en typ av deception och usurpation [4]. Om en användare vill läsa en viss fil och någon har ändrat så att en annan fil visas är det en typ av spoofing. Om en användare försöker logga in på en viss dator över Internet men istället hamnar på en annan dator som utger sig för att vara samma dator är det också en typ av spoofing. Denial of Service är en form av usurpation och innebär att en attackerare hindrar en server från att erbjuda en tjänst [4] Säkerhetspolicies och -mekanismer En säkerhetspolicy är en beskrivning av vad som är tillåtet och inte tillåtet [4]. En säkerhetsmekanism är en metod, verktyg eller procedur för att verkställa säkerhetspolicyn [4]. 6

13 KAPITEL 2. BAKGRUND 2.2 Kryptografi Kryptografi handlar om att göra data oläsbar för alla utom de tänkta mottagarna. Kryptografiska funktioner kan delas in i två typer: symmetriska och asymmetriska. Symmetrisk kryptografi använder en nyckel. Med hjälp av denna nyckel kan data transformeras till oläsbar kryptotext. Med samma nyckel kan kryptotexten transformeras tillbaka till originaldatan. Asymmetrisk kryptografi (eller public key-kryptografi) innefattar två nycklar per individ: en privat nyckel som endast individen känner till samt en publik nyckel som är fri för alla att känna till. För att kryptera data avsett för en viss individ används denna individs publika nyckel. För att dekryptera denna data använder mottagaren sin privata nyckel. [5] Hashfunktioner använder ingen nyckel alls. En hashfunktion transformerar data (m) av valfri längd till en kort bitsträng av en fast längd (h(m)). En hashfunktion ska snabbt kunna räkna ut h(m) men det ska vara mycket svårt att hitta ett meddelande m som ger hashvärdet h(m) om endast hashvärdet känns till. Det ska inte finnas något enklare sätt än att testa alla möjliga kombinationer av m och beräkna h(m) för varje m. Eftersom antalet möjliga meddelanden är större än antalet möjliga hashvärden finns det flera meddelanden som ger samma hashvärde. Det ska dock vara mycket svårt (d.v.s. i praktiken omöjligt) att hitta två meddelanden som ger samma hashvärde. [5] Signaturer är ett begrepp inom asymmetrisk kryptografi. En signatur är ett tal som associeras med ett meddelande. Signaturen genereras med hjälp av signerarens privata nyckel och meddelandet som ska signeras. [5] Det resulterande talet kan sedan publiceras tillsammans med meddelandet. Vem som helst kan sedan verifiera signaturen med hjälp av meddelandet och signerarens publika nyckel RSA: Rivest, Shamir, Adleman RSA är ett asymmetriskt kryptosystem som kan använda en variabel nyckelstorlek. [17] RSA är relativt långsamt och används därför ofta i kombination med ett symmetriskt kryptosystem, där RSA används för att kryptera den symmetriska nyckeln. [5] SHA-1: Secure Hash Algorithm 1 SHA-1 är en hashalgoritm som standardiserades av NIST. SHA-1 tar ett meddelande med en längd på maximalt 2 64 bitar och producerar en 160-bitars hash. [5] En kollision hos en hashalgoritm med n bitars utdata kan alltid teoretiskt sett hittas på i genomsnitt 2 n = 2 n/2 operationer med en s.k. födelsedagsattack. I februari 2005 publicerades en attack på SHA-1 som sänkte antalet beräknade operationer innan en kollision inträffar från 2 80 till [2] År 2009 presenterades en attack med en komplexitet på endast [3] 7

14 KAPITEL 2. BAKGRUND DES: Data Encryption Standard DES är ett symmetriskt kryptosystem som standardiserades Det använder en nyckelstorlek på 56 bitar. DES nyckelstorlek är inte tillräcklig för att ge ett effektivt skydd idag. Därför används ofta 3DES, där data krypteras tre gånger efter varandra med DES-algoritmen och använder tre olika nycklar, vilket ger en nyckelstorlek på 168 bitar AES: Advanced Encryption Standard AES är ett symmetriskt kryptosystem som standardiserades Det kan använda nyckelstorlekarna 128, 192 och 256 bitar. Behovet av ett nytt symmetriskt kryptosystem fanns eftersom DES nyckelstorlek var för liten och 3DES var för långsamt. [5] 2.3 SSL: Secure Sockets Layer SSL (Secure Sockets Layer) är ett system för säker kommunikation mellan två nätverksanslutna datorer. TLS (Transport Layer Security) är uppföljaren till SSL och är i stort sett ekvivalent med SSL version 3. [5] SSL/TLS erbjuder konfidentialitet och integritetskontroll av data med hjälp av kryptografiska algoritmer. I traditionell nätverkskommunikation används sockets, som är ett programmeringsgränssnitt för att kommunicera över nätverk. En socket sätts upp på servern och binds till en viss IP-adress och port. En annan socket sätts upp på klienten som sedan används för att ansluta till serverns socket. Under anslutningen tilldelas den lokala socketen en ledig slumpmässig port. Kommunikationen sker sedan i klartext över anslutningen, oftast med TCP (Transmission Control Protocol) som protokoll. SSL låter programmeraren behålla samma system för nätverkskommunikationen. De olika funktionerna för att sätta upp sockets och ansluta till servern byts ut mot nya med inbyggd SSL-funktionalitet och sedan sköter SSL-implementationen krypterings- och autenticeringsfunktionaliteten. En SSL-anslutning inleds med att klienten skickar en handskakning till servern. Under handskakningen kommer klienten och servern överens om vilka kryptografiska algoritmer som skall användas (genom att använda en algoritm som båda sidor stödjer). Efter detta skickar servern sitt certifikat till klienten, som i sin tur verifierar certifikatet. Klienten och servern kommer sedan överens om en nyckel att använda för kryptering av datan under sessionen. Datan krypteras med en symmetrisk krypteringsalgoritm med den nyckeln. Nyckeln skapas genom att klienten genererar ett slumpmässigt tal som sedan skickas till servern krypterat med serverns publika nyckel. Från detta tal genereras sessionsnyckeln. [5] En mycket spridd och fritt tillgänglig implementation av SSL är OpenSSL. [10] 8

15 KAPITEL 2. BAKGRUND Certifikat Certifikat används i SSL för att garantera en servers identitet. Varje server har ett certifikat som skickas till klienten när anslutningen upprättas. Certifikatet består av serverns publika nyckel och information om ägaren av certifikatet, giltighetstid och serverns domännamn. För att servern ska bevisa sin identitet skickar klienten under anslutningsprocessen slumpdata som krypteras med den publika nyckeln som finns i certifikatet. För att anslutningen ska lyckas måste servern dekryptera datan med hjälp av sin privata nyckel och skicka den till klienten. På så sätt garanteras serverns identitet förutsatt att certifikatet i sig inte är förfalskat. [10] För att garantera att certifikatet i sig inte är förfalskat kan en betrodd tredje part användas. En sådan kallas ofta CA (Certificate Authority). En CA kan, efter att ha kontrollerat certifikatets äkthet, signera certifikatet med sin privata nyckel. Signaturen inkluderas sedan i certifikatet. Klienten kan sedan verifiera signaturen med hjälp av CA:ns publika nyckel. Klienten har typiskt en lista på CA:s som den väljer att lita på. Om CA:n som användes vid signeringen av certifikatet finns med i listan väljer klienten att lita på att certifikatet är äkta. Om det inte finns med accepteras det inte. I webbläsare visas typiskt ett meddelande som varnar att certifikatet är signerat av en okänd CA. Det är CA:ns uppgift att verifiera att de certifikat den signerar är äkta. En vanlig webbläsare idag har ett antal CA:s inlagda i sin lista som automatiskt accepteras. 2.4 PHP: Hypertext Preprocessor PHP [1] är ett skriptspråk som är mycket populärt för att skapa dynamiska webbsidor. Traditionella webbsidor levererar statiskt innehåll som beskrivs med HTML (Hypertext Markup Language). PHP möjliggör skapandet av mer avancerade webbsidor som ser olika ut beroende på indata från användaren. Till exempel kan webbsidan låta användaren logga in och presentera olika innehåll för olika användare. 2.5 Nätverksbaserad säkerhetskopiering Nätverksbaserade säkerhetskopieringssystem bör vara både lagringseffektiva och erbjuda starkt skydd av den säkerhetskopierade datan. Ett enkelt system uppnår detta genom att först komprimera datan på klienten, sedan kryptera den. Det är viktigt att komprimeringen utförs först, då utdata från krypteringsfunktioner typiskt innehåller mycket lite redundans och därför gör komprimeringen ineffektiv [15]. Förutsatt att en stark krypteringsalgoritm och nyckel används är datan nu säker mot obehörig läsning. Systemet kan dock fortfarande vara sårbart mot attacker som 9

16 KAPITEL 2. BAKGRUND förstör säkerhetskopiorna, t.ex. genom att ladda upp nya filer som ersätter de gamla. Det är därför också viktigt att användarna av systemet autenticeras. Då datan krypteras måste givetvis nyckeln vara tillgänglig. Nyckeln konstrueras oftast från ett lösenord. Det innebär antingen att användaren måste skriva in lösenordet varje gång en säkerhetskopiering äger rum, eller att nyckeln måste sparas i minnet. I praktiken sparar många system nyckeln på hårddisken [15], vilket gör den sårbar. Systemen kan välja att använda en eller flera nycklar för att kryptera säkerhetskopiorna. Används en enda nyckel betyder det att en förlust av den nyckeln gör alla säkerhetskopior värdelösa och att alla säkerhetskopior kan läsas om nyckeln stjäls av en obehörig. Att använda flera nycklar är mer komplicerat och svårare att underhålla Ett återkalleligt säkerhetskopieringssytem En fil som har säkerhetskopierats genom ett nätverksbaserat system kan ligga kvar länge på samma ställe. Det kan vara svårt eller omöjligt att ta bort gamla säkerhetskopior. Det kan dock vara önskvärt att ta bort gamla säkerhetskopior, t.ex. personliga e-postmeddelanden. Även om filerna är krypterade kan någon obehörig kanske komma över nyckeln i framtiden. Boneh och Lipton [7] beskriver ett återkalleligt system för säkerhetskopiering. I detta system krypteras de filer som säkerhetskopieras med en slumpmässigt genererad nyckel. När användaren vill ta bort en gammal säkerhetskopia låter han systemet glömma bort nyckeln som användes vid krypteringen. Varje fil som ska säkerhetskopieras får en krypteringsnyckel associerad till sig. Krypteringsnyckeln får även en livslängd som användaren kan kontrollera. När livslängden går ut läggs nyckeln till i en lista med gamla nycklar. När antalet gamla nycklar överstiger ett användarspecificerat maxvärde tas den äldsta nyckeln bort. På detta sätt kan användaren välja att helt ta bort säkerhetskopiorna av filen, genom att ta bort samtliga nycklar för filen. Han kan också ta bort vissa versioner av säkerhetskopian, t.ex. de som är äldre än en viss tid. Alla nycklar i systemet lagras i en nyckelfil. Varje fil som krypterats med systemet har en rad i nyckelfilen som innehåller filens namn, antal utgångna nycklar som system ska spara, livstiden för en nyckel och en lista över nycklar. Listan innehåller den aktuella nyckeln som första element och därefter de utgångna nycklarna i tidsordning. När en ny nyckel genereras flyttas alla nycklar ett steg och den äldsta nyckeln tas bort. Nyckelfilen sparas på hårddisken och skyddas så att bara privilegierade processer kan läsa den. Om nyckelfilen förloras blir all säkerhetskopierad data förlorad. Därför måste även nyckelfilen säkerhetskopieras. Den kan dock inte sparas i klartext, då det skulle vara omöjligt att permanent ta bort nycklar. I systemet krypteras därför nyckelfilen med en ny masternyckel när varje säkerhetskopiering äger rum. Nyckelfilen får en rad i sig som innehåller filnamnet på nyckelfilen. Antal nycklar sätts till 1 och livslängden för en nyckel sätts till 0 för att en ny nyckel ska genereras 10

17 KAPITEL 2. BAKGRUND varje gång, och de gamla omedelbart tas bort. Nykellistan innehåller endast en nyckel: masternyckeln. Om nyckelfilen tappas bort måste den återställas med hjälp av masternyckeln. Masternyckeln måste därför hanteras varsamt. Den enklaste hanteringen av masternyckeln är att användaren skriver ner den vid varje säkerhetskopiering och därefter förstör den gamla masternyckeln pstore: Ett säkert peer-to-peer-säkerhetskopieringssystem Batten m.fl. [6] beskriver pstore, ett säkert peer-to-peer-baserat säkerhetskopieringssystem. pstore kombinerar styrkor hos olika peer-to-peer-applikationer med versionshanterings- och säkerhetskopieringssystem. En fil representeras i pstore av flera filblock (FB) som lagras i en filblocklista (FBL). Ett filblock innehåller en del av filens data. Filblocklistan har för varje filblock en unik identifierare för filblocket, ett hashvärde av det okrypterade filblocket, längden på filblocket och positionen på filblocket i den ursprungliga filen. För varje ny version av filen får filblocklistan en ny ordnad lista av filblock. Den nya listan skapas med en algoritm baserad på rsync-algoritmen. Om den nya versionen har block som förekom i förra versionen låter man filblocklistan referera till det gamla blocket istället för att göra en kopia, vilket sparar lagringsutrymme och överföringstrafik. Filblocken krypteras med ett hashvärde av den okrypterade datans innehåll. På det sättet kan flera olika användare dela på samma filblock. Filblocklistorna är dock personliga och krypteras med en för användaren privat nyckel. Filblock och filblocklistor transporteras i peer-to-peer-nätverket som datablock C(i, p, s, d) där i är en identifierare, p är publik metadata, s är en digital signatur och d är datan. Den publika metadatan signeras med ägarens privata nyckel och ägarens publika nyckel inkluderas med varje datablock. På det sättet kan alla verifiera och läsa den publika metadatan, men endast ägaren kan ändra den. Ett FB-block C(i, p, s, d) kan beskrivas enligt: i = H(H(d) salt) p = typ i s = E p K K A(H(p)) A d = EH(F s B) (F B) Ett FBL-block C(i, p, s, d) kan beskrivas enligt: i = H(K A ) katalognamn filnamn salt p = typ tidsstämpel i H(d) s = E p K K A(H(p)) A d = Ef(E s A )(F BL) 11

18 KAPITEL 2. BAKGRUND H betecknar en hashfunktion, E p K en asymmetrisk krypteringsfunktion med nyckel K, EK s en symmetrisk krypteringsfunktion med nyckel K, K A en publik nyckel tillhörandes A, K A en privat nyckel tillhörandes A och f är en funktion som ger den symmetriska nyckeln från användarens privata nyckel. Operatorn innebär konkatenering. För FB-blocken används en hash av det krypterade innehållet som filblockidentifierare. Den kan användas för att verifiera att innehållet i filblocket inte har ändrats. Den publika metadatan för FB-blocken innehåller identifieraren och används som autenticering när FB-block tas bort. Den innehåller också en typ som anger att detta är ett FB-block och inte ett FBL-block. För FBL-blocken används en hash av användarens privata nyckel samt katalogoch filnamnet för filen som identifierare. Den publika metadatan består av en typspecificerare, en tidsstämpel, identifieraren och en hash av den krypterade datan. Hashvärdet kan användas av vem som helst för att verifiera integriteten hos datan. pstore är ett möjligt säkerhetskopieringsystem. Det finns många fler med olika styrkor och svagheter. Gemensamt för de flesta är skyddet av datan genom kryptering och uppdelningen av data i mindre block för att spara utrymme Säkerhetskopiering av nycklar Maher [14] beskriver ett system för säkerhetskopiering av kryptografiska nycklar. Med systemet kan en nyckel som används vid kryptering av ett dokument automatiskt säkerhetskopieras till en betrodd person, vilket kan vara mycket användbart inom en organisation. Den betrodda personen kan återställa nyckeln om den skulle komma bort. Det förhindrar också att t.ex. en anställd som slutar gör en fil oåtkomlig för resten av organisationen. Systemet består av sex komponenter: Betrodd backupagent. Agenten kan återställa förlorade krypteringsnycklar som genererats genom en MKV. Publik MasterKey Vector (MKV). Används för att generera krypteringsnycklar för filer. Privat MasterKey Vector (MKV). Används av backupagenten för att återställa förlorade krypteringsnycklar. En nyckel som skapas med en publik MKV kan bara återställas med dess motsvarande privata masternyckel. Backup Recovery Vectors. Publika vektorer som innehåller identiteten på backupagenten och tillräcklig information för att återställa en fils krypteringsnyckel. Krypteringsnyckelsgeneratorer. Genererar krypteringsnycklar som en funktion av slumpmässiga tal och publika MKV:er. Backup-återställningsprogram. Ett program som hjälper till med administrationen av systemet. 12

19 KAPITEL 2. BAKGRUND För att implementera systemet används asymmetrisk kryptografi. Låt f(x, r) vara en funktion som är enkel att beräkna, men svår att invertera (det är svårt att räkna ut r från värdet f(x, r) när x är känt). För två värden r 1 och r 2, f(f(x, r 1 ), r 2 ) = f(f(x, r 2 ), r 1 ). Ett exempel på en sådan funktion är f(x, r) = x r (mod p), där p är ett stort primtal. Processen kan sedan beskrivas som följer: 1. Låt r M vara den privata masternyckeln ett slumpmässigt tal genererat av backupagenten. 2. Låt y = f(x, r M ) vara den publika masternyckeln. 3. Låt id y vara en identifierare för y. 4. Låt sign(person_id, message) vara en digital signatur-funktion som binder en persons id till ett meddelande 5. Låt (y, id y, sign(a, y)) vara den publika MKV:n associerad med backupagenten med id A. 6. Låt U vara en användare av systemet 7. Låt r U vara ett tal som slumpmässigt genererats av U. 8. k = proj n (f(y, r U )) är en nyckel till en fil, där proj n extraherar de första n bitarna av sitt argument 9. b = (id A, id y, f(x, r U )) är BRV:n associerad med k. Genom funktionen f:s andra egenskap kan agenten A, men ingen annan, återställa nyckeln k från b. Programmet som hanterar systemet katalogiserar publika masternycklar så att användaren kan välja mellan dem och genererar filnycklar genom publika masternycklar. Det hanterar också krypteringen av filer, där det placerar en BRV i en header på filen som möjliggör återställande av nyckeln. Systemet kan även använda flera backupagenter. Dessa behöver då inte var för sig känna till nyckeln. Användaren väljer två publika MKV:er, en från varje agent och multiplicerar ihop dem. När användaren vill återställa sin nyckel skickas BRV:n till båda agenterna. Användaren får sedan tillbaka värdena f(f(x, r U ), r M1 ) och f(f(x, r U ), r M2 ) som multipliceras ihop och bildar nyckeln k. 13

20 Kapitel 3 BaQup BaQup är namnet på Byteactives system för säkerhetskopiering. Detta kapitel beskriver systemet och dess komponenter. 3.1 Grundläggande uppbyggnad BaQup-systemet består av två huvudkomponenter: BaQup-klienten och core-servern. BaQup-klienten installeras på användarnas datorer och programmet används sedan för att säkerhetskopiera sin data till andra BaQup-klienter. BaQup-klienten kommunicerar dels med core-servern, dels med de andra BaQupklienter som finns inlagda som vänner (figur 3.1). Figur 3.1. Enkel modell av BaQup-systemet 14

21 KAPITEL 3. BAQUP 3.2 BaQup-klienten BaQup-klienten används för att kommunicera med sina vänner (andra BaQupklienter) och är egentligen både en klient och en server. Den används dels som klient till de andra BaQup-klienterna för att ladda upp sina filer till dem, dels som server för de andra BaQup-klienterna, när de sparar sina filer till programmet. Programmet har en tillhörande konfigurationsfil där information om vilka ens vänner är sparas. Där sparas också användarens användarnamn och lösenord, och diverse programinställningar. Gränssnittet mot användaren består främst av huvudfönstret, där användarens vänner finns i en lista (och tillgängliga vänner markeras med grönt). Där finns också knappar för att göra säkerhetskopiering, återställa data och ändra inställningar (figur 3.2) Figur 3.2. Huvudfönstret på BaQup-klienten Det mesta i programmet sköts automatiskt. Programmet körs i bakgrunden och gör regelbundet (enligt önskemål) säkerhetskopior till de vänner som för tillfället är tillgängliga. Programmet är skrivet i C++ och använder biblioteket wxwidgets för de grafiska komponenterna. Nätverkskommunikationen sköts med OpenSSL-biblioteket. 3.3 Core-servern Core-servern kan beskrivas som en databas som har information om alla användares senast kända IP-nummer, lösenord och licensnycklar. Core-servern körs på en globalt åtkomlig adress och används av samtliga BaQupklienter. Om en BaQup-klient t.ex. vill kontakta en av sina vänner, kontaktas coreservern och IP-adressen till vännen hämtas därifrån. Därefter ansluter sig BaQupklienten till den IP-adressen. 15

22 KAPITEL 3. BAQUP 3.4 Säkerhetskopiering Säkerhetskopieringen sker från en BaQup-klient till en annan. Den görs oftast automatiskt, utan någon aktivitet från användaren, och med jämna mellanrum. För varje säkerhetskopiering skapas ett arkiv på den mottagande BaQup-klientens dator. Endast nya filer eller filer som ändrat innehåll behöver föras över som data. Data kan enligt önskemål konfigureras att krypteras och/eller komprimeras, på klientsidan. Därmed behöver inte den mottagande datorn få tillgång till informationen i filerna. 3.5 Säkerhetsmekanismer BaQup-systemet har ett antal säkerhetsmekanismer inbyggda för att skydda data. De flesta är byggda med hjälp av OpenSSL-biblioteket, som är en implementation av SSL (Secure Sockets Layer) Kryptering av data De filer som säkerhetskopieras kan krypteras. Algoritmen som används är 3DES och nyckeln baseras på lösenordet som användaren själv väljer. Krypteringen sker på klienten, innan datan skickas iväg till vännerna Verifiering av core-servern Core-servern är en central komponent i BaQup-systemet. Den är globalt åtkomlig över Internet, och adressen till den är statiskt specificerad i BaQup-klienten. Det är viktigt att BaQup-klienten kan vara säker på att det är den äkta coreservern den pratar med. En attackerare skulle t.ex. kunna ändra routningen eller DNS-servern så att klientdatorn istället pratar med en helt annan host. Lösningen på problemet är användningen av SSL-certifikat. Varje BaQup-klient har en kopia av Byteactives CA-certifikat. När anslutningen upprättas till coreservern, skickar core-servern sitt certifikat som är signerat av Byteactives CAcertifikat. Klienten kontrollerar därefter core-serverns certifikat med hjälp av CAcertifikatet Verifiering av andra BaQup-klienter Varje klient har ett certifikat som garanterar dess identitet. Detta certifikat fås av core-servern när BaQup-klienten startas för första gången. Klienten skickar (efter verifiering av core-serverns äkthet) sitt användarnamn och lösenord samt ett CSR (Certificate Signing Request) till core-servern. Coreservern kontrollerar användarnamnet och lösenordet mot sin databas. Om inloggningen lyckades signerar core-servern klientens CSR. Det signerade certifikatet skickas sedan tillbaka till klienten. 16

23 KAPITEL 3. BAQUP När klienten sedan har tillgång till detta certifikat kan det användas för att garantera sin identitet gentemot andra BaQup-klienter. Kontrollen sker mot Byteactives CA-certifikat. Detta gör att systemet fungerar även om core-servern inte skulle vara tillgänglig, och minskar dramatiskt belastningen på core-servern. De signerade certifikaten har en giltighetstid på en månad. När tiden gått ut måste ett nytt certifikat hämtas från core-servern Användarnamn och lösenord Alla användare av systemet har ett användarnamn (i form av en e-postadress) och ett lösenord som används för att autenticera användaren. Användaren får välja användarnamnet vid registreringen av programmet och blir då tilldelad ett lösenord som skickas med e-post. Användarnamnet används för att identifiera användaren t.ex. när vänner lägger till en lagringsplats och kan betraktas som allmänt känd information Klientens säkerhetsprocedur När BaQup-klienten startas för första gången efter en installation utförs följande operationer: 1. Klienten genererar ett RSA-nyckelpar bestående av en privat och en publik nyckel. Den privata nyckeln krypteras med 3DES-algoritmen och användarens lösenord. Den krypterade privata nyckeln sparas på hårddisken och hålls hemlig. 2. Klienten genererar ett CSR (Certificate Signing Request). 3. Klienten lokaliserar Byteactives CA-certifikat, som finns paketerat med programmet. 4. Klienten ansluter till core-servern (mot en statiskt specificerad Internetadress som via DNS översätts till en IP-adress). Klienten autenticerar core-servern med hjälp av SSL och Byteactives CA-certifikat. 5. Klienten loggar in på core-servern genom att skicka sitt användarnamn och lösenord. Informationen sänds krypterad med SSL (med en nygenererad sessionsnyckel). 6. Core-servern verifierar att användarnamnet och lösenordet stämmer. Om de inte stämmer bryts anslutningen. 7. Klienten skickar sitt CSR till core-servern. 8. Core-servern kontrollerar att CSR:en innehåller samma användarnamn som det som användes vid inloggningen. 17

24 KAPITEL 3. BAQUP 9. Core-servern signerar CSR:en från klienten och skickar det signerade certifikatet till klienten. 10. Klienten har nu ett certifikat som verifierar dess identitet. Certifikatets giltighetstid är en månad. Efter den tiden måste proceduren göras om BaQup-klientens funktioner BaQup-klientens två främsta funktioner är att säkerhetskopiera data och att på begäran återställa säkerhetskopierad data. Säkerhetskopior görs generellt sett automatiskt med jämna mellanrum, men det går även att trycka på en knapp som påbörjar säkerhetskopieringen direkt. Säkerhetskopieringen görs till alla vänner som för tillfället finns tillgängliga. Tillgängliga vänner markeras med en grön (istället för grå) symbol i vänlistan. Återställning av säkerhetskopierad data görs efter ett aktivt val från användaren. Användaren trycker på en knapp och sedan laddas listor med filer ner från alla vänner som är tillgängliga Nätverksprotokoll BaQup använder ett enkelt nätverksprotokoll. Varje meddelande som skickas börjar med 8 byte data, där de 4 första byten innehåller en meddelandekod, som talar om vilken typ av meddelande det handlar om. De andra 4 byten innehåller storleken på meddelandet i bytes (figur 3.3). Beroende på meddelandetyp ser resten av meddelandet olika ut, och tas om hand på olika sätt. Figur 3.3. Beskrivning av ett nätverksmeddelande i programkod struct NetMessage_Struct { unsigned int MessageType; unsigned int MessageLength; }; 18

25 Kapitel 4 Systemets arkitektur Detta kapitel diskuterar olika möjliga uppbyggnader av systemet för webbaserad åtkomst till BaQup samt de för- och nackdelar de olika valen har. 4.1 Specificerade krav Innan arbetet med webbsystemet påbörjades ställdes en del krav på prototypen upp. De kan delas in i funktionella krav, säkerhetskrav och skalbarhets- och prestandakrav Funktionalitet Systemet skall ha följande funktioner implementerade i sitt gränssnitt: Inloggning med hjälp av användarnamn och lösenord. Listning av sina vänner. Listning av säkerhetskopierade filer. Nerladdning av säkerhetskopierade filer. Uppladdning av filer som säkerhetskopior. Förutsatt att systemet körs på en publik webbserver skall det enda kravet för att använda tjänsten vara att användaren har ett konto i BaQup-systemet samt att denna användare har en Internetuppkoppling och en webbläsare med stöd för den krypteringsteknik som kommer att användas Säkerhet Säkerhet spelar en central roll i systemet. Det ska inte vara möjligt att få tillgång till filer eller information om filer utan ett korrekt användarnamn och lösenord. Användarnamnet och lösenordet måste skyddas så de inte kan läsas av någon obehörig. 19

26 KAPITEL 4. SYSTEMETS ARKITEKTUR Systemet ska vara konstruerat på ett sätt som undviker uppenbara säkerhetsproblem. Användarnamn och lösenord måste krypteras i kommunikationen mellan användaren och systemet, så att de inte kan avlyssnas. Användaren ansvarar själv för att sin nyckel (sitt lösenord) inte kommer bort. Om det kommer bort kan systemet inte återställa säkerhetskopiorna Skalbarhet och prestanda Systemet måste kunna stödja många samtidiga användare. Det skall vara möjligt att sätta in extra resurser (t.ex. datorer) för att förbättra prestanda om belastningen ökar till följd av ökande antal användare. Några exakta gränser på skalbarheten är inte specificerade. Systemet måste vara rimligt snabbt. En typisk användare med en vanlig dator och bredbandsuppkoppling får inte uppfatta systemet som för långsamt. 4.2 Avgränsningar Det bör noteras att de ursprungliga kraven, undantaget funktionskraven, inte är särskilt specifika. Detta examensarbete tar inte upp andra aspekter än de som finns beskrivna här. Sådant som inte diskuteras är användarvänlighet och gränssnittets utseende. Skydd mot Denial of Service (DoS)-attacker diskuteras inte heller. Fokus ligger på säkerhet och skalbarhet hos webbsystemet. Någon djupare analys eller beskrivning av själva säkerhetskopieringssystemet görs inte. 4.3 Arkitektur Den enklaste uppbyggnaden av ett fungerande system man kan tänka sig är ett där systemet består av en huvudkomponent som både hanterar kommunikationen med BaQup-systemet och kommunikationen med användaren (figur 4.1). Ett sådant system kan konstrueras med ett skriptspråk anpassat för webben. Det finns dock flera anledningar till att inte göra en sådan enkel lösning Uppdelning i lager Moderna webbapplikationer är oftast byggda enligt en princip där applikationen delas upp i separata lager (eng. multi-tier architecture). Vanligast idag är tre lager. Det översta lagret, presentationslagret, skrivs i ett dynamiskt skriptspråk anpassat för webben (t.ex. PHP). Dess uppgift är att presentera data för användaren på ett för användaren enkelt och tilltalande sätt. Det lagret kommunicerar med lagret på nivån under mellanlagret. 20

27 KAPITEL 4. SYSTEMETS ARKITEKTUR Figur 4.1. Den enklast tänkbara modellen för webbsystemet Mellanlagret tillhandahåller själva logiken i systemet. Den innehåller de funktioner som användaren sedan använder i presentationslagret. I fallet med detta webbsystem kan det t.ex. vara att lista sina vänner. Mellanlagret kommunicerar sedan med det lägsta lagret backenden. Det är ofta en databas, där stora mängder data kan lagras. I detta fall kan själva BaQupsystemet med core-servern och de olika vänklienterna ses som det lägsta lagret i systemet (figur 4.2). Figur 4.2. Ett system med två separata lager Fördelen med en sådan arkitektur är att det blir enkelt att skapa nya presentationslager, som kan ha ett helt annat utseende och låta det använda sig av mellanlagrets funktioner. Mellanlagret behöver inte ändras. Dessutom blir det svårare att förstöra grunden i systemet om man ändrar i presentationslagret. 21

28 KAPITEL 4. SYSTEMETS ARKITEKTUR En annan fördel är att man fritt kan välja programmeringsspråk på både mellanlagret och presentationslagret. Programmeringsspråk anpassade för webben har ofta sämre prestanda och är inte anpassade för att hålla data i minnet under längre tider. Presentationslagret och mellanlagret kan potentiellt köras på olika datorer. Det ger en större flexibilitet. Flera instanser av presentationslagret kan använda sig av samma mellanlagersinstans och vice versa Kommunikation mellan lager I ett system med flera lager uppstår många kommunikationsvägar mellan lagren. I tvålagersmodellen ovan uppstår följande kommunikationsvägar: 1. Mellan användarens webbläsare och presentationslagret 2. Mellan presentationslagret och mellanlagret 3. Mellan mellanlagret och core-servern 4. Mellan mellanlagret och (ett olika antal) vänklienter Genom alla dessa kommunikationsvägar transporteras känslig information. 4.4 Hårdvara Systemet kräver minst en dator för att kunna köras. Då placeras presentationslagret och mellanlagret på denna enda dator. Det gör installationen av systemet enklare. Presentationslagret och mellanlagret kan även köras på olika datorer. Det ger större flexibilitet. Presentationslagret kan potentiellt kontakta olika mellanlager som körs samtidigt vilket ger möjlighet till lastbalansering. Dessutom kan systemet fortfarande fungera om ett av mellanlagren går ner. Det kan även finnas flera presentationslager som körs på olika datorer och använder sig av samma eller olika mellanlager. Möjligheten att köra presentationslager och mellanlager på olika datorer måste därför finnas. 4.5 Mjukvara En del mjukvara behövs för att utveckla och köra systemet Operativsystem Utvecklingen av systemet kommer att ske på GNU/Linux. Systemet kommer därför i första hand att köras på detta system. GNU/Linux används ofta för serverprogram och har även fördelen att vara släppt som fri programvara. 22

29 KAPITEL 4. SYSTEMETS ARKITEKTUR Presentationslager Presentationslagret kräver en webbserverprogramvara med ett tillhörande programmeringsspråk. Apache är en populär webbserverprogramvara och PHP är ett mycket spritt programmeringsspråk för webbapplikationer. Främst på grund av deras stora spridning valdes Apache och PHP för att utveckla och köra presentationslagret Mellanlager Mellanlagret måste kunna kommunicera med BaQup-systemet samt med presentationslagret. Då BaQup-klienten och core-servern är skrivna i C++ är det naturligt att även skriva mellanlagret i detta språk. Kommunikationen mellan både presentationslagret och BaQup-systemet kräver funktionalitet för säker nätverkskommunikation. Till detta används biblioteket OpenSSL som är en fritt tillgänglig implementation av SSL/TLS. Som C++-kompilator valdes g++ i gcc-paketet (GNU Compiler Collection). Som avlusare valdes gdb och som editor emacs. Samtliga dessa programvaror ingår i en komplett GNU/Linux-distribution Hantering av sessioner En användare som loggat in i systemet har startat en session som avslutas vid utloggningen. Under denna session måste mellanlagret, som innehåller själva funktionaliteten i systemet, hålla olika typer av data och anslutningar i minnet. Presentationslagret kan antingen upprätthålla en anslutning till mellanlagret vid inloggningen som sedan hålls öppen fram till att utloggningen sker, eller öppna och stänga en anslutning för varje förfrågan till mellanlagret. Det första alternativet är svårt att implementera då en PHP-sida typiskt utför och avslutar alla kommandon innan den presenterar webbsidan för användaren. Det senare alternativet är enkelt att implementera och är därför att föredra. Presentationslagret gör då följande operationer för att utföra ett kommando: Öppna en anslutning till mellanlagret Skicka information som identifierar sessionen Skicka önskat kommando (t.ex. lista vänner) Tag emot svar (listan med vänner) Stäng anslutningen till mellanlagret 23

30 KAPITEL 4. SYSTEMETS ARKITEKTUR 4.6 Användare av systemet Webbsystemets användare är en person med ett konto i BaQup-systemet. Denna användare vill få tillgång till sina säkerhetskopior eller göra en ny säkerhetskopia av en eller flera filer. Användaren kan troligen för tillfället inte använda sin vanliga BaQup-klient. Det kan bero på att han inte har tillgång till sin vanliga dator och inte har tid eller möjlighet att installera BaQup-klienten på den tillfälliga datorn. 4.7 Systemets skalbarhet Presentationslagret och mellanlagret kan bara hantera ett visst antal samtidiga användare. Uppdelningen i lager gör att flera mellanlager kan användas av samma presentationslager. Det är viktigt att en viss session hanteras av samma mellanlager. Det är även möjligt att flera presentationslager kommer att behövas. Det enklaste sättet att fördela last över flera presentationslager är att sätta upp flera servrar och låta ett och samma domännamn peka på flera olika IP-adresser. Det finns dock inte någon garanti för att lasten blir jämnt fördelad på de olika servrarna. En något mer avancerad lösning är att koppla domännamnet till en enda IPadress där en lastbalanserare installeras. En sådan har till uppgift att vidarebefordra trafiken till olika presentationslager och fördela lasten jämnt mellan dem. Den kan hantera ett mycket stort antal förfrågningar samtidigt. Om varje presentations- och mellanlagerpar kan hantera x samtidiga användare, kan y sådana par hantera xy samtidiga användare förutsatt att lasten fördelas jämnt. n = xy (4.1) En annan faktor i skalbarheten är lasten på core-servern, som är en central komponent. För varje inloggning måste ett anrop ske till core-servern bl.a. för att hämta vännernas aktuella IP-adresser. Ur webbsystemets synvinkel är core-servern en extern komponent som antas kunna leverera tillräcklig kapacitet. För att förbättra core-serverns prestanda kan även den använda sig av lastbalansering. Det är svårt att beräkna hur många användare som kan hanteras av ett presentations- och mellanlagerspar. Många faktorer spelar in, som serverns hårdvara, systemets konfiguration, möjlig överföringshastighet till och från systemet, vad användarna förväntas göra (endast lista sina säkerhetskopior eller ladda ner stora filer?). En prestandajämförelse av PHP och JSP som presentationslager [16] visar att PHP är långsammare än JSP när enbart enkla funktioner används. För ett scenario där presentationslagret används som en Internetbank, där trafiken alltid är krypterad, kunde ungefär 700 samtidiga anrop hanteras med bra svarstider och cirka 1000 samtidiga anrop med rimliga svarstider. Servern hade en 3.4 GHz Xeon-processor och använde Linuxdistributionen Fedora Core 7 med Apache och PHP

31 KAPITEL 4. SYSTEMETS ARKITEKTUR Någon noggrann undersökning av hur många samtidiga anrop mellanlagret kan hantera har inte gjorts, men en stor del av beräkningstiden bör gå till SSL:s funktioner, precis som i presentationslagret. Övriga beräkningsintensiva funktioner är att dela upp och sätta ihop filer vid säkerhetskopiering och återställning. Beroende på hur stor del av användarna som använder systemet för säkerhetskopiering och återställning till skillnad från listning av säkerhetskopior bör antalet samtidiga anrop kunna uppgå till några hundra. 4.8 Flera samtidiga kommandon Mellanlagret måste kunna hantera flera samtidiga kommandon. Det enklaste systemet man kan tänka sig hanterar endast ett kommando åt gången och låser anslutningen till mellanlagret under tiden ett kommando utförs. Den lösningen är dock inte tillräcklig då vissa kommandon kan ta lång tid att utföra. När klienten (presentationslagret) har anslutit till mellanlagret måste hanteringen av kommandot startas i en ny process eller tråd. När denna process eller tråd har startats kan mellanlagret genast lyssna efter nya anslutningar på samma port. Fördelen med att starta en ny process för varje kommando är att om någon sådan process skulle krascha förstörs endast den processen övriga processer kan fortsätta att hantera de andra kommandona. Nackdelen är att det tar längre tid att skapa en process än en tråd. Då prestanda är en viktig faktor i systemet valdes användning av trådar för prototypen. 4.9 Timeout En användare som har loggat in har startat en session som tar upp minnesutrymme på mellanlagret. Om användaren av någon anledning inte loggar ut via presentationslagret kommer sessionen att ligga kvar på mellanlagret. Det måste därför finnas en gräns för hur länge en session ska ligga kvar på mellanlagret innan den automatiskt tas bort. Systemet måste därför hålla reda på när det senaste kommandot utfördes för en viss session. Om tiden överstiger det inställda gränsvärdet ska sessionen förstöras genom att ta bort all information om den från minnet Minneshantering Mellanlagret ska köras utan avbrott under så långa tider som möjligt för att förhindra avbrott i systemet. Detta gör att minnesläckor inte får finnas. Minnesläckor kan uppstå när ett program allokerar utrymme under programmets körning och sedan inte frigör minnet när utrymmet inte längre används. Till exempel allokeras minne för varje inloggning (då ett objekt som hanterar användarens session 25

32 KAPITEL 4. SYSTEMETS ARKITEKTUR allokeras). Detta minnesutrymme måste frigöras när användaren loggar ut, eller när en timeoutnivå är nådd (som diskuterades i förra avsnittet). 26

33 Kapitel 5 Säkerhet Webbsystemet kommer att hantera potentiellt känslig data för många olika användare och säkerhet är därför en mycket viktig del av systemet. Den känsliga datan består framför allt av de filer som transporteras genom systemet när antingen en återställning av en fil sker eller en ny säkerhetskopia av en fil laddas upp. Övrig information som transporteras genom systemet är till exempel filnamn och vännernas användarnamn. Denna information är också känslig. Låt oss utgå från den grundläggande arkitekturen i föregående kapitel och analysera vilka risker ett sådant system utsätts för. Risk är en funktion av sannolikheten att en given hotkälla utnyttjar en potentiell sårbarhet och den resulterande effekten för organisationen [9]. 5.1 Säkerhetspolicy Säkerhetspolicyn för webbsystemet är enkel. Varje användare har rätt att lista sina vänner, lista sina egna filer, ladda hem sina egna filer och ladda upp nya filer som säkerhetskopior. Användaren får inte se någon information om andra användare (förutom namnet på sina vänner). Den som driver webbtjänsten kommer teoretiskt sett att kunna göra samma sak som en användare kan (d.v.s. lista, ladda ner och ladda upp filer) för en godtycklig användare av webbsystemet. Anledningen är att användarnas användarnamn och lösenord skickas till webbsystemet. Detta förutsätter att användaren någon gång loggat in via webbsystemet. Säkerhetspolicyn för prototypen innehåller inga krav på systemets tillgänglighet. Ingen annan får lista någon användares filer, ladda ner dess filer eller ladda upp nya filer. 27

34 KAPITEL 5. SÄKERHET 5.2 Hotkällor En hotkälla kan antingen vara en avsikt och metod att utnyttja en sårbarhet eller en situation och metod som oavsiktligt kan utlösa en sårbarhet [9]. Både människor och olika omständigheter (som bränder etc.) kan alltså vara hotkällor. Låt oss titta på några av de mänskliga hotkällor som kan finnas för vårt system (tabell 5.1). Hotkälla Cracker Sabotör Bekant Tabell 5.1. Hotkällor för systemet Mål Läsa filer från en godtycklig användare Förstöra systemet på ett eller annat sätt Läsa en specifik användares filer Det finns tre huvudtyper av mänskliga hotkällor. En typ som vill komma åt en specifik användares filer, en typ som vill komma åt filer från vilken användare som helst och en typ som vill förstöra själva systemet på ett eller annat sätt. I tabellen kallas typerna cracker, sabotör och bekant. Motivet för crackern kan vara nyfikenhet eller utmaningen att knäcka systemet. Motivet för sabotören kan vara hämnd eller att vinna konkurrensfördelar. Motivet för den bekanta kan vara nyfikenhet eller möjligheten till utpressning. Det finns även en rad hotkällor som inte utgörs av människor, t.ex. åsknedslag, bränder och elavbrott. Gemensamt för dessa är att de hotar systemets tillgänglighet. 5.3 Sårbarheter En sårbarhet är en brist eller svaghet i ett systems säkerhetsprocedurer, design, implementation eller interna kontroller som kan utnyttjas och resultera i ett säkerhetshål eller en kränkning av systemets säkerhetspolicy. [9] Med utgångspunkt från den arkitektur som presenterades i förra kapitlet (utan säkerhetsmekanismer) kan en lista på sårbarheter som ett sådant system har byggas upp (tabell 5.2). Hotkällorna är de som är mest troliga. Det är t.ex. fullt möjligt för en nyfiken bekant att bryta sig in på mellanlagret för att komma över en specifik användares lösenord eller filinformation. Det är dock mer troligt att denne riktar sin attack direkt mot användaren på något sätt. 5.4 Säkerhetsmekanismer Denna del beskriver de säkerhetsmekanismer som kan installeras för att skydda mot de sårbarheter som beskrevs ovan. 28

35 KAPITEL 5. SÄKERHET Tabell 5.2. Sårbarheter i systemet Sårbarhet Hotkälla Hotaktion Kommunikation mellan användaren och presentationslagret kan avlyssnas Cracker, Bekant Passiv avlyssning Kommunikation mellan presentationslagret Cracker Passiv avlyssning och mellanlagret kan av- lyssnas Kommunikation mellan mellanlagret Cracker Passiv avlyssning och Core-servern kan avlyssnas Kommunikation mellan mellanlagret Cracker Passiv avlyssning och vänklienter kan avlyssnas Användaren autenticerar inte presentationslagret Cracker, Bekant Spoofing Presentationslagret autenticerar inte Cracker Spoofing mellanlagret Mellanlagret autenticerar inte coreservern Cracker Spoofing Mellanlagret autenticerar inte vänklienterna Cracker Spoofing Presentationslagret kan utsättas för Cracker, Bekant, Sabotör XSS XSS-attacker Känslig data kan läsas om en attackerare Cracker Systemintrång tar över mellanlagret Känslig data kan läsas om en attackerare tar över presentationslagret Cracker Systemintrång Kommunikation mellan användaren och presentationslagret All information som användaren skickar och tar emot går via presentationslagret. Beroende på var presentationslagret fysiskt är placerat går informationen mellan ett olika antal routrar som alla kan avlyssna informationen. För att hindra att utomstående kan läsa informationen i klartext kan kommunikationen krypteras med hjälp av SSL/TLS. De flesta webbserverprogram har stöd för SSL/TLS. I Apache används en modul kallad mod_ssl [11]. En förutsättning för att klienten (webbläsaren) ska kunna komma åt systemet är att den stödjer SSL/TLS. Idag har de största webbläsarna länge haft stöd för detta. Som standardinställning tillåter mod_ssl både version 2 och 3 av SSL samt TLS version 1. Dessutom tillåts en lång rad både starka och svaga krypteringsalgoritmer. SSL version 2 är en gammal version av SSL med kända säkerhetssvagheter och bör idag inte stödjas [10]. För att stänga av stöd för SSLv2 specificeras följande i konfigurationen för 29

36 KAPITEL 5. SÄKERHET mod_ssl: SSLProtocol all -SSLv2 SSLCipherSuite HIGH Den första raden talar om att alla versioner av SSL utom version 2 kan användas (d.v.s. SSLv3 och TLSv1). Den andra raden talar om att endast krypteringsalgoritmer med hög säkerhet får användas Kommunikation mellan presentationslagret och mellanlagret Om presentationslagret och mellanlagret är placerat på olika datorer kan informationen som skickas mellan dem avlyssnas. Även denna kommunikationskanal kan skyddas med SSL/TLS. I PHP finns sedan version stöd för SSL-sockets. En SSL-socket kan skapas på detta vis: fp = fsockopen("sslv3://localhost", 1917, $errno, $errstr, 10); Där första argumentet är adressen (i detta fall samma dator som presentationslagret körs på), andra argumentet är porten, tredje och fjärde argumentet är variabler för att lagra eventuella felmeddelanden och femte argumentet är en timeout i sekunder innan funktionen ger upp anslutningsförsöket. Observera att det i adressen specifikt sägs att SSL version 3 ska användas. Det är viktigt eftersom SSL version 2 har kända svagheter i säkerheten Kommunikation mellan mellanlagret och core-servern Core-servern är en central server i BaQup-systemet. Endast en instans av denna körs och är gemensam för alla användare. Mellanlagret måste kommunicera med core-servern, och även den kommunikationskanalen måste skyddas. Core-servern använder sig av SSL för säker kommunikation Kommunikation mellan mellanlagret och vänklienter Mellanlagret kommunicerar med ett okänt antal vänklienter. Samtliga dessa anslutningar måste skyddas då de transporterar känslig information. Även BaQup-klienterna använder sig av SSL för säker kommunikation Autenticering av presentationslagret Presentationslagret är användarens gränssnitt mot systemet. Det är viktigt att användaren kan lita på att presentationslagret är äkta, då användaren skickar sitt användarnamn och lösenord dit. Att lura en användare att skicka känsliga uppgifter till en falsk webbsida är ett utbrett fenomen som kallas phishing. Något effektivt skydd mot detta finns inte. Om en användare går in på en falsk webbsida och inte inser att den är falsk kan 30

37 KAPITEL 5. SÄKERHET attackeraren komma över användarnamnet och lösenordet som skrivs in. Det kan dock vara svårt att övertyga användaren om att sidan är äkta, då användaren kan notera att adressen till webbsidan inte är den vanliga. En mer sofistikerad form av bedrägeri är pharming, där en DNS-server eller router tas över och dirigerar om trafiken till en falsk webbsida. Då blir adressen densamma i webbläsaren. Autenticeringen av presentationslagret kan även den skötas med hjälp av SSL/TLS. Ett certifikat placeras hos presentationslagret som signeras med Byteactives CAcertifikat Autenticering av mellanlagret Presentationslagret använder sig av mellanlagret för att utföra olika kommandon. Presentationslagret måste verifiera att mellanlagret är äkta för att undvika attacker där ett falskt mellanlager installeras och får tillgång till användarnamn och lösenord. Den största risken i detta fall är att trafiken dirigeras om till ett falskt mellanlager. Detta falska mellanlager kan då ta emot känslig information, t.ex. användarnamn och lösenord Autenticering av core-servern Mellanlagrets kommunikation med core-servern måste autenticeras av samma anledning. Mellanlagret har en kopia av Byteactives CA-certifikat. När anslutningen till core-servern sker kontrolleras att certifikatet hos core-servern är signerat av Byteactives CA-certifikat Autenticering av vänklienter Mellanlagrets kommunikation med vänklienterna måste även de autenticeras. Varje BaQup-klient får genom BaQup-systemet ett certifikat signerat av Byteactives CAcertifikat. Mellanlagret kontrollerar att certifikatet är korrekt signerat och tillhör rätt vän XSS-attacker på presentationslagret Presentationslagret kan potentiellt utsättas för en typ av attack kallad XSS (Cross- Site Scripting). Denna typ av attacker har ökat kraftigt på webben och beror på buggar i webbapplikationerna. [8] Sårbarheter kan uppstå när webbapplikationen använder indata från klienten på ett osäkert sätt. Ett enkelt exempel på detta är följande: $tmp = $_GET[ id ]; echo "ID entered: $id<br/>"; 31

38 KAPITEL 5. SÄKERHET I koden lagras indata från användaren i variabeln tmp som sedan används i utskriften på andra raden. Denna kod är sårbar mot XSS-attacker. En attackerare kan konstruera en speciell URL och lura användaren att öppna denna. Ett exempel på en sådan URL är: När denna URL öppnas kommer texten ><script>farlig_funktion();</script> att skrivas ut av PHP. Det första tecknet (>) gör att resten av texten skrivs ut i klartext. Funktionen kommer därmed att köras av klienten. Den farligaste typen av attack stjäl sessions-id:t från klienten med hjälp av en JavaScript-funktion. Då koden ser ut att härstamma från webbapplikationen kommer JavaScript-koden att ha rättigheter att läsa den cookie som hör till webbsidan. Denna kan sedan skickas vidare till attackeraren. Med denna information kan attackeraren ta över sessionen och ladda hem användarens filer. Som skydd mot denna typ av attacker måste all indata till webbapplikationen genomgå ett filter som kontrollerar att datan är korrekt (eller åtminstone inte innehåller tecken som > och <). I PHP finns funktionen htmlentities() som gör detta. Det finns utvecklade verktyg för att automatiskt kontrollera kod för att hitta sårbarheter mot XSS-attacker, t.ex. Pixy [13] och WebSSARI [8] Systemintrång på mellanlagret En attackerare som lyckas få fullständig åtkomst till mellanlagret kan läsa data ur minnet. I minnet finns information om inloggade användares användarnamn och lösenord i klartext. De användare som inte är inloggade har sina certifikat lagrade på mellanlagret. Dessa är krypterade med användarens lösenord. En attackerare som kommer över en stor mängd certifikat har en god chans att hitta något certifikat som är krypterat med ett svagt lösenord Systemintrång på presentationslagret En attackerare som lyckas få fullständig åtkomst till presentationslagret kan även där läsa data ur minnet. Information om inloggade användares användarnamn och lösenord kan alltså stjälas. 5.5 Risk För att bedöma de risker systemet utsätts för måste först troligheten att de sårbarheter som identifierats utnyttjas av en hotkälla bedömas. NIST använder nivåerna och definitionerna i tabell 5.3. [9] Systemets sårbarheter och trolighetsnivåer finns i tabell

39 KAPITEL 5. SÄKERHET Nivå Hög Mellan Låg Tabell 5.3. Definitioner av trolighetsnivåer Definition Hotkällan är starkt motiverad och tillräckligt kapabel, och kontroller för att förhindra sårbarheten från att utövas är ineffektiva. Hotkällan är motiverad och kapabel, men kontroller är installerade som kan hindra en lyckad utövning av sårbarheten. Hotkällan har inte motivation eller kapabilitet, eller kontroller är installerade som helt eller nästan helt kan hindra sårbarheten från att utövas. Tabell 5.4. Sårbarheter och deras trolighetsnivåer Attack Kommunikation mellan användaren och presentationslagret kan avlyssnas Kommunikation mellan presentationslagret och mellanlagret kan avlyssnas Kommunikation mellan mellanlagret och Core-servern kan avlyssnas Kommunikation mellan mellanlagret och vänklienter kan avlyssnas Användaren autenticerar inte presentationslagret Presentationslagret autenticerar inte mellanlagret Mellanlagret autenticerar inte core-servern Mellanlagret autenticerar inte vänklienterna Presentationslagret kan utsättas för XSS-attacker Känslig data kan läsas om en attackerare tar över mellanlagret Känslig data kan läsas om en attackerare tar över presentationslagret Nivå Låg Låg Låg Låg Mellan Låg Låg Låg Låg Mellan Mellan Nivåerna blir naturligtvis alltid subjektiva i någon grad. Sannolikheten att någon ska kunna avlyssna data i klartext under överföringen till eller från någon del i systemet anses mycket låg, då SSL, rätt konfigurerad, anses vara en mycket effektiv säkerhetsmekanism. Även autenticeringen av de olika komponenterna sköts med SSL och anses säkra. Autenticeringen av mellanlagret är dock speciell, eftersom det är användaren av webbläsaren som själv måste välja att inte använda systemet om autenticeringen av presentationslagret misslyckas. Beroende på webbläsare är det olika svårt att ignorera den misslyckade autenticeringen. Om användaren väljer att ignorera den misslyckade autenticeringen kan inget stoppa attackeraren från att ta del av användarnamn och lösenord. Presentationslagret måste noga kontrolleras så att inga XSS-attacker görs möjliga. I prototypen är presentationslagret enkelt och tunt, och samtliga variabler som får sitt innehåll utifrån körs genom filtreringsfunktioner. Möjligheten att ta över mellanlagret och presentationslagret beror helt på konfigurationen av systemet i övrigt och är i princip inte en del av säkerhetsanalysen för detta system. Systemet måste aktivt underhållas och eventuella tjänster som körs på systemet måste uppdateras om säkerhetsluckor skulle upptäckas i dem. Så få tjänster som möjligt bör köras på systemet för att minimiera riskerna. [12] 33

40 KAPITEL 5. SÄKERHET För samtliga attacker kan motiverade hotkällor lätt hittas. För att bedöma riskerna krävs också att effekterna av ett lyckat utnyttjande av en sårbarhet bedöms. NIST använder nivåerna och definitionerna i tabell 5.5. [9] Nivå Hög Mellan Låg Tabell 5.5. Definitioner av effektnivåer Definition Utnyttjande av sårbarheten (1) kan resultera i mycket hög förlust av realtillgångar eller resurser; (2) kan starkt kränka, skada eller hindra en organisations uppdrag, rykte eller intresse; eller (3) kan resultera i mänsklig död eller allvarlig skada. Utnyttjande av sårbarheten (1) kan resultera i kännbar förlust av realtillgångar eller resurser; (2) kan kränka, skada eller hindra en organisations uppdrag, rykte eller intresse; eller (3) kan resultera i mänsklig skada. Utnyttjande av sårbarheten (1) kan resultera i viss förlust av realtillgångar eller resurser eller (2) kan märkbart påverka en organisations uppdrag, rykte eller intresse. Tabell 5.6. Sårbarheter och deras effektnivåer Sårbarhet Kommunikation mellan användaren och presentationslagret kan avlyssnas Kommunikation mellan presentationslagret och mellanlagret kan avlyssnas Kommunikation mellan mellanlagret och Core-servern kan avlyssnas Kommunikation mellan mellanlagret och vänklienter kan avlyssnas Användaren autenticerar inte presentationslagret Presentationslagret autenticerar inte mellanlagret Mellanlagret autenticerar inte core-servern Mellanlagret autenticerar inte vänklienterna Presentationslagret kan utsättas för XSS-attacker Känslig data kan läsas om en attackerare tar över mellanlagret Känslig data kan läsas om en attackerare tar över presentationslagret Nivå Mellan Mellan Mellan Mellan Mellan Mellan Mellan Låg Mellan Hög Mellan Sårbarheternas effektnivåer finns i tabell 5.6. Även dessa nivåer är subjektiva. Definitionerna ser på effekterna för organisationen (d.v.s. Byteactive) och inte en enskild användare. Att en enskild användares filer kan läsas av en attackerare innebär dock en mycket negativ effekt på organisationens rykte. När nivåerna för sårbarheternas sannolikheter och effekter bedömts kan en risknivåmatris utvecklas (tabell 5.7). Varje hots sannolikhets- och effektnivå tilldelas ett numeriskt värde. Risknivån fås genom att multiplicera dessa värden och ett högre värde står för ett större risk. Kolumnerna i tabellen anger sårbarhetens effekt och raderna anger dess trolighet. Riskvärdet r definieras som lågt för 1 r 10, mellan för 10 < r 50 och högt för 50 < r

41 KAPITEL 5. SÄKERHET Tabell 5.7. Risknivåmatris Låg (10) Mellan (50) Hög (100) Hög (1.0) Låg (10) Mellan (50) Hög (100) Mellan (0.5) Låg (5) Mellan (25) Mellan (50) Låg (0.1) Låg (1) Låg (5) Låg (10) Tabell 5.8. Sårbarheter och deras risker Sårbarhet Kommunikation mellan användaren och presentationslagret kan avlyssnas Kommunikation mellan presentationslagret och mellanlagret kan avlyssnas Kommunikation mellan mellanlagret och Core-servern kan avlyssnas Kommunikation mellan mellanlagret och vänklienter kan avlyssnas Användaren autenticerar inte presentationslagret Presentationslagret autenticerar inte mellanlagret Mellanlagret autenticerar inte core-servern Mellanlagret autenticerar inte vänklienterna Presentationslagret kan utsättas för XSS-attacker Känslig data kan läsas om en attackerare tar över mellanlagret Känslig data kan läsas om en attackerare tar över presentationslagret Risk Låg Låg Låg Låg Mellan Låg Låg Låg Låg Mellan Mellan Sårbarheternas risknivåer finns samlade i tabell Riskanalys Tre sårbarheter har en högre risknivå än den låga nivån: autenticeringen av presentationslagret och övertagningen av mellan- eller presentationslagret. Autenticeringen av presentationslagret för en högre risknivå eftersom sannolikheten för en lyckad attack anses större för just presentationslagret, då användaren själv kan välja att ignorera att autenticeringen misslyckas. Övertagning av mellan- och presentationslagret har också högre risknivåer då det finns en risk att tjänster som körs på de datorerna inte hålls uppdaterade eller konfigureras slarvigt och därmed ger möjlighet till t.ex. fjärrinloggning. Allvarligast är en övertagning av mellanlagret, då en attackerare kan komma över en stor mängd certifikat och försöka dekryptera dem. De övriga riskerna anses låga då effektiva säkerhetsmekanismer installerats som skydd. 35

42 Kapitel 6 Beskrivning av prototypen Detta kapitel beskriver den prototyp som togs fram utifrån kravspecifikationen. Figur 6.1. Modell av prototypen Systemet delades i två huvuddelar: presentationslagret, som är användarens gränssnitt mot systemet, samt mellanlagret, som sköter själva logiken i systemet (figur 6.1). Mellanlagret kommunicerar dels med core-servern, dels med andra BaQup-klienter. De andra BaQup-klienterna kan ses som backendlagret i en vanlig trelagersarkitektur. 6.1 Presentationslagret Presentationslagret skrevs i PHP och gränssnittet gjordes mycket enkelt. Först visas ett inloggningsformulär där användaren fyller i sitt användarnamn och lösenord. Efter lyckad inloggning visas en lista på sina vänner. De vänner som är online är klickbara länkar. Klickar användaren på en sådan länk visas de arkiv som finns 36

43 KAPITEL 6. BESKRIVNING AV PROTOTYPEN lagrade hos den vännen. Klickar användaren på ett arkiv visas de filer som ingår i arkivet. Klickar användaren på en fil laddas den ner genom webbläsaren. Överst på varje sida finns huvudmenyn med valen List friends, Technical information och Log out. Den tekniska informationen består i prototypen enbart av en versionssträng som hämtas från mellanlagret. Det finns också möjlighet att ladda upp filer, via en länk på sidan som visar arkiven Grundläggande uppbyggnad Presentationslagret består av ett antal olika PHP-filer. I princip finns en sådan fil för varje funktion som presentationslagret utför (t.ex. inloggning, listning av vänner, listning av arkiv o.s.v.). Det finns också två filer som inkluderas i varje sådan PHP-fil: header.php och footer.php. Den första inkluderas i början och den andra i slutet av filen. I de filerna beskrivs utseendet på webbsidan. Där inkluderas även kod för att generera ett sessions-id (session_start()) och om användaren har loggat in skapas också ett MT-objekt för kommunikation med mellanlagret Sessions-id Ett session-id är en slumpmässigt genererad sträng som används för att identifiera en session hos presentationslagret (figur 6.2). Strängen skickas från presentationslagret till klienten. I klienten lagras strängen som en cookie. När klienten sedan gör en ny anslutning till presentationslagret skickas strängen automatiskt med. PHPSESSID=rpo1hl5a03qa4emh3hdnhir735 Figur 6.2. Exempel på sessions-id Kommunikation med mellanlager För kommunikationen med mellanlagret skapades en klass med namnet MT. I denna sparas användarnamnet, lösenordet och sessions-id:t. Klassen har funktioner för att öppna en anslutning till mellanlagret (openconnection()), stänga anslutningen till mellanlagret (closeconnection()), skicka ett kommando till mellanlagret (sendcommand()) och hämta ett svar från mellanlagret (getreply()). Dessutom har varje kommando (t.ex. LOGIN) en egen funktion, som i sin tur använder sig av sendcommand(). En mer utförlig funktionslista finns i tabell Hantering av inloggning Vid första besöket på sidan får användaren ett formulär med användarnamn och lösenord att fylla i. Informationen i formulären förs sedan över via HTTP POST. När 37

44 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Tabell 6.1. Funktioner i klassen MT Funktion Beskrivning openconnection() Öppnar en SSL-anslutning till mellanlagret closeconnection() Stänger anslutningen till mellanlagret getversion() Returnerar mellanlagrets version som en sträng addfriend() Lägger till en vän i listan receivefriends() Tar emot listan över vänner, returnerar en array isfriendonline() Kontrollerar om en vän är online, returnerar true/false downloadfile() Laddar ner en fil uploadfile() Laddar upp en fil listfilesinarchive() Tar emot listan över filer i ett arkiv, returnerar en array listarchives() Tar emot listan över arkiv, returnerar en array login() Loggar in, returnerar true/false sendcommand() Skickar ett kommando till mellanlagret getreply() Tar emot ett svar från mellanlagret denna överföring sker är det mycket viktigt att SSL/TLS används för att undvika att informationen avlyssnas. När presentationslagret tar emot informationen via HTTP POST sätts motsvarande information som sessionsvariabler. Ett MT-objekt skapas sedan för kommunikationen med mellanlagret. På detta objekt körs funktionen login() som returnerar true vid lyckad inloggning och f alse vid misslyckad. Beroende på resultatet av funktionen anses inloggningen antingen lyckad eller ej Filer Detta avsnitt beskriver de PHP-filer som ingår i presentationslagret. För samtliga filer inkluderas header.php (och i förlängningen mt.php) i början och footer.php i slutet. Genom header-filen kontrolleras först att en session är aktiv. Om ingen session är aktiv visas istället inloggningsformuläret. archive.php Filen archive.php visar filer i ett arkiv med hjälp av funktionen listfilesin- Archive() i MT-objektet. file.php Filen file.php används för att ladda ner en fil med hjälp av funktionen download- File() i MT-objektet. Med hjälp av funktionen header() i PHP sätts typen till application/octet-stream och kan laddas ner via webbläsaren: header("content-disposition: attachment; filename=$filename"); header("content-type: application/octet-stream"); 38

45 KAPITEL 6. BESKRIVNING AV PROTOTYPEN header("content-length: ".$filesize); header("pragma: no-cache"); header("expires: 0"); Variablerna filename och filesize innehåller filens namn och storlek. Efter detta hämtas filens innehåll från mellanlagret. index.php Filen index.php används för att lista vänner. När en viss vän valts används samma fil även för att lista arkiven som finns hos den vännen. Listningen av vänner görs via funktionen receivefriends() och listningen av arkiv görs via listarchives(). logout.php Filen logout.php förstör sessions-id:t genom att först köra session_regenerate_id() och därefter session_destroy(), och visar därefter ett meddelande som informerar om att användaren har loggat ut. putfile.php Filen putfile.php används för att ladda upp en fil som en säkerhetskopia. Överföringen till presentationslagret sker via PHP:s inbyggda filöverföringsfunktioner. Efter att presentationslagret tagit emot filen förs sedan filen över till mellanlagret via SSL-sockets. techinfo.php Filen techinfo.php visar teknisk information, som i prototypen enbart är versionssträngen från mellanlagret. Versionssträngen hämtas med funktionen getversion() Konfiguration av webbserver Som webbserver användes Apache. För att erhålla konfidentialitet och integritet på kommunikationen mellan presentationslagret och användaren måste Apache konfigureras för att används SSL/TLS (se Kontrollmetoder i säkerhetskapitlet). 6.2 Mellanlagret Mellanlagret är systemets största komponent. Den är skriven i C++ och använder ett antal något modifierade komponenter från BaQup-klienten. Kommunikationen med core-servern och andra BaQup-klienter sker via SSL-sockets och med ett redan utvecklat protokoll. Mellanlagret döptes till baqupcommd BaQup Communication Daemon. 39

46 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Grundläggande uppbyggnad Mellanlagret består av en huvudfunktion och litet antal viktiga klasser: instance, cs_comm och storage_comm (figur 6.3). Klassen instance beskriver en session och har till exempel information om användarnamn, lösenord och vilka vänner som användaren har. Klassen cs_comm används för att kommunicera med core-servern och klassen storage_comm för att kommunicera med användarens vänner. Huvudfunktionen initierar SSL och sätter upp en SSL-socket att lyssna på en förinställd port. När en anslutning upprättats startas en tråd att ta hand om anslutningen. Tråden väntar på att klienten ska skicka sitt sessionsnummer. När sessionsnumret tagits emot kontrolleras om en session med detta sessionsnummer redan är aktiv. Om så är fallet tas ett gammalt instance-objekt fram, i annat fall skapas ett nytt instance-objekt. Efter detta körs funktionen readcommand() på objektet, som tar emot kommandot, utför det, och skickar svaret till klienten. Figur 6.3. Mellanlagrets grundläggande uppbyggnad Trådhantering När en klient anslutit sig körs funktionen pthread_create(), som i sin tur startar en tråd och utför funktionen thread(). I thread() startas först SSL-funktionerna via SSL_accept(), sedan läses sessions-id:t in Hantering av aktiva sessioner Det finns två globala variabler för att hantera de aktiva sessionerna: myinstances och myinstancemap. Den förstanämnda är en std::vector som innehåller pekare till samtliga aktiva instance-objekt. Den andra är en std::map som knyter sessionsnumret till rätt instance-objekt. 40

47 KAPITEL 6. BESKRIVNING AV PROTOTYPEN När sessions-id:t tagits emot från klienten kontrolleras om det finns inlagt som nyckel i myinstancemap. Om det inte finns läggs det in i myinstancemap och myinstances. Med jämna mellanrum görs en kontroll över hela myinstances-vektorn, där alla instance-objekts tidsstämplar gås igenom. Om tidsstämpeln skiljer sig mer än ett gränsvärde från den aktuella tiden tas objektet bort Kommandon Mellanlagret har funktionalitet för att hantera ett antal olika kommandon (tabell 6.2). Vanligen skickas dessa kommandon från presentationslagret som också läser av svaret som mellanlagret skickar. Hanteringen av kommandona finns i funktionen readcommand() som är en del av instance-klassen. Tabell 6.2. Kommandon i mellanlagret Kommando Parametrar Svar LOGIN LISTFRIENDS Användarnamn Lösenord Bool Antal [Användarnamn, Bool] Antal ISFRIENDONLINE Användarnamn Bool LISTARCHIVES LISTFILESINARCHIVE DOWNLOADFILE UPLOADFILE Användarnamn Användarnamn Arkiv Filmönster Katalogmönster Användarnamn Arkiv Användarnamn Filnamn Filstorlek Antal [Arkiv] Antal Antal [Filnamn, Filstorlek] Antal Fil Bool ADDFRIEND Användarnamn Bool VERSION - Version 41

48 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Varje kommando skickas som en textsträng med enbart versaler. Strängen avslutas med en ny rad. Eventuella argument skickas sedan rad för rad. Alla argument skickas som strängar men konverteras i programmet till rätt typ (t.ex. till heltal). Parametrarnas datatyper finns angivna i tabell 6.3. Parameter Användarnamn Lösenord Antal Arkiv Version Bool Tabell 6.3. Parametrarnas datatyper Typ Sträng Sträng Heltal Heltal (UNIX-tid) Sträng Sträng Svar med flera rader har hakparenteser runt sig. [Arkiv] Antal betyder till exempel att a rader med heltal som beskriver arkiv skrivs ut, där a 0 är ett heltal Klasser instance Klassen instance hanterar en användares session. Efter att en klient kopplat upp sig till baqupcommd och skickat sitt sessionsnummer tas rätt instance-objekt fram. I denna klass finns alla kommandon mot baqupcommd specificerade. Funktionen readcommand() väntar på ett kommando från klienten som skickar ett definierat kommando till funktionen. Funktionen readcommand() kör i sin tur en ny funktion för att hantera kommandot. Om t.ex. användaren skickar kommandot LOGIN kommer readcommand() att läsa strängen, känna igen det kända kommandot och därefter köra funktionen cmdlogin(). Funktionen cmdlogin() kommer i sin tur att läsa in de argument som kommandot kräver (i detta fall användarnamn och lösenord) rad för rad. När alla argument lästs in körs någon kod (i detta fall kontaktas core-servern för verifiering av användarnamnet och lösenordet). Beroende på resultatet skickas sedan SUCCESS eller FAIL tillbaka till klienten. En översikt av de viktigaste funktionerna i klassen finns i tabell 6.4. cs_comm Klassen cs_comm hanterar all kommunikation med core-servern. När t.ex. kommandot cmdlogin() körs i instance-objektet skapas där ett cs_comm-objekt med användarnamn och lösenord som instance-objektet har lagrat. Därefter körs kommandot login() på cs_comm-objektet. Detta kommando upprättar en anslutning till core-servern och utbyter information enligt ett fastställt protokoll. Resultatet (true eller false) returneras sedan. 42

49 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Tabell 6.4. Funktioner i klassen instance Funktion Beskrivning cmdlogin() Hanterar kommandot LOGIN cmdversion() Hanterar kommandot VERSION cmdlistfriends() Hanterar kommandot LISTFRIENDS cmdisfriendonline() Hanterar kommandot ISFRIENDONLINE cmdlistarchives() Hanterar kommandot LISTARCHIVES cmddownloadarchive() Hanterar kommandot DOWNLOADARCHIVE cmdlistfilesinarchive() Hanterar kommandot LISTFILESINARCHIVE cmduploadfile() Hanterar kommandot UPLOADFILE cmdaddfriend() Hanterar kommandot ADDFRIEND addfriend() Lägger till en vän i listan över vänner getline() Hämtar en rad från klienten readcommand() Läser ett kommando från klienten sendcommand(string) Skickar ett svar av typen string sendcommand(bool) Skickar ett svar av typen bool sendcommand(int) Skickar ett svar av typen int sendcommand(long long) Skickar ett svar av typen long long En annan funktion i cs_comm är getfrienddata(), som hämtar en väns senast kända IP-adress. En översikt av de viktigaste funktionerna kan ses i tabell 6.5 Funktion getfrienddata() createkeys() createcsr() reqcertsign() readdata() writedata() sendmessage() getmessage() getreturncode() connecttocs() login() Tabell 6.5. Funktioner i klassen cs_comm Beskrivning Hämtar en väns senast kända IP-adress Skapar ett nyckelpar och krypterar den privata nyckeln med 3DES och användarens lösenord Skapar ett CSR (Certificate Signing Request) Skickar CSR till core-servern och tar emot det signerade certifikatet Läser data från core-servern Skriver data till core-servern Skickar ett meddelande till core-servern enligt protokollet Tar emot ett meddelande från core-servern enligt protokollet Tar emot en returkod från core-servern enligt protokollet Upprättar en SSL-anslutning till core-servern Loggar in på core-servern storage_comm Klassen storage_comm hanterar all kommunikation med andra BaQup-klienter. Här finns funktionerna för att lista arkiv, lista filer i arkiv, ladda upp och ner filer samt 43

50 KAPITEL 6. BESKRIVNING AV PROTOTYPEN kontrollera om en vän är online. Det är den största enskilda klassen i mellanlagret. En översikt av de viktigaste funktionerna finns i tabell 6.6. Funktion initremotehost() listarchives() downloadfile() createnewarchive() restoreandsendfile() backupdir() backupfile() listfilesinarchive() downloadarchive() readdata() writedata() openconnection() closeconnection() verifycert() sendmessage() getmessage() getreturncode() Tabell 6.6. Funktioner i klassen storage_comm Beskrivning Initierar kommunikation med vänklienten enligt protokollet Hämtar listan över arkiv på vänklienten Laddar ner en viss fil från ett visst arkiv Skapar ett nytt arkiv på vänklienten Återställer en fil från vänklienten och skickar till presentationslagret Säkerhetskopierar en katalog Säkerhetskopierar en fil Listar filer i ett arkiv Laddar ner ett arkiv i komprimerad form Läser data från vänklienten Skriver data till vänklienten Öppnar en SSL-anslutning till vänklienten Stänger anslutningen till vänklienten Verifierar att användarnamnet stämmer i vänklientens certifikat Skickar ett meddelande till vänklienten enligt protokollet Tar emot ett meddelande från vänklienten enligt protokollet Tar emot en returkod från vänklienten enligt protokollet Filer För varje användare av systemet finns som mest fyra filer som systemet sparar: användarens CSR, det signerade certifikatet från core-servern (3DES-krypterad), en nyckelfil med både privat (3DES-krypterad) och publik nyckel samt en konfigurationsfil med information om vilka ens vänner är. Dessa filer sparas i en katalog (i prototypen med namnet keys). Denna katalog bör skyddas i största möjliga mån eftersom en attackerare som stjäl filerna har möjlighet att knäcka eventuellt svaga lösenord och på så sätt komma åt certifikat och privata nycklar. 6.3 Prototypens gränssnitt Detta avsnitt beskriver funktionaliteten ur ett användarperspektiv. 44

51 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Inloggning Att logga in är det första en användare måste göra för att använda systemet. När användaren gått in på adressen där systemet körs visas meddelandet Please login samt två textfält för användarnamn och lösenord (figur 6.4). När användaren skrivit in sitt användarnamn och lösenord och tryckt på knappen Login verifieras inloggningen av mellanlagret (och i förlängningen av core-servern). Figur 6.4. Inloggningsformuläret på webbklienten Listning av vänner Efter inloggningen visas sidan för listning av vänner. Då det i det nuvarande BaQupsystemet inte finns möjlighet att hämta information om vilka ens vänner är från core-servern, måste användaren manuellt skriva in sina vänner här. Användaren fyller i en väns användarnamn och trycker på Add friend. Denna användare hamnar sedan i listan över vänner. Före varje vän finns information om användaren är online eller offline. Om användaren är online kan man klicka på vännens användarnamn för att lista sina arkiv (figur 6.5) Listning av arkiv Då användaren klickat på en vän som är online visas de arkiv som finns på vännens klient. De listas ordnade efter datum (senast först). Alla arkiv är klickbara och när användaren klickar på dem visas de filer som arkivet innehåller (figur 6.6). Längst upp finns en länk som heter Upload a file. Klickar användaren här kommer formuläret för uppladdning av filer upp. 45

52 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Figur 6.5. Listning av vänner i webbklienten Figur 6.6. Listning av arkiv i webbklienten 46

53 KAPITEL 6. BESKRIVNING AV PROTOTYPEN Listning av filer Användaren får ett formulär där filmönster och katalogmönster kan specificeras. Standardvärdena är att visa alla filer med extensioner (*.*) i alla kataloger. När användaren valt sina filmönster och tryckt OK presenteras filerna (med valt filter). Alla filer är klickbara. När användaren klickar på en fil laddas den ner till användarens dator via webbläsaren (figur 6.7). Figur 6.7. Listning av filer i webbklienten Nerladdning av fil Beroende på vilken webbläsare som används ser nerladdningen olika ut. Det typiska fallet är att användaren får en fråga om filen ska sparas eller öppnas. Användaren kan t.ex. välja att spara filen på hårddisken Uppladdning av fil Användaren får ett formulär för att välja ett filnamn. Det finns också en Browseknapp, som visar ett fönster att välja en fil i. När användaren valt en fil och tryckt på Submit skickas filen upp till mellanlagret som i sin tur skickar filen enligt BaQupprotokollet till den mottagande klienten Teknisk information I webbgränssnittet finns en länk för teknisk information (Technical information). Den skriver i prototypen enbart ut namn och versionsnummer för mellanlagret. 47