RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

> In particular, start with an approach that "Everything is hostile _except_ the browser" and "Trust no one, not even 'trusted' parties".

Some of the use cases that HW vendors and technologies are trying to address do come with an approach that "Everything is hostile except the HW tokens/e-passports/TEE..." so that the users are protected - to some extent or even fully depending on the design - from a potentially hostile browser when they use some Web services.

It's obviously not that browsers themselves are vulnerable, but rather that there are many reasons for the host operating system itself to be under malicious control without the end-user being aware of it.

These are complementary approaches to security, necessary to build up several layers of defense in the interest of users.

Hervé

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: mardi 3 février 2015 03:08
To: Sean Michael Wykes
Cc: public-webcrypto-comments@w3.org; Siva Narendra; Harry Halpin; Anders Rundgren; Brad Hill; GALINDO Virginie; Lu HongQian Karen; Wendy Seltzer; public-web-security@w3.org; POTONNIEE Olivier; PHoyer@hidglobal.com
Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

On Mon, Feb 2, 2015 at 5:32 PM, Sean Michael Wykes <sean.wykes@nascent.com.br> wrote:
> Suggestion:
> We can start by mapping between smart-card “AppID"s (ISO7816-5 RID) and internet domains, such that a domain/origin can be identified as the owner of an RID. The internet already has IANA registries, DNS lookups, certificate authorities and even online lookups for “FIDO Application Facets”  (pls correct me if I’m wrong on this), so I sure this is feasible.

This doesn't really work. Setting aside the legal framework as to whether domains are property, domains do not represent permanent bindings. example.com may belong to FooCorp one day and BarCorp the next.

As to "online lookups of facets", just look at http://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-appid-and-facets-v1.0-ps-20141208.html

.. Note that any additional grants require that the FacetIDs belong to the same administrative domain boundary (e.g. what is used for cookie scoping, aka the "effective TLD + 1 name component")

> Once the user-agent can determine an origin is for the credential/application, it can do SOP checking and permit or deny access to the smart-card application based on the page origin. This can be extended using something like CORS/CSP, to enable the origin site to “delegate” permissions where necessary, using wildcards. If ident.gov.xx wishes to allow access to “*.gov.xx” it can, but can also decide to allow access to “*.com.xx” or even “*”, if it so wishes. On the other hand, “id-provider.com” can restrict access to it’s own domain, and provide identity services a lá OAUTH/OpenID.

The problem with this delegation is that it works against the user's interests and violates the priority of constituencies.

That is, the user may _not wish_ that their credential be usable to *.com.xx or even *. In the incentive model, every service provider has an incentive to ensure their credential is as widely used as possible, precisely because it favours their ubiquity of deployment. To the user, this is anathema to privacy - granting access to that credential allows persistence of tracking and collapses the effective security model for that credential into "the weakest link in *", which will, of course, be weak as all get out.

The FIDO model does not _expand_ grants of privileges (beyond the scope of the existing web model); rather, it could be argued that it exists to _restrict_.

> Issue 2: User-control of centrally “issued” devices/credentials The 
> web is based on a fundamental premise of user-choice. Contrary to this, Global Platform style access-control models and application-loading permissions are based on the idea of centrally managed devices. For bank-issued payment cards and gov-issued e-ID cards, this makes a lot of sense, and is not really a problem.

I would disagree here, in that governments should hardly be more trusted to keep their citizens' interests at heart compared to corporations and their consumers. Indeed, private corporations run more risk of consumer backlash, whereas short of an insurgency, most governments at a whole are isolated from their citizenry.

> For carrier-issued USIM and eSE devices, there is a fear of lock-out due to the carriers dominant position within the mobile device. The ideal situation would be one in that the user has full control over his/her device. Note however that the problem here is one of who “controls" provisioning (installation of secure applications), not who “uses” the credentials.

The user. The user. The user always controls.

> Question: Can and should the internet support both “centrally-controlled” devices and “user-administered” models?
>
> Suggestion:
> The GP protocols are the de-facto standard for smart card provisioning, with an honorary mention for MULTOS and it’s public-key based alternative. Both can be supported via a “pipe” mechanism to an “admin" AppID owner (thus obeying SOP). Going forwards, the smart-card/secure-chip industry can and should develop alternative methods that permit greater user-control over loading and deleting applications, in a secure fashion (easier said than done, of course!). How long until we see the first “smart-card app-store”?

And until such a solution exists where the user is in control, it doesn't really bear discussing, does it? If we recognize that the proposal fails to respect the priority of constituencies, shouldn't the proposal be ignored until it does?

> Suggestion:
> Several of the recent proposals discuss using browser sandboxing capabilities to isolate the javascript-based middeware from the web-application.

This, of course, is based on a misunderstanding of browser sandboxing and how it works. It's not some magic sprinkle sauce to be added as the solution celebre for all our security woes. It requires a careful and concrete understanding of the risks and the trust model.

In this model, explain why:
1) The user should trust that the middleware is acting in their interests
2) The browser should trust that the middleware is acting in the users interests

Put differently, what would prevent iwanttotrackyou.evil.example.com from having "Evil Middleware" that fails to separate out per-origin the keys being used, and instead offers a persistent tracking identifier?
What would prevent FooCorp from installing "Evil AppID" onto all of the TPMs they ship on their Smart Televisions, restricting access unless you consent to "Evil Middleware"?
What would prevent BarCorp from creating "Earnest Effort Middleware", where they try to do the right thing, but botch security miserably.

This solution is, in effect, a suggestion that the JavaScript language replace the Java VM as our generic "write once, run everywhere" driver solution, with roughly the same consideration for security considerations and implementation correctness. The benefits of solutions _like_ FIDO (lest I be seen as arguing FIDO uber alles) is that they can be freely implemented _in the user agent_ and the user agent can itself verify the protocol is securely and correctly implemented, as can anyone else. This is a vastly different trust model than the "trust JS from Honest Achmed"

> There are other issues, and the proposed solutions / suggestions are somewhat freshly-baked, but can we get any consensus on what problems we need to solve and how? We clearly need to find some common ground, and find ways to adapt ISO7816 smart-card paradigms, many that date from the 1970/80’s, to a 2015 web with basic security premises such as SOP.

It depends on your definition of "we".

"We" is not public-webcrypto, nor is it public-web-security. "We" is the people and vendors who wish to promote such technology for the Web. They (not "we") have an onus to work to understand the issues and attendant security concerns, and look to explore if there are solutions that they can adopt to work with this. I think you've made a good faith effort to decompose the problem, and I think with further thought and consideration, it might yield a fruitful result. But I don't think it's incumbent upon the WebCrypto WG to solve, hence the opposition to "exploratory chartering".

In particular, start with an approach that "Everything is hostile _except_ the browser" and "Trust no one, not even 'trusted' parties".
That's the foundational premise of Web Security. Further, if you find yourself resorting to the notion of prompting, put on your UA hat and ask the following:
1) What is it we need to ask of the user?
2) Can we be assured that what will happen is what the user expects?
3) Do we expect the user to understand this?

Most problems - including ones in use today - fail this test, and UAs are trying very hard to do better.

For example, allowing Geolocation over HTTP fails sniff test #2 (we can't be assured that there is not a MITM attempting to determine the users' location). Prompting "Do you want to allow access to Key X"
fails question 3, and there is not even a semblance of hope that a browser can ascertain #1, thus cannot know #2 either.

Received on Tuesday, 3 February 2015 09:31:23 UTC