W3C home > Mailing lists > Public > public-html-comments@w3.org > June 2012

Re: Resistance of <keygen> to client-side attack

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Thu, 14 Jun 2012 11:32:01 +0200
Message-ID: <4FD9AF91.2010806@telia.com>
To: Alan Egerton <eggyal@gmail.com>
CC: public-html-comments@w3.org
On 2012-06-13 19:51, Alan Egerton wrote:
> Looking over <http://dev.w3.org/html5/spec/the-keygen-element.html>,
> what is there to prevent a client-side script from removing the keygen
> element from the DOM and replacing it with an attacker's key?  One
> presumes that the "challenge" attribute was intended to overcome such
> threats, but the malicious script can read the challenge value and
> generate/sign its own key accordingly.
> 
> Perhaps the browser should provide keys generated by <keygen> to the
> server in an HTTP header that cannot be accessed/manipulated by
> client-side script?

If the browser/platform is corrupt (which a precondition for malicious
client-side scripts), all bets are off.  The "challenge" is most likely
only there to guarantee the freshness/uniqueness of the request to
the server.

What's missing from the plot is a way to assure the issuer that the
key is generated/residing in a specific container.

Anyway, not even Apple actually use <keygen> in spite of pushing it!
They have a much better system in iOS.  The Other Two" are also
working on entirely new schemes for enrollment but none of the
big vendors has any plans showing this to an SDO, at least not
until they are firmly established by their respective customers :-)

Anders

> 
> -- Alan
> 
> 
> 
Received on Thursday, 14 June 2012 09:32:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 June 2012 09:32:57 GMT