maintainer-pgp-guide.rst 37 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967
  1. .. _pgpguide:
  2. ===========================
  3. Kernel Maintainer PGP guide
  4. ===========================
  5. :Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
  6. This document is aimed at Linux kernel developers, and especially at
  7. subsystem maintainers. It contains a subset of information discussed in
  8. the more general "`Protecting Code Integrity`_" guide published by the
  9. Linux Foundation. Please read that document for more in-depth discussion
  10. on some of the topics mentioned in this guide.
  11. .. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
  12. The role of PGP in Linux Kernel development
  13. ===========================================
  14. PGP helps ensure the integrity of the code that is produced by the Linux
  15. kernel development community and, to a lesser degree, establish trusted
  16. communication channels between developers via PGP-signed email exchange.
  17. The Linux kernel source code is available in two main formats:
  18. - Distributed source repositories (git)
  19. - Periodic release snapshots (tarballs)
  20. Both git repositories and tarballs carry PGP signatures of the kernel
  21. developers who create official kernel releases. These signatures offer a
  22. cryptographic guarantee that downloadable versions made available via
  23. kernel.org or any other mirrors are identical to what these developers
  24. have on their workstations. To this end:
  25. - git repositories provide PGP signatures on all tags
  26. - tarballs provide detached PGP signatures with all downloads
  27. .. _devs_not_infra:
  28. Trusting the developers, not infrastructure
  29. -------------------------------------------
  30. Ever since the 2011 compromise of core kernel.org systems, the main
  31. operating principle of the Kernel Archives project has been to assume
  32. that any part of the infrastructure can be compromised at any time. For
  33. this reason, the administrators have taken deliberate steps to emphasize
  34. that trust must always be placed with developers and never with the code
  35. hosting infrastructure, regardless of how good the security practices
  36. for the latter may be.
  37. The above guiding principle is the reason why this guide is needed. We
  38. want to make sure that by placing trust into developers we do not simply
  39. shift the blame for potential future security incidents to someone else.
  40. The goal is to provide a set of guidelines developers can use to create
  41. a secure working environment and safeguard the PGP keys used to
  42. establish the integrity of the Linux kernel itself.
  43. .. _pgp_tools:
  44. PGP tools
  45. =========
  46. Use GnuPG v2
  47. ------------
  48. Your distro should already have GnuPG installed by default, you just
  49. need to verify that you are using version 2.x and not the legacy 1.4
  50. release -- many distributions still package both, with the default
  51. ``gpg`` command invoking GnuPG v.1. To check, run::
  52. $ gpg --version | head -n1
  53. If you see ``gpg (GnuPG) 1.4.x``, then you are using GnuPG v.1. Try the
  54. ``gpg2`` command (if you don't have it, you may need to install the
  55. gnupg2 package)::
  56. $ gpg2 --version | head -n1
  57. If you see ``gpg (GnuPG) 2.x.x``, then you are good to go. This guide
  58. will assume you have the version 2.2 of GnuPG (or later). If you are
  59. using version 2.0 of GnuPG, then some of the commands in this guide will
  60. not work, and you should consider installing the latest 2.2 version of
  61. GnuPG. Versions of gnupg-2.1.11 and later should be compatible for the
  62. purposes of this guide as well.
  63. If you have both ``gpg`` and ``gpg2`` commands, you should make sure you
  64. are always using GnuPG v2, not the legacy version. You can enforce this
  65. by setting the appropriate alias::
  66. $ alias gpg=gpg2
  67. You can put that in your ``.bashrc`` to make sure it's always the case.
  68. Configure gpg-agent options
  69. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  70. The GnuPG agent is a helper tool that will start automatically whenever
  71. you use the ``gpg`` command and run in the background with the purpose
  72. of caching the private key passphrase. There are two options you should
  73. know in order to tweak when the passphrase should be expired from cache:
  74. - ``default-cache-ttl`` (seconds): If you use the same key again before
  75. the time-to-live expires, the countdown will reset for another period.
  76. The default is 600 (10 minutes).
  77. - ``max-cache-ttl`` (seconds): Regardless of how recently you've used
  78. the key since initial passphrase entry, if the maximum time-to-live
  79. countdown expires, you'll have to enter the passphrase again. The
  80. default is 30 minutes.
  81. If you find either of these defaults too short (or too long), you can
  82. edit your ``~/.gnupg/gpg-agent.conf`` file to set your own values::
  83. # set to 30 minutes for regular ttl, and 2 hours for max ttl
  84. default-cache-ttl 1800
  85. max-cache-ttl 7200
  86. .. note::
  87. It is no longer necessary to start gpg-agent manually at the
  88. beginning of your shell session. You may want to check your rc files
  89. to remove anything you had in place for older versions of GnuPG, as
  90. it may not be doing the right thing any more.
  91. Set up a refresh cronjob
  92. ~~~~~~~~~~~~~~~~~~~~~~~~
  93. You will need to regularly refresh your keyring in order to get the
  94. latest changes on other people's public keys, which is best done with a
  95. daily cronjob::
  96. @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
  97. Check the full path to your ``gpg`` or ``gpg2`` command and use the
  98. ``gpg2`` command if regular ``gpg`` for you is the legacy GnuPG v.1.
  99. .. _master_key:
  100. Protect your master PGP key
  101. ===========================
  102. This guide assumes that you already have a PGP key that you use for Linux
  103. kernel development purposes. If you do not yet have one, please see the
  104. "`Protecting Code Integrity`_" document mentioned earlier for guidance
  105. on how to create a new one.
  106. You should also make a new key if your current one is weaker than 2048 bits
  107. (RSA).
  108. Master key vs. Subkeys
  109. ----------------------
  110. Subkeys are fully independent PGP keypairs that are tied to the "master"
  111. key using certifying key signatures (certificates). It is important to
  112. understand the following:
  113. 1. There are no technical differences between the "master key" and "subkeys."
  114. 2. At creation time, we assign functional limitations to each key by
  115. giving it specific capabilities.
  116. 3. A PGP key can have 4 capabilities:
  117. - **[S]** key can be used for signing
  118. - **[E]** key can be used for encryption
  119. - **[A]** key can be used for authentication
  120. - **[C]** key can be used for certifying other keys
  121. 4. A single key may have multiple capabilities.
  122. 5. A subkey is fully independent from the master key. A message
  123. encrypted to a subkey cannot be decrypted with the master key. If you
  124. lose your private subkey, it cannot be recreated from the master key
  125. in any way.
  126. The key carrying the **[C]** (certify) capability is considered the
  127. "master" key because it is the only key that can be used to indicate
  128. relationship with other keys. Only the **[C]** key can be used to:
  129. - add or revoke other keys (subkeys) with S/E/A capabilities
  130. - add, change or revoke identities (uids) associated with the key
  131. - add or change the expiration date on itself or any subkey
  132. - sign other people's keys for web of trust purposes
  133. By default, GnuPG creates the following when generating new keys:
  134. - A master key carrying both Certify and Sign capabilities (**[SC]**)
  135. - A separate subkey with the Encryption capability (**[E]**)
  136. If you used the default parameters when generating your key, then that
  137. is what you will have. You can verify by running ``gpg --list-secret-keys``,
  138. for example::
  139. sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
  140. 000000000000000000000000AAAABBBBCCCCDDDD
  141. uid [ultimate] Alice Dev <adev@kernel.org>
  142. ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23]
  143. Any key carrying the **[C]** capability is your master key, regardless
  144. of any other capabilities it may have assigned to it.
  145. The long line under the ``sec`` entry is your key fingerprint --
  146. whenever you see ``[fpr]`` in the examples below, that 40-character
  147. string is what it refers to.
  148. Ensure your passphrase is strong
  149. --------------------------------
  150. GnuPG uses passphrases to encrypt your private keys before storing them on
  151. disk. This way, even if your ``.gnupg`` directory is leaked or stolen in
  152. its entirety, the attackers cannot use your private keys without first
  153. obtaining the passphrase to decrypt them.
  154. It is absolutely essential that your private keys are protected by a
  155. strong passphrase. To set it or change it, use::
  156. $ gpg --change-passphrase [fpr]
  157. Create a separate Signing subkey
  158. --------------------------------
  159. Our goal is to protect your master key by moving it to offline media, so
  160. if you only have a combined **[SC]** key, then you should create a separate
  161. signing subkey::
  162. $ gpg --quick-addkey [fpr] ed25519 sign
  163. Remember to tell the keyservers about this change, so others can pull down
  164. your new subkey::
  165. $ gpg --send-key [fpr]
  166. .. note:: ECC support in GnuPG
  167. GnuPG 2.1 and later has full support for Elliptic Curve
  168. Cryptography, with ability to combine ECC subkeys with traditional
  169. RSA master keys. The main upside of ECC cryptography is that it is
  170. much faster computationally and creates much smaller signatures when
  171. compared byte for byte with 2048+ bit RSA keys. Unless you plan on
  172. using a smartcard device that does not support ECC operations, we
  173. recommend that you create an ECC signing subkey for your kernel
  174. work.
  175. If for some reason you prefer to stay with RSA subkeys, just replace
  176. "ed25519" with "rsa2048" in the above command. Additionally, if you
  177. plan to use a hardware device that does not support ED25519 ECC
  178. keys, like Nitrokey Pro or a Yubikey, then you should use
  179. "nistp256" instead or "ed25519."
  180. Back up your master key for disaster recovery
  181. ---------------------------------------------
  182. The more signatures you have on your PGP key from other developers, the
  183. more reasons you have to create a backup version that lives on something
  184. other than digital media, for disaster recovery reasons.
  185. The best way to create a printable hardcopy of your private key is by
  186. using the ``paperkey`` software written for this very purpose. See ``man
  187. paperkey`` for more details on the output format and its benefits over
  188. other solutions. Paperkey should already be packaged for most
  189. distributions.
  190. Run the following command to create a hardcopy backup of your private
  191. key::
  192. $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
  193. Print out that file (or pipe the output straight to lpr), then take a
  194. pen and write your passphrase on the margin of the paper. **This is
  195. strongly recommended** because the key printout is still encrypted with
  196. that passphrase, and if you ever change it you will not remember what it
  197. used to be when you had created the backup -- *guaranteed*.
  198. Put the resulting printout and the hand-written passphrase into an envelope
  199. and store in a secure and well-protected place, preferably away from your
  200. home, such as your bank vault.
  201. .. note::
  202. Your printer is probably no longer a simple dumb device connected to
  203. your parallel port, but since the output is still encrypted with
  204. your passphrase, printing out even to "cloud-integrated" modern
  205. printers should remain a relatively safe operation. One option is to
  206. change the passphrase on your master key immediately after you are
  207. done with paperkey.
  208. Back up your whole GnuPG directory
  209. ----------------------------------
  210. .. warning::
  211. **!!!Do not skip this step!!!**
  212. It is important to have a readily available backup of your PGP keys
  213. should you need to recover them. This is different from the
  214. disaster-level preparedness we did with ``paperkey``. You will also rely
  215. on these external copies whenever you need to use your Certify key --
  216. such as when making changes to your own key or signing other people's
  217. keys after conferences and summits.
  218. Start by getting a small USB "thumb" drive (preferably two!) that you
  219. will use for backup purposes. You will need to encrypt them using LUKS
  220. -- refer to your distro's documentation on how to accomplish this.
  221. For the encryption passphrase, you can use the same one as on your
  222. master key.
  223. Once the encryption process is over, re-insert the USB drive and make
  224. sure it gets properly mounted. Copy your entire ``.gnupg`` directory
  225. over to the encrypted storage::
  226. $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
  227. You should now test to make sure everything still works::
  228. $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
  229. If you don't get any errors, then you should be good to go. Unmount the
  230. USB drive, distinctly label it so you don't blow it away next time you
  231. need to use a random USB drive, and put in a safe place -- but not too
  232. far away, because you'll need to use it every now and again for things
  233. like editing identities, adding or revoking subkeys, or signing other
  234. people's keys.
  235. Remove the master key from your homedir
  236. ----------------------------------------
  237. The files in our home directory are not as well protected as we like to
  238. think. They can be leaked or stolen via many different means:
  239. - by accident when making quick homedir copies to set up a new workstation
  240. - by systems administrator negligence or malice
  241. - via poorly secured backups
  242. - via malware in desktop apps (browsers, pdf viewers, etc)
  243. - via coercion when crossing international borders
  244. Protecting your key with a good passphrase greatly helps reduce the risk
  245. of any of the above, but passphrases can be discovered via keyloggers,
  246. shoulder-surfing, or any number of other means. For this reason, the
  247. recommended setup is to remove your master key from your home directory
  248. and store it on offline storage.
  249. .. warning::
  250. Please see the previous section and make sure you have backed up
  251. your GnuPG directory in its entirety. What we are about to do will
  252. render your key useless if you do not have a usable backup!
  253. First, identify the keygrip of your master key::
  254. $ gpg --with-keygrip --list-key [fpr]
  255. The output will be something like this::
  256. pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
  257. 000000000000000000000000AAAABBBBCCCCDDDD
  258. Keygrip = 1111000000000000000000000000000000000000
  259. uid [ultimate] Alice Dev <adev@kernel.org>
  260. sub rsa2048 2018-01-24 [E] [expires: 2020-01-24]
  261. Keygrip = 2222000000000000000000000000000000000000
  262. sub ed25519 2018-01-24 [S]
  263. Keygrip = 3333000000000000000000000000000000000000
  264. Find the keygrip entry that is beneath the ``pub`` line (right under the
  265. master key fingerprint). This will correspond directly to a file in your
  266. ``~/.gnupg`` directory::
  267. $ cd ~/.gnupg/private-keys-v1.d
  268. $ ls
  269. 1111000000000000000000000000000000000000.key
  270. 2222000000000000000000000000000000000000.key
  271. 3333000000000000000000000000000000000000.key
  272. All you have to do is simply remove the .key file that corresponds to
  273. the master keygrip::
  274. $ cd ~/.gnupg/private-keys-v1.d
  275. $ rm 1111000000000000000000000000000000000000.key
  276. Now, if you issue the ``--list-secret-keys`` command, it will show that
  277. the master key is missing (the ``#`` indicates it is not available)::
  278. $ gpg --list-secret-keys
  279. sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
  280. 000000000000000000000000AAAABBBBCCCCDDDD
  281. uid [ultimate] Alice Dev <adev@kernel.org>
  282. ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24]
  283. ssb ed25519 2018-01-24 [S]
  284. You should also remove any ``secring.gpg`` files in the ``~/.gnupg``
  285. directory, which are left over from earlier versions of GnuPG.
  286. If you don't have the "private-keys-v1.d" directory
  287. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  288. If you do not have a ``~/.gnupg/private-keys-v1.d`` directory, then your
  289. secret keys are still stored in the legacy ``secring.gpg`` file used by
  290. GnuPG v1. Making any changes to your key, such as changing the
  291. passphrase or adding a subkey, should automatically convert the old
  292. ``secring.gpg`` format to use ``private-keys-v1.d`` instead.
  293. Once you get that done, make sure to delete the obsolete ``secring.gpg``
  294. file, which still contains your private keys.
  295. .. _smartcards:
  296. Move the subkeys to a dedicated crypto device
  297. =============================================
  298. Even though the master key is now safe from being leaked or stolen, the
  299. subkeys are still in your home directory. Anyone who manages to get
  300. their hands on those will be able to decrypt your communication or fake
  301. your signatures (if they know the passphrase). Furthermore, each time a
  302. GnuPG operation is performed, the keys are loaded into system memory and
  303. can be stolen from there by sufficiently advanced malware (think
  304. Meltdown and Spectre).
  305. The best way to completely protect your keys is to move them to a
  306. specialized hardware device that is capable of smartcard operations.
  307. The benefits of smartcards
  308. --------------------------
  309. A smartcard contains a cryptographic chip that is capable of storing
  310. private keys and performing crypto operations directly on the card
  311. itself. Because the key contents never leave the smartcard, the
  312. operating system of the computer into which you plug in the hardware
  313. device is not able to retrieve the private keys themselves. This is very
  314. different from the encrypted USB storage device we used earlier for
  315. backup purposes -- while that USB device is plugged in and mounted, the
  316. operating system is able to access the private key contents.
  317. Using external encrypted USB media is not a substitute to having a
  318. smartcard-capable device.
  319. Available smartcard devices
  320. ---------------------------
  321. Unless all your laptops and workstations have smartcard readers, the
  322. easiest is to get a specialized USB device that implements smartcard
  323. functionality. There are several options available:
  324. - `Nitrokey Start`_: Open hardware and Free Software, based on FSI
  325. Japan's `Gnuk`_. One of the few available commercial devices that
  326. support ED25519 ECC keys, but offer fewest security features (such as
  327. resistance to tampering or some side-channel attacks).
  328. - `Nitrokey Pro 2`_: Similar to the Nitrokey Start, but more
  329. tamper-resistant and offers more security features. Pro 2 supports ECC
  330. cryptography (NISTP).
  331. - `Yubikey 5`_: proprietary hardware and software, but cheaper than
  332. Nitrokey Pro and comes available in the USB-C form that is more useful
  333. with newer laptops. Offers additional security features such as FIDO
  334. U2F, among others, and now finally supports ECC keys (NISTP).
  335. `LWN has a good review`_ of some of the above models, as well as several
  336. others. Your choice will depend on cost, shipping availability in your
  337. geographical region, and open/proprietary hardware considerations.
  338. .. note::
  339. If you are listed in MAINTAINERS or have an account at kernel.org,
  340. you `qualify for a free Nitrokey Start`_ courtesy of The Linux
  341. Foundation.
  342. .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
  343. .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
  344. .. _`Yubikey 5`: https://www.yubico.com/products/yubikey-5-overview/
  345. .. _Gnuk: https://www.fsij.org/doc-gnuk/
  346. .. _`LWN has a good review`: https://lwn.net/Articles/736231/
  347. .. _`qualify for a free Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
  348. Configure your smartcard device
  349. -------------------------------
  350. Your smartcard device should Just Work (TM) the moment you plug it into
  351. any modern Linux workstation. You can verify it by running::
  352. $ gpg --card-status
  353. If you see full smartcard details, then you are good to go.
  354. Unfortunately, troubleshooting all possible reasons why things may not
  355. be working for you is way beyond the scope of this guide. If you are
  356. having trouble getting the card to work with GnuPG, please seek help via
  357. usual support channels.
  358. To configure your smartcard, you will need to use the GnuPG menu system, as
  359. there are no convenient command-line switches::
  360. $ gpg --card-edit
  361. [...omitted...]
  362. gpg/card> admin
  363. Admin commands are allowed
  364. gpg/card> passwd
  365. You should set the user PIN (1), Admin PIN (3), and the Reset Code (4).
  366. Please make sure to record and store these in a safe place -- especially
  367. the Admin PIN and the Reset Code (which allows you to completely wipe
  368. the smartcard). You so rarely need to use the Admin PIN, that you will
  369. inevitably forget what it is if you do not record it.
  370. Getting back to the main card menu, you can also set other values (such
  371. as name, sex, login data, etc), but it's not necessary and will
  372. additionally leak information about your smartcard should you lose it.
  373. .. note::
  374. Despite having the name "PIN", neither the user PIN nor the admin
  375. PIN on the card need to be numbers.
  376. .. warning::
  377. Some devices may require that you move the subkeys onto the device
  378. before you can change the passphrase. Please check the documentation
  379. provided by the device manufacturer.
  380. Move the subkeys to your smartcard
  381. ----------------------------------
  382. Exit the card menu (using "q") and save all changes. Next, let's move
  383. your subkeys onto the smartcard. You will need both your PGP key
  384. passphrase and the admin PIN of the card for most operations::
  385. $ gpg --edit-key [fpr]
  386. Secret subkeys are available.
  387. pub rsa2048/AAAABBBBCCCCDDDD
  388. created: 2018-01-23 expires: 2020-01-23 usage: SC
  389. trust: ultimate validity: ultimate
  390. ssb rsa2048/1111222233334444
  391. created: 2018-01-23 expires: never usage: E
  392. ssb ed25519/5555666677778888
  393. created: 2017-12-07 expires: never usage: S
  394. [ultimate] (1). Alice Dev <adev@kernel.org>
  395. gpg>
  396. Using ``--edit-key`` puts us into the menu mode again, and you will
  397. notice that the key listing is a little different. From here on, all
  398. commands are done from inside this menu mode, as indicated by ``gpg>``.
  399. First, let's select the key we'll be putting onto the card -- you do
  400. this by typing ``key 1`` (it's the first one in the listing, the **[E]**
  401. subkey)::
  402. gpg> key 1
  403. In the output, you should now see ``ssb*`` on the **[E]** key. The ``*``
  404. indicates which key is currently "selected." It works as a *toggle*,
  405. meaning that if you type ``key 1`` again, the ``*`` will disappear and
  406. the key will not be selected any more.
  407. Now, let's move that key onto the smartcard::
  408. gpg> keytocard
  409. Please select where to store the key:
  410. (2) Encryption key
  411. Your selection? 2
  412. Since it's our **[E]** key, it makes sense to put it into the Encryption
  413. slot. When you submit your selection, you will be prompted first for
  414. your PGP key passphrase, and then for the admin PIN. If the command
  415. returns without an error, your key has been moved.
  416. **Important**: Now type ``key 1`` again to unselect the first key, and
  417. ``key 2`` to select the **[S]** key::
  418. gpg> key 1
  419. gpg> key 2
  420. gpg> keytocard
  421. Please select where to store the key:
  422. (1) Signature key
  423. (3) Authentication key
  424. Your selection? 1
  425. You can use the **[S]** key both for Signature and Authentication, but
  426. we want to make sure it's in the Signature slot, so choose (1). Once
  427. again, if your command returns without an error, then the operation was
  428. successful::
  429. gpg> q
  430. Save changes? (y/N) y
  431. Saving the changes will delete the keys you moved to the card from your
  432. home directory (but it's okay, because we have them in our backups
  433. should we need to do this again for a replacement smartcard).
  434. Verifying that the keys were moved
  435. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  436. If you perform ``--list-secret-keys`` now, you will see a subtle
  437. difference in the output::
  438. $ gpg --list-secret-keys
  439. sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
  440. 000000000000000000000000AAAABBBBCCCCDDDD
  441. uid [ultimate] Alice Dev <adev@kernel.org>
  442. ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24]
  443. ssb> ed25519 2018-01-24 [S]
  444. The ``>`` in the ``ssb>`` output indicates that the subkey is only
  445. available on the smartcard. If you go back into your secret keys
  446. directory and look at the contents there, you will notice that the
  447. ``.key`` files there have been replaced with stubs::
  448. $ cd ~/.gnupg/private-keys-v1.d
  449. $ strings *.key | grep 'private-key'
  450. The output should contain ``shadowed-private-key`` to indicate that
  451. these files are only stubs and the actual content is on the smartcard.
  452. Verifying that the smartcard is functioning
  453. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  454. To verify that the smartcard is working as intended, you can create a
  455. signature::
  456. $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
  457. $ gpg --verify /tmp/test.asc
  458. This should ask for your smartcard PIN on your first command, and then
  459. show "Good signature" after you run ``gpg --verify``.
  460. Congratulations, you have successfully made it extremely difficult to
  461. steal your digital developer identity!
  462. Other common GnuPG operations
  463. -----------------------------
  464. Here is a quick reference for some common operations you'll need to do
  465. with your PGP key.
  466. Mounting your master key offline storage
  467. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  468. You will need your master key for any of the operations below, so you
  469. will first need to mount your backup offline storage and tell GnuPG to
  470. use it::
  471. $ export GNUPGHOME=/media/disk/foo/gnupg-backup
  472. $ gpg --list-secret-keys
  473. You want to make sure that you see ``sec`` and not ``sec#`` in the
  474. output (the ``#`` means the key is not available and you're still using
  475. your regular home directory location).
  476. Extending key expiration date
  477. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  478. The master key has the default expiration date of 2 years from the date
  479. of creation. This is done both for security reasons and to make obsolete
  480. keys eventually disappear from keyservers.
  481. To extend the expiration on your key by a year from current date, just
  482. run::
  483. $ gpg --quick-set-expire [fpr] 1y
  484. You can also use a specific date if that is easier to remember (e.g.
  485. your birthday, January 1st, or Canada Day)::
  486. $ gpg --quick-set-expire [fpr] 2020-07-01
  487. Remember to send the updated key back to keyservers::
  488. $ gpg --send-key [fpr]
  489. Updating your work directory after any changes
  490. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  491. After you make any changes to your key using the offline storage, you will
  492. want to import these changes back into your regular working directory::
  493. $ gpg --export | gpg --homedir ~/.gnupg --import
  494. $ unset GNUPGHOME
  495. Using gpg-agent over ssh
  496. ~~~~~~~~~~~~~~~~~~~~~~~~
  497. You can forward your gpg-agent over ssh if you need to sign tags or
  498. commits on a remote system. Please refer to the instructions provided
  499. on the GnuPG wiki:
  500. - `Agent Forwarding over SSH`_
  501. It works more smoothly if you can modify the sshd server settings on the
  502. remote end.
  503. .. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding
  504. Using PGP with Git
  505. ==================
  506. One of the core features of Git is its decentralized nature -- once a
  507. repository is cloned to your system, you have full history of the
  508. project, including all of its tags, commits and branches. However, with
  509. hundreds of cloned repositories floating around, how does anyone verify
  510. that their copy of linux.git has not been tampered with by a malicious
  511. third party?
  512. Or what happens if a backdoor is discovered in the code and the "Author"
  513. line in the commit says it was done by you, while you're pretty sure you
  514. had `nothing to do with it`_?
  515. To address both of these issues, Git introduced PGP integration. Signed
  516. tags prove the repository integrity by assuring that its contents are
  517. exactly the same as on the workstation of the developer who created the
  518. tag, while signed commits make it nearly impossible for someone to
  519. impersonate you without having access to your PGP keys.
  520. .. _`nothing to do with it`: https://github.com/jayphelps/git-blame-someone-else
  521. Configure git to use your PGP key
  522. ---------------------------------
  523. If you only have one secret key in your keyring, then you don't really
  524. need to do anything extra, as it becomes your default key. However, if
  525. you happen to have multiple secret keys, you can tell git which key
  526. should be used (``[fpr]`` is the fingerprint of your key)::
  527. $ git config --global user.signingKey [fpr]
  528. **IMPORTANT**: If you have a distinct ``gpg2`` command, then you should
  529. tell git to always use it instead of the legacy ``gpg`` from version 1::
  530. $ git config --global gpg.program gpg2
  531. $ git config --global gpgv.program gpgv2
  532. How to work with signed tags
  533. ----------------------------
  534. To create a signed tag, simply pass the ``-s`` switch to the tag
  535. command::
  536. $ git tag -s [tagname]
  537. Our recommendation is to always sign git tags, as this allows other
  538. developers to ensure that the git repository they are pulling from has
  539. not been maliciously altered.
  540. How to verify signed tags
  541. ~~~~~~~~~~~~~~~~~~~~~~~~~
  542. To verify a signed tag, simply use the ``verify-tag`` command::
  543. $ git verify-tag [tagname]
  544. If you are pulling a tag from another fork of the project repository,
  545. git should automatically verify the signature at the tip you're pulling
  546. and show you the results during the merge operation::
  547. $ git pull [url] tags/sometag
  548. The merge message will contain something like this::
  549. Merge tag 'sometag' of [url]
  550. [Tag message]
  551. # gpg: Signature made [...]
  552. # gpg: Good signature from [...]
  553. If you are verifying someone else's git tag, then you will need to
  554. import their PGP key. Please refer to the
  555. ":ref:`verify_identities`" section below.
  556. .. note::
  557. If you get "``gpg: Can't check signature: unknown pubkey
  558. algorithm``" error, you need to tell git to use gpgv2 for
  559. verification, so it properly processes signatures made by ECC keys.
  560. See instructions at the start of this section.
  561. Configure git to always sign annotated tags
  562. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  563. Chances are, if you're creating an annotated tag, you'll want to sign
  564. it. To force git to always sign annotated tags, you can set a global
  565. configuration option::
  566. $ git config --global tag.forceSignAnnotated true
  567. How to work with signed commits
  568. -------------------------------
  569. It is easy to create signed commits, but it is much more difficult to
  570. use them in Linux kernel development, since it relies on patches sent to
  571. the mailing list, and this workflow does not preserve PGP commit
  572. signatures. Furthermore, when rebasing your repository to match
  573. upstream, even your own PGP commit signatures will end up discarded. For
  574. this reason, most kernel developers don't bother signing their commits
  575. and will ignore signed commits in any external repositories that they
  576. rely upon in their work.
  577. However, if you have your working git tree publicly available at some
  578. git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
  579. then the recommendation is that you sign all your git commits even if
  580. upstream developers do not directly benefit from this practice.
  581. We recommend this for the following reasons:
  582. 1. Should there ever be a need to perform code forensics or track code
  583. provenance, even externally maintained trees carrying PGP commit
  584. signatures will be valuable for such purposes.
  585. 2. If you ever need to re-clone your local repository (for example,
  586. after a disk failure), this lets you easily verify the repository
  587. integrity before resuming your work.
  588. 3. If someone needs to cherry-pick your commits, this allows them to
  589. quickly verify their integrity before applying them.
  590. Creating signed commits
  591. ~~~~~~~~~~~~~~~~~~~~~~~
  592. To create a signed commit, you just need to pass the ``-S`` flag to the
  593. ``git commit`` command (it's capital ``-S`` due to collision with
  594. another flag)::
  595. $ git commit -S
  596. Configure git to always sign commits
  597. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  598. You can tell git to always sign commits::
  599. git config --global commit.gpgSign true
  600. .. note::
  601. Make sure you configure ``gpg-agent`` before you turn this on.
  602. .. _verify_identities:
  603. How to verify kernel developer identities
  604. =========================================
  605. Signing tags and commits is easy, but how does one go about verifying
  606. that the key used to sign something belongs to the actual kernel
  607. developer and not to a malicious imposter?
  608. Configure auto-key-retrieval using WKD and DANE
  609. -----------------------------------------------
  610. If you are not already someone with an extensive collection of other
  611. developers' public keys, then you can jumpstart your keyring by relying
  612. on key auto-discovery and auto-retrieval. GnuPG can piggyback on other
  613. delegated trust technologies, namely DNSSEC and TLS, to get you going if
  614. the prospect of starting your own Web of Trust from scratch is too
  615. daunting.
  616. Add the following to your ``~/.gnupg/gpg.conf``::
  617. auto-key-locate wkd,dane,local
  618. auto-key-retrieve
  619. DNS-Based Authentication of Named Entities ("DANE") is a method for
  620. publishing public keys in DNS and securing them using DNSSEC signed
  621. zones. Web Key Directory ("WKD") is the alternative method that uses
  622. https lookups for the same purpose. When using either DANE or WKD for
  623. looking up public keys, GnuPG will validate DNSSEC or TLS certificates,
  624. respectively, before adding auto-retrieved public keys to your local
  625. keyring.
  626. Kernel.org publishes the WKD for all developers who have kernel.org
  627. accounts. Once you have the above changes in your ``gpg.conf``, you can
  628. auto-retrieve the keys for Linus Torvalds and Greg Kroah-Hartman (if you
  629. don't already have them)::
  630. $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
  631. If you have a kernel.org account, then you should `add the kernel.org
  632. UID to your key`_ to make WKD more useful to other kernel developers.
  633. .. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
  634. Web of Trust (WOT) vs. Trust on First Use (TOFU)
  635. ------------------------------------------------
  636. PGP incorporates a trust delegation mechanism known as the "Web of
  637. Trust." At its core, this is an attempt to replace the need for
  638. centralized Certification Authorities of the HTTPS/TLS world. Instead of
  639. various software makers dictating who should be your trusted certifying
  640. entity, PGP leaves this responsibility to each user.
  641. Unfortunately, very few people understand how the Web of Trust works.
  642. While it remains an important aspect of the OpenPGP specification,
  643. recent versions of GnuPG (2.2 and above) have implemented an alternative
  644. mechanism called "Trust on First Use" (TOFU). You can think of TOFU as
  645. "the SSH-like approach to trust." With SSH, the first time you connect
  646. to a remote system, its key fingerprint is recorded and remembered. If
  647. the key changes in the future, the SSH client will alert you and refuse
  648. to connect, forcing you to make a decision on whether you choose to
  649. trust the changed key or not. Similarly, the first time you import
  650. someone's PGP key, it is assumed to be valid. If at any point in the
  651. future GnuPG comes across another key with the same identity, both the
  652. previously imported key and the new key will be marked as invalid and
  653. you will need to manually figure out which one to keep.
  654. We recommend that you use the combined TOFU+PGP trust model (which is
  655. the new default in GnuPG v2). To set it, add (or modify) the
  656. ``trust-model`` setting in ``~/.gnupg/gpg.conf``::
  657. trust-model tofu+pgp
  658. How to use keyservers (more) safely
  659. -----------------------------------
  660. If you get a "No public key" error when trying to validate someone's
  661. tag, then you should attempt to lookup that key using a keyserver. It is
  662. important to keep in mind that there is absolutely no guarantee that the
  663. key you retrieve from PGP keyservers belongs to the actual person --
  664. that much is by design. You are supposed to use the Web of Trust to
  665. establish key validity.
  666. How to properly maintain the Web of Trust is beyond the scope of this
  667. document, simply because doing it properly requires both effort and
  668. dedication that tends to be beyond the caring threshold of most human
  669. beings. Here are some shortcuts that will help you reduce the risk of
  670. importing a malicious key.
  671. First, let's say you've tried to run ``git verify-tag`` but it returned
  672. an error saying the key is not found::
  673. $ git verify-tag sunxi-fixes-for-4.15-2
  674. gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
  675. gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
  676. gpg: issuer "wens@...org"
  677. gpg: Can't check signature: No public key
  678. Let's query the keyserver for more info about that key fingerprint (the
  679. fingerprint probably belongs to a subkey, so we can't use it directly
  680. without finding out the ID of the master key it is associated with)::
  681. $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
  682. gpg: data source: hkp://keys.gnupg.net
  683. (1) Chen-Yu Tsai <wens@...org>
  684. 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
  685. Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q
  686. Locate the ID of the master key in the output, in our example
  687. ``C94035C21B4F2AEB``. Now display the key of Linus Torvalds that you
  688. have on your keyring::
  689. $ gpg --list-key torvalds@kernel.org
  690. pub rsa2048 2011-09-20 [SC]
  691. ABAF11C65A2970B130ABE3C479BE3E4300411886
  692. uid [ unknown] Linus Torvalds <torvalds@kernel.org>
  693. sub rsa2048 2011-09-20 [E]
  694. Next, open the `PGP pathfinder`_. In the "From" field, paste the key
  695. fingerprint of Linus Torvalds from the output above. In the "To" field,
  696. paste the key-id you found via ``gpg --search`` of the unknown key, and
  697. check the results:
  698. - `Finding paths to Linus`_
  699. If you get a few decent trust paths, then it's a pretty good indication
  700. that it is a valid key. You can add it to your keyring from the
  701. keyserver now::
  702. $ gpg --recv-key C94035C21B4F2AEB
  703. This process is not perfect, and you are obviously trusting the
  704. administrators of the PGP Pathfinder service to not be malicious (in
  705. fact, this goes against :ref:`devs_not_infra`). However, if you
  706. do not carefully maintain your own web of trust, then it is a marked
  707. improvement over blindly trusting keyservers.
  708. .. _`PGP pathfinder`: https://pgp.cs.uu.nl/
  709. .. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html