Re: Encrypting basic card data

I'm hearing:

Let's not do this in v1, it may imply more security than is actually being
provided and we haven't actually identified the threat properly to evaluate
it's value.

Rather, let's work out a comprehensive solution for v2 that fully mitigates
a MiM threat

On 10 July 2016 at 09:29, Adrian Bateman <adrianba@microsoft.com> wrote:

> I'm not clear on what this is mitigating. If we're implementing things
> for security then we need to start by outlining the threat, understanding
> the risk/likelihood of any vulnerability, and then assess the cost of the
> mitigation.
>
> I can see some potential benefits for adding this (and we've discussed them
> before) but this doesn't seem to be necessary for v1 given that basic card
> is designed to be equivalent to autofill today.
>
> On Sat, Jul 09, 2016 at 08:52:16, Adrian Hope-Bailie wrote:
> >
> > Hi all,
> >
> >
> > We discussed putting together a more sophisticated card payment method
> > spec at the f2f but I wonder if we shouldn't raise the bar slightly for
> > the basic card spec before we go to CR already?
> >
> >
> > The obvious solution is encrypting the card data in the payment
> > response. The challenge is deciding what key and cipher suite to use and
> > that introduces a massive amount of complexity.
> >
> >
> > We can use asymmetric crypto and the merchant can provide a public key
> > in the request (either unique per transaction or not) which the payment
> > app uses to encrypt the response data. This would not eliminate MiM
> > attacks as a MiM could substitute the key for their own and still steal
> > the credentials. It would however prevent sniffing data from this
> > channel so that an attacker that is monitoring the events/logs but isn't
> > able to actually intercept the messages is thwarted.
> >
> >
> > I believe this is a simple enough solution that we could specify it as a
> > minimum bar and all payment apps/browsers would be capable of
> > implementing this from day 1. What do you think?
> >
> >
> > Note: I'm leaving talk of a more sophisticated solution where the keys
> > are bound to the merchant and can be verified by the payment app to
> > another discussion, there was a decent size group of volunteers in
> > London interested in exploring that topic.
> >
> >
> > Adrian
>
>
>