おはようございます！
トラブルを呼ぶ男GMOコネクトでCTOしている菅野（かんの）こと、さとかん です。
さっきの速報の続報ですよ？
はじめに
Part 1: 概要・ネットワーク管理・ルーティング編に続き、IETF 124 Hackathonのレポート第2弾をお届けします。本記事では、PQCを中心としたセキュリティ・暗号技術関連のプロジェクトに焦点を当てます。
量子コンピュータの脅威に対抗するため、IETFでは積極的にPQC標準化が進められており、今回のハッカソンでも多くの実装と相互運用性テストが行われました。
本記事で紹介するプロジェクト
-
PQC関連
- PQ in X.509
- COSE PQC
- PQC DNSSEC
-
認証・プロビジョニング
- TEEP and VERAISON
- Web Bot Authentication
- Attested TLS
-
その他セキュリティ
- SCONE
- DKIM2
- SCITT
1. PQC関連プロジェクト
1.1 PQ in X.509
プロジェクト概要
既存のX.509構造（鍵、署名、証明書、プロトコル）に耐量子計算機暗号（PQC）アルゴリズムのサポートを追加し、異なる実装間での相互運用性テストを実施しました。
主な達成事項
-
Composite Signaturesの相互運用性テスト
- 多数のチーム間でテストを実施
- ハッカソン直前に公式OIDが割り当てられました
- 複数の実装間での署名生成・検証に成功
-
Composite KEMのテスト
- 鍵カプセル化メカニズムの複合的な利用
- ハイブリッドアプローチの検証
Composite Signaturesとは？
Composite Signaturesは、従来の暗号アルゴリズム（RSA、ECDSAなど）とPQCアルゴリズム（ML-DSAなど）を組み合わせた署名方式です。例えば、RSA-3072とML-DSA-65を組み合わせることで、1つの証明書に2つの異なる暗号方式による署名が含まれます。検証時には両方の署名を確認し、すべてのデジタル署名が検証OKである場合のみ、全体のデジタル署名が有効と判断されます。一つでも失敗すれば、全体の検証が失敗することになります。
想定されるメリット
Composite Signaturesの主な利点は、移行期における安全性の確保です。従来のアルゴリズムとPQCアルゴリズムを組み合わせることで、どちらか一方のアルゴリズムが破られても、もう一方で保護を維持できます。また、既存システムとの共存が容易なため後方互換性にも優れており、PQCアルゴリズムに未知の脆弱性が発見された場合のリスク軽減にもなります。
実装上の課題
最新のドラフトに基づくコンポジット鍵フォーマットの実装は比較的容易でしたが、異なる暗号ライブラリとの統合が最も困難でした。OpenSSL、BoringSSL、liboqsなど異なるライブラリ間には差異があり、APIの非互換性やパフォーマンス特性の違いに対応する必要がありました。
なぜ重要なのか？
十分に強力な量子計算機が実現すると、RSAやECDSAなどの従来の公開鍵暗号が破られる可能性があります。特に懸念されるのが「Store now, decrypt later」攻撃で、現在暗号化されたデータを保存しておき、将来量子計算機で解読するというものです。
このため、早期の移行が重要となります。PKI基盤の更新には時間がかかり、特に長期間有効な証明書（ルートCA等）は早めの対応が必要です。また、相互運用性の確保が実用化の鍵となります。
関連リンク
1.2 COSE PQC
プロジェクト概要
COSEワーキンググループで検討されているML-DSAなどのPQCアルゴリズムを、t_coseライブラリに統合する試みが実施されました。
COSE（CBOR Object Signing and Encryption）とは？
COSEは、制約されたデバイス向けのセキュリティフォーマットです。CBORという簡潔なバイナリ表現を使用し、IoTデバイスなどリソース制約のある環境に最適化されています。JSON Web Signatures（JWS）やJSON Web Encryption（JWE）のバイナリ版として機能します。
主な達成事項と課題
-
ML-DSAのCOSE実装に着手
- NIST標準化されたML-DSA（旧Dilithium）の統合作業
-
AI（LLM）の活用試行
- コーディングの迅速化を試みたが、予想以上に時間がかかった
- 教訓: 複雑な暗号実装ではAIの支援にも限界がある
-
暗号ライブラリ統合の複雑さ
-
t_cose内の異なる暗号ライブラリとの統合が課題 - インターフェースの統一が困難
-
ML-DSA（Module-Lattice-Based Digital Signature Algorithm）
ML-DSAは、NIST PQC標準として選定された格子暗号に基づく署名アルゴリズムです。セキュリティレベルに応じてML-DSA-44、65、87の3つのバリエーションがあります。署名サイズは2.4KB～4.6KB、公開鍵サイズは1.3KB～2.6KBとなっており、署名生成は高速、署名検証は非常に高速という特徴があります。
IoT/組み込みシステムでの課題
IoT環境での主な課題は、メモリ制約（大きな鍵/署名サイズ）、計算能力（一部のマイコンでは演算が重い）、そして電力消費（バッテリー駆動デバイスへの影響）です。
関連リンク
1.3 PQC DNSSEC（DNS Miscellaneous Projectsより）
プロジェクト概要
ポスト量子暗号（PQC）のDNSSECテストベッドの構築、およびML-DSA署名アルゴリズムのMLT（Merkle Tree Ladder）モードサポートの予備的な作業が行われました。
DNSSECへのPQC導入の課題
-
UDPパケットサイズの制限
- DNS応答は通常UDPで送信（512バイト制限、EDNS0で拡張可能）
- PQC署名は大きい（数KB）
- 断片化が発生しやすい
-
キャッシュへの影響
- DNSキャッシュサーバーのメモリ消費増加
- TTLとのバランス
-
ゾーン署名のコスト
- 大規模ゾーンでの署名生成時間
- 鍵のロールオーバー
MLT（Merkle Tree Ladder）モードとは？
Merkle木構造を使用して、署名サイズを削減する技術：
- 通常のML-DSA: 1つの署名につき2.4KB～
- MLTモード: 複数の署名を木構造で管理し、効率化
仕組み：
Merkle木構造を使用して、複数の署名を階層的に管理します。具体的には、複数の署名をペアにしてハッシュ値を計算し、そのハッシュ値を再びペアにして上位のハッシュ値を計算していきます。最終的に1つのルートハッシュ値が得られます。DNSSECレスポンスでは、必要な署名とその署名を検証するために必要な最小限のハッシュ値（パス）だけを送信します。これにより、すべての署名を送信する必要がなくなり、トータルサイズを大幅に削減できます。
DNSSECの将来
- 段階的な導入: まずTLD、次にルートゾーン
- ハイブリッドアプローチ: 既存アルゴリズムとの併用
- プロトコル拡張: DNSSEC over QUICなどの検討
2. 認証・プロビジョニング
2.1 Secure Software Provisioning Using TEEP and VERAISON
プロジェクト概要
TEEPプロトコル（RFC 9397） に基づく、TEE（Trusted Execution Environment） へのセキュアなソフトウェアプロビジョニングのPoCを開発しました。
TEEとは？
Trusted Execution Environment（TEE）：
- 分離された実行環境: メインOSから隔離
- ハードウェア保護: プロセッサレベルでのセキュリティ
- 機密性と完全性: 実行中のコードとデータを保護
代表的な実装として、ARM TrustZone、Intel SGX、AMD SEVなどがあります。
TEEP（Trusted Execution Environment Provisioning）
TEEへのアプリケーション配布を安全に行うためのプロトコルです。TAM（Trusted Application Manager）がTEEPプロトコルを使ってTEEP Agentと通信し、TEEP AgentがTEE内のTrusted Applicationを管理します。このプロセスにより、リモートからTEE内のアプリケーションを安全にインストール、更新、削除することができます。
主な達成事項
-
VERAISONの統合
- リモート認証ベリファイアとしてVERAISONを統合
- 実際のWebAssemblyアプリケーションをTEEPメッセージのペイロードに埋め込んで配布
-
Generic-EAT認証スキームの実装
- TEEPプロトコルのサポートに必要であることが判明
- VERAISONにこのスキームを実装
発見された課題
仕様の曖昧さ：
- リモート認証失敗時のTAM（Trusted Application Manager）の動作が不明確
- 返すべきエラーの詳細が仕様で明確でない
- 実装を困難にする要因
EAT（Entity Attestation Token）
TEEの状態を証明するためのトークンフォーマットで、JSON形式で構造化されています。トークンには、TEEのプロファイル情報、OEM ID、ハードウェアモデル、ハードウェアバージョン、ソフトウェア名、ソフトウェアバージョンなどが含まれます。これにより、TEE内で動作しているソフトウェアとハードウェアの正確な状態を検証者に伝えることができます。
実用的なユースケース
TEEPとVERAISONの統合により、様々なユースケースが実現できます。セキュアなOTAアップデートでは、IoTデバイスへの安全なファームウェア更新やTEE内のアプリケーション更新が可能になります。機密性の高いワークロードとして、金融取引処理、生体認証データの処理、DRMコンテンツの再生などが挙げられます。また、エッジコンピューティング環境では、クラウドからエッジデバイスへの安全なアプリ配布が実現できます。
関連リンク
2.2 Web Bot Authentication
プロジェクト概要
AIエージェントがAPIと対話するための、Web Bot Authenticationドラフトに基づくシンプルなPython CLI実装が構築されました。
なぜ「ボット認証」が必要なのか？
従来のOAuth2などの認証方式は人間のユーザーを想定：
- ブラウザベースのフロー
- ユーザーの同意が必要
- インタラクティブな認証
AIエージェント/ボットの課題：
- 人間の介在なしで動作
- 大量のAPI呼び出し
- 自律的な意思決定
実装した構成要素
-
署名エージェント
- Azure OpenAIとの統合を含む
- HTTPリクエストにHTTP Message Signatureを使用して署名
-
検証サーバー
- 署名の検証
- リクエストの認可
-
ディレクトリサーバー
- エージェントの公開鍵管理
- エージェントのメタデータ
HTTP Message Signaturesとは？
HTTPリクエスト/レスポンスの内容に署名を付与する標準（RFC 9421）で、リクエストのメソッド、パス、ヘッダーなどに対して署名を生成します。具体的には、署名したい要素（メソッド、パス、Content-Typeなど）を選択し、それらを含む署名入力を作成します。署名にはタイムスタンプと鍵IDも含まれ、Base64エンコードされた署名値がSignatureヘッダーに格納されます。これにより、HTTPリクエストが改ざんされていないこと、正しい送信者から送られたことを検証できます。
メリット：
- 改ざん検知: リクエスト内容の完全性を保証
- 認証: 送信者の身元を確認
- 非repudiation: 送信の事実を否認できない
AIエージェントのセキュリティ考慮事項
AIエージェントのセキュリティでは、複数の重要な側面を考慮する必要があります。鍵管理では、エージェントごとに異なる鍵を使用し、定期的な鍵のローテーションを実施します。権限管理では、最小権限の原則に基づき、エージェントのアクセススコープを制限します。また、監査とロギングでは、すべてのAPIアクセスを記録し、異常検知システムを導入します。
実装から得られた知見
- 署名エージェントフィールドの適切な使用法
- JWKサムプリントの活用
- エラーハンドリングのベストプラクティス
2.3 Identity Crisis in Confidential Computing
プロジェクト概要
Confidential Computing環境におけるAttested TLSプロトコルのアイデンティティ問題について議論されました。
Confidential Computingとは？
使用中のデータを保護する技術：
- Data at rest: 暗号化されたストレージ（既存技術）
- Data in transit: TLS/VPN（既存技術）
- Data in use: メモリ内のデータも保護（新しい領域）
実装技術：
- Intel SGX
- AMD SEV
- ARM CCA（Confidential Compute Architecture）
問題意識
従来のPKI認証では不十分：
-
証明書による認証
- サーバーの「所有者」は確認できる
- しかし、サーバー上で何が実行されているかは不明
-
必要な追加保証
- 実行環境（VM内のソフトウェア/ハードウェア）の証明
- Attestation Evidenceが必要
Attested TLSの概念
通常のTLSハンドシェイクに加えて、サーバーがAttestation（実行環境の証明）を提供し、クライアントがそれを検証します。具体的な流れは以下の通りです：
- クライアントがサーバーにTLSハンドシェイクを開始
- サーバーが通常の証明書に加えてAttestation（実行環境の証明情報）を送信
- クライアントがAttestationを検証（実行コードのハッシュ値、ハードウェア構成、セキュリティパッチレベルなどを確認）
- 検証に成功すれば、安全で証明された接続が確立
このプロセスにより、単にサーバーの所有者を確認するだけでなく、サーバー上で実際に何が実行されているかも検証できます。
Attestationの内容：
- 実行中のコードのハッシュ値
- ハードウェアの構成
- セキュリティパッチレベル
- ブートプロセスの整合性
議論のポイント
-
ポストハンドシェイク認証
- Attested TLSの標準化には、TLS 1.3のポストハンドシェイク認証が適切
- 既存のTLSフローを拡張可能
-
認証階層の再考
- 古典的なLoweの認証階層はこの文脈には適さない
- 新しいセキュリティモデルが必要
ユースケース
Confidential Computingは様々な分野で活用されます。機密データ処理では、医療データの解析、金融データの処理、個人情報の取り扱いなどで威力を発揮します。マルチテナント環境では、クラウドプロバイダーからもデータを保護し、テナント間の完全な分離を実現します。また、セキュアな協調計算では、複数の組織間でデータを共有せずに計算を実行できます。
課題
実装には課題も存在します。Attestation検証のパフォーマンスオーバーヘッド、Attestation鍵のライフサイクル管理、そしてAttestationから漏れる可能性のある情報に関するプライバシー懸念などが挙げられます。
3. その他セキュリティプロジェクト
3.1 SCONE Interoperability
プロジェクト概要
SCONEプロトコルの相互運用性テストが実施されました。
主な達成事項
-
初のインターネット越え通信
- 複数の組織（3社以上の企業、1つの大学）が参加
- モントリオールとドイツのテストネットワーク間でSCONEパケットの通信に成功
-
実アプリケーションへの統合
- SCONEクライアントをAndroid上のFacebookアプリに統合
- MetaのFacebookサーバーとのビデオフローで動作確認
- Ericsson SCONE Enforcerを介した通信に成功
SCONEとは？
SCONE（Service-Controlled Network Environment）は、アプリケーションがネットワークサービスを制御するためのプロトコルです。
特徴：
- QoS保証: アプリケーションレベルでのQoS要求
- 動的な制御: ネットワーク条件に応じた適応
- エンドツーエンド: ネットワーク全体での一貫性
ビデオストリーミングでの利用
Facebookアプリでの統合により、以下が実証されました：
- 帯域幅の動的調整: ネットワーク状況に応じた品質調整
- 低遅延化: リアルタイム通信の改善
- 優先度制御: 重要なフレームを優先的に転送
今後の展望
- プロトコルの ワーキンググループ最終コール（WGLC） に向けた進展
- 標準化への大きな一歩
3.2 DKIM2
プロジェクト概要
既存のDKIM（メール署名メカニズム）を置き換えるDKIM2の初期ドラフト（draft-gondwana-dkim2-header-04など）の実装と相互運用性のテストが行われました。
DKIMの課題
現行のDKIM（RFC 6376）には以下の課題があります：
-
柔軟性の欠如
- 署名対象ヘッダーの選択が硬直的
- 新しい要件への対応が困難
-
複雑な正規化
- ヘッダーやボディの正規化ルールが複雑
- 実装の相互運用性に影響
-
セキュリティの問題
- 一部の攻撃に脆弱
- 署名の再利用など
DKIM2の改善点
-
Mail-Versionの導入
- 開発経験に基づいて設計を見直し
- フォーマットを単純化・正規化
-
既存ライブラリの再利用
- 既存のDKIMライブラリを容易に再利用できることを確認
- 移行コストの削減
発見された課題
仕様の曖昧さ：
- フィールドの正確な定義に関して不明確な点
- 実装経験を通じて、より正確な記述が必要であることを認識
メール認証の重要性
スパム/フィッシング対策：
- DKIM: 送信者のドメイン認証
- SPF: 送信サーバーの認証
- DMARC: ポリシー適用
DKIM2の期待：
- より強固な認証
- 実装の容易さ
- 将来の拡張性
3.3 A YANG Data Model for Multi-Statements of SCITT
プロジェクト概要
SCITT（Supply Chain Integrity, Transparency, and Trust） のドラフトでは対処できない、階層的な保護（hierarchical protection） をカバーするためのYANGデータモデルの必要性について議論されました。
SCITTとは？
サプライチェーンの完全性、透明性、信頼を保証するためのフレームワーク：
目的：
- ソフトウェア部品の来歴追跡
- 改ざんの検知
- 透明性のあるサプライチェーン
構成要素：
- Statements: 主張（「このバイナリは私が署名した」等）
- Transparency Service: 主張を記録・公開
- Receipts: 記録の証明
主な達成事項
-
スキームの検証
- SCITT保護されたステートメントを他のステートメントと統合するスキームが有望
- 以下との統合を確認：
- 他のSCITTステートメント
- 脆弱性レポート
- システム設定
-
課題の明確化
- ユースケースセクションの強化が必要
- 誰がどのような利益を得るのかを明確にする必要
-
柔軟性の確認
- データ構造のフォーマットはYANGに限定される必要はない
階層的な保護とは？
複数レベルでの署名・検証により、ソフトウェアサプライチェーンの各段階を保護します。例えば、最下層（レベル1）でソースコードステートメントと依存関係ステートメントに署名し、中間層（レベル2）でビルドステートメントとテストステートメントに署名、最上層（レベル3）でルートステートメントに署名します。各レベルで異なる主体（開発者、ビルドシステム、品質保証チームなど）が署名することで、全体として多層的な信頼チェーンを構築します。これにより、サプライチェーンのどの段階で問題が発生しても、その影響範囲を特定し、信頼性を評価できます。
サプライチェーンセキュリティの重要性
近年、ソフトウェアサプライチェーンへの攻撃が深刻化しています。2020年のSolarWinds攻撃ではビルドプロセスへの侵入が行われ、2021年のLog4Shellでは依存ライブラリの脆弱性が露呈し、2024年のXZ Utils backdoorではオープンソースへの悪意ある貢献が問題となりました。
SCITTは、これらの脅威に対抗するための重要な役割を果たします。各ステップの検証可能性により、異常の早期検知が可能になり、インシデント対応を迅速化できます。
3.4 RADIUS Updates (Protocol-Error)
プロジェクト概要
RADIUSプロトコルのシグナリングエラーを解決するため、新しいパケットタイプ（PROTOCOL-ERROR） の導入と実装テストが行われました。
RADIUSの課題
長年の問題：
- サーバーがパケットを「サイレントに破棄」する場合がある
- クライアントはタイムアウトまで待つしかない
- トラブルシューティングが困難
具体的なシナリオ：
- 不正な属性を含むパケット
- プロトコル違反
- サポートされていない拡張機能の使用
PROTOCOL-ERRORパケット
新しいパケットタイプの導入により、サーバーはエラーを検出した際に、サイレントに破棄する代わりにPROTOCOL-ERRORパケットを返します。具体的な動作は以下の通りです：
- クライアントがサーバーにAccess-Requestを送信
- サーバーがパケット内のエラー（不正な属性、プロトコル違反など）を検出
- 従来：サーバーはサイレントにパケットを破棄し、クライアントはタイムアウトまで待機
- 新方式：サーバーはPROTOCOL-ERRORパケットをエラー詳細とともに即座に返信
- クライアントはエラー内容を確認し、適切に対応
これにより、ネットワーク管理者はタイムアウトを待つことなく、即座に問題の原因を特定できます。主なメリットとして、即座のエラー通知、詳細なエラー情報の提供、デバッグの容易化が挙げられます。
実装とテスト
複数の実装（FreeRADIUS、radsecproxy、Radiator）が参加し、相互運用性テストを実施しました。このテストを通じて、仕様ドラフトの実装上のコーナーケースや変更点が発見され、フィードバックが仕様に反映されました。
RADIUS over QUICの議論
今後の発展として、RADIUS over QUICが議論されました。QUICには、0-RTT接続確立による低遅延、パケットロスへの対応による信頼性、TLS 1.3ベースの暗号化によるセキュリティといったメリットがあります。実現可能性が高いことが示唆され、今後の標準化が期待されます。
まとめ
IETF 124 Hackathon Part 2では、セキュリティと暗号技術の最新動向、特にPQCの実装と相互運用性に焦点を当てました。
主なトレンド
- IETF 124 Hackathonでは、いくつかの重要なトレンドが見られました。まず、PQCの実用化が加速しており、Composite Signatures/KEMの相互運用性テストが実施され、複数の実装が登場し、標準化が進展しています。
- 信頼実行環境の活用も進んでおり、TEEとAttestation、Confidential Computing、エンドツーエンドの保証といった技術が発展しています。
- AIエージェントのセキュリティも重要なテーマとなり、ボット認証の標準化、HTTP Message Signatures、自律的なシステムの認証が議論されました。
- サプライチェーンセキュリティでは、SCITTによる透明性の確保、階層的な保護、来歴の追跡が注目されました。
PQC移行への推奨事項
企業や組織がPQC移行を検討する際は、以下の段階的なアプローチが推奨されます。
まず、インベントリ作成として、現在使用している暗号アルゴリズムの棚卸しを行い、長期保存データを特定します。
次に、ハイブリッドアプローチとして、まずはComposite方式で移行を開始し、リスクを最小化しながら経験を蓄積します。
テストと検証の段階では、本番環境に導入する前に十分なテストを実施し、相互運用性を確認します。
最後に、段階的な展開として、クリティカルでない部分から開始し、徐々に範囲を拡大していきます。
次回予告
Part 3: アプリケーション・AI・IoT編では、DNS over CoAP、PacketScope（LLM-Powered eBPF）、I2ICF（In-Network Computing）、5G-I2NSF、Multi-CDN、その他革新的プロジェクトなど、アプリケーション層とIoT関連の最新技術を紹介します。
お楽しみに！って...読んでくれている人はいるのだろうか...
参考リンク
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
一緒に働きたい人も気軽にコンタクトを取ってください！