Challenges Building
Secure Mobile Applications
   Who Are We?

   Why security is an issue for mobile

   Securing an insecure environment

   Connecting with the re...
•First in-game
        micropayments
2002

       •First mobile viral
2004

       •Playtech mobile casino
        •750+ h...
Why is
Security
an Issue
for Mobile?
   Don’t!


   GSM encryption has been broken


   Attacks and data theft have occurred
 HTTPS =
  end-to-end security
 Mature key
  infrastructure
 Browser support
  consistent, improving
     Padlock icon...
WAP SECURITY               WAP2 SECURITY

   Inherently insecure:         Like the web:




                            ...
   Inconsistent UI support
     Maybe you get a padlock icon


   Certificate details are buried under
    menus




  ...
   Pros:
     Reformat desktop-optimised pages for
     mobile



   Cons:
     Break HTTPS end-to-end security
   Some will ignore HTTPS

   Others will insert themselves in the
    connection
     Handset cannot verify end certif...
   This is similar to a man in the middle
    attack
     Thief proxies the real site
     Steals information passing t...
   Transcoder’s certificate would
    obscure thief’s
     We don’t know transcoder’s policy for
      flagging suspicio...
   You can ask a transcoder not to
    transform your content
     Set HTTP header
      Cache-Control = “no-transformqu...
Securing
An Insecure
Environment
   Application developer gains control over:
       End-to-end GPRS/WiFi/3G/CSD connection security
       File and sto...
   Symmetric Session Encryption

   Message Integrity Checks

   Key Generation: Entropy and
    Pseudo-Random Number G...
 Fast Processing, less than 1ms
    Algorithms: AES, 3DES (Triple DES), RC4, Blowfish
    Minimum Key size: 128 bits
  ...
    Has the message been tampered with?
          Successful decrypt does not mean message is authentic and
            ...
   Message Integrity Code – must be inside encrypted message, such as a hash
    Message Authentication Code – can be ou...
Sender
                                         Receiver
     Session Key1                         Session Key1




   Bo...
 PKI Public/Private Key Encryption
    Slower Processing – 10ms to over 10 seconds
    Algorithms: RSA, Elliptic Curves...
   For a given algorithm, larger
    keys provide better security

   BUT – only if all of the key
    material is unkno...
   Possible values: 0 – 9999
     Assuming each is equally likely


   213 = 8192

   A 4 digit PIN key = 13bit securi...
 Used to create symmetric session key
     Not really random – deterministic to allow testing
     The programmer must ...
Good Sources: the USER or environment noise
   Timing of user keypresses
   Microphone input
   Pen/mouse/accelerometer...
   Standard keypad has 16-20 keys
     0123456789*#, direction and soft keys
     => 4 bits per keypress (24 = 16)

   ...
   No key exchange protection
     Only exchange a guessable PIN
     Embed session or partial keys inside application
...
   Easy to make maths or key mistakes


   Performance on older handsets
     Sometimes traded for code size



   Cer...
   Free!
   Big
     JavaME version is ~1Mb jar
     You need to prune it!
     Unit test heavily if you make changes...
Connecting With
The Real
World
Live at London Marylebone Station
   Cap-Ex intensive rollouts

   Users need new hardware
     Cards (eg. Oyster) or NFC phones


   When will NFC hand...
NOKIA HANDSETS   NOKIA NFC HANDSETS
   Reliable, fast
     Offline scanning
     Tickets still work when Internet doesn’t!


   Open security
     PKI si...
   Tickets must be
    supported on everything!
     Smartphones are a niche


   SMS / MMS / Wap / Web
    delivery su...
Case
Studies
   Parking payments straight from phone
     No need for explicit sign-up or passwords
     Just type CVV again for fut...
Chiltern Railways with YourRail
          Trial user feedback: “Better than the web!”




   Buy anywhere
     No paper,...
   Playtech (AIM: PTEC)
     World’s largest public online
     gaming software supplier

   Sign-up, deposits and pay-...
   Application advantages:
     Secure even on old phones
     Improved usability
     Reduced bandwidth


   Common ...
   Cashless Purchases
     Match Tickets - no touting
     Refreshments - faster service,
      no shrinkage
     Merc...
…and relax, we’re done!
1.   Security is good maths AND good design

2.   If you use HTTPS, set the
      no-transform header (and hope)!

3.   Su...
Transport      Finance &
                  Banks



Entitlement &
                 Gaming
   Venues
• 3rd party certified
Security      • End-to-end
              • Fast and small


              • Popular handsets
Portabi...
   US Government Certified
     British Telecom validated
     IET Security Award

   Latest Encryption Strength
    ...
Masabi Proxy                  Retailer Web
                                             (can be hosted by
                ...
Challenges Building Secure Mobile Applications
Challenges Building Secure Mobile Applications
Challenges Building Secure Mobile Applications
Upcoming SlideShare
Loading in...5
×

Challenges Building Secure Mobile Applications

1,892

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
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,892
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
139
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • <number>
  • <number>
  • Masabi have been producing downloadable mobile applications for over 7 years, and today Masabi secure mobile applications process millions of dollars worth of transactions every year<number>
  • <number>
  • <number>
  • <number>
  • <number>
  • <number>
  • <number>
  • <number>
  • <number>
  • <number>
  • http://mobiforge.com/developing/story/setting-http-headers-advise-transcoding-proxies<number>
  • <number>
  • If you can’t trust the networks, or are using phones that don’t have HTTPS, then you have to take matters into your own hands and put in end-to-end encryption from your app to your own server to ensure that you always know the level of security between server and customer<number>
  • <number>
  • 17
  • 17
  • 19
  • 20
  • 20
  • 20
  • 20
  • 24
  • 24
  • Testing to ensure pRNG’s are implemented correctly is to ensure that pRNG output never becomes cyclic or tends towards a stable value.26
  • 26
  • 26
  • 26
  • 26
  • 26
  • 26
  • We’re using on-screen barcodes to show the ticket values for reading by automatic gates, or checking by the train guards who carry hand-held scanners.The ticket code can be transferred to the NFC element on compatible phones (like this nokia 6131) but this handset is the only mainstream GSM handset with NFC and we’ve not heard of others in the pipeline.Even when NFC services become mainstream, you will still need a secure interface to purchase entitlements, before they get transferred to the NFC element. 26
  • 26
  • 26
  • 26
  • 26
  • 26
  • Simple – simply put in your car, your credit card, and how long you want to park.Brand new user can sign up and pay in just one secure SMS (or 0.02pence worth of data)Extend your parking without returning to the vehicle.26
  • Credit Card details entered just once into the application.Users have said “easier to use the mobile purchase than web purchase” because of quick, optimised workflow.26
  • 26
  • 26
  • 26
  • 26
  • 26
  • Come see me after for live demos, or to chat about building secure mobile applications form-commerce,Banking,Ticketing,Messaging,Read our blog for more details on security.blog.masabi.com26
  • 26
  • Our applications are built on three core principals –Make the application usable and relevant to the end user, and make the default use cases quick and easy on the mobile. (I’ll show you some sides of that later)Then, PORTABILITY to all popular handsets, including the older handsets that many developers avoid, to ensure the largest possible user-base for your service.For Mobile commerce – security, on all phones, to modern public standards.26
  • Standard GSM services are not secure to Financial Services or Payment Card Industry regulations. You shouldn’t use SMS or WAP to send payment instructions, bank passwords or credit card details because too many individuals can gain access to them in transit.(True end-to-end https is only available on the latest handsets – slow and not usable from Java or SMS.)\"The contents of SMS messages are known to the network operator's systems and personnel. Therefore, SMS is not an appropriate technology for secure communications. Most users do not realise how easy it may be to intercept“ Nick Jones, Gartner Research 2002 http://www.gartner.com/DisplayDocument?doc_cd=111720“It would not be enough for a financial institution to provide mobile banking services relying on de-facto GSM protocol security”Pakistan State Bank, Guidelines for Branchless Banking 2007http://www.sbp.org.pk/bprd/2007/Guidelines-Branchless-Banking.pdfWe built EncryptME to the latest standards for new secure web services, and it is still the world’s only US Government Certified mobile java security library.At 3kb, it can provide security on the oldest java handsets, including the black and white Nokia 6310i (show legendary retro business phone)Most importantly, it allows SMS data to be encrypted too!Servers can continue to use standard cryptography from Sun or Microsoft etc – they don’t need to use custom or proprietary security libraries.26
  • Repeat purchases just use steps 3,4,5, and the user only has to enter CVV number.26
  • 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×