オープンソースソフトウェアのソースコードを徹底的に調べてバックドアをチェックすることは理論的には可能ですが( Ken Thompson hack を無視して)、 Electrical Engineering について十分な知識を持っていますおそらく、特定の監視可能な回路が何を実行できるか、どのようにして(少なくとも意図的に)集積回路が本来の動作を実行していることを確認できるでしょうか?
例として、TPMチップが実際に地元のセキュリティ機関に電話をかけないようにするにはどうすればよいでしょうか。統合GSMモデムまたはブリッジイーサネットポートを介して?
そして、回路図がオープンハードウェアである場合でも、製造元(おそらく、個々のチップの極秘製造を監督させない)が独自の「最適化」を追加しないことをどのように確認できますか?
理論的には、チップの機能を確認するには、チップを分解してリバースエンジニアリングします。実際には、これはほぼ不可能です。実際には、ソフトウェアの場合でも、実際のソースコードがあります、あなたがコードがあなたが信じていることを本当に常に実行することを保証することはできません(そうでなければ、バグのないコードを生成することができます)。
これは新しい問題ではなく、諜報機関(オキシモロン)が何度もそれに遭遇しました。 CIAがホワイトハウスのコンピューターに中国が管理するバックドアがいっぱいでないことを確認したい場合、彼らは何をしますか?まあ、彼らは確かに何かのためにチップを見ています明白(統合されたGSMモデムは最小サイズを持っています;それはX線で見ることができますチップのスキャン)。ただし、最終的には、Julius Caesarの時代からその効率を示してきた古典的な調査手法に依存しています。すべてのバックグラウンドチェックを使用して、各コンポーネントのソース、コンポーネントの設計者、製造者、輸送者などを追跡します。関係者、および手順の監査。これは、設計、仕様、開発者の背景、および開発方法が検査される「認定されたソフトウェア」(例 Common Criteria )とそれほど変わらない。
それを確認する1つの方法は、ハードウェアは悪ではないということです-人々は悪です。ハードウェアではなく、人をチェックしてください。
CIAの場合、これは彼らが中国本土のチップよりも台湾のチップをずっと好むことを意味します。
明確にするために。
ここには2つの異なる質問があるように思われます。「製造元を信頼する必要がありますか?」および「TPMは悪意がありますか?」.
2つ目のコメントについては、次のとおりです。
TPMはそのようなことを実行できないだけで、パッシブ/ダムデバイスです。通常、標準バス(LPC)を介して接続されます。 LPCはLDRQ#割り込みを介してDMAアクセスできますが、TPMはその割り込みにアクセスできません。つまり、DMAエンジン自体も他のデバイスと通信することもできません。TPMが引き出す可能性のある攻撃は、サイドチャネル攻撃など、受動的でなければなりません。
Intelによって実装された新しいTPMは、実際にはプラットフォームコントローラーハブ(以前はメモリコントローラーハブ、別名ノースブリッジ)内でアプリケーションとして実行されています。それらは Intel Management Engine を除いて [〜#〜] amt [〜#〜] の上で実行され、vProフラグシップの下にバンドルされています。 IntelのMEは、完全に別のCPU(メインCPUではない)で実行されており、システムメモリへの完全なメモリアクセス(Intel UMAを介して)があるので、リング-3で実行されているオペレーティングシステムと見なすことができます。したがって、誰かがそれらのiTPM(統合されたTPM、実際にはME上で実行されているすべてのアプリケーション)がアクティブであり、あなたが説明するようなことを行う能力を持っていると主張するかもしれません。
その時点で問題は、誰かがインテルME/AMTをバックドアできるかどうかです。はい、可能です。可能性は低いですが、可能です。 exploit it する必要があります。または、ME署名鍵が必要です。また、最初の質問に戻りますが、メーカーのバックドアインテルME/AMTはありますか?同じ答え。
pSある時点で、BadBIOSの背後にある物語は、これが実際に起こっているのかどうかを疑問視するようになりました(つまり、非常に強力で移植可能なエクスプロイト)。
私は数年前(実際には現在10人)のBlackhatでTrusting Trustを再訪した講演を行いました: http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-maynor。 pdf
その後、2005年にLinux Journal向けに書かれた記事を書きました: http://www.linuxjournal.com/article/7839
私はこのトピックを約15年にわたって調査してきましたが、Thompsonの記事の要点は、環境内のすべてのコンポーネントを検証しない限り、できないということです。ロジックは、ハードウェアまたはソフトウェアのトロイの木馬の一部に、実際には逆シェルを実行する疑わしいバイナリBLOBが含まれている可能性があることを示していますが、はるかに微妙な場合があります。 2005年の記事では、strncpyのスタブを作成し、実際にstrcpyを使用する例を取り上げました。コンパイル後のシンボルを見ると、すべてが正しく表示されますが、strncpyによってバッファオーバーフローが停止したと思われる場所は、攻撃ベクトルになります。
ハードウェアに関して言えば、バイナリで文字列を実行することはできないため、このプロセスはさらに難しくなります。 IPの懸念と法律の組み合わせにより、モバイルデバイスなどの下位操作の多くが秘密にされます。ジェイルブレイキングはこのブラックボックスを開くことにある程度の成功を収めましたが、1トンではありませんでした。
IPhoneに反応して書いたこのブログをチェックしてくださいSMS 2009年の脆弱性: http://blog.erratasec.com/2009/07/heres-how-we-do -that-voodoo-that-we-do.html#.UtVBoHk6JFw このバグに対するひどい反応は、AT&TがSMS iPhoneの計画を無効にすることであり、人々は感じた安全です。実際には、SMSプランをお持ちでない場合でも、携帯電話から特別なSMSネットワークチューニング、タワーアップデートなどのアップデートを受け取ります、など...デバイスのバックドアは、タワーのアップデートを電話にプッシュするだけの簡単なものかもしれません。近所のボンネット内のIMSIカテーテルは公式のキャリアタワーであり、問題ありません。
つまり、すべてのコンポーネントを製造し、すべてのソフトウェアを記述し、電話会社を所有し、デバイスがバックドアされているかどうかわからない調査のために有利な法律を通過できる場合を除きます。
「どうやって信頼するの?」には完全には答えられませんが、少なくとも役に立つアイデアを投稿したいと思います。他の回答ですでに述べたように、明らかに2つのオプションがあります:
これらの提示されたオプションは、完全な信頼のレベルをもたらすというそれらの属性に優れていますが、それらは明らかに実行不可能です。時間と物質的な努力の点で、信頼に支払う代償は莫大です。
提示された2つのオプションの限定的な代替手段として追加したいアイデアの一部は、快適さや機能性を犠牲にすることに依存する場合があります。アイデアの論理は次のとおりです。
これをアブストラクトからより実用的なレベルに引き上げるために、例を挙げて説明します。
質問で提案されているように、攻撃者にデータを送信するためにGSM /通信を使用するシステムにmalicouis ICがあると想定します。私たちが3を満たし、ICの機能性が通信に依存せず機能的に分離可能であり、通信デバイスから物理的に分離可能である場合(利用可能なGSM /モデムは挿入されたUSBデバイスのみであると想定)、信頼できます。 USBデバイスを物理的に接続せず、機能的に接続することにより、ICがデータを攻撃者に送信しないようにします。
ソフトウェアのように(たとえば、LSMのようなapparmorで見られるように)アイデアは、分離/分離によって各ICを必要な機能的に必要な接続のみに制限することです。
複雑なICを製造することは不可能かもしれませんが、ハードウェアを介してオンデマンドで(つまりソフトウェアを介して)接続するだけで、現在のニーズに応じてコンポーネントを切り替えるはるかに複雑なICを作成することははるかに可能です。したがって、利用可能な接続性を制限することにより、ある程度の信頼を得ることができます。