Re: Running "Trusted Code" on the Web?

On 02/27/2015 05:12 PM, Anders Rundgren wrote:
> On 2015-02-27 22:14, Manu Sporny wrote:
>> On 02/27/2015 04:44 AM, Anders Rundgren wrote:
>>> That is, the card is never directly exposed to potentially 
>>> malicious merchant code.
>> 
>> Except in the case of some of the more recent merchant store 
>> breaches. :)
> 
> Yes, but that is the card-not-present scenario which is not what I 
> illustrated.

No, it's not.

BlackPOS/Kaptoxa and the Target breach was a card present attack:

http://krebsonsecurity.com/tag/target-data-breach/

The malware would read mag stripe data off of the card as it was swiped.
Card present.

>>> Now if you rather go to the Web, you'll find that the entire 
>>> concept "Trusted Code" is missing!
>> 
>> It is... because it's a really, really hard problem to solve, and 
>> there are multiple layers of what "trusted" could mean.
> 
> Essentially it means known code that has been supplied in such a way
>  that it has a certain level of trust like from an AppStore.

Doesn't matter if you have a trojan on the device scraping memory, as
was the case in BlackPOS. That's why a number of people in the group
believes not transmitting the sensitive data in the first place is the
best path forward.

> AFAIK there are two solutions: - Signed and packaged web-code

Which, demonstrably, wouldn't have prevented the biggest card fraud
cases this year.

> - Calling external native code from the web

Which, again, wouldn't have prevented the biggest card fraud cases this
year as portions of the card stripe data would still be transmitted.

EMV-only would've stopped the theft, as would some system that would
transmit some sort of cryptogram instead of some easily stolen and
re-used card number.

>> Your comments above are very broad brush, so there's not much 
>> actionable in this email, what is the point you're trying to make 
>> and the action you'd like the group to take?
> 
> True this question is out of scope but it might be good knowing about
> it when doing a security analysis so you don't end-up like: 
> https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html

That email was enlightening, thanks for that. :)

What you're suggesting, though, is a demonstrable non-solution. What is
wrong with the current proposal of "don't expose the sensitive payment
data to any system held by the customer or the merchant?" Isn't this
approach simpler than creating a secure execution environment for Web
code (if that's even possible)?

I think you're right in that we need something like web intents to
transmit non-sensitive payment messages and cryptograms from browsers to
native apps (like wallets) and back. I'm not so sure we need a secure
execution environment for Javascript code.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Saturday, 28 February 2015 02:30:28 UTC