Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (14)
Similar to Android secure offline storage - CC Mobile
Similar to Android secure offline storage - CC Mobile (20)
Recently uploaded
Recently uploaded (6)
Android secure offline storage - CC Mobile
- 1. Secure offline storage Steve De Zitter
- 2. Secure offline storage Agenda ▪ Sample-app ▪ Android offline storage possibilities ▪ Android Sandbox model ▪ Some Best practices when using offline storage ▪ Performing back-up on demo app ▪ Secure file storage ▪ Secure database storage ▪ Tamper detection
- 3. SAMPLE-APP
- 4. Sample application ▪ Sample application - https://github.com/SteveDZ/OfflineStorage.git
- 5. Android offline storage possibilities ▪ Several ways to store data in Android - SharedPreferences - Files (Internal and external storage) - SqlLite - These are not secure! ▪ Back-up ▪ Rooted devices
- 6. Android sandbox model MyApp, UID: 12345 MyOtherApp, UID: 9876 Preferences Preferences Internal storage Internal storage databases Databases
- 7. Android sandbox model (Rooted device) MyApp, UID: 12345 MyOtherApp, UID: 9876 Preferences Preferences Internal storage Internal storage databases Databases
- 8. Offline storage Best Practices ▪ Avoid it (if possible) ▪ Avoid external storage (outside of sandbox, globally readable) ▪ set android:allowBackup=”false” ▪ set android:saveEnabled=”false” ▪ MODE_PRIVATE with files
- 9. ADB shell ▪ When app is debuggable (default in DEV) or device is rooted - adb shell - run-as be.ordina.offlinestorage (Not necessary on rooted device) - cd /data/data/be.ordina.offlinestorage/ ▪ shared_prefs ▪ db ▪ files
- 10. Backup extractor -> https://github.com/nelenkov/android-backup-extractor ▪ Command line: adb backup be.ordina.offlinestorage ▪ Unlock the device and confirm backup operation ▪ Command line: java -jar abe-all.jar unpack backup.ab backup.tar ▪ Unzip the tar and check it’s contents (including the prefs file) Backing up application
- 11. DEMO
- 12. Files on internal storage ▪ Internal storage mode MODE_PRIVATE (MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE deprecated) ▪ Files saved on internal storage in MODE_PRIVATE are private to the application. ▪ FILE CONTENT IS NOT SECURE! -> BY BACKING-UP these files are also perfectly readable
- 13. Safe file storage ▪ Encryption of files! ▪ See fragment.EncryptedInternalStorageFragment class for implementation details
- 14. CODE + DEMO
- 15. SQLite ▪ Relational database ▪ Saved on internal storage automatically ▪ can be pulled or backed up with adb ▪ sqlitebrowser: (http://sqlitebrowser.org) ▪ SQLite3 command line interface: https://www.sqlite.org/download.html ▪ NOT SAFE
- 16. DEMO
- 17. SQLCipher ▪ Symmetrically encrypted Sqlite database (AES-256) ▪ Drop-in replacement for regular sqlite ▪ SQLCipher for Android: https://www.zetetic.net/sqlcipher/sqlcipher-for-android/ ▪ Installation instructions IntelliJ: https://discuss.zetetic.net/t/android-studio-integration/65
- 18. SQLCipher Command Line Interface ▪ Download SqlCipher command line interface: https://github.com/sqlcipher/sqlcipher ▪ Build sqlcipher command line tool: http://stackoverflow.com/questions/25132477/how-to- decrypt-an-encrypted-sqlcipher-database-file-on-command-line ▪ Run sqlcipher command line interface:
- 19. SQLCipher design How does SQLCipher actually work? ▪ https://www.zetetic.net/sqlcipher/design/
- 20. CODE + DEMO
- 21. Hiding the key ▪ Ask each time ▪ In the code ▪ In de NDK ▪ Android KeyStore (apple KeyChain equivalent) ▪ Server-side
- 22. Ask each time ▪ At Startup, always ask the users password. ▪ This password can be used to decrypt the database.
- 23. In the code ▪ Generate a device specific key (See fragment.DeviceSpecificKeyFragment.java) ▪ As we saw earlier, this can be reverse engineered and used to recreate the device specific key (Not very safe…)
- 24. In the NDK ▪ Install the NDK: https://developer.android.com/tools/sdk/ndk/index.html ▪ Documentation: <ndk>/docs/Programmers_Guide/html/index.html - Samples/hello-jni: Example Java Native Interface - Building/ndk-build: How to build your native c files - Building/Android.mk: Android .mk file describing c-library
- 25. In the NDK ▪ Android studio - Create folder app/jni ▪ Create Android.mk, Application.mk, <your-module>.c - Create folder src/main/jniLibs - Compile c module: ▪ cd in <project-path>/app directory ▪ <ndk-path>/ndk-build
- 26. Decompile jar with .so modules ▪ http://reverseengineering.stackexchange.com/questions/4624/how-do-i-reverse- engineer-so-files-found-in-android-apks ▪ online disassembler: http://onlinedisassembler.com/odaweb/
- 27. CODE + DEMO
- 28. Android KeyStore (as of 4.3) ▪ Android hardware backed KeyStore ▪ Standard Java JCA (Java Cryptography Architecture) api but ‘AndroidKeyStore’ as provider ▪ http://developer.android.com/training/articles/keystore.html ▪ http://nelenkov.blogspot.be/2013/08/credential-storage-enhancements-android-43.html
- 29. Server side decryption ▪ Communication over HTTPS (of course…) ▪ Send bytes or Strings that need to be decrypted to server ▪ Server decrypts and sends unencrypted data back. Advantages: ▪ Key information doesn’t leave the server (more secure) Disadvantages: ▪ Application needs to be connected to internet to function correctly. ▪ More server round-trips to perform the encryption and decryption of data.
- 30. Tamper Detection ▪ Check if app is installed through play store ▪ Check if app is debuggable ▪ Check if app is running on emulator ▪ Check if device is rooted
- 31. Installed through play store
- 32. Check if app is debuggable
- 33. Check if your app is running on an emulator
- 34. Check if device is rooted ▪ Check for typical rooted binaries - /sbin/, /system/bin/, /system/xbin/, /data/local/xbin/, /data/local/bin/, /system/sd/xbin/, /system/bin/failsafe/, /data/local/, /system/app/ ▪ Check for rooted run command: su ▪ @See RootDetectionUtils.java in Sample project
- 35. Sources ▪ Bulletproof Android. Practical advice for building secure apps (ISBN: 978-0-13-399332-5) ▪ https://www.parleys.com/tutorial/android-application-security ▪ http://nelenkov.blogspot.be/2013/08/credential-storage-enhancements-android-43.html ▪ http://developer.android.com/training/articles/keystore.html ▪ http://nelenkov.blogspot.be/
- 36. QUESTIONS???
Editor's Notes
- Show the small demo app which contains sample code that serves our presentation.
- 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
- 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!)
- 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...
- 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.
- 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!
- 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
- 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!
- 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!
- 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)
- 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)
- 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!
- 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.
- 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…
- 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.
- The compiled c-module becomes a .so module. This module can be disassembled… Show the contents of the .so module in the onlinedisassembler!
- 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
- 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.
- 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.
- 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.
- This may also indicate people are trying to reverse engineer your app. Or repackage it.
- 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.