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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Securing User Data with SQLCipher

Ähnlich wie Securing User Data with SQLCipher (20)

Mehr von CommonsWare

Mehr von CommonsWare (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Securing User Data with SQLCipher