[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Yubikey
Re: [Gnumed-devel] Yubikey
Mon, 02 Aug 2010 08:34:14 -0700
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
3) reinitialize the Yubikey
- same public id
- load the new key
Here's where, over and above Luke, some of these ideas came from
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