openpubkeyについて

sada atsushi

sigstoreとopenpubkeyを比較すると後者は「証明書局とTransparencyログ（sigstoreでいうFulcioとRekor）」を排除していることが火種

sada atsushi

Sigstoreの設計は、アイデンティティ認証情報と公開鍵を新しい証明書に変換するための信頼可能かつpublicに監査可能なサービスを含んでいるのに対して

OpenPubKeyの設計はJWT OIDC tokenを証明書として使用し、そのtokenを署名キーにバインドするためにnonceフィールドを使用している。

sada atsushi

これには2つの懸念点がある。

1 生のJWTを公開することで、長期間にわたってアイデンティティを追跡する際、いくつかのプライバシー上の懸念が生じること。および名前の変更をまたいで追跡すること

2 OIDC署名キーに直接依存して検証することで、クライアントサイドの実装が複雑になったりattack surfaceをもたらしたり、クライアントサイドがOIDCプロバイダのキーローテーションの側面を処理する必要がある（これはよくわかってない）

sada atsushi

1.について

前提として、OIDCはプライベートなクレデンシャルフォーマットで、それを受信して検証することが信頼されているのは限られた当事者だけ。その結果、OIDC ID プロバイダーは、公開鍵にバインディングでunexpectedなデフォルトのclaim値をアイデンティティトークンに含めるかもしれない。これには、メールアドレス、サービスアカウント識別子、アカウントのステータス（例: 2FAの使用状況、アカウントの停止状況）、性別、生年月日などが含まれる。OpenID Connectには郵便住所のためのclaim(address claim)とかも入っている

sada atsushi

これは全ての権限をプロバーダーが所有しているのと以前はメールアドレスのみを公開していたアイデンティティクレデンシャルが、突然、生年月日や性別のclaimを公開し始める可能性もある。ユーザーが各署名操作で手動でJWTクレームを検査していない限りこれには事前通知なく突然起こる可能性もある。最後は、プロバイダー(openid connect プロバイダー)頼みになってしまう点がbad point。最悪の場合、これは深刻な問題になり得る。公開署名を行おうとするユーザーは、個人情報やアカウントの状態情報を事実上永続的に公開してしまう可能性あり。

sada atsushi

一旦、リセットしてsigstoreのkeylessを目指す仕組みを整理する

ユーザーが自分のアイデンティティプロバイダ（Google、GitHub、Microsoftなど）にログインする

ユーザーはこのプロバイダから「アイデンティティトークン」をリクエストし、それを使用してサードパーティに自分のアイデンティティを主張する

アイデンティティプロバイダはユーザーが自分であることを確認し（この方法はプロバイダによります）その後ユーザーにそのトークンを提供する

ユーザーはそのトークンをFulcioに渡す。

Fulcioはアイデンティティプロバイダ（Google、GitHub、Microsoftなど）と信頼関係を持っており、これらのプロバイダによってトークンが正しく署名されていることを確認できる。それにより、Fulcioは特定のアイデンティティプロバイダによって保証された通り、ユーザーが自分であることを知ることができる。

Fulcioはユーザーに署名されたx509コード署名証明書を返し、ユーザーはそれを使用してコードまたは他のアーティファクトに署名できる。この証明書には、オリジナルのIDトークンにバインドされたclaimが含まれているので信頼できる。

ユーザーは自分のコードまたは他のアーティファクトに署名し、その署名と一緒にこの証明書を添付する

こんな感じかな？

誰かが署名を検証したい場合

コード署名証明書が Fulcio によって正しく署名されたことを検証する。

証明書の ID と発行者が、期待する ID と発行者と一致することを確認する。

彼らは署名をアーティファクトと照合して検証する。

この時点で、Fulcio (ID プロバイダーからの ID をチェックした) によって保証されているように、証明書内の ID がアーティファクトに署名したことがわかる。

sada atsushi

次に、OpenPubKeyのflow

ユーザーは自分のアイデンティティプロバイダ（Google、Github、Microsoftなど）にログインする。

ユーザーはこのプロバイダから「アイデンティティトークン」をリクエストする。これは、第三者に自分のアイデンティティを主張するために使用できるものである

ここがsigstoreと異なるflow
このステップの一環として、ユーザーはリクエストの nonceフィールドにいくつかの情報を埋め込む。

OpenPubkey uses ID Tokens issued by OpenID Providers (OPs) to produce PK Tokens. A PK Token consist of the ID Token and the CIC (Client-Instance Claims) where the CIC contains the user's public key and associated metadata. The ID Token contains a hash of the CIC, so that the values in the CIC including the identity's public key are cryptographically bound to the ID Token signed by the OP. For workload-identity, the hash of the CIC is stored in the ID Token's aud claim following the pattern of GitHub Action's workload identity. For user-identity, the hash of the CIC is stored in the ID Token's nonce claim.

アイデンティティプロバイダは、特別な情報を含む署名済みトークン、つまり署名されたnonceを含むトークンを返す。

ユーザーはこのトークンを直接証明書として使用する。nonceフィールドにはユーザーの署名キーに関する情報が含まれており、これにより彼らのアイデンティティがそのキーにバインドされ、アーティファクトに署名できるようになる。

ユーザーはこのトークンを証明書と同様に署名と一緒に添付する。

誰かが署名を検証したい時

アイデンティティトークンがアイデンティティプロバイダ（Google、GitHubなど）によって署名されたことを検証する。

署名をアーティファクトに対して検証する。

この時点で、証明書内のアイデンティティがアイデンティティプロバイダによって保証されていることを知っている。

sada atsushi

OpenPubKeyは実際にはnonceを含む元のIDトークンと、その公開鍵を含むPKトークンを使用している

OpenPubKeyは有効期限のサポートも含んでおり、このモードのデフォルトではこれらの証明書は2週間有効
これにより、FulcioのOIDC部分が実質的に削除され、トークン自体を証明書として使用できている。

sada atsushi

Q. そもそも証明書ってなんだ？

A. その中に含まれる公開鍵が、同じ証明書に含まれるアイデンティティによって所有されていることを示す。このデータを信頼するには、それを信頼する誰かから直接その証明書を取得するか、それが信頼できる誰かによって暗号的に署名されたことを確認する必要がある。ほとんどのシステムは、証明書機関（CA）と呼ばれるものから署名された証明書で動作する。

証明書の存在めっちゃ大事。AWSとかで設定するけどめっちゃ大事や。

sada atsushi

アイデンティティと信頼できる何かによって署名された公開鍵を含むものは、証明書として使用できる。ほとんどの証明書は、x509プロトコルを使用するCAから提供されるけど、他のプロトコルも存在する。たとえば、SSHキーもSSH CAによって署名されることがある。openpubkeyのNonceを埋め込むやり方は、この事実を巧妙に利用している。OIDCプロバイダを信頼できるシステムとして動作させ、公開鍵とアイデンティティを含む何かを署名するようにだます手法

ここまでが証明書の側面からの説明

sada atsushi

OIDCプロトコル的な説明

ユーザーが何らかの方法でアイデンティティプロバイダに認証した後、標準化されたAPIを介してアイデンティティトークンをリクエストする。このアイデンティティトークンは、第三者（OIDC用語でRelying Partyと呼ばれます）に渡すことができ、自分が主張するアイデンティティを証明する。

プロトコルのセキュリティレベルの到達目標の1つは、トークンをリクエストするためのAPIがリプレイ攻撃に対して耐性を持つべき。つまり、これらのリクエストの1つを傍受した人が、新しいトークンを続けて取得し続けることはできないはず。nonceを用いた実装はこれを満たしていると思う？

リクエストにはその中にランダムな値を含める必要があり、それが署名されたトークンに含まれる。アプリケーションは、トークン内のnonceが初期のリクエストのnonceと一致することを確認し、トークンがそのリクエストに固有であることを確認できる。プロトコルでは、nonce値に実際に何が含まれるかは特に問わずであり、リクエスト全体で一意である必要があるだけでなのでこの手法が成立する。公開鍵とアイデンティティを埋め込むことができれば、それを証明書と呼ぶことができるという考えっぽい。へー

sada atsushi

懸念されていること

ただこれによる弊害でプロバイダが提供する秘密の署名キーの秘密性を、プロバイダ自身の外側に依存関係作っちゃっている。IDトークンは認証システムのbearer tokenとして扱われてる。外部でそれらを渡したらなりすましなどのリスクを引き起こす可能性あるよな〜ってこと。確かに。事例としてはこれに近いかも

sada atsushi

参考文献

sada atsushi

openpubkeyのREADMEにおけるFuther Readingに

Guillou and Quisquater, A “Paradoxical” Indentity-Based Signature Scheme Resulting from Zero-Knowledge, Crypto 1988

が追加されている。ゼロ知識証明によって上記インシデントを回避できるかもしれないっぽいけどよく分かってません。

議論としてはこちらのissueかな？

Currently, an OpenPubkey token contains the original signature from the OIDC provider. This arguably means that it isn't safe to share the OpenPubkey token, as the token could be used to impersonate the subject to a service that doesn't check the audience claim, or to trick an OpenPubkey client to issue a token for the subject.

sada atsushi

課題の洗い出し

OpenPubkeyトークンに関するセキュリティ上の懸念
・OpenPubkeyトークンには、OIDC（OpenID Connect）プロバイダーからのオリジナルの署名が含まれている
・これにはリスクがあり、トークンが以下の2つの方法で悪用される可能性がある
・'audience' claimを検証しないサービスに対して被験者をなりすますこと。
・OpenPubkeyクライアントを騙して被験者のためのトークンを発行させること。

そもそもGQ署名ってなんだ

GQ署名は、Louis C. GuillouとJean-Jacques Quisquaterによって開発されたデジタル署名アルゴリズムの一種

これはRSAなどのより広く知られているシステムと同様の目的を持つ公開鍵署名システム。

仕組み
・鍵生成：他の公開鍵暗号システムと同様に、公開鍵と秘密鍵を作成することを含む。
・署名プロセス：署名者は自分の秘密鍵を使用して、メッセージや文書に署名を行う。
・検証プロセス：公開鍵を持つ誰でも、その署名が秘密鍵の保持者によって行われ、メッセージが変更されていないことを検証できる。

OpenPubkeyトークンのオリジナルのOIDCプロバイダーの署名をGQ署名で置き換えることは、OIDC署名を直接露出することに関連するリスクを避けながらセキュリティを維持する方法になり得る。この方法は、GQ署名の暗号学的強度を活用して、トークンの完全性の保証を目指す。

GQ署名による解決策
・GQ署名の作成
・オリジナルのOIDCプロバイダーの署名を持っていることを証明するGQ署名を作成することが考えられる。
・このGQ署名は、オリジナルのOIDC署名ペイロード（ヘッダーとペイロードがドットで区切られたもの）とOIDCプロバイダーの公開鍵を使用して検証できる。

GQ署名が機能する理由
・GQ署名で使用されるプライベートキーは、RSA署名で使用されるものと同等

OpenPubkeyトークンでの実装
・OpenPubkeyトークンで直接OIDCプロバイダーの署名を使用する代わりに、GQ署名が公開されます。
・このアプローチは、オリジナルのOIDC署名を露出させないことでトークンを安全にします。

利点
・この方法は、オリジナルのOIDC署名を保護することで、OpenPubkeyトークンのセキュリティを強化につながる
・トークンのなりすましや欺瞞の潜在的な悪用を防げる