Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Challenges Building Secure Mobile Applications

2,243 views

Published on

A presentation given by Ben Whitaker and Tom Godber of Masabi at the Mobile World Congress 2009 show in Barcelona.

Published in: Technology, Education
  • Be the first to comment

Challenges Building Secure Mobile Applications

  1. 1. Challenges Building Secure Mobile Applications
  2. 2.  Who Are We?  Why security is an issue for mobile  Securing an insecure environment  Connecting with the real world  Case studies
  3. 3. •First in-game micropayments 2002 •First mobile viral 2004 •Playtech mobile casino •750+ handsets • 20 currencies 2006 •6 languages • 4 alphabets •First certified mobile security •3Kb EncryptME 2007 •Award winning •Ticketing • 2 Factor Authentication •Money transfers • Secure messaging 2008 •Banking • UK Rail Ticket Standard
  4. 4. Why is Security an Issue for Mobile?
  5. 5.  Don’t!  GSM encryption has been broken  Attacks and data theft have occurred
  6. 6.  HTTPS = end-to-end security  Mature key infrastructure  Browser support consistent, improving  Padlock icons  Certificate display  Colour coding title bar
  7. 7. WAP SECURITY WAP2 SECURITY  Inherently insecure:  Like the web:  Most handsets  Used on older browsers, use this with “Wap” settings “Internet” settings
  8. 8.  Inconsistent UI support  Maybe you get a padlock icon  Certificate details are buried under menus  Details are not always clear  Inconsistent naming, etc
  9. 9.  Pros:  Reformat desktop-optimised pages for mobile  Cons:  Break HTTPS end-to-end security
  10. 10.  Some will ignore HTTPS  Others will insert themselves in the connection  Handset cannot verify end certificate
  11. 11.  This is similar to a man in the middle attack  Thief proxies the real site  Steals information passing through  Handset can see thief’s certificate  So should be able to inform user
  12. 12.  Transcoder’s certificate would obscure thief’s  We don’t know transcoder’s policy for flagging suspicious certs  We shouldn’t have to care!
  13. 13.  You can ask a transcoder not to transform your content  Set HTTP header Cache-Control = “no-transformquot;  Eg. For Apache: <FilesMatch quot;.(php|cgi|pl)$quot;> Header append Cache-Control quot;no-transform” </FilesMatch>  http://mobiforge.com/developing/story/setting-http- headers-advise-transcoding-proxies  Transcoders should remove themselves from HTTPS connections with this header
  14. 14. Securing An Insecure Environment
  15. 15.  Application developer gains control over:  End-to-end GPRS/WiFi/3G/CSD connection security  File and storage encryption  SMS encryption  Takes responsibility and risk for:  Entropy (randomness) collection  Session Key generation  Session Key exchange  Session Encryption  Message integrity checking  Replay attack prevention
  16. 16.  Symmetric Session Encryption  Message Integrity Checks  Key Generation: Entropy and Pseudo-Random Number Generators  Key Exchange and server authentication Asymmetric encryption for key exchange
  17. 17.  Fast Processing, less than 1ms  Algorithms: AES, 3DES (Triple DES), RC4, Blowfish  Minimum Key size: 128 bits  Same keys at sender and receiver (hence Symmetric) Sender Receiver Session Key1 ABCDEF DADCCB Session Key1 Encrypt Decrypt DADCCB ABCDEF
  18. 18.  Has the message been tampered with?  Successful decrypt does not mean message is authentic and undamaged.  CRC is not enough, a deliberate attack could allow for CRC change Sender DADCCB Session Key1 ABCDEF Encrypt Receiver DADCCB DADCCA Session Key1 Decrypt DADCCA ABCDEZ
  19. 19.  Message Integrity Code – must be inside encrypted message, such as a hash  Message Authentication Code – can be outside  Code is created cryptographically from the un-encrypted payload, and added to the message.  Attacker cannot make a message adjustment and the corresponding MIC/MAC change so they are detected Receiver Sender DADCCA Session Key1 Session Key1 ABCDEF Decrypt Encrypt MAC ABCDEZ DADCCB ASAKFA Check MAC DADCCA ASAKFA ASAKFA KADILSB
  20. 20. Sender Receiver Session Key1 Session Key1  Both sender and receiver need same key  Attacker must not discover/guess key  4 digit pin code is so short that it can be guessed very quickly – not secure  Any key material in the application can be seen by attacker during download
  21. 21.  PKI Public/Private Key Encryption  Slower Processing – 10ms to over 10 seconds  Algorithms: RSA, Elliptic Curves (ECC) – difficult maths  Minimum Key sizes: 1024bit RSA or 160bit ECC  Different key to reverse encryption, public key is freely available Sender Receiver ZAPLAS Private Key1 Public WXYZ Key1 Encrypt Decrypt ZAPLAS WXYZ
  22. 22.  For a given algorithm, larger keys provide better security  BUT – only if all of the key material is unknown to the attacker.  Effective key strength is only the size of the unknown data inside the key 256bit key made from a 4 digit Pin is only 13bits of effective security
  23. 23.  Possible values: 0 – 9999  Assuming each is equally likely  213 = 8192  A 4 digit PIN key = 13bit security  Whether using 64bit DES or 256bit AES!  On average, crackable in 9999/ 2 = 5000 attempts
  24. 24.  Used to create symmetric session key  Not really random – deterministic to allow testing  The programmer must seed with something really random – ENTROPY. User1 Attacker1 User2 Seed Seed Seed (4 digit pin) (guess) (934351...) pRNG pRNG pRNG 4510920……… 4510920……… 1275676……… User 1 is probably in trouble – if seed is easy to guess e.g. 5000 guesses for PIN then the session KEY is easy to guess, in just 5000 attempts, regardless of key size
  25. 25. Good Sources: the USER or environment noise  Timing of user keypresses  Microphone input  Pen/mouse/accelerometer wiggling  Camera image taken especially for randomness Bad Sources: the DEVICE  Time (a favourite for lazy programmers)  Time taken for long process or program startup  Time between ticks of a throttled state machine  IMEI  Network delays  Free memory “Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.” von Neumann
  26. 26.  Standard keypad has 16-20 keys  0123456789*#, direction and soft keys => 4 bits per keypress (24 = 16)  Time presses for extra bits  Assume 30ms clock granularity  1 press per second av. => ~4 bits  Resource loading => no entropy  S40 is almost entirely repeatable  S60 is almost entirely random…
  27. 27.  No key exchange protection  Only exchange a guessable PIN  Embed session or partial keys inside application  Lack of Asymmetric encryption  No real entropy  Seeds from time or some other non-chaotic source  No message integrity check  Vulnerable to message alteration  No replay attack prevention  Server can process repeat transactions
  28. 28.  Easy to make maths or key mistakes  Performance on older handsets  Sometimes traded for code size  Certification tests (with lots of test data)  Reveal subtle bugs  Assure correctness
  29. 29.  Free!  Big  JavaME version is ~1Mb jar  You need to prune it!  Unit test heavily if you make changes  Size comparison (once optimised):
  30. 30. Connecting With The Real World
  31. 31. Live at London Marylebone Station
  32. 32.  Cap-Ex intensive rollouts  Users need new hardware  Cards (eg. Oyster) or NFC phones  When will NFC handsets be mainstream?  O2: “2013” (O2/Telefonica are the operator most involved in NFC trials)
  33. 33. NOKIA HANDSETS NOKIA NFC HANDSETS
  34. 34.  Reliable, fast  Offline scanning  Tickets still work when Internet doesn’t!  Open security  PKI signatures prevent modification  Public Key verification is cheap, easy  Royalty free, open barcodes  Aztec scans best on a handset screen
  35. 35.  Tickets must be supported on everything!  Smartphones are a niche  SMS / MMS / Wap / Web delivery supported  Apps can add:  Better rendering => faster scanning  Quick, secure purchase
  36. 36. Case Studies
  37. 37.  Parking payments straight from phone  No need for explicit sign-up or passwords  Just type CVV again for future purchases  All user data entry and validation performed off-line by application  Secure SMS for users without data settings or with poor reception  New user can sign-up and pay in just one SMS 95% of trial users said: “better than the IVR system we used until now”
  38. 38. Chiltern Railways with YourRail Trial user feedback: “Better than the web!”  Buy anywhere  No paper, no queues - barcode tickets  Tunnels aren’t showstoppers!  Auto-detects SMS or GPRS  1-2 SMS per ticket  Doubles the consumer uptake by removing Data issues  Quick repeat tickets  Customer loyalty and lock-in
  39. 39.  Playtech (AIM: PTEC)  World’s largest public online gaming software supplier  Sign-up, deposits and pay- outs from the handset  Hot swap mid-game  Desktop & mobile share login  1000+ handsets, multiple casinos, multiple languages
  40. 40.  Application advantages:  Secure even on old phones  Improved usability  Reduced bandwidth  Common mistakes:  Must use same login as web  Opera Mini FAQ says don’t use Mini for secure data!  Though some banks recommend it…
  41. 41.  Cashless Purchases  Match Tickets - no touting  Refreshments - faster service, no shrinkage  Merchandise - can even post to home  Live offers to Fans, at optimum times  Ticket offers mid-week (at pub o’clock)  Encourage early entry  Follow-up offers after a win
  42. 42. …and relax, we’re done!
  43. 43. 1. Security is good maths AND good design 2. If you use HTTPS, set the no-transform header (and hope)! 3. Support every handset 4. Remember the entropy 5. 2D barcodes offer lower cap-ex than NFC, without the wait
  44. 44. Transport Finance & Banks Entitlement & Gaming Venues
  45. 45. • 3rd party certified Security • End-to-end • Fast and small • Popular handsets Portability • All form factors • Fragmentation • Offline functions Usability • Interactive experience • Slick and attractive
  46. 46.  US Government Certified  British Telecom validated  IET Security Award  Latest Encryption Strength  1024bit RSA, 256bit AES  Standard Server Cryptography  Tiny 3Kb library  Works on all Java phones  Extremely fast  Secures any medium  SMS, GPRS, Bluetooth, NFC  On-phone storage
  47. 47. Masabi Proxy Retailer Web (can be hosted by retailer) Services SMS “Tickets” to 89080 1 2 Auto-Install SMS 3 Purchase Request and Payment Details 4 (sent by encrypted SMS or Data from the mobile application) XML Web Service Requests 5 Success message with content, ticket or code

×