Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]

On Aug 29, 2012, at 1:43 PM, Ryan Sleevi wrote:

> On Wed, Aug 29, 2012 at 1:11 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>> The application's trust model does not totally depend on what UA tells it where the key comes from. This is a reference and a first level of checking. The application or the back-end server can verify operations done using the key and, hence, if the right key was used. What is the harm of telling the application since the UA knows the information?
> 
> The (significant) harm is that it requires us to figure out an
> taxonomy of key storage types, while still having the spec remain
> neutral about the details about how or what is implemented. The
> problem with such taxonomies, especially spec'd before any
> implementations exist, is that by framing the language in particular
> terms, you directly and indirectly influence what is seen as
> implementable and how things are implemented, and inevitably, the
> taxonomy fails when things are "like-but-not-alike", much like
> Keychain is "Local but not local" or a remote cloud storage is
> "Browser storage, but external"
> 
> Even simple, mechnical definitions such as "software, hardware,
> removal" are, in fact, subtle and complicated, and fail to classify
> even the existing types of key storage provided by common APIs today.
> 
>> 
>> Your quoted discussions mentioned that an application could not trust what UA said in a certain aspect. Is this the trust model of this API? Isn't the UA the one who implements the API? How would an application know to trust or not anything from the API?
> 
> Yes, the trust model of this API, as with every other client-side API,
> as with every other JavaScript API, as with every other crypto API, is
> that you should not and cannot trust the API. The API can lie or be
> subverted, and there is no way, as a server, to know this.
> 
> One of the core, most foundational, unconditional premises for web
> security, is never, EVER, trust the client.
> 
> The ONLY thing you should trust are things you know cannot be
> subverted. This would include trusting a key provisioned on a smart
> card, if you KNEW that the smart card could not be subverted, no
> matter how hostile the environment.

I'd like to restate this in more nuanced terms: the only thing you can trust is the out-of-band knowledge that a given key was originally placed only into a single specific piece of hardware. Then, *to the extent that you know how difficult it is to get the key out of that hardware*, you can trust that someone who proves they have the key also has the piece of hardware. In most cases you are balancing the cost to the victims of a successful attack against the costs to an attacker of performing the attack. It is probably possible to extract the key from most hardware devices, but in many cases it is very very expensive, requiring time, equipment and expertise. This is sufficient in most cases. It's rarely black and white.

Now, having established (to whatever trust level) that the user has a specific physical device, you can bootstrap more trust based on what you know about the security properties of that device. Maybe I know it had a secure OS when it shipped and so I can know something about the software being run now on that device, to the extend that I trust the security of the OS, etc.

However, your level of trust in the software may well be different from your level of trust in the key. If the key is in a removable hardware device then your level of trust in the UA is totally different than your level of trust in the key. Hence an indication from the UA about the source of the key is no more than a hint. It can be useful for directing the application correctly in the normal case where no attacker is present, but it's not useful in establishing trust.  

…Mark



> 
>> 
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Wednesday, August 29, 2012 1:27 PM
>> To: Lu HongQian Karen
>> Cc: Ali Asad; Seetharama Rao Durbha; GALINDO Virginie; public-webcrypto@w3.org
>> Subject: [+SPAM+]: Re: crypto-ISSUE-30 (where is the key ?): How does the application know where the key is stored ? [Web Cryptography API]
>> 
>> On Wed, Aug 29, 2012 at 11:21 AM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>>> While the keyLocation may not be a good name, the point is that the application should be able to request using a key from a desired location and be able to verify or has assurance that the key is indeed from the desired location. The key storage, such as a browser's or a local storage (a local DB or in html5 sense), is not the same as a cryptoProvider. The former stores keys, and the latter has access to keys and performs crypto operations. If cryptoProvider is confusing, we could replace it with specific external key locations, such as TPM, smart card (I was trying to avoid mentioning smart card). In any case, applications' trust models may require knowing that the key used in the web crypto API is in a trusted storage with a certain level of assurance.
>> 
>> As discussed on [1] and [2], this is not a workable trust model, and any application that relies on it is fundamentally flawed in security.
>> 
>> [1] http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0279.html
>> [2] http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0321.html
>> 
>> If an application requires knowing that a key used is in trusted storage, then
>> 1) The Key MUST be provisioned through means OTHER than this API
>> 2) The application should be informed of that (external) key and its trust assurance through out-of-bound means.
>> 
>>> 
>>> -----Original Message-----
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Wednesday, August 29, 2012 12:36 PM
>>> To: Lu HongQian Karen
>>> Cc: Ali Asad; Seetharama Rao Durbha; GALINDO Virginie;
>>> public-webcrypto@w3.org
>>> Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the
>>> application know where the key is stored ? [Web Cryptography API]
>>> 
>>> On Wed, Aug 29, 2012 at 10:02 AM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>>>> Hi Ryan,
>>>> 
>>>> I agree with you that Issue-30 needs more elaboration.
>>>> 
>>>> Regarding to keylocation, I was thinking
>>>> 
>>>> Enum keyLocation {
>>>>  None, // unspecified
>>>>  Browser, // browser's storage
>>>>  Local, // local storage other than browser's
>>>>  CryptoProvider // complexity: a user agent may have more than one
>>>> cryptoProviders };
>>> 
>>> The distinction between "Local" and "CryptoProvider" is fundamentally flawed in assuming an implementation detail - since an implementation may access "Local" (which I assume to mean 'OS storage', but in fact can mean much more) storage via CryptoProviders.
>>> 
>>> In fact, all Browser storage is could simply be another CryptoProvider.
>>> 
>>> So now we're down to only two (meaningful to web application) flags
>>> 
>>> enum {
>>>  None,
>>>  CryptoProvider
>>> };
>>> 
>>> And since you may have multiple cryptoproviders, suddenly you need ways to disambiguate crypto providers, and now you're back to an API that requires providers, which has been repeatedly agreed that is not a focus of this WG nor something that can be reliably implemented across user agents.
>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Karen
>>>> 
>>>> -----Original Message-----
>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>>> Sent: Tuesday, August 28, 2012 8:11 PM
>>>> To: Ali Asad
>>>> Cc: Seetharama Rao Durbha; GALINDO Virginie; Lu HongQian Karen;
>>>> public-webcrypto@w3.org
>>>> Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the
>>>> application know where the key is stored ? [Web Cryptography API]
>>>> 
>>>> On Tue, Aug 28, 2012 at 4:28 PM, Ali Asad <Asad.Ali@gemalto.com> wrote:
>>>>> To the Editors,
>>>>> 
>>>>> 
>>>>> 
>>>>> I suggest that we introduce a new section in Draft API document to
>>>>> indicate future planned work for key query/discovery and how it will
>>>>> handle pre-provisioned keys stored in secure elements. Here is the
>>>>> suggested text for this new section.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>>> 
>>>>> 
>>>>> 18. KeyDiscoverer Interface
>>>>> 
>>>>> 
>>>>> 
>>>>> IDL:
>>>>> 
>>>>> interface KeyDiscoverer : KeyOperation {
>>>>> 
>>>>>      void discover();
>>>>> 
>>>>>      KeyLocation location;
>>>>> 
>>>>> };
>>>>> 
>>>>> 
>>>>> 
>>>>> enum KeyLocation {
>>>>> 
>>>>>     // TBD
>>>>> 
>>>>> };
>>>>> 
>>>>> 
>>>>> 
>>>>> Editorial note:
>>>>> 
>>>>> 
>>>>> 
>>>>> The API for discovery and selection of pre-provisioned keys, for
>>>>> example those residing on secure elements such as smart cards, is
>>>>> not fully specified yet. However, once a key is selected from secure
>>>>> element, the implementing agent will ensure that all subsequent
>>>>> crypto operations are delegated to the secure element that contains this key.
>>>>> Additionally, the application will be informed that the user had
>>>>> selected a key from a secure element.
>>>> 
>>>> Hi Asad,
>>>> 
>>>> Just a quick note - I think the discussion related to key querying (that is, previously authorized or pre-provisioned) and key discovery (discovery of keys not explicitly granted) is too complex and the needs not well understood enough to support adding this to the draft.
>>>> 
>>>> I've made note to highlight ISSUE-30, but I have concern adding this API for FPWD.
>>>> 
>>>> In order to better understand what you're proposing here:
>>>> 1) Can you please provide a sample of what you imagine "KeyLocation" containing.
>>>> 2) Can you please provide a use case for how an application would use "KeyLocation"
>>>> 3) Can you please provide an example of how "KeyLocation" may be implemented by all conforming user agents, in a manner that is agnostic to the method of key storage they use?
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ISSUE-30: How does the application know where the key is stored ?
>>>>> 
>>>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> --- Asad
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Ali Asad [mailto:Asad.Ali@gemalto.com]
>>>>> Sent: Tuesday, August 28, 2012 10:26 AM
>>>>> To: Seetharama Rao Durbha; GALINDO Virginie; Lu HongQian Karen
>>>>> Cc: public-webcrypto@w3.org
>>>>> Subject: RE: crypto-ISSUE-30 (where is the key ?): How does the
>>>>> application know where the key is stored ? [Web Cryptography API]
>>>>> 
>>>>> 
>>>>> 
>>>>> I agree with Seetharama that once we start looking into key query
>>>>> API we can decide how best to incorporate the source information -
>>>>> ether in the query itself, or after the fact, based on user
>>>>> selection. But it is good to keep this issue 30 as a reminder that we have to do this.
>>>>> 
>>>>> 
>>>>> 
>>>>> Since there is little time before going to first public draft, we
>>>>> should at least add some text in the draft to indicate that this
>>>>> will be done later. I will write up a description around this today and send to the group.
>>>>> 
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> --- asad
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Seetharama Rao Durbha [mailto:S.Durbha@cablelabs.com]
>>>>> Sent: Monday, August 27, 2012 5:57 PM
>>>>> To: GALINDO Virginie; Lu HongQian Karen; Ali Asad
>>>>> Cc: public-webcrypto@w3.org
>>>>> Subject: Re: crypto-ISSUE-30 (where is the key ?): How does the
>>>>> application know where the key is stored ? [Web Cryptography API]
>>>>> 
>>>>> 
>>>>> 
>>>>> I am not raising another issue for 'query keys belonging to a type
>>>>> of storage' at this point - as there is no key query mechanism at
>>>>> this point. I think I heard Ryan saying that at some point in future
>>>>> we will have to get key query supported in the spec. At that point,
>>>>> we can add type of storage as another query parameter.
>>>>> 
>>>>> Please let me know if my understanding is not correct.
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Seetharama
>>>>> 
>>>>> 
>>>>> 
>>>>> On 8/27/12 2:49 PM, "GALINDO Virginie" <Virginie.GALINDO@gemalto.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Karen, Asad, and all,
>>>>> 
>>>>> As per your request of todays call, I have created an issue about
>>>>> the location of the key. Feel free to amend/comment its description
>>>>> and agree with the editors to make sure it is correctly expressed in
>>>>> the version of our draft API going to the FPWD.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Virginie
>>>>> 
>>>>> Gemalto
>>>>> 
>>>>> Chair of the Web Crypto WG
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> 
>>>>> From: Web Cryptography Working Group Issue Tracker
>>>>> [mailto:sysbot+tracker@w3.org]
>>>>> 
>>>>> Sent: lundi 27 août 2012 22:46
>>>>> 
>>>>> To: public-webcrypto@w3.org
>>>>> 
>>>>> Subject: crypto-ISSUE-30 (where is the key ?): How does the
>>>>> application know where the key is stored ? [Web Cryptography API]
>>>>> 
>>>>> 
>>>>> 
>>>>> crypto-ISSUE-30 (where is the key ?): How does the application know
>>>>> where the key is stored ? [Web Cryptography API]
>>>>> 
>>>>> 
>>>>> 
>>>>> http://www.w3.org/2012/webcrypto/track/issues/30
>>>>> 
>>>>> 
>>>>> 
>>>>> Raised by: Karen Lu
>>>>> 
>>>>> On product: Web Cryptography API
>>>>> 
>>>>> 
>>>>> 
>>>>> During our discussion on the 27th of august, the problem related to
>>>>> usage of keys stored in secure element has been discussed. While a
>>>>> previous issue (#11] has been already closed about the definition of
>>>>> a specific attribute for indicating if the key was stored in a
>>>>> specific secure element (or crypto providers), the problem about
>>>>> making sure the application is aware of the key location is still
>>>>> pending. The means for solving this specific problem do not need to rely on a specific attribute.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> 
>

Received on Wednesday, 29 August 2012 21:30:29 UTC