サイドチャネル攻撃から得た教訓

クラウドインフラストラクチャは、アプリケーションを構築するためのプラットフォームを実現させた一方、開発者にはスタック内の至る所でアプリケーションを構築できるコンポーネントを提供しています。こうした自由が生まれることで、これらのプラットフォームを使用してどのアプリケーションを一から構築するのかという課題と、どのアプリケーションをサービスとしてサブスクライブするのかという課題の間で考えるべきことが増えます。プラットフォームの完全な統合の確保は、設計時に構築とサブスクライブの間でどう線引きするか見極める上で、検討が必要な重要な課題です。

「独自の暗号を作成するな」という有名な決まり文句があります。これはこれで頼りになるアドバイスですが、これには「独自のプラットフォームを作成するな」という言葉が続くべきでしょう。プラットフォームの構築作業は、非常に多くの組み合わせが伴う可能性があり、これらの間に生じる攻撃対象領域では、巧妙な攻撃者による悪用の機会が生まれます。攻撃者は非常に巧妙です。プラットフォームのカスタマイズは「一度設定すれば、後は何もする必要がない」というものではなく、絶えず進化しています。コンピューティングサービスがキャッシュやネットワークサービスと事前に統合されている Fastly のようなプラットフォームは、変化し続けるこれらの攻撃に対処するのに最適です。 

このブログ記事では、発生しうるトラブルについて説明します。予測が困難なセキュリティ設計の弱点は、主にサイドチャネル攻撃によって顕在化します。内部的には安全なアルゴリズムが驚くべき方法で環境とやり取りすることで脆弱性が生じ、攻撃者はアルゴリズムの機密部分を推測できるようになるのです。

セキュリティ意識の高いユーザーを長年悩ませているサイドチャネル関連の悪用のうち、一般的なものや特殊なものをいくつか紹介するのは、楽しんでもらえるうえに役に立つと長年考えていました。全体を通して基本的な概念をご理解いただけるよう、大まかに概要を解説していきます。セミナーを最後までお楽しみいただいた方は、リンク先から詳細もご確認いただけます。

簡単なウォームアップ

まずは、1980年代まで遡って、古典的な手口を見ていきましょう。Van Eck Phreaking は、今となっては歴史的興味の対象となることが多いですが、サイドチャネル分野を説明する上では最適な例です。この攻撃が主に優れているのは、コンピューターのモニター上で画像を描画する際の副作用として、描写されているものが予測可能な形で EMF (起電力) を発生させることを見抜いた点です。大半の人々は、EMF を無線通信の電波として認識していますが、しつこい攻撃者ならこの電波を変換して、画面自体をある程度まで再現できます。窓のない室内に配置された、ネットワークに接続されていないコンピューターの場合でも、光線を発するモニターの副作用により、悪用可能なサイドチャネルが形成されます。このような対策の不合理さについて深く考えてみると、この問題の複雑さが本当によくわかります。

これらの副作用は、予測するのが腹立たしいほど難しく、時が経つにつれ、さらに巧妙になっていきます。最近の私のお気に入りのひとつは、実のところコンピューターのセキュリティというより物理的なセキュリティに関する副作用で、今年の夏に公表されました。研究者は、錠に挿入される鍵の音声録音を使用して、この録音からこの鍵と一致する鍵を 3D プリントすることに成功したのです。この鍵の音は、サイドチャネルとなりました。誰もがポケットの中やキッチンカウンターの上にマイクを用意してこの音を録音しているわけではないのが、せめてもの幸いです。

時間との勝負

時計もサイドチャネルを生み出す要因となります。そして、セキュリティアルゴリズムにとって予想外の情報が偶発的に暴かれるのも不思議ではありません。Raccoon Attack は、前例が数多くあるこうした攻撃のカテゴリに最近加わった攻撃です。 

この攻撃は、TLS 1.2 以前のかなり深部にある欠陥を悪用します。これは、00314159 のような数字を画面に表示する前に先頭のゼロを除去する場合と同じように、共通バリアントの仕様上、ハッシュ化の前にシークレット値の先頭のゼロを取り除く必要があります。これにより、タイミング攻撃を受ける余地が生じます。00314159 よりも 314159 の方がハッシュの計算は簡単 (かつ高速) であるため、攻撃者は、時計を見ながら TLS の速度を測定するだけで、先頭の1つまたは2つのゼロを推定して、シークレット入力に関する情報を入手できます。

ここ数年、あらゆる種類のキャッシュがタイミング分析型サイドチャネルの欠陥の源泉となっています。キャッシュには、今後の計算をスピードアップするために過去の計算の結果が格納されます。残念なことにこれが、お互いの履歴を知るべきでないエンティティ間での履歴漏えいを助長してしまいます。 

Web ブラウザのキャッシュの例から説明するのがわかりやすいでしょう。ブラウザの重要な役割のひとつは、異なる Webサイトを分離することです。サイト A の閲覧履歴はサイト B とは何の関係もありません。しかし、サイト B は、サイト A のサブリソース自体を読み込んで、読み込みにかかる時間を観察することで、サイト A がキャッシュ内にあるかどうかを確認できる可能性があります。読み込み時間が非常に短ければ、サイト A がキャッシュ内にあり、ユーザーが以前にそこにいたことが暗に示されます。つまり、キャッシュのタイミングがサイドチャネルになるのです。この結果、より多くの種類のキャッシュに「第一当事者」(ロードをトリガーした Webサイト) により二重鍵がかけられることによって、プライバシーは強化されますが、キャッシュの有効性は弱まります。

キャッシュエントリによってフィンガープリントが残るというこの概念は、キャッシュが透過的にパフォーマンスを向上させるといった、まさに有用な処理装置であるという理由から、レイヤー全体における一種の固有の概念となっています。この透過性により、情報が漏えいします。この問題を抱えているのは、ブラウザなどのクライアント側のアプリケーションだけではなく、サーバー側のマルチテナントアーキテクチャも同様です。Pythia は、データセンターやクラスター化されたコンピューティングで効率的にストレージへアクセスするために使用される、RDMA ハードウェア内の透過的なページテーブルのキャッシュを悪用します。この攻撃には、一般的な戦略が用いられます。互いに分離されていると想定される2つのサービスが、独自のリクエストに対するレスポンスのタイミングを慎重に測定し、相手方のサービスのアクションによって何らかの情報がキャッシュされていたのかを推測することで、互いの履歴を詳しく調べることが可能になります。

果てしない議論

前述のとおり、これらの問題の多くは、テクノロジーを生み出すために必要な抽象概念に根ざしています。このため、システムの設計者としては、実際のハードウェアでスタックを調べ上げれば安心感を得られるかもしれません。CPU、チップ、RAM など、古き良きノイマン型アーキテクチャに打ち込むこともできます！しかし、それは単なる幻想にすぎません。それらは仮想マシンかもしれないし、独自のサブプロセッサーを持っているかもしれません。変更可能なマイクロコードが使用されているかもしれないし、独自の複雑さをより管理可能なものにするためだけに重要な抽象概念を含んでいるかもしれません。まさに、果てしない議論です。このように、統合の問題は尽きません。ここで CPU、RAM、ネットワークなどの基本的な部分に焦点を当ててみましょう。

これまでの流れから、Spectre で有名な過渡的実行攻撃の大惨事について説明します。Spectre に関しては、キャッシュに残されたフットプリントやタイミング分析に起因しているなど、さまざまな情報が広く知られています。Spectre は、これらを CPU の内部動作に関連付けることで、さらに脅威を増すのです。プロセッサーのコアロジックの欠陥は、攻撃者にとっては格好の贈り物です。投機的実行が失敗したときに、キャッシュは Spectre クラスの攻撃で突然変異します。これは CPU が、実際に起こったこと以外のことが起きた場合にどうなるかを、それが実際に起こった場合に備えて計算することを意味します。 

「シュレーディンガーの猫」のように紛らわしい話ですが、問題は、この CPU レベルの推測により、プロセッサー独自のキャッシュに、前述のその他のキャッシュ攻撃と同様、タイミング攻撃を介して間違ったコードを有効にできるような証拠が残されることです。これは単なる攻撃にとどまらず、進化し続ける全体的な問題であり、今すぐにでもこの問題を軽減するための思慮に富んだ全体的な深い対策が必要です。

サイドチャネルの多くは、本来読み取ることができないデータを攻撃者に知られることですが、関連するアプローチにはデータの書き込みが可能なものもあります。Rowhammer が典型的な例です。Rowhammer では、攻撃者は、意図的にひとつの RAM を集中的に実行することで、電気インパルスが周囲の RAM に影響を及ぼすようにします。この際、実行が安全かどうかに関するオペレーティングシステムやアプリケーションによる審議は一切行われません。これは、周囲の RAM へのアクセスがサイドチャネルに似た悪用のルートとして機能する障害攻撃であるとみなされる場合もあります。

ここで、別の攻撃についても触れたいと思います。なぜならこれは、特殊なサイドチャネルの使用が確認されている、非常に巧妙な手口だからです。この攻撃について考える度に、自分が把握していると思っていることも先入観を持たず向き合う必要性を思い出します。この攻撃は、攻撃者と被害者の間の共有キャッシュのようなありふれたものに頼るのではなく、被害者の自宅のワイヤレスルーターを介して両者が使用する可能性がある共有ネットワークパスに着目したのです。 

TCP は通常、パス上攻撃に対して安全ではなく、パス外攻撃に対して堅牢であると考えられています。このため、攻撃者がクライアントとサーバー間のトラフィックを見ることができない (トラフィックがトランスポートパス外にある) 場合、接続を操作できないと想定されています。パス外で利用できない悪用可能なシークレットは、TCP シーケンス番号と組み合わせた48ビットのクライアントポート番号です。攻撃者がこの情報を入手すると、好きなデータを簡単に注入できるだけでなく、パス外接続を意のままに終了することさえできます。 

この攻撃の鍵となるのは、攻撃者が制御しているシークレット詮索に対して、攻撃者が正解か間違っているか、それとも正解に近いかどうかによって、被害者が異なる大きさのレスポンスを行う点です。通常、パス外攻撃では異なるレスポンスを見分けることはできないため、この点は重要ではありません。しかし、攻撃者が攻撃と平行して被害者と別の接続を確立した場合、共有しているもの、すなわち、WiFi ルーターに隠されたメッセージの影響を観測できます。パス外チャネル上のメッセージサイズが大きければ、パス上チャネル上のメッセージの速度を観察可能な形で低下させることができます。これは、推測がどのカテゴリに分類されるのか見当をつけるには十分な情報となります。これにより、完全に一致するものを見つけるためにスペース全体を探さなくとも、攻撃者は推測ゲームを楽しみつつ、シークレットスペースを関係のあるものとそうでないものと二つに素早く分けることができます。非常に賢いやり方です！

学んだこと

これらはすべて、DIY プロジェクトに取りかかるときは必ずしも明らかではない可能性がある事柄の例です。これらの例は (起こり得ることのごく一部にすぎませんが) すべて極めて巧妙であり、注意を払う必要があります。私はどちらかと言えば、読者にはアプリケーション構築の創造的な部分に気を配り、絶え間ない労力を必要とすることのない、その形式のアプリケーションをサポートするよう意図され、スケールされ、維持されている統合エッジクラウドプラットフォームを活用してもらいたいと考えています。 

これまで説明してきた欠陥やその他の脆弱性からアプリケーションを保護するのは、不連続なイベントというよりもプロセスに近いです。アプリケーションのコンテキストを慎重に検討し、明らかになったことを記録し、可能であれば対策を講じ、時間とスペースおよびデータ定義を検討する ABI を定義し、絶えず見直しと手直しを行います。「一度出荷すれば、後は何もする必要がない」という態度では、時間が経つにつれて脆弱な状態に陥ります。注意を怠らないでパッチを適用することは重要ですが、そうしたとしても、悪用の中核にある環境的な組み合わせを見落とす可能性があり、個別コンポーネントの開発者にも問題の一部しか見えません。プラットフォームのカスタマイズとは、かかりきりになることが必要な仕事なのです。