CurveBall――偽の証明書を、なぜWindowsが信頼してしまったのか？ ── CryptoAPIと楕円曲線のパラメーター

ダウンロードしたSetup.exeの署名を確認すると、有効と表示される。それでも発行元が偽物だったとしたら、何を確認し損ねたのでしょうか。CurveBallは、署名の計算を間違えなくても、信頼する相手を取り違え得ると示した脆弱性です。

1. 概要

CurveBall（CVE-2020-0601）は、WindowsのCryptoAPIが、細工されたECC証明書を信頼された認証局につながるものとして扱ってしまう脆弱性です。 コード署名の偽装や、TLS通信でのなりすましにつながりました。¹²

暗号方式そのものの破綻ではありません。本物の認証局の秘密鍵を知らなくても、別の条件で作った鍵を本物と取り違えさせられた、という話です。⁷⁸

2. 対象

当時の対象はWindows 10、Windows Server 2016・2019などです。製品別の更新はMicrosoftのCVE情報で確認できます。ここでは、未修正のWindowsで証明書を検証していた場面を扱います。³⁹

影響するのはMicrosoft製アプリだけではありません。CERT/CCは、信頼されたルートまでたどれるかの判断をCertGetCertificateChainへ依存する第三者製アプリも対象になり得ると説明しています。画面を表示するアプリと、検証するライブラリーは別です。¹⁰

flowchart TB
    accTitle: 証明書検証を共有するWindowsアプリ
    accDescr: コード署名やTLSの検証をWindowsへ依頼するアプリでは、画面の違いだけで影響範囲を判断できません。
    A["コード署名を調べるアプリ"] --> C["Windowsの証明書検証"]
    B["TLS証明書を調べるアプリ"] --> C
    C --> D["影響するCryptoAPIの処理"]

図1: 対象は、アプリの名前ではなく、問題のある検証経路を使うかで考えます。¹⁰

また、この攻撃で利用する明示的パラメーター付きECC鍵は、Windows 8.1以前・Server 2012 R2以前ではサポートされません。古い版が同じ経路では影響しないのは、証明書のその形式を受け付けないためです。¹¹

3. 詳細

署名から、どこまでたどるのか

冒頭のSetup.exeを配る会社を「配布元B」、その証明書を発行する認証局を「ルートA」とします。説明を絞るため、中間認証局は省きます。

配布元Bは自分の秘密鍵でファイルに署名します。受け取る側は、Bの証明書にある公開鍵で署名を調べます。しかし、その証明書もB自身が勝手に作ったものなら、Bを信用する理由にはなりません。そこで証明書の発行元をたどり、もともと信頼している認証局まで確認します。¹²

flowchart TB
    accTitle: ファイルの署名から信頼済みの認証局までたどる
    accDescr: Setup.exeの署名を配布元Bの鍵で確認し、Bの証明書を発行したルートAが信頼の起点になる単純な構成です。
    A["信頼済みのルートA"] -->|"Bの証明書に署名"| B["配布元Bの証明書"]
    B -->|"Bの公開鍵で確認"| C["Setup.exeの署名"]

図2: ファイルの署名が合うだけでなく、その鍵を誰のものとして信頼するかを確かめます。¹²¹³

ルートAが信頼されるのは、「自分で自分の証明書に署名したから」ではありません。信頼の起点として、あらかじめ採用されているからです。RFC 5280でも、信頼アンカーの情報は検証へ与える入力であり、自己署名証明書の形で与えられても、それ自体は検証対象の経路に含めないと整理されています。¹³

公開鍵の点だけでは、計算の条件が分からない

ルートAがECDSAを使う場合、公開鍵の点をQ、秘密の整数をd、計算の基準点をGとすると、関係は次のように書けます。¹⁴

Q = d × G

この掛け算は、点の座標をそれぞれd倍することではありません。楕円曲線で定義された点の足し算を繰り返すスカラー倍です。GとQは公開してよい情報ですが、適切な大きさの曲線と固定されたGのもとでは、そこからdを求めることは困難です。¹⁴

証明書にも、点のデータだけが置かれているわけではありません。RFC 5480のSubjectPublicKeyInfoは、アルゴリズムとパラメーターを持つ部分と、公開鍵の点を収める部分に分かれています。¹⁵

flowchart TB
    accTitle: ECCの公開鍵情報は点とパラメーターを組にして読む
    accDescr: SubjectPublicKeyInfoでは、公開鍵の点を収める部分とは別に、アルゴリズムと楕円曲線のパラメーターを表す部分があります。
    A["SubjectPublicKeyInfo"] --> B["algorithm"]
    A --> C["subjectPublicKey：点Q"]
    B --> D["方式とパラメーター"]
    D --> E["曲線・基準点Gなどを特定"]

図3: 点Qのバイト列が一致しても、パラメーターまで同じとは限りません。¹⁵¹⁶

一般的なnamedCurveは、P-384などの名前を表すOIDでパラメーター一式を指定します。一方、公表攻撃では、パラメーターを個別に渡す形式が使われました。ここで、標準のGとは違う基準点を指定できたことが効いてきます。¹⁶⁸

基準点を変えると、同じQを別の秘密鍵で作れる

攻撃者は、ルートAの秘密鍵dを解こうとはしません。公開されているQを、そのまま別の基準点G′に選ぶことを考えます。すると、整数1との組で同じQになります。¹⁷

本物の組：      基準点 G、秘密鍵 d、公開鍵の点 Q = d × G
別の組：        基準点 G′ = Q、秘密鍵 d′ = 1
別の組の計算：  d′ × G′ = 1 × Q = Q

元のdは、最後まで分かっていません。 同じQが得られても、基準点が違うので別の組です。元のルートAのパラメーターで検証すれば、これをルートAの正しい署名として使えるわけではありません。¹⁷

flowchart TB
    accTitle: 異なる基準点から同じ公開鍵の点が得られる
    accDescr: 本物はGをd倍してQを得ますが、別の組はQ自体を基準点にして1倍するため、点の値だけは一致します。
    A["本物：基準点G"] -->|"秘密のd倍"| B["公開鍵の点Q"]
    C["別の組：基準点G′＝Q"] -->|"1倍"| D["同じ点Q"]
    B -.-|"点は一致、条件は不一致"| D

図4: 曲線上の点Qを変えずに、その点を作る基準点と秘密鍵の組を変えています。¹⁷

数値でも確認しておきます。説明用にy² = x³ + 2x + 2 (mod 17)という小さな曲線を選び、G = (5, 1)を7倍するとQ = (0, 6)になります。今度はG′ = (0, 6)を基準にすれば、1倍で同じ点です。

G = (5, 1)
2G = (6, 3)
3G = (10, 6)
...
7G = (0, 6) = Q

G′ = (0, 6)
1G′ = (0, 6) = Q

これは本稿用の小さな計算例で、実用の鍵長でもWindowsの検証結果でもありません。計算スクリプトと結果JSONに、入力と各段階を残しています。ポイントは、曲線の式まで変えなくても、基準点の変更だけでこの関係が成り立つことです。

計算は正しくても、ルートAではない

この別の組を使えば、攻撃者は自分が知っている秘密鍵で、下位の証明書へ署名できます。細工した認証局の情報とその下位証明書をまとめて渡すと、渡されたパラメーター同士では、署名の計算が合う構成を作れます。⁸

それだけなら、信頼されない認証局が発行した証明書にすぎません。問題は、その認証局をルートAと照合する段階でした。McAfeeのTLS経路の検証では、公開鍵情報を照合するときにECCのパラメーターまで比較しておらず、細工した認証局を信頼済みのものと取り違えていました。⁵

flowchart TB
    accTitle: 数学的に成立する署名を誤った信頼へ結び付けた
    accDescr: 攻撃者が渡した情報で署名の計算は成立しますが、異なる基準点を持つ認証局を、同じ点Qを持つ信頼済みルートへ誤って結び付けます。
    A["渡された組：G′とQ"] --> B["その組で署名は成立"]
    B --> C["信頼済みルートとの照合"]
    R["信頼済みの組：GとQ"] --> C
    C -->|"パラメーターの違いを見落とす"| D["ルートAにつながると誤認"]

図5: 署名の計算ではなく、計算に使った鍵を信頼済みの鍵と同一視するところが崩れます。¹⁸⁵

つまり冒頭のSetup.exeでは、攻撃者の用意した署名用証明書に、偽の認証局を経由して信頼が与えられます。信頼済みストアへ偽のルートを追加してもらったのではなく、追加していない偽物を既存のルートへ結び付けてしまったのです。¹⁹

ただし、実際の成立条件を点Qの一致だけに省略してはいけません。Romaillerらの実証には、元のルートが一度読み込まれ、証明書キャッシュにある条件が記されています。また、McAfeeのTLS検証では、名前やシリアル番号が違っても成立しました。実証の手順に現れる値の一致を、全経路共通の必要条件と決めつけないようにします。²⁰²¹

4. 影響

直接壊れたのは、証明書チェーンの信頼判定です。コード署名では、不正な実行ファイルを正規の発行元によるものに見せかけられます。ただし、署名が信用されたことと、そのファイルが実行されたこと、管理者権限を得たことは別です。後者へ進むには、利用者やアプリの実行・権限付与などが必要になります。²¹⁹

TLSでは、利用者の接続を攻撃者のサーバーへ向けられるなどの条件と組み合わさると、偽の証明書を受け入れさせ、通信を読み取ったり変更したりする攻撃につながります。これは、保存済みの暗号通信を後から何でも復号できるという意味ではありません。²

flowchart TB
    accTitle: TLSのなりすましでは暗号化と接続相手の確認を分ける
    accDescr: 利用者が攻撃者側へ接続する条件がある場合、偽の証明書を受け入れると攻撃者との暗号化通信が成立し得ます。本物のサーバーの秘密鍵を解いたわけではありません。
    A["利用者のアプリ"] -->|"偽の証明書を受け入れる"| B["攻撃者側の接続先"]
    B -->|"別の接続で中継する場合"| C["本物のサーバー"]

図6: 通信が暗号化されていても、接続相手を間違えれば、その相手には内容が届きます。²

Microsoftは2020年1月14日の公表時点では、実際の攻撃への利用を確認していないと説明しました。一方、CISAのKEVには2021年11月3日付で掲載されています。「公表時には未確認」を「その後も悪用されていない」と読み替えてはいけません。KEVの登録日は、最初の攻撃日を示すものではありません。³⁶

5. 対策

比較する対象を、点Qだけで終わらせない

Microsoftは2020年1月14日の更新で対処しました。McAfeeの修正後の分析では、公開鍵情報の比較に曲線のパラメーターも含まれるようになったと説明されています。³²²

flowchart TB
    accTitle: 同じ点でも異なるパラメーターの鍵を信頼しない
    accDescr: 信頼済みルートの鍵と照合する際、点Qだけでなく、基準点を含む必要なパラメーターも確認すれば、今回の別の組を同じ鍵として扱えません。
    A["提示された鍵の情報"] --> B{"信頼済みの鍵と一致？"}
    B -->|"Qは同じ、Gが違う"| C["同じ鍵として信頼しない"]
    B -->|"必要な情報が一致"| D["他の検証条件も確認"]

図7: 修正の要点は、同じ公開鍵に見える値を、その解釈に必要な条件と一緒に比べることです。²²

この図は修正の意味を示すもので、Windows内部の全処理順を再現したものではありません。McAfeeも、検証順自体まで変わったかは分からないとしています。パッチの効果と、未確認の実装詳細は分けておきます。²³

なおRFC 5480のPKIX向け規定は、そもそもnamedCurveを使い、明示的なspecifiedCurveを使わないと定めています。これは当時のWindowsが受理していた形式の説明とは別です。「仕様が禁止しているから実装も受け付けないはず」と考えるだけでは、実際の入力経路を見落とします。¹⁶

Windowsの更新を確認する

対策の基本は、この修正を含む適切なWindowsの更新です。NSAも、一部の攻撃を検出・遮断する方法はあっても、包括的な対処はパッチだと説明しています。特定のブラウザーで偽の証明書を拒否しただけでは、同じOS上の別アプリまで確認したことにはなりません。²⁴¹⁰

運用では、対象のWindowsと更新履歴を確認し、証明書を信頼できないというエラーを無効化して回避しないことが重要です。開発側でも、自作の簡略な比較処理へ置き換えるのではなく、更新済みの検証基盤を使い、用途に必要な信頼・名前・有効期限などを確認します。¹²¹³

6. 教訓

CurveBallで見落とされたのは、数値そのものよりも、その数値をどう解釈するかという条件でした。点Qだけを見れば一致する。しかし、Gで作った鍵とG′で作った鍵を同一視すると、元の秘密鍵を知らない相手へ信頼を渡してしまいます。

この違いはテストにもできます。「正しい鍵なら通る」「点を変えたら落ちる」だけでは足りません。点はそのまま、基準点だけ変えたものを、同じ信頼済み鍵として受け入れないかを確かめる。正常例の値を一つだけ変えたとき、その変更が最終的な信頼判定まで届くかを追う、という点検です。

署名の計算に成功したら確認終了、ではありません。計算が成立した鍵と、信頼していた鍵は本当に同じか。冒頭の「有効な署名なのに偽物」という疑問は、そこまでたどると矛盾ではなくなります。

本稿は公開資料に基づく解説です。数値例は独自の小さな曲線上で計算しましたが、未修正Windowsでの脆弱性再現、偽造証明書の作成・配布、通信の傍受は行っていません。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全5件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

関連記事

• Zerologonはなぜ認証を突破できたのか？
• PrintNightmareはなぜSYSTEM権限を奪えたのか？

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

CurveBallでは認証局の秘密鍵が盗まれたのですか？

いいえ。公表された仕組みでは、本物の秘密鍵を取り出さず、楕円曲線の基準点を変えた別の鍵の組を使います。公開鍵の点が同じでも、パラメーターが違えば同じ鍵として信頼してはいけません。

楕円曲線暗号そのものが破られたのですか？

いいえ。問題はWindowsの証明書検証の実装でした。固定された正しいパラメーターのもとで秘密鍵を求める問題を解いたのではなく、別のパラメーターを持つ鍵を信頼済みの鍵と取り違えさせました。

攻撃者は偽のルート証明書をあらかじめインストールする必要がありましたか？

公表された経路は、偽のルートを利用者に信頼登録させることを前提にしません。渡された証明書を既に信頼された認証局へ誤って結び付ける問題です。ただし、対象OS、検証経路、証明書キャッシュなどの成立条件があります。

Windows 7や8.1にも同じ問題がありましたか？

CERT/CCは、Windows 8.1以前とWindows Server 2012 R2以前は攻撃に使う明示的パラメーター付きECC鍵をサポートせず、この経路の証明書を信頼しないと説明しています。古いOS全般の安全性や利用推奨を意味するものではありません。

ブラウザーだけ更新すれば対策になりますか？

この問題を含むWindowsのセキュリティ更新が基本です。CryptoAPIで証明書チェーンを検証する別のアプリも影響を受け得るため、あるブラウザーで警告が出ることだけではOS全体の対策完了を判断できません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。