Kryptering av bilder vid online backup ANDRÉ STRINDBY Examensarbete Stockholm, Sverige 2011
Kryptering av bilder vid online backup ANDRÉ STRINDBY Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Alexander Baltatzis Examinator var Stefan Arnborg TRITA-CSC-E 2011:043 ISRN-KTH/CSC/E--11/043--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc
Sammanfattning Denna rapport går igenom de delar som är viktiga för en applikation som hanterar online-backup av bilder. Det vill säga hur man får den säker, snabb och laglig. Målsättningen med säker är att alla bilder ska krypteras från klienten till servern, snabb att krypteringen inte får ta för lång tid och laglig att tillhandahållaren av applikationen inte ska hållas ansvarig för de bilder som ligger på servern. För att se vad som används idag (2010) för kryptering av bilder undersöktes Facebook, Flickr, Dropbox, KeepIt och Storegate. Facebook och Flickr gör ingen kryptering alls, medan Dropbox, KeepIt och Storegate använder SSL samt AES. Tre varianter av bildkryptering har undersökts, nämligen: 3D Chaotic Baker Maps, Advanced Encryption Standard (AES) samt Faber-Schauder Multivalue Transform (FMT) med AES. Då de flesta bilder redan är komprimerande i ett annat format än FTM, så finns det ingen anledning till varför man bör använda FMT med AES. 3D Chaotic Baker Maps är snabbare på att kryptera okomprimerade bilder än AES, men när det kommer till komprimerande bilder så är AES snabbare. Då 3D Chaotic Baker Maps uppfanns 2006 så är den inte en lika välkänd samt välbeprövad algoritm som AES och det är därför rekommenderat att använda AES. Huvudtanken för att få krypteringsdelen att gå fortare är att göra den på klientsidan. Då kommer användare inte behöva dela på serverresurser för att få kryptera bilderna. Secure Socket Layer (SSL) och Transport Layer Security (TLS) undersöktes för överföringen mellan server och klient. Det är inte mycket som skiljer de båda protokollen åt och det finns inte några direkta konkurrenter till dem heller. Vilken man väljer att använda spelar ingen större roll men att man bör använda en av dem är självklart ifall man vill uppnå säker överföring mellan klient och server. Det finns två lagar som pratar om ansvarsfrihet när det kommer till att bilderna lagras på tillhandahållarens server. Den första är lagen om ansvar för elektroniska anslagstavlor, som säger att den som tillhandahåller en elektronisk anslagstavla bör ha rimlig uppsikt över att den inte innehåller olagligt material (till exempel hets mot folkgrupp och brott mot upphovsrätten). Den andra lagen är E-handelslagen som innehåller bestämmelser om hur mellanhänder som bedriver verksamhet av rent teknisk karaktär inte ska kunna hållas ansvariga för den information de vidarebefordrar eller sparar. Rättsläget är oklart då fall av den här karaktären inte har prövats i svensk domstol.
Encryption for online backup of pictures Abstract This thesis examines the elements that are important to an application that handles online backup of pictures. That is, how you make the application safe, fast and legal. The requirement of safe is that all pictures will be encrypted from client to server. Fast is that the encryption should not take too long and the legal part is that the provider of the application should not be held responsible for the images on the server. To see what is used today (2010) for encryption of images was examined Facebook, Flickr, Dropbox, KeepIt and Great Gate. Facebook and Flickr does not apply encryption, while Dropbox, KeepIt and Storegate are using SSL and AES. Three variants of image encryption have been investigated: 3D Chaotic Baker Maps, AES and the compression method FMT with AES. Since most images are already stored in a compressed format other than FMT, there is no reason why you should use FMT with AES. 3D Chaotic Baker Maps is faster to encrypt the uncompressed images than AES, but when it comes to compressed pictures AES is faster. Today most images are compressed so AES will be a faster choice. Also 3D Chaotic Baker Maps was invented in 2006 and is therefore not an equally well-known and well-tried algorithm as AES. Two good reasons why you should use AES. The main idea to get the encryption working faster is to do it on the client-side. In that case users do not need to share the server resources to encrypt the images. SSL and TLS was examined for transmission between server and client. There is not much that separates the two protocols and there are not any competitors to them either. What you choose to use is not essential but that you should use one of them is a must if you want to achieve secure transmission between client and server. There are two Swedish laws that raise the question of who is responsible for the pictures stored on the server. The first law lagen om ansvar för elektroniska anslagstavlor says that the provider of an electronic bulletin board should in some degree monitor that it does not contain illegal material (for example hate speech and copyright infringement). The second law Ehandelslagen contains the regulations for providers that have services of purely technical nature, should not be held responsible for the information they transmit or store. However, there are no direct court cases of similar nature and therefore it is unclear what the outcome would be for a case of this nature.
Innehållsförteckning 1. Bakgrund...1 2. Syfte...2 3. Mål...3 4. Undersökning...4 4.1 Vad används för att kryptera bilderna idag?...4 4.1.1 Dropbox... 4 4.1.2 Storegate... 4 4.1.3 KeepIt... 4 4.1.4 Flickr... 4 4.1.5 Facebook... 4 4.2 Alternativ på krypteringsalgoritmer i morgon?...5 4.3 Vem ansvarar för bildernas innehåll?...5 4.3.1 Lagen om elektroniska anslagstavlor... 5 4.3.2 E-handelslagen... 5 5. Teori...6 5.1 Krypteringsalgoritmer...6 5.1.1 3D Chaotic Baker Maps... 6 5.1.2 AES... 7 5.1.3 FMT följt av AES... 8 5.2 Säker överföring...9 5.2.1 SSL... 10 5.2.2 TLS... 11 6. Metodik...12 7. Resultat...13 7.1 Vad används för att kryptera bilderna idag?...13 7.2 Krypteringsalgoritmer...13 7.3 Säker överföring...15 7.4 Vem ansvarar för bildernas innehåll?...15 8. Slutsatser...16 Bilagor 1. 3D Chaotic Baker Maps i C++ 2. AES i C++ 3. Bild-lista 4. Testvärden 5. Skärmdump proof-of-conceptapplikation 6. Akronymer
Förord I bilaga 6 finns en lista över akronymer som används i rapporten. Ett tips kan vara att riva ut denna sida och ha bredvid sig om man tycker det är jobbigt med alla akronymer. Förövrigt vill jag tacka Open Mind hos vilka jag har gjort mitt examensjobb och då främst min handledare på företaget Johan Fredsberg som har sett till att arbetet gått framåt. Att sitta på ett kontor har gjort mitt arbete mycket effektivare än om jag suttit hemma bland tv-spel, filmer och andra nöjen. Utan dem hade jag inte gjort klart det i förtid och klarat mig ekonomiskt under tiden. Detta examensjobb är helt specificerat av mig och även om vägen inte blev helt rak var roligt och intressant att få genomföra det.
1. Bakgrund Som datanörd får man ofta hjälpa gamla vänner och bekanta med deras datorproblem. Den uppgift jag oftast får är att återskapa bilder som har blivit raderade av misstag eller försvunnit när datorn har kraschat. Många tänker inte på att göra regelbundna backuper och det är ännu fler som inte riktigt vet hur eller har något bra sätt att göra det på. Bränna ut bilderna på skivor är nog den vanligaste lösningen men även en av de krångligaste, då skivorna inte är så pålitliga och hållbara. På senare år har många backup-tjänster kommit till online, StoreGate är ett exempel på en sådan sida. Även sidor som inte är gjorda för backup blir utnyttjade till det, ett exempel här är Facebook. Men många tycker att det inte känns tryggt att lägga upp sina privata bilder på nätet. Det är då inte bara aspekten av att man inte vet om de verkligen kommer finnas kvar där när man behöver dem, utan även att man inte vet vem som kan se dem. Det är här mitt examensjobb kommer in i bilden, kryptering av bilder vid online-backup. Jag skulle gärna se en applikation som är en blandning av Flickr och Storegate. Det vill säga en applikation där man både kan skapa och dela med sig av album med sina bilder, men även spara sina bilder säkert för att slippa tänka på backuphantering. 1
2. Syfte Syftet med detta examensjobb är att undersöka hur man kan utveckla en applikation för online-backup av bilder som är säker, snabb och laglig. Med säker menas att bilderna ska vara krypterade vid överföring mellan server och klient, samt att de ska sparas krypterat på servern. Hur åstadkommer man detta? Vad använder dagens sidor för online-backup av bilder? Vad ligger på ritbordet som kan revolutionera morgondagens kryptering av bilder? Då säkerhet är ett väldigt stort område så begränsas detta i examensjobbet genom att endast säkerheten mellan klient och server samt lagring på servern tas upp. Alltså inte säkerheten i klienten vid visning av bilderna. Då användare ofta är otåliga får applikationen inte ta orimlig tid på sig för att ladda upp eller ner bilder mellan server och klienten. Då kryptering är kostsamt i prestanda, vad finns det för alternativ till att få applikationen att flyta på bättre? Den juridiska delen innefattar att få reda på vem som ansvarar för bilderna som ligger på servern. Är det användaren som laddat upp dem eller är det tillhandahållaren av tjänsten? Då bilderna är krypterade från att de lämnar klienten så kan inte tillhandahållaren av tjänsten se vad bilderna föreställer. Skulle bilderna vara olagliga så är det bara användaren och dem han väljer att dela med sig bilderna med som skulle kunna se dessa. Detta kanske påverkar vem som får det slutgiltiga ansvaret för bilderna. 2
3. Mål Undersöka om sidor som Facebook, Flickr och Storegate krypterar användarnas bilder och i vilken utsträckning de gör det, vid lagring och/eller överföring. Vad använder de för krypteringsalgoritmer för att få det att gå tillräckligt fort men ändå vara säkert. Målet innefattar även att få veta vad man bör tänka på när det gäller vem som ansvarar för bilderna och hur man kan ge ansvaret till användaren. Med den kunskap som fås från detta examensjobb så ska man kunna veta hur man utvecklar en applikation för online-backup av bilder som är säker, snabb och laglig. 3
4. Undersökning 4.1 Vad används för att kryptera bilderna idag? Hur fem olika sidor hanterar lagring och överföring av bilder har undersökts. Tre sidor (Dropbox, Storegate och KeepIt) som är specialiserade på just backup och två sidor (Facebook och Flickr) som inte är gjorda för att användas till backup men som utnyttjas till det ändå. 4.1.1 Dropbox Dropbox är väldigt tydliga med på hur mycket de krypterar på sin hemsida. Detta har gjort så att de är de enda jag inte ens behövt försöka kontakta. De använder SSL för att överföra filerna säkert mellan klienten och servern. Filerna krypteras på klienten med AES-256 och sparas krypterade på servern [2]. 4.1.2 Storegate Storegate krypterar både överföringen och lagringen av filer hos dem. Överföringen görs som vanligt via SSL [3]. För att få reda på vad för krypteringsalgoritm som används vid kryptering på hårddisken kontaktades Storegate och följande svar mottogs: Den information som finns ute på den publika hemsidan är den vi har valt att informera om. Annars har vi som policy att aldrig kommentera detaljerna kring säkerhetslösningarna i våra system. Av hänsyn till våra kunder avslöjar vi inte hur och var informationen lagras. 4.1.3 KeepIt Det enda KeepIt säger på sin hemsida är att de använder en 256 bitars krypteringsnyckel för att kryptera filerna på sina hårddiskar [1]. Men vid mailkontakt berättade de att de använder 256 bitars AES för att kryptera informationen på klienten. Sedan skickas detta till servern krypterat med 128 bitars AES för att sedan spara den redan krypterade informationen. 4.1.4 Flickr Flickr har inte någon information på sin hemsida om hur de överför eller lagrar bilderna, samt hur man kan kontakta dem. Så genom att skapa ett Flickr-konto och ladda upp ett par bilder samtidigt som all utgående trafik från datorn undersöktes utav Wireshark [8], kunde man se att ingenting skickades över SSL och att bilderna skickades helt okrypterat över TCP. När det kommer till hur de sparar bilderna har jag inte lyckats få fram någon information. 4.1.5 Facebook Facebook har precis som Flickr ingen information om detta på sin hemsida. Därför användes Wireshark även här för att se om bilderna överfördes med SSL. Efter en hel del letande bland all data så kom jag fram till att även Facebook skickar bilderna okrypterat, det går det vill säga ingen trafik över SSL. Man kan även ta länken till godtycklig bild och öppna den separat utan att vara inloggad på Facebook. Detta visar på att Facebook inte sparar bilderna krypterat eftersom ingen inloggning krävs för att se bilden. 4
4.2 Alternativ på krypteringsalgoritmer i morgon? Vid sökning efter en algoritm speciellt designad för att kryptera bilder så fanns det inte så många olika förslag. De flesta sidor nämner AES i något speciellt läge eller med komprimering före. Dock var det en artikel som stack ut från mängden. Den introducerar krypteringsalgoritmen kallad 3D Chaotic Baker Maps som är specialiserad just för att kryptera bilder. Mer om hur denna algoritm fungera och varför den är bra på just kryptering av bilder går att läsa i kapitel 5.1.1. 4.3 Vem ansvarar för bildernas innehåll? Vid rådfrågning av juriststuderande Matilda så var svaret att det finns inget liknande fall där det handlar om krypterade bilder i Sverige och därför är det svårt att säga vem som har ansvaret. Dock kunde hon tänka sig att man skulle kunna åberopa två lagar för göra anspråk på ansvarsfrihet. 4.3.1 Lagen om elektroniska anslagstavlor Lag (1998:112), om ansvar för elektroniska anslagstavlor, säger att den som tillhandahåller en elektronisk anslagstavla ska i rimlig omfattning ha uppsikt över anslagstavlan och ta bort meddelanden som strider mot lagen. De meddelanden det gäller är uppvigling, hets mot folkgrupp, barnpornografibrott, olaga våldsskildring och brott mot upphovsrätten [13]. Att inte ta bort de meddelanden som strider mot lagen är straffbart, både när det sker med uppsåt eller av oaktsamhet. Lagen tar hänsyn till att den elektroniska anslagstavlan kan bli orimligt stor för att kräva att tillhandahållaren aktivt ska kontrollera alla meddelandena. I dessa fall räcker det att användaren kan påtala förekomsten av olagliga meddelanden på en så kallad klagomur och att tillhandahållaren då bedömer och vidtar åtgärder mot dessa meddelanden omedelbart. 4.3.2 E-handelslagen E-handelslagen innehåller bestämmelser för hur mellanhänder som bedriver vissa verksamhetstyper av rent teknisk karaktär inte ska kunna hållas ansvariga för sådan information som de vidarebefordrar eller lagrar. Frihet från ansvar stadgas i e-handelslagen till att omfatta tre typer av tjänster [14]: 1. Ansvarsfrihet för sådan tjänsteleverantör som enbart vidarebefordrar information. Exempel på sådana tjänster är Internet access eller e-postsystem. 2. Ansvarsfrihet för viss tillfällig information i samband med överföring av information (cachning). 3. Ansvarsfrihet vid tillhandahållande av lagringsutrymme för information i funktion av värdtjänster. Värdtjänster motsvarar i allt väsentlighet begreppet elektronisk anslagstavla. Verksamheten behöver även vara rent teknisk, automatisk och av passiv natur för att ansvarsfriheten ska gälla. Med andra ord tjänsteleverantören får inte kontrollera eller ha kännedom om informationen och kan därigenom heller inte ändra eller sortera den [19]. 5
5. Teori 5.1 Krypteringsalgoritmer Kryptering av enbart bilder skiljer sig lite från att kryptera annan data. Detta på grund av att bilder oftast är stora och att intilliggande pixlar i bilderna har samma eller liknande värden. För att undvika homogena fält i bilder så kan man komprimera dem. Bildkomprimeringsalgoritmer söker just efter områden där pixlarna är homogena, för att kunna minska på mängden data som behövs för att spara bilden. Eftersom detta påverkar mängden data så påverkar det även krypteringstiden för bilden. Komprimeringen tar då även tid men den är försumbar mot tiden det tar att kryptera den mängd data som komprimeras bort. 5.1.1 3D Chaotic Baker Maps Det som gör att kaos-baserade algoritmer passar för bildkryptering är att två liknande indata divergerar fort, detta kallas för avalanche effect, då en liten ändring i indata får lavinartad ändring i utdata [17]. I bild 1 kan man se denna effekt då bilden föreställande Lena krypteras med nyckel och sedan dekrypteras med samma nyckel och med en nyckel där den minst signifikanta biten har ändrats. Bild 1 - Bilderna illustrerar hur stor skillnaden blir genom att bara försöka dekryptera med en nyckel som är snarlik den som bilden krypterades med. Detta fås i denna algoritm genom omvandlingen från 2D data till 3D data samt Baker mappningen. Omvandlingen från 2D data till 3D data ger en bra blandning av indatan. Baker-mappningen är ett antal matematiska funktioner som beräknas på kuber av den omvandlade datan [15]. Bild 2 visar hur bilddatan divergerar efter Baker-mappningen. Den vänstra grafen föreställer de intilliggande pixlarnas samband i färg före kryptering av bilden Lena. Den högra grafen föreställer samma sak fast efter kryptering. 6
Bild 2 - Bilderna visar sambandet mellan två horisontellt intilliggande pixlar. Den vänstra bilden är för den okrypterade bilden och den högra är för den krypterade bilden. 3D Chaotic Baker Maps algoritmen går till på följande sätt: 1. Dela upp 128 bitars nyckeln till 3 st 24 bitars flyttal, ett 24 bitars heltal och 2 st 16 bitars heltal. 2. Bildens pixlar omvandlas till ett 3D objekt (en kub). Om H är höjden och W är bredden på bilden så ska M*N*L = W*H, där M är bredden, N är höjden och L är djupet på kuben. 3. Baker-mappningen körs över den staplade bilden, med nyckeln. 4. Sprid ut data med hjälp av en inverterbar funktion som använder sig av två tal från nyckeln. Ett av talen används som seed (24 bitars flyttal) och ett som antalet rundor som funktionen körs (16 bitars heltal). 5. Iterera över steg 3 och 4, antalet iterationer bestäms ifrån nyckelns sista värde (ett 16 bitars heltal). 6. Platta ut 3D objektet till en 2D bild, som nu är krypterad. Nyckellängden som används är 128 bitar, detta anses kunna motstå bruteforce attacker då det ger 4*10 38 olika nycklar [17]. Simulationer visar att medelhastigheten vid kryptering och dekryptering är 1,2 MB/s och kan nå upp till 2,8 MB/s på en 1 GHz Pentium IV dator [15]. Då 3D Chaotic Baker Maps koden inte är tillgänglig för allmänheten finns endast vissa delar av implementationen av algoritmen i C++ i bilaga 1. Vill man prova algoritmen själv finns det DLL-filer att ladda ner på skaparnas hemsida [11]. 5.1.2 AES Advanced Encryption Standard började tas fram 1997 för att ersätta DES (Data Encryption Standard). 2001 släpptes standarden som en FIPS och har sedan dess används världen över. AES är ett blockkrypto som kan köras med tre olika nyckellängder 128, 192 eller 256 bitar. Den innehåller iterativa steg och antalet rundor i dessa beror på vilken nyckel man väljer, 10, 12 respektive 14 [21 s.102]. Det finns ett antal olika lägen man kan köra AES i. ECB (Electronic Codebook) vilket är standarden för AES och betyder helt enkelt att man krypterar block av indatan helt oberoende på varandra. Detta läge har uppenbara svagheter för kryptering av bilder då två identiska indatablock kommer att bli två identiska kryptoblock, identiska indatablock är rätt vanligt vid bilder. På bild 3 kan man se detta fenomen samt skillnaden när man kör i CBC (Cipher Block Chaining) läge. I CBC läge gör man XOR mellan ett kryptoblock och det nästkommande indatablocket. Detta resulterar i att alla block utom det första beror på ett annat 7
block. Det första beror på en så kallad initialiseringsvektor, som innehåller slumpdata. CFB (Cipher Feedback) och OFB (Output Feedback) är två lägen som går ut på att man tar hjälp av en ström av nycklar. Det vill säga att man använder olika nycklar för olika block, vilket resulterar i att AES blir mer likt ett strömkrypto. När det kommer till säkerheten i bildkryptering så hjälper detta avsevärt, då två kryptoblock inte längre kan få samma värde. Bild 3 Här ser man tydligt säkerhetsproblemet med att bara köra AES i standard ECB läge. Samt skillnaden att köra AES i CBC läge. AES kryptering i ECB läge går till på följande sätt: 1. Initierar en variabel State som innehåller klartexten i block. Dessa kör man XOR på med RoundKey (tas ifrån huvudnyckeln). 2. För antalet rundor (10,12 eller 14) minus ett, gör följande på State; applicera en S-box (en matris med fördefinierade värden), skifta raderna, blanda kolumnerna och applicera RoundKey:n. 3. Applicera en S-box, skifta raderna och applicera RoundKey:n. 4. Definiera kryptotexten som State-blocken I bilaga 2 så finns det en implementation av AES i C-kod skriven för Kattis [9]. 5.1.3 FMT följt av AES Om man inte vill köra AES i något speciellt läge eller vill att sannolikheten för att få två identiska kryptoblock ska bli ännu mindre, så kan man först tillämpa FMT (Faber-Schauder Multi-scales Transformation) även känd som Faber-Schauders Wavelet Transformation. FMT eliminerar konstanta och linjära samband mellan intilliggande data, vilket medför att bilderna blir komprimerade [18]. Det vill säga, istället för att förvränga i krypteringen så förvränger man i indata. Man kan förklara FMT så att den räknar ut skalor med ett antal aritmetiska funktioner över de olika pixlarnas värden. Man tar sedan en pixel i en skala och beräknar skillnaden mellan den och de intilliggande pixlarna i den föregående skalan [16]. Områden som uppvisar en lokal topp för dessa skillnader motsvarar en 8
starkt lysande övergång för de grå värdena, medan övriga områden är de områden där nivån för grå är konstant. Se bild 4 för en av FMT skalorna av bilden Lena. Vilket gör att man kan även använda FMT till så kallad kantavkänning. Detta är inget som behandlas i denna rapport, men man kan även se den effekten i bild 4. Bild 4 - Till vänster är originalbilden, till höger är bilden i en av skalorna från FMT:n. Vid jämförelse mellan kompression av FMT och JPEG så är kompressions-nivån liknande och FMT har fördelen av att inte försämra bilden lika mycket. JPEG bygger på DCT transformation som tar block av pixlar [16]. Detta gör att bildens storlek måste vara delbar med den blockstorlek som DCT använder annars kommer bilden försämras, då pixlarnas omfång måste ändras. Man kan tänka sig att man viker ett papper för att komprimera det, när man sedan viker upp pappret så har man ett veck som har försämrats papprets fina yta. FMT omvandlar bildinformationen endast med hjälp av aritmetiska operationer, så den behåller pixlarnas omfång även efter transformationen [18]. Det är detta som gör att bilden inte kommer att försämras på samma sätt som vid JPEG kompression. När FMT är implementerat så är det bara att köra AES precis som vanligt. Hastigheten för denna variant ligger då på cirka 0,5 MB/s på en 1 GHz Pentium IV dator [16]. 5.2 Säker överföring För att åstadkomma säker överföring finns det egentligen bara två metoder att välja på och de är väldigt lika, SSL och TLS. Man kan självklart implementera sin egen metod eller bara kryptera all data hos klienten och sedan dekryptera den hos servern. Men då kanske användaren inte känner sig lika säker, samt att man måste testa sin säkerhet mot att bara köra SSL eller TLS och veta att det är flera som står bakom den säkerheten. 9
5.2.1 SSL SSL (Secure Socket Layer) utvecklades av Netscape och är idag en vanlig metod att använda för att åstadkomma säker överföring mellan två datorer. Tanken är att all information som går mellan de två datorerna ska vara krypterad, så att ingen annan kan manipulera eller avlyssna det som skickas. SSL hjälper även till med att identifiera den dator man vill kommunicera med [20 s.41]. Detta för att man ska undvika Man in the middle -attacker eller rent lurendrejeri. En av SSL:s fördelar är att informationen skickas oförändrad mellan datorerna, vilket gör så att nästan alla protokoll som kan köras över TCP kan även köras över SSL. Det protokollet som används mest med SSL är HTTP [20 s.51] som vid användning med SSL kallas för HTTPS, där det tillagda S:et står för secure. Bild 5 - Hur en SSL handskakning går till. För att initiera en säker SSL-anslutning så gör man en så kallad handskakning. Där klienten och servern hälsar på varandra och utbyter nödvändig information. Bild 5 visar hur handskakningen går till samt vad som skickas mellan servern och klienten. Detta gör så att man kan autentisera servern samt komma överens om de nycklar som man behöver för att kunna kryptera informationen som ska skickas. Informationen som ska skickas delas upp i mindre delar som sedan krypteras och skickas var och ett för sig. Innan varje del krypteras lägger man till något som kallas MAC (Message Authentication Code). MAC:en är där för att ge varje del integritet och autenticitet, detta gör den genom att köra informationen genom en hash-funktion som tar in en nyckel (känd av mottagaren). När mottagaren sedan har dekrypterat informationen kan han köra samma hash-funktion med samma nyckel och sedan jämföra den MAC som skickades med med den han skapade [20 s.61]. I bild 6 visas hur SSL paketen byggs upp från data. 10
Bild 6 - SSL paketens uppbyggnad från den data som skickas. Säkerheten i SSL beror på ett antal parametrar, dessa bör därför hållas i tryggt förvar och vara noggrant valda. Exempel på sådana parametrar är: serverns privata nyckel, använda en bra slumptalsgenerator vid handskakningen, kontrollera och lita endast på godkända certifikat samt välja en bra krypteringsalgoritm [20 s.140]. SSL är inte så snabbt som man skulle önska. Beroende på protokoll som används, serverhårdvara och nätverket så kan SSL anslutningar vara 2 till 100 gånger långsammare än vanliga TCP-anslutningar [20 s.175]. Att undvika prestandaförsämringar vid användning av SSL är omöjligt då all information som ska skickas måste krypteras, vilket är en beräkningstung process. En annan faktor som tar tid är handskakningarna, men även här är det kryptering och dekryptering som tar mest tid. Handskakningen sker endast en gång per anslutning så den tidskostnaden är oftast försumbar. 5.2.2 TLS TLS är IETF standard som utvecklades från SSLv3 och de två protokollen är väldigt lika [6]. De två största skillnaderna är att TLS är bakåtkompatibelt med tidigare versioner av SSL, det vill säga den kan skala ner till en mindre säker version ifall klienten inte stödjer TLS. TLS var inte bakåtkompatibelt från början, anledningen till att detta kom till var att TLS krävde trippel DES kryptering (3DES). Enligt Amerikansk lag så var det förbjudet att exportera kryptografi starkare än 40 bitar (3DES har 56, 112 eller 168 bitars nyckel [10]). Detta gjorde att man antingen kunde köra TLS inom USA med 3DES, eller inte köra 3DES och då kunna använda applikationen internationellt [20]. Den andra skillnaden är att TLS inte bara kan skicka trafik i säkert läge. TLS gör sin handskakning helt öppet och skulle något gå fel så avbryts anslutningen. Detta gör att man kan ha både säkra och osäkra anslutningar på samma port [7] (detta kan alltså inte SSL). SSL är det protokoll som används mest av de båda, detta på grund av historiska skäl. Det kom först och blev implementerat i HTTPS och används fortfarande där. 11
6. Metodik AES i CBC läge samt 3D Chaotic Baker Maps har testats för att se hur hastigheterna skiljer sig för de båda algoritmerna. Se bilaga 3 för en lista över de bilder som har krypterats. Varje bild har testats i fyra olika format: BMP, JPEG, PNG och TIF. Där TIF och BMP är okomprimerade till skillnad mot JPEG och PNG som är komprimerade. Det är olika bilder för olika upplösningar detta mest för att det var lättare att hålla koll på vilken bild som hade vilken upplösning. Upplösningarna är 800x600, 1024x768 samt 2048x1536. Tiden mättes under att varje enskild bild krypterades och dekrypterades, detta upprepades sedan tio gånger för att få en bättre bild av mätdatat. Allt testades på en Intel Core i3 M330 2.13GHz, 3,68 GB RAM dator. Det ska noteras att endast prestanda i tid testas för de båda algoritmerna, det vill säga inga säkerhetstest. En proof-of-concept applikation har även utvecklats i Silverlight, där C#:s standardimplementation av AES användes för att kryptera bilderna. Här testades att ladda upp bilder i klump samt var eventuella flaskhalsar kan uppstå i applikationen. I bilaga 5 finns en skärmdump av applikationens utseende. 12
Krypteringstid (ms) 7. Resultat 7.1 Vad används för att kryptera bilderna idag? De sidor som är utvecklade för backup (KeepIt, Storegate och Dropbox) krypterar både överföring och lagring av datan. Eftersom det inte bara är bilder som lagras hos dem så krypteras informationen av olika AES varianter då det är en säker krypteringsalgoritm på all typ av data. Överföringen görs med SSL hos alla tre sidorna, vilket inte är så förvånande då detta är en välkänd och bra metod för att överföra data säkert. Facebook och Flickr är inte gjorda för att användas som backup för bilder och därför bryr de sig inte om att kryptera. Det skulle dessutom kosta resurser för att erbjuda sina användare kryptering av bilder, vilket de troligtvis inte vill spendera. Bilderna sparas i orginalstorlek på servern men för att minska på datatrafiken så förminskar Facebook och Flickr bilderna. Detta medför att de inte används för backup i samma utsträckning som om man kunde spara bilderna i deras originalstorlek. 7.2 Krypteringsalgoritmer Här följer ett urval av de diagram som skapades utifrån resultaten av testen som beskrevs i metodikkapitlet. Alla diagram och mätvärden finns att se i bilaga 4. Det man kan se genomgående i alla diagrammen är att AES prestanda varierar mer beroende på komprimeringsformatet medan 3D Chaotic Baker Maps (Baker) har liknande mätvärden oberoende på komprimeringsformat. Detta beror på att AES bygger på att man krypterar datan, alltså kommer de format som är mindre komprimerade ta mer tid än de andra. Baker håller bara på med pixelomvandling och baseras därför på bildstorleken och inte filstorleken. Alltså går Baker fortare än AES för råformat så som BMP och TIF, men för format som är komprimerade hårt (JPG i detta test) så vinner AES. Med PNG, som är lite lättare komprimerad, skiljer inte så mycket i tid mellan Baker och AES. 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 Testnr. AES BMP AES JPG AES PNG AES TIF Baker BMP Baker JPG Baker PNG Baker TIF Diagram 1 Penguins 800x600 13
Krypteringstid (ms) Krypteringstid (ms) 400 350 300 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 AES BMP AES JPG AES PNG AES TIF Baker BMP Baker JPG Baker PNG Baker TIF Testnr. Diagram 2 Jellyfish 1024x768 1600 1400 1200 1000 800 600 400 200 0 1 2 3 4 5 6 7 8 9 10 AES BMP AES JPG AES PNG AES TIF Baker BMP Baker JPG Baker PNG Baker TIF Testnr. Diagram 3 Hydrangeas 2048x1536 I proof-of-concept applikationen testades det att ladda upp 10, 100 och 1000 bilder. Flaskhalsar som observerades var att om man tog hand om alla bilder på en gång i applikationens egen tråd, så kraschade webbläsaren som Silverlight applikationen kördes i. Lösningen på denna något självklara flaskhals var att initiera en ny tråd som hanterade uppladdningen av bilderna. Denna tråd itererade över bilderna och läste in, krypterade samt skickade iväg en bild i taget. Detta ledde till att man kan utnyttja köer i vid krypteringen, webbservicen och databasen. Man skulle kunna tänka sig att använda mer än en tråd och parallellisera hela processen, detta skulle hjälpa vid tillfällen då man laddar upp många bilder. Men då skulle köerna till webbservicen växa snabbare, vilket kan bidra till en ny flaskhals. Att ladda upp 100 bilder i storleken 1024x768 med JPG komprimering, med en total storlek av cirka 60 MB, tog cirka 35 s på en Intel Core i3 M330 2.13 GHz, 3,68 GB RAM dator. Hur applikationen ser ut under uppladdning kan ses i bild 7 nedan. När man använder sig av en extra tråd samt köer så blir tiden för krypteringen av varje bild densamma, oavsett hur många bilder man väljer att ladda upp. Denna tid låg på cirka 0,050 s/bild för bilder av på samma dator som ovan, det vill säga totalt cirka 5 s för alla hundra bilderna. 14
Bild 7 I väntan på att 100 bilder ska laddas upp till applikationen visas en laddningsruta där man bland annat ser en progressbar över hur stor del av bilderna som är klara. Totalt tog uppladdningen cirka 35 s varav 5 s bestod av krypteringen. 7.3 Säker överföring Det är inte mycket som skiljer SSL och TLS från varandra, men en sak är klar och det är att det inte finns något som konkurrerar med dem för säker överföring. Idag är SSL vanligast vid HTTP och detta av mest av historiska själ då SSL kom före. Många böcker och artiklar lägger in TLS under SSL, så när de skriver om SSL kan de lika gärna syfta på TLS också. Så lite skiljer det mellan de båda. Strävar man efter säker överföring är SSL eller TLS ett måste. 7.4 Vem ansvarar för bildernas innehåll? Det finns inget direkt liknande fall där man just hanterar krypterade bilder men de lagar kapitel 4.4 nämner är de lagar som bäst stämmer in på denna fråga. Den tänkta bild-backuptjänsten som diskuteras i detta examensarbete kommer att erbjuda tre funktioner som stämmer in på dessa lagar. De är: 1. Anslagstavla i form av att du ska kunna dela med dig av dina album med hjälp av lösenord och länk. 2. Passiv tjänst, då användaren själva laddar upp bilderna. 3. Att tillhandahållaren av tjänsten inte vet vad bilderna innehåller. Det man bör göra för att kunna åberopa ansvarsfrihet är följande saker: 1. Implementera en så kallad klagomur där användare av tjänsten kan informera tillhandahållaren om olagligheter. 2. Inte modifiera eller sortera den data som användaren lagrar med hjälp av tjänsten. 3. Se till att hela tjänsten är en passiv tjänst, det vill säga användaren måste aktivt ladda upp sina bilder. 4. Se till att användaren blir informerad om vad som inte är tillåtet, samt att tillhandahållaren förbehåller sig rätten att ta bort eventuella bilder utan förvarning. Eftersom det inte har funnits fall av liknande karaktär vid en domstol är detta lite av en gråzon i den svenska lagen. 15
8. Slutsatser Skillnaden i tid det tar för att kryptering och dekryptering med AES respektive 3D Chaotic Baker Maps varierar beroende på filstorlek och bildstorlek. Och visst kan man se en fördel för 3D Chaotic Baker Maps när det kommer till bilder som är lite eller icke komprimerade, men algoritmen faller på sin okändhet och att de flesta bilder oftast sparas komprimerade. AES är en standard som är välkänd och välanvänd, vilket innebär att säkerheten är bättre testad och övervakad. Även är det faktum att fler användare troligen känner till AES före 3D Chaotic Baker Maps är viktig då det är användaren som ska känna sig trygg att ladda upp sina bilder. AES är alltså det rekommenderade alternativet när det gäller att kryptera bilderna. I kapitel 7.2 stod det att läsa att medeltiden för att kryptera en 1024x768 bild med C#:s version av AES var 0,049 s/bild på den datorn. Varför krypterar inte då fler sidor bilderna? Det man måste tänka på här är att Silverlight applikationen som testades i kapitel 7.2 krypterar bilderna på klientens dator och skickar dem till servern. Detta är möjligt tack vare att Silverlight kör C# i bakgrunden och är en webbapplikation som laddas ner till webbläsaren och körs på klientdatorn. Facebook finns i många former och flera av dem har inte stöd att köra AES kod på klienten. Det resulterar i att de skulle behöva kryptera bilderna på servern och det är då det blir kostsamt för deras del. Att köra FMT innan AES är inte helt aktuellt då de flesta använder JPEG eller PNG format redan innan de laddar upp bilderna. Detta skulle då endast resultera i onödigt arbete som tar tid. Dessutom har JPEG så kallad EXIF taggar där information som till exempel kameramodell och datum då bilden togs sparas. Denna information går man miste om när man använder FMT. När det kommer till överföringen kvittar det fullständigt om man väljer TLS eller SSL. De är så lika att i de flesta böcker och artiklar syftar man till båda när man skriver om SSL. SSL är en självklarhet för den här aktuella applikationen. Vad man måste göra för att garanterat få ansvarsfrihet kan man inte säga. Det finns många möjligheter som skulle kunna åberopas vid eventuell dom. Däremot är sannolikheten liten att någon utomstående skulle upptäcka eventuella brottsligheter då bilderna alltid är krypterade förutom när de visas på användarens skärm. 16
Litteraturförteckning Webbsidor Adress Information hämtad [1] https://www.keepit.com/howitworks 2010-09-01 [2] https://www.dropbox.com/features 2010-08-29 [3] http://www.storegate.se/110.aspx?pricor=0&service_id=29 2010-08-29 [4] http://www.facebook.se 2010-08-30 [5] http://www.flickr.com 2010-08-30 [6] http://en.wikipedia.org/wiki/transport_layer_security 2010-09-08 [7] http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html 2010-09-06 [8] http://www.wireshark.org/ 2010-09-01 [9] https://kattis.csc.kth.se/problem?id=aes 2010-09-15 [10] http://en.wikipedia.org/wiki/triple_des 2010-09-16 [11] http://www.open-image.org/openimageframe.asp 2010-10-01 [12] http://www.mathworks.com/matlabcentral/fileexchange 2010-10-01 [13] http://www.notisum.se/rnp/sls/lag/19980112.htm 2010-10-22 [14] http://www.notisum.se/rnp/sls/lag/20020562.htm 2010-10-22 Artiklar [15] M. Yaobin et al, A Novel Fast Image Encryption Scheme Based On 3D Chaotic Baker Maps, International Journal of Bifurcation and Chaos, Vol. 14 No. 10 (2004) 3613-3624, World Scientific Punblishing Company [16] M. Benabdellah et al, Encryption-Compression of Images Based on FMT and AES Algorithm, Applied Mathematical Sciences, Vol. 1 No. 45 (2007) 2203-2219, Université Mohamed V Agdal [17] X. Tong et al, Image encryption scheme based on 3D baker with dynamical compound chaotic sequence cipher generator, Signal Processing 89 (2009) 480-491, Elsevier B.V. [18] H. Douzi et al, Faber-Schauder Wavelet Transform, Application to Edge Detection and Image Characterization, Journal of Mathematical Imaging and Vision 14 (2001) 91-101, Kluwer Academic Publishers [19] J. Jacobsson, Internetauktioners ansvar för de objekt som säljs via tjänsten, Juridiska fakulteten vid Lunds universitet, 2009
Böcker [20] E. Rescorla, SSL and TLS Designing and Building Secure Systems, Addison Wesley 2001, ISBN 0201615983 [21] D. Stinson, Cryptography Theory And Practice, Third Edition, Chapman & Hall/CRC 2006,ISBN 1584885084
Bilagor Bilaga 1, 3D Chaotic Baker Maps i C++ /* permute a vector with random number A --- resource array length_of_a --- length of vector A seed --- random seed times --- times of permutation Example: Permute_N_Point([1,2,3,4,5], 80, 3); result:[4 1 3 5 2] */ void Permute_N_Point( int * A, int length_of_a, unsigned int seed, int times) { int t, i, Pos, tmp; unsigned int seed1; seed1 = seed; for ( t = 0; t < times; t++) { srand(seed1); seed1 = rand(); for ( i = 0; i < length_of_a; i++) { Pos = rand() * i/rand_max; tmp = A[i]; A[i] = A[Pos]; A[Pos] = tmp; return; /* from 2D to 3D */ /* get WxLxH from a WidthxHeight image */ void Get_2D_to_3D_parameters( int width, int height, /* original 2D image's width and height*/ int * W, int * L, int * H, /* decomposed W(idth),L(ength) and H(eight) of a cube */ int seed_key, int shuffle_times) /* two keys represent seed and shuffle times respectively */ { int * data; FACTOR_LIST * lst; int n, tmp; n = width * height; lst = creat_factor_list(); int num = get_factors( n, lst); data = new int [num]; num = get_all_factors( lst, data ); lst = delete_all_element(lst); Permute_N_Point( data, num, seed_key, shuffle_times); * W = 1; * L = 1; * H = 1; for (int i = 0; i < num; i = i+3) { * W = (* W) * data[i]; if ( (i+1) < num ) * L = (* L) * data[i+1]; if ( (i+2) < num ) * H = (* H) * data[i+2]; delete data; if ( (*W) < (*H) ) { tmp = *W; *W = *H; *H = tmp; if ( (*L) < (*H) ) {
tmp = *L; *L = *H; *H = tmp; return; #define MAX_INTERVAL 30 void key_generation(char * key, int length, int width, int colors, int * key_l, int * num_key_l, int * key_w, int * num_key_w, double * logistic_key, int * XOR_key, int * seed_key, int * shuffle_times) { double Lo1; int remain, key_counter,tmp, Interval, i; char tp; /* generate key_l */ Lo1 = ((key[0]*256.0 + key[1])*256.0 + key[2])/16777216.0; if ( (Lo1 <= 0) (Lo1 >=1) (Lo1 == 0.5) ) Lo1 = 0.5001; /* three bad point 0,1 and 0.5 */ for (i = 0; i < 50 + key[0]; i++) Lo1 = 4.0*Lo1*(1.0-Lo1); remain = length; Interval = remain > MAX_INTERVAL? MAX_INTERVAL : remain; key_counter = 0; do { do { Lo1 = 4.0*Lo1*(1.0-Lo1); while( (Lo1<0.2) (Lo1>0.8) ); Interval = remain > MAX_INTERVAL? MAX_INTERVAL : remain; tmp = (int)(interval*(lo1-0.2)/0.6); if ( tmp > 0 ) { key_l[key_counter] = tmp; remain = remain-key_l[key_counter++]; while( remain>1 ); if (remain == 1) key_l[key_counter++] = remain; * num_key_l = key_counter; /* generate key_w */ Lo1 = ((key[3]*256.0 + key[4])*256.0 + key[5])/16777216.0; if ( (Lo1 <= 0) (Lo1 >=1) (Lo1 == 0.5) ) Lo1 = 0.5001; /* three bad point 0,1 and 0.5 */ for (i = 0; i < 50 + key[3]; i++) Lo1 = 4.0*Lo1*(1.0-Lo1); remain = width; Interval = remain > MAX_INTERVAL? MAX_INTERVAL : remain; key_counter = 0; do { do { Lo1 = 4.0*Lo1*(1.0-Lo1); while( (Lo1<0.2) (Lo1>0.8) ); Interval = remain > MAX_INTERVAL? MAX_INTERVAL : remain; tmp = (int)(interval*(lo1-0.2)/0.6); if ( tmp > 0 ) { key_w[key_counter] = tmp; remain = remain-key_w[key_counter++]; while( remain>1 ); if (remain == 1) key_w[key_counter++] = remain; * num_key_w = key_counter; /* generate logistic_key */ Lo1 = ((key[6]*256.0 + key[7])*256.0 + key[8])/16777216.0; if ( (Lo1 <= 0) (Lo1 >=1) (Lo1 == 0.5) ) Lo1 = 0.5001; /* three bad point 0,1 and 0.5 */ for (i = 0; i < 100 + key[6]; i++) Lo1 = 4.0*Lo1*(1.0-Lo1); * logistic_key = Lo1; /* generate XOR key */
switch(colors) { case 2: tp = key[9] ^ key[10] ^ key[11]; tp = (tp&0x0f) ^ ((tp&0xf0)>>4); tp = (tp&0x03) ^ ((tp&0x0c)>>2); * XOR_key = (tp&0x01) ^ ((tp&0x02)>>1); break; case 16: * XOR_key = (key[9]&0x0f) ^ ((key[9]&0xf0)>>4) ^ (key[10]&0x0f) ^ ((key[10]&0xf0)>>4) ^ (key[11]&0x0f) ^ ((key[11]&0xf0)>>4); break; case 256: * XOR_key = key[9] ^ key[10] ^ key[11]; break; case 24: default: * XOR_key = ((int)(key[9])*256 + key[10])*256 + key[11]; break; /* generate seed_key */ * seed_key = (int)(key[12])*256+key[13]; /* generate shuffle_times */ * shuffle_times = (int)key[14]+key[15]; if ((*shuffle_times) < 5) * shuffle_times = 5; /* permute key_l and key_w */ Permute_N_Point( key_l, * num_key_l, (unsigned int) * seed_key, * shuffle_times); Permute_N_Point( key_w, * num_key_w, (unsigned int) * seed_key, * shuffle_times); return;
Bilaga 2, AES i C++ #include <iostream> using namespace std; void keyexpansion(unsigned char *key, unsigned char *expandedkey); void chiper(unsigned char *block, unsigned char *expandedkey); void addroundkey(unsigned char *expandedkey, unsigned char *block, int round); void mixcolumns(unsigned char *block); void rotword(unsigned char *word, int steps); //Initiera den fina S-boxen char sbox[] = { 0x63,0x7c,0x77,0x7b,0xf2,0x6b,0x6f,0xc5,0x30,0x01,0x67,0x2b,0xfe,0xd7,0xab,0x76, 0xca,0x82,0xc9,0x7d,0xfa,0x59,0x47,0xf0,0xad,0xd4,0xa2,0xaf,0x9c,0xa4,0x72,0xc0, 0xb7,0xfd,0x93,0x26,0x36,0x3f,0xf7,0xcc,0x34,0xa5,0xe5,0xf1,0x71,0xd8,0x31,0x15, 0x04,0xc7,0x23,0xc3,0x18,0x96,0x05,0x9a,0x07,0x12,0x80,0xe2,0xeb,0x27,0xb2,0x75, 0x09,0x83,0x2c,0x1a,0x1b,0x6e,0x5a,0xa0,0x52,0x3b,0xd6,0xb3,0x29,0xe3,0x2f,0x84, 0x53,0xd1,0x00,0xed,0x20,0xfc,0xb1,0x5b,0x6a,0xcb,0xbe,0x39,0x4a,0x4c,0x58,0xcf, 0xd0,0xef,0xaa,0xfb,0x43,0x4d,0x33,0x85,0x45,0xf9,0x02,0x7f,0x50,0x3c,0x9f,0xa8, 0x51,0xa3,0x40,0x8f,0x92,0x9d,0x38,0xf5,0xbc,0xb6,0xda,0x21,0x10,0xff,0xf3,0xd2, 0xcd,0x0c,0x13,0xec,0x5f,0x97,0x44,0x17,0xc4,0xa7,0x7e,0x3d,0x64,0x5d,0x19,0x73, 0x60,0x81,0x4f,0xdc,0x22,0x2a,0x90,0x88,0x46,0xee,0xb8,0x14,0xde,0x5e,0x0b,0xdb, 0xe0,0x32,0x3a,0x0a,0x49,0x06,0x24,0x5c,0xc2,0xd3,0xac,0x62,0x91,0x95,0xe4,0x79, 0xe7,0xc8,0x37,0x6d,0x8d,0xd5,0x4e,0xa9,0x6c,0x56,0xf4,0xea,0x65,0x7a,0xae,0x08, 0xba,0x78,0x25,0x2e,0x1c,0xa6,0xb4,0xc6,0xe8,0xdd,0x74,0x1f,0x4b,0xbd,0x8b,0x8a, 0x70,0x3e,0xb5,0x66,0x48,0x03,0xf6,0x0e,0x61,0x35,0x57,0xb9,0x86,0xc1,0x1d,0x9e, 0xe1,0xf8,0x98,0x11,0x69,0xd9,0x8e,0x94,0x9b,0x1e,0x87,0xe9,0xce,0x55,0x28,0xdf, 0x8c,0xa1,0x89,0x0d,0xbf,0xe6,0x42,0x68,0x41,0x99,0x2d,0x0f,0xb0,0x54,0xbb,0x16; //Förkalkulerad multiplicationstabellen för multiplication med 2 och 3 char mult2[256] = { 0x00,0x02,0x04,0x06,0x08,0x0a,0x0c,0x0e,0x10,0x12,0x14,0x16,0x18,0x1a,0x1c,0x1e, 0x20,0x22,0x24,0x26,0x28,0x2a,0x2c,0x2e,0x30,0x32,0x34,0x36,0x38,0x3a,0x3c,0x3e, 0x40,0x42,0x44,0x46,0x48,0x4a,0x4c,0x4e,0x50,0x52,0x54,0x56,0x58,0x5a,0x5c,0x5e, 0x60,0x62,0x64,0x66,0x68,0x6a,0x6c,0x6e,0x70,0x72,0x74,0x76,0x78,0x7a,0x7c,0x7e, 0x80,0x82,0x84,0x86,0x88,0x8a,0x8c,0x8e,0x90,0x92,0x94,0x96,0x98,0x9a,0x9c,0x9e, 0xa0,0xa2,0xa4,0xa6,0xa8,0xaa,0xac,0xae,0xb0,0xb2,0xb4,0xb6,0xb8,0xba,0xbc,0xbe, 0xc0,0xc2,0xc4,0xc6,0xc8,0xca,0xcc,0xce,0xd0,0xd2,0xd4,0xd6,0xd8,0xda,0xdc,0xde, 0xe0,0xe2,0xe4,0xe6,0xe8,0xea,0xec,0xee,0xf0,0xf2,0xf4,0xf6,0xf8,0xfa,0xfc,0xfe, 0x1b,0x19,0x1f,0x1d,0x13,0x11,0x17,0x15,0x0b,0x09,0x0f,0x0d,0x03,0x01,0x07,0x05, 0x3b,0x39,0x3f,0x3d,0x33,0x31,0x37,0x35,0x2b,0x29,0x2f,0x2d,0x23,0x21,0x27,0x25, 0x5b,0x59,0x5f,0x5d,0x53,0x51,0x57,0x55,0x4b,0x49,0x4f,0x4d,0x43,0x41,0x47,0x45, 0x7b,0x79,0x7f,0x7d,0x73,0x71,0x77,0x75,0x6b,0x69,0x6f,0x6d,0x63,0x61,0x67,0x65, 0x9b,0x99,0x9f,0x9d,0x93,0x91,0x97,0x95,0x8b,0x89,0x8f,0x8d,0x83,0x81,0x87,0x85, 0xbb,0xb9,0xbf,0xbd,0xb3,0xb1,0xb7,0xb5,0xab,0xa9,0xaf,0xad,0xa3,0xa1,0xa7,0xa5, 0xdb,0xd9,0xdf,0xdd,0xd3,0xd1,0xd7,0xd5,0xcb,0xc9,0xcf,0xcd,0xc3,0xc1,0xc7,0xc5, 0xfb,0xf9,0xff,0xfd,0xf3,0xf1,0xf7,0xf5,0xeb,0xe9,0xef,0xed,0xe3,0xe1,0xe7,0xe5; char mult3[256] = { 0x00,0x03,0x06,0x05,0x0c,0x0f,0x0a,0x09,0x18,0x1b,0x1e,0x1d,0x14,0x17,0x12,0x11, 0x30,0x33,0x36,0x35,0x3c,0x3f,0x3a,0x39,0x28,0x2b,0x2e,0x2d,0x24,0x27,0x22,0x21, 0x60,0x63,0x66,0x65,0x6c,0x6f,0x6a,0x69,0x78,0x7b,0x7e,0x7d,0x74,0x77,0x72,0x71, 0x50,0x53,0x56,0x55,0x5c,0x5f,0x5a,0x59,0x48,0x4b,0x4e,0x4d,0x44,0x47,0x42,0x41, 0xc0,0xc3,0xc6,0xc5,0xcc,0xcf,0xca,0xc9,0xd8,0xdb,0xde,0xdd,0xd4,0xd7,0xd2,0xd1, 0xf0,0xf3,0xf6,0xf5,0xfc,0xff,0xfa,0xf9,0xe8,0xeb,0xee,0xed,0xe4,0xe7,0xe2,0xe1, 0xa0,0xa3,0xa6,0xa5,0xac,0xaf,0xaa,0xa9,0xb8,0xbb,0xbe,0xbd,0xb4,0xb7,0xb2,0xb1, 0x90,0x93,0x96,0x95,0x9c,0x9f,0x9a,0x99,0x88,0x8b,0x8e,0x8d,0x84,0x87,0x82,0x81, 0x9b,0x98,0x9d,0x9e,0x97,0x94,0x91,0x92,0x83,0x80,0x85,0x86,0x8f,0x8c,0x89,0x8a, 0xab,0xa8,0xad,0xae,0xa7,0xa4,0xa1,0xa2,0xb3,0xb0,0xb5,0xb6,0xbf,0xbc,0xb9,0xba, 0xfb,0xf8,0xfd,0xfe,0xf7,0xf4,0xf1,0xf2,0xe3,0xe0,0xe5,0xe6,0xef,0xec,0xe9,0xea, 0xcb,0xc8,0xcd,0xce,0xc7,0xc4,0xc1,0xc2,0xd3,0xd0,0xd5,0xd6,0xdf,0xdc,0xd9,0xda, 0x5b,0x58,0x5d,0x5e,0x57,0x54,0x51,0x52,0x43,0x40,0x45,0x46,0x4f,0x4c,0x49,0x4a, 0x6b,0x68,0x6d,0x6e,0x67,0x64,0x61,0x62,0x73,0x70,0x75,0x76,0x7f,0x7c,0x79,0x7a, 0x3b,0x38,0x3d,0x3e,0x37,0x34,0x31,0x32,0x23,0x20,0x25,0x26,0x2f,0x2c,0x29,0x2a, 0x0b,0x08,0x0d,0x0e,0x07,0x04,0x01,0x02,0x13,0x10,0x15,0x16,0x1f,0x1c,0x19,0x1a; int main(){ //Läser in input från kattis och parsar och utför AES //Initiera variabler för nyckeln och den förlängda nyckeln som vi förkalkulerar //Nyckeln är 16 byte stor (128 bitar) och vi behöver använda //11 nycklar totalt i AES (när vi har 128 bitars nyckel) unsigned char key[16], expandedkey[11*16], block[16]; fread(((char*)key), 1, 16, stdin); //Förläng nyckeln i förväg så sparar vi tid senare keyexpansion(key, expandedkey);
//Kryptera blocken while(fread(((char*)block), 1, 16, stdin) == 16){ chiper(block, expandedkey); fwrite(((char*)block), 1, 16, stdout); //Förlänger nyckeln, tar in en pekare till nyckeln samt en till den förlängda nyckeln void keyexpansion(unsigned char *key, unsigned char *expandedkey){ //Initiera "roundconstants" till deras värden unsigned char RCon[] = {0x1,0x2,0x4,0x8,0x10,0x20,0x40,0x80,0x1B,0x36; //Initiera en tempvariabel unsigned char tmp[4]; //Den första delen ska vara självaste nyckeln for(int i=0; i<16; i++){ expandedkey[i] = key[i]; //För självaste expansionen gör följande for(int i=16; i<176; i+=4){ //Spara in de föregående 32 bytesen av nyckeln i tmp tmp[0] = expandedkey[i-4]; tmp[1] = expandedkey[i-3]; tmp[2] = expandedkey[i-2]; tmp[3] = expandedkey[i-1]; if(i%16 == 0){ //Rotera ordet med 1 åt vänster rotword(tmp, 1); //Tillämpa sboxen på ordet tmp[0] = sbox[tmp[0]]; tmp[1] = sbox[tmp[1]]; tmp[2] = sbox[tmp[2]]; tmp[3] = sbox[tmp[3]]; //Gör XOR med roundconstant //(eftersom bara första byten är satt i RCon så räcker det med tmp[0]) tmp[0] = tmp[0] ^ RCon[i/16-1]; //XOR mellan vårt temporära ord och ordet vi hade för 4 rundor sedan expandedkey[i] = expandedkey[i-16] ^ tmp[0]; expandedkey[i+1] = expandedkey[i-15] ^ tmp[1]; expandedkey[i+2] = expandedkey[i-14] ^ tmp[2]; expandedkey[i+3] = expandedkey[i-13] ^ tmp[3]; void chiper(unsigned char *block, unsigned char *expandedkey){ unsigned char word[4]; //Lägg runda nolls nyckel addroundkey(expandedkey, block, 0); //för alla rundor upp till 10 for(int round=1; round<10; round++){ //Tillämpa sboxen på blocket for(int b=0; b<16; b++) block[b] = sbox[block[b]]; //Förskjut raderna for(int w=0; w<4; w++){ word[0] = block[w]; word[1] = block[w+4]; word[2] = block[w+8]; word[3] = block[w+12]; rotword(word, w); block[w] = word[0]; block[w+4] = word[1]; block[w+8] = word[2]; block[w+12] = word[3]; //Tillämpa mixkolumns mixcolumns(block); //Lägg till rundans nyckel addroundkey(expandedkey, block, round);
//Tillämpa sboxen på blocket for(int b=0; b<16; b++) block[b] = sbox[block[b]]; //Förskjut raderna for(int w=0; w<4; w++){ word[0] = block[w]; word[1] = block[w+4]; word[2] = block[w+8]; word[3] = block[w+12]; rotword(word, w); block[w] = word[0]; block[w+4] = word[1]; block[w+8] = word[2]; block[w+12] = word[3]; //Lägg till sista rundans nyckel addroundkey(expandedkey, block, 10); //Lägg till rundans nyckel genom att XORa med den mot blocket void addroundkey(unsigned char *expandedkey, unsigned char *block, int round){ for(int c=0; c<16; c+=4){ block[c] = block[c] ^ expandedkey[c+(round*16)]; block[c+1] = block[c+1] ^ expandedkey[c+(round*16 + 1)]; block[c+2] = block[c+2] ^ expandedkey[c+(round*16 + 2)]; block[c+3] = block[c+3] ^ expandedkey[c+(round*16 + 3)]; //Utför mixakolumner från Fips void mixcolumns(unsigned char *block){ unsigned char block0, block1, block2, block3; for(int c=0; c<16; c+=4){ block0 = block[c]; block1 = block[c+1]; block2 = block[c+2]; block3 = block[c+3]; block[c] = mult2[block0] ^ mult3[block1] ^ block2 ^ block3; block[c+1] = mult2[block1] ^ mult3[block2] ^ block3 ^ block0; block[c+2] = mult2[block2] ^ mult3[block3] ^ block0 ^ block1; block[c+3] = mult2[block3] ^ mult3[block0] ^ block1 ^ block2; //Rotera ett ord steps antal steg void rotword(unsigned char *word, int steps){ //Initiera en tempvariabel unsigned char tmp; switch (steps){ case 1: tmp = word[0]; word[0] = word[1]; word[1] = word[2]; word[2] = word[3]; word[3] = tmp; return; case 2: tmp = word[1]; word[1] = word[3]; word[3] = tmp; tmp = word[2]; word[2] = word[0]; word[0] = tmp; return; case 3: tmp = word[0]; word[0] = word[3]; word[3] = word[2]; word[2] = word[1]; word[1] = tmp; return;
Bilaga 3, Bild-lista Bilderna Chrysanthemum och Penguins hade upplösningen 800x600 pixlar och 24 bitars färgdjup. Bilderna Jellyfish och Tulips hade upplösningen 1024x768 pixlar och 24 bitars färgdjup. Bilderna Hydrangeas och Koala hade upplösningen 2048x1536 pixlar och 24 bitars färgdjup. Bilderna är Windows 7 exempelbilder. Alla sex bilderna konverterades til BMP, PNG och Tif format från deras orginalformat jpg.
Bilaga 4, Testvärden