Community

I have no trouble with the term temporospatial (it means time and space).  What I don't understand is Robert's assertion that "identity isn't established".

We need much clearer problem definition if we are to tackle ID theft without creating a monster.  Centralised identity "issuers", biometrics, datamining, Eugene Kaspersky's utopian Internet passport, and now the "reality mining" mentioned in the MIT proposal, are cures that in all likelihood are worse than the disease. These sorts of centralist approaches are toxic to privacy and only create new vulnerabilities.  And time and time again, the sheer legal novelty of new identification intermediaries (which is what the MIT proposal entails) has proven to be a showstopper.

We actually do a pretty good job of identifying people in the real world. The real problem underlying the ID theft epidemic is this: once you have a digital ID, it's usually in the form of an alphanumeric string which is too easy to obtain and replay online. 

Stop the replayability of alphanumeric ID data and you will stop most ID theft, without changing the way that people are identified. And without introducing weird and wonderful new identification brokers which would radilcally alter the legal arrangements between participants in commerce.

Nobody in their right mind should want their credit card numbers, Social Security Number, driver licence, employee ID, health IDs, their name and address plus continuous data on all their behavior all tied up in some uber identity.  What people really need is the ability to present a particular digital identity online, appropriate to a particular transaction, without it being stolen and replayed.

Marite: All I got from your comment was the idea that thieves can assault customers to force them to divulge their PINs, and the implication that autographs cannot be obtained by duress.  If that's your position, I am still not sure where that leaves CNP.  I know your idea that cardholders should turn their cards on and off, but that leaves an authentication weakness.  What is the authentication mechanism used when someone requests that the bank turn their card on and off?  It cannot be a remote autograph.  So don't you come back to PINs no matter what?

Marite: Are you actually advocating the use of handwritten autographs instead of PINs for payment cards?  If so, what do you advocate for Card Not Present authentication?

Marite,

Generating a digital signature is not as complicated as you imply.  It is not something that has to "interest" any consumer.  It's a completely transparent process.  I think you know that every time you use a DDA EMV card, digital signatures are created by the card, automatically.  So nothing in my vision for securing digital identity is any more complicated for the cardholder than simply inserting their card and entering their PIN.

What I'm advocating (and it's not my solution, this is just a basic technology) is that whenever a remote party wants to know your important ID -- whether it is your name and address, credit card number, health ID, whatever -- then it's best to present that ID by way of a certificate and digital signature.  Different chips would naturally hold different IDs.  A practical example: your smart driver licence, REAL ID or ID card (in applicable jurisdictions) could carry a certificate that conveys your name and address.  Imagine you are originating a bank account online and the bank wants you to prove where you live.  You could insert your smart driver licence into a reader at your PC at home, enter a PIN, and the chip would send a tamper resistant cryptogram to the bank that includes your name and address.

Marite,

Turning one's account on and off because it's inherently insecure against fraudsters is really just shifting the risk (and the blame).  How does risk get apportioned once users are making active risk decisions?  What if they forget to turn off?

Further, I'm thinking way beyond card accounts.  The fundamental problem underlying almost all ID related fraud is that nothing stops personal data being replayed.  We should be using smartcards, smart phones and the like -- with embedded private keys -- to digitally sign our data when we present it.  Health IDs, name & address, social security numbers, anything. 

You can't jury-rig magnetic stripe cards to create digital signatures.  The technology is a total dead end in the digital economy.

Robert, I don't think it's useful to label thieves, even grand larcenists, as "terrorists".  And comparing this guy to pedophiles and serial killers is disproportionate, and frankly insulting to the victims of these immeasurably more serious crimes.

Having said that, I commend you for highlighting the criticality of inside jobs in the identity crime wave.  The lesson has to be that audits and policy-based responses are of very limited use, because insiders can so easily evade them. 

Why don't we put proper security around online identifiers?  Why do we resist so energetically investing in decent preventative online security?  Imagine running a bank where the main mechanisms to protect the cash was personnel processes and audits.  Duh! We all know that insiders cannot resist multi-million dollar temptations ("it's good to trust; it's better not to"), so we put all manner of proper physical controls around cash. 

We must do the same with identity data. 

As you say Robert, the fun begins when the identity thief obtains a target’s name and address, SSN, birth date and account information.  They get away with ID fraud because it's insanely easy to replay identity data to create new accounts.  You're right that the rules around address matching should certainly be tighter, but the stark underlying problem would still remain: identity data should not be replayable. 

Asymmetric cryptography, digital signatures and secure chip devices for protecting personal identifiers offer the best way to imbue original identity data with a pedigree. These are standardised building blocks, now almost ubiquitous in the personal computing and e-commerce technology stacks. Digitally signed data cannot be replayed; it's useless to theives.  Banks, merchants and governments should use this technology.  And then, on the Internet, you really could tell if I was a dog!

Stephen Wilson, Lockstep.

I see.  But still, tampering with a retail terminals on a large scale is still much more difficult than mounting a conventional MitM attack at the browser isn't it?

If you're mounting a real time MitM attack, you don't need to have tampered with a retail terminal to get the CAP OTP; you just trap the user's OTP as they enter it. 

Do Marite and Dean have anything to say about the substantive issues that others on this thread have raised about the Cambridge attacks?  Or are they content to shoot messengers for being pro Chip-and-PIN?  Yes many of us are pro chip, but we're engaging with the substance of the Cambridge research, and finding that the research isn't actually so profound as to merit sarcastic yelps of joy from EMV critics.

Marite and Dean are anti-chip, but they're silent on the technical issues. They seem to swallow uncritically every bit of bad news about EMV generated by theoreticians.

[Elsewhere Dean is far from silent on pseudo-technical issues, but he has yet to offer a single non-trivial truth about smartcards.]

Like the others, I really don't see that the latest Cambridge attacks are momentous.  Sure, obtaining CAP codes via a tampered terminal is a bit of an eye opener, but the secrets are no good in the vast majority of CAP implementations where codes aren't replayable.

More generally, looking at the significance of this whole line of inquiry ... if the Mafia can mount large scale insider attacks on terminal equipment, then what do the Cambridge folks and their acolytes expect anyone to do about that?

Thanks again Steven.  I see now -- the compromised terminal itself asks the card for the CAP code, under the covers, and sends it back to base. Duh! Pardon my error.

Another mitigating design feature might have been for the EMV card to enforce PIN re-entry for every fresh cryptographic event (the POS transaction, then the CAP code).  I guess you're showing that once the PIN is entered, the card will sit there and accept multiple cryptographic requests until it's taken out of the reader?  Nuts.