Re: Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

On 9/15/15 5:29 AM, Ryan Sleevi wrote:
> On Mon, 14 Sep 2015 16:13:45 -0400, Kingsley Idehen wrote:
>
>      1. Local Browser hosted Key Store -- Mozilla & Opera are examples
>
>
> This has not been true for Opera for some time, not since they
> switched to Chromium.

Ah! That's indeed correct, I just checked Opera. Thus, we are left with
Mozilla as the only browser that still only works with its in-built
keystore, right?

>
>     How are Mac OS X keychain or Microsoft keystore problematic?
>
>
> That's no more reasonable a question, nor any likelier an answer, than
> asking "How can I exploit font rendering bugs in Windows", "Can you
> give me a font exploit?", or "How can I exploit GPU driver bugs".
> Which was the whole point of the paragraph you replied to.

My point is that native OS keystore are superior to those hosted
Browsers, in regards to OS user security. A Browser is an OS-hosted
application.

>
>     > Every desktop operation relevant for discussion allows direct 
>
>     > interaction with the OS keystore w/o OS level authentication
>     challenges. 
>
>      
>
>     That simply isn't the case with Keychain (Mac OS X) or Keystore
>     (Windows).
>
>
> Well, that's not a productive advancement of the conversation. Yes, it
> is the case, because you can observe this today with both <keygen> and
> application/x-x509-user-cert, as your fellow WebID supporters encourage.

Please understand that we provide a native [1] and Web accessible [2]
certificate & private key (crypto data) generator that supports:

1. pkcs#12 file generation - for manual crytpo data import
2. use of <keygen/> to generate crytpto data en route to keystore storage .


In regards to "productive advancement of the conversation" I am actually
trying to isolate the fundamental problem at hand, in civil tone. I know
what I am trying to get at here, so please read on...

>
> Go to a site with a <keygen> tag in Safari or Chrome. See that it
> inserts a key in your (OS) key store.
> Go to a site that delivers an application/x-x509-user-cert for a
> certificate that you have a key to. See that it inserts a certificate
> into your (OS) certificate store.
> Go to a site that requests a TLS client certificate, and use the
> certificate you just created. See that there is no OS-mediated prompting.
>
> It's a demonstrably and factually false statement to claim there's an
> interactivity requirement, provided by the OS, by default. There isn't.

Okay, to be much clearer, rather than "crypto data" I should have said:
X.509 Certificate & Private Key.

My statement is indeed inaccurate, as it was characterized. You can use
the combination of <keygen/> and the "application/x-x509-user-cert"
content-type to place a Certificate and Private key in Keychain on Mac
OS X, and other keystores.

> Can a user configure one? Sure. Does their system quickly become
> (practically) unusable? Absolutely. Are there myriad ways to bypass
> those OS prompts? Yup.
>
>     > Additionally, two out of three of the mainline mobile operating 
>
>     > systems allow such interaction w/o any OS level authentication 
>
>     > challenges. 
>
>      
>
>     It would be helpful if you named the operating systems in question
>     here.
>
>
> I'm somewhat surprised it wasn't abundantly obvious. iOS, Android, and
> Windows Phone. iOS, as I noted, provides no such functionality.

Correct, as I've found out by retesting our apps, down the <keygen/> route.

> Android always forces you through an OS-mediated prompt when importing
> certificates (the application/x-x509-user-cert flow), but not so for
> keys (the <keygen> flow). Windows Phone supports neither, but doesn't
> require OS interaction to add a key.
>
>     I am referring to adding anything to the keystore.
>
>
> Well, then it makes it an easy and practical example to demonstrate
> that your statements about forcing OS mediation are false.

Yes, because our app supports both pkcs#12 and <keygen/> and I always
use the pkcs#12 option. Anyway, you are correct in regards to this issue
of unfettered access when adding certificates and private keys to
keystores via <keygen/> .


> After all, the very crux of some of the arguments put forth here are
> that "<keygen>+application/x-x509-user-cert are the only way to do it
> without user interaction" - so you cannot reasonably or rationally
> argue that the either the modern desktop or mobile OSes require user
> interaction to make a modification to the key store (<keygen>), to use
> the key store (TLS client certificates), or to make a modification to
> the certificate store (application/x-x509-user-cert).


No! As I will demonstrate, <keygen/> isn't the only option. It is an
option we give to the user if they choose to use it. We also give them
the option to generate a pkcs#12 file.

We offer choices.

> To simply use the WebID flow on any browser with OS level integration
> and support for these features (which across all platforms, leaves
> only Chrome), and you will see there is exactly one and only one
> platform where you're given an OS-mediated prompt, and that's Android,
> and that's only when adding a certificate to the certificate store,
> not a key to the key store.

Yes.

>
>     It would be helpful if you could list those operating systems
>     that provide unfettered access to their keystores, in regards to
>     crypto data.
>
>
> Windows. OS X. Linux. Android.
>
> Or perhaps you've played a terminology shift, and you're no longer
> talking about 'modification' to the key store (as you did in the
> message I replied to, and as you did in the majority of the message
> here, including earlier in this message), and are instead talking
> about something entirely different, which is access to the underlying
> key material (which I suspect you're calling crypto data).

Somewhat.

I was looking at *access* to Certificate and Private Key, but have been
clearer anyhow.

>
> In that case:
> Windows. (Keys are just CryptProtectData'd, occasionally with an ACL
> which is no different than Master Password and allows any application
> access to the keys)
> OS X. (Code Signing ACL's in the keychain can be bypassed several
> ways, and the default creation mode of keys is fully exportable key
> material to any application that wishes)
> Linux. (I'm presuming NSS here, since that is the only widely deployed
> library with a dedicated "Key Store" functionality, and is
> conveniently used by both Firefox and Chrome on Linux. Here again, the
> "Master Password" does not make keys unextractable, as any application
> with the password can request the material, and any party in
> possession of the password can modify or inspect the store)
> Android. (Yet again, the default of the OS is to allow the key
> material to be exported if access is granted to the key handle and the
> key was not explicitly created in a way to make the key material
> unextractable)
>
> (iOS is conspicuously absent because the only way to modify the system
> key store is via an Apple developed application, due to keychain ACLs,
> and the only Apple-developed application that will modify the system
> key store is the Mobile Device Manager. Applications are free to
> modify their own per-application key stores and certificate stores,
> however, in which case, they could ostensibly be included in the lists
> above if someone were to develop a non-Apple-branded browser that runs
> on iOS.)
>
> Unless, of course, "those operating systems that provide unfettered
> access to their keystores" is meant to say "those operating systems
> that provide unfettered access *to webpages* to their keystores". In
> which case, well, nothing, because no such implementations exist in
> mainline browsers. That's because I worked quite hard to keep it out
> of scope of the Web Crypto charter, and rightfully so, as you seem to
> recognize the inherent danger of providing ANY application - whether
> web-based or native - unfettered access to the OS key store.

Yes, I am aware of the potential problems associated unfettered access
to any keystore. That said, based on my general usage pattern, I
overlooked that fact that inserting a Certificate and Private Key into
most keystores is indeed unfettered where <keygen/> is supported.

At this juncture, the fundamental issue with <keygen/> is that a web
page can slip a Certificate & Private Key into a user's keychain /
keystore, surreptitiously.

From a WebID-TLS perspective (and PKI in general), bearing in mind the
facts about <keygen/> and keystores, protected-resource-access will
always lead to a keystore access challenge prior to giving a user agent
access to a stored Certificate and Private key. The same thing applies
when attempting to set "trust levels" for certificates in keystores.

> It seems at least on that point, we might agree, even if that's not
> what you actually said, and knowing it's the exact opposite of what
> was requested by your fellow <keygen> enthusiasts :)

I am not a <keygen/> enthusiast, I am simply enthusiastic about apps the
provide end-users with choices. And in situations where said choices are
problematic I prefer to have those problems explained to users rather
than making "big brother" decisions on their behalves.

For those of use that support WebID-TLS, we don't have any issues
raising security alerts (or concerns) in the relevant specs and
guidelines for implementers.

>
> We're far, far into the weeds here to the relevance of <keygen>.
> Unfortunately, much of which you have presented in the thread as
> description of behaviours of OS handling has yet to be technically
> accurate yet, but that can be easily demonstrated empirically.

As per my comments above, I could have been clearer, and I do believe we
have actually made a lot of progress here.

> Worse, however, none of what you describe as possible functionality
> provided by the OS-mediated keystore, but not by a browser-based
> keystore (such as WebCrypto), reflect the reality of <keygen>
> implementations, so it's arguably a distraction from the discussion at
> hand.

No, I think it's actually brought an important <keygen/> issue to the
fore. That said, not enough for <keygen/> to be removed from HTML5 spec.

Fundamental <keygen/> concern scenario:

1. User visits Web Page
2. Certificate and Private Keys end up in user's keystore
3. User visits a site -- maybe coaxed there by some malware
4. User accepts defaults during authentication challenge -- security
illusion for an unsuspecting end-user that doesn't even understand what
certificates are  per se.
5. User's system is utterly compromised.


Alternative:

1. User's are educated about Certificates, Digital Signatures, and Identity.
2. <keygen/> is improved .

For WebID-TLS:

A certificate that's surreptitiously added to you keystore doesn't
guarantee access to a protect resource since access control is
ultimately based on the semantics of entity relationship types using to
define access controls i.e., the resource owner can use an combination
of identity related attributes to constrain resource access [3].

>
> As such, this will be my last reply on this thread, because it's clear
> we've gone so far away from the topic at hand that there really is no
> point continuing.

Hopefully, you will read this reply :)


Links:

[1] http://youid.openlinksw.com -- X.509 Certificate & Private Key
Generator for Android and iOS
[2] http://id.myopenlink.net/youid -- Web hosted variant of the above
(this provides <keygen/> or pkcs#12 file generation as options; and
<keygen/> isn't the default>
[3]
http://www.slideshare.net/kidehen/how-virtuoso-enables-attributed-based-access-controls
-- Presentation that covers WebID-TLS and WebIDACLs .

-- 
Regards,

Kingsley Idehen       
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this