<div dir="ltr"><p dir="ltr">Peter, that's a nice idea, but I have some larger concerns about the general problem being solved.</p><p>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.</p><p>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.</p><p>Which brings us back to the original problem. What exactly are we protecting against?</p><p>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.</p><p>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.</p><p>If we suspend the tamper-resistance requirement, then we're left with this:</p><p></p><ul><li>Valuable asset...</li><li>That is encrypted by a brute-forceable PIN...</li><li>That is not stretched (or else the device would be slow or expensive)...</li><li>That is housed on a device where we must explicitly assume the attacker obtains a copy of the device's ciphertext (uh-oh).</li></ul><div>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.</div><div><br></div><div>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.</div><p></p><div class="gmail_quote"><div dir="ltr">On Thu, Jan 11, 2018, 1:04 AM Peter Lebbing <<a href="mailto:peter@digitalbrains.com" target="_blank">peter@digitalbrains.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/01/18 07:48, Mike Tsao wrote:<br>
> If I'm understanding the current gnuk code, the key-before-PIN policy is also<br>
> the mechanism of the implementation ("Gnuk 1.2 does validation of user PIN by<br>
> successful decryption of private key"), so it doesn't appear that someone with a<br>
> perspective like mine can easily or elegantly reconfigure gnuk accordingly.<br>
<br>
Well, this could be solved by representing the "no key" state with dummy data<br>
that is encrypted to the PIN.<br>
<br>
When there is a key, the PIN encrypts the key, and succesful decryption<br>
indicates success.<br>
<br>
When there is no key, the PIN encrypts the literal string "Nothing to see here,<br>
move along"[1] and succesful decryption indicates success. The PIN that was then<br>
verified in this way can be kept in RAM and used to subsequently encrypt the<br>
uploaded key. I suppose this is roughly what happens when keys are uploaded to a<br>
GnuK that already has some keys?<br>
<br>
HTH,<br>
<br>
Peter.<br>
<br>
[1] Well, that would give me a chuckle if I were reading the code. A string of<br>
zeroes would work just as well and occupy no flash memory in the controller, but<br>
it wouldn't be funny, damn it!<br>
<br>
--<br>
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.<br>
You can send me encrypted mail if you want some privacy.<br>
My key is available at <<a href="http://digitalbrains.com/2012/openpgp-key-peter" rel="noreferrer" target="_blank">http://digitalbrains.com/2012/openpgp-key-peter</a>><br>
<br>
</blockquote></div></div>