IETFアップデート – 第118回IETF [第3弾] ハイブリッド公開鍵暗号スキーム HPKE とその応用技術の動向

「IETFアップデート – 第118回IETF [第1弾] 全体概要、BOF、tigress WG」「IETFアップデート – 第118回IETF [第2弾] TLS WG、SML WG、HotRFC」に続いて、第３弾としてハイブリッド公開鍵暗号スキームであるHPKE (Hybrid Public Key Encryption)と、その応用技術の動向をご紹介します。今回のレポートは、安次富大介氏（合同会社bibital）にご執筆いただきました。

チェコ・プラハで開催された第118回IETFミーティング(IETF 118)にて、私が策定に関わっている仕様の議論に参加し、関連する技術動向を現地で調査してきました。少々ニッチな内容ですが、私の活動領域に絞って、IETF 118の動向を紹介させていただきます。具体的には、HPKE (Hybrid Public Key Encryption)というハイブリッド公開鍵暗号スキームの応用領域に関する話題が中心になります。現在、IETFのセキュリティエリアでは、このHPKEを応用したEnd-to-End暗号技術・プライバシー保護技術がいろいろと議論されており、その全体像と概要、最新動向をざっくり伝えられればと考えています。本編に入る前にあらかじめ断っておきますと、動向紹介までの前置きが長くなってしまいました。なぜ私が IETF の標準化の議論に関わっているのか、どのような技術領域でどのような議論をしているのか、雰囲気だけでも掴んでいただこうと経緯も含めて書いてしまったからです。そこは論文でも調査報告書でもないブログ記事ということでご容赦ください。

■ 標準化活動への関与に至る経緯

まずは経緯から。私は所属会社でコードを書かなくなった3年ほど前から、趣味でオープンソース(OSS)活動を始めました。JWT (RFC7519: JSON Web Token)というアクセストークンをご存じの方も多いと思いますが、このJWTのデータ表現形式である のメジャーなOSSへの貢献から入りました。所属会社で使っていたのがきっかけです。そのうち自分でスクラッチから作りたくなり、題材にしたのが COSE (CBOR Object Signing and Encryption)でした。JOSEのバイナリ版とでも言うべきもので、トークンのデータサイズを極力小さくしたいユースケースのためにIETFで策定された仕様(RFC9052など) でした。例えば、COVID-19のワクチン接種証明書の欧州規格(EUDCC)が、QRコードにデータを詰め込むためにCOSEを採用しています。このCOSEを実装する中で、RFCへの疑問点をCOSE WGのメーリングリストに投稿したのが標準化活動への関与の始まりでした。その後も、標準準拠の暗号ライブラリをいくつか作ったのですが、その中で、COSEの公開鍵暗号方式を使った機能への不満から興味を持って実装したのが HPKE (RFC9180: Hybrid Public Key Encryption)です。同時期、COSE WGで“Use of HPKE with COSE (COSE-HPKE)”という仕様が提案されたので、どちらの実装も知っている立場で本格的に議論に参加するようになったのでした。

■ COSE、HPKE、そして COSE-HPKE

経緯で触れた主要な技術仕様について、もう少し詳しく解説します。

まずは COSE (CBOR Object Signing and Encryption)から。

あるデータに電子署名を付けて送付するケースを想定してみてください。署名者(送信者)から検証者(受信者)に渡す情報として、データ本体と署名データの他にどんな情報が必要でしょうか。署名検証に使う送信者の公開鍵は信頼できる別ルートから取得するのが普通ですが、公開鍵の識別子はあったほうがいいでしょう。電子署名のアルゴリズム、署名対象データのフォーマット情報もあった方が相互運用性が高まります。さらに、これらの付随データも一部は改ざんされないよう署名で保護する必要があるでしょう。署名ではなく暗号データを送付するケースも同様です。公開鍵暗号方式で共通鍵を導出する際には、鍵合意・鍵導出のアルゴリズム情報、鍵合意に使う送信者の公開鍵も必要になります。データ自体の暗号鍵は別に設けて、公開鍵暗号を使って導出した共通鍵で、このデータ自体の暗号鍵を暗号化してあわせて送るようにできると便利です。このように、署名データや暗号データを、それぞれ検証・復号するために必要な種々の付随データとあわせて運ぶためのデータコンテナの仕様がJOSEであり、COSEなのです。前者はテキストベースのJSONを、後者はバイナリベースのCBORを使います。COSEは、リソースに制約のあるデバイスやユースケースを前提とした主にIoTをターゲットとしたIETFのさまざまなWG (SUIT、TEEP、RATS、SCITT、LAKE など)で、ベースとなるデータコンテナ仕様として採用されています。

続いて、HPKE (Hybrid Public Key Encryption) について。

ハイブリッド公開鍵暗号とは、公開鍵暗号方式を使って共通鍵を導出し、これを使って共通鍵暗号方式でデータを暗号化するスキームのことです。公開鍵暗号方式と共通鍵暗号方式の合わせ技なので「ハイブリッド」というわけです。HPKEは、このハイブリッド公開鍵暗号を独立した以下の3ステップの組み合わせとして整理し、それぞれのステップで用いるアルゴリズムを厳選し、柔軟に組み合わせて使えるスキームとして再構成したものです。

KEM (Key Encapsulation Mechanism)：

暗号データの送信者と受信者がそれぞれ作成した鍵ペアの公開鍵を交換し、自身の秘密鍵と相手の公開鍵から共通の鍵素材(shared secret)を作成するステップ。

KDF (Key Derivation Function)：

shared secretから共通鍵暗号方式の共通鍵を導出するステップ。

AEAD (Authenticated Encryption with Associated Data)：

導出した共通鍵で暗号化し、復号するステップ。

HPKEのポイントの一つは、通信プロトコルやデータ形式から独立したファンクションとして定義されている点にあります。これにより、さまざまなレイヤの通信プロトコルやデータ形式と容易に組み合わせて使うことができます。このため、RFC化(2022年2月)される前から、ECH (TLS Encrypted Client Hello)、MLS (Messaging Layer Security)、ODoH (Oblivious DNS over HTTPS)など、IETFのセキュリティ領域のさまざまな仕様で採用されていました。本記事の後半では、IETFで取り組まれているこれらのHPKE応用技術の全体像と最新動向について概説します。

最後に、HPKE応用の一つ COSE-HPKE (Use of HPKE with COSE) について。

COSE-HPKEは、COSE上でHPKEを使うための仕様です。IoT機器向けファームウェアの暗号鍵配送に用いるユースケース(SUIT WG)を想定して、COSE WGに提案されました。もともとCOSEにもハイブリッド公開鍵暗号を行う仕組みは備わっているのですが、私は以前から改善の必要性を感じていました。主な理由は、鍵合意・鍵導出アルゴリズムのバリエーションの少なさ、送信者の公開鍵配送用データ形式の不必要な煩雑さ、鍵導出にアプリケーションコンテキストをバインドするやり方の不必要な煩雑さ、の3点です。(紙幅の都合上、説明は省きますが) HPKEは、実はこれらの問題点をすべて解消してくれるソリューションになっており、レガシーなCOSEの暗号関連機能(JOSEで言えばJWE)は、おおむねCOSE-HPKEで置き換えられると個人的には期待を寄せています。

些末な話を除くと、COSE-HPKEのレイヤで仕様として決めるべきことは、送信者から受信者に暗号データと共に渡す付随データ(カプセル化された送信者の公開鍵と、選択したKEM・KDF・AEADの組み合わせ)をどのように渡すかだけなのですが、私も参戦し、延々と1年以上もメーリングリスト上で議論が続きました。

■ COSE-HPKEへの貢献

なぜ延々と議論が続いたのか？ 主な争点は二つでした。一つは、カプセル化された送信者の公開鍵(encapsulated key)の表現方法。もう一つは、KEM・KDF・AEADの組み合わせをCOSE上でどう扱うか(後述する暗号スイート方式 vs アラカルト方式)。

前者について、初期のドラフトでは、encapsulated keyをCOSE Key (JOSEで言えばJWK)という構造化データとして表現する仕様になっていたのですが、HPKEの仕様上、これはシンプルなバイト列で表現すべきものでした。私(と、もう1人)がメーリングリスト上で問題提起し、長い議論を経てバイト列に修正されました。

後者がさらに大変でした。まず前提として、COSEには、利用するアルゴリズムIDを入れるalgというヘッダがあり、このアルゴリズムIDは IANAレジストリに登録された数値で表現されます。例えば、ECDHとHKDFを使う鍵合意・鍵導出アルゴリズムには、-25 (ECDH-ES+HKDF-256)が割り当てられています。一方のHPKEのKEM・KDF・AEADにも同様に、それぞれ IANAレジストリに登録された数値のアルゴリズムIDが割り当てられています。例えば、P-256曲線のECDHを使うKEMは、0x0010 (DHKEM-P256)、SHA256ベースのKDFは、0x0001(HKDF-SHA256)、鍵長128bitのAES-GCMは、0x0001 (AES-128-GCM)というように。

ここで二つの方式が提案されました。一つ目は、COSEのalg値にKEM・KDF・AEADの組み合わせを入れてしまう方式(暗号スイート方式)です。例えば、上記例の組み合わせ(HPKE-Base-P256-SHA256-AES128GCM)に対してアルゴリズムIDを割り当てる、といった感じです。二つ目の方式は、COSEのalg値には、HPKEであることを表すだけの値を定義・指定しつつ、HPKEのKEM・KDF・AEADのアルゴリズムID値をそのまま使い、encapsulated keyも含める、つまり、HPKEに必要な情報をそのまま含める新たなヘッダを定義する方式(アラカルト方式)です。私はアラカルト方式推し、というか提案者の1人でした。理由はいろいろあるのですが、アラカルト方式の場合、例えば耐量子KEMがHPKEのレジストリに新規登録された際に、新たにCOSE-HPKEの拡張仕様を作る必要も、実装を変える必要もないからです。またCOSEの実装者として、alg値に厳密な暗号スイート定義を入れることへの抵抗もありました。実際、algヘッダには、今回の暗号スイート方式ほどの厳密な定義値を入れた例はあまりなかったのです。私にとっては、アラカルト方式の優位は明白だったのですが、メーリングリスト上での長い議論と投票の結果、暗号スイート方式に決まりました。

この議論の間にも、私はいち早くCOSE-HPKEを実装して仕様へのサンプルデータの提供を行ったり、細かい修正提案を行ったりと地道に貢献していたこともあり、後者の議論には負けたものの、共著者の1人に迎え入れられました。この辺り、やはりIETFは、良いカルチャーだなと思いました。

ここまでが、IETF 118開催前の話です。前置きが長すぎました。

■ IETF 118での活動

ということで、IETF 118は、Internet-Draftの共著者の1人として参加した初めてのIETFになりました。IETFの期間は土曜日に始まり翌週の金曜日に終わるのですが、初日の土曜日朝から翌日曜日の夕方までハッカソンが開催されます。私もHPKEの拡張仕様を実装しようと1人ハッカソンを決め込んで参加していたのですが、 共著者につかまり、COSE WG会合での発表資料作成と、そのための議論を行いました。

議論の主なテーマは、暗号スイートの選定でした。上述の通り暗号スイート方式に決定したわけですが、HPKEのKEM・KDF・AEADはそれぞれ提案中のものもすべて含めると各々10種類、3種類、6種類。組み合わせは180通りになります。この中からリーズナブルな暗号スイートを選択しなければなりません(これも私が暗号スイート方式にネガティブだった理由の一つだったのですが……)。ちなみに、他のHPKE応用仕様の中で、COSEと同じく暗号スイート方式を採用しているのがMLSなのですが(ECH、ODoH、OHTTP 等、他はすべてアラカルト方式)、先行するMLSは7種類の暗号スイートを選定していました。これを軸に、いくつかの選択肢を提示する方向で資料をまとめました(発表資料)。発表も「ダイスケがやって」と押し付けられ、アラカルト方式推しだった私が、なぜか暗号スイートの選択肢を挙げて意見を募るプレゼンをするという、何とも因果な顛末となりました。共著者になった洗礼ということでしょうか。

さておき、IETF 118のCOSE WG会合での気になる発表として、“Hybrid Key Exchange in JOSE and COSE”がありました。Nokia からの提案なのですが、この「ハイブリッド」は、HPKEのハイブリッドとは異なる”PQ/T Hybrid”、つまり耐量子暗号方式と既存暗号方式の組み合わせという意味でのハイブリッドです。内容はKEMにフォーカスしていて、PQ/T Hybrid KEM (具体的には、NISTが選定したKyberとX25519を組み合わせるKEM)をCOSEのアルゴリズムに加え、同時に両方式の鍵を同時利用するための鍵表現の提案も含むものになっています。COSE-HPKEは、KEM・KDF・AEADの組み合わせにアルゴリズムIDを付与する(一気通貫のものとしてとらえる)選択をしたわけですが、私には、このCOSE-HPKEの方針と大きな乖離のある提案に見えています。COSE-HPKEの共著者とは、この提案の鍵表現に欠陥があるという話や、私がIETF 116で提案したHPKE KEMの汎用的な鍵表現がベターな解決策になるという話をしました。近々、カウンター提案を行うかもしれません。

以上ここまでが、HPKEの応用の一つ、COSE-HPKEにフォーカスした私の活動報告でした。COSEという比較的ニッチな技術領域のお話でしたが、扱っている内容は、暗号スイート方式 vs アラカルト方式(これは、ここ数年たまに話題に上がる Cryptographic Agility批判に通底する議論)だったり、暗号スイートの選択の話だったり、PQ/Tハイブリッドの適用・運用の話だったりと、テーマ自体は意外とニッチではない汎用的かつ普遍的なものだったことが伝われば幸いです。

■ IETFにおける HPKE応用技術の動向

前述したように、HPKEは通信プロトコルやデータフォーマットから切り離された独立したファンクションとして定義されており、使い回しが良く、IETFセキュリティエリアの各所で議論されているEnd-to-End暗号技術・プライバシー保護技術のベースとして活用されています。

現在、HPKEの応用が議論されているWGは以下の通りです。

• CFRG
• COSE WG
• JOSE WG
• MLS WG
• OHAI WG
• PPM WG

以下、各WGの概要、動向について概観していきます。

〇CFRG (Crypto Forum Research Group)

CFRGは、IETFではなく長期的な研究寄りの活動を担う IRTF (Internet Research Task Force)に属する研究グループです。プリミティブな暗号アルゴリズム等の要素技術の研究開発を行っており、HPKEもここでRFC化されました。現在、HPKEの拡張仕様として、以下の三つが提案されています。

Deterministic Nonce-less Hybrid Public Key Encryption：

EC鍵のコンパクト表現に対応したECDHベースのKEMと、nonceの再利用への耐性があるAES-GCM-SIVをそれぞれ、HPKEのKEMとAEADのラインナップに加える提案。

secp256k1-based DHKEM for HPKE：

secp256k1曲線を使ったECDHベースのKEMをHPKEのラインナップに加える提案。

X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE：

前述したハイブリッド耐量子KEMをHPKEのラインナップに加える提案。

今回のIETF 118では、いずれも議論されませんでした。ちなみに、secp256k1曲線を使ったDHKEMについては、私は仕様が提案される前に試験的に実装していました。提案も検討していたのですが、先を越されました。著者には実装者としてフィードバックを行っています。

〇COSE (CBOR Object Signing and Encryption) WG

前述の通り、Use of HPKE with COSE (COSE-HPKE)が議論されています。今回のIETF 118で取り上げた暗号スイートは、MLSが選定したものを踏襲する方向か、あるいは、これに選択肢の対称性を考慮してAEADにChaChaPolyを用いる暗号スイートをいくつか追加する方向のいずれかでまとまる見込みです。大きめの課題が数件残っているのですが、個人的には次バージョンのドラフトでWGLCに進めるのではないかと考えています。

〇JOSE (JSON Object Signing and Encryption) WG

JOSEは、Webセキュリティではお馴染みのJWT (JSON Web Token)を含む、JSONベースのセキュリティデータコンテナ仕様を扱うWGです。JWT、JWA、JWS、JWE、JWKという一連のJSONベースの仕様を策定し、活動をクローズしていましたが、横浜で開催された IETF 116から、新たにJWP (JSON Web Proof)を定義する目的で再開されました。前回(IETF 117)から、JWP以外のテーマも扱うようになり、今回のIETFでは、Use of HPKE with JOSE (JOSE-HPKE)が提案されました。JOSEとCOSEは特に暗号まわりの仕様が微妙に異なるため、COSEをJOSEで置き換えるような単純な話では済まない可能性が高いです。

余談ながら、今回、具体的な提案が出てきたFully Specified Algorithms for JOSE and COSEは、JOSEやCOSEのalg値に、厳密なアルゴリズムを入れるようにしようというMichael B. Jonesらの提案なのですが、これは、COSE-HPKEの議論の中で、私が「alg値は (特にCOSEでは)アルゴリズムを厳密に定義するものにはなっていない」と指摘したことが提案の端緒になっているものです。

〇MLS (Messaging Layer Security) WG

MLSは、End-to-Endメッセージングをセキュアに行うためのアーキテクチャとプロトコルを扱うWGです。ここで扱うプロトコルは、メッセージング自体のプロトコルではなく、主にEnd-to-End暗号通信を行うためのクライアント間・グループ間での鍵素材の共有など、鍵管理、グループ・クライアント管理のための制御プロトコルです。むしろ、メッセージングプロトコルとは独立・非依存のものになっています。HPKEは、もちろんEnd-to-End暗号を実現する基本仕様として採用されています。

前回のIETF 117に先立つ2023年7月、プロトコル仕様がRFC化されました(RFC9420)。IETFの会合でシャンパンがふるまわれるのを初めて目にしましたが、一つの区切りがついたということでしょう。片割れのアーキテクチャ仕様はまだRFC化されていませんが、今回の会合では、WGのチャーター(趣意書)の更新が主な議題でした。本記事の執筆時点では、チャーターのドラフトは、MLSプロトコルの拡張にフォーカスした内容にアップデートされていました。

〇OHAI (Oblivious HTTP Application Intermediates) WG

OHAIは、匿名性の高いPrivacy-PreservingなHTTPアクセスを実現する仕組みを扱うWGです。要は個々のHTTPアクセスをサーバ側から見たときに”Unlinkable”にしようという話なのですが、これを実現するプロトコルとしてOblivious HTTP (OHTTP)という仕様の策定を進めています。これは、クライアントとサーバの間に、クライアントのIPアドレスはわかるがリクエストの内容はわからない「リレー」と、クライアントのIPアドレスはわからないがリクエストの内容はわかる「ゲートウェイ」という二つのコンポーネントを設けることで目的を達成するのですが、クライアントとゲートウェイが、リレーにわからないようにリクエストをやり取りするところにHPKEが使われています。

今回、OHAI WGの会合は開催されませんでしたが、私が本記事を執筆している2024年1月時点で、コア仕様であるOHTTPはAUTH48に進んでおり、まもなくRFC化される見込みです。

〇PPM (Privacy Preserving Measurement) WG

PPMは、プライバシーを保護しつつメトリクス収集・集約するためのプロトコルを扱うWGです。ここでは詳しい説明は省きますが、クライアントからのメトリクス収集や、集約データの共有にHPKEによるEnd-to-End暗号が活用されています。Let’s Encrypt を運営しているISRG (Internet Security Research Group)が、ここで策定中のDAP (Distributed Aggregation Protocol for Privacy Preserving Measurement)というプロトコルを使ったDivvi Upというプライバシー保護メトリクス収集サービスをローンチしようとしています。このため、WGの会合では、Divvi Upの実装状況の報告も行われたりしています。今回の会合のメイントピックはやはりDAP仕様で、Issueベースで活発なディスカッションが行われていました。

余談ですが、このDivvi Upが、Webブラウザ上で動くクライアント実装に私のHPKEライブラリを採用してくれています。こういうところも、OSSや標準化活動をする醍醐味の一つかなと思います。

以上、HPKEとその応用に関する動向について一通り概説してみました。既に策定されたECHやODoHだけでなく、現在でも多様なユースケースやレイヤでHPKEの活用検討が進んでいることが伝われば幸いです。