Secure Transactions - are SIMs ready?

By Steven Sidley, Prism Holdings

The world of secure transactions has been around for a while. From a consumer perspective, this started when the first EFTPOS device was deployed to read a credit card and transmit the information to a bank for authorization, more than 30 years ago. The arcanae and minutiae of payment protocols, financial message formats and EFT security have been continually honed and refined to the point to which there are clear rules and policies which require adherence, before banks will accept a financial transaction, particularly if it involves consumer payment.

The founding fathers of GSM were probably only dimly aware of these requirements as they drew up their specifications. After all, their arrows were aimed at designing a global communication infrastructure, not at the subtleties of encrypting a debit card PIN number on a SIM.

But there's the rub - this is exactly where GSM operators find themselves, rushing headlong in Value Added Services requiring secure functionality like payment, as their mandate to make pots of money via voice calls and SMS-delivered voice messages expires.

Thus as operators sift through the cornucopia of VAS offerings and mobile wallets being developed a hawked by vendors worldwide, so the beast of cryptography, PIN translation and other banking security requirements raises its ugly head.

So I would like to make some emphatic statements about what the minimum requirements for secure transacting over GSM are:

• You had better make sure that some sort of response is returned to the initiator of the transaction with 7 seconds. Much more than that, and your application starts to lose popularity fast.
• The SIM had better know how to encrypt a PIN using banking industry standard algorithms like DUKPT (Derived Unique Key Per Transaction). Otherwise forget about applications that require, say, debit card clearance.
• The SIM had better know how to encrypt messages with industrial strength symmetric schemes like 3DES.
• The SIM had better support RSA public/private keys, in order to host PKI infrastructures.
• The SIM had better support digital signatures, because standard GSM security may authenticate a SIM to the network, but it pays scant attention to authenticating the user of the SIM.
• The GSM operator better understand how to do PIN translation, because you can bet that any bank worth its salt is going to want to travel through the network in the warm embrace of its own PINs.

Truth is, most SIM manufacturers have begun to realize this, but so much energy is being expended in issues like common SIM operating platforms, that not much attention is being paid to interoperable specifications around these issues. This has created an interesting new set of dynamics in the marketplace. Prism Holdings (South Africa) and Setec have both developed SIMs that contain advanced crypto functionality, and Prism has included advanced banking functionality in the form of PIN encryption like DUKPT. Smarttrust has developed plugin specifications for their Wireless Internet Browser 1.2 that includes some transaction security (like digital signature) and is working with companies like Prism to specify further transaction plug-ins for future releases.

A number of the other major SIM manufacturers have begun to implement digital signature algorithms, and, more significantly, some of the SMS-C providers, like Logica have started to gaze their steely eyes in this direction. Which brings up a tautology - that which is encrypted (or signed), must be decrypted (or verified). It is all very well to talk of the stuff that needs to be done on the SIM to secure transactions, but anyone contemplating secure mobile transactions needs to understand what happens when the transaction hits the GSM cloud, and moreover, what happens when it leaves the cloud and moves on to a service provider like a bank.

Prism, in addition to supplying a SIM containing multiple crypto and banking plug-ins, also provides the crypto hardware on the other side, to decrypt, verify signatures, and, significantly, handle tasks like PIN translation, to enable banks to launch their own secure zone before the transaction leaves the cloud. The API to these crypto products is at a sufficiently low level so the crypto server can sit on the SS7 stack, or be addressed via IP outside the cloud.

Returning to the SIM - while some people think that waiting for widespread PKI adoption is like waiting for Godot, (the character in the famous Samuel Beckett play), just consider this: the security vulnerability inherent in managing private keys for literally tens of millions of anonymous consumers is as good an advertisement for asymmetric security as I can imagine. New silicon from Infineon, Atmel and the like support RSA co-processors, facilitating the processing speed required to support PKI. Watch this space - you will see full-blown PKI acceptance by major operators by the end of 2002.

And finally, a word about performance. If your transactive interactive application takes longer than 7 seconds forward and backward, you are in trouble. I know that there are many potential bottlenecks to be considered, but don't let the SIM be one of them. And if you are using a standard Java card on 16 bit processor silicon, you've got a problem. A Java card needs a Java Virtual Machine. And by definition your performance is going to suffer.

You may like the other pro-Java arguments, but performance is definitely not one of them. A test at a major operator in APAC on a complex transactive application found that the card was spending 6 SECONDS interpreting the code! This, plus the network latency, resulted in a 12 second transaction, which killed the application, and they moved to Prism card, which executes object code directly. Result? - The entire transaction, back and forward in 6 seconds, and massive consumer acceptance.