Published on February 26, 2009
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
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
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
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 ...
MANET: Challenges and Applications ... Building routing protocols ... Regardless of the variety of applications and the long history of mobile ad ...
Mobile Cloud Security Issues and Challenges: ... for building the higher level applications. ... MCC to integrate mobile applications with the ...
The Challenges and Benefits of Identity and ... regulated to keep data secure. ... SaaS applications on a mobile device can be more cumbersome ...
Mobile applications share most of the security issues of ... they’re secure, ... These limits bring the challenges in building mobile security technology.
A service that provides the ability to forecast intent and protect applications against ... Building the Trusted Smart Grid: Threats, Challenges, and ...
building mobile applications with ... expert oracle and java security programming secure oracle database applications ... ethical challenges building an ...
Guide to Securing Web Applications. Left Navigation Additional Information Menu. ... OWASP Building Secure Web Applications and Web Services;