This document discusses the challenges of building secure mobile applications. It covers why security is important for mobile, how to secure applications in an insecure mobile environment, and case studies of mobile security implementations. Some key points discussed include using HTTPS for end-to-end security, securing the key exchange process, ensuring strong entropy for keys, implementing message integrity checks, and supporting a wide range of mobile devices and networks.
5. Don’t!
GSM encryption has been broken
Attacks and data theft have occurred
6. HTTPS =
end-to-end security
Mature key
infrastructure
Browser support
consistent, improving
Padlock icons
Certificate display
Colour coding title bar
7. WAP SECURITY WAP2 SECURITY
Inherently insecure: Like the web:
Most handsets
Used on older browsers, use this with
“Wap” settings “Internet” settings
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. Pros:
Reformat desktop-optimised pages for
mobile
Cons:
Break HTTPS end-to-end security
10. Some will ignore HTTPS
Others will insert themselves in the
connection
Handset cannot verify end certificate
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. 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. 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
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. 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.
19. 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
20. 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
21. 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
22. 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
23.
24. 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
25. 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
26. 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
27. 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
28. 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…
29. 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
30. 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
31. Free!
Big
JavaME version is ~1Mb jar
You need to prune it!
Unit test heavily if you make changes
Size comparison (once optimised):
34. 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)
36. 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
37. 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
39. 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”
40. 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
41. 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
42. 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…
43. 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
45. 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
46.
47. Transport Finance &
Banks
Entitlement &
Gaming
Venues
48. • 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
49. 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
50. 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
Notas del editor
<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>
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