耐量子OpenID Connect

著者: Phil Schmieder(University of Wuppertal)、Ethan Heilman(Cloudflare)

編集・査読・協力いただいた方々に感謝します: Ralph Bragg、Serj Hallam、Gail Hodges、Frederik Krogsdal Jacobsen、Michael Jones、Nat Sakimura、Bas Westerbaan。

インターネット全体が耐量子暗号への移行を進める中、OpenID Connectの導入環境が耐量子アルゴリズムへの移行に際して直面しうる潜在的な問題と、この移行を円滑に進めるためのベストプラクティスについて検討したいと考えました。

大まかに言えば、OpenID Connectを耐量子セキュアにすることは簡単に思えるかもしれません。ML-DSAやSLH-DSAのような耐量子署名方式は、RS256のような従来型(すなわち耐量子セキュアではない)署名方式をそのまま置き換えられるからです。単純にRS256というアルゴリズムをML-DSAに置き換えればよいのでは、と思うかもしれません。OpenID Connect向けにML-DSA署名を可能にするIETF標準はすでに策定済みです。しかし、多くの場合、それほど単純にはいきません。以下では、こうした課題と、それを緩和するためのベストプラクティスについて検討します。

1. 耐量子署名アルゴリズムは、署名と公開鍵のサイズが従来の10倍から100倍に増大します。これにより、増大したサイズを扱えないソフトウェアやプロトコルが破壊される可能性があります。
2. 新しいアルゴリズムの導入により、OpenID Connect実装に潜在していた既存のバグが表面化する可能性があります。
3. ほとんどのOpenID Connectソフトウェア実装は、耐量子アルゴリズムに対応していません。
4. 一部のOpenID Connect RPは、クライアントソフトウェアをすべて一度に耐量子アルゴリズムへアップグレードできない場合があり、IDトークンの要求時にどのアルゴリズムで署名するかを選択する仕組みが必要になることがあります。

以下では、これらの課題を一つずつ取り上げ、エコシステムの現状と、これらのリスクを是正するために取りうる対策について見ていきます。

サイズの問題:鍵と署名の肥大化

こうした問題の一因は、新しい耐量子セキュアな方式における暗号公開鍵と署名のサイズが、RS256やES256と比較して大きいことにあります。今日最も広く使われているアルゴリズムであるRS256(2048ビット)は、公開鍵が256バイト、署名も256バイトです。これに対し、代表的な耐量子署名アルゴリズムの一つであるML-DSA-44は、公開鍵が1,312バイト、署名が2,420バイトあります。それでもML-DSA-44は耐量子署名方式の中では比較的小さい部類に入ります。SLH-DSA-*-128sに至っては、署名が7,856バイトにもなります。さらに、公開鍵と署名はBase64urlエンコードされるため、サイズはさらに増大します。当然ながら、このようなサイズの増大は、IDトークンなどのデータ構造を現在よりもはるかに大きくし、特定の箇所で厳格なサイズ制限を超えてしまう原因となり得ます。

その一例が、Cookieサイズの上限とされる約4kBという値です。この約4kBという数値は、あくまでIETFの規定上ブラウザが対応すべき最小値であるにすぎませんが(RFC 6265)、実際には多くのシステムがこれを厳格な上限として扱っています。そのため、この閾値を超えると機能が損なわれるリスクがあります。Cookieがこのサイズを超えると、通知なく破棄されることがあります。そのCookieに格納されたトークンに依存するアプリケーションは、トークンをまったく受け取れず、それによって得られるはずの重要な真正性を失うことになります。

私たちは、依存しているブラウザやその他のソフトウェアについて、こうしたサイズ増大によって引き起こされうる問題がないか監査を始め、増大したサイズに対応できるよう更新していく必要があります。

今、表面化する潜在的バグ

あらゆる技術変更と同様に、一見無関係に見えるバグが予期せず発生することがあります。これは例えば、新技術における見落としや、これまで一度も発現しなかった旧技術のバグ、あるいはプロトコルの硬直化(オシフィケーション)などに起因します。

OpenID Connectでは、プロトコルの硬直化に起因するバグがすでに表面化しています。RaidiamのRalph Bragg氏は、JWTライブラリに共通するバグを報告しました。これは、新しい鍵タイプ`AKP`(RFC 9964)を持つJWKを含むJWKSを解析する際に発生するものです。このバグは、ライブラリがJWKSを解析中に、解析方法を知らないJWKに遭遇した際に生じます。本来であれば、ライブラリは解析できないJWKを無視し、理解できる残りのJWKの解析・利用を継続すべきです。しかし実際にはエラーをスローし、JWKS全体の解析が失敗してしまいます。

これは、OPがそのタイプの鍵をJWKSに公開している場合に大きな問題となります。JWKSに必須のRS256公開鍵が含まれていても、OPがML-DSA公開鍵に用いられる`AKP`タイプの公開鍵を追加で公開していると、影響を受けるライブラリはJWKS全体の解析に失敗します。このバグは、`AKP`タイプの公開鍵が取得できなくなるだけでなく、`AKP`タイプの公開鍵が存在するJWKS内の他のすべての公開鍵にも影響を及ぼします。

耐量子セキュアなアルゴリズムを展開する前に、こうしたバグを特定し修正しておくことが重要です。したがって、将来の耐量子移行が遅れることのないよう、こうした障害やバグは今のうちに修正しておくべきです。

新しいアルゴリズムへの対応状況

耐量子セキュアなトークンがRPに発行される前に、RPおよびその背後でトークンを検証するサービスは、トークン検証時にその署名を検証できるようになっている必要があります。しかし現時点では、トークン検証に使われる多くのJWTライブラリは、まだ耐量子署名に対応していません。

以下の表は、Octoverse 2025でGitHubが報告した人気プログラミング言語上位5言語、およびGoとRustについて、JWTライブラリとML-DSAで保護されたJWTへの対応状況の現状を示したものです。

円滑な耐量子移行のための暗号アジリティ

これに関連するもう一つの懸念は、耐量子OpenID Connectの一般的な実現可能性そのものではなく、耐量子暗号への移行プロセスに関するものです。これは主に、RPが複数の署名方式を同時にサポートする必要性から生じます。例えば、あるRPがIDトークンを利用する2つの異なるサービス、すなわちレガシーサービスとより新しいサービスを持っているとします。保守担当者は新しいサービスを耐量子署名に対応させることは迅速に行えるかもしれませんが、レガシーサービスの対応にはより多くの時間とテストが必要になるかもしれません。このような場合、RPがML-DSA-44と、RS256のような従来型アルゴリズムを同時にサポートできれば、保守担当者はまず新しいサービスを移行し、発生した問題を修正した上で、レガシーサービスを後から更新することができます。このようなシナリオでは、RPはML-DSA-44とRS256のどちらで署名されたトークンを受け取るかを決定できる必要があります。当然ながら、Q-Day以降はML-DSA-44が望ましい選択となりますが、互換性の観点から、RPが十分に高速なローテーションを伴うRS256を使用する場合もあり得ます。

OPが対応していれば、RPはid_token_signed_response_alg登録パラメータを通じて、自身に発行されるトークンの署名に使用すべきアルゴリズムを指定できます。しかし、これは単一のアルゴリズムしか指定できないため、RPのアルゴリズム選択はオール・オア・ナッシングになってしまいます。さらに、このパラメータは登録時に設定されるものであり、その場で変更することはできません。より緩やかな移行を望むRPには、複数のアルゴリズムを指定し、リクエストごとにトークンの署名に使用するアルゴリズムを選択できる仕組みが必要になります。これを実現するには、追加の標準化作業が必要になるでしょう。

結論

耐量子OpenID Connectへの移行には、ライブラリ、RP、そしておそらくOpenID Connect標準そのものにまたがる協調的な取り組みが必要です。ライブラリは耐量子署名への対応を実装し、耐量子署名アルゴリズムの採用によって表面化するバグを修正しなければなりません。ベンダーおよびRPは、これらのライブラリの最新版へ更新し、システムをテストする必要があります。私たちは、移行に伴うリスクと複雑さを軽減するために、OpenID Connectに追加のアルゴリズムアジリティの仕組みを導入することも検討すべきです。