M ODELANALYSE

I dette afsnit videreudvikles den grundlæggende model for det foreslåede system og de vigtigste aspekter analyseres.

3.3.1 Kommunikation og autentificering

Systemet er afhængigt af sikker kommunikation, for at modstanderen ikke kan angribe secret sharing protokollerne. Sikker kommunikation mellem noderne kan opnås vha. asymmetrisk kryptografi, hvor hver bruger har sit eget nøglepar. Desuden benyttes symmetriske

sessionsnøgler til at øge hastigheden på krypteringsoperationerne, hvilket er beskrevet nærmere i afsnit 4.4.1. Brugerens offentlige nøgle gives til de andre noder, mens den private holdes

hemmelig. Herved sikres både fortrolighed og integritet af kommunikationen. Ved både at kryptere med modtagerens offentlige nøgle og lave en signatur med afsenderens private nøgle, sikres desuden non-repudiation. Dermed kan en kompromitteret node ikke sende falsk data og siden hen benægte afsendelsen. Hvis det ikke lykkes en bruger at holde sin private nøgle hemmelig, vil modstanderen både kunne læse brugerens kommunikation med andre noder og lave korrekte signaturer. Dermed vil modstanderen kunne generere sine egne

kommunikationspakker og signere dem med brugeren private nøgle, før de sendes til andre noder, sådan at modtagernoderne vil tro, at pakkerne kommer fra den pågældende bruger selv.

Det er således essentielt, at private nøgler holdes hemmelige i systemet.

Før kommunikationen er sikker, skal nøglerne dog kunne autentificeres. En fælles

gruppeautentificering er utilstrækkelig til at gennemføre systemets autentificering, da det her er gruppens samlede holdning til det nye medlem, der afgør, om denne autentificeres. Da det ikke er gruppen i fællesskab, der skal tage en backup, men den enkelte bruger, er der behov for, at hver enkelt bruger (på hver enkelt node) kan autentificere hver af de andre og derved afgøre, om han tør stole på disse eller ej. Derfor benyttes i stedet certifikater og certifikatautoriteter til autentificering. Løsningen muliggør effektiv autentificering af brugere, og kræver ikke nogen tidligere kontakt eller fælles kontakter ligesom Web of Trust, hvor man helst skal kende nogen, som kender nogen osv.

Hver bruger skal således have et certifikat fra en certifikatautoritet, som bevidner, at dennes offentlige nøgle er autentisk og tilhører brugeren. En node gemmer desuden modtagne certifikater fra andre noder, der er autentificerede. Disse benyttes for at opnå sikker kommunikation.

3.3.2 Secret sharing

Ved anvendelsen af secret sharing mindskes paradokset omkring fortrolighed kontra

pålidelighed. Det er dog ikke forsvundet, da de to egenskaber stadig er forbundne. Som eksempel herpå er en (25,2)-model meget pålidelig, idet 25 noder opbevarer data mens kun to kan

genskabe data. Omvendt vil en (25,12)-model have en større fortrolighed, da 12 noder skal bruges for at genskabe hemmeligheden. Dette betyder til gengæld også, at robustheden og dermed pålideligheden mindskes, da hemmeligheden vil gå tabt, hvis 14 af de 25 noder mister deres data i samme tidsperiode.

Det samlede niveau af fortrolighed og pålidelighed kan dog med rimelighed antages at kunne øges vha. secret sharing. En (25,1)-model svarer til normal replikkering af data, da alle 25 noder hver for sig kan genskabe data. Ved f.eks. at øge k til 3, øges fortroligheden væsentligt, da det er markant sværere at skaffe tre shares end et enkelt. Derimod mindskes pålideligheden kun en lille smule, da der stadig skal gå 23 shares tabt, før data mistes.

Da systemet skal beskyttes mod aktive angreb, er det vigtigt, at en verificerbar secret sharing model vælges. Denne vil forhindre, at protokollen omgås ved at falske shares kommer i omløb.

For at holde systemets protokol så simpel som muligt, vil det desuden være en fordel, hvis den verificerbare secret sharing er ikke-interaktiv. Feldmans VSS opfylder de krav, som systemet har til verificerbarhed, og da denne model desuden er den simpleste, vælges denne.

Backup-data kan ofte blive gemt i mange år, og selv når der ikke er brug for en

rekonstruktionsfunktionalitet fordi data er forældet, er det ofte stadig et krav, at data holdes fortrolige. Dette kan bl.a. skyldes forretningshemmeligheder eller følsomme kundedata. Derfor er det vigtigt, at systemets sikkerhed ikke mindskes væsentligt som tiden går (udover den naturlige forringelse af krypteringsnøglernes styrke). Sikkerhedsforringelserne vil enten kunne ske i forbindelse med kompromitterede noder eller shares, der går tabt. Proaktivt secret sharing løser disse problemer med de omtalte share-opdaterings- og share-gendannelsesoperationer, jf.

afsnit 2.2.3.

Til hver backup-fil hører en symmetrisk krypteringsnøgle, der krypterer filen, når en backup skal foretages. Den krypterede backup-fil sendes til alle deltagende servere. Disse er udvalgt blandt servere, som filejeren har autentificeret. Derefter benyttes secret sharing til at dele den

symmetriske krypteringsnøgle mellem medlemmerne i et (n,k)-threshold scheme, som filejeren har valgt. Da Feldmans VSS afhænger af, at det diskrete logaritmeproblem ikke kan løses, vil en symmetrisk krypteringsnøgle alene være for lille til at sikre, at dette ikke kan ske. Derfor skal den symmetriske krypteringsnøgle pakkes ind i en større envelope, før den deles via secret sharing.

Denne løsning er valgt, da størrelsen af en backup-fil kan variere meget og da det ikke er hensigtsmæssigt at dele store filer direkte vha. secret sharing. En årsag hertil er, at shares skal sendes over netværket til filejeren i forbindelse med en rekonstruktion af det hemmelige data.

Hvis en backup-fil fylder 100 Mb, vil direkte shares af filen ligeledes fylde 100 Mb. Disse vil således skulle sendes fra k noder til filejeren, for at denne kommer i besiddelse af k shares og kan rekonstruere data (antaget at filejerens eget share er gået tabt). Dette vil sandsynligvis gøre båndbredden til et flaskehalsproblem. Problemet undgås ved i stedet at dele en krypteringsnøgle med secret sharing. Filejeren behøver således kun at modtage k shares af en størrelse magen til krypteringsnøglen samt en enkelt version af den krypterede backupfil (100 Mb). Herved spares en båndbredde på k * 100Mb – (100 Mb + k * nøglestørrelse) ≈ (k-1) * 100Mb. De samme

flaskehalsproblemer vil opstå i forbindelse med opdatering og rekonstruktion af shares, hvis ikke denne løsning vælges.

Denne løsning betyder dog, at systemet også skal tage højde for at selve det krypterede backup-datas integritet er i orden. Systemets protokol skal altså designes til at kunne checke integritet af både filer og shares. Dette er beskrevet yderligere i afsnit 4.5.7.

De secret sharing protokoller, som systemet skal indeholde, er derfor som følger:

• Grundlæggende verificerbart secret sharing til at foretage backup og til at rekonstruere backup-data.

• Proaktiv verificerbar share-opdateringsfase, hvorved gamle shares bliver ubrugelige.

• Proaktivt integritetscheck af shares.

• Proaktiv verificerbar share-gendannelsesfase, hvor tabte og modificerede shares gendannes.

• Proaktivt integritetscheck af selve backup-data.

Desuden skal beskyldninger i forbindelse med protokolafvigelser håndteres (se afsnit 3.3.4).

3.3.3 Gruppestruktur

Hvis systemet skal fungere med mange brugere på samme tid, vil det være besværligt, at holde styr på alle uden en gruppeinddeling. Ved at brugere tilslutter sig en backup-gruppe, kan man vælge en delmængde af systemets brugere, som man ønsker at samarbejde med. En

gruppeinddeling giver ligeledes mulighed for adgangsbegrænsede grupper, sådan at en virksomhed f.eks. kan lave sin egen password-beskyttede gruppe, som ingen andre kan blive medlem af. Det skal dog bemærkes i denne sammenhæng, at systemets sikkerhed ikke afhænger af en gruppeautentificering, da alle brugere skal autentificere hinanden enkeltvist.

Gruppestrukturen laves således primært for at lette brugen og overskueligheden af systemet.

I en gruppe har alle mulighed for at foretage backup hos hinanden. For hver fil der tages backup af, vælger ejeren, hvilke gruppemedlemmer, der skal have et share, da alle medlemmer ikke nødvendigvis stoler på hinanden.

3.3.4 Kompromitterede noder

System skal være robust overfor kompromitterede og fejlende noder. En stor del af denne robusthed opnås vha. proaktivt secret sharing, hvori det antages, at kompromitterede noder ikke er kompromitterede for evigt men typisk kun i en eller to tidsperioder. Efter noder er

kompromitterede kan den rigtige ejer af noden ”rense” denne, sådan at noden ikke længere er styret af modstanderen. Denne rensning bliver beskrevet som en reboot rutine [11]. I praksis vil det ofte kræve en reinstallering af systemet, før man kan være sikker på, at modstanderen ikke længere befinder sig i systemet. Dette kræver dog, at systemet er klar over, at noden er

kompromitteret, sådan at ejeren kan blive gjort opmærksom på situationen.

Systemet kan opdage kompromitterede noder ved kontinuerligt at sikre sig, at systemets protokol overholdes. I det øjeblik protokollen brydes, er den ansvarlige node kompromitteret. Ofte vil alle noder opdage dette på nogenlunde sammen tid (f.eks. hvis den kompromitterede node slet ikke svarer) men hvis modstanderen er mere snu, vil han forsøge at finde huller i protokollen ved at sende falsk data til en enkelt eller få noder, mens resten af systemet modtager korrekt

information. Her er det væsentligt, at hver enkelt node kan vurdere, om den modtagne

information er korrekt. Dette kan klares primært vha. verificerbarheden i secret sharing. Dernæst skal modtagernoden være i stand til at bevise, at den kompromitterede node afviger fra

protokollen, sådan at resten af systemets noder ligeledes vurderer noden som kompromitteret.

Derudover må det ikke kunne lade sig gøre for en kompromitteret node at overbevise resten af systemet om, at en korrekt node er kompromitteret, således at denne udelukkes fra systemet.

Disse problemstillinger kan håndteres vha. den asymmetriske kryptografi, som benyttes til kommunikationen mellem noderne, da afsenderen ikke kan benægte at have sendt den

pågældende pakke, når dennes signatur matcher. En node, der modtager falsk information, vil således sende en beskyldning (accusation) indeholdende informationen og signaturen videre til resten af systemets noder. Disse kan ved at betragte signaturen og informationen vurdere, om en node er kompromitteret. Når en node sender en beskyldning om en anden node til resten af gruppen, svarer det altså til, at den prøver at tilbagekalde den kompromitterede nodes certifikat.

Tilbagekaldelsen i dette tilfælde foretages dog ikke af certifikatautoriteten men af systemets egen protokol. Figur 5 og Figur 6 herunder skitserer beskyldningerne.

Figur 5 – Her sender node 4 korrekt data til node 2 og node 3, men data til node 1 er forfalsket for at forsøge at få systemet til at fejle.

Figur 6 – Her benytter node 1 den falske data (og den tilhørende signatur) til at beskylde node 4 for at snyde. Node 2 og node 3 kontrollerer informationen fra node 1, og hvis de er enige i, at node 4 har snydt, registrerer de noden som værende kompromitteret.

Et særtilfælde til denne slags angreb er dog, hvis modstanderen vælger slet ikke at sende data til enkelte noder. Dermed vil de ikke kunne bevise, at modstanderens node afviger fra protokollen (han kan heller ikke selv være sikker, da årsagen kan skyldes simple fejl i stedet). Denne

problematik er således nødt til at blive håndteret af protokollen, sådan at denne type angreb ikke kan finde sted. Det nærmere protokoldesign, der skal sikre, at disse angreb er umulige, er

beskrevet i afsnit 4.5.

Hvis en node kompromitteres, lærer modstanderen grundet secret sharing ikke noget om backup-data (med mindre k noder er kompromitteret). Dette er dog ikke gældende, hvis brugerens private nøgle ligeledes kompromitteres. Herved vil modstanderen få adgang til at genskabe dennes

backup, hvorved sikkerheden er brudt. Dog er det kun den kompromitterede nøgles ejers filer, der ikke længere vil være beskyttet. Det er derfor en nødvendighed for den enkelte brugers filers sikkerhed, at private nøgler ikke kompromitteres.

Når en node betragter en anden som kompromitteret ignorer den alt information fra nodens bruger. Dette gøres ved at ignorere pakker, der er signeret med brugerens private nøgle. Når den rette ejer har renset systemet for modstanderen og ønsker at deltage, vil han således stadig blive betragtet som kompromitteret af de andre noder. For at blive anerkendt igen, må han få et nyt nøglepar og et nyt certifikat fra certifikatautoriteten og autentificere sig på ny. Da

brugerinformationen i det nye og gamle certifikat vil være ens (det er den samme bruger, der har fået udstedt begge certifikater), vil brugeren have samme rettigheder som tidligere overfor sine filer i systemet. Brugeren vil således atter kunne genskabe sine filer og virke på lige fod med de andre noder i systemet.