Another example of why cheap 2factor is doomed

Consider the following attempt at el-cheapo (no hardware) authentication:

It is possible to imagine an authentication scheme that wants to use
something like a certificate with signing, encrypting random nonces
etc., to verify that someone agrees to some transaction(s). If the
certificate is on a PC, though, it gets exposed to theft.

In the cert is a private key. If the system were required to contact a
"backend" server first, passing it perhaps a cipher containing its
serial number encrypted with its private key and its identity, the
server could send back a (hopefully unique to that cert) decryption key
that would decrypt the private key, allowing its use; the code at the PC
would need to erase the cleartext private key when done. The server
could check the serial number matched the "identity" (it would have the
public key) to prevent a simple search of the server for these
encrypting keys.

This all seems reasonable and deals well with the environment perhaps of
the 1990s. Problem today is that it is still utterly vulnerable to
backdoor code on the PC which could be arranged to either listen for the
decrypting key or just pluck it out of memory while the real cert was
being used in cleartext.

This is another demo of the difficulty of building any kind of software
token that can be connected to uncontrolled environments and which can
keep secrets. It may resist OFFLINE attack, but that is not the primary
attack threat today for such a beast.

Glenn Everhart
Everhart@gce.com