challenges building secure mobile applications
DESCRIPTION
A presentation given by Ben Whitaker and Tom Godber of Masabi at the Mobile World Congress 2009 show in Barcelona.TRANSCRIPT
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
2002
•First in-gamemicropayments
2004•First mobile viral
2006
•Playtech mobile casino
•750+ handsets
•6 languages
2007
•First certified mobile security
•3Kb EncryptME
•Award winning
2008
•Ticketing
•Money transfers
•Banking
• 20 currencies• 4 alphabets
• 2 Factor Authentication• Secure messaging• UK Rail Ticket Standard
Why isSecurityan Issuefor 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
Inherently insecure:
Used on older browsers, “Wap” settings
WAP2 SECURITY
Like the web:
Most handsetsuse this with “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 seethief’s certificate
So should be ableto 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 headerCache-Control = “no-transform"
Eg. For Apache:<FilesMatch "\.(php|cgi|pl)$">
Header append Cache-Control "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 andPseudo-Random Number Generators
Key Exchange and server authenticationAsymmetric 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)
Session Key1
Encrypt
ABCDEF
DADCCB
Session Key1
Decrypt
ABCDEF
DADCCB
Sender Receiver
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
Session Key1
Encrypt
ABCDEF
DADCCB
Sender
Session Key1
Receiver
DADCCB
DADCCA
Decrypt
ABCDEZ
DADCCA
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
Session Key1
Encrypt
ABCDEF
DADCCB
Sender
Session Key1
Receiver
MAC
ASAKFA
DADCCA
ASAKFA
Decrypt
ABCDEZ
DADCCA
ASAKFA
Check MAC
KADILSB
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
Session Key1 Session Key1
SenderReceiver
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
Public
Key1
Private Key1
Encrypt
WXYZ
ZAPLAS
Decrypt
WXYZ
ZAPLAS
Sender Receiver
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.
pRNG
Seed (4 digit pin)
User1
4510920………
Attacker1
pRNG
Seed (guess)
4510920………
User2
pRNG
Seed (934351...)
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 RealWorld
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”
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
Chiltern Railways with YourRail
Trial user feedback: “Better than the web!”
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 theno-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 & Venues
Gaming
Security
Portability
Usability
• 3rd party certified
• End-to-end
• Fast and small
• Popular handsets
• All form factors
• Fragmentation
• Offline functions
• 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
SMS “Tickets” to 89080
Auto-Install SMS
XML WebService Requests
Purchase Request and Payment Details(sent by encrypted SMS or Data from the mobile application)
Success message with content, ticket or code
Retailer Web Services
Masabi Proxy(can be hosted by
retailer)
1
2
3
4
5