Community

Crikey, that's harsh Rob!

OK ... yes my gig is privacy, but I haven't lost my hair.  What stresses me is the anti-private elements that are striving to sell something.  Like full body scanners. If you're in favour of this technology, then let's see an argument for it rather than an opening attack on privacy advocates. Incidentally I am not against  body scanners per se, just the casual and intellectually lazy dismissal of privacy as being the enemy of security.

Privacy is far from dead.  See the reactions to Google Chrome's Ts&Cs?  Or Facebook's occasional forays into monetising users' personal information? Or the popularity of Ann Cavoukian?  Privacy is alive and well.

My detailed views on privacy, and in particular my radical ideas that we can enjoy and should privacy and security at the same time, are freely available in my publications library.

Cheers,

Stephen Wilson.

Without fail, when someone tries to tell you that privacy is over -- whether they're a politician, law enforcer, technologist or security adviser -- they are trying to sell you something.  The privacy-security dichotomy is pure propaganda. 

Steve Murdoch apparently set out to slur EMV by describing a "foolish error" but later admitted that the year 2016 theory did not come from "any reputable source". 

"However, before criticizing too harshly, one should remember that EMV is almost impossible to implement perfectly"

This throw away line contains all sorts of red herrings:

• It's almost trivial to state that any particular complex scheme XYZ cannot be implemented "perfectly".  This is really quite an unprofessional criticism for him to make.  Security is never about perfection; it is about fitness for purpose.
• In respect of fitness for purpose, there have indeed been and will continue to be errors in EMV implementation, and it's good that the likes of the Cambridge boys continue to pound away and publish the errors they find.  But the constructive response is not to damn all of EMV as they do, but rather to press for better certification. [A parallel example is the sensationalised attacks they've mounted by tampering with EMV terminals.  These results are really unsurprising: if organised crime can tamper with merchant terminal equipment, then the sky's the limit.  But the clear lesson is that terminal manufacture quality controls need to be looked at, not that the payments system is all of a sudden broken.]
  
• In terms of testability, EMV probably utilises simpler technologies than FIPS-201, for which there are elaborate testing and certification schemes.  The challenge of correctly implementing EMV is not great compared to other security programs.  It may require greater care and investment than we've seen from issuers to date, but that's the way security economics tends to work: businesses under-invest at first, and catch up later.  The scheme itself is not broken.
• The year 2016 date error doesn't seem to me to relate directly to EMV at all, but looks like an elementary software error in some other module in the smartcard and/or the terminal.  The charge that this error reflects badly on the EMV program at large is drawing a long bow, and comes across as another example of the Cambridge boys over-reacting as part of their anti-EMV agenda.

Security and cryptography are careful and precise disciplines.  I wish that security practitioners would exercise commensurate care and precision in the way they publicise their findings. We all decry security sensationalism on the part of politicians with agendas, but politicians are not the only offenders.

Cedric,

I wish you'd answer some of the plain technical questions instead of speaking in riddles all the time!

If you don't think addressing security at the merchant side is sensible, then what do you make of SSL EV? Why should anyone invest that extra $1000 to improve their site integrity?  Or invest in any other discretionary security measure like ISO 27001?

Are you seriously saying that no merchant should take steps to better secure their own site, because that would make other merchants more attractive targets for fraudsters?  Whose problem is that exactly?

And you haven't explained how changing customer behaviour with this on/off idea, introducing yet more user interfaces, and changing cardholder agreements, is worth all the trouble, when the basic problem is that payment cards today aren't safe when they're left turned on! Forcing this onto users is just another patch.

Marite,

I'm going to have another go at highlighting some fundamental differences between your ideas and mine.

I'm sure we all agree that changes are needed at one or more points in the payment system to address card fraud. It's important to look at the broader impact that different approaches have on business rules, legal arrangements, customer behaviour.

I favour digitally signing payment transactions at the browser to make them non-replayable.  This is essentially how DDA EMV security works, and now we can replicate these techniques in browsers for CNP transactions.  If the digital signature is created using a private key in the customer's chipped device, then the merchant is assured that the transaction is genuine, original and cannot have been replayed by an attacker. Once validated, the merchant server can push the transaction into their regular acquiring interface where cardauth etc. occurs as normal via the established four party model.

I believe it's important to leave the four party payment processing model unchanged. While some proclaim that the traditional model is broken, I say it's fundamentally sound but it suffers from one specific vulnerability in the digital environment: merchant servers have great difficulty telling genuine card data from copies.

Digitally signing payment transactions at the browser fixes that vulnerability; it stops replay attack at participating merchants.  This is a more elegant approach not just technologically - it's legally and contractually elegant too. There is no change to merchant acquiring relationships, or to customer behaviour.

Cedric and I have debated the pros and cons of installing security at merchants.  He hasn't answered my point that most e-commerce security today is in fact optional and is focused at merchant sites.  Examples include SSL, EV SSL, ISO 27001, PCI, TRUSTe and the like.  Online shoppers are told to look out for padlocks, trust seals, reputable payment gateways, privacy policies etc. so it makes sense that some merchants should elect to adopt more secure payment measures, like accepting non-replayable digitally signed card transactions.

The alternative is to mess with the four party model, which generally introduduces untold legal risks and cost implications.  Many approaches (e.g. CAP and tokenization) entail brand new intermediaries, with added costs, processing overheads, and contractual complexities.  Look at 3D Secure and its novel requirement that the cardholder authenticate themselves directly to the card issuer in real time. That step alone could be one of the biggest changes to the four party model ever seen.

The idea of cardholders turning their cards on and off seems to me to involve deep changes to systems and customer behaviour. There will need to be new backend software at the issuers (I guess?) to turn accounts on and off and adjust limits up and down, new user education programs, new user interfaces to request these changes, and above all, new rules.

Today nobody needs to think about their cards being on or off.  So what sort of changes to the cardholder agreement will be required? Will you still have to pore over your statements every month in case a fraudster has turned your card on without you knowing? Why should users even have to think about all this, when there are technically simple ways to stop replay attack?

My experience is that the legal analysis and contractual impacts can be fatal when making these sorts of changes. When we're fighting fraud we should address the actual technical problem (replayability of cardholder data) instead of papering over this vulnerability with more ad hoc measures. For sure, the less change to business rules the better.

The GTC is certainly saying the right things about privacy.  It is indeed all about putting users in control of the information that is revealed about them.  I very much like the stated focus on relationships (I've previously written about why relationships may be a more powerful way of thinking about "identity"). 

I'd now like to know more about GTC's technology intentions.  Do they plan to develop and promote an architecture?  Or a service?  Many user-centric identity management proposals in fact turn out to be centralist, and can lead inadvertently to new aggregations of identity data and behavioural metadata, threatening privacy after all.  The Microsoft Identity Metasystem for example turns many service providers into "identity issuers", and this changes the relationships they once had with their customers, in ways I don't think have yet been worked out.

I think it's important that users have the ability to reveal verified identifying details about themselves directly to each second party they're trying to strike up a new relationship with.  The recent ENISA discussion paper on eIDs and internet banking makes some valuable and progressive points about the potential for government issued ID cards to carry trusted attestations about the cardholders' details.

In the video interview, GTC's David Merkel does mention technology as an important part of the mix.  And the GTC stresses "interoperability" too.  At this stage it's hard to comment on the security of this approach, without being able to take a deep dive into the technology.  The GTC website so far focuses on policy and legal.  I look forward to hearing more about their technology vision, and the sorts of working groups one would expect will be formed.

Cedric wrote:

Any solution that has to be installed on the merchant side cannot solve the problem of fraud.

I disagree.  The vulnerability that is responsible for almost all digital identity fraud is the replayability of IDs.  CNP fraud occurs simply because merchant servers cannot tell genuine card numbers from copies and fakes.  So the merchant side is precisely where the best solutions should be focused. Any other approach is a patch.

If your system is not installed with all the merchants, consumers are not protected all the time! You are forcing them to buy only with the merchants that use your system. You need to be a bit more realistic here.

This is not an unrealistic or unusual approach.  In most jurisdictions, online merchant security is very lightly regulated.  In the US and Australia for example, website security is almost totally discretionary.  And some banks famously say they wish to compete on security. 

So security is bought today in a free market.  Different merchants invest in different levels of security for different reasons. SSL certificates, EV SSL certificates (for an extra $1000), trust and privacy seals, and ISO 27001 security certification are all optional.  I happen to agree that we should have more regulation to counter cybercrime, but Cedric, if you want to be "realistic", think about the fact that most of the crime fighting effort today goes on consumer education.  We already have a situation where some merchants are more secure than others, and consumers are expected to choose between them.

Even the centrally mandated security measures like PCI DSS compliance have a huge discretionary component.  Merchants have free choice of PCI-compliant software and QSAs.  We all know that you can spend the bare minimum to pass a PCI audit, or you can invest more if you like in a comprehensive security solution. 

So I just don't understand your objection to merchant-side solutions. Especially when most other suggestions introduce new processing intermediaries, and/or changes to the four party model, and/or changes to cardholder agreements.

I'm sorry Cedric that you don't like the way this conversation has evolved, but it was Marite who moved us this way, by suggesting turning cards on and off is an answer to the security problems raised by Robert.

I don't care where we discuss it.  But instead of insulting my "blind" belief in smartcards, and ignoring my extensive writings on the topic here and elsewhere, perhaps you could answer the question: If there is a reliable means to authenticate the request to turn a card on and off, why isn't that means sufficient to authenticate the presentation of the card to a merchant?

So there are two ways to go. We could go forward, and have chip payment cards and terminals rolled out universally, eventually taking out the mag stripe. 

Or we could go backwards.  We could remain so paralysed by customer convenience over security that we keep layering more and more complexity and stop-gap fixes on the good old magnetic stripe card.  Don't worry about all the complexity, so long as we still got the stripe!

Chips are taking over all types of cards; why resist the tidal flow?  It's ironic to me that the US gets a bad rap for its reluctance to go to EMV cards, yet the US market happens to enjoy the best smartcard-enabled laptops (like the Dell e-series, with contact and contactless car readers built-in) thanks to the growth in FIPS 201 PIV cards and a rich array of associated apps.

Someone is going to have to explain this idea of turning on and off my credit card, like I'm six years old.

If I can contact my bank over the network, prove to them that I am Stephen B. Wilson, holder of card no. 4000 1234 5679 0123, and ask them to turn that card on, then I must be authenticating myself pretty well, yes?  If so, why not use that same authentication mechanism to prove to a merchant that I am Stephen B. Wilson, holder of card no. 4000 1234 5679 0123?  Then I could leave my card on all the time!

Enough already with the stop gap fixes!!  Turning cards on and off because they're not really trustworthy when they're on seems very odd to me.  Let's tackle the real problem -- which is that digital ID data presented online can be replayed -- without introducing more and more layers of complexity between buyer, seller and their banks.