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

Hi Everyone,

I’ve been closely following the discussion over the last few days, and would like to throw in a few thoughts and suggestions. I’ve tried to pick out some of the major pain-points, at least, as far as I understand them, and write them down in a way that both web-wise and smart-card-wise people can relate-to. Here goes ..

Issue 1: Same Origin Policy concerns
SOP is a fundamental component of the Web Security Model. A major bone of contention seems to be related to the fact that large numbers of “centrally-issued” credentials currently in use are based on “physical world” identification models that require permissive visibility, a concept that is anathema to SOP and web privacy. For example, a government-issued e-ID must be usable wherever the citizen needs to be identified, a bank-issued payment credential must be usable anywhere the payment-card scheme is present, and so one. Current smart-cards use registered AppID’s (ISO7816 AID) to identify applications, a namespace totally unrelated to web origins.

Question: Can we remodel or adapt “centrally-issued” credentials and smart-card applications to fit into a SOP world, and how?  

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. 

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 <http://ident.gov.br/> 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 <http://id-provider.com/>” can restrict access to it’s own domain, and provide identity services a lá OAUTH/OpenID.

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. 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. 

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”? 

Note that GP-style permissions for app-usage are not needed/desirable for open web usage, given an adequate solution for the first issue above (SOP).

Issue 3: Web-application access to smart-card hardware
Different applications have different functionalities and different needs. No one-size solution fits all, and not all hardware-backed credentials and cryptographic tokens have the same raison d’être. Relying on platform-level support is insufficient, since although the platform offers the “physical” connection to the secure hardware (PC/SC reader, USB, NFC, embedded, BLE, …), some type of software convertor or driver will always be needed for an open system. Simply providing web applications with low-level “protocol” (APDU-style) access does not seem to be an acceptable option. The middleware sits between the web-app and the data-pipe to the h/w. For ISO7816 smart-cards and family, suitable middleware would be required for each different application on the card.

Question: Can and should the web be used to deploy middleware, or is this purely a platform problem?

Suggestion: 
Several of the recent proposals discuss using browser sandboxing capabilities to isolate the javascript-based middeware from the web-application. The middleware (either a browser extension, a downloadable “web-sec-app”, or something else) would be linked to, downloaded from, and potentially digitally signed by, the AppID’s origin. The middleware could implement PKCS#11, for example, and provide discoverable keys and a SubtleCrypto interface for “origin-linked” keys and credentials, or implement an EMV payments API, or whatever a specific application needs. Note that the smart-card application and the middleware share the same origin.

——
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 would be nice to have some feedback, both from the web security and the smart-card fields, thus comments and critiques welcome. 

Sean Michael Wykes
Nascent Technology Consultants





> On 2 Feb 2015, at 19:59, Ryan Sleevi <sleevi@google.com> wrote:
> 
> 
> 
> On Mon, Feb 2, 2015 at 1:54 PM, Siva Narendra <siva@tyfone.com <mailto:siva@tyfone.com>> wrote:
> Ryan -- if we are able to collaborate and come up with a web implementation architecture that not only encompassed FIDO, but also equally viable standards such as PIV Derived Credentials [1] and EMV Tokenization [2]....and such standards to come in other industries, will you be supportive of it. Or, you do not want to support anything other than FIDO?
> 
> Same question for Anders and Brad.
> 
> Best,
> Siva
> 
> [1] http://www.nist.gov/manuscript-publication-search.cfm?pub_id=914530 <http://www.nist.gov/manuscript-publication-search.cfm?pub_id=914530>
> [2] http://www.emvco.com/specifications.aspx?id=263 <http://www.emvco.com/specifications.aspx?id=263>
> 
> 
> Siva,
> 
> I'll echo what I've said publicly for the last three years:
> - If a proposal is put forward that can reasonably consider the Web Security model and fit within the privacy goals, it will be considered.
> 
> You've put forward a false dichotomy by suggesting it's "FIDO or legacy"
> 
> Without evaluating [1] or [2], if they cannot or do not fit the web security model, then unquestionably, I oppose and will continue to oppose them. FIDO respects these goals - and was designed with them first and foremost in mind - so it absolutely deserves consideration.
> 
> There has yet to be a proposal that demonstrates how [1] or [2], or any of the other legacy APDU systems, can be done in a way that preserves and respects security and privacy at the right layer (the origin). So naturally, I see no reason to block FIDO from being exposed, especially when three years have passed - in which time FIDO was written, implemented, and made mass-market available - while no such earnest efforts appear to have happened for legacy.