Challenges Building Secure Mobile Applications
-
Upload
masabi -
Category
Technology
-
view
1.808 -
download
0
description
Transcript of Challenges Building Secure Mobile Applications
![Page 1: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/1.jpg)
Challenges Building
Secure Mobile Applications
![Page 2: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/2.jpg)
Who Are We?
Why security is an issue for mobile
Securing an insecure environment
Connecting with the real world
Case studies
![Page 3: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/3.jpg)
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
![Page 4: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/4.jpg)
Why isSecurityan Issuefor Mobile?
![Page 5: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/5.jpg)
Don’t!
GSM encryption has been broken
Attacks and data theft have occurred
![Page 6: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/6.jpg)
HTTPS =end-to-end security
Mature key infrastructure
Browser support consistent, improving
Padlock icons
Certificate display
Colour coding title bar
![Page 7: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/7.jpg)
WAP SECURITY
Inherently insecure:
Used on older browsers, “Wap” settings
WAP2 SECURITY
Like the web:
Most handsetsuse this with “Internet” settings
![Page 8: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/8.jpg)
Inconsistent UI support
Maybe you get a padlock icon
Certificate details are buried under menus
Details are not always clear
Inconsistent naming, etc
![Page 9: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/9.jpg)
Pros:
Reformat desktop-optimised pages for mobile
Cons:
Break HTTPS end-to-end security
![Page 10: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/10.jpg)
Some will ignore HTTPS
Others will insert themselves in the connection
Handset cannot verify end certificate
![Page 11: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/11.jpg)
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
![Page 12: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/12.jpg)
Transcoder’s certificate would obscure thief’s
We don’t know transcoder’s policy for flagging suspicious certs
We shouldn’t have to care!
![Page 13: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/13.jpg)
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
![Page 14: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/14.jpg)
Securing An Insecure Environment
![Page 15: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/15.jpg)
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
![Page 16: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/16.jpg)
Symmetric Session Encryption
Message Integrity Checks
Key Generation: Entropy andPseudo-Random Number Generators
Key Exchange and server authenticationAsymmetric encryption for key exchange
![Page 17: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/17.jpg)
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
![Page 18: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/18.jpg)
![Page 19: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/19.jpg)
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
![Page 20: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/20.jpg)
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
![Page 21: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/21.jpg)
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
![Page 22: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/22.jpg)
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
![Page 23: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/23.jpg)
![Page 24: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/24.jpg)
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
![Page 25: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/25.jpg)
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
![Page 26: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/26.jpg)
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
![Page 27: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/27.jpg)
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
![Page 28: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/28.jpg)
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…
![Page 29: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/29.jpg)
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
![Page 30: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/30.jpg)
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
![Page 31: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/31.jpg)
Free! Big
JavaME version is ~1Mb jar
You need to prune it!
Unit test heavily if you make changes
Size comparison (once optimised):
![Page 32: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/32.jpg)
Connecting With The RealWorld
![Page 33: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/33.jpg)
Live at London Marylebone Station
![Page 34: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/34.jpg)
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)
![Page 35: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/35.jpg)
NOKIA HANDSETS NOKIA NFC HANDSETS
![Page 36: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/36.jpg)
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
![Page 37: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/37.jpg)
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
![Page 38: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/38.jpg)
Case Studies
![Page 39: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/39.jpg)
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”
![Page 40: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/40.jpg)
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!”
![Page 41: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/41.jpg)
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
![Page 42: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/42.jpg)
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…
![Page 43: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/43.jpg)
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
![Page 44: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/44.jpg)
…and relax, we’re done!
![Page 45: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/45.jpg)
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
![Page 46: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/46.jpg)
![Page 47: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/47.jpg)
Transport Finance & Banks
Entitlement & Venues
Gaming
![Page 48: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/48.jpg)
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
![Page 49: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/49.jpg)
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
![Page 50: Challenges Building Secure Mobile Applications](https://reader033.fdocuments.us/reader033/viewer/2022051611/54b6b3bd4a7959e71f8b45d7/html5/thumbnails/50.jpg)
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