NanoNote as SecurID substitute

Bas Wijnen wijnen at
Sat Jul 28 04:45:26 EDT 2012

Hash: SHA1


On 28-07-12 04:31, neil at wrote:
> We have been comparing passwords, authorized_keys and Kerberos for 
> securing access to servers via SSH.
> + How often must we authenticate? Too often is unpleasant + Is
> there a risk of breach should a laptop be stolen? + Do we have
> continued access if a laptop is lost? + In which scenarios are we
> denied access? + Are we susceptible to password-guessing attacks? +
> Can we gain access from any computer anywhere in the world?
> Kerberos scores well against the above but is still susceptible to 
> password guessing, failure of the Kerberos servers and is work to 
> install on a fresh workstation.

Passwords should never be used for authenticating over a network.

> Would it work for:
> + The secured server to re-generate passwords each minute + The
> NanoNote generates the same password upon request ( based on a 
> shared secret and the current time)

There isn't really a benefit to this, AFAICS. I hope you plan to keep
the algorithm open. In that case, this sort of obfuscation doesn't
help at all: the attacker will just follow the same procedure. The
shared secret is the "password" that he's actually after.

> + Both the server and the NanoNote need fairly accurate clocks.
> GPS over UBB to keep the time accurate without the Internet might
> be desirable

Plus this opens new attack vectors for people who have stolen the
NanoNote, by messing with the clock (they might be able to get to the
shared secret).

> + The shared secret must still be protected on the NanoNote with a 
> pass phrase, although biometrics or RFID over UBB would be fun

For the sort of security you seem to be talking about, biometrics
aren't very secure at all, since they are nowadays recorded and stored
in databases. Also, depending on which biometrics you want, it's
fairly easy to "steal" this information (you can't leave it at home in
a safe).

I'm not sure what you would do with RFID. That's just a way to send a
number from a portable unit over very short distance without a battery
in the sender. This has little to do with security. (They use it for
security in shops by checking at the gate if you carry an RFID with a
number that isn't registered as "paid"; it doesn't do any sort of
authentication. And if it did, the RF part doesn't add anything to its

> I've left out a lot of detail in case there's a critical flaw in
> the approach.

I think a pgp card is still the best we can do:
- - It's easier to "enter" it than a passphrase.
- - It can contain a full key, which is much more secure.

However, it has one drawback: while it is connected to a computer, it
can be used for encrypting and signing things. If the computer is
compromised, you may end up signing stuff you don't want to sign.

This is something the NanoNote could solve. It would present itself as
a pgp cardreader, but has its "card" always inserted. Now instead of
doing whatever the computer asks, it should ask for confirmation
before signing or decrypting anything. Because it has a screen, quite
some information can be provided before the user has to accept.
However, because there is an extra confirmation step, which means that
it shouldn't be requested too often.

Actually, I think this is something that the NanoNote should be able
to "almost solve" very well, too. :-)

> If it could be made to work, would it sell more units?

I doubt it. Not many people are interested in this sort of security.
"Normal" public key encryption with a passphrase is enough for most

> A lot of technologists face this problem of SSH authentication and
> getting a full UN*X system with a UN*X keyboard with their SecurID
> token could make it a desirable solution.

I have no number on how many people this is about, but I don't think
it is so large. Many companies use tokens for security, but almost all
of them are using Windows and don't have enough control over their
system to start using a different authentication method. Also, even if
they would, they'd probably want to wait a year or 10 before believing
that it doesn't have flaws.

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the discussion mailing list