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

On Thu, Jun 14, 2012 at 10:32 AM, Anders Rundgren
<anders.rundgren@telia.com> 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

Received on Thursday, 14 June 2012 12:30:44 UTC