「丸い穴に四角いくぎは入らない（不向き）」という表現はよく知られています。コードサイニングで、一時期この問題がありました。お客様から丸い穴と四角い穴の課題を解決するよう求められ、提供できたものは丸いくぎだけでした。何を意味するかと言うと、一時期 DigiCert® Secure Software Manager では標準の鍵ペア構成（秘密鍵と対応する公開鍵）しかサポートできず、丸いくぎしか提供できなかったということです。標準鍵ペアモデル（当社の丸いくぎ）は、標準コードサイニングのユースケース（丸い穴）をお持ちのお客様にぴったりです。しかし、GPG 署名のユースケースと Keyring モデル構成への GnuPG エコシステムのサポートはどうでしょう。これは当社から見ると四角い穴の課題でした。今まで選択肢がほとんどなく、この四角い穴の課題に対し丸いくぎによる標準鍵ペアソリューションを提供してきました。

くぎと穴について聞かされるのは、もううんざりですか。では、比喩で説明しましょう。GPG Keyring と標準鍵ペアに関連する署名のユースケースに焦点を当てます。当社が行ったことと、なぜそれが重要かについてです。

SSM ネイティブによる GPG Keyring と容易な鍵管理のサポート

まず、SSM （Secure Software Manager）で GPG Keyring を 直接サポートしました。GPG キーにはマスターキーと関連するサブキーが含まれる点で、GPG キーは標準鍵ペアとは異なります。そのため、GPG Keyring は、鍵が証明書の階層構造に依存するのではなく、独自の階層構造を持つことができます。マスターキーとサブキーとの間に技術的な差異はない一方で、これらの鍵の責任は別々のままにして、セキュリティが強化されます。

GPG キーの一覧

Keyring のダウンロード

サブキーの作成にはマスターキーのみを使用し、サブキーを署名に使用することをお勧めします。サブキーが危殆化した場合、影響を受けたサブキーを無効にして置換できるようになり、マスターキーと危殆化してないサブキーのセキュリティは維持されます。鍵 ID はマスターキーと関連付けられているため、マスターキーが危殆化された場合、マスターキーとすべての関連付けられたサブキーを無効にして置換する必要があります。

マスターキーと関連付けられたサブキー/ユーザー ID の詳細ページの表示

CLI が GPG キーと署名一覧を示し、SSM-SCD を用いてすべてを検証

SSM のような署名ソリューションを使用する場合、鍵の危殆化のリスクレベルは低リスクから実在しないリスクまであります。しかし、署名ソリューションが提供できるリモートで保管された鍵で署名することには、ロールや職務の分離（誰がマスターキーを管理するか、署名のためにサブキーにアクセスする権限をどのユーザーに委譲するか）のような他のメリットがあります。これは、GPG、RPM、Debian、Redhat、Docker、その他の Linux の署名タイプを用いて、現在および将来の署名ユースケース向けの GPG Keyring モデルの活用を検討している人にとって大きなメリットです。マスターキーとサブキーへのアクセスを保護、制限することは、関係するユーザーにとっての課題でした。そのため、セキュリティと自動化のバランスを取るという長年の問題を、開発者チームと情報セキュリティ組織が何度も議論してきました。

オープンソース SCD からデジサートの SSM-SCDへ。さらなる OS が可能に。

解決した次の問題は、エンドユーザーがコンパイルする必要があり、使用できるところが限られ、機能制限のあるオープンソースライブラリへの依存性をなくすことでした。今まで、SSM はオープンソースの SCD （スマートカードデーモン）を活用していました。これは GnuPG-pkcs11-scd と呼ばれ、ユーザーが SSM-PKCS11 ライブラリを用いて署名キーで保護された SSM に戻るパスを渡すために、ソースコードからコンパイルする必要がありました。GnuPG-pkcs11-scd への依存性によって、Linux OS に GPG 署名から提供できることは限られていました。また、ECDSA や EdDSA キータイプをサポートしないオープンソースライブラリであるため、RSA に対する鍵アルゴリズムにも制約がありました。

この問題を解決するために、オープンソース SCD への依存性をなくし、独自の SSM-SCD を構築することにしました。こうして、GPG 署名を安全に行いたいお客様向けに、セットアップを容易にし、機能セットを改善することができました。以下の例があります。

1. SSM-SCD はコンパイルされ準備が済んだ状態となり、お客様がコンパイルする必要がなくなり、SSM-SCD を環境に実装すればよくなりました。新しい機能を導入するか、問題を修正するためのパッチ適用が必要な場合には、置換するだけで済みます。
2. SSM-SCD は Linux、Windows、Mac に対応しています。また、最適なパフォーマンスを目指して Linux バージョンを特定の Linux OS タイプに調整する予定です。
3. SSM-SCD には RSA、ECDSA、EdDSA キータイプのサポートが付随しています。このため、お客様はユースケースに最適なアルゴリズムを選択でき、RSA のみに制限されません。
4. SSM-SCD は SSM GPG 専用の REST API に直接コード化されるため、GPG Keyring の pubring construct をサポートします。ユーザーは SCD 実装で署名を開始し、実行を許可されたユーザー向けに pubring keyring（公開鍵のみで、秘密鍵はなし）をダウンロードできます。

つまり、この新機能は、Linux の署名要件を持つ SSM ユーザーに対して GnuPG エコシステムと GPG Keyring モデルへのネイティブサポート機能を提供します。一方で、Git Commits への GPG、RPM、Debian、新規にサポートする GPG Keyring の署名サポート（ソースコードへ署名すると GitHub と他のコードリポジトリでコミットすること）、また RedHat の Podman を使って現在サポートしている OCI （Open Container Interface）標準に対して最適化した方法での Linux 署名業務に関係するすべての監査ログと署名ログのキャプチャ、セキュリティ制御、鍵保護および管理、ハッシュ署名ワークフローの恩恵を受けています。

結局、完全自動化機能を維持しつつ、今まで GPG 署名を実装してきた方法に変化はありません。また、GPG Keyring の SSM へのインポートをサポートする予定です。これにより、現在 GPG マスターキーとサブキーを保護する方法の安全性についてセキュリティ上の懸念があるお客様は、これらのフローを SSM に移行して同じ自動化署名を実施でき、処理が一層安全で堅牢性だという確証を持てます。

将来にわたる署名の課題、問題の種類に関わらず、四角い穴の問題と丸い穴の問題に必要なくぎを当社は提供できます。

SSM ツールリポジトリ：

GPG 機能について詳しくは https://www.digicert.com/content/dam/digicert/pdfs/datasheet/ssm-gpg-datasheet-en.pdf（英語） を、Secure Software Manager については https://www.digicert.com/jp/signing/secure-software-manager をご覧ください。

DigiCert® Secure Software Manager について

DigiCert ONE™ の DigiCert® Secure Software Manager は、ポータブルで柔軟な実装モデルと安全な鍵管理によって、CI/CD （継続的インテグレーション/継続的デリバリー）パイプライン全体でセキュリティを自動化することでコードサイニングを管理する最新のツールです。Secure Software Manager は、秘密署名、オンデマンドキー、ローテーションキーへの署名ごとに一意の鍵と証明書などのコードサイニングのベストプラクティスをサポートしています。Docker、Microsoft、Java、 Android などの主要なプラットフォーム、ライブラリと互換性があります。Secure Software Manager を使うと、コードを製品開発プロセスに簡単に統合できる一方、暗号操作や署名の業務および管理を制御された監査可能な方法で委譲できます。DigiCert ONE の一部として、Secure Software Manager は大量の証明書の数分以内での高速展開を実現し、オンプレミス、国別、クラウドに柔軟に展開できます。