Securing User Data with SQLCipher

Copyright © 2012 CommonsWare, LLC

Securing User Data with SQLCipher

AnDevCon IV


Workshop Overview

● Who Is At Risk?● Offense and Defense● SQLCipher Integration● SQLCipher: Hands On!● Encrypting SharedPreferences & Files● Passphrases● Encrypted Communications


Who Is At Risk?

● The Clumsy– Leaving phones lie around– Some percentage get personal data lifted

● The Traveler– Spear-fishing attack on a specific business– Corporate espionage or just garden-variety theft


Who Is At Risk?

● The Freedom Fighter– Devices used for communication, coordination– Devices confiscated upon arrest

● The Terrorist– Devices used for communication, coordination– Devices confiscated upon arrest


Who Is At Risk?

● The Citizen (of Repressive Regimes)– Arrests ranging from freedom of expression

(protest rallies) to “just because” (race, religion, etc.)

● The User– May fall into any of the above categories– Even for apps not normally thought of as

requiring such security


Who Is At Risk?

● The Developer– Press reports of “plaintext” stuff on internal

storage– Negative publicity leads to negative reputation


Offense and Defense

● Defense: Lock Screen Security– Swipe: um, not really– Face: well, better than nothing– PIN: we're getting somewhere– Password: secure!

● Right?


Offense and Defense

● Offense: Exploits– Example: USB Debugging

● Create app that dismisses keyguard● Run via USB cable and adb shell am● Net: bypass lock screen regardless of security

settings● (according to Google: not a bug)


Offense and Defense

● Defense: Internal Storage– Read-write for app, deny-all for everyone else– User has no direct access via USB cable– Net: only way to get at the data is via the app!

● Right?


Offense and Defense

● Offense: Rooting– Most devices can be rooted– Can run apps as root, with access to all parts of

internal storage– Run a file manager, copy off whatever is desired

● Or write an app that bulk-copies entire internal storage for later analysis


Offense and Defense

● Defense: Full-Disk Encryption– Entire internal storage bulk encrypted– Reboot locks down device, requiring manual

entry of password– Many root attacks require a reboot– Net: only way to get at data is via encryption

password!● Right?


Offense and Defense

● Offense: Exploits– Ineffective against many temporary root attacks– Weak full-disk encryption passwords

● Same as lock screen for most devices● Can be brute-forced

– Assumes users know of, apply full-disk encryption

● Not offered during initial setup


Offense and Defense

● Defense: Cloud– Keep data off the device– Many Web sites and apps have decent defenses

against brute-forcing attacks– So long as user is willing to enter password every

time, the data is secure!● Right?


Offense and Defense

xkcd comics reproduced under CC license from Randall Munroe, despite Hat Guy's best efforts.


General Strategy

● Use Base Defenses– Lockscreen– Internal Storage– Full-Disk Encryption


General Strategy

● Per-App Crypto– More flexible authentication models

● Help to mitigate “always entering password” problem

– Containers with better brute-force resistance– Storage Models

● Database● SharedPreferences● General files


Introducing SQLCipher

● SQLCipher– Modified version of SQLite– AES-256 encryption by default, of all data– Relatively low overhead– Cross-platform– BSD license



● SQLCipher Security– Customizable encryption algorithm

● Based on OpenSSL libcrypto

– Individual pages encrypted, with own initialization vector

– Message authentication code (MAC) per page, to detect tampering

– Hashed passphrase (PBKDF2) for keyXkcd comics reproduced under CC license from Randall Munroe. Hat guy is not impressed.



● SQLCipher for Android– NDK-compiled binaries– Drop-in replacement classes for Android's

SQLite classes● SQLiteDatabase● SQLiteOpenHelper● Etc.



● SQLCipher for Android Limitations– Adds ~3MB to APK size per CPU architecture– x86 binaries not available for public download

right now● Must build them yourself, versus downloading ARM

binaries● Available for this workshop!



● SQLCipher and Third Party Code– Typically should work for open source via fork

● Replace their references to SQLite classes the same way you would replace your references

● Find way to pass in passphrase● Either package as separate JAR or blend their source

into your project as needed● Examples: ORMLite, SQLiteAssetHelper


Integrating SQLCipher

● Step #1: Add to Project– Download ZIP file from:

https://github.com/sqlcipher/android-database-sqlcipher

– Copy ZIP's assets/ into project's assets/– Copy ZIP's libs/ into project's libs/



● Step #2: Replace Import Statements– Eclipse

● Delete all android.database.* and android.database.sqlite.* imports

● Use Ctrl-Shift-O and choose the net.sqlcipher equivalents



● Step #2: Replace Import Statements– Outside of Eclipse

● Replace all occurrences of android.database with net.sqlcipher, revert back as needed

● Replace all occurrences of android.database.sqlite with net.sqlcipher.database



● Step #3: Supply Passphrases– SQLiteDatabase openOrCreateDatabase(),

etc.– SQLiteOpenHelper getReadableDatabase()

and getWritableDatabase()– Collect passphrase from user via your own UI



● Step #4: Testing– Tests should work when starting with a clean

install● No existing unencrypted database

● Step #5: Beer!– Hooray, beer!



● Upgrading to Encryption– Open unencrypted original– Create and ATTACH new encrypted database– sqlcipher_export()– Save schema version from old database– DETACH and close databases– Open encrypted database and set schema

version


SQLCipher: Hands On!

● Option #1: Tutorial– Materials on USB thumb drive– Step-by-step instructions (PDF)– Live walkthrough of all steps

● Designed to supplement instructions

– Goal: add SQLCipher to an existing Android app, including handling the database upgrade



● Option #2: Upgrade Your Own App– Use instructions, walkthrough as guide for applying

similar changes to your own code● Warning: tutorial probably smaller than your app!

● Support– Ask questions of presenter, who will be up front or

wandering around aimlessly between walkthrough sections



● Option #3: Return at 11:25am for more exciting slides!– ...though we will all miss you...



● Step #1: Getting Your Starting Point● Step #2: Adding SQLCipher for Android● Step #3: Adding a New Launcher Activity● Step #4: Collect Passphrase For New Encryption● Step #5: Create or Encrypt the Database● Step #6: Collect Passphrase For Decryption


Encrypted SharedPreferences

● How They Are Normally Stored– Unencrypted XML files– Internal storage in shared_prefs/ directory

● Peer to your databases/, files/ directories● Precise root path may vary, especially on Android 4.2

with multiple accounts



● Introducing CWSharedPreferences– Strategy-based pluggable storage model

● SQLite● SQLCipher● Others as you wish via interfaces

– Implements SharedPreferences● Manual preference-using code requires no changes

once you have your SharedPreferences object



● Creating a SQLCipherStrategy– Supply name of preferences, passphrase, LoadPolicy

● LoadPolicy.SYNC: loads on main application thread● LoadPolicy.ASYNC_BLOCK: loads in background thread,

blocks if you try using them before loaded● LoadPolicy.ASYNC_EXCEPTION: loads in background

thread, raises exception if you try using them before loaded

● Test Case Walkthrough



● Limitation: No PreferenceActivity– Hard-wired to use stock SharedPreferences

● Alternative: Encrypt at GUI Level– Custom Preference classes with encryption,

decryption logic, also available for use outside of preference UI

– Requires more manual fussing with encryption– Encrypts values, perhaps not keys


Encrypted Files

● Option #1: javax.crypto– Standard solution for Java for years– Plenty of online recipes– Search StackOverflow for Android-specific

idiosyncrasies


Encrypted Files

● Option #2: SpongyCastle– Refactored version of BouncyCastle, to avoid VM

collisions● Android's javax.crypto based on BouncyCastle, but

with somewhat hacked version

– Fairly popular, probably less likely to run into Android-specific headaches


Encrypted Files

● Future Option: IOCipher– Uses SQLCipher as a backing store for virtual

filesystem● You work with drop-in replacement File class that

stores, reads “files” as BLOBs from database

– Benefits: less work, benefits of SQLCipher container

– Pre-alpha


Passphrases

● Passphrase Entry Pain– Users do not like typing long passwords– Result = weaker quality– Option: “diceware”

● Choose ~5 words from stock list● Can offer scrolling lists, auto-complete to help speed

data entry● Downside: more annoying for accessibility


Passphrases

xkcd comics reproduced under CC license from Randall Munroe, even though Hat Guy owns a $5 wrench


Passphrases

xkcd comics reproduced under CC license from Randall Munroe, but BYO talking horse


Passphrases

● Multi-Factor Authentication– Passphrase generated in code from user-

supplied pieces– Organization options

● Simple concatenation● Concatenation with factor prefix, un-typeable divider

characters


Passphrases

● Multi-Factor Authentication Objectives– Longer passphrase without as much user input– Help defeat casual attacks

● Need all factors to access via your UI● Otherwise, need to brute-force


Passphrases

xkcd comics reproduced under CC license from Randall Munroe. Hat Guy is not amused.


Passphrases

● Multi-Factor Authentication Sources– NFC tag– QR code– Paired Bluetooth device– Wearable app– Gesture (e.g., pattern lock)– Biometrics (e.g., fingerprint scanner)


Passphrases

● Password Managers– Some offer APIs (e.g., OI Password Safe)– Benefit

● Easier: user does not have to remember as many passphrases

– Downside● Reliant upon third-party app and its security


Passphrases

● Changing SQLCipher Password– PRAGMA rekey = 'new passphrase';– Requires access to database with existing key– Execution time proportional to database size

● Background thread, please!


Encrypted Communications

● BackupManager– No control over exactly where this data is sent

● Could be replaced by device manufacturers, carriers

– Ideally, all data backed up should be encrypted with user passphrase

● Either because that data is always encrypted, or encrypt especially for backup/restore

● No sense in using static passphrase, as can be reverse-engineered



● GCM and C2DM– Data is encrypted during transmission– Data is not encrypted at Google's servers– Options

● Encrypt the message payloads● Message payloads are pointers to encrypted data

held elsewhere



● SSL: Basics– Use https:// URLs with URL or HttpClient– Use normally– Pray that your certificates are installed

● Self-signed certs● Unusual certificate authorities● Varying certificate authorities

– http://goo.gl/8anF9



● SSL Attack: Hack the CA– Comodo, DigiNotar, etc.

– Forged certificates claiming to be Google, Mozilla, Microsoft, etc.

– “When an attacker obtains a fraudulent certificate, he can use it to eavesdrop on the traffic between a user and a website even while the user believes that the connection is secure.”



● SSL Defense #1: Avoid CAs– CAs are needed for general-purpose clients (e.g.,

Web browsers)– If you control front end (app) and back end (Web

service), use private SSL certificates that can be verified by the app itself

– Moxie Marlinspike Implementation● http://goo.gl/DYTrb● See Option 1



● SSL Defense #2: Pinning– Assumes that you need to use a CA for some

reason (e.g., Web site + Web service)– Validates issuing CA

● Rather than the certificate itself● Limits attacks to ones where your CA gets hacked

– Moxie Marlinspike Implementation● http://goo.gl/DYTrb● See Option 2



● SSL Defense #3: User Validation– Assume that attacks are infrequent– Alert user when you see a different certificate

than used before● May indicate a MITM attack

– https://github.com/ge0rg/MemorizingTrustManager/wiki● Implementation of trust store and UI



● OnionKit– StrongTrustManager

● Customized set of CAs based on Debian cacerts file● Full chain verification● Limited pinning

– Proxying through Orbot● Tor implementation for Android

– https://github.com/guardianproject/OnionKit


Summary

● Consider Encryption– ...even if you don't think you need it

● SQLCipher: Easiest Option for Encrypted Database– ...if you can live with the APK footprint

● Think About Encrypting Other Data Stores, Means of Collecting Passphrases

● Q&A

Securing User Data with SQLCipher

Technology

Transcript of Securing User Data with SQLCipher