Resistance of <keygen> to client-side attack

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Resistance of <keygen> to client-side attack

Alan Egerton
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?

-- Alan


Reply | Threaded
Open this post in threaded view
|

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

Anders Rundgren
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
>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Alan Egerton
On Thu, Jun 14, 2012 at 10:32 AM, Anders Rundgren
<[hidden email]> wrote:
> If the browser/platform is corrupt (which a precondition for malicious
> client-side scripts), all bets are off.

Not necessarily.  An XSS attack, for example, could have introduced
malicious script without corrupting browser/platform.  It could then
proceed to alter the form that is submitted to the server so that the
generated public key is replaced with an attacker's key - and the
server has no means to know whether that has taken place.

Better would be for the generated public key to be returned to the
server in a channel which cannot be affected by client-side script,
such as an HTTP header.  I agree that this would not protect against
compromise of the browser/platform, but as you say all bets are off if
that is this case (and clearly avoiding such attacks is out of the
scope of HTML).

> 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 :-)

The only time I have come across <keygen> in practice is on obtaining
a S/MIME key from StartCom using Safari.  Not only would the above
issue have existed, but I also did not receive any feedback to assure
me that the apparently downloaded key was indeed generated by <keygen>
(rather than simply generated elsewhere and sent to my browser).  This
is a browser UI issue, again out of scope for HTML, but nevertheless
one worth considering.

-- Alan