Sigstore で OSS コード署名

注意
Sigstore の Keyless Signing は開発段階で実験的に実装されているため、今後本稿で説明している内容から仕様や実装方法が変更する可能性があります。

サイバートラストは、オープンソースソフトウェアに署名と検証を行い、OSS のサプライチェーンを保護するための標準規格およびサービスである Sigstore 運用可能性の検討に取り組んでおり、本記事では検討の一次成果として、Sigstore の仕組みについての調査結果を解説します。

経緯

2021 年 7 月にサイバートラストが Open Source Security Foundation（以下、OpenSSF）に参画しました。
多くのオープンソースソフトウェア（OSS）は、コミュニティの主導で開発されており、全体の品質やメンテナンスに責任を持つ中央機関がなく、ソースコードの再利用が可能でバージョン管理や依存関係が複雑であることを背景に、セキュリティ問題の発見と情報共有や対策といったプロセスの普及に課題がありました。OpenSSF は、OSS のセキュリティを継続的に改善していくことを目的に、OSS 業界のリーダーが集結し、業界横断的に連携しているプロジェクトです。OSS の継続的なセキュリティ向上のため、オープンソースプロジェクトに存在するセキュリティ上の脅威の発見やセキュリティツールの整備、セキュリティのベストプラクティスの提案などを行っています。

2022 年 10 月には OpenSSF の「OSS セキュリティのための動員プラン」に向けた活動を開始しました。サイバートラストは、The Linux Foundation の OpenSSF が推進する OSS のセキュリティ強化に関する 3 つの目標と 10 項目の動員プランに対して、7 つの重点分野について具体的な活動をスタートしました。

下記の重点項目について、全社横断で活動している OSPO（オープンソースプログラムオフィス）チームを活用し、コミュニティ連携と事業推進の両輪を迅速に推進できるシームレスな部門横断体制を構築し、活動を開始しました。

セキュリティ教育と認定 ：OpenSSF で発行する英語コンテンツの日本語翻訳やコミュニティ、市場でのトレーニング、セミナーの実施
電子署名 ：電子認証局運営の知見共有と国内での Sigstore 運用可能性の検討
データ共有 ：ディストリビューターの知見を活かした、OSS 利用状況、CPE（Common Platform Enumeration：共通プラットフォーム一覧）のゆらぎなどの情報フィードバック、修正
SBOM の普及 ：SBOM 利用状況情報のフィードバック、自社製品、サービスとの SBOM 連携の強化、提供
サプライチェーンの改善 ：Yocto、KernelCI、CIP などの OSS ビルドシステム、CI/CD、ツールなどのコミュニティへの積極参加、フィードバックと自社製品、サービスへの迅速な取り組み

Sigstore とは何か

Sigstore は、OSS のサプライチェーン強化を目的としたコード署名のプロジェクトです。ソフトウェア開発者がリリースしたファイル、コンテナ、バイナリ、SBOM などを安全に署名できる仕組みを提供します。
ソフトウェア署名を行うことでマルウエアなどの開発元不明のソフトウェアが混入するリスクを低くすることが可能です。
しかしながら OSS への電子署名は、あまり普及していないという問題があります。その原因の１つとして、電子署名を行うための秘密鍵の管理は、開発者にとって負担であるという背景があります。また過去に開発者の秘密鍵が流出し、問題となったケースも存在します。

Sigstore は、OpenID Connect、キーレス署名、透過性ログ、自動化を行うツールなどを用いて鍵を保管、管理する手間を大幅に削減することで、OSS 開発者への負担を軽減し、デジタル署名を普及させることを目的としています。後述する仕組みにより、開発者は連携する Idp にログインするだけで署名が可能となり、秘密鍵の管理を意識せずに利用できます。

Sigstore は 100% コミュニティベースで開発、運用、管理されており、無料で利用可能です。

Sigstore の署名処理

それでは実際に、Sigstore の署名の流れを説明したいと思います。

署名処理は、利用する署名クライアントの実装によって若干異なります。以下の説明では全体のコンセプトを中心に説明するため、詳細や実際の実装と異なる場合があります。

初めに、Sigstore のソフトウェア構成群について簡単に説明します。
主な登場人物の説明は以下のとおりです。

Fulcio：OIDC(OpenID connect) による認証結果をもとに、短期間（10 分ほどの有効期間）の証明書を発行する認証局です。
Rekor：署名の透明性ログ（Transparency Log）を提供するサーバです。基本的な仕組みは、SSL/TLS 証明書発行に関する透明性ログを提供する CTLog サーバ（参考リンク）と同じですが、公開される情報は電子署名に使用した証明書、署名値、開発者を特定する情報、そのほかメタデータなどを提供します。
Cosign：署名を行うクライアント側のソフトウェアの１つです。Cosign はコンテナ署名用に作成されたクライアントであり、Sigstore プロジェクトの中でも一番活発に開発されている署名クライアントです。
Identity Provider（IdP）：OIDC は、OAuth2.0 を拡張したプロトコルで、例えば Google や Github が他のサービスにログインするときに利用している認証機能です。コミュニティによりサービスとして提供されます。OIDC による認証を行う認証サーバです。現在 Sigstore で利用可能な Idp は Google、Microsoft、Github の３つとなります。

Sigstore は、主に Fulcio、Rekor、Cosign の 3 つが中心となり連携します。
上記の登場人物をもとに構成されるキーレス署名の署名時の流れは以下の通りです。
（※一部詳細は省略しております）

キーレス署名の署名時の流れ

以下に署名の流れを説明します。

開発者が署名処理を開始する。
Cosign は、開発者に OIDC トークンを要求する。
開発者は、ブラウザなどを用いて OIDC の Idp へ認証要求を行う。
Idp は、OIDC トークンを返却する。
開発者は、OIDC トークンを Cosign へ連携する。
Cosign は、鍵ペア、証明書発行要求を作成する。
Cosign は、Fulcio に証明書発行要求を行う。
Fulcio は、証明書発行要求を検証し証明書を発行する。
※連携された OICD トークンも検証する。
発行された証明書を使用して署名処理を行う
Rekor の透明性ログ（以下 T ログ）に署名に関する情報を記録する。
※証明書、署名値、開発者の情報などを記録し Rekor は改ざんされないようにログにタイムスタンプを付与する。
Cosign は、署名値や証明書を開発者に返却する。
Cosign は、署名処理が完了すると秘密鍵を削除する。

Sigstore において、本人であることの証明は秘密鍵の保持ではなく OIDC で担保します。また発行される証明書は署名時のみ有効な証明書（有効期限が 10 分）が発行され、署名後に秘密鍵を破棄することで秘密鍵の流出に対して考慮する必要がなくなります。したがって失効情報の提供も不要となります。なお有効期限が短いことによる弊害は、後述する T ログのタイムスタンプ時刻で担保します。

キーレス署名と言われていますが、実際には証明書を発行するために鍵を使っているため、完全に鍵無しというわけではありません。発行しても鍵の管理をせず、使用後に破棄するという点が特徴です。

Sigstore の署名検証

Sigstore の署名について説明しましたが、実際どのように署名された対象を検証するのでしょうか。

例えば、公開鍵暗号の仕組みを利用した署名検証であれば、検証したい人は、まず対象のハッシュ値を求め、暗号化されたハッシュ値を公開鍵を入手して復号します。そして、その対象のハッシュ値と復号されたハッシュ値が同じであればその対象が改ざんされていないことを確認できます。

また同時に証明書の検証も必要となります。検証は、証明書の有効期限内であること、証明書が失効されていないかなどを確認し、検証時に有効であることを確認します。

（参考：「電子契約における電子署名の仕組み」）

Sigstore では、一般的な公開鍵暗号による署名値の突合などは同じ仕組みで検証を行いますが、証明書の検証の仕組みが異なります。Fulcio 発行の証明書は 10 分程で期限切れとなるため、公開鍵暗号の仕組みをそのまま利用した検証はできません。

Sigstore は署名を検証するために、公開された T ログを利用します。CTLog（Certificate Transparency log）、Rekor の T ログ（Transparency log）です。

T ログは、署名をした記録として署名値や証明書などの検証情報を提供します。T ログにはタイムスタンプが押されているため、署名した正確な時刻がログから確認できます。

上記を踏まえて、署名検証する流れは以下の通りです。（※一部詳細は省略しております。）

署名検証の流れ

利用者は、署名対象 / 署名値 / 署名者を特定できる情報を指定して Cosign を実行する。
（※署名者を特定できる情報とは、メールアドレスや OIDC の情報など）
Cosign は、署名対象のハッシュ値、署名者を特定する情報（メールアドレス /Idp など ) をもとに Rekor に T ログを要求する。
Rekor は、条件と一致する T ログを返却する。
Ｔログから証明書、署名値、署名された時刻を取得する。
署名に使用された証明書の検証を行う。改ざん検知、SCT の検証、ポリシーの検証などを行う。
署名に使用された証明書を用いて、署名値の検証を行う。
2 で取得した署名時刻が署名に使用された証明書の有効期間内であることを確認し、署名した時刻に証明書が有効であったことを検証する。

上記のとおり、Rekor を用いて時刻の検証およびその証跡を使用することで秘密鍵を管理しない署名方法においても、署名の有効性を担保しています。

※具体的な実装の確認は cosign の sign-blob を参考にしています。署名クライアントによって実装方法や項目は異なる可能性がございます。一部省略、誤記などがある可能性がございます。

一般的な認証局との違い

Sigstore の検証について記載してきましたが、既存の認証局を用いた署名方式と署名検証との違いを考えていきます。以下の表に大きく異なる点をまとめてみました。

	Sigstore	一般的な認証局による署名
証明書の有効期限	短い（10 分間）	認証局の運用による（大体は数年単位）
秘密鍵の管理方法	署名後に即時破棄するため鍵の管理が不要	鍵の管理が必要
失効情報	鍵の管理がないため提供しなくてよい	失効情報を公開、検証する必要がある。
有効期限後の署名の検証	透過ログが公開されている期間は可	不可（※一部長期署名を除く）
信頼済みストア	公開された TUF により管理	各認証する機器にて管理
発行時の審査	OpenID Connect を用いた認証	認証局の規定による

上記のとおり、Sigstore では中心のコンセプトとなる「秘密鍵の管理を少なくする」という仕組みを実現するために、既存の認証局と提供する機能や検証方法に大きく違いがあります。そのため先にも述べたとおり、署名する処理もそうですが特に検証部分は独自の仕組みになります。

また現状の実装では検証方法がクライアントの実装に依存するため、今後コミュニティとしても検証項目の規格化などや、利用者が正しく検証できるための仕組み、連携方法を確立していく必要があると感じました。

OSS 開発者にとって秘密鍵を管理することは負担が大きいため、小規模なプロジェクトや個人でメンテナンスしている場合、ソフトウェア署名自体の普及を妨げている原因でした。Sigstore は、認証局×OSS に取り組む弊社としても今後 Sigstore に貢献し、普及させることで、OSS のサプライチェーンにおける電子署名を一般的にし、信頼できるサプライチェーンを形成する助けとなるよう、コミュニティへの貢献をしていければと思います。