[Gnuk-users] gnuk-users Digest, Vol 107, Issue 3

[Mike Tsao]

Peter, that's a nice idea, but I have some larger concerns about the
general problem being solved.

First, if the plaintext is known, then a dictionary or at least brute-force
attack is feasible. In this case, though, the threat model involves first
obtaining the unique physical device, so I'm not sure an attacker would
bother to construct the dictionary. It's unlikely someone would suddenly
find 10,000 gnuk devices with PINs but no keys.

The brute-force attack unfortunately applies to both the static string and
the private key plaintext cases. I haven't looked at the gnuk
implementation that verifies the PIN indeed decodes the private key
correctly, but it's likely equivalent to the static case -- checking a few
magic header bytes.

Which brings us back to the original problem. What exactly are we
protecting against?

Normally private keys in a GnuPG keychain must be stored in a way that's
immune to offline brute-force attacks (PBKDF with strong passphrase).
That's a well-understood and secure system, but it's hard to use because
users need to worry about managing strong passphrases, including worrying
about whether malware steals the passphrase. Thus GnuPG is hard to use.

Smart cards solve that problem. They are inexpensive and they replace a
strong stretched passphrase with a short unstretched PIN that's easy to
memorize and enter. But they can do this only if the hardware is
tamper-resistant, and if the firmware locks out anything resembling a
brute-force attack on the PIN. That lockout mechanism must be very
conservative (only 3 tries) because the PIN space is so small.

If we suspend the tamper-resistance requirement, then we're left with this:


   - Valuable asset...
   - That is encrypted by a brute-forceable PIN...
   - That is not stretched (or else the device would be slow or
   expensive)...
   - That is housed on a device where we must explicitly assume the
   attacker obtains a copy of the device's ciphertext (uh-oh).

This is an unsolvable problem. If the PIN is long enough to resist brute
forcing, then the smart card's purpose (usability) is defeated. If the PIN
is stretched, an attractive element of the hardware (cheap and fast) is
lost. And if the device is compromised and the attacker contains a
ciphertext weakly encrypted with a small key, the smart card is worse than
no solution at all, because it caused a well-protected but unusable key to
be exposed in the open with virtually no real protection.

That's why it makes more sense to assume the device actually is
tamper-resistant (the hacker will never obtain the ciphertext), and build
on that assumption. Otherwise we end up with partial solutions that don't
actually address the threat model sufficiently to stop any attacker.

On Thu, Jan 11, 2018, 1:04 AM Peter Lebbing <peter at digitalbrains.com> wrote:

> On 11/01/18 07:48, Mike Tsao wrote:
> > If I'm understanding the current gnuk code, the key-before-PIN policy is
> also
> > the mechanism of the implementation ("Gnuk 1.2 does validation of user
> PIN by
> > successful decryption of private key"), so it doesn't appear that
> someone with a
> > perspective like mine can easily or elegantly reconfigure gnuk
> accordingly.
>
> Well, this could be solved by representing the "no key" state with dummy
> data
> that is encrypted to the PIN.
>
> When there is a key, the PIN encrypts the key, and succesful decryption
> indicates success.
>
> When there is no key, the PIN encrypts the literal string "Nothing to see
> here,
> move along"[1] and succesful decryption indicates success. The PIN that
> was then
> verified in this way can be kept in RAM and used to subsequently encrypt
> the
> uploaded key. I suppose this is roughly what happens when keys are
> uploaded to a
> GnuK that already has some keys?
>
> HTH,
>
> Peter.
>
> [1] Well, that would give me a chuckle if I were reading the code. A
> string of
> zeroes would work just as well and occupy no flash memory in the
> controller, but
> it wouldn't be funny, damn it!
>
> --
> 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20180111/20862906/attachment.html>