Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Privacy & Security in Apps

B272216b76be8aacbfd11fad48196558?s=47 Ivo Jansch
November 13, 2012

Privacy & Security in Apps

An overview of various privacy and security related topics for mobile app developers. Covers examples in Android and iOS. Presented at the 'appdev' event, the developer track at the 'Bedrijf Zoekt App' event on november 13, 2012 in Bussum, The Netherlands.

B272216b76be8aacbfd11fad48196558?s=128

Ivo Jansch

November 13, 2012
Tweet

Transcript

  1. http://www.egeniq.com info@egeniq.com @egeniq Bedrijf Zoekt App / AppDevEvent, 13 november

    2012 Ivo Jansch Privacy & Security in Apps
  2. About Me @ijansch Entreprenerd Mobile & Web Developer Author &

    Speaker 2
  3. About Egeniq Mobile Development Knowledge Distributed 3

  4. Can We Trust The Device? 4

  5. Your phone knows things your friends don’t 5

  6. What your phone knows: 6 Where you are Time &

    Date Orientation & Position Who you are Who your wife is Your sister’s birthday Where your wife is Where you work Who you call Who emails you Who your friends are What you like Contact details
  7. PlaceRaider 7 Source: http://www.technologyreview.com/view/429394/placeraider-the-military-smartphone-malware/

  8. Smartphone as an eavesdropping device 8 Source: http://www.switched.com/2011/01/20/ralf-philipp-weinmann-turns-smartphone-hack-eavesdropping-device/

  9. Banks use advanced privacy protection 9 Picture taken from: http://systemato.com/2012/08/my-6-favourite-android-apps/

  10. ... but is app protection sufficient? 10 Source: http://www.zdnet.com/mind-hackers-could-get-secrets-from-your-brainwaves-7000003267/

  11. Actual Incidents 11

  12. Incidents ‣ iPhone Location Tracking (2011) • http://www.nytimes.com/2011/04/28/technology/28apple.html? _r=2& •

    Accident ‣ Path Address Book Upload Controversy (2012) • http://www.theverge.com/2012/2/8/2785217/path-ios-address- book-upload-ceo-apology • Naivety, good intentions ‣ Google Play Malware ‘grand theft auto’ (2012) • http://www.informationweek.com/security/attacks/more-android- malware-pulled-from-google/240003514?itc=edit_in_body_cross • Bad intentions 12
  13. Our responsibility as developer 13

  14. IMHO, Developers Should: ‣Respect user privacy • Collect only what

    you need • Be open about what you collect • Treat data responsibly ‣Write secure code • Follow common security best practices • Protect data (server, device, transport) • Don’t invent your own wheels (standards!) 14
  15. A small demo: TIQR Learning about security using open source

    tools 15
  16. Tiqr - Demo 16 1 2 3 4 5 6

    http://www.tiqr.org
  17. Why is Mobile Security Important? ‣Apps run on our user’s

    hardware • Out of our control ‣Our users deal with third party services • Even more out of our control 17
  18. A Use Case 18 Mobile App Third Party Services Server

    backend
  19. OAuth 19 OAuth Consumer OAuth Provider

  20. Why do you need to protect keys? 20 8 OAuth

    Provider
  21. Security Mechanisms On the major platforms 21

  22. Sandboxing ‣Apps only have access to their own data ‣Access

    is based on OS user ID ‣Further protected by application signature 22
  23. Permission Models ‣ Android uses permissions: ‣ Apple: GPS and

    push • Since iOS6: Contacts, Photos, etc. 23
  24. Storage + Secure Storage ‣ Device Storage • Apps have

    their own location, within sandbox ‣ USB Storage (Android) • External storage, sharable between apps ‣ Hardware Encrypted Storage (iOS) • Hardware Encryption (passcode lock) • Sandboxed Keychain ‣ Software Encrypted Storage (Android) • Java KeyStores with strong encryption algorithms • Honeycomb/ICS also have ‘whole device encryption’ 24
  25. So we don’t have to worry, right? ‣Can I securely

    store data? • Is sandboxing a solution? -> Not when device is rooted • Is device storage a solution? -> Not when device is rooted 25
  26. It’s a common question Stackoverflow search for ‘store secret iphone’:

    26
  27. With common answers 27

  28. Know what? I’ll just use a library 28

  29. Securing Data In Your Code 0. Obfuscation 29

  30. Obfuscation 30

  31. Securing Data In Your Code 1. Encryption 31

  32. Encryption (iOS) 32

  33. Decryption (iOS) 33

  34. Encryption (Android) 34

  35. Encryption (Android) 35

  36. What’s the problem with encryption? 36 We need another key

    to protect the secret
  37. Other Encryption gotchas ‣AppStore is US based: Encryption export •

    Requires NSA approval, basically • Process is documented, but time consuming • Not needed if it’s only for “authentication purposes” ‣Two flavours of US gov approval: • Self classification (if you use standard stuff for standard things) • Agency classification (non standard stuff and/or non standard things) 37
  38. Securing Data In Your Code 2. Secure Storage 38

  39. KeyChain (iOS) ‣Hardware based encryption for secrets ‣Good: • Not

    too much code • No extra key/password required (device passcode) • Works well with (encrypted) iTunes Backup ‣Bad: • Not every user has a passcode set • Lower level functions, lots of C (complexity) • Doesn’t work across iCloud backup/restore 39
  40. More KeyChain So if I use the KeyChain and have

    a passcode, I’m safe, right? RIGHT? ‣4 digit passode can be brute forced in 9 minutes ‣6 digit passcode takes 1.5 years Source: Fraunhofer’s “iOS KeyChain Weakness FAQ” http://sit4.me/ios-keychain-faq 40
  41. Using the KeyChain 41

  42. Using the KeyStore (Android) 42

  43. Using the KeyStore (Android) 43

  44. Securing Data In Your Code 3. Server Side Solutions 44

  45. Retrieve key from API 45 iOS App OAuth Provider Your

    API ?
  46. Transparent Proxy 46 iOS App OAuth Provider Proxy

  47. Securing Data In Your Code 4. “All of the above”

    47
  48. What are we doing in Tiqr? ‣ Tiqr secrets are

    encrypted • The encryption key is a pincode • There’s no plain text to compare against, so breaking it is hard ‣ Encrypted identities are stored in keychain • So also protected by passcode lock, if present ‣ Secret is not communicated • Challenge/response for ‘proof of posession’ ‣ Requires server validation of decrypted secret • Server enforces temporary and permanent blocks to stop brute force 48
  49. Always Secure Your Code (Because data is not the only

    thing at risk) 49
  50. Buffers 50 ‣Especially when moving down to C level constructs,

    be wary...
  51. Validate input! ‣Don’t trust ANY input • Data entered by

    the user • Data entered by other apps • Data retrieved from an API • Data retrieved from .... ‣Don’t think ‘SQL Injection’ is only a concern for web developers 51
  52. Conclusion 52

  53. Conclusion It’s all about awareness 53

  54. Recommended Reading ‣ ISBN: 2147483647 ‣ Authors: • Himanshu Dwivedi

    • Chris Clark • David Thiel ‣ Covers: • Android • Apple • WinMo 54
  55. Thank you! Questions? http://www.egeniq.com info@egeniq.com @egeniq http://www.egeniq.com (about us) http://tiqr.org

    (demo + code) ivo@egeniq.com @ijansch
  56. Credits ‣ ‘Tege in Sandbox’ by Judi Cox - http://www.flickr.com/photos/madaise/3406217980/

    ‣ ‘Locker (KHS up close) by Travis Hymas - http://www.flickr.com/photos/ travishasphotos/3481640534/ ‣ ‘Mask’ by Ben Fredericson - http://www.flickr.com/photos/xjrlokix/3932488768/