Re: Need for Smart Card support

On Mon, Jun 11, 2012 at 5:34 PM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

>  One possible solution to your privacy problem is to always have the user
> agent reject such a request if it is received from an unknown site, then
> prompt the user asking them if they want to provide credentials to the
> site. If the user agrees, the site is added to the known list and the page
> is reloaded. So the server can still probe the client, but only if the user
> agrees to let it do so.****
>
> ** **
>
> There is a potential issue with having to reload the page in such
> situations, but it should be manageable with some best practice guidance
> for developers.
>

Perhaps you could elaborate a bit on this.

Would the server be granted access to all keys the user has? If so, does
that present new privacy/security risks? If it does, is it reasonable to
expect users are well-informed and knowledgeable about these risks to make
a balanced decision? If not, will it condition them to simply "Click
through" the warnings (as has been shown on other forms
of interstitials/prompts, typically of much greater security risk).

If the user is not granted access to all keys, can they indicate criteria
for which to select keys? If so, how would one mitigate attacks such as the
timing-analysis attack I gave, where the response time to different
requests acts as an oracle for whether or not the user has a key available?

One idea that I haven't really fleshed out, and that I'm not sure how
comfortable I am with, would be to have some sort of event that the web
site could listen for when keys become available. This would fit into the
"key management" scenario. I'm not sure how comfortable I am with it mostly
because it feels at first glance like it may lean too much into "secure
element" territory, but it may offer a way to resolve this privacy concern.

As I see it, there's two parts of the API needed:
1) An intent, by the web site, to indicate interest in keys matching
certain criteria
2) A confirmation, by a user, that the web site is authorized for such keys.

A very, very bad pseudo-API that I haven't thought through entirely, and is
effectively something very similar to the MediaQueryList interface [1].

interface KeyQueryCriteria {

// Some sort of criteria such as algorithm, mode, id, etc
// It may even indicate keys that are bound to certificates, where the
certificate meets some criteria (eg: as is done in SSL/TLS client auth and
for document signatures)

// Multiple criteria are ANDed together. OR is handled by creating multiple
listeners. NOT is not supported?

}

interface KeyQueryList {

readonly attribute KeyQueryCriteria criteria[];

void addListener(KeyQueryListListener listener);

void removeListener(KeyQueryListListener listener);

}

[Callback, NoInterfaceObject]
interface KeyQueryListListener {

void onKeyAdded(KeyQueryList kql, KeyID keyId);

void onKeyRemoved(KeyQueryList kql, KeyID keyId);

}



A web site may use this by doing something like:

var kql = window.crypto.queryKey([Some, Criteria, Here]);
kql.addListener({
  onKeyAdded: function(query, keyId) {
  },
  onKeyRemoved: function(query, keyId) {
  }
);


KeyID may be a string identifier or may be a handle to an existing key
(whatever is appropriate, I'm not sure).

The benefit of such an approach is that, once a U-A knows of a websites
desire to use keys of a certain criteria, it can take appropriate
asynchronous action. For example

   - If the user already has a key / a set of keys matching the criteria,
   it may prompt them non-invasively (eg: what Chrome calls the infobar, but
   other U-A's may choose different schemes and offer different management
   options) asking if the user wishes to allow the site access to the key.
   - Further, if a U-A knows the user has a smart card / secure element
   with that key, and it's not presently inserted, it might prompt them
   (non-invasively) to insert the secure element into the reader.
   - If a non-prompt scheme is adopted, the website itself may prompt the
   user to insert the secure element, if it knows apriori that the key it
   desires is stored on a secure element. Once the element is inserted, and
   the U-A sees that a new key/set of keys are available, it may then notify
   the site.

If the U-A never receives an onKeyAdded event, it doesn't provide
information to the site about whether or not the user has a matching key.

Now, I certainly haven't thought of all the ways this can be thwarted, and
it may be a completely broken proposal, but it may offer a solution for
those that desire richer smart card interaction *and *offer a solution that
provides for stronger privacy protection, if we're allowing pre-provisioned
keys.

Would the above (sort of) API meet your needs?

[1] http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface

> ****
>
> ** **
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Monday, June 11, 2012 10:50 AM
> *To:* Lu HongQian Karen
> *Cc:* David Dahl; Ali Asad; James L. Davenport; public-webcrypto@w3.org
>
> *Subject:* Re: Need for Smart Card support****
>
> ** **
>
> On Mon, Jun 11, 2012 at 10:25 AM, Lu HongQian Karen <karen.lu@gemalto.com>
> wrote:****
>
> The crypto API itself (for encryption, signing, hash etc.) should be
> generic without specific reference to hardware devices.****
>
>  ****
>
> A web application or the user should be able to choose which crypto
> provider (implemented in software or hardware) to use, which may be default
> to the one built-in the browser or OS. A hardware secure element may
> implement a different crypto provider. This approach has been implemented
> in current browsers (or add-ons) so that SSL/TLS mutual authentications are
> possible. Users can choose which crypto provider to use, for example,
> select her smart card. The problems are: first, the crypto functionalities
> are only available to the web browsers but not to web applications; and
> second, different OS’s and browsers uses different API’s (Microsoft’s CAPI,
> Apple’s CSSM, PKCS#11 for everyone else). ****
>
>  ****
>
> May be choosing crypto providers and accessing hardware devices belong to
> different working groups?****
>
>  ****
>
> Regards,****
>
> Karen****
>
> ** **
>
> I certainly don't speak for the chairs/WG, but as an implementer, I would
> specifically want to avoid re-implementing APIs in which "selecting crypto
> provider" was a core design point of the functionality. Web pages don't
> derive any cryptographic value from knowing the crypto providers on a users
> system without implementing some form of proof-of-possession (since the
> users system may lie), and the user significantly loses privacy and the API
> loses portability. I also think the user is not particularly well-served,
> in that most users do not have any cryptographic background, and thus
> presenting them with a choice of cryptographic providers is asking for
> information that they cannot reasonably (as a novice) provide.****
>
> ** **
>
> SSL/TLS client authentication, as implemented in browsers today as part of
> their core implementation (eg: discounting addons), does not require the
> user to have any particular knowledge about any secure elements, providers,
> or their implementation. The user simply selects a "certificate".****
>
> ** **
>
> To that end, I think as far as users, browsers, and sites go, if there
> does need to be any recognition of a pre-provisioned key, and that requires
> some degree of user interaction (perhaps to grant permission to that origin
> to use that key), then a similar approach can/should be used.****
>
> ** **
>
> I think one of the big concerns about 'secure elements' is that they
> typically represent high-value keys. This can be both directly high value -
> eg: this is the key I use to authenticate with my bank - or they may be
> indirectly 'high value' - if I know you have this key, I can track you
> across multiple origins and it's expensive/impossible for you to disable
> this tracking ('supercookie'). This is why I think any specific handling
> for 'secure elements' may be better served once we've laid a solid
> foundation, and then we can explore what the interaction scenarios would be
> for these elements.****
>
> ** **
>
> Depending on how we handle key identification, it's concievable that there
> may be an API for something like:****
>
> (Website -> User) "I would like to use any keys identifier by X Y or Z if
> you have them"****
>
> (Browser -> User) "The site at domain foo wishes to use the following key:
> X" (user doesn't have Y or Z)****
>
> (User makes selection)****
>
> (Browser -> Website) "The following keys are now available: X"****
>
>  ****
>
> However, even such a trivial exchange carries with it security
> complications. A website could then try to enumerate all the keys the user
> has by measuring how long it takes the user to respond. If the user can
> respond instantly, the site can assume the user has no keys identified by X
> Y or Z, while if there is some delay, it might assume the user possesses
> one or more.****
>
> ** **
>
> Unlike other APIs (such as filesystem or geolocation), the mere act of
> saying "no" yields an attacker information, which is why we must be very
> careful, and why I'm very hesitant towards supporting such efforts
> initially.****
>
> ** **
>
>   ****
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Friday, June 08, 2012 1:45 PM
> *To:* David Dahl
> *Cc:* Ali Asad; James L. Davenport; public-webcrypto@w3.org****
>
>
> *Subject:* Re: Need for Smart Card support****
>
>  ****
>
>  ****
>
> On Fri, Jun 8, 2012 at 9:43 AM, David Dahl <ddahl@mozilla.com> wrote:****
>
> Of course, the existing PKCS#11 routine (Prefs->Advanced->Encryption) in
> Firefox is a way to register a device. Perhaps I am under the impression
> that the API would govern the registration of hardware modules?****
>
>  ****
>
> I would think that would definitely be out of scope.****
>
>  ****
>
> "Registration of hardware modules" inevitably involves native code, and
> the idea of a JavaScript API allowing sites to install native code is a
> non-starter. Further, as noted in the charter and as Harry noted,
> specifically trying to avoid that as it involves device-specific calls.***
> *
>
>  ****
>
>
> I need to read up on how other browsers do this - and how NSS deals with
> crypto hardware and keyIDs. I think the real question here is does the API
> not have to do anything, just have the keyID passed to it to operate? All
> of the implementation details are hidden from the API, and things
> just work?****
>
>   ****
>
> I would prefer that, in our first draft, and consistent with the charters
> goals, that any awareness of smart cards or secure elements be left out.
> Simply dealing in key IDs is, I believe, sufficient enough to support the
> core use cases and primary goals, and also gives implementors the
> flexibility to expose keys stored in secure elements in an
> implementation-independent way that is compatible with the core API.****
>
>  ****
>
> For web developers, the nature of whether or not a key is stored in a
> secure element is unknown/unknowable to them - they have simply have a key
> ID, for which they can do the appropriate low or high level crypto
> operations.****
>
>  ****
>
> At the risk of fueling a fire, I do not believe the "this key is in a
> secure element" can be reliably exposed to applications, both due to the
> web security model and due to the vendor-specific nature. As Anders
> Rundgren repeatedly pointed out during the community group and the activity
> on the public-identity mailing list, proof of possession/proof of a key
> being within secure element has been a fundamental challenge in crypto, one
> which inevitably requires significantly more complex *protocols* that
> simply don't belong within a generic, simple API for signing/encrypting.
> Anything short of such complex schemes/protocols can easily be faked, and
> thus add zero security or programmatic value and only hinder further
> progress.****
>
>  ****
>
>
> Cheers,
>
> David****
>
>
> ----- Original Message -----
> From: "David Dahl" <ddahl@mozilla.com>
> To: "Ali Asad" <Asad.Ali@gemalto.com>
> Cc: "James L. Davenport" <jdavenpo@mitre.org>, public-webcrypto@w3.org
> Sent: Friday, June 8, 2012 11:18:56 AM
> Subject: Re: Need for Smart Card support
>
> ----- Original Message -----
> > From: "Ali Asad" <Asad.Ali@gemalto.com>
> > To: "James L. Davenport" <jdavenpo@mitre.org>, public-webcrypto@w3.org
> > Sent: Monday, June 4, 2012 9:32:25 AM
> > Subject: RE: Need for Smart Card support
> >
> > I think it will be good to have an option for interacting with secure
> > element (smart card being one example) in the API. Browsers that
> > choose to support it can implement it while others can skip it. But
> > the fact that it is there in the API will allow creation of secure
> > applications (as indicated by the use cases below) for those
> > interested in them.
> >
>
> I would like to see what the interfaces for this look like.
>
> A. How does the browser (in a cross-browser and platform way) know about
> the secure element? In other words, how is the secure element registered
> with the browser?
>
> B. Does the secure element appear to the browser as another software API
> that can be called, e.g: window.crypto.secureElement.* ?
>
> * or *
>
> C. Does the secure element export keys which the browser imports and uses
> like any other keys that have a key handle?
>
> I wonder what this looks like in practice. Is this a combination of crypto
> API + new browser features that 'register' the secure element with the
>  browser?  It does not appear an API can do all of this alone.
>
> Cheers,
>
> David
>
>
>
>
> ****
>
>   ****
>
>  ** **
>