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