Protecting data on device with SQLCipher, Stephen Lombardo


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • IntroductionHere to talk about Mobile data encryption and securityDifficult to discuss security without understanding the threat modelWhat we are trying to secure – how sensitive, etc.Impact of security issuesPotential attacks that can be mountedSecurity issues we care about as developersTwo things this talk will coverFirst, Provide context about mobile securityWhy its importantSome of the challengesSecond, provide specific information about SQLCipherAn encryption library for Xamarin (and other platforms)Goal – give a detailed summary of what it does, how it works, so you can make educated decisions about whether it makes sense to use itNo silver bullet, but tools like SQLCipher can provide some real benefits
  • Mobile security presents a set of unique challenges.Security teams and developers recognize thisSmall,Light, usually Untethered, brought everywhereResults in poor Physical Security – Unlike servers in a data center, workstations at the office, or laptops on a home deskThe perfect targets for loss and theftDue to their connected nature, data is often shared off deviceThere is a growing set of threats against mobile devices. Mobile OS makers like Google and Apple recognize this, and provide a set of built in security featuresLets take a quick look at the standard set of defenses
  • Most common method of device authenticationPin codes make horrible credentialsShort, low entropy, easily brute forced. Even without brute force attack, terribly predictableHeatmap of PIN codes DataGenetics study about distribution of PINsMore than 26% of pin codes guessed with 20 combinationsLower left corner – pins starting with 0 and 1, MM / DD formatsBig vertical stripe – pins that start with 19.Diagonal – repeated couples, 2121, 0000 etc – bright dots are quad numbersWeak codes making them susceptible to targeted attacks + research. Also easy to research (birth date, anniversary, kids ages)
  • Neat option for unlocking android phones.Unique “biomentric” optionTake a picture of yourself on the deviceShow face to the camera to unlock it. Standard facial recognition algorithms to detect that its youIt’s “biometric” right? It must be secureEasy to bypass. Grab a picture off the internet, or a mugshot, and you can usually unlock a device.Even newer versions that have a “liveliness check” are can be easily bypassed with some photoshopingPlus, this is inconvenient - slow to initialize, doesn’t work in low light etc, so it falls back on pincodeAt best, as secure as pin code, at worst, well, much much worse.
  • Pattern locks are big on Android (now a bit on windows)Better retention of visible patterns than random number stringsPointed out this feature as a benefit of androidLimitation is that a 3 x 3 block only has so many combinations: ~ 300k, not great but still that’s better than a pin code right?Fatal flaw is smudge attacks. Paper,Smudge Attacks on Smartphone Touch Screens, did a good job of analyzing the risks herePatterns can be easily read off a screen, even if it is wiped afterwards
  • Show of hands – who uses a password or 8+ digit pin code on their devices?Greater level of security than other options combined.inconvenientdifficult to typefrequently based on dictionary wordsReused and subject to guessing on targeted attacksMark Burnett of ( the book about passwords “Perfect Password: Selection, Protection, Authentication”Found 14% in top 10 passwords, 40% from the top 100 passwords
  • What about device encryption?For apple, if you setup a lock code its enabled by default.Show of hands for android – how many people have enabled device encryption on their phones or tablets?1+ hour setup on Android, during which you cant use the phone, unplug it, etc.Also, as weak as the lock keyDevice encryption is a great feature – the fact that it is offered across practically all devices is wonderful, but you really can’t count on it.
  • Many device security optionsBut, devices are insecure by defaultMany people take them home, and set them upNever bothering setting up a passcodeNever enable encryptionEven if they are setup “right”, routinely shared devices with coworkers, family, friendsYou need to assume the worstTreat device security necessary, but sufficient for sensitive apps
  • Forensic toolkits from companies like Elcomsoft and Cellbrite for targeting phonesRooting / Jailbreaking allows vectors for untrusted software - android SwiftKeykeyloggerOS Issues - Lock bypass exploitsInfrequent updatesRemovable storage Cloud services now store mobile device dataNo longer a little lockboxApps share data with third partiesiCloud, Dropbox, Google Drive, cloud services, corporate data centersA fact exploited by forensic tookitsLoose exclusive control of dataDevices are often shared – Show of handsRaise your hand if there is at least one other person who can access your device (i.e. shared pin code)Has anyone here, in the last week, you’ve unlocked your device so that someone else can use it We place a lot of trust in technology that is extremely difficult to secure
  • App developers we face an additional responsibilityDriven by regulatory compliance (e.g. HIPPA)Desire to protect the secrets of the company they work forPrevent financial liability and loss of reputation associatedProtect against government threatsNo tinfoil hat here, but there are may citizens in oppressive regimes that use mobile applicationsOne of the organizations we work with, The Guardian Project, focuses heavily on serving these needsDon’t always know how apps will be used. Finally, a responsibility to the user, in all shapes and forms, torespect their privacy,treat the information they share with us with respect.
  • Goalsfor risk mitigation at the application level. The first key is layered security. It’s OK to use the device security as a first gatewayApplications should consider whether they need their own security implementationThe more layers you can put between a potential attacker and your data, the better
  • Reduce attack “surface area”Don’t assume for a second that the owner if the device is going to be the only person using it.If your application deals with sensitive data it should provide a security “Step Up”Even a minimal block to ensure that a casual user can’t open the app and poke around
  • Simple authentication or local auth to keep casual users outBut, don’t trust that the app is the only way to get the data on or off deviceData can be extracted off devicesOff backupsDevice can be lost and compromisedUsing a cloud service (Dropbox, Google Drive, iCloud), can you control all of the access points?Vectors for replacing / compromising databases
  • Authentication - verify that the user of the application knows some unique secret to access the dataEncryptionEnsure that the data is unreadable without the secretEven if extracted off the devicepulled off a cloud servicepulled from a backup on SD card, etcAuthenticityEnsure that if the data can’t be tampered withOptionsDon’t do anything locallyUsability, performance, offlineFile level encryptionField level encryptionA lot of work
  • SQLCipher can provide three “services” to an applicationExtension to SQLite (plugin, but more involved).SQLite is amazingHistoryRead / write interceptionProvide all features, functions, etc of SQLiteThe entire database is encryptedFast only decrypts what it needsLike SQLite, PortableXamarin.*, iOS, stock Android, Mac, Linux, Windows via ADO.NET, PHPCore is Open Source, transparent
  • AES 256 CBCRandom IVsRandom saltPBKDF2MACOpenSSLFast startupNo size limit
  • Pager CodecKey DerivationEncryptionMAC
  • Drop-in ReplacementiOS & AndroidComponent StoreFree for EnterpriseTrial Available
  • We just added support for sqlite-net A. Krueger
  • Indistinguishable from random data
  • Performance on the overall is very goodEncryption overhead is minimal ranging from 5 – 35% in most cases, more in some exceptional situationsDesign is importantDo - Normalize dataDo - Use indexesDo – Use TransactionsDon’t - frequent non-indexed queries or massive updatesDon’t - open new connections for every database
  • PRAGMA rekeyPRAGMA cipherPRAGMA kdf_iterPRAGMA cipher_page_sizePRAGMA cipher_use_hmacATTACHsqlcipher_export()
  • Key ManagementAt least part of the key needs to come from the userApps should recommend strong passwords, not weak pins or passphrasesLost Credentials - If you forget the key you are cookedExisting Databases – migrate them using ATTACH and sqlcipher_export()Compression – Not well!Portability – Very good, the same database can be opened on any platform supporting SQLCipherExport Administration Regulations, Bureau of Industry and Security
  • Protecting data on device with SQLCipher, Stephen Lombardo

    1. 1. Mobile Data EncryptionEnhanced Application Security with SQLCipherStephen Lombardo | Zetetic LLC | @sjlombardo
    2. 2. Unique Challenges
    3. 3. Pin CodesShortLow EntropyPredictableSource: DataGenetics, could be guessed by attempting 20 combinations
    4. 4. Face RecognitionPhoto BypassPoor PerformanceInconvenient
    5. 5. Pattern LockLow EntropySmudge AttacksSee Also: Smudge Attacks on Smartphone Touch Screens ,
    6. 6. PasswordsInconvenientDictionary BasedFrequently ReusedSource: 10,000 Top Passwords, Mark Burnett
    7. 7. Device EncryptionInconvenientUses Lock Key
    8. 8. Default InsecureOriginal photo by Jean-Etienne Poirrier (jepoirrier) on Flickr
    9. 9. Threat Landscape•Forensic Analysis•Rooting / Jail breaking•OS Issues•Infrequent Updates•Removable Storage•Cloud Services•Targeted Attacks•Device Sharing
    10. 10. ResponsibilityComplianceCorporateLiabilityGovernment ThreatsRespect
    11. 11. Defense in DepthMake attacksdifficult withmultiple layers ofsecurity
    12. 12. Principle ofLeast PrivilegeAccess to deviceshould not allowaccess to all appsand data
    13. 13. Data SecurityMinimize impact ofunauthorizedaccess, on and offdevice
    14. 14. Strategies1. Authentication2. Encryption3. Authenticity
    15. 15. SQLite ExtensionFull DatabaseEncryptionGood PerformancePortableOpen Source CoreSQLite by D. Richard Hipp, Hwaci,
    16. 16. Features• AES 256 CBC• Random IVs• Random salt• Key Derivation• MAC• OpenSSL• Fast startup• No size limit
    17. 17. How it WorksPager CodecKey DerivationEncryptionMACDatabaseSaltEncrypted DataEncrypted Data IVMACEncrypted DataEncrypted Data IVMACEncrypted DataEncrypted Data IVMACPage1Page2Page3
    18. 18. XamarinDrop-in ReplacementiOS & AndroidComponent StoreFree for EnterpriseTrial Available
    19. 19. Installation
    20. 20. Mono.Data.Sqlcipherusing Mono.Data.Sqlcipher;using(var conn = new SqliteConnection(ConnectionString)){conn.SetPassword(secret);conn.Open();using (var cmd = conn.CreateCommand()){cmd.CommandText = “CREATE TABLE Model(“ +“Id INTEGER PRIMARY KEY AUTOINCREMENT, Content TEXT)";cmd.ExecuteNonQuery();cmd.CommandText ="INSERT INTO Model (Content) VALUES (@content)";var p = cmd.CreateParameter();p.ParameterName = "@content";p.Value = content;cmd.Parameters.Add(p);cmd.CommandText =“SELECT * FROM Model Where Id = 0";var reader = command.ExecuteReader ();while (reader.Read()) {}}}© The Mono ProjectRobert Simpson &
    21. 21. sqlite-netusing SQLite;public class Model{[PrimaryKey,AutoIncrement]public int Id { get; set; }public string Content { get; set; }}…using(var conn = new SQLiteConnection (file, secret)){conn.CreateTable<Model>();conn.InsertOrReplace(new Model() {Id = 0, Content = content});var models = conn.Table<Model>().Where(x => x.Id == 0);models = conn.Query<Model> ("SELECT * FROM Model WHERE Id = ?", 0);}© Frank Krueger, Krueger Systems
    22. 22. Results
    23. 23. Performance
    24. 24. Advanced• PRAGMA rekey• PRAGMA cipher• PRAGMA kdf_iter• PRAGMA cipher_page_size• PRAGMA cipher_use_hmac• ATTACH• sqlcipher_export()
    25. 25. FAQ• Key Management• Lost Credentials• Existing Databases• Compression• Portability• Export
    26. 26. Resources
    27. 27. Q & A
    28. 28. Thank you!Stephen Lombardo | Zetetic LLC | @sjlombardo