On 2019-04-24 20:34, Rich Freeman wrote: > The only reason to have a separate primary key is to have an offline > copy,
Not quite. First and foremost, you don not want to have an offline copy of the primary private key - you want to have the primary ENTIRELY offline. Secondly, the reason for that is not (just) to have a backup but that the primary private key gives you virtually unlimited control. Create pretty much any number of additional subkeys? Check. Assign additional user IDs? Check. Change expiration dates? Check. And so on... In short, having the primary private key compromised means A LOT of trouble - and not just for the key owner either, the primary is also used to sign other people's public keys so it could mess up other users' trust databases. > So, maintaining this requirement with a Nitrokey means that we in > reality have the primary key online most of the time, Seeing as separating the primary and the signing key has been part of OpenPGP best practices for a long, long time, I have got highly mixed feelings about this statement. On the one hand, it is not reasonable to expect someone with no or minimal prior knowledge of OpenPGP to master it overnight. On the other, we are not just some random people from Teh Intarwebz and we *have* been using OpenPGP signatures on commits for quite a while now. > when if it were the same as the signing key then both would be > offline in the Nitrokey. Using a hardware security device is not the same as making the key offline - especially given that the Gentoo NitroKey workflow as currently posted on the Wiki suggests disabling forcesig, which could effectively leave the signing private key unlocked for extended periods of time. > Also, by generating the key outside the Nitrokey it is exposed to a > far higher risk of compromise. As Kristian has already mentioned, in principle one could keep the primary private key on a separate token. > In any case, I think it is far more likely that somebody generating > keys using software has a rooted box than somebody is going to come > up with a way to extract keys from a Nitrokey. You do not have to extract keys from a smartcard in order to be able to use keys physically present on it. All you have to do observe the smartcard user's PIN - either physically or using said rooted box - then nick the smartcard off them, ehich given that we are talking about keys that are supposed to be used on a regular basis might be very simple. Hell, if said smartcard contains the primary key you might even return it to them once you're done compromising them (e.g. by generating your own set of subkeys) and chances are pretty good that as long as everything keeps on working fine for them, it will take a quite a while before anyone notices. Conversely, even a software-generated primary key stored on a software-encrypted USB stick might be more secure simply because with it being only occasionally required, it can be stored somewhere hard to access. You don't even need a vault (which, incidentally, is something I have found people trying to make fun of crypto nerds mention a lot) either - my personal experience has taught me that giving to a trusted family member or friend who doesn't live with you is not a bad solution either. > Really the only thing we're missing with the Nitrokey is some form of > attestation to ensure the keys are in fact generated on the device. That would indeed be nice to have, unfortunately I do not think the current hardware supports this. I know recent YubiKeys do but only in PIV mode (i.e. for X.509). On the other hand, vulnerabilities such as ROCA show clearly that generating the private key on a smartcard does NOT necessarily make it more secure than generating it in software, importing it into the smartcard and wiping the original. -- MS
