full-disclosure - Interesting but vulnerable scheme for tokenless auth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <44503563.3000403@gce.com>
Date: Thu Apr 27 01:14:04 2006
From: everhart at gce.com (Glenn Everhart)
Subject: Interesting but vulnerable scheme for tokenless
	auth

Consider the following attempt at el-cheapo (no hardware) authentication 
(which occurred to me recently while reading some ads):

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. While code tricks can minimize time of exposure 
and obscure the use of the underlying key, they cannot block it, and 
once the private key is gone the use of such quickly becomes worse than 
useless.

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@....com