Community

Gosh, so many red herrings, so many strawmen!

Multiple ID's ... sound like an even bigger headache than we have now.

Actually no, it's what we do now in the real world.  We use different IDs in different contexts, to minimise extraneous data disclosure.  Privacy 101.  Check out the Laws of Identity, some of the best thinking in this space for many years.

I want my Mum to be able to check the credentials of the plumber before she opens the door to them.

Correct -- she needs to know their credentials but not their singular identity!  Your mum has no right to know the plumber's singular identity.

Not personal details. I plan to make them worthless.

I would agree with you about making personal details worthless, but I find your 'solution' utterly impenetrable.  What is it, if it's not a universal global identifier on a phone?  How does that possibly work, and how is it unable to be stolen?

I'm not exactly unfamiliar with biometrics ...

I have no idea why you keep raising biometrics.

As for not giving away IP, get over it. 

Your opacity is not my problem, it's yours.  No security solution deserves consideration until it is open to review.  Your claims are hyperbolic, sometimes preposterous.  On what basis can anyone believe them?

What does my Mum do Steve? Who is going to buy her, and every other grandmother, a reader? 

It depends on what she is trying to do.  You've skimmed across the top of several utterly different trransactions.  Voting, banking and checking out the plumber are all totally different and require different solutions.  In my view, to do Internet banking and shopping, yes she probably needs a smartcard.  There are numerous ways to furnish readers.  In Taiwan, over 2,000,000 ordinary people have bought them for themselves.  My laptop has one built in.  In the US, new Dells have wireless readers built in.

Explain the processes for individuals. What do we need to participate in the multiple identity card/reader solution? How does it help us interacting? Not just with the bank or the bus? You ignore many important identity occasions and don't have a solution for them.

I am not the one advocating a single solution for all conceivable transactions.  I have a clear vision for how to fix identifier takeover on the Internet, with a specific focus on CNP fraud (and also G2C transactions).  I do not have any pretensions of revolutionising the way we interact with traffic cops, plumbers, or polling station workers. I am not even sure that these are pressing problems.

The smart card crowd are living in denial. So what if you've issued a million cards, or 10 million, or a hundred million, they'll end up in the trash before those 3 billion plus mobiles do, and when they do they won't be replaced like the mobiles will.

Huh?  Of course they will be replaced. Your figures are really rubbery. Nearly 1000,000,000 EMV cards have now been issued, and they're trending solidly towards replacing all mag stripe payment cards (I am not sure of that number but it's big).  These cards naturally get replaced every two or three years, for ever.  There are another several hundred million government ID and health smartcards already issued, with another billion on the horizon in India alone.

I don't mind admitting I fooled around with 'smart cards' a couple of decades back, but to me they made even less sense now than they did then, I had my mobile back then ...

Really?  In 1988?

For instance. Child care centres. How do they know who is authorised to pick up a child? What if someone else has to do it in an emergency?

I'd like Steve to explain the process.

Not my problem to explain Dean.  I haven't advocated using anything to authorise the collection of children; this is a hard problem and doesn't seem amenable to any one technology solution.  I steer clear of one-size-fits-all solutions.  These are your claims, so you might care to explain how a mobile phone will solve these problems.

How would you do it with cards Steve? Explain the exception process, rather than the rule. New person in an emergency, lost card, fingerprint fingers in a cast?

I have explained, in full, how we can solve CNP fraud, and how we can anonymise G2C transactions.  It's all on our website.  And we have nothing to do with biometrics, ever.  That's your strawman, not mine.

This debate is a bit of fun I suppose, but let's focus please.  Dean, you've made extraordinary claims for a mobile phone based solution in unlimited transaction settings.  It's supposed to save money, be absolutely resistant to theft, and be compatible with 3 billion handsets today.  You say it will do wonders in banking, healthcare, childcare, voting, policing and plumbing.  Be reasonable -- we just want to know how it works. 

Cheers,

Stephen Wilson, Lockstep.

Dean wrote:

"Forget your regular ID, that's been stolen. It's been stolen by criminals and mismanaged by governments."

We need some precision in this discussion.  It's very rare for criminals to steal an "identity" full stop. But they steal identifiers (plural) by the truck load. Card Not Present fraud is the classic example; it involves replaying a parcel of stolen identifiers and supporting data.  But taken together these data are not my "identity" in the sense that Dean uses in the rest of his post, which is mostly concerned with government identity.  Most "identity theft" is better understood as "identifier takeover". This semantic point is usually not worth worrying about, but when the discussion jumps from banking ID to government ID I think it's worth pointing out the technical differences.

Dean goes on to posit ...

"DI the new ID - the one they can't steal."

Unless Dean is willing now to talk turkey and explain how this works, the discussion remains worse than academic -- it's hyperbolic!  What sort of technology is so good that one can make the bald statement "the one they can't steal"?  Security 101 says 'No security technology is perfect'.

In reality, a safer approach is to have people maintain separate identities (or 'identifiers', or 'claims' to use the terminology of the Laws of Identity) each specific to a certain class of transactions. This isn't as hard as it might sound -- we do it today, seamlessly.  When I access my personal bank account, or my business bank account, or my health insurance, or my airline club, I use separate ids, almost instinctively.

Multiple ids means the compromise of one of the them won't ruin the rest of your life.

Cheers,

Stephen Wilson, Lockstep.

Dean might have paraphrased Pascal or Mark Twain, "I'm sorry this blog is so long, but I did not have time to make it shorter". 

Dean's encyclopedic post contains some good ideas, using what The Laws of Identity call "Directed Identity".  And there are some motherhood statements about trust.  But I'm still at a complete loss to know just what he proposes to do about anything.

As bloggers we all tend to fall into the trap of over-simplification.  In our hasty little dispatches we try to solve the problems of the world, without first defining the problem.  The medium of the bloggosphere  assumes that all readers understand the problem at the start of every rant.  But in the complex modern finance sector we're really not all on the same page.  The sub-problems are many and varied: money laundering and know-your-customer reforms, identity theft (actually better defined as identifier takeover), payments fraud (which breaks down further into online fraud, POS fraud etc etc.), rogue trading, payments efficiency, accessibility and ease of use, customer choice, and all the myriad aspects of the current financial meltdown. These diverse issues should not be carelessly (much less willfully) mashed up, as if they might be solved in one utopian paradigm shift.

Ranting and raving and waxing philosophical is great fun -- I enjoy robust dinner table arguments as much as the next person.  But most Finextra readers are probably more interested in solid contributions to solving specific, well defined problems in the finance system.

So in the interests of good problem definition, I'd just like to reiterate how I see the major security problem with cards.  CNP fraud is a huge problem, but it is not sufficient grounds to abandon cards and shift holus bolus to opportunistic untried mobile schemes.

The four cornered model remains fundamentally sound but it runs foul of fraud on the Internet because Merchants find it so hard to tell whether Cardholder data is genuine or not.  High tech solutions like 3D Secure operate by shifting the authentication task from Merchant-identifies-Customer to Issuer-identifies-Customer in real time.  Medium tech solutions like CAP blend two factor authentication to stop ID theft, with kludges like re-entering transaction data to thwart Man-in-the-Middle attack.  The price paid for these approaches includes slower processing because of all the new bottlencks, and complicated user interfaces.  But at least they don't introduce any new commercial entities, contracts or processors. 

Instead of leaving you with an oblique implied sales pitch, I will state clearly that my company researches specific solutions that safeguard cardholder data when they transact online. We advocate using smartcards (or USB keys or cryptochips in phones) to digitally sign cardholder IDs before presentation, using private keys in hardware, so that the IDs cannot be stolen and replayed.  The approach is simpler to use, faster to process, and introduces no new intermediaries or contracts.

Cheers,

Stephen Wilson, Lockstep.

Dean,

I well know the connection between cybercrime and terrorism financing.  What I object to is your line that one should feel guilty about using a credit card because some of the proceeds of crime might be passed on to terrorists. 

The implication -- given the backdrop of your long, long thread of anti-card, pro-mobile grandstanding -- is that if we switch to Transinteract, we'd be, what, purer, as well as more secure?

On Finextra, you have made a string of glorious yet utterly unsubstantiated claims for your technology, at one point even having the temerity of putting a price on it. You have avoided answering my many questions about what it actually does or how it actually works.  As a security professional I find this objectionable; in the absence of any details, I have to say you're posturing.  But when you drag terrorism into the mix, you're stooping very low indeed.

Regards,

Stephen Wilson.

Dean suggested vaguely:

While I don't think a system where the doctor used your phone to access your health records would work, perhaps one where you used your phone as you enetered reception, to ID yourself and give the doctor permission to access your records?

What do you actually imagine doing here?  To whom am I am identifying myself?  Which doctor, and for which of my records?  If I am booked in to see a doctor, then they already have permission to read my records; if it's an emergency then permission is moot and other consent protocols kick in.  So, do you have any real workflows in mind?  Electronic health records and consent management are not trifling problems.

Of course there is a backup plan for the technologically challenged ...

That's nice, but it would be good to know exactly what the up-front plan is, before turning to the promise of a backup plan.

It is generally better for the doctor to review your medical history before you enter his examination room so identifying yourself at reception is a good idea.

They do this now, taking my name from the appointment system. There is no crying need for ID on the way through the door of reception.

Of course as soon as you have ID you have integrated billing, and that makes the doctors' job easier and leaves them more time for doctoring.

If only it were that simple.

Cheers,

Stephen Wilson, Lockstep.

Dean, now you're really scraping the bottom of the barrel.

Stephen Wilson.

Dean asked rhetorically: Did you take your mobile with you last time you went to the doctor's?"

Err, no I didn't actually.  It's frowned upon to have the phone turned on in the GP's clinic.  And of course they're banned altogether in hospitals.

And another thing -- my cell phone battery is rubbish. So, what if it were to die just when the doctor were to try and access my health records with it? 

No thanks!

Stephen Wilson, Lockstep.

I was questioning the wisdom of piggy-backing payment authentication services onto the mobile telephone network.  I asked "If the network fails, who's liable for losses arising in the new fangled mobile-secured transactions?"

Dean responded:

I have a recollection that the mobile network is somewhat more reliable than the EFTPOS network, anyone have any numbers to disagree? Who is liable when the EFTPOS network or smart card reader fails?

Plainly, when the EFTPOS network fails, the EFTPOS network operator is liable.  But when a mobile phone network fails, and damages result in a payments application for which that network might not have been designed for (nor accredited for) then the question is obviously much more complex. Though I fear that the answer might be simple: the mobile operator is likely to say 'no' to liability! And perhaps even 'no' to any use of its systems for these novel purposes.

Consider this parallel.  One day I realise that Qantas runs a more reliable transport network than any trucking company.  So it strikes me that a good business opportunity is to start carrying parcels as hand luggage on behalf of business clients.  And then one day a parcel gets lost in the airline system and my service level agreement with my customers is breached.  What chance do I have of recovering losses from Qantas?  In the absence of a contract with the airline, absolutely zero.  So it would be wise for my ad hoc courier business to have an arrangement in place with Qantas for me re-using their service. 

But what do you think that sort of arrangement would look like?

I think the telephone network is perfectly fine for authentication and transactions, if you use the right methodology and features.

With respect Dean, what you think isn't the issue, it's what the mobile network operators think, especially in relation to liability arrangements and contracts.  So when I ask "what is under the covers", what I'm really interested in is the legal arrangements you propose to have with telcos for their networks to be coopted for authenticating payments?

As I've mentioned before on these pages, what kills novel authentication arrangements (like all manner of federated ID schemes for instance) regardless of their technological merits, is the sheer novelty of the legal arrangements that are implied.  To get lawyers to get their heads around new schemes, especially when these schemes break open existing silos and change business models, is a lengthy and staggeringly expensive exercise.

Cheers,

Stephen Wilson, Lockstep.

Dean starts out with the perfectly reasonable observation that proper authentication is what's need to counter phishing.  But his argument then proceeds with a classic strawman tactic: lead the reader to believe that biometrics is the leading authentication method, then demolish it, leaving mobiles as apparently the only alternative. 

It's a flimsy argument on a couple of counts. Firstly, biometrics is not actually a sensible way to authenticate e-mail senders.  After all, they're often machines!  It's quite specious to add biometrics into the debate; nobody has seriously suggested that e-mails from banks be biometrically signed by actual human bankers.  No, what's probably needed is digitally signed e-mails, with certificates chaining to trusted authorities, and revamped e-mail clients that properly process digital signatures so as to block the unsanctioned originators.  But there are plenty of other approaches too, like web mail which can be architected to be pretty well phishing proof.

Secondly, just because mobile phones are ubiquitous, that's insufficient reason to press them into service as all-purpose security solutions. Was the telephone network designed to be coopted for authentication?  If the network fails, who's liable for losses arising in the new fangled mobile-secured transactions?  What legal arrangements can be put in place to allocate risk if we are to bridge the hitherto separate banking and telephone networks?

Just what Dean's mobile technology actually does remains entirely unclear.  How would it secure e-mails so as to stop phishing?  Would our experience of e-mail have to be re-jigged to put the phone into the loop?  Or is it just a warning system that actually doesn't touch the e-mail at all but instead protects account holders after they happen to fall for a phish?  Or what?

If we're going to debate technologies and talk seriously about security solutions, then let's have some transparency please; i.e. what's under the hood Dean?

Cheers, 

Stephen Wilson, Lockstep.

"Merchants are specifically required NOT to store the CVV"

Indeed, but what a multitude of issues lies beneath the surface!

- Collecting the CVV and them discarding it, is non trivial, as anyone in IT knows.

- The CVV is cached at multiple steps along the way.  The merchant needs to transmit it to the gateway: where does the CVV end up, and who is responsible for its safekeeping? Who can say it's been discarded?

- PCI compliant systems need to be carefully designed, carefully installed and carefully maintained, if they are to keep the solemn promise of discarding the CVV. 

- Above all, CVVs are valuable on the black market.  Therefore there is a profit incentive for insiders to sell them.  You can have a merchant that is PCI compliant up to the hilt, but is still leaking CVVs like a sieve because corrupt employees are selling them on.

It all points to the futility of using any ID data alone (CVV2, billing address etc.) to authenticate a card holder.  ID data, when it is replayable in CNP transactions, is immensely valuable.  It is the very value of naked ID data that makes PCI compliance ultimately of very marginal benefit. 

Sadly, every SME running an online business and taking credit cards is on the hook for PCI, requiring crazy levels of security and audit, when all it takes is one corrupt insider with access to a large volume system to siphon off a million cardholder records.

Cheers,

Stephen Wilson, Lockstep.