Re: I want to have unsafe key exchange.

On Sat, Jul 14, 2012 at 6:50 AM, GALINDO Virginie
<Virginie.GALINDO@gemalto.com> wrote:
> Vijay, Ryan, and all,
>
>
>
> Just to make sure we are on line on this topic :
>
> About a key to be extractable, Ryan wrote” it is up to the implementation
> and how it handles key”, my understanding of our conversations was that this
> ‘extractable capability’ should be defined at key creation. If it is really
> up to the implementation and will vary from one browser to another, then I
> think we do not help the developer to build consistent security : he will
> not be able to choose if the key could or not be viewed by the JS.
>
> Did I miss something ?
>
>
>
> Regards,
>
> Virginie

Whether or not a key is extractable is dependent upon how the key was created.

- If the key was pre-provisioned/re-used, then the keying material MAY
be extractable, dependent upon how it was initially provisioned.
- When provisioning a key, authors MUST be able to specify whether or
not they wish for the keying material to be extractable. If an
application cannot fulfill the request for (extractability,
non-extractability), it MUST fail the key provisioning.
  - "Key provisioning" includes key generation AND key derivation
- No requirements/interpretations are placed on what
"protected"/"non-extractable" means
  - It may mean stored unencrypted on the host OS filesystem, but JS
apps are prevented from access
  - It may mean stored with some sort of encryption, but still on the
filesystem, and JS apps are prevented from access
  - It may mean stored in a secure element

My point of implementation dependence was simply that the
specification should not specify how non-extractable is implemented,
nor should it specify that ALL keys MUST be extractable. It should be
fine if some keys are not - either at the authors request or (in the
event of pre-existing/pre-provisioned keys), at the time of external
provisioning.

Cheers,
Ryan

>
>
>
>
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: lundi 2 juillet 2012 20:53
> To: Vijay Bharadwaj
> Cc: Eric Rescorla; Wan-Teh Chang; David Dahl; Zooko Wilcox-OHearn;
> public-webcrypto@w3.org
>
>
> Subject: Re: I want to have unsafe key exchange.
>
>
>
>
>
> On Sat, Jun 30, 2012 at 12:11 AM, Vijay Bharadwaj
> <Vijay.Bharadwaj@microsoft.com> wrote:
>
> I'd like to advocate for not requiring the raw shared secret to be
> accessible to apps.
>
>
>
> I don't think it's required that the raw key be extractable - for exactly
> the reason that you specified.
>
>
>
> However, it may be extractable - it's up to the implementation and how it
> handles secrets. I think this is true independent of any discussion of
> secure elements - simply whether or not javascript content can/should be
> exposed to raw keys.
>
>
>
> Part of my goal is wanting to provide a useful API that provides a facility
> that, even if the browser doesn't implement (insert esoteric algorithm
> here), the application can route around it - either by utilizing a different
> algorithm (via discovery) or by implementing an algorithm in content (which
> requires raw access). Every new "standard" first starts off as something
> esoteric, and then is eventually implemented wide enough that it could
> rightly be considered standard.
>
>
>
> Since the web platform still has to contend with legacy devices, and will
> inevitably have to consider constrained devices as well, I want to make sure
> that content always has the possibility to gracefully degrade the
> experience, even as standards and technologies (such as DH + some KDF here)
> change.
>
>
>
>
> Many crypto modules (often for FIPS and other certification purposes) only
> expose the key agreement primitive (i.e. DH operation + a KDF) and do not
> expose a raw DH primitive. For the specific case of ZRTP, this would appear
> to be enough - ZRTP appears to be doing an SP800-56A key agreement (i.e. DH
> + SP 800-56A KDF) followed by another KDF (i.e. SP 800-108 KDF). This is
> achievable as long as we provide a KDF primitive. I do agree we must provide
> a facility for importing raw keys if we want to support any form of DH (as
> others have noted).
>
> I realize raw DH is useful in various places; but it's arguable that it is
> similar to mod-exp - a math-level primitive which is not essential to a
> crypto-level API.
>
>
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, June 18, 2012 12:41 PM
> To: Wan-Teh Chang
> Cc: Ryan Sleevi; David Dahl; Zooko Wilcox-OHearn; public-webcrypto@w3.org
> Subject: Re: I want to have unsafe key exchange.
>
> On Mon, Jun 18, 2012 at 11:34 AM, Wan-Teh Chang <wtc@google.com> wrote:
>> I think we should provide the commonly used key derivation functions
>> to reduce application mistakes.  But I find Zooko's challenge of
>> implementing ZRTP very thought-provoking.  Since the key derivation
>> function of ZRTP doesn't seem to be a common one, I believe that a web
>> browser will need to export the raw shared secret either in native
>> code or in JavaScript.  (I don't know of a native crypto API that
>> allows a caller to provide an arbitrary key derivation function.)
>
> I don't believe that this can be done without effectively allowing the
> application to extract the secret input if it chooses to.
>
> I.e., this is a cut point between two models of key isolation:
>
> (1) reduce application screwups by making it hard to access the key
> (2) protect against malicious applications accessing the key.
>
>
> -Ekr
>
>

Received on Monday, 16 July 2012 18:51:21 UTC