Re: [Gnumed-devel] Yubikey

[Jim Busser]

On 2010-08-01, at 11:35 PM, Sebastian Hilbert wrote:

>>> If the hospital PC
>>> grabs your credentials it still cannot be used unless the second step
>>> (Yubikey) is available to the attacker.
>> 
>> So that's the second vector of security: possession. Is it ?
> 
> Sure. Better then nothing.

Luke's cautions do sit well with me, and I do appreciate the "trust no one" 
ethos because people in real life end up doing all kinds of things they were 
not supposed to do, for reasons sometimes understandable and sometimes not. So, 
the best protection against somebody choosing to do something they ought to not 
do is by removing the temptation (by removing the capacity).

Luke's right. It could be better done. Yubikey could

1) avoid storing their copy of the AES key unencrypted in a postgres table but, 
instead, store it encrypted. They would only decrypt the AES key (using their 
own private key) in response to an incoming authentication request, in which 
they would do a lookup as they already do, based on the public portion (serial 
number) of the key. It is just that the AES key would live in the backend 
*encrypted*. This would afford Yubico (and the Yubikey user) extra protection 
in the event their table or db got hacked, assuming their private key was 
separately safe. Mind you we don't *know* that Yubico doesn't already do this, 
we only assume it from the available open source packages.

2) still provide the AES key to an individual or organization that was out to 
"get" somebody. I don't know whether Yubico related, to my identifiable 
purchase from them, the *serial numbers* of the two keys that they mailed me. 
Ideally, they would not have. This would not matter if the "entity of interest" 
that I want to authenticate my key could know where to direct the 
authentication request *other than* to Yubico. This too is achievable:

i) if the entity is my own server, I can have my server direct the request to 
whatever system *other* than Yubico that I decide to trust (and I can 
reinitialize the key, and provide the trusted machine, which could be my own 
machine, its copy of the key)

ii) a root authority could be set up for such keys, outside Yubico, where the 
key owner could register their public key, specifying where requests for 
authentication are to be directed. Of course, you would have to show that you 
own the key that you want registered, which you could do if you started with 
Yubico as default. You could maybe, in a subsequent transaction:

1) authenticate (via Yubico) and then
2) inside an authenticated session with the root authority:
        - specify a new authenticating service, and date/time to take effect
        - encrypted-connect to that service
        - upload what is to be the new key
        - disconnect
3) reinitialize the Yubikey
        - same public id
        - load the new key

all set!

Here's where, over and above Luke, some of these ideas came from

        
http://webcache.googleusercontent.com/search?q=cache:FVo_MmnrPWcJ:www.lca2010.org.nz/slides/50304.odp
        html version of the file http://www.lca2010.org.nz/slides/50304.odp

and yet, as a first step, I would still see it as not unreasonable (in my own 
situation) to use a Yubikey

-- Jim