| 項目 | 推奨設定・結論 | 理由・備考 |
|---|---|---|
| アルゴリズム | Ed25519 (署名) / Cv25519 (暗号化) | 軽量・高速かつ十分な安全性。RSA 4096bitは処理負荷と鍵長サイズの観点から非推奨へ移行 |
| マスターキー運用 | Certify (証明) のみ /
オフライン隔離 |
日常運用での盗難リスク排除。ローカル表示は sec#
となる状態を構築 |
| サブキー構成 | Sign (署名), Encrypt (暗号化),
Authenticate (認証) |
用途別にサブキーを分離。個別の失効・更新を可能にする |
| 有効期限 | 1〜2年(定期的に延期運用) | 鍵紛失時の有効期限切れによる自動無効化を担保。マスターキーからいつでも延長可能 |
| 信用設定 | 移行先で Ownertrust = 5 (ultimate) を再設定 |
秘密鍵インポートのみでは自身の鍵としてフル信用されないため必須 |
1. 推奨アルゴリズムと期限設定
- ECC (Ed25519 / Cv25519): 現代のデファクトスタンダード。256bitの鍵長でRSA 3072bit〜4096bitと同等以上の安全性を提供し、署名・検証・鍵交換の処理速度が極めて高速。
- RSA (4096bit): レガシーシステムや古くからのSmartCard等の互換性が必須な場合を除き、新規作成は非推奨。
- 有効期限方針: マスターキー・サブキーともに1〜2年程度に設定し、期限が切れる前に更新(延期)を行う。万が一マスターキーの秘密鍵および失効証明書を紛失した場合でも、時間の経過により自動的に失効と同等の状態(期限切れ)に移行させる防犯設計。
2. エキスパートモードによる鍵作成(マスターキー隔離設計)
マスターキーには証明権限(C:
Certify)のみを与え、署名(S)・暗号化(E)・認証(A)の各機能は個別のサブキーに割り当てます。
# エキスパートモードで鍵生成を開始
gpg --expert --full-generate-key対話型プロンプトの選択手順
- アルゴリズム選択:
(11) ECC (set your own capabilities)を選択 - 機能の調整: 既定の
[Sign, Certify]からsを入力してSignを外し、Current allowed actions: Certifyの状態にする ->qで確定 - カーブ選択:
(1) Curve 25519を選択 - 有効期限:
2y(2年)等を指定 - ユーザー情報: 本名・メールアドレスを入力し確定
作成後、キーID($KEYID)を確認し、サブキー(S,
E, A)を追加します。
# 鍵一覧で KEYID(40桁のフィンガープリントまたは下位8/16桁)を確認
gpg --list-secret-keys --keyid-format LONG
# 鍵の編集モードに入る
gpg --expert --edit-key $KEYIDgpg内でのサブキー追加操作
gpg> addkey
# (11) ECC (set your own capabilities) を選択 -> 's' のみ有効化して 'q' -> Curve 25519 -> 署名用サブキー(S)作成
gpg> addkey
# (12) ECC (encrypt only) を選択 -> Curve 25519 -> 暗号化用サブキー(E)作成
gpg> addkey
# (11) ECC (set your own capabilities) を選択 -> 'a' のみ有効化して 'q' -> Curve 25519 -> 認証用サブキー(A/SSH用)作成
gpg> save
3.
マスターキーのオフライン隔離(sec# の構築)
日常的に使用する端末には「サブキーの秘密鍵のみ」を残し、マスターキーの秘密鍵はオフラインストレージ(USBメモリ等)へ退避させます。
# 1. 念のため全秘密鍵(マスター+サブ)の完全バックアップを作成
gpg --export-secret-keys --armor $KEYID > master-backup.asc
gpg --export-secret-subkeys --armor $KEYID > subkeys-only.asc
# 2. 非常時用の失効証明書を事前に生成(安全なオフライン環境に保存)
gpg --output revoke-$KEYID.asc --gen-revoke $KEYID
# 3. ローカルの keyring から一度すべての秘密鍵を削除
gpg --delete-secret-keys $KEYID
# 4. サブキーの秘密鍵のみを再インポート
gpg --import subkeys-only.asc
# 5. ステータス確認
gpg --list-secret-keys --keyid-format SHORTフラグ確認ポイント
表示結果の1行目が sec# と表示されていれば成功です。 *
sec: マスターキーの秘密鍵がローカルに存在している状態 *
sec#:
マスターキーの秘密鍵が存在せず、ダミー(または非活性)化されている状態(安全)
* ssb: サブキー(Secret
Subkey)の秘密鍵が存在している状態
4. 鍵のエクスポートと移行先でのOwnertrust設定
エクスポートコマンド
# 公開鍵一括エクスポート
gpg --export --armor $KEYID > publickey.asc
# 全秘密鍵(マスター含む)のエクスポート
gpg --export-secret-keys --armor $KEYID > secret-all.asc
# 特定のサブキーのみのエクスポート(キーIDの末尾に ! を付与)
# 例: 署名用サブキー $SUBKEY_ID のみを取り出す場合
gpg --export-secret-subkeys --armor $SUBKEY_ID! > secret-subkey-single.asc重要(
!記号の意味): キーIDの末尾に!を付けないと、GPGは指定したキーIDに紐づく鍵グループ全体(マスターキーおよびすべてのサブキー)を対象として処理します。特定のサブキー単体のみを厳密に指定・操作する場合は!の付与が必須です。
移行先端末での復元と信用度(Ownertrust)設定
秘密鍵をインポートしただけでは、GPGはその鍵を「自分自身の本物の鍵」として完全に信用しません(trust: unknown)。Ownertrustを直感的な対話または非対話で
ultimate (5) に再設定する必要があります。
# 秘密鍵・公開鍵のインポート
gpg --import publickey.asc
gpg --import subkeys-only.asc
# 非対話コマンドによる Ownertrust (ultimate = 5) の設定
echo "$KEYID:6:" | gpg --import-ownertrust
# (参考)対話型で設定する場合
# gpg --edit-key $KEYID -> 'trust' -> '5' (ultimate) -> 'y' -> 'save'5. 鍵の運用・メンテナンス(延長および失効)
期限切れ(Expired)鍵の延長手順
鍵の有効期限が切れても、暗号強度が低下したわけではありません。マスターキーの秘密鍵が存在する環境(オフライン環境)で期限を延長すれば、再び正常に利用可能です。
# マスターキーが存在する環境で実行
gpg --edit-key $KEYID
gpg> expire
# 変更する鍵を選択(何も選択しない場合はマスターキーの期限を変更)
# 期間を指定 (例: 2y)
gpg> key 1
# 1番目のサブキーを選択(* 印がつく)
gpg> expire
# 期間を指定 (例: 2y)
gpg> save
# 延長した公開鍵を再エクスポート・配付/サーバーに再送付サブキーの失効(Revoke)手順
端末の盗難やサブキーの秘密鍵漏洩時には、マスターキーを使って該当サブキーのみを失効させます。
gpg --edit-key $KEYID
# 対象のサブキーを選択(例: key 2)
gpg> key 2
# サブキー失効コマンド
gpg> revkey
# 失効理由の選択(1 = Key has been compromised 等)およびコメント入力
gpg> save
# 失効情報が含まれた公開鍵を鍵サーバーへ送信
gpg --keyserver keys.openpgp.org --send-keys $KEYID6. 失効鍵の不可逆性とローカル削除手順
- 再有効化不可の論理的理由: OpenPGPの基本アルゴリズム構造上、失効(Revocation)ステートメントはマスターキーの暗号署名によって作成される「不可逆な追加レコード」です。一度作成・頒布された失効署名を「取り消す」仕様はプロトコル上に存在せず、暗号学的に無効化を撤回することはできません。失効させた鍵を再利用することは不可能なため、新規にサブキーを作成する必要があります。
ローカルからの鍵削除(正しい削除順序)
GPGのデータ構造依存関係により、「秘密鍵」を先に削除してから「公開鍵」を削除する順序を厳守する必要があります(公開鍵を先に削除しようとするとエラーになります)。
# 1. 秘密鍵の削除(マスターおよびサブキーの秘密鍵が消去されます)
gpg --delete-secret-keys $KEYID
# 2. 公開鍵の削除
gpg --delete-keys $KEYID7. 公開鍵サーバー運用と同一メールアドレスでの複数鍵運用仕様
鍵サーバー(keys.openpgp.org
等)への登録と検索
現代の keys.openpgp.org
はプライバシー保護およびスパム防止のため、メールアドレスの検証(Verifiable
Identity)プロセスを採用しています。
# 鍵サーバーへのアップロード
gpg --keyserver keys.openpgp.org --send-keys $KEYID
# 鍵サーバーからの検索・インポート
gpg --keyserver keys.openpgp.org --search-keys user@example.com
# またはフィンガープリント指定による直接取得
gpg --keyserver keys.openpgp.org --recv-keys $KEYID- 注意点:
アップロード直後は「フィンガープリント」でのみ検索可能です。メールアドレスによる検索を有効にするには、
keys.openpgp.orgから送信される検証メールのURLをクリックしてアイデンティティ確認を完了させる必要があります。
同一メールアドレスでの複数鍵運用仕様
OpenPGPの仕様上、同一のメールアドレス(User ID)を持つ複数のOpenPGP鍵(異なるプライマリKEYID)を作成・配付することは完全に許容されています。
- 暗号化時の挙動: 送信者が
gpg -e -r user@example.comで暗号化を試みた際、ローカルのKeyringに同一アドレスの有効な公開鍵が複数存在する場合、GPGは警告を発するか、利用可能なすべての公開鍵に対してマルチ受取人暗号化を行います(または送信者が明示的にフィンガープリントで1つに絞り込む必要があります)。 - 移行時のベストプラクティス: 新鍵への完全移行時は、旧鍵のユーザーIDに「[DEPRECATED]」等の注記を追記して鍵サーバーに更新送付するか、旧鍵自体に「Superseded(新鍵への移行)」を理由とした失効宣言(Revocation Certificate)を発行・配布して、混乱を防止してください。
変更履歴
- 2026/08/23
- 新規作成
0 件のコメント:
コメントを投稿