1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html><head><title>Using multiple subkeys in GPG</title></head><body style="background-color: white;">
<div>[ <a href="http://fortytwo.ch/">main gpg page</a> ]
<hr>
<h1>Using multiple subkeys in GPG</h1>
<hr>
<h2>Motivation</h2>
<p>
For a time, I've had two different gpg keys - one at home on my presumably
secure machine, one at the office, with NFS mounted home directory and
quite a few people having accounts everywhere. This worked, but the problem
is that when exchanging key signatures I always had to beg people to sign
both my keys.
</p>
<p>
With gpg and the possibility of having multiple subkeys, I can now have
only one key, but still retain the security feature that I don't have to
revoke my primary key (and lose all signatures on it) if the key at the
office is compromised.
</p>
<p>
<b>NOTE:</b> Most of the following can apply to both signing and encrypting
subkeys. Encryption subkeys can not be used to solve the multiple accounts
problem, though, please see the <a href="#problems">Problems</a> section
further down. Also, note that I don't use multiple encryption subkeys, so I
don't know if there are additional problems with them.
</p>
<p>
The following is based on <b>gnupg 1.2.1</b>. It should all work with newer
versions, too. Older versions do not support everything and have some
additional problems. As I really do recommend you use a recent gpg version, I
have omitted anything related to older gpg versions.
</p>
<h2>Basics</h2>
<p>
Generate a normal key pair, or use an existing key. Usually this will be a
DSA/ElGamal key (this is what I use), but using RSA or other keys is
equally possible. Be sure to do this on a 'really secure' machine.
</p>
<p>
Then "<tt>gpg __edit <i>keyid</i></tt>" the key and add a further subkey
using "<tt>addkey</tt>". "<tt>save</tt>" will store the new subkey on the
keyring. You'll want to save the whole key (secret and public) with
"<tt>gpg __export <i>keyid</i> > pubkey</tt>" and "<tt>gpg
__export-secret-key <i>keyid</i> > seckey</tt>". Best copy those files
onto an offline storage, too. (A basic working knowledge of how to use a
command line and how to deal with files is assumed. Also, you should know
a bit how key handling in gpg works. If you can't see what the above commands
do, you better do <a href="http://www.gnupg.org/gph/en/manual.html">some
reading</a> before continuing here).
</p>
<p>
Now you should also <b>back up your keyrings</b>, as the following has to
work on a keyring to work around some missing or broken gpg features.
</p>
<p>
As you probably will only take one of the subkeys to your not-so-secure
location, "<tt>gpg __edit <i>keyid</i></tt> and delete the subkeys you
don't want to expose (mark them with "<tt>key <i>n</i></tt>" and then delete
them with "<tt>delkey</tt>").
</p>
<p>
"<tt>gpg __export-secret-subkeys <i>keyid</i> > crippled.seckey</tt>"
will then export the remaining subkeys, without the keymaterial of the
primary key.
</p>
<p>
Now, you can restore the keyrings (secret <em>and</em> public, since
deleting the subkeys has also deleted the public subkeys!), and your secure
machine is ready to use. Perhaps you don't want to use your 'insecure'
subkey on your secure machine - again, "<tt>gpg __edit <i>keyid</i></tt>",
"<tt>key <i>n</i></tt>" and "<tt>delkey</tt>" takes care of this; again, it
is necessary to re-import the public key.
</p>
<p>
On your 'insecure' machine, you do "<tt>gpg __import pubkey
crippled.seckey</tt>" (the same files you've generated above), now you're ready
to use gpg on the 'insecure' machine. To verify that you really don't have any
secret keys you don't want, have a look at the output of "<tt>gpg
__list-secret-keys</tt>": all primary secret key where the key material is not
present are marked with '#'.
</p>
<pre>
$ gpg __list-secret-key testuser
sec<b>#</b> 1024D/971B7A70 2003-01-03 testuser <testuser@mydomain.foo>
ssb 1024g/ACDF80C4 2003-01-03
ssb 1024R/BE9CA308 2003-01-07
</pre>
<p>
Of course, you'll have to publish your new public key, so people can
verify your signatures and send you encrypted mail. Read the <a
href="#problems">Problems</a> section for a few comments about this.
</p>
<h2>Effects</h2>
<p>
Keys are always signed with your primary key, so you (or any attacker) won't be
able to sign other keys with the key on the 'insecure' machine. This is why we
started doing all this acrobatics after all. </p>
<p>
You will always be able to revoke a subkey (just "<tt>gpg __edit
<i>keyid</i></tt>", "<tt>key <i>n</i></tt>" and "<tt>revkey</tt>") when you
have the primary secret key available, even if you lose your secret subkey.
Meaning: you may use a secret subkey at an office location, and it is not
strictly necessary to back it up on a secure location (It's still a good idea,
though). The reason for this is that a revocation is really a signature on the
subkey - and this signature is done with the primary key. Of course, this means
that you can't revoke a subkey when you don't have the primary secret key.
</p>
<p>
If you're signing documents, gpg will always try to use a subkey if one
is available, and announce this with a message like "<tt>1024-bit DSA key, ID
E5A7F7D6, created 2002-08-22 (main key ID 92082481)</tt>" . Verifying such
signatures used to cause a similar message, but at least with gpg 1.2.3 no
indication is given that the signature was made with a subkey. If you want to
use a specific subkey (or the primary key), you have to specify it with the
"<tt><i>keyid</i>!</tt>" syntax. I don't remember what happens if more than one
signing subkey is available; I'm sure you can find details on this somewhere in
the <a href="http://www.gnupg.org/documentation/mailing-lists.html">gnupg
mailing list archives</a>.
</p>
<h2><a name="problems">Problems</a></h2>
<p>
The above approach has several problems that may lead to you not doing
things like this. <b>These are not just possible problems. These are real,
and <em>will</em> affect you! You have been warned.</b>
</p>
<p>
First, distributing secret subkeys this way (one subkey for each
account/machine you use) only makes sense with signing subkeys. You can have
multiple encryption subkeys, but you can't force people sending you encrypted
mail using a specific subkey. Naturally, if you're using encryption for
yourself, you can chose the encryption key to use with the
"<tt><i>keyid</i>!</tt>" syntax. The presence of multiple encryption subkeys
is, however, useful if you revoke an older one to replace it with a new one.
</p>
<p>
Old PGP versions apparently can't cope with such keys. I didn't verify this
myself, but people on the gnupg-users mailing list said that current PGP
versions (up to 7.x) can not verify signatures from a subkey. With PGP 8 the
situation is a bit more complicated: PGP 8 can verify subkey signatures, but
has still problems with multiple subkeys: a key with a signing subkey that is
newer than the encryption subkey cannot be used for encryption in PGP 8. A key
where the encryption subkey is newer than the signing subkey can be used for
encryption. So, when you create your key, generate it as 'signing only' key
first, then generate all the signing subkeys you need, and in the end generate
the encryption subkey. (Thanks to David Shaw for this info).
</p>
<p>
Most keyservers can not handle keys with multiple subkeys. Some of them even
make these keys unusable. This should get better soon, as JHarris has written a
patch for the pks keyserver, and keyservers with other software that handles
this are deployed more widely. The keyservers that can handle multiple subkeys
are summarized as <tt>subkeys.pgp.net</tt>.
GnuPG 1.2 added code to recover somewhat when a broken key is retrieved - one
of the subkeys is useable (the others can't be used, as the signature binding
the subkey to the primary is lost).
</p>
<p>
Besides corrupting keys with multiple subkeys, all of these old keyservers
will also only search keys based on the primary key id - so, automatic key
retrieval on signature verification will not work, too. Yet another
reason to oonly use the subkeys.pgp.net keyservers.
</p>
<p>
Finally, keyhandling is not comfortable with such keys - the user interface of
gpg could be better. The following is valid for gpg 1.2.1, some things may be
fixed in newer versions.:
</p>
<ul>
<li>
"<tt>gpg __import <i>secret key</i></tt>" does not merge the keys properly.
If a secret key is already present, additional secret subkeys are not
imported. Also, a dummy primary key is not replaced by the real subkey on
import. Workaround is to shuffle around the keyrings, or do
"<tt>__export</tt>"s at all stages and use "<tt>__delete-secret-key</tt>"
often. (People with masochistic inclination may probably also use
combinations of <tt>gpgsplit</tt>, <tt>cat</tt> and "<tt>gpg __export</tt>"
and "<tt>__import</tt>. I've not tried this.)
</li>
<li>
"<tt>gpg __export-secret-key <i>keyid</i>!</tt>" and <tt>gpg
__export-secret-subkeys <i>keyid</i>!</tt>" should really only export the
named subkey (or the primary stripped of all subkeys). Much keyring shuffling
could be avoided. (<b>2003-02-12:</b>David Shaw added this to the development
branch of the gpg code. Great!)
</li>
</ul>
<h2>Links</h2>
<p>
Some additional reading that might be interesting:
</p>
<ul>
<li>
The <a href="http://www.ietf.org/rfc/rfc2440.txt">rfc2440</a>, specifying
the OpenPGP key format.
</li>
<li>
The <a href="http://www.gnupg.org/gph/en/manual.html">GNU Privacy Handbook</a>
is a fairly complete manual to gpg.
</li>
<li>
The <a
href="http://lists.gnupg.org/pipermail/gnupg-users/2002-August/014721.html">using
various subkeys</a> thread on the gnupg-users mailing list, where most of these
issues were discussed.
</li>
<li>
The <a
href="http://lists.gnupg.org/pipermail/gnupg-devel/2002-September/007700.html">using
subkey signatures</a> thread on gnupg-devel where I asked about the auto key
retrieval problem.
</li>
<li>
Other <a href="http://atom.smasher.org/gpg/">tutorials</a> on advanced black
magic with keys by Atom Smasher, dealing with what you can do with subkeys.
</li>
</ul>
<h2>Acknowledgments</h2>
<p>
Of course, thanks to the gnupg crew for the cool software, and especially to
Werner Koch and David Shaw for replying to my initial questions about this. And
to Jason Harris for fixing pks to accept keys with multiple subkeys, I hope
this patch spreads really fast as soon as it is officially out.
</p>
<p>
</p>
</div>
<hr>
<div style="font-size: x-small;">
©2002-2004 <a href="mailto:avbidder+gpg@fortytwo.ch">Adrian von Bidder</a>
- Permission to redistribute and/or modify this document is granted if (i) the
original author (Adrian von Bidder, Switzerland) is acknowledged and (ii) the
document remains freely available for distribution and modification.
</div>
</body></html>
|
