Android secure offline storage - CC Mobile

Editor's Notes

• #4: Show the small demo app which contains sample code that serves our presentation.
• #7: Applications run in a sandbox. This means: Apps are given a userId and the apps run with that userId. Files stored in the sandbox are accessible only to those userIds. Apps with a different userId can not access those files. REMARKS. Apps signed with the same key or apps with the same sharedUserId (AndroidManifest) can access the same sandbox Rooted phones overcome this limitation
• #8: On a device that’s rooted, everything basically runs as root. As root you gain access to practically everything and all Android limitations that exist no longer apply (isDebuggable, allowBackup, etc…) (IF IM NOT MISTAKEN!)
• #9: Avoid offline storage. In the US for example, Health Insurance regulations state that apps running in airplane mode that still “work” are non-compliant. Avoid external storage. Use ContentProviders to share information between apps instead of saving data in the globally accesible storage… Set allowBackup=false. This will prevent adb backup command from working. set android:saveEnabled=”false” prevents the application from saving instancestate of your activity during screen rotation…This behaviour is not desired. MODE_PRIVATE with files. Store all files in MODE_PRIVATE. This should keep your files private to your app. In case of a rooted device, the above best practices don’t really increase the security of your offline files. Rooted devices are not limited by the android sandbox...
• #10: More explanation on the isDebuggable flag: Can be set in AndroidManifest.xml. Android studio (not sure about eclipse, but probably also) by default sets this flag on true when deploying on a device during development.
• #11: The android backup extractor can be used to convert .ab (android backup) files to .tar files. The resulting .tar file can then simply be unzipped and the contents can be inspected!
• #12: DEMO the adb shell and adb backup tools. adb shell demo: Connect device adb shell run-as be.ordina.offlinestorage (package in AndroidManifest.xml) cd /data/data/be.ordina.offlinestorage (normally, the run-as command already cd’s into this directory) REMARKS: when app isDebuggable is false, this does not work! When running from android studio, the app is debuggable When creating release build, the app is not debuggable isDebuggable property is being set on the application tag in AndroidManifest.xml adb backup demo: Connect device cd ~/AndroidSecurityWorkshop/Androidackups adb backup be.ordina.offlinestorage confirm backup on device abe-all.jar unpack backup.ab backup.tar extract the tar REMARKS: when app allowBackup=false, then the backup pulled from the device will not be readable after running the backup-extractor
• #13: Always use MODE_PRIVATE. This will ensure that files are being saved in the application’s sandbox. Only apps signed with the siging key or apps with the same sharedUserId (AndroidManifest.xml) can access files in the sandbox!
• #15: DEMO the offline stored files. Demo the code: Show the code where file is created. Notice the MODE_PRIVATE. explain that this means the file will not be accessible for other applications (unless device is rooted of course) Backup the application (or re-use an existing backup). Show the file content! Explain that storing files in this way is not secure!
• #17: DEMO the Sqlite database. Open the app Navigate to the SqlLite fragment Insert a user adb backup the application open de database in sqlitebrowser (or command-line with sqlite)
• #18: SqlCipher encrypts the database with AES-256 symmetric encryption It’s a drop-in replacement for sqlite. So all code samples you find on the internet which apply to sqlite can be used for sqlCipher. Only difference is the packagename of the sqlcipher objects (net.sqlcipher.database instead of android.database.sqlite)
• #20: SQLCipher works by hooking into the database system at a certain point where they can intercept blocks of data before they are being written or read. At this stage, they are being encrypted using AES-256. More details about this can be found at the url listed on this slide!
• #21: Demo SQLCipher. First show the code. Comparison with Sqlite code (notice the drop-in replacement. No different api calls, only different package names) Show the usage of a password Perform backup of the application (Or re-use an existing backup) open the encrypted database with sqlite cli (Notice this won’t work!) open the encrypted database with sqlcipher cli (Notice that without PRAGMA key=”<KEY>”;, this won’t work either) open the encrypted database with sqlcipher cli (USE PRAGMA key=”<KEY>”; statement and query the db!) Demo decompiled jar and show password in code: CD into ~/AndroidSecurityWorkshop/AndroidApks Run: adb shell pm path your-package-name. Run: adb pull <.apk-path> Rename base.apk to base.zip Extract the zip Run: java -jar ../abe-all.jar base/classes.dex Open the resulting jar with JD-GUI Open the correct classname, and display the password.
• #22: Now that we have encrypted our local files and local databases, our data has become unreadable. Our problem now shifts to hiding the key. Because when users find the key, our encryption mechanisms are useless…
• #23: DEMO the SqlCipherFragment! DBLoginFragment is being used as login fragment… Login attemts are being sent to the OfflineStorageActivity through a callback. In the callback, the password is retrieved and sent to the SqlCipherFragment, which tries to connect to the database with the password. In case of a wrong password, login fails.
• #27: The compiled c-module becomes a .so module. This module can be disassembled… Show the contents of the .so module in the onlinedisassembler!
• #28: Show the c-code: Explain how the method name should correspond to a method declared in java Show the native Java method Show how to load the library! Show how the method is called and the password is being retrieved from the native library
• #29: As of Android 4.3, The Android KeyStore Api allows a user to store keys in the secure hardware of your CPU! This was previously also possible (as of android 4.0) but required the use of reflection and was limited to RSA keys.
• #32: App can be tampered with when not installed through play store. For example, the app could be decompiled, altered and packaged again and then manually be installed. This should be prevented.
• #33: Unless explicitily configured, apps in production aren’t debuggable. App could be tampered with when you detect it’s running in debuggable mode. This might be an indication that people are trying to reverse engineer your app. Check is being done by bitwise AND’ing the flags on our application with the FLAG_DEBUGGABLE. If the result is 0, then the app is debuggable.
• #34: This may also indicate people are trying to reverse engineer your app. Or repackage it.
• #35: Rooted device allow for applications to bypass the sandboxing model. This implies: Resources are accessible by anyone. Private storage can be inspected regardless of whether the app is debuggable or backupable. (database, preferences, files, etc…) Check is being done by looking for the typical rooted binaries and the su command.