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

An Adaptive Approach to Securing Ubiquitous Smart Devices ...€¦ · An Adaptive Approach to Securing Ubiquitous Smart Devices in IoT Environment with Probabilistic User Behavior

Securing Your User Profiles Against Abuse Securing Your User

Securing Cloud-assisted Services5 Securing cloud storage Client-side encryption of user data is desirable But naïve client-side encryption conflicts with • Storage provider’s

Securing Graphical User Interfaces - TU Dresden

Monitoring, Managing, and Securing SDN … Managing, and Securing SDN Deployments ... Managing, and Securing SDN Deployments ... Managing, and Securing SDN Deployments

Securing SharePoint Environment and its Content - SharePoint User Group UK Cambridge (22 March 2016)

Symantec, Facebook and Navillus - a comprehensive approach to securing & monitoring user access with GRC Advanced Controls

Securing ERP · 2020-02-14 · Securing Oracle ERP Cloud: Overview Oracle ERP Cloud is secure as delivered. This guide explains how to enable user access to ERP functions and data

Introducing Novell Privileged User Manager and Securing Novell Open Enterprise Server 2

SECURING COMMUNICATION IN IP-CONNECTED SECURING

Securing IoT Connected Device Applications - GOTO Blog · Securing IoT Connected Device Applications Ian Massingham Technology Evangelist, AWS IanMmmm. ... Amazon Cognito User Identity

Securing Legacy Software SoBeNet User group meeting 25/06/2004

The 2017 Duo Trusted Access Report - Amazon …...Securing the new enterprise network requires a new approach – one that focuses on securing user and device access to applications

Securing Debian Manual – securing-debian-howto.pt-br.pdf

Securing Enterprise Securing Enterprise Securing Enterprise

Securing ArcGIS Server Services An Introduction · Securing ArcGIS Server Services Technical Workshop 2013 Esri International User Conference July 8–12, 2013 ... - An Introduction

AWS Artifact - User Guide · AWS Artifact User Guide Securing Your Documents Securing Your Documents AWS Artifact documents are conﬁdential and should be kept secure at all times

Chapter 8: Securing Switched LANs · 2 8: Securing Switched LANs 3 Chapter Roadmap Securing Switched Ethernet LANs Securing the MAC self-learning process Securing DHCP and ARP Securing

Securing Your User Profiles Against Abuse - iSeries AS/400

Windows Phone App Security - Global AppSec2015.appsec.eu/wp-content/uploads/2015/09/owasp... · Consider adopting SQLCipher instead of SQLite 21 Windows Phone App Security Secure