Masabi at Infosecurity Europe 2008

This week Masabi are at the Infosec show at London's Olympia demonstrating our mobile solution for secure ID jointly developed with our partner GrIDsure. If you're interested in having a chat about our work in this area or mobile encryption and security in general feel free to swing by the GrIDsure stand (No. G245) and ask for either Ben or Alex.

Ideas for Interoperability of Secure Barcode Tickets

Barcode ticket security is a growing issue (we get asked about it all the time) and there aren't any standards yet for preventing unscrupulous individuals from altering the tickets that are issued.

Barcodes are being used as a form of virtual ticket that you can print from your PC at home or show on your phone screen to gain access to airport check-in, bus tickets, train tickets, promotional coupons, to gain access to a venue or be entitled to something valuable.



What do we want to achieve?
Barcode tickets that can be used to allow a virtual transaction, such as on a PC or a mobile phone to provide an instant ticket to the customer, with which they can instantly prove entitlement at a venue.
Ideally, to get the largest acceptance of barcode tickets, the designers of venue ticket systems should be free to integrate the ticket validation in whatever hardware or software they want to, and without any onerous security requirements - that way whatever cash registers (tills/EPOS), handheld scanners or gate systems that a venue uses can be used at their convenience.

Is there a problem?
As an illustration, mobile and print-at-home barcode ticketing on the UK railways is currently limited as follows:

• Barcode tickets are only used on a few routes because they are not inter-operable from one company to another;
• The reading hardware and ticket data formats are not agreed - each route uses different standards (although reading hardware is pretty similar);
• Barcodes are only currently used for advance-purchase tickets (purchased the day before travel) because the ticket validation databases don't propagate quickly enough from the central servers to the on-train scanners to support walk-up (instant) tickets.
  

The same problems affect event tickets, gift tokens, and other uses where a more unified approach, and more secure ticket data would enable the convenience of m-ticketing to grow.

So, we need to get something in place that allows interoperability between barcode schemes, and also allows walk-up tickets to be validated without having to propagate all of the ticket databases.

Why do we need Security?
As the value of barcode entitlements go up, more people will take an interest in copying, altering, or re-generating valuable barcodes. Without the security, the ticket cannot be proof.

Why Interoperability?
When a ticket needs to be issued by one party, and checked by another party, then you need some way of the two parties being sure that the ticket is valid, paid for, and has not been altered between issue and scanning.
On public transport, some journeys swap on and off vehicles run by different companies - it is preferable that a single ticket can bought in one place and validated by each different company on the route, rather than the user having to separately purchase and show different tickets.

The data security risk is that, in most cases the ticket generator can be kept in a safe place (locked in your secure e-commerce server) but your ticket checking is distributed thinly around, at the entrances to venues, or often in a mobile devices held by bouncers or ticket-inspectors that can't be expected to keep your devices safe from unwanted attention or theft 100% of the time.

We will describe the security measures for simple (small) 1D barcodes that just contain a number, medium sized barcodes with some details and symmetric seals, right up to large 2D barcodes that contain the full details of the ticket and asymmetric cryptographic signatures to verify authenticity.

SMALL BARCODES (1D, around 12 bytes)
(images are all examples only - don't expect to scan them and get anything useful out of them)




Anti-copying using DRM (Digital Rights Management)
However you deliver a barcode, it has to be presented in a scannable format, which means that an adversary can always scan the ticket, and if they want to, change some details on the barcode and create multiple copies without DRM. People that have barcode delivery systems that use or rely on "forward lock" or DRM to prevent the barcode image being sent from one person to another are being blind to the availability of barcode scanners to beat all of their software. Also consider that OMA DRM for forward locking images downloaded to phones places laughably little protection against an assailant armed with such exotic tools as a web-browser and a text editor.

Anti-copying using a local database at the scanner
Storing the serial number of each ticket scanned, and flagging/halting duplicate scan attempts can detect the most obvious cases of a small group of users copying tickets and sharing them around. You can refuse the second use of the same ticket, and also in your back-office systems start to collate details of which user's tickets are being copied/re-used the most, and lock those users out, or mark their tickets (and future tickets) on a blacklist for 100% inspection in the future, including ID check.

Anti-Editing using Central Database
Simple (small) barcode tickets are just a serial number, and their validity is checked from a database of known tickets, which reveals all of the extra ticket detail, possibly including ID information about the legitimate user of the ticket which might be checked in high value situations.

The problem of this approach is that your ticket checking systems must have up-to-date access to the ticket database. This is fine if all of your tickets are sold many hours in advance, and your local ticket validating system has had time and connectivity to synchronise it's local database with the ticket selling server, but is far less use when people are buying tickets immediately before use, or when your ticket database is too big for your portable ticket checking devices to download and store, or if one ticket vendor doesn't want to give copies of all of their tickets to every single ticket checking agent, because one of the agents may just sell them on!

Live Check Speed and reliability issue:
If you design a ticket checking system that relies on the scanners being connected to the internet, to access a central database to check every ticket, then you may get issues with speed of checking tickets, and therefore the throughput of your entry systems. Especially if you have to check tickets underground or on a moving vehicle.
Additionally, your whole system could become useless from a single point of failure or connection. A huge factor in the design of the Oyster smartcard transport system for London was to make sure that each station could continue to check tickets in milliseconds, even if disconnected or when connectivity was slow. Otherwise any unforeseen issue with central servers or internet connections could bring millions of Londoners to a grinding halt during business rush hour - an expensive and potentially pin-stripe and bowler-hat riot inducing situation, if you are unfamiliar with London!

Offline Ticket Checking
If you can put all of the details of the ticket into a medium or larger barcode, then an offline system can scan the ticket, and instantly know what the entitlement is without the need to access a database. Trouble is, you need to make sure that the ticket is genuine, and not adjusted. There are two major ways to do this:

MEDIUM BARCODES (2D, around 42 bytes, ~27pixel square)

These not only contain the ticket serial number, but can also contain brief details about what the ticket entitles, such as destination, price paid, and valid date, and possibly even some very brief ID information, such as the last 4 digits of the credit card used to purchase the ticket, which could be checked against the user to make sure they are the valid ticket holder.

Anti-Editing using Symmetric Cryptography.
If your ticket issuing server and your ticket checking systems all share a secret symmetric key (symmetric means that all parties use the same key) then the contents of the medium barcode can be encrypted using the secret key. You can either encrypt and hide the contents, or leave the contents in clear text and add a small amount of the encrypted version at the end, as a "seal" or "signature" that can be verified by the scanner. Were an attacker to change the plain text bit of the ticket (such as the date) then after scanning the verifying scanner can encrypt the new plain text, and compare the new encrypted seal with the previous seal in the barcode, and detect an alteration, and can now reject the barcode as a forgery. The moment we can "seal" the contents of the barcode, it means that we can also add customer ID information to the barcode so that a validating agent can check that the correct user is gaining access.

Example format:
sellerIdentifier + ticketNumber + ticketDetails + CMAC
(CMAC is a small message authentication code, around 4 to 16 bytes long, created from the text of the message with a symmetric cryptographic function, using a secret key known only to the ticket seller, and ticket validators)
Suggested encryption scheme: AES 256 based CMAC.

Benefits: doesn't add much data - adding a symmetric seal to the end of a ticket can be done in very little space (you can just put a small portion of the encrypted or hashed version of the ticket into the seal and still provide strong protection) You can even send these medium barcodes in an SMS picture message (not MMS or WAP).

Problems: If a symmetric key is discovered by a thief, they can create and adjust tickets. This becomes quite likely as you have to give every ticket validator copies of every single symmetric key in use, so that they can check tickets. If one piece of ticket validating equipment is stolen, or compromised by a virus, or sold to criminals, then it can reveal the symmetric keys.

The ITSO ticket system makes it difficult for a thief to retrieve keys from stolen equipment by protecting the keys in a smart-card "Secure Module", and closely controlling the development of hardware that works with the smartcard. However, you can only use special hardware and software that is certified for use with ITSO, which increases the costs of integrating new ticketing systems, and expanding ticket reading options. Some organisations resist adopting ITSO ticketing due to the added cost and reduced flexibility (Oyster isn't compatible for one). Even if a symmetric key system doesn't use ITSO, it would need some hardware or cunning protocol to protect against leaking of keys. The big problem is that it would be impossible to detect which agent was losing keys, so if there were business losses, it would be difficult to assign responsibility.

LARGE BARCODES (2D, around 128bytes, ~41pixel square)



These tickets can contain all of the information about the ticket, including detailed ID information, multiple travellers, terms of the ticket, and details about the purchase history and multiple entitlements such as multi-part journeys, reserved seating etc. Some draft standards for Airline tickets and Train tickets require data payloads as large as this for full e-tickets.

Anti-Editing using Asymmetric Cryptography
Modern internet systems use Asymmetric cryptography for just about every secure transaction you do on-line.
Asymmetric encryption is often called Public/Private key cryptography, and means that the two parties use different keys - one of which is kept secret at the server, for creating and signing tickets, but the Public half of the key for validating the tickets can be freely given away (even to your enemies).

Benefits: The public keys, and instructions for their use can be freely distributed to ticket validators, friends, and enemies, for checking the validity of tickets. It means that open source ticket checking software can be made available to allow quicker integration of new scanning systems, and greater flexibility of providers.

Each Ticket issuing party can have their own private key, and give away their public key on a public website for all ticket validators to download and use. The keys would not need to be updated, unless one was stolen, or completely new providers appeared.

If one of the Private keys was lost, through virus, hacking, theft, or deliberate fraudulent activity, then the only new tickets that a thief could create would be from that one ticket issuing source, and that ticket issuer could be held financially liable for fraudulent tickets, without other members of the scheme being affected.

Suggested usage: football tickets or Olympic tickets - these may be sold in many places, and need to be checked in multiple locations, by different organisations. In some cases it may be advantageous for a ticket to entitle certain linked items, such as reductions on food in the olympic village for certain guests. You would need the ticket to be checkable by a food vendor, but you wouldn't necessarily want to equip every vendor with an ITSO hardware module or a large database of tickets. However, if you could provide open software and public keys, then EPOS integrators, mobile phones, and all manner of cheaper scanners could perform scanning and validation of the global ticket without reducing the security of the ticket.

Simple Format of the data inside the barcode:
sellerIdentifier + ticketSerialNumber + ticketDetailsEncryptedBySellersPrivateKey
Suggested Asymmetric encryption standard: 1024bit RSA with PKCS#1

Drawbacks: Asymmetric cryptography creates larger signatures than the symmetric cryptography, and therefore requires larger barcodes to contain them. Some much older (black and white) mobile phones wouldn't be able to display the larger barcodes. However, for walk-up tickets on paper or the modern phones this would not be an issue. You could display these on a mobile which supported MMS or WAP or Java based ticket delivery.

What about ECC instead of RSA?
ECC based Asymmetric encryption could probably be used too, even on the medium sized 40 byte barcodes, but there aren't such clear standards for message encrypt/decrypt with ECC quite yet - we'd be keen to explore this further.

Common Misconception: Small devices haven't got the processing power to cope with Asymmetric Encryption - this is simply not true.
Phones displaying a barcode don't have to process the encryption at all, and phones or PDA's checking the code can do so easily with modern methods. An ancient black-and-white Nokia 6310i could check an 1024bit RSA encrypted barcode in 1 second, a modern mobile phone or PDA could check the code in less than 1/100th of a second. ECC is roughly equivalent to RSA in speed for small keys, and gets faster than the equivalent RSA key as they get bigger.


Suggestion: 2 approaches:
Legacy phones: Use MEDIUM barcodes, which have to be live-checked when being validated in an inter-operator way. Slower, but the only way to use the smaller ticket format without the security issues of having to give away all of your tickets or all of your private keys to third parties.
A standard web-services server interface should be agreed so that one ticket validator can query the validity of a ticket from the Ticket Issuer's database in a standard way.
Operators that trust each other could share secret keys and mirror databases to speed up ticket validation and allow off-line checking, as long as security steps have been taken to help prevent staff leaking keys and ticket databases.

Newer Phones and Print at Home: Use LARGE barcodes with Asymmetric encryption. This allows walk-up tickets to be sold and instantly verified by open standard scanning hardware, even with no database connectivity or secret key distribution.


Less Critical: 2D Barcode Format:
Datamatrix, QR Code and Aztec are all suitable.
Datamatrix is more freely available and has more scanners available, so if it was adopted there would be more choice for providers of scanning hardware. (More choice usually leads to cheaper and lighter hardware.)
Aztec can cope better when there's less whitespace around the barcode, which Datamatrix needs.

We've seen plenty of scanners that read Datamatrix and QR, but fewer that handle Aztec.
Every Aztec scanner reads Datamatrix and QR, and the same data format can be contained in all barcodes, and in most cases the hardware in the scanner makes the difference between one format and the other transparent anyway, as long as the scanner supports the rarer Aztec.

We would go for Datamatrix, but the internal data format and the security model behind it is the most important thing to standardise at this point.


If you are interested in Barcode tickets, please comment on this thread, especially the following:

• Can people agree to inter-operate barcode tickets?
• Is the ability to off-line check not as important in the connected world?
• Are the large format barcodes that we talk about too big?
• Should we link virtual tickets to physical smartcards?
• Should we all publish our barcode ticket formats each time we launch mobile ticketing, so that other similar providers can easily copy them, to make sharing barcode systems easier in the future?
• Have you had experience that one barcode symbology is MUCH better than the others for scanning success from the mobile?
  
• What ECC (Elliptic Curves Cryptography) standard would you suggest to use Asymmetric encryption in MEDIUM 40byte barcodes? And how much data payload data could fit inside?
  

Did the NSA put a back door in our Mobile Security? (and more about bad random number generators)

After the recent discovery of a potential back-door in a NIST approved random number generator, I thought it would be timely to state clearly that we do not use the generator scheme involved, but a more straightforward AES based random number generator, which does not fall prey to the suspicious curves.

Why do we care about random number generators anyway?

For the encryption newbie: Quick Summary of key exchange to set up a secure session, using random number, and asymmetric encryption:

1. Generate a Big Random Number on the phone, that becomes your symmetric session key
   
   
2. Encrypt that secret session key using slow Asymmetric Encryption like RSA (using the server's public key that the mobile application already has, and we are quite happy for the attacker to know too)
   
   
3. Send the asymmetric encrypted session key over the public network to the server
   
   
4. Only the server with the private asymmetric server key can decrypt the data and read the secret session key
   
   
5. Secure session continues with fast symmetric encryption like AES using the shared secret session key in both directions.

If the attacker can guess what big random number you created at step 1, they can jump straight in to read everything at step 5.

The vulnerability in the news story above is that whoever knows the secrets to the elliptic curves that underpin that particular random number generator might be able to guess the sequence of random numbers it will generate more easily (mathematically quicker) than should be possible for a normal attacker.

This posting will not say anything more about that specific (possibly deliberate) vulnerability, but instead look at situations where developers inadvertently put much worse weaknesses in their security systems which allow attackers to beat your system as if they had a similar back door, which you accidentally left wide open, accompanied by big flashing neon signs that say "hackers enter here".

The Random Issue

All cryptography relies on a good source of randomness, and it is very important for system designers and security evaluators to understand that although they may have thought hard about how many bits long their keys are, all of their fancy cryptography is worth nothing if they haven't built it on top of a good random number.

WAKEUP CALL: If you build a 128 bit key from 8 bits of un-guessable randomness, you have a system with an effective security key strength of only 8 bits.

Pseudo Random Number Generators
Just having an approved Secure Random Number Generator is not enough, you need to seed (initialise) the generator with some real randomness (entropy) otherwise the secure random will be predictable. This is because all secure random number generators are actually PSEUDO-random number generators, and will produce exactly the same sequence of numbers from an identical seed. They have to work this way so that they can be properly tested and profiled to avoid generating patterns in the sequence output that could reveal something about the source seed (that is, that they are one way functions which don't create repeating patterns). In layman's terms, it means that the seed must be from something really random, and then your pseudo random number generator can get on with producing a nice continuous stream of apparently random numbers, suitable for cryptography.

What's a good seed?
One of the common forms of cryptographic attack (after fooling people) is "side channel attack" where an attacker observers some external aspect of the client system and uses that to guess the keys or data. In this case they can ignore the algorithms in use, and just second guess the seeding of the random number generator (RNG), which then gives them the session key.

It's easy to see why - the default Java implementation of secure random "seeds" it's RNG from the system time when it was started - so to guess the session key in use during an encrypted session, you simply guess (roughly) when that program's RNG was started (usually a few hundred milliseconds before the first network connection) and throw all the times around that through an identical RNG algorithm until one of the generated keys works. This would allow you to guess a 256 bit key in only 9 bits worth of attempts (effectively reducing the key strength to 9 bits, therefore easily brute-forcible). It turns out that since Java 5 the default seed implementation also adds a counter to the current system time, but that doesn't really represent a real attacker-defeating source of entropy!

Q: "We run a maths loop thousands of times and take the processing time and free memory differences from that to make the random seed, will that do?"

"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin.'' von Neumann

On mobile you cannot run a "futile cycle" to generate random times and memory usage like you do on a PC, as many handset operating systems are so simple that they run completely uniformly (the same every time) in most cases.
We profiled all common phones during thousands of program startup cycles, and found that on some Nokias, for example, you could load a hundred images and do all sorts of other things in memory and it would take the same number of milliseconds, (+/- 10ms) every time, so even if you "stirred" your RNG with the timing, memory, or results of your startup, it would be something that an attacker could also copy, and just use that as a known quantity in their "guessing". On top-end Symbian handsets you can get better access to microphone, screen coordinates, less uniform performance from the multi-tasking OS etc, but on standard MIDP phones it is all far too predictable to be a reliable source of entropy.

Side Note: Reverse Compiling Java:
Mobile Java is very straightforward to reverse-compile (getting the original source), so you have to start your analysis by assuming that a committed attacker can completely understand, and make use of your own code against you. All of the worst case scenarios that we are guarding against assume that the attacker has full knowledge of what the developer is doing, and could perform quite advanced profiling of how it performs on each handset, or just target a particularly vulnerable handset.

This may sound like a very long winded process, but the attacker may have been quite highly funded by criminal gangs or antagonistic Government agencies to break your security, or worse, they might just be a bored academic that likes a challenge.

Solution:
You have to rely on the USER for a true source of randomness.

Some PC security programs get the user to wiggle a mouse or speak into a microphone before they generate your keys - this is all about seeding. Get the mobile user to press buttons, or interact in some way, such as playing a game. This is the only way to get a good seed on many handsets.

The exact times of keypresses are one good source of some randomness. But you must first figure out how much true entropy you get on each handset from this. More handset profiling is required.

Clock Granularity - why the mobile cryptographer would care:
Many handsets give time in milliseconds, but only have a clock granularity (minimum reported time difference) of around 25ms. If someone is banging random keys, an attacker may guess the presses are occurring roughly each second, so the variation that they can't guess is going to be less than about half a second, varying by say 15 actual reported clock intervals (375ms). So we might only get 4 bits of randomness in the time. If they are hitting random buttons, on a 10 button keypad, the value of the key pressed is another 3 bits, and the key release time about another 1 bit of uncertainly. You can throw in the free memory at the time of keypress too if you like, which in the worst case may vary in a fixed way according to the timing of keypresses, so I'll not give myself any new uncertainty for that as you have to always consider the worst case.

So if I want to generate a 128 bit random key, and I get roughly 8 bits of un-guessable entropy from each user keystroke (if they are banging the keys to give me randomness) then they will have to hit at least 16 keys to be sure. (and there will be plenty of people that will argue for less bits of entropy per keystroke, and demand 20 keys hit, so we usually go for 20 as our minimum).

On newer phones you could get entropy from the tilt sensor, or record sounds and background noise from the microphone, but we have to make sure that there's a workable solution for even the most basic MIDP1 phones that only provide user keyboard input.

Some developers use the IMEI or other phone properties as an extra bit of information to throw into the random seed - by all means add this, but don't assume that this would be impossible for an attacker to find either from a browser HTTP header (Nokia S60 phones add the IMEI here) or by installing a second application that simply asks for the same properties (similar to the attacks on XP and BSD random seed pools); adding this doesn't increase your worst case entropy count.

Good Examples:

• Playtech Mobile Casino - (written by Masabi) these games get the user to press random keys to seed the RNG, and also use the keystroke timings during fun-games (which run without secure networking) to collect seed information, and will only make a secure connection once enough seed information is collected. An entropy counter clocks up the number of user generated events, and only allows secure networking when enough have occurred.
  
  
• Opera Mini Advanced - the secure versions of opera mini get the users to press random keys to seed their random number generator before making secure connections - good on you Opera!
  

Bad Examples:

There are plenty of "Secure" mobile applications that don't practice safe seeding, and are open to RNG guessing attacks. It could be that they have some other hidden source of randomness that none of the rest of the computer scientists in the world have thought of, but I doubt it.

If you are using a secure mobile app, especially on MIDP1, and you get a secure connection without pressing at least 16 buttons first, then chances are your connection is vulnerable to attack, and someone getting into your session in under 1000 guesses.
It's also a first sign that the application developer may not have had anyone skilled and independent truly analyse their security, because it would be the first thing spotted by a security professional or white-hat hacker, simply by looking at the finished product, and before viewing a single line of code.... there could be other mistakes too.

Another Bad (and common) approach:
No Random Number Generation, No Key Exchange
It is difficult to build both an Asymmetric and Symmetric encryption systems small and fast enough to use on mobile devices, and we've noticed that some secure mobile products don't bother with it at all, and just implement a Symmetric cipher alone, like RC4, 3DES or AES, and pre-share a symmetric encryption key through some other corner cutting technique.

Common bad key-sharing tricks: (we've seen these in live systems)

1. Building the key material into the application JAD or JAR file prior to install.
   PROBLEM: The JAD and JAR are transmitted in the clear, and however obscured the key material is, it would be possible for an attacker to retrieve that key material from observed network data during install.
   
   
2. Using customer data entered on the mobile device (username, account numbers, DOB) as key material, as this is also known to the central server.
   PROBLEM: much of this data would also be known or discoverable by the attacker.
   
   
3. Sending an "Activation code" via a second channel for the user to type in to Activate the secure connection, and using that activation code as the seed or key material
   PROBLEM: building a 128 bit key from a 4 digit activation code represents a key strength of only 13 bits, far too weak to secure financial transactions that should be protected by at least 128 bits of effective cryptographic key strength (requiring an activation code of 39 digits length). Also if you are using 3DES your effective bitstrength is only 2/3 of the total number of bits of key material, so a 3DES system based on 14 bits of unknown key data may only present a 9 bit problem for an attacker to brute-force, possibly requiring the raw unadulterated processing power of a 1980's pocket calculator for a second or two.
   

So, after all that, we're not really scared that the US Government has a back door implanted into the publicly known and widely investigated algorithms that we use; but more importantly I hope we've looked carefully enough at our handling of random numbers and key exchange to make sure that we haven't inadvertently left another back door open for the attentive hacker to exploit.

However, it does seem that some vendors are still leaving these vulnerabilities in their systems by design - I hope that this all gets brought into line soon so that as an industry we don't make mistakes that could earn mobile commerce a bad reputation with the public before we've even truly got started!

Two Factor Authentication (2FA) - Opportunity and Pitfalls

In this post I will describe the need for Two Factor Authentication (2FA), the problems with existing 2FA, , and some of the emerging approaches to introduce stronger authentication methods - in particular, the opportunity to use mobile technology to avoid the hardware costs and introduce much stronger two channel protection.

Some people might start by asking why 2FA is needed in the first place?
Put simply it's too easy for attackers to steal usernames and passwords on the web, and back in the real world it's easy to steal your keys or cards (entry cards or credit cards). The whole point of 2FA is "something you have and something you know" where the card or one-time-password generating token is what you "have", and your PIN/username/password is what you "know". Therefore in theory a thief will have to succeed in both the real world, and the digital world to defeat the authorisation check.

There are three main problems with existing 2FA solutions: Vulnerability to Attack, Expense and Cumbersome Implementations.

Vulnerable to Attack

All systems can be attacked, but the important consideration is how easily they can be attacked successfully. Alas, standard 2FA is all too vulnerable to simple attacks.

For example simple attacks on the most common form of 2FA, the ATM Card and PIN, tend to be based on copying or stealing the physical card after watching the PIN being typed, either with a hidden camera or a real person (shoulder-surfer). We aren't just scare-mongering, Card Fraud has soared in the UK since the introduction of Chip and Pin, but actual numbers are hard to come by as UK card operators charge back the merchants for fraud, and don't bear or report the total loss centrally.
This style of attack works just as well against door entry systems using keys/cards/RFID that are associated with a PIN.

Aside: Copying Chip and PIN cards

Copying cards should be more difficult than it currently is, but unfortunately there are two major vulnerabilities:

1. The Smart-Cards still mix all of the old and new card identifiers on one card, including the raised card number and owner name, and also the magnetic stripe which are child's play to clone.
2. Some Chip and Pin implementations use offline checking and a weak cryptographic process which make the card chips easier to clone than they should be, such as cards in France.

Further reading:

• Ross Anderson Phish and Chips
• Chip and Spin
• Cambridge University
• Guardian Newspaper
• Light Blue Touchpaper security blog
• Physical bait and switch with full smartcards: Two chip and pin cards, swapping their transactions.

OTP Attacks

Attacks on the logins protected by One-Time-Password (OTP) devices are equally simple. The key-fob - a device that generates a sequence of numbers that change every few minutes - is considered the physical "something you have" component in 2FA, to go with your password which is "something you know". The best known is the RSA SecureID key-fob style token used to protect corporate VPN logins and some Bank logins.

This can be attacked in a similar way to simple "one factor" password systems with one twist: the Man-in-the-middle or key-logger attacker must use the stolen details immediately, rather than at his leisure. The recent ABN Amro and Citibank attacks used this method
(see Phishers break ABN Amro's 2FA protected Web Banking).

Aside: Man-In-The Middle attacks are simpler than you may at first think

An attacked simply has to:

1. Set up a free WiFi hotspot in the middle of a city or airport;
2. Use a virus to adjust their "hosts" file;
3. Hack any DNS server (when was the last time you checked your home ADSL router, or the one at your hotel? Would you even know if it was compromised?)

Once this is achieved the attacker can redirect users to whatever site they want. This will go undetected as long as the attacker relays almost all pages perfectly to the victim, only stepping in when they log into a bank or corporate site. At that point the attacker makes the login with the user's details (including whatever One Time Passcode they entered), whilst showing the user a "sorry come back in 30 mins" page; the attacker can then do whatever they like, maybe invalidating the login credentials when they leave to make it harder for the user to realise what had happened.

Some 2FA devices, such as the Barclays Card-Reader device, introduce challenge/response codes where a code is shown to the user to type into their card reader, along with their pin, so that their card can "sign" the transaction to authorise it.

However these systems are also ready victims to a Man-In-the-Middle attack where a "bait and switch" is performed, just like the physical card attack described above. The attacker shows you web pages that describe the victim's intended transaction, but actually the attacker is performing another. When the attacker is given the challenge code for their criminal purchase, they simply relay it to the victim who dutifully responds with the correct response, however many pins/cards/steps they have taken to process the challenge. The problem is that when the user types in the code to sign, they have no idea what transaction they are really signing.

Expensive and Cumbersome

The hardware key-fob or card reader devices introduced by RSA, Barclays and others are usually fixed lifetime devices that are a burden for customers to keep with them at all times. Some have a planned lifespan of only two years, yet anecdotal evidence presented to me was that over 20% of secure tokens were washed, broken or lost before their natural end.
Additionally, as you increase the number of systems that you want to protect, the number of hardware devices presents an ever greater burden on the end user.

To get around the expense and inconvenience of Hardware Tokens, new Software tokens have been developed which can be used from USB key-fobs, PDAs or Mobile Phones.

One problem with these soft-tokens is that they are often run on untrusted devices at the edge of, or beyond, any corporate security controls. The most vulnerable tokens are those on readily attacked platforms like the USB sticks and PDAs and smart-phones (eg. running the Symbian, Linux or Windows Mobile OSs) that can fall victim to viruses.

Aside: Mobile Java Security

Standard phones which are not running a smartphone OS like Symbian, Linux or Windows Mobile are very resistant to viruses. Most can run Java programs, but each program is run in a restrictive "Sandbox" which prevents the program from accessing the files or memory of another program or accessing the hardware of the device in the uncontrolled way that C or machine code programs can. In fact, one of the main reasons that Java was chosen as the language to use on phones was that it's sandbox would help prevent bad or faulty programs from affecting the normal call and message functions of the phone. One day someone might find ways to make a practical virus on these devices, but it has not yet been shown.

The key vulnerability of mobile Java programs is that if an attacker persuades the user to install a new hacked version of an application over the top of a previous application, the hacked version can (if the user permits it) gain access to any data previously stored on the device by the first program, such as the secret seed to the time-sync service that runs the One Time Password Generator, or any other secret part of the OTP/2FA service on the phone. To prevent this happening on the latest handsets you can digitally sign the application to prevent an attacker from overwriting your application, but there are many serious problems with digitally signing applications related to root certificate issues on handsets as noted in a previous blog posting.

Two Channel Protection

Two factor is a good start, but if you are performing challenge-response through just one channel you leave yourself open to hijack or bait-and-switch on that single channel. One approach to improving transaction protection is to perform part of the process through a second channel, where the second channel uses a different trust system and repeats the details of the proposed transaction to the user, so that they can be sure that they are not being tricked.

Mobiles have been used as the second factor already, providing "Soft Tokens" to replace the simple RSA SecureID Tokens, but as simple OTP generators they are just as vulnerable to MiM, if not more so, as they are frequently stolen. However - mobile phones offer the potential to introduce a second channel to the transaction. You can send the transaction details through an encrypted SMS or encrypted GPRS/3G connection, along with part of the transaction authorisation key. The phone will be communicating using a different network, so any virus, local DNS attack, or dodgy WiFi access point will not compromise its security.

Please note: until now this article has been product-neutral - this example is one we've built, so stop reading now if you're likely to complain about product pitches! However we think it's rather natty, and the best way we can think of doing transaction auth!

Masabi have built a Two Factor, Two Channel Auth system in partnership with GrIDsure, which provides standard off-line time-synchronised OTP generation for logins and low value transactions and secure two channel authentication for more sensitive transactions. For example when adding a new payment recipient to an on-line bank account, the system sends an encrypted SMS message to the user's phone which wakes up the app and shows the user the details of the transaction, before showing the OTP to authorise that transaction. As the transaction details are encrypted with the private key of the card issuer they cannot be adjusted by a man-in-the-middle. The user is also given the option to report a transaction as fraudulent if they had no previous knowledge of the transaction, or the details of the transaction differ between the two channels, thus revealing MiM or bait-and-switch attacks.

The extra twist to this GrIDsure system is that the presentation of the OTP to the user does not give away the actual code or PIN to an attacker or phone thief. The OTP numbers are shown hidden within a grid and the user selects the correct auth code from a secret pattern (PIP) shared between the user and the card issuer, rather than a shared PIN. Because of duplication of the numbers on the grid an attacker or pin thief has to see both the phone and the characters typed into the computer or ATM for many transactions to learn the shared pattern. The user never types the code into the same device that shows the Grid so that only compromising both devices for several transactions will reveal the relationship between grid and code.

This means that the user can use a compromised ATM, Chip&PIN, virus-ridden PC or tell an auth code to a phone operator without revealing their secret pattern.

Full details of our Mobile Two Factor Two Channel system will be published on 4th October on this page.

Other Two Channel Systems

An alternative two channel (or "out of band") system is being promoted by Authentify which calls up the user to confirm large purchases using a normal voice call. We tried their demo and were slightly surprised to find that the voice call did not repeat the transaction details, leaving it open to MiM or bait-and-switch attack, but I'm sure they could improve that with a little development time. Authentify's solution does not really allow the user to detect MiM if the calls are being re-routed, but otherwise their solution is a good step in the right direction.

Also Cronto are using on-screen barcodes to transfer the encrypted transaction details and one time passcode to the user from the merchant or bank website. It relies on the phone having application access to a camera, and they've got to get the cryptography right to prevent a malicious website from adjusting the contents of the barcode, but it's another example of thinking in the right direction.

2FA demo in Cambridge on Wed 5th Sep

Two Factor Authentication systems have come under fire recently from hackers and researchers for a number of drawbacks and vulnerabilities:

1. Man-in-the-middle attacks are being successfully used against Banks using 2FA
2. Reports of more than 20% of Hardware tags are lost or broken
3. Expensive - and cumbersome for consumers
   
4. PIN codes can still be stolen by phishers, or Shoulder-surfers/cameras

In conjunction with GrIDsure, we have developed a mobile 2FA system which addresses these issues and has the following benefits:

1. Resistant to Man-in-the-middle
2. No additional Hardware
3. Resistant to PIN theft
4. Resistant to keyloggers/viruses/cameras/people watching the mobile or the PC
5. Many times stronger than PIN
6. Fraud Reactive
7. Still protects several transactions even if your phone AND your PC are compromised (I haven't heard of many systems that can claim that)
   
8. Simple and convenient, even 7 year old children can use it

We will be at the Cambridge Enterprise Conference on Wednesday 3rd September, along with GrIDsure, demonstrating Two Factor and Two Channel protection of purchases and logins that are suitable for protecting ATMs, Door entry, E-Commerce, VPN logins, On-Line Banking and more. Come along and see us if you are in the area. (previous live demonstration given at Mobile Monday )

We will post screenshots and a full description of the technology next month.

Problems with Mobile Security #1

Mobile ticketing, m-commerce, secure messaging, corporate applications, government communications, e-money, the list goes on of things that would be great to do on mobile - as long as they really were secure.

So, security on our phones, and we'd like to use publicly endorsed standards - 10 out of 10 security experts prefer it and describe any non-standard (proprietary) security as "Snake-Oil".

Q: HTTPS/SSL is used for e-commerce everywhere, why not use it for mobile-commerce?

A: a number of issues make it impractical for mass-market mobile use:

1. Not available on all phones
   MIDP1 phones don't support SSL connections. MIDP1 represents fewer than half of the JAVA enabled phones in circulation in the West, but a significant number and a greater proportion in the developing world where used handsets are popular. To develop systems that won't run on these handsets is to needlessly cut down your potential user-base.
   
   
2. Out of Date Symmetric Ciphers
   Some handsets have built in HTTPS/SSL for their browsers and many handsets use the easiest to develop, and alas the oldest ciphers in their SSL/HTTPS. Some of these ciphers have known vulnerabilities, and should not be added to new systems, for example RC4. US Govt CERT Advisory: SSL/RC4 passwords easily crackable; solution: Do not use RC4 encryption.
   This is alarming as most mobile browsers which have SSH/HTTPS only use RC4. Try connecting to your bank, and look at the page/connection security details, and I'll bet it says that you are using RC4. It should be retired, not built into brand new systems.
   "RC4 encryption algorithm is not a Federal Information Processing (FIPS) standard and probably won't ever be because network professionals see RC4 as rather weak in terms of message authentication and integrity." - William Burr of NIST
   
   
3. Only secures TCP data
   The built in SSL/HTTPS cannot be used to add encryption to locally stored data, SMS, MMS, Bluetooth, IrDA or any other connections used by the mobile device, so anything you are doing on these channels is in the clear. This non-TCP data is important because many users don't always have the correct data settings for java networking, or know how to use them, and you can greatly help them by being able to "fall-back" to encrypted SMS to make your purchase, as you will find in our latest apps. We will cover networking issues in a later blog post. Also people have attacked and opened the RMS data stores on phones, so your stored details are not safe unless you have taken extra steps beyond standard MIDP behaviour.
   
   
4. Certificate Problems
   Many handsets don't have a full complement of root certification authority certificates installed. This means that your HTTPS server certificate will often not be recognised as a properly authenticated cert (throwing worrying messages to the user, and completely voiding the trust relationships that make SSL/HTTPS useful), and the phone will NOT CONNECT AT ALL to your server from Java as invalid and self-signed certificate warnings are not fed to the user when the connection is made. For example one of our test applications was unable to connect to the major and popular London Underground Oyster site, or the Barclays bank websites on most Nokias, because of certificate issues.
   It is impossible on almost all handsets to install any new certificates, so regardless of the technical abilities of your users or support teams you will not be able to overcome this issue; the FAQ site for Opera mini also acknowledges this issue.
   One final confusion: the original phone model from the handset manufacturer may have contained a valid Verisign or Thawte root cert, but sometimes the mobile network operator will remove that and put in their own certificates instead at the customisation stage, so you can't reliably know what certs are installed even if you are sure which model of handset you are talking to.
   


5. Slow to initiate
   HTTPS and SSL require several connections to establish a secure session. On a fast PC network with low ping times this isn't much of a problem as the amount of data sent is tiny. However on a phone with two second ping times, commonly up to six seconds, each connection (regardless of amount of data) takes serious time to travel to the server and back. On many handsets the cryptography required on the handset side can also cause delays - in our experience up to eight seconds on the encryption alone, even on a recent MIDP2 Nokia.
   
   


6. Vulnerabilities in WTLS/Secure WAP - also not end-to-end
   Most handsets implement WTLS (Wireless Transport Layer Security protocol). This is similar in intent to SSL, but with some bits chopped out to make it easier for phones to use with their limited memory and small CPU. Once the data gets to the WAP gateway it is decrypted and then re-encrypted into an SSL/HTTPS session to the destination server on the internet.
   Unfortunately the protocol allows the use of very weak, or no encryption at all between the phone and the WAP gateway. There are several known cryptographic attacks on WTLS too, detailed here.
   Worse, the data is all in plaintext within the WAP gateway i.e. this does not constitute end-to-end encryption - it relies on network engineers not to read or sell your data, unknown 3rd parties to maintain the server security, and defend the WAP gateway from compromise.
   
   The risks of leaving your data in plaintext at the WAP gateway (or anywhere inside the mobile network) are wonderfully demonstrated by the recent revelations that hackers have gone undetected inside mobile networks for years - see stories of accidental discovery of long term hackers in Vodafone Greece and T-Mobile, and also of network engineers snooping at user data passing through their systems for romantic reasons.
   
   [Open question to readers, because I'm suspicious but not sure: when using the default WAP Gateway, not an Internet Gateway, for your mobile data connection, are you able to use full end-to-end HTTPS or does the WAP/UDP protocol drag everything down to WTLS? If it did, all your WAP based banking may well be clear-text in the Wap gateway.]
   

Q: What about Opera Mini - the advanced one for MIDP2 that has some security built in, can't we just do e-commerce through that?

A: It's not end-to-end encrypted - so you have to trust Opera's engineers, servers, sysadmins and maintenance contractors with your plain-text passwords and credit cards. Again they chose to use the RC4 cipher of all things, which should be retired, not built into new products.
In good news though, they do seed their Random Number Generator correctly, which is disappointingly rare in mobile security.


Q: What about SMS - internet based hackers can't see them, as they are all in the Mobile Network Operator's walled gardens?

A: Same problems as WTLS, because network engineers, 3rd party service technicians, servers, and base stations in the Mobile Networks are not policed to PCI DSS standards (required for sending/processing credit cards).
Additionally an SMS may not just be going through the UK networks that have familiar brand names. SMS's are often transferred internationally across the Wild Wild Web through various companies that you have never heard of, and may originate or terminate in some very odd countries where you wouldn't dream of leaving your credit card.
The infamous case of bored network engineers poking through other people's MMS pictures of naked girlfriends (and forwarding them on) is nothing compared to what may happen when and if large amounts of credit card data start to get sent through SMS messages. After the case of O2 engineers abusing their access to SMS messages, analysts Gartner said "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".
If I was thinking like a hacker or spy, the first thing I would do is place logging hardware in a few base-stations, which see plenty of data passing through them. Lawyers, government ministers and top business people leak enough valuable information without throwing credit cards into the mix. It should also be pointed out that it is child's play to fake the sender number of an SMS.


Q: What about the open source Bouncy Castle Light Crypto Libraries?

A: A jolly good start, but they're not THAT light. Adding a simple security system using Bouncy Castle with Asymmetric Key exchange, a Symmetric session cipher and a Random Number Generator (the bare minimum for secure comms) adds over 22Kb to the basic app, even after you've stripped unused code and obfuscated it. With the very oldest handsets having JAR size limits of 29Kb - such as the Nokia 6310i, which despite its age is still very popular, people clinging to it like limpets and some major companies still issuing them NEW to their executives (we learned in a recent meeting). Common MIDP1 handsets have 64Kb limits - Playtech saw more than 1 in 10 downloads go to these handsets in the first half of 2007, a substantial market share. Most of the work in mobile dev is making things small, and use as little memory as possible, so that you've got plenty of room for pictures and text and all that code that needs to glue it all together smoothly.

---

What a moaning session! I do apologise, but there's no point beating about the bush.

Solution: (a suggestion, not the only solution)

To reliably create encrypted sessions from mobile you have to build a truly lightweight encryption/decryption system into your applications. This allows you to support every possible phone and also control the choice of cipher, the encryption strength, and eliminate certificate incompatibilities. It also allows you to encrypt data stored on the handset, SMS messages, or communication on other channels, which HTTPS and SSH do not.

This is why Masabi built EncryptME, a 3KB security component for J2ME that allows all phones to make encrypted connections over SMS, GPRS, WiFi or just about anything else. EncryptME is also US Government verified and certified, so you don't have to take the our word for it that it does what it says on the tin. It provides 1024bit RSA, 256bit AES and an approved RNG, if you were wondering.

Additionally, by being standards compliant you can continue to use standard server cryptography components, for example those from Sun, Microsoft or our friends Bouncy Castle. Even against phones with built in SSL/HTTPS, EncryptME is between 6 and 20 times faster on a mobile in live tests.

And good choice of algorithms isn't enough! You must use them in a wise way with user education, good seeding, padding, key management, and protection against replays, insertions, concatenations, man in the middle, phishing and all manner of other attacks that cryptography alone will not solve - but that's another story, to be entitled "When good crypto goes bad".

Good Examples:

• Opera Mini Advanced: MIDP2 only, but has their own crypto with proper RNG seeding. Well done, apart from lack of end-to-end and use of RC4.
  


• Playtech Online Casino: supports almost all MIDP phones, built in encryption, 1024bit RSA and 256bit AES, with player key-strokes during gameplay used to seed RNG.

Bad Examples:

• Opera Mini Basic: no encryption, but allows users to interact with their secure HTTPS banking sites while sending cleartext usernames, passwords or credit cards over the internet. To be fair they do admit it here with a good diagram.
  


• Mobile java apps that rely on SSL or HTTPS - they won't work in all cases, and slow down user interaction where they do work.
  
  
• Plaintext SMS apps which invite you to send Credit Cards or other sensitive data.
  
  
• Anything using "security through obscurity" or "snake oil" where they don't reveal what they do to protect your data.
  Also a special mention for the use of the word "patented" in security. It may help to raise a company's valuation in the eyes of Venture Capitalists and investors, but to a cryptographer (or hacker) "patented" doesn't mean safer, or correct, or even clever. It only really says that someone has sent it on a piece of paper to their local Patent Office and can be a good hint that very few people have had the chance to check it and test it, especially if this patented technology is only used by one or two companies.
  In Java reverse compiling (reverse engineering) end user applications is pretty straightforward, so the secrets will come out pretty quick as soon as someone takes an interest in your product.
  

---

I hope that gives you some idea about security on current generation mobiles. My next post will cover getting good Entropy for your secure random number generator on mobile, a need highlighted in a timely fashion by Brian at Mobile Crunch.

Comments: there are no completely secure systems in the world, and security only gets better through challenging, discussion, testing, probing and questioning. Please post your questions or corrections if you have any, and I'll do my best to respond, or correct mistakes/omissions as they are pointed out.
Also please feel free to post good examples of clear and honest mobile security if you've seen some, but don't be surprised if we start poking them and asking questions back at you!