web-dev-qa-db-ja.com

AMDのセキュアプロセッサの機能について何がわかっていますか?

"Intel x86は有害と見なされます(第4章はMEについてです)" Joanna Rutkowskaによる調査論文を含む、IntelのMEの機能についてかなりの量の調査結果を見つけましたが、 AMDのセキュアプロセッサ(以前はPSPと呼ばれていました)に関する情報を見つけるのが難しくなりました。

AMD PSPはMEよりも「同じくらい悪い」または「より悪い」と主張する人もいます。 (たとえば、PSPについて多くのことを主張する oft-cited page がlibrebootプロジェクトのサイトにありますが、それらの主張の多くの独立した確証はまだ見つかりませんでした。librebootの視点は実用的なセキュリティ研究者とは明らかに異なります。)

最終的に私が答えたいのは、AMDが工場でCPU/APUを事前にバックドアしていないと脅威モデルが想定している場合、将来のバックドア(「リング- AMDまたはサードパーティのいずれかによるIntelで実証された3つのルートキット」、およびその脅威は緩和可能ですか?

しかし、主観的ではありませんが、セキュアプロセッサですでに見られている機能と、それがMEについて知られているものとどのように比較されるのかを知りたいのです。

  • IntelのAMTと同様のリモート管理に使用されていますか?
  • 独自のネットワークスタックがあることが知られていますか?
  • ソフトウェアの更新が可能なファームウェアはありますか?そのファームウェアはどのように保護されていますか?
  • それを標的とした既知のエクスプロイト、またはファームウェアで行われた公開調査はまだありますか?
  • AMD PSPの状況は、Intel MEの状況よりも「良い」または「悪い」とはどのような理由で言えますか?
20
mikkros

したがって、直接メモリアクセスを提供し、本質的にプロセッサに代わって処理を実行するものは、コンピューティングプラットフォームに導入する脅威表面の他の完全なセットです。したがって、脅威の表面は同じではないとしても、似ていると思います。

PSPが動作することになっている方法は、多くの点でMEを模倣しますが、主な焦点であると思われる暗号化操作にも参加します。現在話題になっているプラ​​ットフォーム上の攻撃はまだありません。

そのように活用される可能性が高いと私に思わせる部分はティーザーです:盗難防止ソフトウェアはPSPが有効にするはずの機能の1つです...これのほとんどすべてのケースが利用されますMEまたは不器用なUEFIシムの場合、これが同じであることを意図している場合は、PSPシステムオンチップの常駐/オフライン管理機能を想定しています。

ネットワーキングスタックと直接通信する仕様はありませんが、そのために残されたスタブである可能性がある「IO」と対話するためのコールアウトがあります。

また、AMDが10年以上にわたって使用されている主要な競合他社の機能を無視した場合も、私は驚きます。しかし、それは決定的ではありません。

4
Ori

同じ問題に興味があり、予備調査を行いました。私はいくつかの質問に答えようとしますが、AMD以外のエンジニアとしては確信が持てません。

ソフトウェア更新可能なファームウェアはありますか?

はい、そうです。このファームウェアは、AMDからUEFIファームウェアベンダーに配布されるバイナリBLOB [〜#〜] agesa [〜#〜] (AMD Generic Encapsulated Software Architecture)の一部です。 リリースノート が付属しているコアブートにも、PSPセクションでは、さまざまなプラットフォームのPSPバージョン番号について説明しています。これは、それらが更新可能であることを示唆しています。

そして、そのファームウェアはどのように保護されていますか?

ファームウェアコードを抽出できず、どのように保護されているのかわかりません。考えられる兆候は、SMUファームウェアがどのように保護されているかです:ヘッダーにHMAC-SHAがあり、秘密鍵が隠されています( Rudolf Marekのプレゼンテーション を参照)。

IntelのAMTと同様のリモート管理に使用されていますか?

それが何に使用されたかを知ることは不可能です。ただし、私の調査結果は、リモート管理が(IntelのMEとは異なり)主な目的ではないことを示唆しています。私が見つけたもの:

  • PSPはCPUのブートプロセスで役割を果たします(これはよく引用されるため、繰り返さないでください)。

  • PSPは、秘密鍵管理用のfTPM(ファームウェアベースのTPM)APIを提供します。

  • PSPはSEV(Secure Encrypted Virtualization API)のキー管理を行いますVMメモリ暗号化。これは API to the PSP を使用します。詳細については、 a LinuxパッチRFC サポートを導入します。

  • PSPは、暗号オフロードに使用できます。これに対するサポートは、Linuxカーネルのdrivers/crypto/ccpにあります。

ただし、コードを動的にロードできるという証拠があります。

  • コアブートでの「トラストレット」の読み込み。さらなる分析のためのポインター: corebootのPSPライブラリ
  • Linuxカーネルのdrivers/gpu/drm/AMD/amdgpu/psp_gfx_if.hにあるコメント「Trusted ApplicationバイナリをPSP OSにロードするコマンド」。これは、GPUダイ上の別のPSPを処理する可能性がありますが、それはAMDコードであるため、オーバーラップする可能性があります。

独自のネットワークスタックがあることが知られていますか?

いいえ、ネットワークスタックをストック構成にすることはわかっていません。すべてのAPIは、外界ではなく、CPUに面しているようです。

これらのプロセッサが「エンタープライズユーザー」やDRMベンダーのあいまいな仕様でどのように設計されているかを知っていると、ネットワークスタックでリモート管理モジュールをロードできる可能性があります。しかし、私が見つけたものは、それを最終的に証明するものは何もありません。

それを標的とした既知のエクスプロイト、またはファームウェアで行われた公開調査はまだありますか?

fTPM APIの公開脆弱性 があります。ファームウェアに関する公開調査は見つかりませんでした。

AMD PSPの状況は、Intel MEの状況よりも「良い」または「悪い」とはどのような理由で言えますか?

Intel MEとは異なり、少なくともAMDセキュリティプロセッサは、(私たちの知る限り)そのままではリモート管理APIを提供しません。それをネットワークを聴くバックドアに変えるには、OSソフトウェアが追加のモジュールを提供するか、場合によっては妥協する必要があります。

しかし、私たちが発見したように、それはブラックボックスであり、公的な研究はほとんど行われていません。暗号化では、システムは頻繁に分析され、脆弱性が見つからなかった後に信頼を得ます。あいまいさによるセキュリティは受け入れられません。残念ながら、ケルクホフスの原則にセキュリティプロセッサを適用する人はいません。

4
wump