「GnuPG」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (→参照: リンクを修正) |
Kusanaginoturugi (トーク | 投稿記録) (→鍵サーバー: 一部飜訳) |
||
138行目: | 138行目: | ||
==== 鍵サーバー ==== |
==== 鍵サーバー ==== |
||
+ | 最も一般的な鍵サーバーは次の通りです。 |
||
− | The most common keyservers are: |
||
− | * [https://keyserver.ubuntu.com Ubuntu |
+ | * [https://keyserver.ubuntu.com Ubuntu 鍵サーバー]: federated, no verification, keys cannot be deleted. |
* [https://sks-keyservers.net SKS Keyserver Pool]{{Dead link|2021|05|13|status=SSL error}}: federated, no verification, keys cannot be deleted. |
* [https://sks-keyservers.net SKS Keyserver Pool]{{Dead link|2021|05|13|status=SSL error}}: federated, no verification, keys cannot be deleted. |
||
− | * [https://keys.mailvelope.com Mailvelope |
+ | * [https://keys.mailvelope.com Mailvelope 鍵サーバー]: central, verification of email IDs, keys can be deleted. |
* [https://keys.openpgp.org keys.openpgp.org]: central, verification of email IDs, keys can be deleted, no third-party signatures (i.e. no Web of Trust support). |
* [https://keys.openpgp.org keys.openpgp.org]: central, verification of email IDs, keys can be deleted, no third-party signatures (i.e. no Web of Trust support). |
||
− | + | 詳細は [[Wikipedia:Key server (cryptographic)#Keyserver examples]] に一覧があります。 |
|
An alternative key server can be specified with the {{ic|keyserver}} option in one of the [[#Configuration files]], for instance: |
An alternative key server can be specified with the {{ic|keyserver}} option in one of the [[#Configuration files]], for instance: |
2021年11月28日 (日) 23:09時点における版
公式サイト によれば:
- GnuPG は RFC4880 (別名 PGP) で定義される OpenPGP 標準の完全でフリーな実装です。GnuPG を使うことでデータや通信を暗号化したり署名することができます。多目的の鍵管理システムであり、あらゆる種類の公開鍵ディレクトリのアクセスモジュールです。GnuPG (またの名を GPG) は他のアプリケーションとの簡単に連携できる機能を備えたコマンドラインツールです。豊富なアプリケーションとライブラリが利用可能です。GnuPG のバージョン2は S/MIME と ssh のサポートも含んでいます。
目次
- 1 インストール
- 2 設定
- 3 使い方
- 4 鍵の管理
- 5 署名
- 6 gpg-agent
- 7 スマートカード
- 8 ヒントとテクニック
- 9 トラブルシューティング
- 9.1 Not enough random bytes available
- 9.2 su
- 9.3 エージェントがファイルの終末についてエラーを表示する
- 9.4 KGpg 設定のパーミッション
- 9.5 GNOME on Wayland で SSH エージェントのソケットが上書きされる
- 9.6 mutt
- 9.7 gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する
- 9.8 (鍵を受信しようとすると) どのキーサーバーでも gpg がフリーズする
- 9.9 スマートカードが検出されない
- 9.10 gpg: WARNING: server 'gpg-agent' is older than us (x < y)
- 9.11 IPC connect call failed
- 9.12 Mitigating Poisoned PGP Certificates
- 9.13 Invalid IPC response and Inappropriate ioctl for device
- 10 参照
インストール
gnupg をインストールしてください。
gnupg をインストールすると、GnuPG がパスフレーズエントリに使用するシンプルな PIN やパスフレーズエントリダイアログのコレクションである pinentry もインストールされます。pinentry はシンボリックリンク /usr/bin/pinentry
によって決められ、デフォルトでは /usr/bin/pinentry-gtk-2
になります。
グラフィカルフロントエンドや GnuPG と連携するプログラムを使いたい場合はアプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィーを参照してください。
設定
設定ファイルのディレクトリ
GnuPG では $GNUPGHOME
によって全ての設定ファイルを保存するディレクトリが指定されます。デフォルトでは $GNUPGHOME
は設定されておらず、代わりに $HOME
が使われます。そのためインストール直後は ~/.gnupg
ディレクトリが確認できます。スタートアップファイルに次の行を記述することでデフォルト設定を変更できます:
export GNUPGHOME="/path/to/directory"
設定ファイル
デフォルトの設定ファイルは ~/.gnupg/gpg.conf
と ~/.gnupg/dirmngr.conf
です。
デフォルトでは、gnupg ディレクトリのパーミッションは 700 に設定されており、ディレクトリのファイルのパーミッションは 600 に設定されています。ファイルの読み書きやアクセスの権限を持っているのはディレクトリの所有者だけです (r,w,x)。これはセキュリティ上の理由で設定されていることなので変更してはいけません。ディレクトリやファイルがこのセキュリティ対策に従っていない場合、ファイルやホームディレクトリのパーミッションが安全ではないという警告が表示されます。
どんな長いオプションも設定ファイルに追加します。2つのダッシュを書かないで、オプションや必要な引数の名前を書いて下さい。スケルトンファイルは /usr/share/doc/gnupg/
にあります。gpg がなんらかの操作のため最初に起動されたとき、~/.gnupg
が存在しなければこれらのファイルが ~/.gnupg
にコピーされます。#参照 に他の例があります。
また、pacman がパッケージの署名の検証に使用する設定ファイルは別に存在します。詳しくは pacman-key を見てください。
新規ユーザーのデフォルトオプション
新規ユーザーのデフォルトオプションを設定したい場合、/etc/skel/.gnupg/
に設定ファイルを配置してください。新しいユーザーが追加されると、/etc/skel/.gnupg/
から GnuPG のホームディレクトリにファイルがコピーされます。既存のユーザーのために新しい GnuPG ホームディレクトリを作成できる addgnupghome というスクリプトも存在します:
# addgnupghome user1 user2
上記のコマンドは /home/user1/.gnupg
と /home/user2/.gnupg
を作成してスケルトンディレクトリからファイルをコピーします。既に GnuPG のホームディレクトリが存在するユーザーはスキップされます。
使い方
鍵ペアの作成
鍵ペアを生成するにはターミナルに次を入力:
$ gpg --full-gen-key
上記のコマンドを実行すると複数の質問がきかれます。大抵の場合、以下の設定が必要になります:
- RSA (署名のみ) と RSA (暗号化のみ) 鍵。
- 鍵長は2048ビットで十分です。4096ビットを使ったところで "大した効果はありませんし、無駄に時間がかかるようになるだけです" 。
- 副鍵の有効期限の設定は技術的には必須ではありませんが、設定することは悪くありません。標準的なユーザーなら、1年間で十分でしょう。たとえ鍵束へのアクセスを失っても、他の人が有効でないことを知ることができるようになります。鍵を作成した後、新しい鍵を再発行しなくても満了日は延長することができます。
- 名前とメールアドレス。後で同じ鍵に別の識別子を追加できます (複数のメールアドレスが存在する場合など)。
- コメントは必要ありません。コメントフィールドのセマンティクスは 定義があやふや なため、識別子としては限定的です。
- 安全なパスフレーズを選ぶようにしてください (セキュリティ#パスワードの管理を参照)。
鍵一覧
- 公開鍵束の鍵の一覧:
$ gpg --list-keys
- 秘密鍵束の鍵の一覧:
$ gpg --list-secret-keys
公開鍵のエクスポート
公開鍵暗号で交換されたメッセージの機密性を保証するのが gpg の主な利用法です。互いの鍵束の公開鍵を交換して、メッセージを暗号化するときに使用します。秘密鍵は必ず漏洩しないようにしてください。機密性が破れてしまいます。
他の人があなたに暗号化したメッセージを送れるようにするには、彼らがあなたの公開鍵を知っている必要があります。
(メールで送る場合などのために) ASCII 版の公開鍵を public.key
ファイルとして生成するには:
$ gpg --output public.key --armor --export user-id
あるいは、鍵サーバーで鍵を共有する方法もあります。
公開鍵のインポート
メッセージを暗号化して他の人に送るには、彼らの公開鍵が必要です。公開鍵 (public.key
) を自分の公開鍵リングにインポートするには:
$ gpg --import public.key
あるいは、鍵サーバーで公開鍵を見つけます。
If you wish to import a key ID to install a specific Arch Linux package, see pacman/Package signing#Managing the keyring and Makepkg#Signature checking.
鍵サーバーを使用する
鍵の送信
自分の公開鍵を公共の PGP 鍵サーバーに登録することで、他の人があなたに直接連絡することなしにあなたの鍵を入手できるようになります:
$ gpg --send-keys user-id
鍵の検索と受信
鍵サーバーの鍵の情報を確認したい場合、次のコマンドを実行:
$ gpg --search-keys user-id
鍵サーバーから鍵をインポートするには:
$ gpg --recv-keys key-id
鍵サーバー
最も一般的な鍵サーバーは次の通りです。
- Ubuntu 鍵サーバー: federated, no verification, keys cannot be deleted.
- SKS Keyserver Pool[リンク切れ 2021-05-13]: federated, no verification, keys cannot be deleted.
- Mailvelope 鍵サーバー: central, verification of email IDs, keys can be deleted.
- keys.openpgp.org: central, verification of email IDs, keys can be deleted, no third-party signatures (i.e. no Web of Trust support).
詳細は Wikipedia:Key server (cryptographic)#Keyserver examples に一覧があります。
An alternative key server can be specified with the keyserver
option in one of the #Configuration files, for instance:
~/.gnupg/dirmngr.conf
keyserver hkp://pool.sks-keyservers.net
A temporary use of another server is handy when the regular one does not work as it should. It can be achieved by, for example,
$ gpg --keyserver hkps://keys.openpgp.org/ --search-keys 931FF8E79F0876134EDDBDCCA87FF9DF48BF1C90
Web Key Directory
The Web Key Service (WKS) protocol is a new standard for key distribution, where the email domain provides its own key server called Web Key Directory (WKD). When encrypting to an email address (e.g. user@example.com
), GnuPG (>=2.1.16) will query the domain (example.com
) via HTTPS for the public OpenPGP key if it is not already in the local keyring. The option auto-key-locate
will locate a key using the WKD protocol if there is no key on the local keyring for this email address.
# gpg --recipient user@example.org --auto-key-locate --encrypt doc
See the GnuPG Wiki for a list of email providers that support WKD. If you control the domain of your email address yourself, you can follow this guide to enable WKD for your domain. To check if your key can be found in the WKD you can use this webinterface.
暗号化と復号化
非対称
暗号化や復号化をするときは複数の秘密鍵を使用することが可能です。複数の鍵を使うときは使用する鍵を選択する必要があります。-u <user-id>
オプションや --local-user <user-id>
オプションを使うことで選択できます。このオプションを使うとデフォルトの鍵を使用する代わりに指定された鍵を使用します。先に#鍵の作成が必要です。
(テキストでメッセージをコピー&ペーストするのに適している) ASCII armor を使ってファイルを暗号化するには、次を使用:
$ gpg --encrypt --armor secret.txt
単に暗号化だけしたいときは --armor
は不要です。
ファイルを復号化するには、次のコマンドを使用:
$ gpg --decrypt secret.txt.asc
パスフレーズの入力が求められます。復号化するには送信者の公開鍵をインポートしてある必要があります。
対称
対称暗号化では鍵を生成する必要がなくパスフレーズだけでデータを暗号化できます。対称暗号化を使用するするには --symmetric
または -c
を使用します:
$ gpg -c doc
例:
- パスフレーズを使って対称暗号で
doc
を暗号化。 - AES-256 暗号アルゴリズムを使ってパスフレーズを暗号化。
- SHA-512 ダイジェストアルゴリズムを使ってパスフレーズをハッシュ化。
- 65536回繰り返しパスフレーズをハッシュ化。
$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 doc
対称暗号化された doc.gpg
をパスフレーズで復号化して doc
として同じディレクトリに出力するには:
$ gpg --output doc --decrypt doc.gpg
Directory
Encrypting/decrypting a directory can be done with gpgtar(1).
Encrypt:
$ gpgtar -c -o dir.gpg dir
Decrypt:
$ gpgtar -d dir.gpg
鍵の管理
秘密鍵のバックアップ
秘密鍵をバックアップするには以下を実行:
$ gpg --export-secret-keys --armor <user-id> > privkey.asc
gpg のリリース 2.1 からデフォルトの挙動が変わっており、たとえ鍵の作成時にパスワードを設定しなかった場合でも上記のコマンドを実行したときにパスフレーズによる保護が必須になっています。エクスポートされたファイルを入手してしまえば、パスフレーズを知らなくてもファイルを暗号化したり署名を加えることができてしまうためです。
秘密鍵のバックアップをインポートするには:
$ gpg --import privkey.asc
Backup your revocation certificate
Revocation certificates are automatically generated for newly generated keys. These are by default located in ~/.gnupg/openpgp-revocs.d/
. The filename of the certificate is the fingerprint of the key it will revoke.
The revocation certificates can also be generated manually by the user later using:
$ gpg --gen-revoke --armor --output revcert.asc user-id
This certificate can be used to #Revoke a key if it is ever lost or compromised. The backup will be useful if you have no longer access to the secret key and are therefore not able to generate a new revocation certificate with the above command. It is short enough to be printed out and typed in by hand if necessary.
鍵の編集
gpg --edit-key <user-id>
コマンドを実行するとメニューが表示され、鍵管理に関連するほとんどの作業を行うことができます。以下は満了日を設定する例です:
$ gpg --edit-key <user-id> > key number > expire yyyy-mm-dd > save > quit
便利なコマンド:
> passwd # change the passphrase > clean # compact any user ID that is no longer usable (e.g revoked or expired) > revkey # revoke a key > addkey # add a subkey to this key > expire # change the key expiration time
- 公開鍵の ASCII バージョンを生成 (例: メールなどで配るため):
$ gpg --armor --output public.key --export <user-id>
- PGP 公開鍵サーバーに鍵を登録して、他の人があなたに直接連絡しなくても鍵を取得できるようにする:
$ gpg --keyserver pgp.mit.edu --send-keys <key-id>
- ユーザー Bob あてに署名と暗号化:
$ gpg -se -r Bob file
- クリアテキスト署名を作成:
$ gpg --clearsign file
副鍵のエクスポート
複数のデバイスで同じ鍵を使い回す場合、マスター鍵を分離させて、セキュリティが低いシステムでは暗号化に必要な副鍵だけを使いたいという状況が考えられます。
まず、エクスポートしたい副鍵を確認してください:
$ gpg -K
エクスポートする副鍵だけを選択:
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg
ここで作業を終えても良いですが、パスフレーズの変更もしておくと安全です。一時フォルダに鍵をインポートします:
$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg $ gpg --homedir /tmp/gpg --edit-key <user-id> > passwd > save $ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg
これで、他のデバイスで /tmp/subkey.altpass.gpg
を使うことができます。
副鍵の使用
副鍵を設定して一定期間後に満了したら、新しい副鍵を作成できます。他のユーザーが鍵束を更新できるように数週間前に行うようにしましょう。
- 新しい副鍵を作成 (署名と暗号化の鍵の両方)
$ gpg --edit-key <user-id> > addkey
そして質問に答えて下さい (推奨される設定については前のセクションを参照)。
- 変更を保存:
> save
- キーサーバーにアップデート:
$ gpg --keyserver pgp.mit.edu --send-keys <user-id>
署名
署名は文章を証明します。文章が改変された場合、署名の検証に失敗します。公開鍵を使用して文章を暗号化する暗号化とは違って、署名はユーザーの秘密鍵を使って作成されます。署名された文章を受け取った人は送り主の公開鍵を使って署名を検証できます。
署名の作成
ファイルに署名する
ファイルに署名するには --sign
または -s
フラグを使います:
$ gpg --output doc.sig --sign doc
上記のコマンドは暗号化も行ってファイルをバイナリ形式で保存します。
ファイルやメッセージにクリア署名
バイナリ形式に圧縮しないでファイルに署名するには:
$ gpg --clearsign doc
上記のコマンドは文章を ASCII-armored 署名でラッピングしますが、文章に変更は加えられません。
分離署名を作成する
文章やファイルとは別に署名ファイルを作成したい場合、--detach-sig
フラグを使ってください:
$ gpg --output doc.sig --detach-sig doc
上記の方法はソフトウェアプロジェクトを配布するときによく用いられます。署名書を検証することで第三者によってファイルが改竄されていないことが確認できます。
署名の検証
署名を検証するには --verify
フラグを使います:
$ gpg --verify doc.sig
doc.sig
は検証したい署名に置き換えてください。
ファイルの検証と復号化を同時に行いたいお場合、--decrypt
フラグを使ってください。
分離署名を検証する場合、ファイルと署名の両方が必要になります。例えば、Arch Linux の ISO を検証する場合:
$ gpg --verify archlinux-version.iso.sig
archlinux-version.iso
が同じディレクトリに存在していなければなりません。
署名の確認
署名を確認するには、--verify
フラグを使用します。
$ gpg --verify doc.sig
where doc.sig
is the signed file containing the signature you wish to verify.
If you are verifying a detached signature, both the signed data file and the signature file must be present when verifying. For example, to verify Arch Linux's latest iso you would do:
$ gpg --verify archlinux-version.iso.sig
where archlinux-version.iso
must be located in the same directory.
You can also specify the signed data file with a second argument:
$ gpg --verify archlinux-version.iso.sig /path/to/archlinux-version.iso
If a file has been encrypted in addition to being signed, simply decrypt the file and its signature will also be verified.
gpg-agent
gpg-agent はキーチェインにパスワードをリクエストしたりキャッシュしたりするのに使われるデーモンです。メールクライアントなど外部のプログラムから GnuPG を利用する場合に便利です。gnupg には systemd ユーザーソケットが付属しており、デフォルトで有効になります: gpg-agent.socket
, gpg-agent-extra.socket
, gpg-agent-browser.socket
, gpg-agent-ssh.socket
, dirmngr.socket
。
- gpg はメインの
gpg-agent.socket
を使って gpg-agent デーモンに接続します。 gpg-agent-extra.socket
はリモート環境から Unix ドメインソケットの転送を設定します。秘密鍵をリモート環境に移さなくてもリモート環境で gpg が使えるようになります。詳しくは gpg-agent(1) を参照。- The
gpg-agent-browser.socket
allows web browsers to access the gpg-agent daemon. - SSH は
gpg-agent-ssh.socket
を使って ssh-add プログラムによって追加された SSH 鍵をキャッシュします。必要な設定は #SSH エージェントを見てください。 dirmngr.socket
は鍵サーバーへの接続を処理する GnuPG デーモンを起動します。
設定
gpg-agent は ~/.gnupg/gpg-agent.conf
ファイルで設定することができます。設定オプションは gpg-agent(1) に記載されています。例えば、未使用の鍵の cache ttl を変更することができます:
~/.gnupg/gpg-agent.conf
default-cache-ttl 3600
エージェントのリロード
設定を変更した後は、gpg-connect-agent
でエージェントをリロードしてください:
$ gpg-connect-agent reloadagent /bye
シェルに OK
と出力されます。
However in some cases only the restart may not be sufficient, like when keep-screen
has been added to the agent configuration.
In this case you firstly need to kill the ongoing gpg-agent process and then you can restart it as was explained above.
pinentry
最後に、ユーザーにパスワードを尋ねる方法をエージェントに設定する必要があります。gpg-agent の設定ファイルで設定できます。
デフォルトでは gtk のダイアログが使われます。使用できるオプションは info pinentry
を見て下さい。ダイアログの実装を変更するには pinentry-program
設定オプションを設定します:
~/.gnupg/gpg-agent.conf
# PIN entry program # pinentry-program /usr/bin/pinentry-curses # pinentry-program /usr/bin/pinentry-qt # pinentry-program /usr/bin/pinentry-kwallet pinentry-program /usr/bin/pinentry-gtk-2
変更を行った後は、gpg-agent をリロードしてください。
パスワードのキャッシュ
GnuPG のパスワードをセッションの間だけ記憶させたい場合、max-cache-ttl
と default-cache-ttl
を高い値に設定してください:
gpg-agent.conf
max-cache-ttl 60480000 default-cache-ttl 60480000
詳しくは #gpg-agent を参照。
無人のパスフレーズ
GnuPG 2.1.0 から gpg-agent と pinentry の利用が必須になりました。これによって --passphrase-fd 0
コマンドラインオプションによって STDIN からパイプで渡されたパスフレーズの後方互換性が損ねられています。古いリリースと同じような機能を使うには2つのことをする必要があります:
まず、gpg-agent の設定を編集して loopback pinentry モードを許可してください:
~/.gnupg/gpg-agent.conf
allow-loopback-pinentry
gpg-agent プロセスが実行している場合は再起動して変更を適用します。
次に、更新する必要があるアプリケーションに以下のようにコマンドラインパラメータを含めて loopback モードを使用します:
$ gpg --pinentry-mode loopback ...
もしくは、コマンドラインで設定ができない場合、オプションを設定に追加します:
~/.gnupg/gpg.conf
pinentry-mode loopback
SSH エージェント
gpg-agent には OpenSSH エージェントのエミュレーション機能が存在します。既に GnuPG スイートを使っているのであれば、SSH 鍵をキャッシュするのに使うことが可能です。さらに、パスフレーズを管理するのに GnuPG エージェントの PIN エントリダイアログを使えます。
SSH_AUTH_SOCK の設定
SSH が ssh-agent の代わりに gpg-agent を使うように SSH_AUTH_SOCK
を設定してください。シェルのタイプに関係なくプロセスが gpg-agent インスタンスを使うようにするには pam_env を使用します:
~/.pam_environment
SSH_AGENT_PID DEFAULT= SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
または、Bash を使う場合:
~/.bashrc
unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" fi
適切な TTY を使うように pinentry を設定
gpg-agent(1) にあるように、ユーザーを X セッションに切り替えた場合は GPG_TTY も設定して TTY を更新してください。例:
~/.bashrc
# Set GPG TTY export GPG_TTY=$(tty) # Refresh gpg-agent tty in case user switches into an X session gpg-connect-agent updatestartuptty /bye >/dev/null
If you use multiple terminals simultaneously and want gpg-agent to ask for passphrase via pinentry-curses from the same terminal where the ssh command was run, add the following to the SSH configuration file. This will make the TTY to be refreshed every time an ssh command is run [6]:
~/.ssh/config
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
Note that GPG_TTY environment variable has to be set for this to work.
SSH 鍵の追加
gpg-agent が起動していれば ssh-agent と同じように ssh-add で鍵を追加できます。追加された鍵は ~/.gnupg/sshcontrol
ファイルに保存されます。パスフレーズが必要になったときは毎回 pinentry ダイアログが表示されます。パスフレーズのキャッシュは ~/.gnupg/gpg-agent.conf
ファイルで制御します。以下の例では gpg-agent で鍵を3時間キャッシュします:
~/.gnupg/gpg-agent.conf
default-cache-ttl-ssh 10800 max-cache-ttl-ssh 10800
SSH 認証に PGP 鍵を使用する
PGP 鍵を SSH 鍵として使うこともできます。鍵のメンテナンスを楽にして SSH 鍵をキーカードに保存できます。認証機能を有効にして鍵を作成する必要があります (#カスタム機能を参照)。SSH 認証に PGP 鍵を使用することで得られる様々な利点があります。
- Reduced key maintenance, as you will no longer need to maintain an SSH key.
- The ability to store the authentication key on a smartcard. GnuPG will automatically detect the key when the card is available, and add it to the agent (check with
ssh-add -l
orssh-add -L
). The comment for the key should be something like:openpgp:key-id
orcardno:card-id
.
To retrieve the public key part of your GPG/SSH key, run gpg --export-ssh-key gpg-key
. If your key is authentication-capable but this command still fails with "Unusable public key", add a !
suffix ([7]).
Unless you have your GPG key on a keycard, you need to add your key to $GNUPGHOME/sshcontrol
to be recognized as a SSH key. If your key is on a keycard, its keygrip is added to sshcontrol
implicitly. If not, get the keygrip of your key this way:
$ gpg --list-keys --with-keygrip
sub rsa4096 2018-07-25 [A] Keygrip = 1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7
Then edit sshcontrol
like this. Adding the keygrip is a one-time action; you will not need to edit the file again, unless you are adding additional keys.
$GNUPGHOME/sshcontrol
1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7
スマートカード
GnuPG はスマートカードリーダーのインターフェイスとして scdaemon を使います。詳しくは man ページを参照してください。
GnuPG のみ設定
GnuPG ベース以外のカードを使う予定がない場合は、~/.gnupg/scdaemon.conf
の reader-port
パラメータを確認してください。'0' が最初に利用できるシリアルポートリーダーを、'32768' (デフォルト) が最初の USB リーダーを示しています。
GnuPG と OpenSC
opensc ドライバーであらゆるスマートカードを使う場合は (例: いろいろな国の ID カード)、GnuPG の設定に注意する必要があります。何も設定をしていないと gpg --card-status
を使った時に以下のようなメッセージが表示されることがあります:
gpg: selecting openpgp failed: ec=6.108
デフォルトでは、scdaemon はデバイスに直接接続しようとします。リーダーが他のプロセスによって使用中だとこの接続は失敗します。例えば: OpenSC によって使用される pcscd デーモン。この状況に対処するには、opensc と同じ基盤のドライバーを使って一緒に動作できるようにする必要があります。scdaemon に pcscd を使用させるため、~/.gnupg/scdaemon.conf
から reader-port
を削除して、libpcsclite.so
ライブラリの場所を指定し、ccid を無効化してください:
~/.gnupg/scdaemon.conf
pcsc-driver /usr/lib/libpcsclite.so card-timeout 5 disable-ccid
OpenSC を使わない場合は scdaemon(1) をチェックしてください。
ヒントとテクニック
他のアルゴリズム
強力なアルゴリズムを使用したい場合:
~/.gnupg/gpg.conf
... personal-digest-preferences SHA512 cert-digest-algo SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES
GnuPG の最新版では、デフォルトのアルゴリズムとして SHA256 と AES が使われており、どちらも殆どの場合安全です。しかしながら、2.1 以前の古い GnuPG を使っている場合や、さらに高いセキュリティを求めたい場合、上記のように設定するようにしてください。
パスワードの暗号化
パスワードを暗号化すれば、設定ファイルに平文で書き込まれなくなります。メールのパスワードなどが良い例でしょう。
まずパスワードを記述したファイルを作成してください。パスワードの後に空行を一行だけ追加しておく必要があります。そうしないとファイルを評価するときに gpg がエラーメッセージを返します。
そして次を実行:
$ gpg -e -a -r <user-id> your_password_file
-e
は encrypt、-a
は armor (ASCII 出力)、-r
は受取人のユーザー ID です。
新しく your_password_file.asc
ファイルが作られます。
鍵の無効化
新しい鍵を生成すると無効化証明書が自動的に生成されます。ユーザーが手動で後から生成することも可能です。無効化証明書は ~/.gnupg/openpgp-revocs.d/
に存在します。証明書のファイル名は無効化する鍵のフィンガープリントになります。
鍵を無効化したい場合、無効化証明書をインポートするだけです:
$ gpg --import <fingerprint>.rev
そして鍵サーバーをアップデート:
$ gpg --keyserver subkeys.pgp.net --send-keys <userid>
信頼モデルの変更
デフォルトでは GnuPG は信頼モデルとして Web of Trust を使います。Web of Trust から Trust on First に変更することが可能です。鍵を追加するときに --trust-model=tofu
を追加するか GnuPG の設定ファイルにオプションを追加してください。詳細は GnuPG メーリングリストのメール を参照。
受取人の id を全て隠す
デフォルトでは暗号メッセージには受取人の鍵 ID が含まれます。hidden-recipient <user-id>
を使うことで暗号化するときに ID は削除することが可能です。全ての受取人で ID を削除するには設定ファイルに throw-keyids
を追加してください。この設定によってメッセージの受取人を隠すことができ、トラフィックの解析に対抗することができます (ソーシャルエンジニアリングを使うことでメッセージを復号化できてしまえば誰が受取人なのか確認される可能性があります)。欠点としては、暗号鍵を全て試すことになるので復号化が遅くなります (--try-secret-key <user-id>
)。
キーサインパーティで caff を使う
キーサーバーやキーリングにある鍵の正当性をユーザーが確認 (つまり鍵の持ち主が本人であることを確認) できるように、PGP/GPG はいわゆる信頼の輪 ("Web of Trust") を利用しています。信頼の輪を維持するために様々なハッカーイベントが開かれており、キーサインパーティはそのひとつです。Zimmermann-Sassaman 鍵署名プロトコルはキーサインパーティを効果的に行うための方式です。こちら にハウツー記事があります。
キーサインパーティの後、鍵に署名したり所有者に署名を送るのを簡略化するために、caff というツールを使うことができます。AUR のパッケージ caff-svnAUR でインストールすることができます。
所有者に署名を送信するには MTA が必要です。MTA を設定していない場合、msmtp をインストールして下さい。
長い ID やフィンガープリントを毎回表示する
長い鍵 ID を表示させるには設定ファイルに keyid-format 0xlong
を追加してください。鍵の指紋を完全に表示するには、設定ファイルに with-fingerprint
を追加してください。
カスタム機能
鍵にカスタム機能を設定することができます。以下の機能を使うことが可能です:
- Certify (マスター鍵のみ) - 副鍵の作成ができるようになります。
- Sign - 公開鍵で検証することができる暗号化署名が作成可能になります。
- Encrypt - 公開鍵でデータを暗号化して、秘密鍵で復号化することができます。
- Authenticate - GnuPG 以外のプログラムで鍵を使って認証できます。SSH 鍵として使用することができるようになります。
マスター鍵の機能は以下のコマンドで指定できます:
$ gpg --full-generate-key --expert
オプションを選択して機能を設定することができます。
副鍵にカスタム機能を指定したい場合、gpg --edit-key
に --expert
フラグを追加してください。詳しくは#鍵の編集を参照。
トラブルシューティング
Not enough random bytes available
鍵を生成するときに、gpg は以下のエラーを表示することがあります:
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!
残っているエントロピーを確認するには、カーネルパラメータをチェックしてください:
$ cat /proc/sys/kernel/random/entropy_avail
エントロピーがたくさんある健康的な Linux 環境ならマックスの 4,096 ビットに近い値が返されます。返ってくる値が 200 以下の場合、システムのエントロピーが足りていません。
エントロピー問題を解決するには、メッセージ通りのことをするのがベストです (例: ディスクを動かす、マウスを動かす、wiki を編集する - 何でもエントロピーの生成に繋がります)。それでも問題が解決しない場合、エントロピーを使い果たしているサービスが何なのかチェックして、しばらくそのサービスを停止してみてください。サービスを停止できない場合、乱数生成#高速な RNG を見て下さい。
su
pinentry
を使う場合、使用するターミナルデバイス (例: /dev/tty1
) の適切なパーミッションが必要です。しかしながら、su (または sudo) を使用すると、所有権は元のユーザーに残り、新しいユーザーにはなくなります。これでは pinentry はたとえ root であっても起動しません。pinentry を使用する (つまりエージェントで gpg を使用する) 前にデバイスのパーミッションを同じ所に変更する必要があります。root で gpg を実行する場合、gpg を使用する直前に所有者を root に変更してください:
# chown root /dev/ttyN # where N is the current tty
そして gpg を使用した後に元に戻して下さい。おそらく /dev/pts/
と同じのが正しいです。
エージェントがファイルの終末についてエラーを表示する
デフォルトの pinentry プログラムは pinentry-gtk-2 であり、D-Bus セッションバスを正しく実行する必要があります。詳しくは一般的なトラブルシューティング#セッションのパーミッションを見て下さい。
もしくは、pinentry-qt
を使うこともできます。#pinentry を参照。
KGpg 設定のパーミッション
kgpg には ~/.gnupg/
のオプションが使えないという問題がありました。非推奨となった options ファイルが原因です。バグ レポートを参照してください。
GNOME on Wayland で SSH エージェントのソケットが上書きされる
Wayland のセッションでは、gnome-session
によって SSH_AUTH_SOCK
が標準の gnome-keyring ソケット $XDG_RUNTIME_DIR/keyring/ssh
に設定されます。このため ~/.pam_environmment
や systemd のユニットファイルで設定した値が上書きされてしまいます。
この挙動を無効化するには GSM_SKIP_AGENT_WORKAROUND
変数を設定してください:
~/.pam_environment
SSH_AGENT_PID DEFAULT= SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh" GSM_SKIP_SSH_AGENT_WORKAROUND DEFAULT="true"
mutt
Mutt は gpg-agent を正しく使用できないため、mutt を使う場合は GPG_AGENT_INFO
環境変数を設定する必要があります (中身は何でもかまいません)。パスワードのキャッシュも有効化してください。
詳しくは フォーラムスレッド を参照してください。
gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する
gpg --list-keys
を実行しても以前まで使っていた鍵が表示されない場合、また、アプリケーションが鍵を見つけられないまたは鍵が不正だとエラーを吐く場合、鍵が新しいフォーマットに移行できていない可能性があります。
GnuPG invalid packet workaround を読んで下さい。要約すると、旧式の pubring.gpg
と secring.gpg
ファイルの鍵にはバグが存在しており、新しい pubring.kbx
ファイルと private-keys-v1.d/
サブディレクトリ、そしてディレクトリのファイルによって置き換えられたということが書かれています。以下のコマンドを実行することで消失した鍵を復旧させることができるかもしれません:
$ cd $ cp -r .gnupg gnupgOLD $ gpg --export-ownertrust > otrust.txt $ gpg --import .gnupg/pubring.gpg $ gpg --import-ownertrust otrust.txt $ gpg --list-keys
(鍵を受信しようとすると) どのキーサーバーでも gpg がフリーズする
特定のキーサーバーで鍵を受信しようとして gpg がフリーズしている場合、dirmngr を kill して (問題が起こっていない) 他のキーサーバーにアクセスできるようにする必要があります。そうしないと全てのキーサーバーでフリーズしてしまいます。
スマートカードが検出されない
スマートカードにアクセスするための権限がない場合、カードを正しく設定して接続しても、card error
が表示されることがあります。
スマートカードにアクセスする必要があるユーザーに scard
を追加することで解決できます。追加したら、以下のような udev ルールを作って下さい:
/etc/udev/rules.d/71-gnupg-ccid.rules
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"
VENDOR と MODEL は lsusb
の出力にあわせて変更する必要があります。上記は YubikeyNEO の例です。
gpg: WARNING: server 'gpg-agent' is older than us (x < y)
gnupg
をアップグレードしたのに古い gpg-agent が動作し続けていると警告が表示されます。ユーザーの gpg-agent.socket
を再起動してください (再起動するときに --user
フラグを使ってください)。
IPC connect call failed
Make sure gpg-agent
and dirmngr
are not running with killall gpg-agent dirmngr
and the $GNUPGHOME/crls.d/
folder has permission set to 700
.
If your keyring is stored on a vFat filesystem (e.g. a USB drive), gpg-agent
will fail to create the required sockets (vFat does not support sockets), you can create redirects to a location that handles sockets, e.g. /dev/shm
:
# export GNUPGHOME=/custom/gpg/home # printf '%%Assuan%%\nsocket=/dev/shm/S.gpg-agent\n' > $GNUPGHOME/S.gpg-agent # printf '%%Assuan%%\nsocket=/dev/shm/S.gpg-agent.browser\n' > $GNUPGHOME/S.gpg-agent.browser # printf '%%Assuan%%\nsocket=/dev/shm/S.gpg-agent.extra\n' > $GNUPGHOME/S.gpg-agent.extra # printf '%%Assuan%%\nsocket=/dev/shm/S.gpg-agent.ssh\n' > $GNUPGHOME/S.gpg-agent.ssh
Test that gpg-agent starts successfully with gpg-agent --daemon
.
Mitigating Poisoned PGP Certificates
In June 2019, an unknown attacker spammed several high-profile PGP certificates with tens of thousands (or hundreds of thousands) of signatures (CVE-2019-13050) and uploaded these signatures to the SKS keyservers. The existence of these poisoned certificates in a keyring causes gpg to hang with the following message:
gpg: removing stale lockfile (created by 7055)
Possible mitigation involves removing the poisoned certificate as per this blog post.
Invalid IPC response and Inappropriate ioctl for device
The default pinentry program is /usr/bin/pinentry-gtk-2
. If gtk2 is unavailable, pinentry falls back to /usr/bin/pinentry-curses
and causes signing to fail:
gpg: signing failed: Inappropriate ioctl for device gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
You need to set the GPG_TTY
environment variable for the pinentry programs /usr/bin/pinentry-tty
and /usr/bin/pinentry-curses
.
$ export GPG_TTY=$(tty)