W3C home > Mailing lists > Public > public-web-security@w3.org > February 2015

Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

From: Siva Narendra <siva@tyfone.com>
Date: Mon, 2 Feb 2015 12:45:46 -0800
Message-ID: <CAJhTYQyNp1gt6fhiuiJwmd+J8sqvG7uAkTwsrk42_xxa9-8_jg@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>, Wendy Seltzer <wseltzer@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Harry Halpin <hhalpin@w3.org>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>, "public-web-security@w3.org" <public-web-security@w3.org>, Brad Hill <hillbrad@fb.com>
Hi Ryan --

Unless I'm mistaken, FIDO leverages such GP secure elements in its devices.
This was possible only because several companies already built such
standards (GP) based secure elements and devices, for use with the web,
even though web did not standardize its interfacing to such hardware. These
devices allow any application developer to take advantage of hardware
security, just like FIDO based application developers can.

What some of us are asking for is to make sure that when web supports
hardware security, that it be generic to support further innovation and not
be limited to FIDO.

I assume you do not object to this. Or is your view that all roads shall
lead only to FIDO?
Cheers,
Siva



*--*


*Siva G. Narendra Ph.D. CEO - Tyfone, Inc.Portland | Bangalore |
Taipeiwww.tyfone.com <http://www.tyfone.com>*
*Voice: +1.661.412.2233*


On Mon, Feb 2, 2015 at 12:32 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
>
> On Mon, Feb 2, 2015 at 5:28 AM, POTONNIEE Olivier <
> Olivier.Potonniee@gemalto.com> wrote:
>
>>  Ryan,
>>
>>
>>
>> What I’m saying is: WebRTC and geolocation API give access to personal
>> information (your voice, or your position). Any origin may request access
>> to these services, and the access control to these services is not based on
>> **same-origin policy** but on permissions. Your same voice, and
>> potentially your same position, may be shared with multiple origins. Both
>> can be used to track you.
>>
>> Of course the access control mechanism to a service has to be adapted to
>> the level of privacy/risk associated to the disclosed information.  And I’m
>> not saying the existing one is not adapted to WebRTC and geolocation API.
>>
>> What we are willing to define in W3C is a hardware backed-up crypto
>> service protected with an access control matching the sensitive nature of
>> secure hardware tokens.
>>
>> --
>>
>> Olivier
>>
>>
>>
>
> Oliver,
>
> The comparison here is about as apples and oranges as you can get.
>
> First, let's be clear: The access control to these services IS based on
> the same origin policy. It is ALSO based on permissions. It is not
> "either/or", but "and", and that is a critical distinction to note and
> realize. Granting permission to Origin A access to any of your capabilities
> does not and should not grant access to Origin B. That's (part of) what we
> mean by the same origin policy - only the SAME ORIGIN that was originally
> granted access to something continues to have access to it.
>
> Second, I think it's important to realize how flawed proposals are that
> rely on sharing access to the same device across multiple origins when that
> device has a level of persistence. That fundamentally violates many of the
> key security guarantees of the web, in that now Origin A and Origin B can
> independently influence eachother, collaborate, or otherwise be granted
> transient and ambient permissions.
>
> For example, when I grant Origin A access to my microphone, Origin B has
> no ability to influence that access whatsoever. It does not receive access,
> it can not influence how my voice is presented, nor can it simulate my
> voice to Origin A. Similarly, when I grant geolocation to Origin A, the
> capabilities granted to it have no ability to influence how Origin B
> behaves.
>
> Now, consider what's being proposed here by the hardware vendors on the
> list trying to ensure an insecure technology stays relevant in a web world
> where security is no longer optional: If I grant Origin A access to key
> material, it can impersonate messages from Origin B (if Origin B also has
> access). Similarly, if Origin A creates a key, Origin B can discover this
> key. Both of these fundamentally violate the origin separation that is
> crucial to the web.
>
> This is where the relevance to FIDO is all the more important - even
> though a single hardware token may be involved:
> - Origin A and Origin B have NO shared key store
> - Messages from Origin A are identified as such explicitly as part of the
> message construction, preventing it from being compared with Origin B
> - Persistent identifiers are (effectively) opaque, and thus user agents
> can provide a number of privacy enhancing means on this
>
> I hope you realize how geolocation/microphone permission models are thus
> apples & oranges to what has been proposed by Gemalto and Typhone, and
> similarly how FIDO and the legacy APDU-based smartcards are, similarly,
> night and day.
>
> ANY solution that attempts to expose these capabilities MUST have, as a
> first class citizen and intrinsic to the design, a model that recognizes
> origins as the basis for all security decisions. Keys MUST NOT be shared
> between origins AND messages MUST be attributable to origins are two basic
> requirements that are needed for any serious consideration.
>
Received on Monday, 2 February 2015 20:46:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 February 2015 20:46:38 UTC