T RUSSELSMODEL

I dette afsnit beskrives identificerede trusler mod systemet. Det vil ligeledes blive beskrevet, hvordan truslerne håndteres. Afsnittet tager udgangspunkt i en aktiv mobil modstander, der forsøger at ødelægge systemets fortrolighed eller tilgængelighed.

3.5.1 Direkte angreb mod krypteringen

En modstander kan forsøge at gætte en af systemets krypteringsnøgler vha. kryptoanalyse.

Afhængig af hvilke nøgler der gættes, vil et succesfuldt angreb betyde at systemets sikkerhed eller dele heraf er brudt. Dette må naturligvis ikke kunne forekomme.

Modstanderen kan vælge flere steder at foretage et sådant angreb. Først og fremmest kan han forsøge at bryde krypteringen af det hemmelige backupdata, som er krypteret med en symmetrisk nøgle. Ellers kan han forsøge at bryde den asymmetriske kryptering, der benyttes til

kommunikationen mellem noderne eller kommunikationens symmetriske sessionsnøgle, sådan at shares kan opsnappes og bruges til at rekonstruere hemmeligheden. Sidst men ikke mindst kan han forsøge angreb på det diskrete logaritmeproblem i forbindelse med den verificerbare secret sharing, da denne vil afsløre den hemmelige krypteringsnøgle. Et sådant angreb vil dog kræve, at modstanderen først har skaffet sig adgang til kommunikationen, f.eks. ved at kompromittere en af systemets noder.

Disse angreb håndteres alle ved at vælge algoritmer og nøglelængder, der kraftigt sandsynliggør, at angrebene vil mislykkes. Det bør ligeledes være omtrent lige svært at bryde de forskellige krypteringssystemer. Dette er beskrevet yderligere i afsnit 4.4.3.

3.5.2 Angreb mod en node

Modstanderen kan forsøge at kompromittere en af systemets noder. Herved opnår han følgende:

• Mulighed for at benytte den kompromitterede node, som allerede er en del af systemet, til at udføre angreb på resten af systemet.

• Information om nodens data, såsom shares og krypterede backup-filer.

Angrebet kan være et direkte angreb på systemet, hvor svagheder i protokollen eller systemets forudsætninger og omgivelser udnyttes. Dette er beskrevet i de efterfølgende afsnit. Ellers vil angreb mod noder typisk foregå ved, at modstanderen skaffer sig adgang til hele nodens system, f.eks. vha. et hul i operativsystemet. Hvis modstanderen har kontrol med operativsystemet, vil backup-applikationen ligeledes være under dennes kontrol. Ligeledes må det antages, at modstanderen kan kompromittere en node, hvis han opnår fysisk kontrol med maskinen, som denne kører på (f.eks. ved at stjæle en bærbar pc).

Hvis en node kompromitteres, kan modstanderen muligvis også få fat i brugerens private nøgle.

Med denne kan modstanderen siden hen udgive sig for at være den pågældende bruger.

Ligeledes vil han kunne dekryptere data sendt specielt til brugeren. Den private nøgle vil dog eventuelt kunne beskyttes vha. smart card eller anden hardware, sådan at det bliver meget vanskeligt for modstanderen at få fat i denne. Ved en sådan konstruktion vil modstanderen dog sandsynligvis stadig kunne bede noden signere pakker til andre noder (hvis noden

kompromitteres mens smart card’et er til stede), hvorved nodens brugers filer vil kunne genskabes af modstanderen.

Angreb mod de systemer, som backupsystemets noder befinder sig på, håndteres ikke af det foreslåede backup-system. Det er typisk brugerens (eller administratorens) opgave at sikre det enkelte system mod angreb. Backupsystemet vil dog tage højde for, at direkte angreb mod systemets protokol kan forekomme fra autentificerede brugere som er kompromittet, idet

systemets protokol designes med henblik herpå. Ligeledes håndteres det, at modstanderen får fat i noget information om systemets shares og filer ved at kompromittere en node. Dette gøres vha.

proaktivt secret sharing, sådan at informationen vil være ubrugeligt for modstanderen,

medmindre k noder kompromitteres i samme tidsperiode, hvilket antages at være svært. Brugeren af en kompromitteret nodes filer vil dog muligvis ikke kunne beskyttes af secret sharing

modellen. Derfor er det stadig vigtigt, at brugeren beskytter sit eget system. Dette er beskrevet yderligere i afsnit 3.6.1.

3.5.3 Angreb mod systemets kommunikationsprotokol

Der findes mange måder, hvorved svagheder i en protokol kan findes, som vil betyde, at

systemets sikkerhed kan brydes. Et angreb på protokollen er succesfuldt, hvis det får systemet til at afsløre værdifuld information eller holde op med at virke efter hensigten. Følgende fire typer angreb vil blive beskrevet:

• Injektionsangreb

• Modificeringsangreb

• Man-in-the-middle angreb

• Replay angreb

Ved et injektionsangreb laver modstanderen selv en datapakke, som sendes til systemet (dvs. til en eller flere noder). Modstanderen vil forsøge at lave en pakke, som med den rigtige opbygning og på det rigtige tidspunkt kan give det ønskede resultat.

Ved et modificeringsangreb opsnapper modstanderen en pakke, hvor enkelte dele modificeres, før denne sendes tilbage til systemet på samme måde som ved et injektionsangreb. Det kan ofte være lettere for modstanderen at modificere en pakke en lille smule, sådan at systemet stadig genkender pakken, men reagerer utilsigtet i forhold til den rigtige protokol.

Ved et man-in-the-middle angreb opsamler modstanderen kommunikationen fra to parter, der prøver at kommunikere. Modstanderen sørger herefter for, at sende sine egne pakker tilbage til de to parter, sådan at de stadig tror, at de kommunikerer med hinanden. Man-in-the-middle angreb beskrives oftest i forbindelse med nøgleudvekslinger, hvor to parter vil bytte nøgler. Her er det modstanderen, der ender med at have begges nøgler, uden af parterne er klar over det, da modstanderen udgiver sig for at være begge parter. Hermed brydes krypteringens sikkerhed.

Både injektionsangreb, modificeringsangreb og man-in-the-middle angreb forhindres ved udelukkende at benytte krypteret kommunikation. Herved kan modstanderen ikke sende egne pakker til systemet, selvom han har modtagernodernes offentlige nøgler til rådighed, sådan at troværdige pakker kan laves til den enkelte modtager. Dette skyldes, at han mangler en autentificeret privat nøgle til at signere pakkerne, hvorfor noderne ikke vil godtage pakkerne.

Modstanderen vil kunne modificere en pakke, men resultatet vil være det samme, da det

dekrypterede data vil være ændret på en uforudsigelig måde og vil derfor med stor sandsynlighed være ganske ulæseligt for systemet. Man-in-the-middle angreb vil ligeledes være umuligt, når modstanderen ikke kender de anvendte krypteringsnøgler, da han ikke kan udgive sig for at være en anden, uden at kende deres offentlige nøgle.

Systemets indledende kommunikation er dog ikke krypteret, da der først skal udveksles nøgler.

Her kunne de nævnte angreb komme på tale. Dette forhindres dog ved at benytte certifikater til autentificering. Medmindre modstanderen er i stand til at forfalske et certifikat, hvilket med rimelighed kan antages at være umuligt, kan et angreb ikke lade sig gøre her.

Et angreb der dog ikke kan håndteres vha. simpel kryptering er et replay angreb. Her opsamler modstanderen pakker fra systemet og sender disse uændret tilbage på udvalgte tidspunkter.

Selvom pakken er krypteret og selvom modstanderen ikke ved præcist, hvad den indeholder, vil den således stadig have mening for systemet på et andet tidspunkt. Dermed kan modstanderen muligvis få systemet til at bryde sammen eller afgive fortrolig information. Den eneste måde at undgå replay angreb er således, at designe systemets protokol til at undgå dette. Dette problem er beskrevet yderligere i afsnit 4.4.2.

Da det er en antagelse at noder kan kompromitteres af modstanderen, vil denne kunne overtage kontrollen med en node og ændre nodens opførsel i forhold til systemets rigtige protokol. Dette muliggør pludselig injektionsangreb, da modstanderen nu kan sende forståelige pakker, der er signeret med en autentificeret nøgle. Den eneste måde at håndtere disse angreb, er derfor i designet af systemets protokol. Protokoldesignet er beskrevet i afsnit 4.5.

Modificeringsangreb og man-in-the-middle angreb vil stadig ikke kunne lade sig gøre, da andre brugeres kommunikation vil være krypteret med deres personlige nøgler, som stadig er uden for modstanderens rækkevidde.

3.5.4 Denial of service

Denial of service (DoS) angreb kan foregå på mange måder. Modstanderen kan f.eks. klippe et netværkskabel over, eller slukke for en node, som han har fået fysisk kontrol med. Derved vil denne node være sat midlertidigt ud af spil. Angrebet kan ligeledes foregå ved at modstanderen sender så mange pakker til en node, at den ikke er i stand til at håndtere arbejdsbyrden, hvorefter den fejler. En nodes båndbredde vil ligeledes kunne opbruges, sådan at protokollens trafik ikke vil kunne komme igennem.

De fysiske DoS angreb vil ikke blive gennemgået yderligere, da disse ikke kan forhindres vha.

software. Overbelastning af en enkelt node, kan dog håndteres på forskellig vis, ved at begrænse nodernes arbejde. Først og fremmest kan man sørge for, at undlade unødvendige returpakker, når noden bliver kontaktet. Herved kan noden spare en del arbejde og blive mere resistent overfor denne type DoS angreb. For at forhindre at modtagne DoS-pakker tager for mange af nodens ressourcer, kan man implementere funktionalitet, der sørger for at noden ikke vil modtage en ubegrænset mængde pakker fra samme node. Ved et distribueret DoS angreb (DDoS) vil dette dog ikke virke, da pakkerne her kommer fra forskellige noder.

En node, der deltager i systemet, vil kunne opbruge en anden nodes båndbredde ved

kontinuerligt at sende store backupfiler til denne. Dette vil virke som et DoS angreb og det kan være svært at afgøre, hvornår afsendernoden rent faktisk laver en lovlig backup, og hvornår der er tale om DoS. Umiddelbart er der ingen let løsning på problemet, men man kan evt. vælge at lave nogle indstillinger, som lader den enkelte bruger afgøre, hvor meget man ønsker at modtage fra andre noder. Dermed vil problemerne kunne mindskes, men dette vil kræve en del

administration.

Hvis secret sharing backupsystemet havde haft en klient/server struktur, ville et DoS angreb på serveren kunne sætte hele systemet ud af drift. Idet systemet er lavet med en peer-to-peer struktur, vil det være nogenlunde robust overfor DoS-angreb. Hvis en modstander angriber en node vha. DoS svarer det til, at systemets n midlertidigt mindskes med én. Så længe der stadig er k korrekte noder tilbage i systemet, vil filer stadig kunne genskabes. Hvis flere end n-k noder angribes med DoS, vil systemet ikke længere kunne fungere. Dette er dog kun midlertidigt, indtil angrebet ophører. Systemets fortrolighed er således ikke kompromitteret og tilgængeligheden er kun midlertidigt kompromitteret. Dette kan naturligvis være kritisk nok, hvis angrebne indtræffer på de rigtige tidspunkter, men da data hverken er gået tabt eller afsløret for modstanderen, må det anses for mindre alvorligt.

Den maksimale længerevarende effekt modstanderen kan få af avanceret DoS angreb er, at der kun vil være k korrekte shares i systemet. Dette opnås ved at sætte n-k servere ud af spil under en opdateringsrutine, således at disses shares bliver ubrugelige. Da der stadig vil være k korrekte og fungerende noder tilbage i systemet vil disse opdatere deres shares efter planen. Hvis flere end n-k noder sættes ud af spil, vil opdateringen slet ikke kunne foregå, hvorfor den længerevarende tilgængelighed ikke er truet. Et sådant angreb vil kunne håndteres ved, at systemet selv kan skifte konfiguration, jf. afsnit 2.2.5. Herved vil de tilbageværende k noder kunne vælge en anden konfiguration, der ikke kræver, at alle tilbageværende noder er fejlfri.

Prototypen vil af tidsmæssige årsager ikke indeholde funktionalitet til at imødegå DoS angreb.

3.5.5 Social engineering

Ved et social engineering angreb forstås, at modstanderen vha. sociale relationer skaffer sig adgang til systemer. Det mest anvendte social engineering består i at ringe til folk og bede dem afsløre deres password¹⁵, og undersøgelser har vist, at overraskende mange vælger at gøre det, til trods for, at de ikke kender personen i den anden ende. Social engineering er en af de mest benyttede og effektive angrebsmetoder og kræver ofte ingen teknisk viden, hvorfor alle og enhver kan gøre det.

Alle systemer er sårbare over for social engineering og dette backupsystem er ingen undtagelse, hvorfor systemet aldrig kan blive mere sikkert end de mennesker, der bruger det. Hvis

modstanderen kan overbevise k deltagere om at afsløre deres share (eller blot overbevise dem om, at han lige skal kigge på deres computer i fem minutter, hvorved han selv kan finde frem til share-informationen), vil systemets sikkerhed være brudt. Det samme vil være gældende, hvis modstanderen kan franarre private krypteringsnøgler fra tilpas mange brugere, da han herved kan læse den hemmelige kommunikation og udgive sig for at være en af brugerne.

Dette backupsystem er dog mere robust overfor social engineering, end de fleste andre systemer.

Dette skyldes, at modstanderen skal overbevise k brugere om at udlevere deres share, hvilket vil være væsentlig meget sværere, end at franarre en tilfældig godtroende bruger sit password. Man kan desuden forestille sig, at brugerne af backupsystemet ofte vil være spredt ud over mange dele af verden, hvilket besværliggør angrebet yderligere.