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.

1. Challenges Building
Secure Mobile Applications

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

3. •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

4. Why is
Security
an Issue
for Mobile?

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

14. Securing
An Insecure
Environment

15.  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

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

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

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):

32. Connecting With
The Real
World

33. Live at London Marylebone Station

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)

35. NOKIA HANDSETS NOKIA NFC HANDSETS

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

38. Case
Studies

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

44. …and relax, we’re done!

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

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