Community

Mark Anderson asks a very good question. 

Paypal recently launched a fingerprint secured payment app also running on the Samsung Galaxy 5S. Paypal's app was very carefully designed to the new FIDO Alliance standards, which prevent biometric templates leaving client end points.  All matching is done on the remote devices.  (Paypal is a founder of the FIDO Alliance and a major contributer to the protocols). 

Was the Westpac app build using FIDO protocols and principles?

Fujitsu says that PalmSecure "maximises security" when used with NFC devices but the truth may be the other way around, because palm scanning used in 1:N matching mode needs a second factor like a card or a phone. And thus the biometric ATM falls short of what people have been led to believe by watching sci fi movies. You don't just walk up to a machine, get scanned, and your money comes out. The mindane reality is that someone else's money will come out unless the manufacturers take special precautions. 

In Japan, cardless palm scanning ATMs require custoemers to enter their date of birth and a PIN. The reason is that when you try to match a scanned palm against a central database of enrolled banking customers, you get a number of false matches.  We don't know how many false matches because the vendors are secretive about their true in-field error rate, but we do know that false matches will rise as more users are enrolled.  If they used biometric alone, then a customer may be given randmom access to someone else's bank account. To stop this, the ATM needs a second factor, which in Japan tends to be something-you-know - a PIN. 

I interpret the European announcement about integrating with mobiles as meaning that the PalmSecure ATM will use the phone as a second factor. 

I'm not sure how it's possible for this concept to be applied to a chip card. The magnetic stripe Coin card is able to clone all necessary card holder information that ordinarily is encoded (in plaintext) in the stripe.  But with EMV (technically, with DDA 'dynamic data authentication' EMV chips), the whole point is that the cardholder's details are authenticated via private keys that are created at the time the card is personalised and which subsequently never leave the chip memory.  The chip is used to digitally sign transactions on the user's behalf; ths signature cannot be replicated without having access to the private keys.  An EMV version of Coin would have to obtain copies of the cardholders' private keys. And that can't be done.

I'm not sure how it's possible for this concept to be applied to a chip card. The magnetic stripe Coin card is able to clone all necessary card holder information that ordinarily is encoded (in plaintext) in the stripe.  But with EMV (technically, with DDA 'dynamic data authentication' EMV chips), the whole point is that the cardholder's details are authenticated via private keys that are created at the time the card is personalised and which subsequently never leave the chip memory.  The chip is used to digitally sign transactions on the user's behalf; ths signature cannot be replicated without having access to the private keys.  An EMV version of Coin would have to obtain copies of the cardholders' private keys. And that can't can be done.

Sorry, the security of biometrics is entirely deniable.

No biometric today provides lasting signatures on electronic transactions. Biometric security is much more focused on access control – to secure data centres or to log on to computers – than transaction authentication. A biometric doesn't let you "leave your mark" on the transactions you later create. Biometrics just don't meet the business needs of paperless applications.

We must remember biometric devices are imerfect. Even if individuals' biological traits  were intrinsically unique (and few actually are), the ability of real world commercial devices to measure them flawlessly is limited. Lenses (and bodies) get dirty, lighting varies, body parts age and scar, and each time they get presented to the scanners in subtly different ways, with variable pressure, angle, volume etc.

Therefore, every biometric system commits errors. They can confuse one user with another (False Positive) or they can fail to recognise an enrolled user at all (False Negative). The very best technologies have trial-by-trial False Positive rates of around one in a million - which sounds good but for biometric ATMs is actually not good enough; see below. Typical error rates are actually more like one in a hundred or worse, which has an impact in even small scale usage.

When deployed without any other authentication factor, in what's called "1:N identification", biometric performance becomes critical. If the trial-by-trial False Positive Rate rate is 1 in a million, the chance of getting at least one False Match when identifying someone against a database of N enroled users is P = 1-(1-0.000001)^N. So for 100,000 people using a 1-in-a-million accurate vein scaner, the probability of at least one false match is surprisngly high 9% [the maths isn't hard; Google "Birthday Pardox"]. For very 100 attempted withdrawls at a biometric-only ATM, around nine of those accesses will hit the wrong bank account. For N = one million customers, P = 1-(1-0.000001)^N = 74%. That is, 3 out of 4 withdrawls will hit someone else's account!!

So if you look at the much vaunted Japanese biometric ATMs they don't use vein scanning alone. Rather, customers must enter their PIN and their Date of Birth!

Biometrics suffer significant performance concerns especially in large scale deployments where users must be matched against big databases. Tests were conducted by the UK Passport Office in May 2005 on over 10,000 people using fingerprint, face and iris technologies. Average verification times were 39 seconds for face, 58 secs for iris and 73 secs for fingerprints. Accuracy was disappointing too: success rates were 96% for iris, 81% for fingerprints, and 69% for face.

These performance stats are old, but sadly there isn't much more recent information available in the public domain. Biometrics vendors tend to be rather secretive. A critical spec is the "Detection Error Tradeoff" curve which shows how False Positives go up (security worsens) when False Negatives are pushed down (for better convenience). But I find it impossible to get vendors to talk about their DET curves.

Biometrics are not really mature technologies. Different vendors use different algorithms; biometric scanners & software applications for now rarely interoperate across manufacturers. Single vendor solutions are usually mandatory, and migration to alternate suppliers is difficult. Many algorithms have only just come out of the R&D lab.

Perhaps the worst problem is this: it is impossible to revoke a compromised biometric and reissue a new one. In contrast, one of the best security features of smartcards and most other authenticators is they can be cancelled and replaced if lost or stolen. No security system is perfect; all good security systems have fallback mechanisms. 

This issue has long driven me nuts. Stock markets are unstable.  If you gave them to a second year electrical engineer, as a Control Systems project, they would quickly look for positive feedback loops, and ways to "damp" the oscillations.  This is really standard undergraduate stuff.  Amplifiers, suspension systems, and umpteen other mechanical and electrical systems tend towards instability, and engineers have a common set of tools for bringing them under control.

Has anyone tried a "low pass filter" on the stock exchanges?  What if we simply slowed down trading, and applied a one or two day rolling average to the stock prices? 

I cannot imagine this is rocket science.  And surely it's in nobody's interest to look for solutions on the leading edge of academic research.  Stock markets are mission critical; peoples' very lives are on the line when markets crash and whole countries cut back on essential services. 

We really should be trying well tested technologies first, like college text book damping filters.

Secure Elements come in a variety of form factors and memory capacities. They're just chips, like smartcards, and as such can be as large as we like, subject to the normal design tradeoffs. With their influence, big players like Google and banks could drive device manufacturers to make SEs as big as they like for their needs.  Today, typical SEs have storage of around 100KB, more than enought to store half a dozen CCNs and still meet all the other demands on SE memory.

I'd like to see some analysis of why using the Sercure Element is thought to impede take up.  It's not like the SE and Trusted Service Manager (TSM) are innately visible to consumers. 

PS. thanks for picking up my typo! I'll fix it.

Thanks for the feedback.

Asymmetric cryptography describes a big class of technoloigies, including hashes but also digital signatures, which is an even better way to protect the pedigree of data sent from a device, on behalf of its owner.

A digital signature is created by processing transaction data through a private key kept in a chip like a smartcard, mobile phone SIM, NFC element, Trusted Platform Module and so on. The signature code can be readily processed by any receiver that has been preconfigured with the corresponding public "master" key [skipping some unimportant details here about public key certificate paths]. Modern Internet servers come with the master keys of almost all commercial PKI providers, plus the necessary software primitives.

CNP fraud is just online carding, and could be solved the same way.  Magnetic stripe carding was solved by Chip-and-PIN's asymmetric cryptography.  Each transaction is digitally signed in the chip before being sent across to a terminal, making the transaction specific to both the session and the card, and thus non-replayable. The very same chip could be used to digitally sign CNP transactions sent from browsers or mobile devices over the Internet to a merchant server, to prevent replay attack and CNP fraud, and thus neutralise the black market in stolen card details.

If we used personal smart technologies to sign transaction data sent  to merchants, then we would prevent replay attack at its roots. We could then preserve the entire four cornered settlement model, and avoid the legal and technological complexity engendered by 3D Secure etc. It's nuts that we don't leverage chips to perform the same security services in the online channel as they do in offline. 

I agree that the problems are of the payment industry's making, but I disagree that cards "are not really fit for use on the Internet".  For the purposes of payments, at a network level, the Internet is just another comms channel.  As we all found in the late 1990s, the decades old MOTO rules and Four Party settlement model {Cardholder, Merhcant, Issuer, Acquirer} extend very nicely from mail orders and telephone to the web.

Let's be very clear about why paying by credit card online is risky, who bears the risk, and what should be done about it. When cardholder details are presented online, a merchant cannot tell if the 1s and 0s are stolen or original.  It's not actually a safety issue for customers, but rather for merchants.  E-merchants could reassure onine shoppers all they like of their PCI-DSS compliance, but that's not the point, and in any case, most stolen card details are taken from big retailer and processor databases, not e-merchants.

All we need to do to make cards safe online is to better protect the presentation of cardholder detals to merchants.  Asymmetric cryptography would do the trick very nicely. If merchant servers were equipped to tell real PANs from stolen ones, then it wouldn't matter at all if the human-readable numbers and photos were posted online. 

One of the deep problems with 3D Secure is that it breaks the Four Party model.  It joins the Cardholder to the Issuer in real time to complete a redundant secondary authentication handshake, complicating not only the user experience but also the merchant's legal arrangements, and slowing the transaction to a crawl.

CNP fraud is just online carding, and could be solved the same way.  Magnetic stripe carding was solved by Chip-and-PIN's asymmetric cryptography.  Each transaction is digitally signed in the chip before being sent across to a terminal, making the transaction specific to both the session and the card, and thus non-replayable. The very same chip could be used to digitally sign CNP transactions sent from browsers or mobile devices over the Internet to a merchant server, to prevent replay attack and thus neutralise the black market in stolen card details. We should be solving CNP fraud the same way as we did skimming and carding, without overturning the decades old settlement processes. The payment card concept has decades of life left in it.

Which brings us back to my point! The default "2FA" -- meaning one time password generators -- is a toy, long ago defeated by determined criminals, and of marginal benefit. But "two factor authentication" achieved by smarter means like chip cards, enables transactions to digitally signed and rendered non-replayable, and mutual authentication too, where the chip's intelligence can detect and respond to site spoofing etc..  Then two factor authentication would offer real advantages, and be as easy to use in the remote Internet setting as POS and ATM systems.

Not all "two factor authentication" is the same, and we should take the time to think beyond the simple key fobs and calculators that have come to mean "2FA" by default.