1 Improving secure storge of dt in Android Fysl Boukyou, Jorn Lpon, Brt De Decker nd Vincent Nessens Abstrct Android devices re incresingly used in corporte settings. Although openness nd cost re key fctors to opt for Android, the level of security offered by the pltform is often insufficient for corporte use. This pper presents strtegy for secure credentil nd dt storge in Android. It is supplemented by mechnism tht restricts dt vilbility by subjecting it to contextul conditions. Combining both pproches results in higher dt protection level thn wht the ios pltform offers when device is stolen, nd doesn t require modifictions to the operting system. This work is vlidted through the development of context-wre file mngement system. Keywords Secure storge, Context-wre security, Mobile devices, Android I. INTRODUCTION For yers mobile devices were minly used for personl communiction nd dministrtion, nd leisure. However, the corporte world hs strted to discover their dded vlue. For instnce, sles representtives cn present products to customers on their tblets. If the ltter show further interest, the tblet cn be used to retrieve to retrieve stock informtion nd to close contrcts. Similrly, home cre nurses cn use tblet or smrtphone to consult ptient s dietry prescriptions. In confined setups like retirement communities, nurses my lso be grnted controlled ccess to the door locks of serviced flts. Hence, myrid of sensitive dt nd credentils my be present on these devices. At the sme time, they re prone to theft or loss. While illegitimte dt exposure my induce substntil losses to n enterprise, mny compnies still issue smrtphones or tblets to their employees. Tody, ios is often selected for its built-in security fetures, offering protection ginst mlwre nd theft. This is minly due to strong ppliction vetting nd tight hrd- nd softwre integrtion. For instnce, dt protection is bsed on crypto engine with keys fused into the ppliction processor, thus mking offline ttcks to retrieve dt very hrd (even when the device is jilbroken). Moreover, ios supports multiple vilbility levels for both dt nd credentils (i.e. dt protection clsses). On the other hnd, selecting n Android device lso hs benefits. Brod rnges from different mnufcturers re vilble. A compny my select device, bsed on price nd hrdwre specifictions (e.g. communiction nd storge extension cpbilities, processing power, screen size... ). Moreover, the hrd- F. Boukyou, J. Lpon nd V. Nessens re ffilited with KU Leuven, Deprtment of Computer Science, Ghent Technology Cmpus, Gebroeders De Smetstrt 1, 9000 Ghent, Belgium. Emil ddresses: fysl.boukyou@cs.kuleuven.be, jorn.lpon@cs.kuleuven.be, vincent.nessens@cs.kuleuven.be B. De Decker is ffilited with KU Leuven, Dept. of Computer Science, iminds-distrinet, Celestijnenln 200A, 3001 Heverlee, Belgium. Emil ddress: brt.dedecker@cs.kuleuven.be nd softwre costs re typiclly lower thn ios devices. However, regrding security, Android does not impose hrdwre constrints on device crypto, which mkes sset protection more difficult. Optionlly, the file system is encrypted, using psscode-derived key. However, offline brute force nd dictionry ttcks remin possible. Contribution. This pper presents secure sset storge mechnism for Android-bsed devices. It is supplemented by context-wre module tht further limits sset exposure. Although dopting one mechnism lredy increses the protection level, we show tht pplying both, improves dt nd credentil protection beyond wht ios offers. The secure storge mechnism is bcked by tmperproof module, pluggble into mny current Android devices. We offer protection ginst DoS ttcks by mlwre, nd even online psscode ttcks re mde infesible (s opposed to ios). The context-wre module provides decision support by utomting sset mngement tsks nd only relesing dt to externl pps when contextul preconditions re fulfilled. Note tht no modifictions to the operting system re required. This work is vlidted through the development of context-wre filemngement system. The rest of this pper is structured s follows. Section II presents relted work. Our generl pproch is described in section III. Therefter, the secure sset storge strtegy nd the context-wre sset mngement module re presented in section IV. Section V describes the prototype. Both components re evluted in section VI. Finlly, conclusions re drwn nd future work is suggested in section VII. II. RELATED WORK Mny security-sensitive pplictions, cross mobile pltforms, use custom, poorly designed mechnisms [2], [4]. Yet pltform-provided security cn offer both strong crypto nd integrtion in n orgnistion s MDM infrstructure. In Android, we distinguish three clsses of persistent memory. The internl storge provides ppliction-level ccess to files nd is confined by the Android sndbox. Externl storge on the other hnd, is ccessible to ll pplictions tht hve the corresponding Mnifest permission(s). Mny populr pps use it to keep permnent nd temporry dt nd copies of IPC-obtined dt [6], [12]. Meticulously mnging this informtion cn become n encumbrnce to the user. This ultimtely leds to n incresed exposure of ssets to ineligible pps nd users. Neither internl nor externl storge re encrypted by defult. A third mens is the KeyChin, in which pps cn store nd retrieve their own privte keys. Until Android 4.3, however, the KeyChin hsn t been hrdwrebcked, s opposed to ios nd Windows Phone. Even so, hrdwre support is required, currently offered by few devices.
2 Both ios nd Windows Phone rely on the ARM Trust- Zone rchitecture to provide hrdwre-bcked encryption. This thwrts offline ttcks, but the number of online psscode ttempts is unlimited. Windows Phone never encrypts the externl storge. Similr to Android, BlckBerry offers only softwre-bsed encryption, lso not enbled by defult. Removble storge cn be protected by either using (1) rndomly generted key tht is stored on the device, (2) decryption key derived from user psscode or (3) both. Extensions exist tht provide tmper-resistnt solutions for user uthentiction (screen lock) nd ccess to PKI certifictes. Notbly, Smsung Knox nd Blckberry provide support for militry CAC crds. These extensions llow devices to communicte with n externl smrt crd reder over Bluetooth. Thereby credentils on the crd become vilble for use by pps on the device nd for the estblishment of VPN connections. However, fine-grined secure storge of ppliction ssets is not supported. Different ppers hve proposed using context nd context wreness for sset protection. ConUCON [1] presents context-wre policy specifiction nd enforcement model in Android, for resource usge nd ccess control. However, enforcement is only bsed on OS mechnisms. This leves device ssets vulnerble to ttcks resulting from loss or theft. Sint [9] focuses on providing Android pps with mechnisms to restrict the use of their interfces by other pplictions. It uses contextul informtion in its decision mking. As Sint modifies the OS, it cn provide fr-reching enforcement cpbilities. However, coopertion with pp developers nd modifictions to the Android pltform re required simultneously, which is not very likely to hppen. Also, secure storge is not considered. The pproch by Feth nd Jung [5] much resembles the context-wre component of this work. TintDroid s [3] cpbility is used to nlyse dt flows throughout Android. However, strtegy for secure dt nd credentil storge is not suggested. The uthors rightly rgue tht BYOD in corporte environments is gining significnce. However, solution tht modifies the mobile OS, is less likely to be dopted. Porsch [8] extends OMA DRM, implementing (1) content binding to the mobile device, (2) ppliction restrictions on content usge nd (3) usge constrints. Porsch trusts Android nd the preinstlled system pps. However content-providing prties do not necessrily know which system pps re included by device mnufcturer. Additionlly, since Porsch requires pltform modifictions, content providers must rely on the pltform vendors to include it in Android. III. GENERAL APPROACH AND ARCHITECTURE This pper s gol is improving the security of ssets (i.e., credentils nd dt) mnged by pplictions tht run on the Android pltform, without modifying the operting system. To ddress the Android s shortcomings listed in section II, we tke 2 complementry pproches. First, soft security module utomtes number of security mesures, bsed on Loction Time... PRP PIP/PEP PDP PAP Policy Mngement Policy Decision Context Sensing policies Mobile Device Appliction Logic PEP Policy Enforcement Secure Component Communiction cred. store Assets ppliction dt Tmperproof HW Secure Component Communiction Fig. 1. Overview of the modules for both the soft (grey) nd strong (white) security pproches. the context of the device. Thereby it relieves the user from some sset mngement tsks. The second pproch tkes hrd security mesures, by introducing secure storge mechnism tht relies on tmperproof module (e.g. secure micro SD, SIM or wireless smrt crd). As result, the security of Android-bsed mobile devices is incresed considerbly. The rchitecturl modules re depicted in figure 1. The soft security pproch is uses context-wre policies. Therefore, five min components re dded to the ppliction frmework to hndle these policies. The Policy Mngement serves s the policy dministrtion point (PAP) nd llows the user or ppliction to mnge context-wre policies. The specifiction provided for context-wre policies is pltformindependent nd esily extensible. As result, brod rnge of sensory informtion cn be incorported s context. A context-wre policy events my be triggered when n ppliction is trying to ccess n sset. In tht cse, the Policy Enforcement (PEP) first requests ccess confirmtion from the Policy Decision (PDP). This module will then grnt or deny ccess, depending on the context nd the policies collected from the policy retrievl point (PRP). Doing so, the Context Sensing is used s policy informtion point (PIP): it provides sensory informtion to the policy decision module. The context my chnge, however, which triggers the execution of required opertions (e.g. when the smrtphone leves the premises of the compny, confidentil report is to be ersed from the device). In such cse, the Context Sensing lso functions s Policy Enforcement Point, nd triggers the pproprite ctions, s defined by the policy. The second pproch improves secure sset storge on the mobile device. Appliction-level encryption is provided nd secure cred. store
3 bound to tmperproof hrdwre. This hrdwre ensures tht only predefined pplictions nd users cn retrieve encrypted ssets: key mteril is only exposed to the ppliction fter correct user nd pp uthentiction. The Secure Component Communiction tkes mjor role in enforcing this. It resides prtly on the mobile device nd prtly on the tmperproof hrdwre nd dels with setting up secure, uthenticted communiction chnnel between both. Once this chnnel is estblished, n pp hs ccess to its credentils. They re either directly retrieved or indirectly used in crypto opertions on the tmperproof module. An pp cn only ccess keys tht re ssigned to it. In other words: ccess control is enforced by the tmperproof module. This is further detiled in section IV. The secure credentil store cn hndle symmetric nd symmetric keys, for both confidentility nd uthentiction purposes. Symmetric keys re especilly useful to encrypt nd decrypt stored ssets. We envisge three possible pproches to use symmetric keys. A first is for the tmperproof hrdwre to perform the crypto opertions, thereby never relesing these keys. However, computtionl nd bndwidth constrints of such hrdwre impose n uncceptble dely for cipher opertions tht involve lrge mounts of dt. A second option is to directly retrieve the symmetric keys nd to perform cryptogrphic opertions on the mobile device. Third, we cn store symmetric keys in wrpped form on the mobile device, long with their corresponding ssets. Here, the ppliction hs privte key on the tmperproof hrdwre, with which externl symmetric keys re unwrpped. The second pproch hs dvntges over the third: directly retrieving symmetric keys is typiclly fster thn unwrpping them on the tmperproof module. In ddition, code on this module cn be kept miniml. It cn use stndrd fcilities supported by much of the considered hrdwre, such s secure micro SD crds, contctless smrtcrds, SIM crds or the builtin Secure Element. On the other hnd, the third strtegy llows to certify nd distribute public keys, thereby integrting the device in PKI infrstructure. In the rchitecture presented in this pper, we denote the following ctors: the user U, the mobile device M, the mobile ppliction A, the tmperproof module SE, the ppliction server S, nd the system dministrtor SA. The ltter mnges the security policies, in order to protect personl/corporte informtion. We now list the requirements for the rchitecture presented bove: ) Functionl Requirements: Our solution must be usble on brod rnge of Android devices without requiring ny operting system chnges. Idelly, externl pplictions need not be modified. Lstly, our pproch nd the pps tking dvntge of it, should not cuse ny insurmountble burden to the user (e.g., by requiring long psscode to operte the mobile device). b) Security Requirements: S1 In cse of lost or stolen mobile device, the potentil loss of ssets, mnged by the bove mechnisms, is reduced (even if the ttcker cquires full control of the device). S2 The solution protects ginst mlwre getting hold of the dt. c) Assumptions: We ssume the following bout the operting system: (1) The security controls nd sfegurds re enforced correctly, the sndboxing mechnism in prticulr. (2) The user does not weken the pltform security, for instnce by rooting the device. IV. SECURE ASSET STORAGE In order to further constrin the vilbility of ssets towrds the user nd pplictions on the Android pltform, we present solution bsed on tmperproof hrdwre. Exmples re secure micro SD, SIM, contctless NFC crd, or the builtin secure element. This hrdwre cts s secure credentil store. However, in contrst to stndrd solutions, credentils in this store re vilble only to the ppliction tht instlled or generted it. They cn then be used to encrypt nd decrypt ssets stored on the device or in the cloud. Moreover, depending on the type of credentil, it is possible to generte digitl signtures or uthenticte towrds server without it ever leving the crd. In this solution, three min threts re mitigted in order to increse the security of dt nd credentils hndled by Android pplictions. Evesdropping. Since communiction with the tmperproof hrdwre is not lwys trusted (e.g. when using NFC), the crd exposes (certified) public key tht is used to set up secure communiction chnnel. Unuthorised ccess. Second, unuthorised pplictions cnnot ccess credentils on the tmperproof hrdwre. Simply put, both the ppliction nd the user must uthenticte towrds the crd to unlock the pp-specific credentils. The user uthentictes with personl psscode (e.g. PIN) nd the ppliction proves knowledge of n ppliction secret obtined during n initil piring phse. Denil of Service. To prevent brute-force ttcks on the psscode, the number of llowed ttempts is limited. However, mlicious pplictions could perform DoS ttck on the crd by repetedly lunching ttempts. Therefore, the crd first verifies the ppliction secret nd only then, n uthentiction ttempt is counted. A. Protocols We now present detils on the most importnt protocols used in this solution. 1) Piring.: The piring protocol llows n ppliction to enroll to the tmperproof module. In other words, secure credentil store is set up on the module, specificlly ssocited with tht ppliction. The result is the ppliction obtining the public key of the tmperproof module, in both prties shring the sme pp-specific secret (K SE,A ) nd in number of credentils being initilised. A simple solution is to use strong PUK code entered by the user prior to the piring phse, expressing his consent to proceed. In some cses, entering this code my be cumbersome or uncceptble. In such cse, to pprove n ppliction, trusted third prty could medite between the new ppliction
4 nd the tmperproof hrdwre, or in more dvnced setting, white-box cryptogrphy could be used to weve symmetric key into the ppliction code. 2) Access to ssets.: Once the ppliction hs been pired with the tmperproof hrdwre, the ppliction cn, with the user s consent, ccess its secure credentil store. For this purpose, secure chnnel is set up using protocol 1. Here, symmetric session key is estblished using the public key of the tmperproof hrdwre (1). Next, the ppliction requests the user s psscode nd forwrds it together with the ppliction secret K SE,A to the tmperproof hrdwre(3-4). Then, the tmperproof hrdwre verifies the ppliction secret (5), followed by verifiction of the user s psscode (6). Protocol 1 (setupsecurechnnel): (1) SE A : K sess uthkeyagreementôsk SE ;pk SE Õ % further communiction is encrypted with key K sess (2) SE A : N SE (3) U A : psscode enterpsscodeôõ (4) SE A : hôk SE,A N SE 1Õ,psscode (5) SE : if Ônot verify A ÔK SE,A ÕÕ bort (6) SE : if Ônot verify U ÔpsscodeÕÕ bort When successful, the tmperproof hrdwre grnts ccess to the ppliction, which cn now ccess its secure credentil store, kept on the crd. The credentils in this store cn then be used to increse the security of the Android pp in severl wys. For instnce, the ppliction cn retrieve symmetric key in order to encrypt nd decrypt its sensitive dt. This llows exclusive ccess to the externl storge. It lso lso prevents dt compromistion following device loss or theft. Additionlly, the store cn lso mnge credentils tht re used for user uthentiction or digitl signtures. B. Context-wre sset mngement The min rtionle behind context-wre sset mngement, is to selectively constrin the vilbility or the presence of ssets on the mobile device. Note tht the context-wre component serves to provide soft, user-ssisting security. This implies tht eligible users re not considered potentil dversries: proper uthentiction nd secure storge remin must. The secure storge mechnism, described in section IV, provides direct user uthentiction to tmperproof module by mens of psscode. Policies govern how ssets re protected. The policy dministrtor specifies which ctions hve to or my tke plce nd under which contextul conditions. Vrious metrics qulify s context: time, loction, ppliction white- or blcklists, the presence of nerby wireless networks, etc. The policy dministrtor cn differ, depending on the system setup: device user, corporte dministrtor or third prty service provider. Ech locl sset is ccompnied by sticky policy. The policies described here, pertin to both ccess control nd device self-mngement. Prominent lnguges in these domins re XACML [7] nd Ponder2 [11], respectively. To further illustrte the intended pproch, two exmple policies re shown below. The first policy constrins the vilbility of door credentils on home nurse s tblet. If the device is wy from the residence of ptient X or if door credentil Y hs not been used for over one hour, then it is removed. If loction offsite "Residence of ptient X" OR unused > 1hr Then Remove "DoorCredentil Y" In the second policy, ccess to contrct on sles representtive s tblet, is restricted. The contrcting pp is only grnted red nd write ccess during working hours. If 8:00 <= time <= 18:00 Then App.Contrct hs R/W-ccess to "Contrct Z" The context-wre module cn dynmiclly grnt to files upon n pp s request, in ccordnce with contextul policies. Furthermore, it cn utomticlly downlod nd remove ssets. Lstly, controlled ccess to code invoction cn lso be provided. Policy enforcement implementtion is pltform-specific nd is therefore described long with the prototype in section V. V. PROTOTYPE: CONTEXT-AWARE FILE MANAGEMENT The proof-of-concept implements corporte file mngement system, consisting of three prts: mobile component on smrtphone, corporte file server nd mngement component. The user cn synchronise ssets with the server during n uthenticted session. The mobile component stores ssets securely nd provides controlled provisioning nd semiutomted tsks to constrin their vilbility. A. File Server The file server is considered prt of lredy existing infrstructure. Therefore, it is not modified for this prototype. Stte of the rt file mngement solutions offer wide rnge of functionlities nd protocols. However, to vlidte the interoperbility of our pproch, we use legcy FTP server, with mutul uthentiction over TLS lyer. B. Mngement Component Although different configurtions re conceivble, we ssume policy dministrtion in corporte setup. The MDM server resides on the sme mchine s the file server. In more complex deployments, these cn be hosted seprtely. The mobile component fulfills two mjor tsks: creting nd modifying policies nd pushing new nd updted ones to the file server nd the ffected mobile devices. Following the cretion or the ltertion of policy, ech ffected mobile device is notified. Consequently, its mobile component connects to the file server nd retrieves the policies tht hve chnged. Notifictions re typiclly pushed to relieve mobile devices from listening to incoming connections. The push service we use, is Google Cloud Messging.
5 C. Mobile Component The mobile component is implemented s dedicted support pp tht provides (1) secure storge for itself nd other pps (2) context-wre constrinment of sset vilbility. 1) Contextul Frmework: The contextul frmework is built on top of generic codebse, which cn be extended to contin vrious types of context. The internl policy representtion is hierrchicl nd event-driven. Monitoring chnge events is necessry, s policy decisions do not only occur in reltion to n sset request, but lso s result of context chnge. This proof of concept incorportes the following contextul metrics: loction, bsolute nd recurring time intervls nd ppliction blck- nd whitelists. Multiple implementtions of the sme contextul vrible re supported. For instnce, time cn be retrieved from the mobile device or through trusted time server, for more criticl uses. 2) Asset Synchronistion nd Secure Storge: The tmperproof module is Giesecke & Devrient Mobile Security Crd, with Jv Crd 2.2.2, offering tmperproof storge of key mteril. It houses symmetric encryption key for ech pp tht hs previously completed the piring phse (see section IV-A). The ssets belonging to this pp, re stored encrypted, using this key. Policies re not treted s confidentil. Dt uthentiction on the other hnd, concerns both files nd policies. It is chieved on two levels. The integrity while in trnsit between the server nd the mobile, is provided by the TLS lyer. Integrity for file nd policy storge is provided by using uthenticted encryption. Mutul uthentiction between the file server nd the mobile component, implies both hving privte key nd the other prty s public key. The privte key for client uthentiction is stored on nd confined to the Mobile Security Crd. The protocol to estblish secure chnnel between pp nd the Mobile Security Crd, is Elliptic Curve Diffie-Hellmn, with 192-bit key. A performnce test of 100 runs shows tht the verge time to set up the secure chnnel nd retrieve the pp encryption key is 1667ms. Note tht this step only tkes plce when the ppliction is strted: the key remins vilble s long s the pp is running in the fore- or bckground. A usbility-security trdeoff exists in how frequently user is sked to enter his PIN. For symmetric file encryption, 128-bit AES in CBC mode is used. This corresponds with the configurtion of dm-crypt, the Linux module providing Android s file system encryption. During performnce test of 100 runs, files of 10KB, 100KB, 500KB, 1MB, 5MB nd 10MB were copied from the internl pp storge to SD crd nd vice vers. The I/O opertion towrds the SD crd is decryption, while the strem to the internl pp memory is encrypted. Tble I compres the men vlues of four setups: unencrypted I/O, Android s file system encryption nd two versions of the proposed secure storge mechnism: Jv-bsed (Bouncy Cstle v1.47) nd C-bsed one (PolrSSL v1.3.2), which is ccessed through the Jv Ntive Interfce. The tests were run on Smsung Glxy Tb 2, with Android 4.1.2. Note tht dm-crypt is nerly s fst s hving no encryption t ll. The Jv-bsed implementtion, on the other hnd, is prohibitively slow: between 7 nd 27 times. Therefore we decided to evlute the speed of ntive implementtion. A performnce gin cn be clerly observed. For 10MB, the C implementtion with 20KB buffer encrypts nd decrypts only 1.5 nd 3 times slower thn dm-crypt, which opertes t the kernel-level. Test results for smller nd lrger buffer sizes, suggest tht using smller buffer, speeds up the cipher opertions for smller files (less thn 500KB). The C- bsed implementtion cn be further optimised by not only executing the cipher opertions ntively, but the I/O s well. This prtly decreses the overhed incurred by the use of JNI. Additionlly, the AES-CBC decryption cn be prllelised. 3) Policy Decision nd Enforcement: Files re mde ccessible to externl pps using Content Provider, stndrdised Android building block, which is extended with policy decision nd enforcement logic nd with the contextul frmework (see section V-C1). Content Providers offer dynmiclly ssignble nd revocble permissions nd cn essentilly supply ny structured dt type, including files. The cretion nd updting of informtion is lso supported. To denote the type nd id of the requested entity, n externl pp typiclly constructs nd sends n Intent with locl URI. This llows fine-grined control over relesed informtion. Note tht nothing prevents receiving pps from sving copy of cquired files. Determining which pps to trust, is seen s prt of the dministrtor s tsk. Consequently, this trust preference is specified in n pp white- or blcklist, which is prt of the sticky policy. The resulting dvntge of this pproch is tht neither Android nor the externl pp need modifiction: secure storge nd policy enforcement re hndled trnsprently by the mobile component. Automtic downlod, synchronistion nd deletion tsks re executed by n Android Service, which is lso context-driven. Such tsks cn tke plce in two different mnners: reltive to user s workflow (e.g. deleting credentil one hour fter lst use), or completely utomted (e.g. periodic clenup of ssets not used for more thn given time spn). More dvnced functionlity cn be relised if we llow modifictions to externl pps. ContentProvider s API provides cll method for the invoction of custom methods. Similrly, RPC interfces cn be supplied by Android Service implementtions. Externl pplictions cn bind to it nd invoke its exposed set of methods, with the Service enforcing controlled ccess. This pproch llows support for credentilbsed opertions without relesing the secrets (e.g. signing, proof genertion). VI. EVALUATION This section evlutes the dded vlue of the contextwre mngement module (CAM) nd the secure storge module (SST). We minly focus on the dded security tht CAM nd SST offer compred to solely relying on support by existing mobile pltforms. Moreover, we show tht both components ese the burden on users, contributing to their doption. Tble II summrises the min benefits. For the security nlysis, we ssume tht the sndboxing mechnism works correctly on both Android nd ios. More specificlly: mlwre pp cnnot stel dt tht is stored nd relesed in the scope of corporte pp. Moreover, we ssume
6 TABLE I. SECURE STORAGE PERFORMANCE: COMPARATIVE TEST RESULTS (MILLISECONDS) TABLE II. File size 10KB 100KB 500KB 1MB 5MB 10MB NO ENCRYPTION Outgoing strem 1.17 5.06 24.14 48.56 239.83 638.28 Incoming strem 2.13 17.73 86.23 171.53 871.87 1784.20 ANDROID FILE SYSTEM ENCRYPTION (DM-CRYPT) Outgoing encryption 1.18 5.58 23.95 49.78 250.13 903.48 Incoming decryption 2.61 17.69 95.65 181.22 937.48 1962.45 JAVA-BASED AES (BOUNCY CASTLE) Outgoing encryption 19.46 140.98 644.34 1309.11 6940.81 13801.72 Incoming decryption 18.78 147.93 688.69 1438.58 7222.27 14607.33 C-BASED AES THROUGH JNI (1K BUFFER) Outgoing encryption 3.84 37.90 194.22 402.09 1977.56 4138.84 Incoming decryption 6.93 55.89 272.75 539.62 2678.56 5333.50 C-BASED AES THROUGH JNI (20K BUFFER) Outgoing encryption 15.50 45.95 143.60 277.94 1384.46 2799.56 Incoming decryption 15.32 45.98 158.44 308.13 1491.25 2957.24 COMPARISON OF SECURITY AND USABILITY PROPERTIES OF ANDROID, IOS, THE CONTEXT-AWARE MANAGEMENT MODULE (CAM), AND THE SECURE STORAGE MODULE (SST). Android ios CAM SST SST CAM Security -Fctors psscode psscode, device n/ psscode, TM psscode, TM -Attck brriers PBKDF2 PBKDF2 ( t) n/ ttempt limit ttempt limit -Locl sset mgmt pp/user pp/user semi-uto pp/user semi-uto -Dt revoction wipe wipe n/ implicit implicit Prerequisites Internet Internet none none Usbility -Psscode complexity high medium high low low -Hrdwre reqs? no yes: on bord no yes yes -Context mgmt grn. none corse fine none fine mlwre cnnot stel entered psswords. Similr ssumptions re tken in [10], nd re resonble if user does not root/jilbrek his device. However, powerful ttcker cn ccess the (encrypted) file system on stolen devices, nd hs knowledge nd softwre tools to perform pssword ttcks. The Android pltform uses file system encryption system bsed on dm-crypt. The key for decryption is derived from psscode, nd PBKDF2 is used s the key derivtion function. An ttcker cn fter obtining root ccess perform psscode ttempts offline, nd thereby rely on dditionl processing power. ios file decryption keys re derived from psscode nd hrdwre-bound secret (i.e. the device UID), which prevents offline psscode ttcks. Although the user or mobile device mngement (MDM) system cn configure psscode ttempt limit for wipe to tke plce, this security mesure cn be circumvented if the device is first jilbroken. Hence, the key derivtion function (i.e. PBKDF2) together with the UID tht cn not be extrcted from the device only slow down brute force psscode ttcks (i.e. t in tble II). SST surpsses the security offered by both pltforms. It is bsed on psscode nd tmperproof module (TM). Hence, psscode ttempt limit cn be enforced, even if the device is rooted by n ttcker. After limited number of unsuccessful ttempts, she cn only decrypt files nd credentils by ttcking the cryptosystem. Although CAM does not impede file decryption ttcks, policies restrict the dt nd credentils tht re stored on the device. This implies tht less dt cn be recovered if n ttcker succeeds to stel psscode or decryption key. Further note tht n Internet connection is needed to wipe n Android or ios device, nd tht wipe only removes mster secret. This mens tht n ttcker should ttck the crypto system fter successful wipe is performed. Our system implicitly blocks ccess to decryption keys fter number of psscode ttempts (i.e. implicit wiping). However, denil-ofservice ttcks by mlwre re very hrd, s psscode ttempts cn only be performed fter the TM hs verified tht the correct ppliction secret is in use. The ltter is stored in the context of the corporte pp nd, hence, not ccessible by mlwre (ssuming tht the sndboxing principle works correctly). An ttcker tht hs (temporry) physicl control
7 over the device cn perform denil-of-service ttck by ttempting multiple psscodes fter strting the corporte pp. However, n unwipe procedure cn be implemented by the compny. If so, blocked TM cn be rectivted using mster secret kept in secure storge t the compny. Although SST nd CAM offer incresed security to corporte ssets, they do not impose high usbility brriers. Ech of them even decreses the burden on users. First, psscode complexity is reduced with SST due to the ttempt limit. Second, fine-grined policies llow to utomte ctions relted to locl dt storge nd removl, nd hence, decrese the burden on users. ios only supports corse-grined dt protection policies (i.e, through the Dt Protection clsses). Wheres the compny cn define context-wre policies, the dt protection clsses re selected by the ppliction developer which decreses dministrtive flexibility. Finlly, lthough dditionl hrdwre is required to support SST, multiple lterntives re possible. A secure micro SD cn be plugged into the mobile device. If so, no dditionl hrdwre must be crried long, but the mobile must hve empty micro SD slot. An lterntive is to implement the functionlity on device tht is crried seprtely. Although such device should hve short rnge wireless communiction cpbilities (like NFC or Bluetooth), it should not necessrily be tmperproof, ssuming tht steling it, is hrd. VII. CONCLUSIONS AND FUTURE WORK This pper hs presented secure sset storge strtegy for the Android pltform. It is bcked by tmperproof module tht verifies the eligibility of the user s well s the pp before key mteril cn be ccessed. This pproch is supplemented by context-wre, user-ssisting module. It provides utomted decision support by enforcing remotely mnged policies to constrin sset vilbility. We hve shown tht dopting either of the two pproches, lredy significntly improves Android s sset protection level. Applying both strtegies results in setup tht performs better thn ios w.r.t. credentil nd dt protection. Importnt dvntges re the interoperbility with existing pps nd the bsence of ny required chnges to the operting system. An interesting extension to this work, is to integrte the tmperproof module in the Android KeyChin, so tht APIlevel support is offered to ny ppliction using Android s stndrd credentil storge. Additionlly, this would llow the integrtion of our secure storge strtegy into the Device Administrtion (i.e. MDM) API. A limittion to this pproch, however, is tht the KeyChin hs only been publicly vilble since Android 4.0. [3] Willim Enck, Peter Gilbert, Byung-Gon Chun, Lndon P. Cox, Jeyeon Jung, Ptrick McDniel, nd Anmol N. Sheth. Tintdroid: n informtion-flow trcking system for reltime privcy monitoring on smrtphones. In Proceedings of the 9th USENIX conference on Operting systems design nd implementtion, OSDI 10, pges 1 6, Berkeley, CA, USA, 2010. USENIX Assocition. [4] Ssh Fhl, Mrin Hrbch, Mrten Oltrogge, Thoms Muders, nd Mtthew Smith. Hey, you, get off of my clipbord. In Proceedings of the 17th Interntionl Conference on Finncil Cryptogrphy nd Dt Security, Lecture Notes in Computer Science, Okinw, April 2013. Springer. [5] Denis Feth nd Christin Jung. Context-wre, dt-driven policy enforcement for smrt mobile devices in business environments. In AndresU. Schmidt, Giovnni Russello, Ionnis Krontiris, nd Shiguo Lin, editors, Security nd Privcy in Mobile Informtion nd Communiction Systems, volume 107 of Lecture Notes of the Institute for Computer Sciences, Socil Informtics nd Telecommunictions Engineering, pges 69 80. Springer Berlin Heidelberg, 2012. [6] Michel J. My nd Krthikeyn Bhrgvn. Towrds unified uthoriztion for ndroid. In Engineering Secure Softwre nd Systems, pges 42 57. Springer, 2013. [7] OASIS Foundtion. extensible Access Control Mrkup Lnguge Specifiction (Version 3), Jnury 2013. [8] Mchigr Ongtng, Kevin Butler, nd Ptrick McDniel. Porsch: policy oriented secure content hndling in ndroid. In Proceedings of the 26th Annul Computer Security Applictions Conference, ACSAC 10, pges 221 230, New York, NY, USA, 2010. ACM. [9] Mchigr Ongtng, Stephen McLughlin, Willim Enck, nd Ptrick McDniel. Semnticlly rich ppliction-centric security in ndroid. Security nd Communiction Networks, 5(6):658 673, 2012. [10] Peter Teufl, Thoms Zefferer, nd Christof Stromberger. Mobile device encryption systems. In Proceedings of the 28th IFIP TC-11 SEC 2013 Interntionl Informtion Security nd Privcy Conference, pge 15, Aucklnd, New Zelnd, July 2013. [11] K. Twidle, E. Lupu, N. Duly, nd M. Slomn. Ponder2 - policy environment for utonomous pervsive systems. In Policies for Distributed Systems nd Networks, 2008. POLICY 2008. IEEE Workshop on, pges 245 246, 2008. [12] Xueto Wei, Lorenzo Gomez, Iulin Nemtiu, nd Michlis Floutsos. Mlicious ndroid pplictions in the enterprise: Wht do they do nd how do we fix it? In Dt Engineering Workshops (ICDEW), 2012 IEEE 28th Interntionl Conference on, pges 251 254, 2012. REFERENCES [1] Gungdong Bi, Ling Gu, To Feng, Yo Guo, nd Xingqun Chen. Context-wre usge control for ndroid. In Sushil Jjodi nd Jinying Zhou, editors, Security nd Privcy in Communiction Networks, volume 50 of LNICST, pges 326 343. Springer Berlin Heidelberg, 2010. [2] Andrey Belenko nd Dmitry Sklyrov. secure pssword mngers nd militry-grde encryption on smrtphones: Oh, relly? Technicl report, Elcomsoft, Amsterdm, Mrch 2012.