Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/26/19 12:52 AM, Rich Freeman wrote: > gpg is the same. Yes, the concepts are great once you understand them > (though the smartcard standard is needlessly limited). The actual > command line interface is just painful to use if you're doing more > than just encrypting/signing something. If you want to use something > other than your default key you pass --default-key, which seems odd, > since you don't really want to change your default, and there isn't > any way to pass a "non-default" key. I get having a default key > option in a config file, since that is what it describes. And then > there is all the interactivity, which makes sense to have as an > option, but not without a command line override. I mean, the FTP > interactive console also makes sense but there is a reason everybody > uses curl/wget/etc, and not FTP+expect. default-key is exactly for config file, for other operations you use -u/--local-user -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 6:29 PM Kristian Fiskerstrand wrote: > > On 4/26/19 12:26 AM, Rich Freeman wrote: > > I mean, I'd expect any Gentoo dev to be able to figure out how to use > > git as well, but git also has a terrible command line interface, > > Not really, it is quite intuitive once you understand the basics. > So, I love git, and certainly understand the basics, and created a python script to map/reduce our repo into a list of all unique files in the history with their hashes and commit info to compare to cvs during the migration. I certainly think the command line is terrible. How many different ways are branches identified in the various commands? git-am is a favorite whipping boy of many critics. It is just inconsistent from command to command, and some common things like backing out one commit require arcane syntax. Yes, it all makes sense if you understand the data model, but it is hardly a clean interface. I'm certainly not the first to say this, and it is not because of a lack of git knowledge. I suspect Linus himself would concur. It was a personal tool that scratched an itch that we're all stuck with because it works well enough that nobody will want to create a new interface. gpg is the same. Yes, the concepts are great once you understand them (though the smartcard standard is needlessly limited). The actual command line interface is just painful to use if you're doing more than just encrypting/signing something. If you want to use something other than your default key you pass --default-key, which seems odd, since you don't really want to change your default, and there isn't any way to pass a "non-default" key. I get having a default key option in a config file, since that is what it describes. And then there is all the interactivity, which makes sense to have as an option, but not without a command line override. I mean, the FTP interactive console also makes sense but there is a reason everybody uses curl/wget/etc, and not FTP+expect. > > > > Personally I think we ought to make it easier to just use the > > Nitrokeys we spent all this money on in a more secure manner than just > > leaving primary keys lying around on hard drives, > > The decisions involved are disjunct here, but leaving around on > hard-drives is generally a bad idea irrespective of any nitrokey, and > certainly something expected not to happen from a Gentoo Dev to begin > with (for primary key material at least) IMO this is quite naive. The desire to store it offline isn't even documented in the GLEP, nor is it enforceable. I get that some people like to care for their gpg keys the way other people like to wax their cars, but not everybody signed up as a Gentoo dev so that they have an excuse to participate in a WoT. And I think that the practical side of security is VERY relevant here. My argument is that having a single primary+signing key generated on a smartcard is more secure than having a separate primary+signing key stored on an internet-connected PC hard drive. And yet the first is forbidden by the GLEP and the second is allowed. The fact that you can't conceive of somebody using gpg in basically the most out-of-the-box way available doesn't mean that this isn't how most devs would actually do it. The integrity of this entire exercise is as secure as the dev who takes the least care to secure their keys, not the one who takes the greatest care. IMO it is in the interests of security to create a process that is both convenient and secure, and I think that keys generated on a smartcard achieve a better balance of this than other alternatives allowed under the current policy. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 5:54 PM James Le Cuirot wrote: > > if I understood it correctly, it only removes the primary private key > from the online copy and not the entire primary key. The --list-keys > option shows an [SC] primary with an [E] subkey and an [S] subkey and I > gathered from a conversation in #gentoo-dev that this is correct. Are > you suggesting the [SC] primary should not appear here at all? No, the public key should remain in your keychain. It is, after all, public, so there is no risk of compromise. You really want it to be published as widely as possible actually to reduce the risk of somebody using the wrong key. > > > Secondly, the reason for that is not (just) to have a backup > > but that the primary private key gives you virtually unlimited control. > > Are you contradicting yourself here? You explained why the private key > must be kept secure but you didn't say anything about the rest of the > primary key. The only keys you need to secure are the private keys. These keys are created in public/private pairs always. In the case of our GLEP we have three pairs: a primary, a signing, and an encryption. The signing and encryption pairs are referred to as subkeys, but this is just a convention - mathematically they work exactly the same. Ideally you want all your keys to be secure, but the concept of having tiered keys is that you can keep the primary in a safer place, since it can be used to invalidate and issue new subkeys, and thus you don't have to completely replace the trust chain if one key is compromised. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/26/19 12:26 AM, Rich Freeman wrote: > I mean, I'd expect any Gentoo dev to be able to figure out how to use > git as well, but git also has a terrible command line interface, Not really, it is quite intuitive once you understand the basics. > > Personally I think we ought to make it easier to just use the > Nitrokeys we spent all this money on in a more secure manner than just > leaving primary keys lying around on hard drives, The decisions involved are disjunct here, but leaving around on hard-drives is generally a bad idea irrespective of any nitrokey, and certainly something expected not to happen from a Gentoo Dev to begin with (for primary key material at least) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 4:55 PM Kristian Fiskerstrand wrote: > > Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg > interface. > Being able to is not the same as caring enough to be bothered with it... I don't want to custom-tailor my Gentoo key. I just want to generate a key that will make the commit scripts happy. The key is completely disposable from a personal standpoint - when the GLEP was recently revised to make my old key no longer valid, I just generated a new one. I didn't even bother revoking the old one, since it had no function as soon as I changed the fingerprint in LDAP. I was generating PGP keys back when it used idea and I'm guessing md5. I've had gpg keys for decades. I used my personal one for Gentoo until the point where there were specific requirements for a Gentoo key, and rather than try to personally live with the Gentoo requirements it makes far more sense to just generate a Gentoo-specific key. Then we can change the GLEP as often as we like it it really doesn't bother me much. I can just discard my key and create a new one, though it would be nice if those creating the GLEPs would actually document the simplest way to do this for those who really can't be bothered to read the man page. I mean, I'd expect any Gentoo dev to be able to figure out how to use git as well, but git also has a terrible command line interface, so rather than put a bunch of requirements in a document and force everybody to dig through manpages to get it to generate signed commits/pushes/etc we just give a handy workflow. After all, our goal is to maintain the repo, not spend all day independently decipering how to sign pushes or figuring out that a commit sig and a push sig are two different things. Personally I think we ought to make it easier to just use the Nitrokeys we spent all this money on in a more secure manner than just leaving primary keys lying around on hard drives, which is where I suspect the vast majority will reside, completely negating the expense the Foundation and Nitrokey both went through to provide them for us. While I'm all for GLEPs themselves sticking to specs, having a workflow document to go along with it would go a long way to helping devs to comply, rather than spending all our effort writing increasingly clever scripts to yell at them when they aren't complying. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, 25 Apr 2019 12:57:54 +0100 Marek Szuba wrote: > 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 do not want to have an offline copy > of the primary private key - you want to have the primary ENTIRELY > offline. This has confused me. Granted, GLEP 63 does not say anything about where to store the primary key but I followed the Debian guide at https://wiki.debian.org/Subkeys, believing it to be best practise and if I understood it correctly, it only removes the primary private key from the online copy and not the entire primary key. The --list-keys option shows an [SC] primary with an [E] subkey and an [S] subkey and I gathered from a conversation in #gentoo-dev that this is correct. Are you suggesting the [SC] primary should not appear here at all? > Secondly, the reason for that is not (just) to have a backup > but that the primary private key gives you virtually unlimited control. Are you contradicting yourself here? You explained why the private key must be kept secure but you didn't say anything about the rest of the primary key. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpVGro7fCSWU.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/25/19 10:48 PM, Rich Freeman wrote: > I think a big problem is that gpg is sorely lacking in command line > commands/options for key management. Almost anything having to do > with key management involves a back-and-forth console interaction. Yes and no.. One issue is it depends on context, which differs, for generating a new TPK everything is easy to document, but from there things gets curious for how to adjust existing key material. The main issue is security can't be solved technically, it is ultimately requires social interaction and proper procedures / policy (if you haven't seen the movie Crimson Tide, now is the time to do so, it is the only movie I'm aware of that is singularly about proper security procedure) E.g --quick-add-key can be easily used to generate a new signing subkey from a default generated key, but why not just do an addkey in interactive mode? Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg interface. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 4:34 PM James Le Cuirot wrote: > > On Thu, 25 Apr 2019 11:30:27 -0400 > Alec Warner wrote: > > > > 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. > > > > > > > This is untrue though; we *are* random people from teh interwebs. > > > > I store my primary key on my desktop. > > I don't have copies of my primary key. > > My primary key is protected by a passphrase. > > Most of the time its cached in gpg-agent, so the passphrase is easily > > stealable by local attackers. > > I've been a dev for like > 10 years. > > > > I assume that every other dev does the same. Obviously some do not (and > > I've spoken to many who have better practices) but I assume > > people do the lazy / easy thing and I highly recommend this assumption. If > > you assume that people have your security practices, you should prepare to > > be disappointed. > > > > Many devs have *no idea* how GPG works. > > GPG is quite possibly the worst program I've even been forced to use in > > terms of doing any operation, particularly around setup (hmm maybe Imation > > Ironkeys were worse?) > > Many devs are just following the wiki instructions and get what they get. > > I can sort of echo this. I believe I'm close to the recommendations now > but it took me several evenings to actually wrap my head around all > this and even then, I still felt very nervous setting it up and I had > to rehearse it beforehand. As a professional software engineer for many > years, it really shouldn't be this hard. People talk about GPG best > practices but it was really difficult to find a reliable update-to-date > guide and it certainly doesn't feel like best practise when you have to > manually delete ~/.gnupg/private-keys-v1.d/KEYGRIP.key, where KEYGRIP > is returned by the obscure --with-keygrip option. I think a big problem is that gpg is sorely lacking in command line commands/options for key management. Almost anything having to do with key management involves a back-and-forth console interaction. This means that you can't just tell somebody to run "gpg --long --list --of --options" and have it just do the right thing. You also can't script anything unless you feed input or even worse use something like expect. Some of the guides I've seen require editing config files because presumably these options can't be set on the command line. I completely get what asymmetric crypto is. It is just a royal PITA to actually get gpg to do something very specific like have a separate signing key without pouring through manpages. Generating a key with the default options is easy, but after that you're on your own largely. Oh sure, once you know how to do it then it isn't a big deal. Until you have to do it again because you don't generate new gpg keys every other week... -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, 25 Apr 2019 11:30:27 -0400 Alec Warner wrote: > > 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. > > > > This is untrue though; we *are* random people from teh interwebs. > > I store my primary key on my desktop. > I don't have copies of my primary key. > My primary key is protected by a passphrase. > Most of the time its cached in gpg-agent, so the passphrase is easily > stealable by local attackers. > I've been a dev for like > 10 years. > > I assume that every other dev does the same. Obviously some do not (and > I've spoken to many who have better practices) but I assume > people do the lazy / easy thing and I highly recommend this assumption. If > you assume that people have your security practices, you should prepare to > be disappointed. > > Many devs have *no idea* how GPG works. > GPG is quite possibly the worst program I've even been forced to use in > terms of doing any operation, particularly around setup (hmm maybe Imation > Ironkeys were worse?) > Many devs are just following the wiki instructions and get what they get. I can sort of echo this. I believe I'm close to the recommendations now but it took me several evenings to actually wrap my head around all this and even then, I still felt very nervous setting it up and I had to rehearse it beforehand. As a professional software engineer for many years, it really shouldn't be this hard. People talk about GPG best practices but it was really difficult to find a reliable update-to-date guide and it certainly doesn't feel like best practise when you have to manually delete ~/.gnupg/private-keys-v1.d/KEYGRIP.key, where KEYGRIP is returned by the obscure --with-keygrip option. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpsvBE3uLuyQ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 7:58 AM Marek Szuba wrote: > 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. > This is untrue though; we *are* random people from teh interwebs. I store my primary key on my desktop. I don't have copies of my primary key. My primary key is protected by a passphrase. Most of the time its cached in gpg-agent, so the passphrase is easily stealable by local attackers. I've been a dev for like > 10 years. I assume that every other dev does the same. Obviously some do not (and I've spoken to many who have better practices) but I assume people do the lazy / easy thing and I highly recommend this assumption. If you assume that people have your security practices, you should prepare to be disappointed. Many devs have *no idea* how GPG works. GPG is quite possibly the worst program I've even been forced to use in terms of doing any operation, particularly around setup (hmm maybe Imation Ironkeys were worse?) Many devs are just following the wiki instructions and get what they get. -A > > 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 > >
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Thu, Apr 25, 2019 at 7:57 AM Marek Szuba wrote: > > 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. Agree, I could have said that better. Though, to be clear the primary key needs to be on a PC anytime you use it, which includes time of generation and renewal. Typically this PC will be online. > > 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. IMO this has nothing to do with knowledge, and everything with risk tolerance and incentives. Generating a key on a smartcard is practically a one-liner and is convenient. It is also VERY secure. Now, if you're going to have a completely offline PC that never gets connected to the internet, and use that for key generation, and treat any media used to transfer keys as if you're working on a classified software project, then sure, that would be more secure. It is also a LOT less convenient. I'd argue that most devs who understand how to use GPG fairly well would not bother with this. I've never kept a primary key offline and I was using PGP back when you had to be located in the US to download it from the original official source. > > > 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. I'm all for revising this, but it isn't part of the GLEP. Maybe it should be. A smartcard is a practical compromise. It gives a great deal more security than online keys, while being convenient. Sure, it might not be the most secure approach possible, but it is far more secure than approaches most are likely to actually use, even if they know better options exist. > > > 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. Sure, though this is definitely more cumbersome, and not a one-liner in gpg for sure. And last time I checked we're only issuing one Nitrokey per dev, so it is unlikely many would do this. > > > 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. Sure, but this requires physical theft, which is a HUGE escalation of effort. IMO the most likely attack is some script kiddie on the other side of the planet. I mean, somebody could steal my ID and get into my work and go cause a mess. However this is extremely unlikely in practice. If we were defending against the CIA or whatever I'd consider this a more serious concern, but this isn't realistic, and we would need far better standards to do that. > 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. I don't see how it differs whether the primary vs signing key is stolen, unless you regenerate new signing keys frequently. If you keep just re-extending expiry on your signing key then that stolen key will work forever. And if you do generate signing keys often then the window of compromise is the same either way. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
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
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand wrote: > > On 4/24/19 4:19 PM, Rich Freeman wrote: > > If it is the case that Nitrokeys can't support a separate primary key, > > I'd suggest modifying the GLEP to remove that requirement when a > > smartcard is in use. Its main purpose is to keep a key component > > offline, and if the key is generated on the card that is already > > accomplished. Maybe somebody has a suggestion for how to make the two > > work together, otherwise I'll go ahead and suggest a GLEP revision for > > the next Council meeting. > > > The GLEP should not be changed on the requirement for distinct signing > subkey, this is one of the expected results of it to begin with. So, I intend to propose this. Council is welcome to vote it down. However, I'm really interested in what the concern is here. The only reason to have a separate primary key is to have an offline copy, but it is not a current requirement that it be kept offline, and I suspect that 99% of devs won't keep it offline, and of course there is no way to verify if this is being done anyway. So, maintaining this requirement with a Nitrokey means that we in reality have the primary key online most of the time, when if it were the same as the signing key then both would be offline in the Nitrokey. This requirement effectively makes the key less secure in practice. It doesn't matter if the signing key is safely stored in the Nitrokey if somebody can steal the primary key, since they can just create a new signing key at will. Also, by generating the key outside the Nitrokey it is exposed to a far higher risk of compromise. At best for the 1% of devs who would actually keep the primary key offline then this achieves the same level of security you have with the Nitrokey anyway, which always keeps its keys offline (effectively). The only exception to this would be an exploit in the Nitrokey, which seems like a pretty low risk. And of course it is only a risk when the Nitrokey is plugged in, and the intent would be for devs to only plug it in when working on commits. 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. Now, I think it is a great best practice which we should support for anybody who wants to have their offline key-generation machine they keep in a vault or whatever. And by all means require the additional key when using keys not generated on a Nitrokey. As to how you can tell which are which, I'd simply point out that you can't tell if keys are being stored offline or not, so really your risk is unchanged in taking devs at their word. I think most companies issuing these sorts of tokens to users would generate their keys on the tokens for these very reasons. The reason they're using these hardware tokens is because they know that users in practice will not take extraordinary care to protect keys, and the token provides a similar level of security with very little inconvenience. 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. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 4/24/19 4:19 PM, Rich Freeman wrote: > If it is the case that Nitrokeys can't support a separate primary key, > I'd suggest modifying the GLEP to remove that requirement when a > smartcard is in use. Its main purpose is to keep a key component > offline, and if the key is generated on the card that is already > accomplished. Maybe somebody has a suggestion for how to make the two > work together, otherwise I'll go ahead and suggest a GLEP revision for > the next Council meeting. The nitrokey has 3 slots, one signing (which can hold signing subkey or primary), encryption and authentication. So yes, the primary should be kept on an offline system or on a separate token that isn't brought around on regular basis, while the daily use operations use subkeys that reside on the token. The GLEP should not be changed on the requirement for distinct signing subkey, this is one of the expected results of it to begin with. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Wed, Apr 24, 2019 at 10:25 AM Alon Bar-Lev wrote:
>
> On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman wrote:
> > Well, in that case recommendations for how to generate a key that
> > complies in software would be helpful. There used to be a wiki
> > article on it, but it is marked with various warnings saying it isn't
> > recommended to follow it, and has seemingly vanished with a note that
> > it moved somewhere.
> In the meantime, I think that you may find the following commands useful...
>
> $ gpg --expert --full-generate-key
Well, sure, but the part that comes after would be the key bit.
> $ gpg --expert --edit-key ${MASTER_KEY_ID}
> gpg> addkey
This bit is already covered on the Nitrokey guide.
In any case, I'll stick with the key I have for the moment until the
Council rules on the GLEP. Neither key I have currently complies with
the current one so I'm generating a new one either way, unless the
GLEP changes.
--
Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman wrote:
> Well, in that case recommendations for how to generate a key that
> complies in software would be helpful. There used to be a wiki
> article on it, but it is marked with various warnings saying it isn't
> recommended to follow it, and has seemingly vanished with a note that
> it moved somewhere.
Please wait for me to receive mine... :)
In the meantime, I think that you may find the following commands useful...
$ gpg --expert --full-generate-key
$ gpg --expert --edit-key ${MASTER_KEY_ID}
gpg> addkey
Regards,
Alon
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On Wed, Apr 24, 2019 at 10:01 AM Marek Szuba wrote: > > On 2019-04-24 13:41, Rich Freeman wrote: > > > What is the recommended way to create an on-card key? > > I haven't got my NitroKey yet but between the specifications (which say > NK2 can hold up to 3 private RSA keys) and my prior experience with > OpenPGP smartcards (which have always had at most one slot each assigned > to authentication, encryption and signing), chances are pretty high you > cannot have two separate signing keys in hardware. If so, your best bet > is probably to generate the primary key in software (preferably with > usage bits stripped down so that it can ONLY be used for signing keys), > generate hardware subkeys associated with it, then stash the private > primary key away somewhere. > Well, in that case recommendations for how to generate a key that complies in software would be helpful. There used to be a wiki article on it, but it is marked with various warnings saying it isn't recommended to follow it, and has seemingly vanished with a note that it moved somewhere. Aside from that, it seems a bit odd to issue devs Nitrokeys (at significant expense to both the Foundation and a kind sponsor), then require a key design that can't actually be stored on the Nitrokey. A Nitrokey-generated key is going to be way more secure than the way 99% of devs will actually implement what seems to be intended, which is to just generate their keys on a regular online host, and probably just leave it there. If it is the case that Nitrokeys can't support a separate primary key, I'd suggest modifying the GLEP to remove that requirement when a smartcard is in use. Its main purpose is to keep a key component offline, and if the key is generated on the card that is already accomplished. Maybe somebody has a suggestion for how to make the two work together, otherwise I'll go ahead and suggest a GLEP revision for the next Council meeting. -- Rich
Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
On 2019-04-24 13:41, Rich Freeman wrote: > What is the recommended way to create an on-card key? I haven't got my NitroKey yet but between the specifications (which say NK2 can hold up to 3 private RSA keys) and my prior experience with OpenPGP smartcards (which have always had at most one slot each assigned to authentication, encryption and signing), chances are pretty high you cannot have two separate signing keys in hardware. If so, your best bet is probably to generate the primary key in software (preferably with usage bits stripped down so that it can ONLY be used for signing keys), generate hardware subkeys associated with it, then stash the private primary key away somewhere. -- MS
[gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
I just generated a gpg key on my nitrocard using the default options, as I could not find any other official recommendations for how to create a key. However, it appears that the default config uses the same signing and primary key, and thus generates a warning when pushing to the main repo. What is the recommended way to create an on-card key? Or is the only supported way to do this to create a local key and then export it to the card? If so, what is the current recommended way to do that? -- Rich
