ホワイトボックス暗号に対する3つの最も難解な反論と、それらが的を外している理由

In シリーズ第1部 以前の記事では、ハードウェアセキュリティがどこまで機能するのか、つまり、AndroidのTLSスタックがStrongBoxを完全にバイパスする理由、ハードウェアの断片化によってほとんどのユーザーが保護されない理由、そしてハードウェアセキュリティがバイナリリバースエンジニアリングからプロトコル層を保護できない理由について考察しました。まだ読んでいない方は、その背景知識が重要になります。 

この記事は、ハードウェアセキュリティだけで十分だと考える人ではなく、ホワイトボックス暗号を完全に否定しているような、これまでとは異なるタイプの懐疑論者を対象としています。これらは私たちが最もよく耳にする3つの議論であり、直接的な回答に値するものです。 

論点１：「WBCはケルクホフスの原則に違反している。それはインチキだ。」 

学術的な批判はこうだ。ケルクホフスの原理によれば、暗号システムは鍵以外のすべてが公知であっても安全であるべきだ。ホワイトボックス暗号は鍵を保護するために実装を隠蔽するが、その安全性は秘匿性に依存している。これは真の安全性とは言えない。WhibOxのようなキャプチャー・ザ・フラッグ競技で公開されているホワイトボックス暗号の実装は、いずれも数日で解読されてしまう。これは非科学的な仕掛けに過ぎない。 

この批判は、WBCが実際に行っていることを誤解しており、その結果、WBCが依拠する原則そのものを誤って適用している。 

WBCはアルゴリズムを隠蔽しません。ホワイトボックス形式のAESは依然としてAESであり、入力、出力、演算はすべて同じです。アルゴリズムは完全に公開されており、変更されていません。WBCが行うのは、鍵の保存方法と使用方法を変更し、変換された実装に鍵を埋め込むことで、鍵の抽出を著しく困難にすることです。アルゴリズムは公開されたままですが、鍵は秘密のままです。これこそが、ケルクホフスの原理が要求するところです。 

批判者たちは「実装が強化されている」ことと「アルゴリズムが秘密にされている」ことを混同している。これらは同じことではない。鍵を保護するために実装を強化することは、鍵保護メカニズムであり、原則に違反するものではなく、むしろ原則を満たすものである。 

では、その保護がない場合に何が起こるかを考えてみましょう。攻撃者はあなたのアプリとデバイスを手に入れます。鍵の抽出は高度な攻撃ではなく、チュートリアルレベルの作業です。バイナリ内のARM AES命令を見つけ、ブレークポイントを設定し、アプリを実行してその操作を実行します。レジスタから鍵を読み取ります。無料で入手できるツールを使えば、数分で完了します。この時点で、ケルクホフスの原理はあなたを救ってくれません。鍵は失われてしまうのです。 

WBCは、ケルクホフスの原理を敵対的な環境下でも有効にするものです。攻撃者がバイナリとデバイスを入手した場合でも、鍵を秘密に保つための仕組みです。 

注目すべきは、同じブレークポイント攻撃がOpenSSLに対しても有効であるということだ。AES命令を見つけ、ブレークポイントを設定し、レジスタを読み取る。OpenSSLやその他のオープンソース暗号ライブラリの鍵抽出を破るためのCTFコンテストは開催されていない。なぜなら、それらはそもそも悪意のある実行環境下で鍵を保護するように設計されていないからだ。WBCは、どの標準的な暗号ライブラリも満たしていない基準で評価されている。違いは、WBCがこの問題の解決に積極的に取り組んでいる点にある。 

WhibOxに対する批判には直接答える価値があります。確かに、CTFの実装は破綻することがあります。しかし、商用実装は別物です。当社のRSA/AES実装における既知のDFA脆弱性は、2019年のTFITで解決済みです。また、当社の楕円曲線実装に対する既知のDFA攻撃は確認されていません。当社の製品はFIPS 140-3認証番号4910を取得しており、これは学術的なCTFエントリーでは取得できない独立した検証です。 

さらに重要なのは、WBCは単独で機能するわけではないということです。アプリ強化製品（難読化、動的計測検出、デバッガー検出、フック検出など）は、攻撃者が単純な実装を突破するサイドチャネル攻撃を実行するために必要なツールを積極的に無効化します。強化されたアプリに対してFridaを実行しようとする攻撃者は、難読化されたアルゴリズムに直面しているのではなく、攻撃者のツールを検出して対応するシステムに直面しているのです。これは難読化によるセキュリティではなく、多層防御です。 

議論2：「コードリフティングはWBCを無価値にする。」 

これは、セキュリティの専門家であるアーキテクトたちの意見です。彼らの主張はこうです。ホワイトボックス実装から生の鍵を抽出できなくても、抽出する必要はありません。アプリからホワイトボックスのバイナリデータ全体をコピーして、自分のサーバーで実行すればいいのです。これで、事前にパッケージ化された復号ツールが手に入ります。鍵の抽出は不要です。 

これは実際に有効な攻撃です。サーバー側の検証を行わない単純な実装に対しては、この攻撃は有効です。 

適切に実装されたデプロイメントに対しては、サーバー境界で失敗します。その理由は次のとおりです。 

不正にコピーされたバイナリは、あなたのアプリではありません。正規の未改変デバイスで実行されるアプリのようなランタイムセキュリティ状態を備えていません。アプリのセキュリティ強化ガードは、動作テレメトリを生成します。このクライアントは改ざん検出をトリガーしましたか？実行環境はクリーンですか？これは検証済みのランタイムですか？ 

攻撃者のサーバー上で実行される、不正にコピーされたホワイトボックスモジュールは、これらのチェックに合格しません。アプリケーション認識テレメトリ履歴がなく、動作証明も通過できません。サーバーは、クライアントの実行時セキュリティ状態に基づいて応答を調整することができ、またそうすべきです。不正にコピーされたバイナリのように見えるクライアントは、それに応じて処理されます。 

動作証明に加え、デバイスごとに固有の鍵交換が行われるため、あるデバイスのプロビジョニングから派生したホワイトボックス実装は、別のターゲットでは機能しません。抽出されたデータは、それが抽出された特定のサーバーとのやり取りに対してのみ有効であり、汎用的な復号ツールとしては機能しません。 

コードリフティングは、現実的な攻撃手法であり、それに対する適切なアーキテクチャ上の対応が必要です。その対応策とは、攻撃が存在しないふりをするのではなく、動作証明とデバイスごとの鍵の一意性を確保することです。 

論点3：「ハードウェアセキュリティによってソフトウェア保護は不要になる。」 

この主張は、プラットフォームの管理者やハードウェアベンダーから発せられたもので、StrongBox、TEEを基盤としたキーストア、セキュアエンクレーブが成熟した現在、ソフトウェアベースの暗号化保護は旧式の手法であるというものです。アプリケーションはハードウェアによる分離プリミティブに依存すべきであり、ソフトウェアによる難読化は不要です。 

パート1ではこの議論の技術的な根拠について説明しましたが、ここで率直に述べておきます。前提が間違っており、それは証明可能です。 

AndroidのTLSスタック（HttpsURLConnectionまたはOkHttpを介して標準的なHTTPS接続を行うすべてのアプリが使用するパス）は、BoringSSLとConscryptを介してECDH鍵交換をソフトウェアで完全に処理します。StrongBoxを経由せず、TEE Keystoreも使用しません。TLSセッションキーは、ハードウェアのセキュリティ機能に関係なく、すべてのAndroidデバイスのメモリ上に生のバイト列として存在します。 

これは理論上のギャップではありません。BoringSSLのソースコード、Conscryptのメンテナー間の議論、査読済みの研究論文にも記載されています。ハードウェアセキュリティは、特定のハードウェアベースの操作において、保存されている鍵を保護するのに非常に優れています。しかし、ほとんどのAndroidアプリで最も一般的な暗号化操作においては、ハードウェアセキュリティは適用されません。 

TLSの脆弱性以外にも、ハードウェアセキュリティはバイナリのリバースエンジニアリングを防ぐことはできません。攻撃者がプロトコルを理解して認証済みリクエストを偽造することを防ぐこともできません。アプリケーション層の認証機能も提供しません。ランタイムの動作上の脆弱性に対処することもできません。 

ハードウェアセキュリティは金庫のようなものだ。ホワイトボックス暗号化とアプリケーションの強化は装甲輸送車のようなもので、金庫から出て現実世界に参加するあらゆるものを保護する。金庫と装甲輸送車は互いに補完し合う関係にある。優れた金庫があれば装甲輸送車は不要になる、と主張するのは、それぞれの役割を誤解していることになる。 

正直な要約 

ホワイトボックス暗号は破られないものではありません。信頼できるベンダーは誰もそう主張していません。ホワイトボックス暗号が主張するのはコストの非対称性です。つまり、攻撃を成功させるために必要なコストと高度な技術を十分に高めることで、ほとんどの攻撃者がより容易な標的に移るようにし、実際に成功する攻撃には、Fridaのようなスクリプトキディではなく、国家支援型または高度に標的を絞った作戦に関連するようなリソースが必要となるようにするのです。 

WBCに対する学術的な批判は、単純なスタンドアロン実装に対しては妥当である。しかし、WBCをアプリのセキュリティ強化、動作証明、デバイスごとのキーの一意性といった要素と組み合わせた、適切に設計された展開には当てはまらない。 

これらは、当社のエンジニアリング、セキュリティ、カスタマーサクセスチームと共に徹底的に検証した3つの論点です。アプリ保護を検討中で、これらの論点がお客様の環境や脅威モデルにどのように適用されるかについてご説明をご希望の場合は、ぜひご相談ください。 今すぐデモをリクエストしてください