W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

Re: Additional use cases

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 7 May 2013 14:24:19 -0700
Message-ID: <CACvaWvbKbBf+jzee4774gtH76KcOz+osaD-cBua8_sUrhsv5ag@mail.gmail.com>
To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Cc: Seetharama Rao Durbha <S.Durbha@cablelabs.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Tue, May 7, 2013 at 2:17 PM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> Would it be beneficial to add an optional "key owner" authenticator that was stored with the key material?
>
> This would mean that a simple structured clone of the Key Object or cross-origin messaging (postMessage) would be blocked unless the authenticator was also made available.
>
> So, the key creation methods would need a nullable parameter added and the sign and decrypt would need the same.
>
> The authenticator could either be sent direct from the server, entered on the page, or entered in the UA.
>
> Regards,
>         Michael

Strongly opposed to this - you can see the (many) discussions of PINs
in the past, and why such security models fail to make sense -
including this most recent thread.

>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Tuesday, May 07, 2013 4:00 PM
>> To: Seetharama Rao Durbha
>> Cc: Lu HongQian Karen; Arun Ranganathan; public-webcrypto@w3.org Working
>> Group
>> Subject: Re: Additional use cases
>>
>> On Tue, May 7, 2013 at 1:35 PM, Seetharama Rao Durbha
>> <S.Durbha@cablelabs.com> wrote:
>> > Ryan
>> > I agree. I agree that every deployment comes with its own risks, and
>> > people come up with ways to mitigate them.
>> > In the Web Crypto case, it looks like the (strong) recommendations we
>> > make for deployments generating signatures are
>> >
>> > store keys with PIN (no way to automatically load them) Instruct your
>> > users to enter PIN only on sites using TLS with (EV) validated
>> > certificates
>> >
>> >
>> > Thanks,
>> > Seetharama
>> >
>>
>> I'm not sure how you reach those conclusions. It seems like it would be
>> useful for Arun's documentation to explain the rationale.
>>
>> The first assumption is we're talking about origin-bound keys - eg:
>> what the core spec declares, not about any other aspect or future work. If
>> you're thinking about smart cards or other keys, then our assumptions
>> about the security model are entirely different, and thus an entirely
>> different set of assumptions need to documented before we can reasonably
>> discuss the use case that explains the assumptions.
>>
>> With such per-origin keys, why can the origin not prompt (through its web
>> UI under the web applications control) a "PIN" prompt. What assurances do
>> you expect to realize if the "PIN prompt" is implemented in browser-chrome
>> versus in the web page.
>>
>> How does this compare with middleware prompting - which itself is "as
>> insecure" as having the webpage prompt.
>>
>> Also, note again, keys are per-*origin*. That means the HTTP version of a
>> site can never access the HTTPS keys - and vice versa.
>>
>> As for EV, that provides no added security value in practice, so it's not
>> worth mentioning.
>>
>> > On 5/7/13 11:48 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>> >
>> > On Tue, May 7, 2013 at 8:14 AM, Seetharama Rao Durbha
>> > <S.Durbha@cablelabs.com> wrote:
>> >
>> > With the ownership of the key based on SOP that is not cognizant of
>> > tampering (as of now), I am afraid that any discussion of signatures
>> > will be futile, they cannot be used for non-repudiation, at the end of
>> the day.
>> >
>> > http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0247.html
>> >
>> >
>> > I don't see why you equate the discussion of ownership at all with
>> > tampering/proof.
>> >
>> > Further, I don't know if your claims are entirely justified to say
>> > "They cannot be used for non-repudiation".
>> >
>> > A quick example of the many attack vectors that exist in today's
>> > applications - and yet are still somehow acceptable for
>> > non-repudiation:
>> > 1) Native executables may or may not be code-signed.
>> > 2) There is no way for native executables to verify that they have
>> > been properly code-signed with no malicious code injected. If
>> > malicious code was injected, it would just lie.
>> > 3) There is no way for smart cards to know whether or not the calling
>> > application is "legitimate". For example, it's not at all uncommon to
>> > see malware hijack smart cards (eg: see Sykipot)
>> >
>> > There are two realities here - the technical reality and the political
>> > reality. The political reality of non-repudiation likes to believe
>> > that today's solutions are acceptable - even though the technical
>> > reality is flawed.
>> >
>> > If these arguments all sound familiar, well, it's because I said the
>> > exact same thing in September - see the thread
>> > http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0156.html
>> > (and don't forget Anders' comments on public-webcrypto-comments at
>> > http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Sep/
>> > 0010.html
>> > )
>> >
>> > This disconnect has nothing to do with the ownership model of the key
>> > - either you accept some technical realities or not.
>> >
>> > For example, in the native code, you have no assurances that hostile
>> > code/malware is not running on the users machine. A PIN or password do
>> > nothing to mitigate this threat. If you accept those signatures, then
>> > WebCrypto should be the same. Your "code signature" is handled via TLS
>> > - and your signature verification can be bolstered via means such as
>> > pinning. Either you trust that code or you don't - no different (nor
>> > more flawed) than native.
>> >
>> > I'm sympathetic for those who want "more" assurances - but I want to
>> > make sure it's recognized how fundamentally flawed the argument is
>> > when compared to the already deployed, politically accepted reality of
>> > general purpose computing. If we're going to try and improve things,
>> > we must set reasonable expectations about what the real threats are
>> > and what the benefits are.
>> >
>> > If the only security guarantees for the Web API can be realized when
>> > on a fully restricted, user-hostile machine (eg: not the general
>> > purpose machine that the browser vendors represented here develop
>> > for), then I'm more inclined to suggest that it belongs elsewhere -
>> > such as SysApps or somewhere else - because it doesn't reflect a
>> > general pattern for an open Web.
>> >
>
Received on Tuesday, 7 May 2013 21:24:47 UTC

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