Securing User Data with SQLCipher

AnDevCon IV

Securing User
Data with
SQLCipher
Copyright © 2012 CommonsWare, LLC

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 key
Xkcd 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 Copyright © 2012 CommonsWare, LLC

● 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 Copyright © 2012 CommonsWare, LLC

Securing User Data with SQLCipher

Recomendados

Recomendados

Más contenido relacionado

Similar a Securing User Data with SQLCipher

Similar a Securing User Data with SQLCipher (20)

Más de CommonsWare

Más de CommonsWare (20)

Último

Último (20)

Securing User Data with SQLCipher