Whishlist for next-gen card

[Peter Lebbing]

On 21/02/15 19:54, NdK wrote:
>>> 4 - HOTP PINs for signature/certification keys
>> What generates the HOTP then? Do you type a PIN on the HOTP device to get the HOTP?
> No need. Just an applet on the phone could do. At least if you aren't
> using the same phone to do the crypto.

I don't understand the practical difference between HOTP and the button
to confirm an action.

As it is now, it is the case that malware can sniff your PIN and use
that to use the card. When you add a button, it knows the PIN, but can't
push the button, so you're back in the loop. The malware needs an action
by you, the user.

If you use HOTP, the malware doesn't know the next HOTP to do an action,
which means it once again relies on you to enter the HOTP.

In the former, the user pushes the button. In the latter, the user
enters the HOTP.

What does the HOTP prevent that the button doesn't? And then I don't
mean "learning the PIN", but something that is a goal of an attacker.
Getting the PIN is only the means, their goal is, for instance, to
decrypt or sign. What goal can an attacker achieve when only the button
is there, not the HOTP?

> Maybe its addition to the security is marginal, but can be *way* more
> practical than having to reenter a complex PIN every time.

I think the security benefit from having to enter your PIN on every
access is already very marginal, and outweighed by the burden of
entering the PIN. In other words, have the card remain unlocked and
ready for use with a single PIN entry. If you're working on a
compromised PC, you're already so screwed that your forced entry of the
PIN each and every time isn't going to help.

To me, the benefit of the button is that it is out-of-band. Re-entering
your PIN every time is in-band, and in my eyes, not worth it.

> If that info is embedded in the signature packet, it could add something
> to the signature value (if the receiving party sees that signature is
> about a txt file and the presented object is a doc, there's something
> wrong and suspect).

Are you proposing that the internal hash state after the hashing of the
document is handed over to the smartcard, after which the smartcard
computes the hash over the signature subpackets that you want protected
this way? It's unclear to me how you see such a thing be implemented
without passing all data to the smartcard.

> That's the fingerprint ssh shows you. It should be computed from the
> complete public key.

I wasn't talking about what it shows me, I was talking about what is in
the challenge that is signed.

I've had a quick look in RFC 4252, with public key user authentication
for SSH2. I don't think there's anything that you can show on a display
that would help the user decide if it were what they wanted to see.
After a really quick glance in the RFC, I see just the username and the
session identifier. The username is hardly unique (I usually use peter),
and the session identifier is a unique number computed for the SSH
session. It's the bit that prevents signature replay attacks but is not
useful to show on a display, since the user can't tell whether it's good
or not: it's just the output of a hash function.

All this is based on a really quick read of documentation I hadn't
consulted before. It could be glaringly wrong. But when you said "it is
the fingerprint", I wondered if you misunderstood or that the
fingerprint is actually part of the challenge. I don't think it is.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.You can
send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>