Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Säkerhetsanalys av Android som plattform för
företagsapplikationer
av
Per Jinnegren och Erik Thorselius
LIU-IDA/LITH-EX-A-11/033-SE
2011-10-24
Linköpings universitet SE-581 83 Linköping, Sweden
Linköpings universitet 581 83 Linköping
Examensarbete
S¨
akerhetsanalys av Android som plattform f¨
or
f¨
oretagsapplikationer
avPer Jinnegren Erik Thorselius
LIU-IDA/LITH-EX-A–11/033–SE
Handledare : Andreas Olofsson
Avdelningen f¨or mobila plattformar vid HOW Solutions
Examinator : Nahid Shahmehri
Institutionen f¨or datavetenskap vid Link¨opings universitet
Sammandrag
I rapporten unders¨oks s¨akerhetsaspekter f¨or f¨oretagsapplikationer utveckla-de till androidplattformen. Rapporten tar ¨aven upp Androids grunder och dess s¨akerhetsmodell. Syftet med rapporten var att unders¨oka Androids l¨amplighet f¨or projekt som HOW Solutions har planerade. Under arbetet har en applikation f¨or tr˚adl¨os ¨oppning av l˚as utvecklats. Resultatet var att m˚anga av de hot som uppt¨acktes var, f¨or f¨oretag, i vissa fall ¨ar sv˚ a-ra att mitigea-ra och att viss relevant funktionalitet saknas p˚a plattformen. Trots det ¨ar slutsatsen att Android ¨ar en mogen plattform med ett gediget s¨akerhetsarbete och d¨arf¨or l¨ampar sig bra f¨or f¨oretagsapplikationer.
Nyckelord : Android, S¨akerhet, Abuse cases, STRIDE, Sandbox, Root
Tack
Vi vill tacka b˚ade IDA och HOW Solutions som har m¨ojliggjort examens-arbetet. Andreas Olofsson som har visat ett stort intresse som handledare och Nahid Shahmehri som har varit en bra examinator. Vi vill ocks˚a tacka Frida Str˚alin som har tagit sig tid och kommenterat v˚ar rapport. Sist vill vi tacka oss sj¨alva, det har varit ett riktigt bra samarbete!
Inneh˚
all
Figurer viii Tabeller 1 1 Inledning 2 1.1 Syfte . . . 3 1.2 Bakgrund . . . 3 1.3 Problemformulering . . . 3 1.3.1 Beskrivning . . . 3 1.4 Avgr¨ansningar . . . 4 2 Metodik 5 2.1 Metoder i litteraturen . . . 5 2.2 Metod . . . 7 2.2.1 Litteraturstudie . . . 72.2.2 Implementation av ett androidprogram . . . 7
2.2.3 Abuse cases . . . 8 2.2.4 S¨akerhetskrav . . . 8 2.2.5 Arkitekturell riskanalys . . . 10 2.3 Metodkritik . . . 10 3 En beskrivning av Android 11 3.1 Grunder . . . 11 3.1.1 Applikationer . . . 12 v
vi INNEH˚ALL Komponentbeskrivning . . . 12 Intents . . . 13 3.1.2 Dalvik VM . . . 14 3.1.3 Sandboxning . . . 16 3.1.4 Spr˚akst¨od i Android . . . 16 3.1.5 Paketeringsprocessen . . . 16 3.2 Androids s¨akerhetsmodell . . . 17 3.2.1 R¨attighetsmodellen . . . 17 3.2.2 Kodsignering . . . 17
3.2.3 Linuxk¨arnans inblandning . . . 18
UID/GID . . . 18
Ge applikationer samma UID . . . 18
R¨attigheter f¨or filer och enheter . . . 19
Sandboxning genom egna anv¨andare . . . 19
4 Applikationen 21 4.1 Syfte . . . 21
4.2 Det befintliga systemet . . . 21
4.2.1 Backend . . . 22
4.2.2 Databasen . . . 23
4.2.3 Telefonen . . . 23
4.2.4 L˚aset . . . 23
4.2.5 Loggning . . . 24
4.2.6 Uppl˚asningsf¨orfarande . . . 25
4.3 Den utvecklade applikationen . . . 25
4.3.1 Inloggning . . . 26
4.3.2 Inst¨allningar . . . 27
4.3.3 L˚aslista . . . 28
4.3.4 Uppl˚asning . . . 28
5 Resultat och analys 29 5.1 Identifierade s¨akerhetsproblem . . . 29
5.1.1 Rootning . . . 29
5.1.2 Loggning . . . 30
5.1.3 R¨attigheter f¨or filer och databaser . . . 30
INNEH˚ALL vii 5.1.5 SQL-injektion . . . 32 5.1.6 Gamla versioner . . . 33 5.2 Hj¨alpmedel . . . 33 5.2.1 Obfuskering . . . 33 ProGuard . . . 34
Hur stor skillnad g¨or obfuskering . . . 34
5.2.2 St¨od f¨or kryptering . . . 35
5.3 Distribution . . . 36
5.3.1 Nackdelar med Android market . . . 36
5.3.2 Krav . . . 36
5.3.3 Automatiskt uppdatering . . . 37
5.3.4 Telefonspecifika installationsfiler . . . 37
5.3.5 Initialinstallation fr˚an en centralpunkt . . . 38
5.3.6 S¨akerhetsaspekter p˚a designf¨orslag . . . 38
6 Diskussion 39 6.1 Diskussion av resultatet . . . 39 6.2 Vidare studier . . . 41 Litteraturf¨orteckning 42
Appendix
47
A Misuse cases 47Figurer
3.1 Intentval . . . 15 3.2 Packeteringsprocessen . . . 20 4.1 System¨oversikt . . . 22 4.2 Utvecklingsd¨orren . . . 24 4.3 Inloggningsrutan . . . 26 4.4 Resursmappar . . . 27 4.5 Spr˚akstr¨angar . . . 27 viiiTabeller
2.1 Abuse case mall . . . 9
Kapitel 1
Inledning
F¨oretag har i flera ˚ar haft applikationer med f¨oretagsk¨anslig information ute p˚a f¨altet, att utveckla program till mobiltelefoner ¨ar inte heller n˚agot nytt. Under de senaste ˚aren har dock mobiltelefonmarknaden genomg˚att stora f¨or¨andringar. Datormobiler har tagit st¨orre plats och utvecklingen g˚ar snabbt fram˚at. F¨oretagen har f˚att upp ¨ogonen f¨or att integrera mobiltele-fonerna i sin organisation och intresset f¨or f¨oretagsapplikationer1 ¨ar stort. Kraven p˚a b˚ade telefonerna och applikationerna ¨ar dock stora.
I media debatteras ofta om hur os¨akra de nya mobila plattformarna ¨
ar [1] [2]. Dock p˚avisar argumenten s¨allan n˚agra tekniska brister. Debatten handlar oftast om anv¨andarens omd¨ome och mer exakt hur sv˚art det ¨ar med anv¨andare som g¨or informerade men d˚aliga beslut, till exempel installera applikationer som utf¨or fler funktioner ¨an vad den utger sig f¨or att g¨ora. Detta kan exempelvis vara att skicka vidare dina kontakter till en tredje part.
Idag anv¨ander flera f¨oretag applikationer utvecklade f¨or datormobiler i sina IT-l¨osningar. Hur ser s¨akerheten ut f¨or dessa f¨oretagsapplikationer om anv¨andaren ¨aven laddat ned op˚alitliga applikationer? Vad ¨ar viktigt att t¨anka p˚a som utvecklare?
1En applikation som anv¨ands av f¨oretag eller organisationer och inte intressanta f¨or
hemanv¨andare. Applikationen tillhandah˚aller en arbetsrelaterad tj¨anst.
Inledning 3
1.1
Syfte
Syftet med denna rapport ¨ar att ge en ¨overblick ¨over Androids s¨ akerhets-l¨osning och hur denna hanterar s¨akerheten mellan applikationer. Vidare beskriver rapporten ¨aven hj¨alpmedel som kan anv¨andas av utvecklare f¨or att ¨oka s¨akerheten i de applikationer som utvecklas.
1.2
Bakgrund
HOW Solutions ¨ar ett konsultbolag som erbjuder l¨osningar inom IT- och verksamhetsl¨osningar. HOW Solutions har tidigare utvecklat en applikation till plattformen Windows Mobile 6 samt till de mobiler som kan k¨ora Java ME2. Applikationen ¨ar en l¨osning att l˚asa upp ytterd¨orrar med digitala nycklar i telefonen och anv¨ands inom hemtj¨ansten p˚a flera orter i Sverige. D˚a Windows Mobile 6 ¨ar p˚a v¨ag att ers¨attas av Windows Phone 7 och Java ME har visat sig kr¨ava telefonspecifika l¨osningar, har HOW Solutions valt unders¨oka andra plattformar och d˚a med fokus mot Android, se kapitel 3.
1.3
Problemformulering
Arbetet utf¨ordes med avseende p˚a tre problemformuleringar. Hur hanterar Android s¨akerheten mellan applikationer?
Vilka s¨akerhetsproblem kan vi identifiera i Androidplattformen? Vilka hj¨alpmedel finns f¨or utvecklare och distribut¨orer av
f¨oretagsap-plikationer?
1.3.1
Beskrivning
HOW Solutions ville unders¨oka plattformen med avseende p˚a f¨oljande fo-kusomr˚aden.
2Java Micro Edition ¨ar en nedbantad version av Java Standard Edition designad f¨or
4 1.4. Avgr¨ansningar
Kommunikation med webbservices
Distribution av applikationer utanf¨or market Spr˚akkonvention
Databasst¨od Datalagring
Kommunikation via Bluetooth Grafiska komponenter
Kodobfuskering Signering av kod
Automatisk uppdatering
HOW Solutions var intresserade av att utvecklingsarbetet skedde i stan-dardmilj¨on. F¨or Android inneb¨ar det en utvecklarmilj¨o i Eclipse och Java som utvecklingsspr˚ak. Utvecklingen gjordes b˚ade i den medf¨oljande emula-torn och p˚a Androidmobiler. I uppdraget l˚ag s¨akerhetsfokus p˚a att analy-sera de problem som r¨orde de interna strukturerna i Android och kommu-nikationen med andra system.
1.4
Avgr¨
ansningar
Examensarbetet fokuserar p˚a de s¨akerhetsproblem som direkt eller indirekt kan p˚averka den utvecklade applikationens funktioner eller data. Applika-tioner som missbrukar de r¨attigheter som anv¨andaren godk¨anner har inte unders¨okts. En j¨amf¨orelse mot de befintliga klienter som HOW Solutions tidigare utvecklat har inte utf¨orts d˚a de plattformarna inte l¨angre ¨ar intres-santa att anv¨anda i systemet. ¨Overs¨attningar av engelska termer kommer fr˚an Svenska datatermgruppens3 rekommendationer. I de fall d¨ar ingen ¨
overs¨attning finns har den engelska termen anv¨ants.
Kapitel 2
Metodik
I det h¨ar kapitlet presenteras en kort ¨oversikt av litteraturen som behandlar metoder f¨or att f¨orb¨attra s¨akerheten i programvara tillsammans med en beskrivning av de metoder som anv¨ants.
2.1
Metoder i litteraturen
McGraw (2006) [3] beskriver Seven touchpoints for software security”, vilka ¨
amnar mot att ¨oka s¨akerheten i mjukvarusystem. 1. Abuse cases 2. S¨akerhetskrav 3. Riskanalys 4. Riskbaserade s¨akerhetstester 5. Kodgranskning 6. Penetrationstestning 7. S¨akerhets˚atg¨arder
6 2.1. Metoder i litteraturen
Abuse cases, ibland ¨aven kallade misuse cases, kan beskrivas som en variant av use cases med fokus p˚a s¨akerhet. McDermott & Fox (1999) [4] definierar ett use case som en specifikation av en fullst¨andig interaktion mellan ett system och en eller flera akt¨orer och beskriver allts˚a en funktion i systemet. Enligt Sindre & Opdahl (2001) beskriver abuse cases funktio-nalitet som man vill att ett system inte ska till˚ata [5]. Sindre och Ophdahl (2004) [6] skriver att vanliga use cases ¨ar anv¨andbara n¨ar man arbetar med funktionella krav med f¨oljden att man l¨att missar extrafunktionella krav som till exempel s¨akerhetskrav och menar vidare att dessa s¨akerhetskrav kan hittas med abuse cases. CockBurn (2001) [7] skriver att use cases oftast beskrivs med vanlig text men kan ocks˚a utg¨oras av exempelvis fl¨odes- och sekvensdiagram. Sindre & Opdahl [6] skriver att detta ocks˚a kan utnyttjas f¨or abuse cases.
Mead & Stehney (2005) [8] skriver att krav ¨ar kritiska f¨or hur v¨al ett projekt lyckas och att kostnaden f¨or att r¨atta till fel som beror p˚a bristan-de krav ofta ¨ar en stor del av den totala projektkostnaden. Mead (2006a) [9] skriver att i m˚anga fall n¨ar s¨akerhetskrav ¨ar definierade ¨ar dessa of-ta of-tagna fr˚an en lista med s¨akerhetsfunktioner. Vidare skriver f¨orfattaren ocks˚a att fastst¨allandet av s¨akerhetskrav inte ¨ar en eng˚angsaktivitet utan b¨or t¨ankas p˚a under hela utvecklingsprocessen. Ett antal metoder f¨or ut-formandet av s¨akerhetskrav har definierats. Viega (2005)[10] beskriver en metod kallad CLASP som anv¨ander sig av roller och resurser f¨or att bygga s¨akerhetskrav. Mead (2006b) [11] skriver om en process kallad SQUARE som utvecklats p˚a Carnegie Mellon University som utvecklar, kategoriserar och prioriterar s¨akerhetskrav. Haley m.fl. (2008) [12] beskriver ett ramverk f¨or s¨akerhetskrav som har f¨oljande aktiviteter:
1. Identifiera funktionella krav 2. Identifiera s¨akerhetsm˚al 3. Identifiera s¨akerhetskrav 4. Verifiera systemet
Dessa aktiviteter utf¨ors under ett antal iterationer.
McGraw (2006) [3] menar att designbrister ¨ar ansvariga f¨or 50% av s¨ a-kerhetsproblemen. Han f¨oresl˚ar en metod f¨or att utf¨ora arkitekturell
riska-Metodik 7
nalys som best˚ar av tre stycken huvudaktiviteter; attack resistance analysis som ¨ar ¨amnat att hitta k¨anda svagheter med hj¨alp av exempelvis checklis-tor och metoder som Microsoft STRIDE [13] , ambiguity analysis som ¨ar ¨
amnat att hitta nya svagheter i systemet som ej hittas med attack resistan-ce analysis samt weakness analysis som ¨ar ¨amnat att unders¨oka svagheter i underliggande system och plattformar.
2.2
Metod
I det h¨ar avsnittet beskrivs de metoder som har anv¨ants under examens-arbetet.
2.2.1
Litteraturstudie
I b¨orjan av examensarbetet utf¨ordes en litteraturstudie f¨or att ¨oka kun-skapen om androidplattformen och dess s¨akerhetsfunktioner. D˚a Android ¨
ar en relativt ung plattform var utbudet av vetenskapliga artiklar, r¨orande Androids s¨akerhet, d˚aligt. D¨arf¨or studerades ¨aven artiklar r¨orande Linux-k¨arnan, s¨akerhetsmetoder, implementationer m.m.. Artikels¨okningen ut-f¨ordes i huvudsak i, av LiU tillhandah˚allna ,s¨okmotorer som exempelvis Scopus. Databaser ¨over s˚arbarheter som till exempel National vulnerability database1 anv¨andes f¨or att hitta aktuella s¨akerhetsbrister i Android.
Ett stort st¨od under utvecklingen var ocks˚a Androids utvecklarhemsida2 d¨ar en f¨orteckning ¨over Androids utvecklingsapi tillhandah˚alls. Hemsidan inneh˚aller ¨aven resurser som till exempel inspelningar fr˚an Googles utveck-larkonferens Google I/O och artiklar r¨orande funktioner i Android.
2.2.2
Implementation av ett androidprogram
Under examensarbetet implementerades en androidversion av ett klient-program som idag finns till Java ME-telefoner och Windows Mobile 6. Pro-grammet integrerades med ett befintligt bakomliggande system d¨ar
hante-1En erk¨and databas ¨over k¨anda s˚arbarheter som administreras av amerikanska staten
http://nvd.nist.gov/
8 2.2. Metod
ringen av till exempel anv¨andare sk¨ottes. Utvecklingen skedde i korta itera-tioner med specifika fokusomr˚aden som till exempel Bluetooth, databaser och GUI. Applikationen ¨ar en l¨osning f¨or att l˚asa upp d¨orrar via mobiltele-foner och beskrivs n¨armare i sektion 4.3. M˚alet med implementationen var inte att ta fram en slutprodukt.
2.2.3
Abuse cases
Under examensarbetet anv¨andes abuse cases f¨or att diskutera och iden-tifiera potentiella s¨akerhetsproblem. En variant av den mall som Sindre & Opdahl [6] f¨oresl˚ar togs fram. Mallarna anv¨andes som utg˚angspunkt i diskussionen och f¨or att dokumentera arbetet, se tabell 2.1. I abuse casen mallen anv¨andes inte alltid alla f¨alt d˚a dessa ibland inte var relevanta. Oli-ka tillg˚angar identifierades i applikationen och systemet i sin helhet. Dessa tillg˚angar, som en angripare eventuellt skulle vilja komma ˚at, anv¨andes sedan f¨or att skapa abuse cases.
2.2.4
S¨
akerhetskrav
F¨or att utforma de s¨akerhetskrav som skulle st¨allas p˚a det system som HOW Solutions ville utveckla anv¨andes, med vissa modifikationer, den me-tod som Haley m.fl (2008) [12] definierar. Arbetet inleddes med att definie-ra funktionella kdefinie-rav p˚a applikationen d˚a dessa inte fanns att tillg˚a. Utifr˚an dessa funktionella krav identifierades tillg˚angar i systemet som sedan an-v¨andes f¨or att skapa hotbildstupler. Hotbildstuplerna ¨ar uppbyggda enligt attack, tillg˚ang, skada och kategoriserade enligt CIA 3 [14]. S¨akerhetsm˚al, ¨
aven dessa kategoriserade enligt CIA, f¨or systemet utvecklades sedan med dessa som grund.
Den sista aktiviteten var att utforma s¨akerhetskrav. Dessa s¨ akerhets-krav ¨ar en konkretisering av s¨akerhetsm˚alen och kopplade till de funktio-nella kraven.
Metodik 9
Attributnamn F¨orklaring
Namn Namn p˚a abuse caset
Sammanfattning En kort sammanfattning av abuse caset
F¨orfattare Namn p˚a den som skrivit abuse caset
Datum Datumet d˚a abuse caset skrevs
Standardv¨ag Den v¨ag som ¨ar standard f¨or attacken
Alternativa v¨agar Alternativa v¨agar som angriparen kan
g˚a f¨or att n˚a sitt m˚al
Mitigering S¨att p˚a vilket en attack kan f¨orhindra,
alternativt mildras
Anknutna abuse cases Abuse cases som ¨ar anknutna till ak-tuellt abuse case. Till exempel om en attack beskriven av ett annat abuse ca-se ¨ar en del av n˚agon v¨ag f¨or att utf¨ora attacken i detta abuse case
Utl¨osande faktor Vad som utl¨oser ett abuse case
Villkor Vilka villkor m˚aste uppfyllas f¨or att
abuse caset skall vara m¨ojligt att utf¨ora
Antagande Antaganden om till exempel systemet
eller angriparen
Mitigeringsf¨ors¨akran Beskriver vad resultatet ¨ar av ett miti-gerat abuse case
V¨arsta m¨ojliga hot Beskriver vad v¨arsta m¨ojliga utfall av abuse caset ¨ar
Relaterade aff¨arsregler Vilka aff¨arsregler som bryts ifall abuse caset ¨ar lyckat
Potentiell missanv¨andarprofil Beskriver en angriparen eller den an-v¨andare som anv¨ander systemet felak-tigt
Ber¨orda parter och hot De som p˚averkas av abuse caset och de hot som abuse caset ber¨or
Terminologi och f¨orklaringar Viktig terminologi och f¨orklaringar Tabell 2.1: V˚ar mall f¨or abuse cases
10 2.3. Metodkritik
2.2.5
Arkitekturell riskanalys
Arbetet inleddes med att skapa en h¨ogniv˚amodell ¨over de olika komponen-terna i applikationen och systemet. Detta f¨or att enkelt kunna f˚a en ¨oversikt och enklare kunna identifiera potentiella problemomr˚aden i arkitektur och design. N¨asta steg var att g¨ora en Attack resistance analysis och h¨ar an-v¨andes Microsoft STRIDE. H¨ogniv˚amodellen tillsammans med abuse casen anv¨andes f¨or att dela upp applikationen i relevanta subgrupper. STRIDE ¨
ar en akronym f¨or ett antal attacktyper: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service och Elevation of Privilege. Ef-ter detta unders¨oktes vilka av dessa attacktyper som var m¨ojliga mot de olika suggrupperna. N¨asta steg var att hitta mer konkreta risker mot de olika grupperna och d˚a anv¨andes ett antal diskussionsfr˚agor som beskrivs i Howard & Lipner 2006 [15].
En analys som gick ut p˚a att leta efter redan k¨anda attacker mot de plattformar som anv¨ands av systemet utf¨ordes. Denna begr¨ansades dock till Android och de komponenter som anv¨andes.
En Ambiguity analysis, som ocks˚a ing˚ar i en arkitekturell riskanalys enligt McGraw (2006) [3] , utf¨ordes ej d˚a denna analys kr¨aver en stor erfa-renhet utav datas¨akerhet.
2.3
Metodkritik
En begr¨ansning ¨ar att de touchpoints McGraw (2006) [3] beskriver ¨ar t¨ankta att anv¨andas i st¨orre projekt. De slutprodukter som metoderna resulterade i var inte lika viktiga som diskussionerna som h¨olls under utformandet av dessa. Diskussionerna hade blivit b¨attre i en lite st¨orre grupp. Varvandet mellan implementering och de s¨akerhetsmetoder som anv¨andes ¨ar ett bra s¨att f¨or att b¨attre se helheten av arbetet. Den metod som anv¨andes f¨or att ta fram s¨akerhetskraven skalade inte till den applikationen som utvecklades. D¨arf¨or utf¨ordes p˚a grund av tidsbrist endast en iteration. En annan metod f¨or att ta fram s¨akerhetskraven borde anv¨andas.
Microsoft STRIDE ¨ar en enkel metod att anv¨anda och resultatet av denna var mycket bra. Metoden hittade flera s¨akerhetsbrister som inte hade uppt¨ackts i de tidigare aktiviteterna.
Kapitel 3
En beskrivning av
Android
I detta kapitel beskrivs plattformen Androids grunder samt s¨ akerhetsmo-dellen.
3.1
Grunder
Android ¨ar en samling mjukvara som utg¨ors av ett operativsystem, mel-lanprogramvara och vissa standardapplikationer [16]. Operativsystemet an-v¨ands f¨orst och fr¨amst i mobiltelefoner men finns ¨aven till surfplattor. Open Handset Alliance, d¨ar bland annat Google ing˚ar, st˚ar bakom Android. Android sl¨apptes under licensen Apache 2.0 i september 2008, men nya versioner utvecklas kontinuerligt[17]. Flera mobiltillverkare utvecklar idag androidmobiler bland annat HTC, Sony Ericsson och Samsung och dessa har i sin tur ett flertal olika modeller p˚a marknaden.
Android anv¨ander sig av linuxk¨arnan och ¨arver d¨arf¨or mycket av den grundfunktionaliteten som finns hos den vilket exempelvis ¨ar hantering av tr˚adning, kommunikation med enheter och systemanrop [16].
12 3.1. Grunder
3.1.1
Applikationer
Externa applikationer ¨ar en viktig del i Android och det som mest utm¨arker den nya generationens mobiltelefoner. Att installera applikationer p˚a tele-foner ¨ar inget nytt utan det nya ¨ar integrationen mellan applikationerna och operativsystemet. Det finns applikationer som hanterar telefonresur-ser som till exempel SMS eller telefonsamtal. Andra applikationer tillf¨or underh˚allning som till exempel spel eller videospelare.
Applikationer distribueras p˚a Android Market, som ¨ar en form av pa-kethanterare1. I Android finns ¨aven m¨ojligheten att installera program fr˚an externa k¨allor, dock m˚aste anv¨andaren explicit till˚ata detta genom att ¨ and-ra i inst¨allningarna. Google har en mer ¨oppen syn p˚a vad som f˚ar publice-ras p˚a market ¨an vad till exempel Apple [18] har. I denna rapport kommer distributionen inte j¨amf¨oras med konkurrenternas l¨osningar, men generellt l¨agger Android ¨over mer ansvar p˚a anv¨andaren. Dwivedi m.fl. (2010) [19] p˚apekar att anv¨andaren d¨arf¨or b¨or vara noga med att kontrollera vad appen egentligen g¨or innan den laddas ned.
Komponentbeskrivning
En androidapplikation best˚ar i grunden av fyra applikationskomponenter. Dessa ¨ar aktiviteter, services, content providers och broadcast recievers. Nedan beskrivs dessa n¨armare.
En aktivitet i Android ¨ar en del i applikationen som presenterar en sk¨arm f¨or anv¨andaren att interagera med [20]. En applikation best˚ar oftast av ett antal aktiviteter som ¨ar sammankopplade och n¨ar en aktivitet startas visas den framf¨or den f¨orra aktiviteten. Den tidigare aktiviteten l¨oper d˚a risk f¨or att bli borttagen ur minnet av Androids skr¨apsamlare. Det ¨ar d¨arf¨or viktigt att t¨anka p˚a att spara undan data som man vill ska finnas kvar i applikationen n¨ar aktiviteten pausas. Aktiviteterna som k¨orts l¨aggs i en stack och n¨ar anv¨andaren trycker p˚a bak˚atknappen avslutas den aktivitet som har fokus och den aktivitet som nu ligger h¨ogst upp p˚a stacken f˚ar fokus.
Om man vill utf¨ora uppgifter i bakgrunden som exempelvis att spela upp en musikfil b¨or man g¨ora detta i en s˚a kallad service som ¨ar en
En beskrivning av Android 13
kationskomponent som inte har n˚agot GUI. En service som startas av en applikation forts¨atter k¨ora ¨aven om en annan applikation startas. D¨arf¨or ¨
ar det viktigt att man st¨anger ned services n¨ar de inte l¨angre beh¨over k¨ o-ras alternativt att man p˚a n˚agot s¨att informerar anv¨andaren att servicen fortfarande k¨ors, till exempel genom att visa en notifikation i statusraden h¨ogst upp p˚a telefonen.
En content provider hanterar delning av datak¨allor [21]. Content pro-viders ¨ar t¨ankt att anv¨andas fr¨amst om data ska delas mellan applikatio-ner men ¨ar en anv¨andbar abstraktion ¨aven inom en applikation. Android har flera inbyggda content providers som hanterar exempelvis kontakter, video och ljud. Kommunikationen med en content provider sker genom s˚a kallade content resolvers tillsammans med en URI(Uniform Resource Identifier)[22].
En broadcast receiver ¨ar ett objekt som lyssnar p˚a en s˚a kallad broadcast som skickas ut till hela systemet. De flesta broadcasts har sitt ursprung p˚a systemniv˚a och kan till exempel meddela att batteriniv˚an ¨ar l˚ag eller att sk¨armen har blivit p˚aslagen. En broadcasts kan ocks˚a skickas ut av appli-kationer [23][21]. Broadcast receivern utf¨or sedan en operation beroende p˚a vad broadcastmeddelandet inneh˚aller.
Intents
Alla ovanst˚aende komponenter f¨orutom content providers aktiveras med hj¨alp av asynkrona meddelanden som i Android heter Intents. Genom In-tents binder man ihop olika delar av applikationen. Ett Intent inneh˚aller en abstrakt beskrivning av vad som skall utf¨oras. Om intentet skickas till en broadcast receiver beskrivs ist¨allet vad som h¨ant.
Det finns tv˚a huvudkategorier av intents, explicita och implicita: I ett explicit intent ¨ar det specificerat vilken klass som ska f˚a
informa-tionen. Man m˚aste allts˚a veta det exakta namnet p˚a klassen f¨or att kunna skicka intentet vilket inneb¨ar att det n¨astan enbart anv¨ands f¨or kommunikation mellan komponenter inom samma applikation. I ett implicit intent ¨ar det inte specificerat exakt vilken komponent
som ¨ar m˚alet utan intentet m˚aste inneh˚alla tillr¨ackligt med informa-tion f¨or att systemet skall kunna v¨alja en passande mottagare.
14 3.1. Grunder
Ett intent inneh˚aller som sagt information om vad som ska utf¨oras. Nedan beskrivs kortfattat vad denna information kan vara.
Component name Komponentnamnet ¨ar m˚alklassen f¨or intentet. Ett in-tent d¨ar komponentnamnet ¨ar definierat ¨ar alltid ett explicit intent. Action Detta ¨ar en str¨ang som beskriver vad som skall utf¨oras alternativt
vad som har utf¨orts. Str¨angen f¨or att ringa ett samtal ¨ar exempelvis ”ACTION CALL” och str¨angen f¨or att meddela att batteriniv˚an ¨ar l˚ag ¨ar ”ACTION BATTERY LOW”.
Data Den URI[22] till den data som den Action som specificerats skall. Det g˚ar ¨aven att specificera vilken typ av data det ¨ar. Detta f¨or att inte en applikation skall f¨ors¨oka ¨oppna en fil den inte kan ¨oppna. Category En str¨ang som beskriver vilken sorts komponent som ska
hante-ra intentet. Den kan inneh˚alla flera olika kategorier och en komponent m˚aste tillh¨ora samtliga dess f¨or att kunna ta emot intentet. Exem-pel p˚a kategorier ¨ar ”CATEGORY BROWSERABLE”, som inneb¨ar att komponenten kan ¨oppnas inifr˚an en webbrowser, och ”CATEGO-RY LAUNCHER” som inneb¨ar att komponenten ¨ar huvudaktivitet i en applikation.
Extras och flags Ytterligare information, som skall ¨overf¨oras till n¨asta komponent, kan l¨aggas till i ett intent. Extras ¨ar en tupel som inne-h˚aller en nyckel och ett v¨arde. Flaggor beskriver oftast hur en kom-ponent skall k¨oras.
F¨or att operativsystemet ska hitta vilken komponent som ¨ar mottagare av ett implicit intent anv¨ands intentfilter. N¨ar ett implicit intent kastas s˚a j¨amf¨ors tre parametrar i intentet gentemot intentfiltret. Parametrarna mat-chas mot intentfiltrets action, category och data (b˚ade URI och datatyp). Om det finns flera applikationer som uppfyller intentet s˚a f˚ar anv¨andaren besluta vilken applikation som ska hantera anropet[24][25]. Se figur 3.1.
3.1.2
Dalvik VM
Huvudspr˚aket f¨or Android ¨ar Java som k¨ors i en virtuell maskin. Syftet med en virtuell maskin ¨ar att skapa en abstraktion s˚a program skrivet f¨or
En beskrivning av Android 15
Figur 3.1: Ett exempel p˚a n¨ar anv¨andaren f˚ar v¨alja vilket program som skall ta emot det intent som skickats
den virtuella maskinen inte beh¨over ta h¨ansyn till den aktuella h˚ardvaran. Android anv¨ander inte Javas VM utan har ersatts av en ny virtuell maskin kallad Dalvik. Den st¨orsta tekniska skillnaden ¨ar att Dalvik ¨ar en regis-terbaserad virtuell maskin medan JVM som ¨ar en stackbaserad virtuell maskin. Fler tekniska skillnader finns som g¨or att Java VM och Dalvik inte ¨
ar kompatibla med varandra. Program skrivna i Java m˚aste vara special-skrivna f¨or att fungera p˚a Android. N¨ar en applikation exekveras i Android, skapas en egen instans av Dalvik. Dalvik ¨ar ingen extra s¨akerhetsfunktioner d˚a det ¨ar till˚atet f¨or applikationer att k¨ora kod utanf¨or Dalvik. Dalvik ¨ar ¨
16 3.1. Grunder
3.1.3
Sandboxning
Android anv¨ander sig av en teknik som kallas f¨or sandboxning som inneb¨ar att ett program k¨ors i en isolerad milj¨o som ofta har begr¨ansade r¨ attighe-ter att anv¨anda resurser i operativsystemet. Android anv¨ander de tillst˚and som godk¨anns av anv¨andaren f¨or att bygga den sandbox som applikatio-nen sedan ska k¨oras i. Genom att anv¨anda sandboxning f˚as ocks˚a f¨ordelen att om n˚agot skulle g˚a fel s˚a ¨ar det en begr¨ansad del av systemet som p˚averkas[27][28][29].
3.1.4
Spr˚
akst¨
od i Android
Majoriteten av alla applikationer till Androids skrivs i Java. Genom arvet fr˚an linux s˚a st¨odjer ¨aven Android kod skrivet i C, C++ och assembler med f¨oljden att tillg˚angen till Androids API begr¨ansas. Utvecklaren kan fritt blanda olika programspr˚ak i samma projekt. Det kan vara praktiskt om Java inte ger en tillr¨ackligt h¨og prestanda och delar av applikationen kan d˚a skrivas i till exempel C. Det har ¨aven gjorts f¨ors¨okt f¨or att f˚a in andra spr˚ak, som till exempel Erlang [30] eller .NET [31], till Android.
3.1.5
Paketeringsprocessen
En applikations k¨allkod ¨ar uppdelad och har en mer fast struktur ¨an ett traditionellt javaprojekt. K¨allkodsfilerna ¨ar enligt Javastandard med pa-ket och klassfiler. En applikation har ¨aven resursmappar som definierar det grafiska gr¨anssnittet, bilder, spr˚ak och liknade information. Resurserna l¨ankas ihop med koden genom en fil som heter R.java och som genereras av utvecklingsverktygen. Vid paketering s˚a interpreteras alla javafiler till .classfiler. Dessa ¨overs¨atts sedan till Dalvik bytekod (.dexfiler) f¨or att k¨oras p˚a Androids virtuella maskin. Dexfilerna packas ihop med resurserna i en s˚a kallad Android Package (.apk). Paketfilen signeras och ¨ar redo f¨or att k¨oras p˚a en telefon [32]. Packeteringsprocessen beskrivs i figur 3.2
En beskrivning av Android 17
3.2
Androids s¨
akerhetsmodell
I detta avsnitt beskrivs Androids s¨akerhetsmodell p˚a b˚ade applikationsniv˚a och systemniv˚a.
3.2.1
R¨
attighetsmodellen
En applikation har som standard inte till˚atelse att anv¨anda funktioner som kan p˚averka andra applikationer, operativsystemet eller anv¨andaren [27]. Dessa funktioner kan exempelvis vara att l¨asa anv¨andarens kontakter eller att koppla upp sig mot internet. En applikation kan dock be om tillst˚and att anv¨anda dessa funktioner genom att specificera detta i AndroidMani-fest.xml2. Vid installation av applikationen f˚ar anv¨andaren bekr¨afta om applikationen ska f˚a anv¨anda dessa funktioner, om anv¨andaren v¨aljer att inte godk¨anna detta utf¨ors ingen installation. Det finns ingen m¨ojlighet att dynamiskt ¨andra vilka tillst˚and en applikation f˚ar anv¨anda, en applikation ¨
ar allts˚a bundet till de tillst˚and som godk¨ants vid installationen.
Att godk¨anna ett tillst˚and inneb¨ar att applikationen har till˚atelse att anv¨anda den resurs och/eller funktion som ¨ar kopplad till tillst˚andet. Hur resurserna sedan anv¨ands ligger utanf¨or Androids s¨akerhetsmodell. En ap-plikation som har tillst˚and att initiera samtal kan till exempel anv¨anda detta f¨or att ringa till dyra betalnummer utan anv¨andarens vetskap. D¨ ar-f¨or ligger mycket ansvar p˚a att anv¨andaren ¨ar kritisk till vilka tillst˚and en applikation verkligen beh¨over. Ett tetrisliknande spel kanske inte beh¨over ha till˚atelse att komma ˚at telefonboken.[19]
3.2.2
Kodsignering
Operativsystemet delar upp systemet i tv˚a delar, kod som tillh¨or systemet och resterande applikationer. F¨or att applikationer ska f˚a installeras m˚aste de vara signerade med ett certifikat. Certifikatet beh¨over inte vara signerat av en betrodd 3:e part (en s˚a kallad certifieringsutgivare) utan egensigne-rade certifikat ¨ar till˚atna. Signeringens syfte ¨ar att identifiera och verifiera applikationens utgivare. Applikationer med samma namn och signerad med samma signatur identifieras som exakt samma applikation. Vid den f¨orsta
18 3.2. Androids s¨akerhetsmodell
installationen best¨ams s¨okv¨ag, anv¨andarid (UID)och gruppid (GID). Vid senare installationer kommer applikationen tilldelas samma s¨okv¨ag, UID och GID. F¨or att underl¨atta f¨or utvecklare har Android ett utvecklingsl¨ a-ge som till˚ater applikationer att vara signerade med ett enklare certifikat [34]. Utvecklingsl¨aget ¨ar avst¨angt som standard, inte f¨or att det ¨ar speciellt os¨akert men det ¨okar dock attackytan n˚agot.
3.2.3
Linuxk¨
arnans inblandning
Android anv¨ander sig av linuxk¨arnan. Linuxk¨arnan implementerar mycket av de s¨akerhetsfunktioner som n¨amns i denan rapport. Bovet (2005) [35] skriver att k¨arnan ¨ar av typen monolitisk k¨arna, vilket kortfattat inneb¨ar att den st˚ar f¨or allt som inte de egna processerna g¨or, dvs exekvering av drivrutiner, minneshantering etc. K¨arnan ansvarar ¨aven f¨or filsystemet och d¨arf¨or spelar UID/GID en central roll i Android som dock implementerar detta lite annorlunda.
UID/GID
Ett UID eller User ID ¨ar ett nummer i ett system som unikt identifie-rar en anv¨andare. En anv¨andare tillh¨or ocks˚a en grupp som har ett unikt GID. UID med v¨ardet 0 identifierar systemadministrat¨oren ¨aven kallad root. Root ¨ar en privilegierad anv¨andare med n¨astintill obegr¨ansade r¨ attig-heter i operativsystemet.
Ge applikationer samma UID
En m¨ojlighet som Android erbjuder ¨ar att ge tv˚a applikationer samma UID och vilket inneb¨ar att de kan exekveras inom samma sandbox. Appli-kationerna kan d˚a komma ˚at varandras resurser. Det m¨ojligg¨or ocks˚a f¨or applikationerna att dela process och allt annat i sandboxen. Funktionen kan utg¨ora en signifikant s¨akerhetsrisk, det finns dock vissa krav som m˚ as-te uppfyllas: F¨or att tv˚a applikationer ska f˚a dela UID m˚aste dessa vara signerade utav samma utvecklarcertifikat. Vidare m˚aste de ocks˚a explicit specificera ett UID i respektive AndroidManifest.xml.
En beskrivning av Android 19
R¨attigheter f¨or filer och enheter
Fr˚an UNIXv¨arlden finns ett begrepp som fortfarande lever vidare i Linux och det ¨ar ”In UNIX everything is a file”[36]. Detta g¨or att filr¨attigheter spelar en v¨aldigt central roll d˚a dessa ¨aven g¨aller f¨or till exempel enheter. Linux r¨attigheter ¨ar enligt POSIX standarden, d¨ar varje m¨ojlig anv¨andare delas in i tre kategorier. Anv¨andaren kan vara ¨agare, gruppmedlem eller resterande anv¨andare. F¨or varje kategori kan filen ha tre olika r¨attigheter l¨as, skriv och exekvera. Skapas en fil sparar operativsystemet ner metadata och d˚a s¨atts ¨agaren till filen till det aktiva UID och gruppen till det aktiva GID.
Sandboxning genom egna anv¨andare
I persondatorer brukar ett UID definiera just en anv¨andare och alla pro-gram som den anv¨andaren k¨or f˚ar samma UID. En vanlig session p˚a en persondator ¨ar till exempel att anv¨andaren loggar in och startar upp n˚agra program som en webbl¨asare och en mailklient. De inneb¨ar att webbl¨asare och mailklienten kommer k¨oras under anv¨andarens GID/UID. Detta g¨or att de delar l¨as- och fisker¨attigheter till inst¨allningsfiler och sessionsdata. Programmen har ¨aven r¨attigheter att exempelvis avsluta varandras proces-ser. I Android startas ist¨allet varje applikation under sitt egna UID vilket ger en v¨aldigt stark separation mellan applikationer, processer och filer.
20 3.2. Androids s¨akerhetsmodell
Kapitel 4
Applikationen
I det h¨ar kapitlet beskrivs det system som existerar idag samt hur den ap-plikation som utvecklats till Android fungerar och passar in i det nuvarande systemet.
4.1
Syfte
Syftet med applikationen var f¨orst och fr¨amst att unders¨oka de delar som HOW Solutions ville ha mer information om, se sektion 1.3.1. Applikationen utvecklades ocks˚a med m˚als¨attningen att utforska Android f¨or att finna svagheter och fallgropar som kan p˚averka s¨akerheten.
4.2
Det befintliga systemet
Systemet best˚ar idag av en backend, en databas, mobilklienter och d¨orrl˚as som kommunicerar med varandra. En h¨ogniv˚abeskrivning av systemet kan ses i figur 4.1.
22 4.2. Det befintliga systemet
Figur 4.1: En ¨oversikt av systemet
4.2.1
Backend
Backendens syfte ¨ar att hantera autentisering, koppla ihop l˚as, brukare och telefoner samt att synkronisera data som till exempel loggar. Backend och klienterna kommunicerar via https och data formateras till JSON1. Ett generellt webbanropsfl¨ode beskrivs nedan.
1. En inloggningsf¨orfr˚agan g¨ors till en utav de webbservices som finns.
Applikationen 23
2. Backend h¨amtar de anv¨andaruppgifter f¨or autentisering fr˚an databa-sen.
3. Backend kontrollerar anv¨andaruppgifterna fr˚an klienten med uppgif-terna fr˚an databasen.
4. Backend kontrollerar anv¨andarens befogenheter.
5. Ett svar genereras och paketeras som ett JSON objekt. 6. Svaret returneras till klienten.
Backendens webbservices f¨oljer designarkitekturen REST2 vilket har defi-nierat en stor del av den interna designen i applikationen.
4.2.2
Databasen
Databasen i backend ¨ar en SQL-databas. Databasen inneh˚aller information om anv¨andarna s˚asom namn, anv¨andarnamn och adress. Databasen ansva-rar ¨aven att f¨or lagra vilken brukare som ¨ar kopplad till vilket l˚as och vilka anv¨andare som har till˚atelse att ¨oppna l˚asen.
4.2.3
Telefonen
Telefonens funktion i systemet ¨ar att k¨ora de olika mobilklienterna. Klien-ten finns idag till Windows mobile och till Java ME. Telefonen l¨ampar sig bra som klient d˚a telefonerna redan anv¨ands av de anst¨allda i tj¨ansten. En-heterna ¨ar n˚agot dyrare men beh¨over oftast inte lika mycket administration som till exempel handdatorer. Dessutom underl¨attar 3G-n¨atet kommuni-kationen med backend d˚a det oftast har mycket bra t¨ackning.
4.2.4
L˚
aset
L˚asets uppgift ¨ar att sk¨ota kommunikationen med mobilklienterna och att l˚asa upp de fysiska l˚asen. L˚asets h˚ardvara best˚ar av ett inbyggt system, me-kanik f¨or att l˚asa upp l˚aset och ett batteri. Mjukvaran i l˚aset har utvecklats
2En akronym f¨or Representational State Transfer och ¨ar ett designm¨onster f¨or
24 4.2. Det befintliga systemet
tidigare. Kommunikationen mot det inbyggda systemet sker ¨over Bluetooth d¨ar l˚aset enbart st¨odjer protokollet RFCOMM, vilket ¨ar ett v¨aldigt simpelt protokoll som ¨aven kallas seriell port ¨over Bluetooth. En viktigt detalj vid kommunikationen med l˚aset var att parning av enheterna inte skulle kr¨ a-vas. Denna funktionalitet d¨ok upp i Androids API niv˚a 10. I figur 4.2 visas den d¨orr som anv¨andes f¨or utveckling.
Figur 4.2: Utvecklingsd¨orren p˚a utsidan
4.2.5
Loggning
Loggningen ¨ar en viktigt del av systemet. Det ¨ar funktionalitet som ¨ar betydligt sv˚arare och mer manuellt i ett traditionellt system med fysiska nycklar. Den mesta loggningen sker i backend f¨or att minska tilliten till kli-enterna. De loggarna klienten m˚aste ansvara f¨or ¨ar kommunikationen med l˚asen. Dessa loggar synkroniseras sedan mot backend f¨or att ¨oka sp˚ arbar-heten.
Applikationen 25
4.2.6
Uppl˚
asningsf¨
orfarande
1. En anv¨andare kommer till en d¨orr som har ett av speciall˚asen instal-lerat.
2. Anv¨andaren loggar in med sina anv¨andaruppgifter p˚a klienten.
3. Backend autentiserar anv¨andaren.
4. En lista med l˚as som anv¨andaren har till˚atelse att l˚asa upp skickas till klienten.
5. Anv¨andaren v¨aljer det l˚as som skall ¨oppnas och klickar p˚a l˚as upp.
6. Klienten startar d˚a en kommunikation med l˚aset och skickar ¨over ett l˚as upp-kommando.
7. Om l˚as upp-kommandot ¨ar korrekt vibrerar telefonen och l˚aset g˚ar att ¨oppna.
Klienten m˚aste ha tillg˚ang till internet f¨or att kunna logga in och h¨amta de olika l˚asen. Efter dessa steg finns dock m¨ojligheten att anv¨anda sig av applikationen i ett offlinel¨age genom att genera och synkronisera ner kryptonycklar i f¨ortid. Det kan vara n¨odv¨andigt om vissa brukare bor s˚a att telefonerna inte har t¨ackning.
4.3
Den utvecklade applikationen
Den applikation som utvecklades under examensarbetet ¨ar en begr¨ansad version utav de klienter som redan existerar f¨or andra plattformar. Det unders¨oktes ej hur klienterna f¨or Windows Mobile och Java var program-merade. Applikationen utvecklades ist¨allet utifr˚an en mer generell program-beskrivning. F¨or att kunna utnyttja plattformen p˚a b¨asta s¨att l˚ag fokus i b¨orjan av utvecklingen p˚a att f¨orst˚a Android och dess funktionen. Nedan beskrivs kort de delar i applikationen som utvecklades.
26 4.3. Den utvecklade applikationen
4.3.1
Inloggning
En anv¨andare loggar in med sitt anv¨andarnamn och sitt l¨osenord p˚a n˚agon utav de telefoner som finns tillg¨angliga. En anv¨andare beh¨over allts˚a inte ha en individuell telefon. D¨aremot ¨ar varje telefon bara kopplad till l˚as inom ett distrikt. Telefonen identifieras via sin bluetoothsadress som ¨ar unik f¨or varje telefon. Autentisering av anv¨andarna sker via ett anrop backend och efter autentisering f˚ar anv¨andaren tillg˚ang till de resterande delar i applikationen. F¨or att snabba upp inloggningen s˚a sparas anv¨andardata p˚a telefonen. Denna data ¨ar sparad tills en ny anv¨andare loggar in, d¨aremot sker alltid autentiseringen i backend. Hur inloggningsrutan ser ut kan ses i figur 4.3.
Applikationen 27
4.3.2
Inst¨
allningar
En inst¨allningssida, d¨ar telefonspecifika inst¨allningar ska kunna sparas, ut-vecklades. En inst¨allning som fanns i de tidigare applikationerna var m¨ oj-ligheten att v¨alja spr˚ak. I Android finns funktionen att vid utvecklandet skapa individuella resursmappar f¨or olika spr˚ak vilket kan ses i figur 4.4[37].
Figur 4.4: Resursmapparna f¨or engelska, finska och svenska
Vilken resursmapp som v¨aljs baseras p˚a objektstypen Locale som in-neh˚aller information om vilket land och vilket spr˚ak telefonen befinner sig i[38]. Genom att ¨andra vilken Locale som skall anv¨andas kan applikationen, utan att beh¨ova ¨andra i k¨allkoden, visa str¨angar i olika spr˚ak. I figur 4.5 ges exempel p˚a tv˚a resursstr¨angar i Android, en engelsk och en svensk. Ge-nom att referera till str¨angarnas namn i koden v¨aljs r¨att str¨ang beroende p˚a vilket spr˚ak som ¨ar valt.
28 4.3. Den utvecklade applikationen
4.3.3
L˚
aslista
N¨ar inloggning har skett visas en lista med de l˚as som anv¨andaren har till˚atelse att ¨oppna. Denna lista synkroniseras med j¨amna mellanrum mot servern s˚a att anv¨andaren alltid har senaste l˚aslistan. L˚asen sparas i en SQLite-databas p˚a telefonen via en “content provider” som beskrivs i sek-tion 3.1.1. Varje l˚as representeras av en textstr¨ang som ¨ar namnet p˚a den brukare eller den adress som ¨ar kopplad till l˚aset.
Intill varje l˚as finns en knapp f¨or att l˚asa upp respektive l˚asa. N¨ar anv¨andaren klickar p˚a knappen startar en uppl˚asning respektive l˚asning.
En designprincip som anv¨ants vid presentation l˚aslistan ¨ar att inte skapa upp nya objekt f¨or varje element i listan. Ist¨allet ˚ateranv¨ands det objekt som f¨orsvann fr˚an sk¨armen och inneh˚allet samt vilket element som detta refererar till ¨andras. Detta rekommenderas av Google f¨or att snabba upp listhantering och f¨or att spara minne [39].
4.3.4
Uppl˚
asning
Det f¨orsta som anv¨andaren beh¨over g¨ora ¨ar att r¨ora handtaget f¨or att star-ta elektroniken p˚a insidan av d¨orren. N¨ar elektroniken i d¨orren ¨ar ig˚ang kan anv¨andaren starta kommunikationen med l˚aset. Ett meddelande krypterat med l˚asets publika nyckel h¨amtas fr˚an backend. I meddelandet meddelar backend om anv¨andaren har beh¨orighet att ¨oppna l˚aset eller inte. Anv¨ an-daren f˚ar feedback genom en animation som visar n¨ar de olika delarna i uppl˚asningsprocessen utf¨ors och n¨ar de ¨ar klara visas en gr¨on bock. D˚a kan anv¨andaren trycka ner handtaget och d¨orren g˚ar att ¨oppna. Om n˚agot steg inte g˚ar att utf¨ora visas ist¨allet ett r¨ott kryss.
Kapitel 5
Resultat och analys
I detta kapitel presenteras resultatet fr˚an litteraturstudien, abuse case-framst¨allningen, kravutformningen och riskanalysen med avseende fr˚ age-st¨allningarna.
5.1
Identifierade s¨
akerhetsproblem
Flera identifierade s¨akerhetsproblem uppt¨acktes under implementation och f¨orberedelsearbete. Dessa beskrivs n¨armare i denna sektion.
5.1.1
Rootning
Rootning som begrepp inneb¨ar att skaffa sig tillg˚ang till administrat¨ orskon-tot root. F¨or angripare ¨ar tillg˚ang till rootkontot bland de ¨aldsta motiven just f¨or att i princip allt ¨ar till˚atet f¨or rootanv¨andaren. Standardinst¨ all-ningen i Android ¨ar att rootkontot ¨ar inaktiverat, vilket ¨ar en intressant designl¨osning. Det g¨or android till ett multianv¨andarsystem utan en ak-tiv rootanv¨andare vilket g¨or att sandboxningen ¨ar mycket stark. P˚a grund av detta finns det starka motiv f¨or en angripare att aktivera rootkontot. Vanliga anv¨andare kan ocks˚a g¨ora detta frivilligt f¨or att f˚a tillg˚ang till l˚ast funktionalitet.
30 5.1. Identifierade s¨akerhetsproblem
Det ¨ar sv˚art att skydda sig mot anv¨andare som aktivt och ¨oppet v¨aljer att roota sin telefon. I nya versioner av Android har nyheterna ofta varit funktionalitet som var m¨ojligt om anv¨andaren hade en rootad enhet och p˚a s˚a s¨att har incitamentet f¨or att l˚asa upp rootanv¨andaren minskat. F¨or angripare som ¨ar kunniga p˚a Linuxk¨arnan, blir ¨aven Android en v¨alk¨and attackyta. Attackm¨ojligheterna skiljer sig inte speciellt mot andra opera-tivsystem. Standardattacker som buffer overflow och race condition g¨aller ¨
aven f¨or Android. Det ¨ar ¨aven fullt m¨ojligt att s¨akerhetsh˚al f¨or Linuxk¨arnan som uppt¨acks i andra sammanhang ocks˚a kan vara aktuella s¨akerhetsh˚al till Android. Det finns k¨anda attacker [40] mot Android d¨ar man har utnyttjat k¨anda s¨akerhetsh˚al f¨or att skaffa sig root utan att anv¨andaren uppt¨acker attacken.
5.1.2
Loggning
En viktig del av p˚alitligheten i ett system ¨ar att man kan f¨olja h¨ andel-sef¨orloppet genom loggning. D¨arf¨or ¨ar det mycket viktigt att integriteten p˚a loggningen ¨ar h¨og. Ett potentiellt problem som l¨att kan f¨orbises vid designandet av loggningsfunktionen ¨ar att ett program kraschar efter att den utf¨ort sin uppgift men innan loggning hunnit att ske. I den utvecklade applikation skulle detta kunna vara att en uppl˚asning av en d¨orr utf¨ors men att applikationen sedan kraschar innan en skrivning till loggen skett p˚a grund av att telefonens minne ¨ar fullt exempelvis. I praktiken kan man d˚a l˚asa upp d¨orrar utan att l¨amna loggar efter sig. I detta fall ¨ar det allts˚a viktigt att loggning sker innan till exempel en uppl˚asning utf¨ors.
Att s¨anka tillg¨angligheten p˚a applikationen, genom att den slutar fun-gera om m¨ojligheten att skriva till loggen inte finns, ¨ar en rimlig l¨osning. Likv¨al om applikationen inte kan synkronisera loggarna tillbaka till serven inom till exempel 4 timmar borde anv¨andaren informeras och applikationen sluta fungera.
5.1.3
R¨
attigheter f¨
or filer och databaser
En viktig s¨akerhetsaspekt i de flesta system ¨ar att ˚atkomst till filer och funktioner endast ¨ar till˚atet f¨or de som har r¨att till det. I Android ¨ar det
Resultat och analys 31
viktigt att de r¨attigheter som s¨atts p˚a de filer som ska vara privata f¨or applikationen ¨ar r¨att. Filer kan ha tre olika r¨attigheter.
MODE PRIVATE Med denna r¨attighet kan endast den egna applikatio-nen, eller en applikation med samma UID, l¨asa och skriva till filen.
MODE WORLD READABLE Med denna r¨attighet kan alla andra
applikationer l¨asa filen men inte skriva till den.
MODE WORLD WRITEABLE Med denna r¨attighet kan alla
appli-kationer i systemet b˚ade l¨asa och skriva till filen.
En databas i Android lagras som en fil och r¨attigheter till denna ges p˚a samma s¨att som till filerna. Om en utvecklare slarvar och s¨atter fel r¨attigheter p˚a filer eller databaser kan detta leda till att information stj¨als eller att n˚agon helt enkelt ¨andrar informationen och d˚a spelar det ingen roll hur stor s¨akerheten ¨ar i applikationen i ¨ovrigt.
Nyligen uppt¨acktes det att information fr˚an Skypes androidapplikation kunde l¨acka till obeh¨origa [41]. Orsaken var d˚aligt satta r¨attigheter p˚a databaserna som hanterade anv¨andarnas uppgifter. Ist¨allet f¨or att endast skypeapplikationen hade tillg˚ang till databasen, allts˚a att r¨attigheten ”MO-DE PRIVATE” valts, hade samtliga applikationer l¨asr¨attigheter och kunde d¨arf¨or potentiellt l¨asa ut data fr˚an databasen. Datan i databasen var ocks˚a lagrad okrypterad. En svaghet som detta borde s˚aklart ha uppt¨ackts innan applikationen sl¨appts. H¨ar hj¨alper metoder som exempelvis STRIDE till att uppt¨acka f¨orekomster av enkla men allvarliga svagheter som denna.
5.1.4
Androids aktivitetsstack
N¨ar en ny aktivitet startas i Android l¨aggs den p˚a en aktivitetsstack som hanteras av operativsystemet. Den aktivitet som senast k¨orde ligger d˚a kvar under den nya aktiviteten och n¨ar den nya aktiviteten p˚a n˚agot s¨att avslutas, ˚aterupptas den aktivitet som nu ligger h¨ogst upp p˚a stacken. Ett s¨att att avsluta en aktivitet ¨ar att anv¨anda den bak˚atknapp som finns p˚a m˚anga androidtelefoner.
H¨ar har vi uppt¨ackt ett m¨ojligt s¨akerhetsproblem. Ponera att en ap-plikation har en inloggningsfunktion. N¨ar anv¨andaren loggat in anv¨ands
32 5.1. Identifierade s¨akerhetsproblem
applikationen p˚a korrekt s¨att och anv¨andaren loggar sedan ut och appli-kationen ˚aterg˚ar d˚a till inloggningssk¨armen. Om anv¨andaren d˚a trycker p˚a bak˚atknappen kan senast anv¨anda aktivitet visas f¨or anv¨andaren. Det-ta kan d˚a vara en aktivitet som inte avslutades n¨ar anv¨andaren loggade ut fr˚an applikationen vilket eventuellt kan leda till att applikationen kan anv¨andas trots att anv¨andaren egentligen ¨ar utloggad. Det ¨ar viktigt att t¨anka p˚a hur Android hanterar aktiviteter och tj¨anster s˚a att problem som dessa inte uppst˚ar. Det finns vissa sv˚arigheter med att l¨osa detta problem. En l¨osning p˚a detta ¨ar dock att anv¨anda sig av en intentflagga som heter ”FLAG ACTIVITY CLEAR TOP” n¨ar startaktiviteten anropas[42]. Den-na flagga inneb¨ar att alla aktiviteter som ligger ¨over den anropade aktivi-teten avslutas och den anropade aktiviaktivi-teten hamnar h¨ogst upp p˚a stacken. Genom att utf¨ora omfattande tester vid utveckling av applikationer som g¨or undantag fr˚an Androids standardhantering av aktiviteter kan liknande problem uppt¨ackas tidigt under utvecklingen och inte n¨ar applikationen ¨ar sl¨appt.En god f¨orst˚aelse f¨or hur Androids aktivitetscykel och aktivitetshan-tering rekommenderas ocks˚a.
5.1.5
SQL-injektion
D˚a varje applikation har tillg˚ang till en sqldatabas ¨ar attacken aktuell. En SQL-injektionattack ¨ar en attack som utnyttjar d˚aligt saniterad indata och anv¨ander indatan i fr˚agor mot databas. Genom v¨alutformad indata kan en anfallare plocka ut eller ¨andra data i databasen. Ett exempel visas nedan [43][44]. Tanken med f¨oljande query ¨ar att f˚a ut anv¨andardata fr˚an anv¨andartabellen f¨or det username som anges.
q u e r y = ”SELECT * FROM u s e r s WHERE name =” + username + ” ; ”
Om en anv¨andare skriver in anv¨andarnamnet som ‘ or ‘1’ = ‘1 resulterar detta ist¨allet i att all anv¨andardata returneras.
SELECT * FROM u s e r s WHERE name = ”” or 1=1;
I Android, liksom i m˚anga andra moderna system, mitigeras attackerna genom funktionalitet f¨or att hj¨alpa programmeraren att utforma sql fr˚agor och att sanera indata. Det ¨ar viktigt d˚a det kan vara m˚anga steg mellan skapande av databasfr˚agan och exekveringen av fr˚agan. Ett vanligt exem-pel ¨ar att kommunikation sker indirekt med en databas via en content
Resultat och analys 33
resolver som i sin tur kommunicerar med en content provider. Ett viktigt verktyg i kampen mot SQL-injektion ¨ar funktionen query i SQLiteQuery-Builder. Denna funktion anv¨ander sig av parametrisering av sql-argument. Parametrisering inneb¨ar att de argument som anv¨ands f¨or att utf¨ora se-lektionen j¨amf¨ors i sin helhet och kan allts˚a inte tolkas som ytterligare SQL-kommandon.
F¨or att hj¨alpa till med sanering av indatan finns funktionen append-WhereEscapeString i SQLiteQueryBuilder [45]. Denna funktion saniterar str¨angar fr˚an escape tecken.
Genom att anv¨anda sig av Androids inbyggda l¨osningar kan man f¨ or-sv˚ara utf¨orandet av SQL-injektionsattacker. Attacken kan ¨aven ske mot den server som applikationen kommunicerar med och n¨odv¨andiga ˚atg¨arder b¨or g¨oras ¨aven p˚a denna del av systemet.
5.1.6
Gamla versioner
Ett problem ¨ar att m˚anga telefoner k¨or gamla versioner av Android som eventuellt har kvar gamla svagheter. En stor orsak till detta ¨ar att det ¨ar tillverkarna av telefonerna som har ansvar f¨or att skicka ut uppdateringar till telefonerna. Flera tillverkare prioriterar inte uppdateringar f¨or ¨aldre telefonmodeller
5.2
Hj¨
alpmedel
I detta avsnitt beskrivs n˚agra av de hj¨alpmedel som kan utnyttjas av ut-vecklare f¨or att ¨oka s¨akerheten p˚a applikationerna.
5.2.1
Obfuskering
All kod g˚ar att dekompilera f¨or att kunna se hur applikationen ¨ar byggd. Obfuskering d¨oper om variabler till oigenk¨annlighet, tar bort d¨od kod och tar bort alla kommentarer. Koden kommer inte att bli om¨ojlig att l¨asa men det kommer att ta betydligt l¨angre tid. Eftersom obfuskering h¨anger starkt ihop med spr˚ak och byggprocessen har endast obfuskering r¨orande androidplattformen ber¨orts.
34 5.2. Hj¨alpmedel
ProGuard
Det obfuskeringsverktyg som Android har valt att integrera heter ProGu-ard. Det ¨ar ett ¨oppenk¨allkodsprojekt och har funnits l¨angre ¨an Android och fungerar f¨or Java i allm¨anhet. ProGuard f¨oljer med bland Androids utvecklingsverktyg och integreras v¨al med resten av processen som ¨ar au-tomatiserad om man anv¨ander till exempel Eclipse som utvecklingsmilj¨o. N¨ar ProGuard ¨ar aktiverat k¨ors classfilerna ett varv genom ProGuard innan de ¨overs¨atts till dexfiler. Det h¨ar g¨aller bara n¨ar applikationen ¨ar i s˚a kallat releasel¨age och inte i utvecklingsl¨age d˚a obfuskering f¨orsv˚arar debuggning.
Hur stor skillnad g¨or obfuskering
En del av koden ur den applikation som utvecklades kan ses nedan. ¨Overst visas originalk¨allkoden, i mitten en uppackad apkfil utan obfuskering och sest en uppackad apkfil med obfuskering.
// S e t v a r i a b l e s s a l t T a s k = new S a l t H e l p e r ( ) ; l o g i n T a s k = new L o g i n H e l p e r ( ) ; Button btn = ( Button ) f i n d V i e w B y I d (R . i d . l o g i n b u t t o n ) ; u s e r n a m e E d i t T e x t = ( E d i t T e x t ) f i n d V i e w B y I d (R . i d . l o g i n u s e r n a m e e d i t t e x t ) ; Button l o c a l B u t t o n = ( Button ) f i n d V i e w B y I d ( 2 1 3 1 3 6 1 8 1 9 ) ; E d i t T e x t l o c a l E d i t T e x t 1 = ( E d i t T e x t ) f i n d V i e w B y I d ( 2 1 3 1 3 6 1 8 1 5 ) ; t h i s . u s e r n a m e E d i t T e x t = l o c a l E d i t T e x t 1 a l o c a l a = new a ( ) ; t h i s . e = l o c a l a ; c l o c a l c = new c ( ) ; t h i s . f = l o c a l c ; Button l o c a l B u t t o n = ( Button ) f i n d V i e w B y I d ( 2 1 3 1 3 6 1 8 1 9 ) ; E d i t T e x t l o c a l E d i t T e x t 1 = ( E d i t T e x t ) f i n d V i e w B y I d ( 2 1 3 1 3 6 1 8 1 5 ) ; t h i s . b = l o c a l E d i t T e x t 1 ;
Som exemplet ovan visar ¨ar koden fortfarande relativt l¨asbar. Namn-valen f¨orsvinner vilket f¨orsv˚arar l¨asandet. Dock ¨ar alla externa API-anrop fullt l¨asbara. S˚a obfuskeringen i ett starkt typat spr˚ak som Java ¨ar inte speciellt effektiv. Aktiveringen av ProGuard ¨ar dock enkel och en utveckla-re b¨or anv¨anda denna funktion. Utvecklaren b¨or vara medveten om graden av obfuskering.
Resultat och analys 35
5.2.2
St¨
od f¨
or kryptering
Kryptering ¨ar en s¨akerhetsfunktion som anv¨ands f¨or att skydda sig mot tjuvlyssning av data men ocks˚a mot o¨onskad manipulering. I systemet har fyra olika delar f¨or vilket behovet av kryptering har identifierats. Kommu-nikationen med servern, inst¨allningsfiler, den lokala databasen och kommu-nikation med l˚aset.
F¨or kryptering av kommunikation ¨ar krypteringen redan definierade av det befintliga systemet. Protokollet f¨or kommunikation med servern sker i SSL/TLS d¨ar Android har ett v¨alutvecklat st¨od. Android API skeppas med Apaches httpklient, vilket ¨ar en klient som ¨ar flera ˚ar ¨aldre ¨an Android [46]. Applikationen hanterar data som ¨ar intressant att h˚alla hemlig till exempel anv¨andaruppgifter och kryptonycklar till l˚asen men applikationen skickar ¨aven hem loggar d¨ar integriteten ¨ar prioriterad. D˚a ¨ar SSL/TLS bra d˚a det st¨odjer autentisering av servern, krypterar data samt skyddar data fr˚an manipulering. L˚asets kryptering ¨ar inget som st¨ods direkt av Android utan kr¨aver ett tredjepartsbibliotek. Biblioteket som anv¨ants heter Bouncy Castle1[47] som st¨odjer ett flertal av krypteringsalgoritmer. Bouncy Castle ansvarar f¨or kryptering ¨over den okrypterade Bluetooth kopplingen gentemot l˚aset. Det var ett krav d˚a l˚aset bara kommunicerade krypterat.
Kryptering av lagrad data ¨ar ett svagt skydd. Nyckeln m˚aste finnas i applikationen vilket g¨or det fullt m¨ojligt att dekompilera applikationen och utl¨asa nyckeln. Det skulle skydda mot program som till exempel massinsam-lar information men har lyckats ta sig runt sandboxningen. F¨or kryptering av filer har inte Android n˚agon eget utvecklat utan anv¨ander sig av javas st¨od via javax.crypto. Bouncy Castle ¨ar ett rimligt alternativ speciellt d˚a det redan anv¨ands i applikationen. Kryptering av databasen finns det inget inbyggt st¨od f¨or. Det finns n˚agra trejdepartsl¨osningar [48] som borde g˚a att f˚a kompatibla, men v˚ar uppfattning ¨ar att det kr¨avs mycket arbete. En annan l¨osning ¨ar att kryptera texten innan den lagras till databasen, h¨ar kan dock datam¨angden ¨oka v¨asentligt. Ett test utf¨ordes genom att kryp-tera en 50 tecken l˚ang str¨ang med algoritmen Blowfish. Den krypterade str¨angen resulterade i en 96 tecken l˚ang str¨ang. Eftersom SQLitedataba-sen som skeppas med Android har en begr¨ansning p˚a att storleken inte f˚ar ¨
overstiga 1 MB ¨ar detta ett relevant problem. Blowfish ¨ar en symmetrisk
36 5.3. Distribution
kryptering s˚a storleksbegr¨ansningen blir mer aktuell om en asymmetrisk algoritm anv¨ands ist¨allet. Kryptering av f¨alt i databasen ¨ar m¨ojligt och beror p˚a m¨angden data, storlek p˚a nycklar och val av algoritm.
5.3
Distribution
HOW Solutions var intresserade av alternativ till Android Market. I det h¨ar stycket unders¨oks n˚agra olika s¨att f¨or att distribuera applikationen. Ur ett s¨akerhetsperspektiv ¨ar det viktigt med en v¨al definierad infrastruktur f¨or att kunna uppdatera klienterna.
5.3.1
Nackdelar med Android market
Det som g¨or market oattraktivt f¨or f¨oretagsapplikationer ¨ar att det p˚a market inte g˚ar att begr¨ansa vilka som ska f˚a ladda ner applikationerna2. Vid rapportens skrivande finns det ingen r¨attighetsmodell utan en appli-kation ¨ar tillg¨anglig f¨or alla [50]. F¨oretag kan ha ett intresse att deras f¨oretagsapplikationer inte sprids ¨oppet. En annan begr¨ansning p˚a market ¨
ar att anv¨andarna m˚aste vara kopplade till ett googlekonto.
5.3.2
Krav
HOW Solutions ville att plattformen skulle st¨odja vissa delar med avseen-de p˚a distribution. Ett krav var att det ska g˚a att automatisk uppdatera applikationen. Vid en ny version av applikationen ska enheterna ladda ner och installera den nya versionen. Installationen av den nya versionen b¨or vara osynlig f¨or anv¨andarna.
Ett annat krav var m¨ojligheten att kunna skicka ut telefonspecifika ap-plikationer. Det inneb¨ar att en inst¨allningsfil inneh˚allande unik data f¨or enheten m˚aste inkluderas i installationsfilen.
Det sista kravet var att centralt kunna skicka applikationen till en ny telefon utan att fysiskt beh¨ova hantera telefonen.
2Man kan vid utveckling av applikationen definiera vilka krav som m˚aste uppfyllas
av telefonen som ska k¨ora applikationen. Detta kan vara exempelvis mjukvaruversion, sk¨armstorlek eller touchsk¨arm. Detta ¨ar dock inte anv¨andbart i detta fall [49].
Resultat och analys 37
5.3.3
Automatiskt uppdatering
Tv˚a m¨ojliga l¨osningar f¨or automatisk uppdatering identifierades. Anting-en sk¨oter varje applikation sina egna uppdateringar eller s˚a ansvarar en separat applikation f¨or att sk¨ota de andra applikationernas uppdateringar likt en pakethanterare. Pakethanterare l¨ampar sig om organisation har fle-ra olika applikationer f¨or sina anst¨allda. Eftersom det f¨or tillf¨allet bara var aktuellt med en applikation valdes l¨osningen med att applikationen sk¨ ot-te uppdaot-teringen sj¨alv. L¨osningen var att rikta ett Intent.ACTION VIEW mot application/vnd.android.package-archive. Android ger applikationen en tydlig kommunikationskanal mot systemets installationsprogram. Det gick inte att f˚a uppdateringen osynligt mot anv¨andaren vilket b˚ade kan va-ra en f¨ordel och en nackdel. N¨ar installationsprogrammet tar ¨over s˚a kr¨avs godk¨annande av anv¨andaren vid installationen ¨aven om det bara ¨ar en ny version av applikationen.
5.3.4
Telefonspecifika installationsfiler
HOW Solutions har implementerat denna s¨akerhets˚atg¨arden i sitt nuvaran-de system. Tanken ¨ar att applikationen ska paketeras med telefonspecifika inst¨allningar innan den distribueras till telefonen. Om applikationen k¨ors p˚a en annan telefon ¨an applikationen var byggd f¨or s˚a ska applikationen varna och sluta fungera. Det finns inte n˚agon f¨ardig l¨osning likt l¨osningen i J2ME. I J2ME var det m¨ojligt att ha en separat fil kallad Java Application Descriptor (JAD) d¨ar inst¨allningar f¨or programfilen kunde genereras innan applikationen distribuerades.
I ett tidigare stycke presenterades hur paketeringen f¨or Android g˚ar till se sektion 3.1.5. Det ¨ar fullt m¨ojligt att bygga en l¨osning med liknade resultat som i den befintliga l¨osningen. De telefonspecifika inst¨allningarna m˚aste dock l¨aggas in i sj¨alva installationspaketet vilket g¨or att det f¨or¨ andra-de paketet m˚aste signeras. Signeringen kr¨aver att den privata nyckeln samt l¨osenordet m˚aste vara tillg¨angligt f¨or distributionsservern vilket minskar s¨akerheten runt nyckelhanteringen. Detta ¨ar en mycket stor risk och en annan l¨osning vore att f¨oredra.
38 5.3. Distribution
5.3.5
Initialinstallation fr˚
an en centralpunkt
Kravet ¨ar v¨aldigt beroende p˚a befintlig infrastruktur i organisationen. Tv˚a olika kommunikationsv¨agarna var relevanta och dessa var e-post och SMS. Den mest tillg¨angliga tekniken ¨ar SMS d˚a varje enhet m˚aste vara upp-kopplad mot mobiln¨atet och d¨ar igenom st¨odjer enheten SMS automatiskt. D¨aremot m˚aste inte varje enhet ha ett epostkonto inkopplat. SMS har ock-s˚a f¨ordel av att vara krypterad[51] per automatik till skillnad fr˚an epost. Nackdelen med SMS ¨ar att varje SMS har en kostnad knuten till sig till skillnad fr˚an epost. Oavsett teknik f¨oresl˚ar vi att distributionen sker via utskick av en nedladdningsl¨ank. Det medf¨or mindre exponering av instal-lationsfilen.
5.3.6
S¨
akerhetsaspekter p˚
a designf¨
orslag
Automatiska uppdateringar ¨oppnar f¨or nya attacker genom att byta ut uppdateringen mot skadlig kod. D¨arf¨or ¨ar det l¨ampligt att verifiera signatu-rerna. Signaturen kan verifieras p˚a servern. En kontroll av den nedladdade uppdateringens signatur innan apkn l¨amnas ¨over till installationsprogram-met b¨or ocks˚a utf¨oras. ¨Aven om Android skulle skilja p˚a den installera-de applikationen och en utbytt applikation via installera-deras signaturer s˚a skulle Android inte kunna uppt¨acka att det ¨ar skadlig kod. Applikationen skulle d˚a installeras som en ny applikation ist¨allet f¨or att ers¨atta den gamla.
Kapitel 6
Diskussion
I detta kapitel diskuteras resultatet i f¨oreg˚aende kapitel och f¨orslag p˚a vi-dare studier ges.
6.1
Diskussion av resultatet
Det st¨orsta s¨akerhetshotet mot f¨oretagsapplikationer p˚a Android ¨ar att en-heten p˚a n˚agot s¨att rootas. I en rootad telefon har anv¨andaren tillg˚ang till root-anv¨andaren som har fullst¨andiga systemr¨attigheter. Det ¨ar inte sj¨alva rootningen i sig som hotar applikationen utan bristen p˚a begr¨ansningar f¨or rootkontot som m¨ojligg¨or applikationer att utf¨ora annars otill˚atna aktivite-ter. F¨oretagetapplikationer b¨or ej lita p˚a operativsystemet och sin privata data om 3:e parts applikationer kan f˚a tillg˚ang till rootr¨attigheter. Det ¨ar ytterst sv˚art att s¨akerst¨alla integriteten eller konfidentialiteten i det fallet. Google har i de senare versionerna av Android ¨oppnat f¨or funktionali-tet som inte varit tillg¨angligt tidigare men som har varit m¨ojligt med en rootad telefon. Ett exempel p˚a detta ¨ar att lagra och k¨ora applikationer fr˚an minneskortet. Det kan dock diskuteras om detta har att g¨ora med att Google vill minska anledningarna f¨or att roota telefonen eller om de helt enkelt ger anv¨andarna vad de vill ha. Oavsett motiv ¨ar detta en positiv utveckling och det ¨ar viktigt att minska incitamentet f¨or rootning.
40 6.1. Diskussion av resultatet
Ett stort problem ¨ar att m˚anga av de telefoner som finns p˚a marknaden fortfarande k¨or p˚a gamla versioner av Android och d¨armed fortfarande kan ha kvar allvarliga s¨akerhetsh˚al. Det ˚aligger telefontillverkaren att sl¨appa de nya versionerna till deras telefoner. Att dessa uppdateringar ¨aven kommer ut till gamla telefoner ¨ar mycket viktigt och en f¨orb¨attring av detta ¨ar v¨alkommet.
Kryptering i Android, speciellt med avseende p˚a databasen, ¨ar omst¨ an-digt.H¨ar finns det m¨ojlighet att f¨orenkla och hj¨alpa utvecklarna att lyckas med implementationen. Genom att implementera denna funktionalitet i API:et ¨okar kan utvecklare f˚a b¨attre st¨od. Ett s¨akerhetsl¨age f¨or applikatio-ner likt m¨ojligheten att lagra applikationen p˚a minneskortet men d˚a ist¨allet lagra p˚a en krypterad partition ¨ar ocks˚a en intressant l¨osning.
Utvecklaren f˚ar ett bra st¨od fr˚an operativsystemet. Androids sandbox-ning ¨ar genomarbetad och stark. S¨akerhetskedjan som bildas genom m˚anga olika lager g¨or att s¨akerheten ¨ar h¨og. Kravet p˚a signering av applikationer anv¨ands f¨or att starkt knyta ihop utvecklaren och applikationen. Varje applikation k¨ors som en egen anv¨andare med f¨oljden att linuxk¨arnans mul-tianv¨andarst¨od skyddar filsystem, processer och sessionsdata. Sista delen i kedjan ¨ar systemets nya funktionalitet f¨or att kommunicera med “content providers” och liknade. Kedjan avlastar utvecklaren men ansvar ligger fort-farande kvar hos utvecklaren som har m¨ojlighet att bryta sandboxningen. Utvecklarnas ansvar ¨ar, som s˚a ofta i s¨akerhetsarbete, att undvika slarv. Att bygga mjukvara ¨ar sv˚art och kan STRIDE anv¨andas som metod f¨or att minska slarvet och systematisera s¨akerhetsarbetet. ¨Aven om diskussionsfr˚ a-gorna inte var specifika f¨or Android var detta ett bra hj¨alpmedel.
Distribution av applikationen till enheterna fungerar tillfredsst¨allande f¨or f¨oretagsapplikationer. Androids l¨osning var ¨oppen och flexibel och m¨ oj-ligt att bygga egna l¨osningar med integration mot befintlig infrastruktur ¨
ar antagligen m¨ojlig i de flesta fall. Applikationens signatur ¨ar det viktiga f¨or operativsystemet. D¨arf¨or ¨ar det v¨aldigt viktigt att skydda den privata nyckel och d¨arf¨or b¨or den privata nyckeln inte vara lagrad p˚a media som ¨
Diskussion 41
6.2
Vidare studier
Under arbetets g˚ang har s¨akerhetsproblem identifierats genom att studera litteraturen samt utf¨orande av s¨akerhetsmetoder under kravframst¨allning och design.. Ett intressant omr˚ade f¨or vidare studier ¨ar att ist¨allet un-ders¨oka s¨akerheten i en redan utvecklad applikation genom att till exempel anv¨anda sig av penetrationstestning. En studie som syftar till att unders¨oka vilka s¨akerhetsmetoder som kan anv¨andas vid utveckling av mobilapplika-tioner hade ocks˚a varit intressant. Den litteratur som finns att tillg˚a vid skrivandets stund ¨ar tunn och d¨arf¨or vore det intressant med fler artiklar ang˚aende ¨amnet.
Det hade ocks˚a varit intressant med en mer omfattande j¨amf¨orelse mel-lan de tre stora mobilplattformarna: Android, iOS och Windows Phone 7 med avseende p˚a s¨akerheten. En unders¨okning med fokus p˚a distribution av applikationer och program hade ocks˚a varit intressant.
Litteraturf¨
orteckning
[1] P1-Morgon. Mobil os¨akerhet. http://sverigesradio.se/sida/ artikel.aspx?programid=1650&artikel=4343964, februari 2011. H¨amtad 2011-03-05 09:00.
[2] SONIA KOLESNIKOV-JESSOP. Hackers go after the
smartp-hone. http://www.nytimes.com/2011/02/14/technology/
14iht-srprivacy14.html?_r=1&scp=4&sq=smartphones&st=cse, februari 2011. H¨amtad 2011-05-03 09:00.
[3] Software Security: Building security in. Addison-Wesley, 2006.
[4] Chris McDermott, John & Fox. Using abuse case models for security requirements analysis. In Proceedings of the 15th Annual Computer Security Applications Conference, pages 55–66. ACSAC, IEEE Com-puter Society, 1999.
[5] Andreas L Sindre, Guttorm & Opdahl. Capturing security require-ments through misuse cases. Norsk informatikkonferanse, 2001. [6] Andreas L Sindre, Guttorm & Opdahl. Eliciting security requirements
with misuse cases. Requirements Engineering, 10(1):34–44, January 2004.
[7] Writing effective use cases. Addison-Wesley, 2001.
[8] Nancy R Mead. Security quality requirements engineering (square) methodology. In ACM SIGSOFT Software Engineering Notes.
