5.3 Distribution
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 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.
LITTERATURF ¨ORTECKNING 43
[9] Nancy R Mead. Security requirements engineering. https:// buildsecurityin.us-cert.gov/bsi/articles/best-practices/ requirements/243-BSI.html, augusti 2006. H¨amtad 2011-05-11 11:20.
[10] John Viega. Building security requirements with clasp, 2005.
[11] Nancy R Mead. Square process. https://buildsecurityin.
us-cert.gov/bsi/articles/best-practices/requirements/ 232-BSI.html, januari 2006. H¨amtad 2011-05-11 11:20.
[12] Charles B m.fl Haley. Security requirements engineering: A framework for representation and analysis. IEEE Transactions on Software Engi- neering, 34:133–153, jan-feb 2008.
[13] Microsoft. The stride threat model. http://msdn.microsoft.com/ en-us/library/ee823878(v=cs.20).aspx, 2005. H¨amtad 2011-05- 11 11:20.
[14] Confidentiality, integrity and availability (cia). http://it.med. miami.edu/x904.xml. H¨amtad 2011-05-10 11:08.
[15] Steve Howard, Michael & Lipner. The Security Development Lifecycle. Microsoft Press, 2006.
[16] What is android? http://www.android.com/about/. H¨amtad 2011- 04-14 16:13.
[17] Android (operating system). http://en.wikipedia.org/wiki/ Android_(operating_system). H¨amtad 2011-04-14 16:21.
[18] Daniel Claesson. Market vs app store. http://www.mobilzonen.se/ kronika-market-vs-app-store/, augusti 2010. H¨amtad 2011-04-14 16:44.
[19] Mobile Application Security. McGraw-Hill/Osborne, 2010.
[20] Activities. http://developer.android.com/guide/topics/
44 LITTERATURF ¨ORTECKNING
[21] Application fundamentals. http://developer.android.com/guide/ topics/fundamentals.html. H¨amtad 2011-04-19 14:59.
[22] Uniform resource identifier. http://en.wikipedia.org/wiki/ Uniform_Resource_Identifier. H¨amtad 2011-04-19 16:01. [23] Broadcastreceiver. http://developer.android.com/reference/ android/content/BroadcastReceiver.html. H¨amtad 2011-04-18 15:51. [24] Intent. http://developer.android.com/reference/android/ content/Intent.html. 2011-04-20 11:55. [25] http://developer.android.com/guide/topics/intents/ intents-filters.html. H¨amtad 2011-04-20 11:55.
[26] What is android? http://developer.android.com/guide/basics/ what-is-android.html. H¨amtad 2011-04-14 14:39.
[27] Google. Security and permissions. http://developer.android.com/ guide/topics/security/security.html. H¨amtad 2011-04-14 14:50. [28] Wikipedia. Sandbox (computer security. http://en.wikipedia.org/
wiki/Sandbox_(computer_security). H¨amtad 2011-04-14 14:51.
[29] Amit Singh. A taste of computer security. http://www.
kernelthread.com/publications/security/sandboxing.html, ju- ni 2004. H¨amtad 2011-04-14 14:51.
[30] Niclas Axelsson. Erlang for the android platform. http://www. burbas.se/artiklar/erlang-for-the-android-plattform/, november 2010. H¨amtad 2011-05-23 11:35.
[31] Mono for Android. Mono for android. [32] Google. Building and running.
[33] Google. Manifest.permissions. http://developer.android.com/ reference/android/Manifest.permission.html. H¨amtad 2011-04- 01 13:14.
LITTERATURF ¨ORTECKNING 45
[34] Google. Signing your applications. http://developer.android.com/ guide/publishing/app-signing.html. H¨amtad 2011-04-14.
[35] Understanding the Linux Kernel. O’Reilly Media, third edition, no- vember 2005.
[36] Philippe Hanrigou. In unix everything is a file. http://ph7spot. com/musings/in-unix-everything-is-a-file. H¨amtad 2011-09-19 13:28.
[37] Google. Localization. http://developer.android.com/guide/ topics/resources/localization.html. H¨amtad 2011-04-28 14:23. [38] Google. Locale. http://developer.android.com/reference/java/
util/Locale.html. H¨amtad 2011-04-28 14:23.
[39] Google. The world of listview. http://developer.android.com/ videos/index.html, Maj 2010. H¨amtad 2011-05-27 11:05.
[40] Tim Strazzere. Update: Android malware droiddream:
How it works. http://blog.mylookout.com/2011/03/
android-malware-droiddream-how-it-works/, mars 2011. H¨amtad 2011-04-26 12:35.
[41] Justin Case. Exclusive: Vulnerability in skype for andro-
id is exposing your name, phone number, chat logs, and
a lot more. http://www.androidpolice.com/2011/04/14/
exclusive-vulnerability-in-skype-for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/, April 2011. H¨amtad 2011-05-26 17:00.
[42] Google. Intent. http://developer.android.com/reference/
android/content/Intent.html#FLAG_ACTIVITY_CLEAR_TOP. H¨am- tad 2011-05-02 12:35.
[43] Wikipedia. Sql-injektion. http://sv.wikipedia.org/wiki/
SQL-injektion. H¨amtad 2011-05-10 09:14.
[44] Wikipedia. Sql-injection. http://en.wikipedia.org/wiki/
46 LITTERATURF ¨ORTECKNING
[45] Google. Sqlitequerybuilder. http://developer.android.com/ reference/android/database/sqlite/SQLiteQueryBuilder.
html#appendWhereEscapeString(java.lang.String). H¨amtad
2011-05-04 12:59.
[46] The Apache Software Foundation. Apaches hemsida. http://hc. apache.org/news.html. H¨amtad 2011-04-19 15:40.
[47] ¨Oppenk¨allkod. Bouncy castle crypto api. http://www.bouncycastle. org/. H¨amtad 2011-05-27 10:44.
[48] SQLiteCrypt. Sqlite crypt. http://sqlite-crypt.com. H¨amtad 2011-04-19 15:31.
[49] Google. Market filters. http://developer.android.com/guide/ appendix/market-filters.html. H¨amtad 2011-05-11 14:16.
[50] Google. Putting android to work for your busi-
ness. http://googleenterprise.blogspot.com/2011/04/
putting-android-to-work-for-your.html, april 2011. H¨am-
tad 2011-04-25 13:25.
[51] Dieter Gollmann. Computer Security. John Wiley & Sons, Ltd, second edition, 2006.
Bilaga A
Misuse cases
Autentisera sig som annan användare
Sammanfattning: En skurkaktig användare av systemet tillskanskar sig en annan användares
inloggningsuppgifter och autentiserar sig mot systemet.
Författare: Per Jinnegren & Erik Thorselius Datum: 2011-03-16
Standardväg:
1. En naiv användare lånar ut sina inloggningsuppgifter till angriparen.
2. Angriparen loggar in med en annan användares inloggningsuppgifter.
3. Angriparen använder applikationen i en annan användares namn.
Alternativa vägar:
1. Istället för punkt 1 kan angriparen snappa upp uppgifterna genom att avläsa
tangentbordet på telefonen när användaren skriver in sina uppgifter antingen genom att installera ett program som avlyssnar tangentbordstryckningar eller genom att se knapptryckningarna visuellt.
2. Istället för punkt 1 kan angriparen avlyssna nätverkstrafiken och på så sätt få reda på användaruppgifter.
3. Istället för punkt 1 kan angriparen ha fått tag i en användares inloggningsuppgifter till någon annan tjänst till exempel en eposttjänst. Många använder idag samma lösenord på flera ställen.
Mitigering: En viktig funktion för att mitigera standardvägen dvs en osund lösenordskultur är att
diskutera spårbarhet och ansvar men också ge användarna möjlighet att byta lösenord. Det går dock aldrig att förhindra detta hot helt. För att mitigera av3 kan man informera användarna att inte använda samma lösenord för inloggningen på appen som de gör privat.
Anknutna misuse cases: Avlyssna nätverkstrafiken Utlösande faktor: Kan alltid ske
Antagande: Angriparen har fysisk tillgång till klienten.
Önskad mitigeringsförsäkran: En användare kan inte få tag i en annan användares uppgifter. Värsta möjliga hot: Angriparen använder applikationen för att utföra brottsliga handlingar och
den oskyldiga användaren får skulden.
Potentiell missanvändarprofil: Ingen signifikant teknisk kunskap.
Byta ut applikationen vid uppdatering
Sammanfattning: När applikationen hämtar en ny applikation så kan angriparen byta ut
applikationen mot en egen applikation.
Författare: Erik Thorselius Datum: 2011-03-21 Standardväg:
1. Applikationen ringer hem och upptäcker att det finns en ny version av applikationen. 2. Genom någon man-in-the-middleattack lyckas angriparen få applikationen att hämta en
egen utvecklad applikation istället för den nya versionen.
3. Då applikationen kommer vara signerade med olika certifikat installeras den som en ny användare.
Alternativa vägar:
1.
a. Istället för sv3 så har angriparen har tillgång till utveckarens certifikat.
b. Applikationen installeras som med samma användare som orginalapplikationen.
Mitigering: Sv: Attacken kan mitigeras på två ställen, ena är motverka man-in-the-
middleattacken och den andra är när applikationen är nerladdad att då verifera singeringen.
Av1: Är mycket svår att mitigera då utveckarcertifikatet är stulet. Se det anknutna misuse caset. Anknutna misuse cases: Få systemrättigheter genom rootning, stöld av certifikat
Utlösande faktor: Det finns en ny uppdatering av applikationen och användaren vill ladda ner
denna.
Villkor: Möjligheten av uppdatering av applikationen via telefonen.
Värsta möjliga hot: Sv: Öppnar upp för stöld av användaruppgifter och privatdata. Den öppnar
även upp för en egen klient som rapporterar felaktigheter till servern.
Potentiell missanvändarprofil: En teknisk attack där angriparen behöver en stor förståelse hur
Få systemrättigheter genom rootning.
Sammanfattning: Genom att roota telefonen får angriparen tillgång till systemrättigheter och
kan då till exempel läsa av andra applikationers privata data och filer.
Författare: Erik Thorselius och Per Jinnegren Datum: 2011-03-17
Standardväg:
1. Angriparen laddar ner en rootapplikation från Android market eller motsvarande distributionskanal.
2. Angriparen kör applikationen som rootar telefonen.
3. Nu kan även andra program utnyttja funktionallitet som root låser upp till exempel läsa och skriva till privata filer.
Alternativa vägar:
1.
a. Användaren laddar ner applikation från market.
b. Applikationen utan användares vetskap rootar telefonen genom ett säkerhetshål. 2.
a. Angriparen låser upp bootloadern via adb.
b. Användaren laddar ner en .img fil som sedan flashas till telefonen via den upplåsta bootloadern.
Mitigering: Genom återkommande kontroller av telefonerna kan man upptäcka ifall någon
installerat root. Man skulle även kunna tänka sig loggningsystem men den koden är väldigt enhetsberoende.
Anknutna misuse cases: Stulen telefon
Villkor: sv: Det måste vara möjligt att roota telefonen via en applikation. Angriparen måste ha
fysisk tillgång till telefonen vid sv1 och av2.
Antagande: Användarna av telefonen har möjlighet att ladda ner och installera applikationer. Mitigeringsförsäkran: Det kommer alltid att finnas en risk att en telefon rootas. Genom att
kontrollera telefonerna kan man i alla fall upptäcka när det hänt och därefter vidta lämpliga åtgärder.
Värsta möjliga hot: Mycket av androids säkerhet bygger på att det inte finns en system
användare, genom att införa en så sänks säkerheten markant. Att en angripare/elak applikation har fulla rättigheter på telefonen är det största hotet. Möjligheterna att stjäla, manipulera och förstöra står vidöppna. Det svåraste är att förebygga standardvägen då användaren väljer att
Fiffla med databasen genom SQL-
injection
Sammanfattning: Angriparen avläser, ändrar eller på något annat sätt fifflar med databasen
genom att utföra en så kallad SQL-injection.
Författare: Per Jinnegren Datum: 2011-03-17 Standardväg:
1. Angriparen utformar inputdatasom en SQL-fråga som sedan skickas till programmet. 2. Programmet använder datan som angriparen skrivit i ett databasanrop.
3. Programmet avkodar datan som en SQL-fråga och utför angriparens förfrågan.
Mitigering:
1. Genom att använda Androids inbyggda parametrisering av SQL-frågor kan man mitigera detta hot. Se DEVELOPING SECURE MOBILE APPLICATIONS FOR ANDROID
2. Att genomföra kodanalys för att hitta ställen i programmet där man använder input från användaren i SQL-frågor utan att göra någon koll av inputen.
3. Inte ha SQL-frågor som är beroende av användarinput.
4. Genom loggar m.m. kan man se om någon utfört otillåtna anrop till databasen. Detta hindrar inte attacken från att ske men man får i alla fall reda på att något har hänt.
Villkor: Programmet måste använda input från användaren i ett databasanrop. Angriparen
måste ha fysisk tillgång till telefonen.
Antagande: Angriparen har kunskapen och möjligheten att skapa relevanta SQL-frågor.
Mitigeringsförsäkran: Kan förhindras helt om man genomför parametrisering eller att man inte
har SQL-frågor som beror på användarinput.
Värsta möjliga hot: Angriparen får full kontroll över databasen. Relaterade affärsregler: Förlust av känslig data.
Potentiell missanvändarprofil: Tekniskt kunnig.
Berörda parter och hot: Känslig data läcks till obehöriga personer. Detta kan till exempel vara
Stjäla/manipulera privata filer
och inställningar från telefonens
systemminne
Sammanfattning: En angripare försöker stjäla privata filer så som inställningsfiler eller
databasen.
Författare: Erik Thorselius Datum: 2011-03-17 Standardväg:
1. Angriparen lyckas bli root det vill säga system administratör. 2. Angriparen kan då läsa och skriva till programmets privata filer.
Alternativa vägar:
1.
a. Utvecklaren sätter fel rättigheter på dom privata filerna. Filerna blir då publika för hela systemet.
b. Angriparen kan då läsa eller skriva till programmets privata filer. 2.
a. Utveckaren tillåter att applikationen körs från minneskortet.
b. Angriparen kan lättare flytta över informationen till en plattform där angriparen redan är system administratör.
c. Angriparen kan då läsa eller skriva till programmets privata filer.
Mitigering: Alla vägar mitigeraras genom att kryptera den privata informationen eller inte spara
den alls. Sv är otroligt svår att mitigera sig emot. Den av1 är slarv och kan mitigeras med till exempel kodgranskning eller tester. Då av2 är en funktionalitet från opertivsystemt och man skulle kunna mitigera problemet genom att ha olika policy beroende på vart applikationen installeras eller enbart tillåta applikationen på det interna minnet.
Utlösande faktor: Alltid ett hot
Värsta möjliga hot: Information stjäls och loggar manipuleras. Relaterade affärsregler: Förlust av känslig data.
Potentiell missanvändarprofil: En viss datorvana behövs dock ingen avancerad kunskap. Berörda parter och hot: Hotet sträcker sig från utvecklare till fältpersonal.
Stöld av certifikat
Sammanfattning: Android skiller på applikationer genom namnet och vilket certifikat som
applikationen är signerade med. Det går inte att installera en applikation på android utan att ha signerat den. Så den privata nyckeln skapar en koppling mellan applikationen och utvecklaren. Nyckeln skyddas med ett lösenord. Blir den privata nyckeln stulen öppnar det för en uppsjö attacker.
Författare: Erik Thorselius Datum: 2011-03-21 Standardväg:
1. Angriparen kopierar den privata nyckeln. 2. Angriparen stjäl lösenordet till nyckeln.
Mitigering: Det är viktigt att inblandade förstår hur viktig den här filen är. Den är grundbulten
i androids säkerhet. Mitigeringen handlar mer om sunt förnuft genom att inte exponera filen. Man kan tänka sig flera rutiner som mitigerar problemet till exempel att man måste vara 2 personer vid en signering. Att inte förvara lösenordet tillsammans med certifikatet. Att minska tillgängligheten på certifikatet kanske genom att fysiskt låsa in det. Om en stölds upptäcks så är den ända lösningen att byta ut certifikatet och då kommer operativsystemet se det som en ny applikation. Bra distribuerings kanaler underlättar beslutet att byta certifikat.
Värsta möjliga hot: Värsta hotet är att integriteten är bruten. Det är en uppsjö attacker som kan
utföras men det som gör det här hotet unikt är att det inte går att verifiera att applikationen inte är förändrad.
Relaterade affärsregler: Väldigt viktig för produktutvecklingen och lansering av nya funktioner. Potentiell missanvändarprofil: Utvecklare, systemadminstratör eller inbrottstjuv.
Stöld av kod
Sammanfattning: Koden för appen blir stulen på något sätt. Koden kan sedan användas för att
hitta svagheter, sälja till konkurrenter etc.
Författare: Per Jinnegren Datum: 2011-03-21 Standardväg:
1. En utvecklare kopierar källkodsfilerna.
Alternativa vägar:
1.
a. En angripare får tag på applikationens apk-fil.
b. Genom att använda gratis program kan angripareen få ut källkodsfilerna från apk:n och se hur applikationen är skriven.
Mitigering: Standardvägen är mycket svår att mitigera man får dock se till att skydda det
certifikat som applikationen signeras med så att angriparen inte kan skriva elaka versioner av programmet. Av1a: Genom att ta bort apk efter installation kan man undvika att en angripare får tag i apk-filen. Av1b: Här kan man använda sig av obfuskering av källkoden.
Anknutna misuse cases: Stöld av certifikat.
Villkor: Av1 kräver att angriparen har fysisk tillgång till telefonen.