Challenges Building Secure Mobile Applications

63 %
38 %
Information about Challenges Building Secure Mobile Applications
Technology

Published on February 26, 2009

Author: masabi

Source: slideshare.net

Description

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

Challenges Building Secure Mobile Applications

 Who Are We?  Why security is an issue for mobile  Securing an insecure environment  Connecting with the real world  Case studies

•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

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 icons  Certificate display  Colour coding title bar

WAP SECURITY WAP2 SECURITY  Inherently insecure:  Like the web:  Most handsets  Used on older browsers, use this with “Wap” settings “Internet” settings

 Inconsistent UI support  Maybe you get a padlock icon  Certificate details are buried under menus  Details are not always clear  Inconsistent naming, etc

 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 certificate

 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

 Transcoder’s certificate would obscure thief’s  We don’t know transcoder’s policy for flagging suspicious certs  We shouldn’t have to care!

 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

Securing An Insecure Environment

 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

 Symmetric Session Encryption  Message Integrity Checks  Key Generation: Entropy and Pseudo-Random Number Generators  Key Exchange and server authentication Asymmetric encryption for key exchange

 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

 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

 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

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

 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

 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

 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

 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

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

 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…

 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

 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

 Free!  Big  JavaME version is ~1Mb jar  You need to prune it!  Unit test heavily if you make changes  Size comparison (once optimised):

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 handsets be mainstream?  O2: “2013” (O2/Telefonica are the operator most involved in NFC trials)

NOKIA HANDSETS NOKIA NFC HANDSETS

 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

 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

Case Studies

 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”

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

 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

 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…

 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

…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. Support every handset 4. Remember the entropy 5. 2D barcodes offer lower cap-ex than NFC, without the wait

Transport Finance & Banks Entitlement & Gaming Venues

• 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

 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

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

Add a comment

Related presentations

Related pages

MWC 2009 talk: Challenges Building Secure Mobile Applications

Ben Whitaker and myself gave a presentation in the App Garage of Mobile World Congress in Barcelona this year. The slides of the talk are reproduced here ...
Read more

MANET: Challenges and Applications - Villupuram

MANET: Challenges and Applications ... Building routing protocols ... Regardless of the variety of applications and the long history of mobile ad ...
Read more

Mobile Cloud Security Issues and Challenges: A Perspective

Mobile Cloud Security Issues and Challenges: ... for building the higher level applications. ... MCC to integrate mobile applications with the ...
Read more

The Challenges and Benefits of Identity and Access Management

The Challenges and Benefits of Identity and ... regulated to keep data secure. ... SaaS applications on a mobile device can be more cumbersome ...
Read more

Issues and Challenges in Mobile Security - IJETAE

Mobile applications share most of the security issues of ... they’re secure, ... These limits bring the challenges in building mobile security technology.
Read more

Building the Trusted Smart Grid: Threats, Challenges, and ...

A service that provides the ability to forecast intent and protect applications against ... Building the Trusted Smart Grid: Threats, Challenges, and ...
Read more

Building Mobile Applications With Java Using The Google ...

building mobile applications with ... expert oracle and java security programming secure oracle database applications ... ethical challenges building an ...
Read more

Guide to Securing Web Applications - Northwestern IT

Guide to Securing Web Applications. Left Navigation Additional Information Menu. ... OWASP Building Secure Web Applications and Web Services;
Read more