W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2012

Re: ISSUE 2: How to address pre-provisioned keys

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 23 Jul 2012 16:39:48 -0700
Message-ID: <CACvaWvYmwr9W-7o8aV23AJ2=B-ra71iJLKKqHPLKyGBFDQvp9A@mail.gmail.com>
To: Lu HongQian Karen <karen.lu@gemalto.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Jul 23, 2012 at 4:05 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
> ISSUE-2: How to address pre-provisioned keys and managing ACLs
> https://www.w3.org/2012/webcrypto/track/issues/2
> Since the key provisioning is out of the scope, the web crypto API should be able to discover existing keys and learn how the key should be used. We can imagine that the key has various attributes, including
>          Type of the key, length, value, etc.
>          Key store location - where the key is stored, for example
> o    Browser/local-storage, browser/secure-store, OS/secure-store, or smart card, etc.
>          Crypto provider name  who does crypto using this key, a hint for the browser, for example
> o    Browser, or smart card
> For example, for a pre-provisioned key in a smart card, it will have the smart card as the key store, and the smart card as the crypto provider. Web browsers already have ways for a user to choose which smart card and which key.

Hi Karen,

I feel like these points have been addressed on several of our calls,
but I appreciate you bringing them forward to the list so that we can
keep a good archive of these discussions.

As I've mentioned previously, I do not think "crypto provider name"
and "where the key are stored" are suitable to be exposed via this
API, and it was very intentional that I avoided proposing such a
notion with the strawman that has now migrated to the editor's draft.

"Where the key is stored" is not a secure/strong signal, since a
hostile/compromised script can easily be compromised. This has been
pointed out by several members during the call. Thus it merely acts as
an advisory signal, and because of this, doesn't really offer any
value, but may cause significant harm if applications treat it as a
'secured' attribute. This point was raised again on our most recent
call, on 7/16, with a similar discussion being had.

"Crypto provider name" is not a portable solution, and is very much
tied to the underlying cryptographic implementation. An example of
this is that one browser may interact with a key store via an opaque
OS API (such as Keychain on OS X), and thus have no knowledge about
how a key is implemented, one may interact via a PKCS#11 module and
thus only have the (non-localized) module name, which may vary for
users in different languages depending on the version of the module
they have installed, and another user agent may interact via CNG,
which uses key store providers.

Further, because both of these concepts are directly tied to smart
cards, they seem to be out of scope.

> One use case is a web application letting users to sign documents using their smart cards. The signature key pair is pre-provisioned inside the smart card. The key pair, hence, has the attributes: keystore=smartcard; crypto=smartcard. The application uses the web crypto API while the browser knows to use the smart card for the signature operation instead of its own implementation.

Thank you for providing this use case, since it provides an
opportunity to show why such an API is not necessary for equivalent
(but reliably secure) functionality.

Rather than exposing such information (which, as discussed above,
cannot be done so portably/reliably), applications might instead use
"pre-provisioned keys", within either the ontology I proposed or Vijay
proposed. The application should merely request that the user agent
perform the signing with Key X, where the application knows a-priori
that Key X is stored on a smart card. Thus, instead of a user agent
telling an application that Key X is stored on a smart card (where the
user agent may be deceptive or coerced), the application instead knows
this out of band, where such attributes can be delivered and vetted

Likewise, if an application is dealing with keys that were not
directly pre-provisioned by it (eg: a banking application that wishes
to use a government-issued smart card, which is a situation where the
smart card provisioner is != application consuming the web crypto
API), then it's fully possible that
- The banking application can inquire the user agent for accepted keys
 - Criteria might include certificates or issuers, as has been
discussed in "Secondary features" of the API and mentioned on previous
calls and threads
- The user agent can interact with the user to determine whether or
not they wish to grant access to said keys
- If granted, the banking application can interact with properties of
the key (such as signing a 'proof of possession' message, or
calculating the hash of the public key)
- The banking application can make a back-end (ie: wholly independent
of this API) call to the government issuer, asking "Did you issue Key
X to this User"
- The government issuer can inform positively or negatively, as well
as any other assertions (eg: this key is stored on a smart card)

Such solutions do not require any introduction of smart-card specific
key notions to this API.

Further, within the scope of secondary features, there exists
discussion about the exposure of X.509 certificates and meta-data
associated with keys. Such keys would be able to act as an alternative
for the (banking <-> government) backend. For example, if the banking
application knows that the government provider stores on smart cards
any key+cert pairs that chain to a given root, the banking application
need only verify that the signature chains to such a root.

A solution such as that equally does not require the API expose any
smart-card specific notions.

> In addition to listing available keys, it may be interesting to have API to discover browser-supported key stores and crypto providers.

I did not receive significant feedback on my KeyQueryList proposal,
which I believe addresses this in a way that is wholly agnostic for
crypto providers. It is in the process of being incorporated into the
editor's draft, to hopefully ensure its visibility.

As discussed on several calls, including the most recent one, the API
so far has not been designed around the concept of crypto providers,
but instead around interactions with keys. Even the concept of "key
stores" is not present in the API - instead, a single monolithic key
store is presented (whether via KeyQueryList, window.crypto.keys, or
ddahl's KeyAccessor).

I strongly believe that, having written applications that uses almost
a dozen different APIs, each of which has a separate notion of what
represents a cryptographic provider and how key storage is exposed,
that the notion of "crypto providers" is an inherently non-portable
notion, and any web applications written to such an idea would find
them limited to a very specific browser implementation, on a very
specific platform, and for very specific devices. Such a solution is
not generic enough to meet our criteria or the criteria of users of
this API.

While many implementations share similar concepts or abstractions,
such as the concept of providers, the functional details and naming
significantly differ, such that I do not believe it's possible to
define a generic Web Platform API that is not inherently bound to one
or two specific implementations (eg: CryptoAPI, CNG, PKCS#11, etc).

A concrete example of this is how the five different major desktop
APIs (PKCS#11, CNG, CryptoAPI, Keychain, CDSA) each refer to keys and
providers in different ways and with different abstractions. In the
above case, the /only/ commonality in their nomenclature is
identifying private keys by looking up their public key pair.

This is why I've strongly discouraged the notion that they be exposed,
and instead have focused on interactions with keys and key discovery.
While such an API is more abstract, it offers a way that applications
that are developed should be able to cross-operate between different
user agents on different platforms, each of which may be talking to
the same key backed on the same smart card, without requiring the web
application to specifically encode this knowledge.

My own preference would be to table further discussions of smart cards
until we've reached agreement on some of the other outstanding issues.
We've definitely identified smart cards and secure elements as out of
scope for this effort. The API I put forth and which we've been
discussing was done in such a way as to not preclude smart cards, if a
browser decided to implement/expose them, but absolutely does not
require any implementation whatsoever to be conformant.

As an implementor, I think it's worth mentioning that we have serious
security concerns about exposing smart cards to web applications, such
that any mandate to support them might lead us to not implementing the
API, and thus our initial focus will be solely on browser mediated key
storage. Past work such as SConnect or CAPICOM have shown that such
exposure creates a fertile ground for attackers, and it's an exposure
we'd like to protect our users from.


> What do you think?
> Regards,
> Karen & Asad
> Gemalto
Received on Monday, 23 July 2012 23:40:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:11 UTC