CPUが何をしているかを伝えるのは本当に不可能ですか?[閉まっている]


24

コンピュータープログラマーは、x86の命令は完全に不透明であるというマントラをしばしば唱えます:Intelは彼らが何かをしていると言っていますが、NSAがRNGをバックドアするように命じた場合、だれもがそれを確認できるという希望はありません。それについて何でもします。

さて、コンピュータープログラマーはこの問題について何もできないと思います。しかし、電気技師はどのように攻撃しますか?電気技術者が、回路が仕様に記載されている操作を実際に実行し、他の操作を実行していないことを確認するために使用できる技術はありますか?


5
X線をxrayし、すべてを分析して、実際に何をしているかを確認する必要があります。基本的に、チップをリバースエンジニアリングし、すべての回路の機能を説明します。完全に非現実的です。
DKNguyen

7
ノイズと、ある日「十分に大きい」グリッチが発生する可能性がわずかにあるため、電気回路は正確な仕様を満たしていません。
アンディ別名

5
楽しい情報:これは、ラプラスの悪魔に漠然と関連しています。
ハリースベンソン

6
Intelのコンテンツデータベースから内部ドキュメントを盗む方が、最新の複雑なIntel CPUを1つでもリバースエンジニアリングするよりも簡単になります。
フォレスト

14
@Harperの態度は建設的ではなく、ハードウェアでバックドアを隠せないという主張は真実ではありません。
pjc50

回答:


14

この件に関して私が読んだ最高の論文は、2014年の「Stealthy Dopant-Level Hardware Trojans」(Becker et al)です。

変更された回路は、すべての配線層(すべての金属およびポリシリコンを含む)で正当に見えるため、トロイの木馬ファミリーは、粒度の細かい光学検査や「ゴールデンチップ」に対するチェックなど、ほとんどの検出技術に耐性があります。 Ivy Bridgeプロセッサで使用されるIntelの暗号で保護されたRNGデザインから派生したデジタルポストプロセッシングとサイドチャネル耐性のSBox実装の2つのデザインにトロイの木馬を挿入し、それらの検出可能性とセキュリティへの影響を調査します。

このペーパーでは、変更の方法、シリコンの検査で検出するのが非常に難しい方法、製造テストからそれを隠す方法、ハードウェア暗号RNGのセキュリティを低下させる方法、またはキー情報を漏らす方法について説明しています。 AES実装のパワーレールサイドチャネルを介して。

サイドチャネルは新たな関心分野です。インテルは、プログラムで使用されていなかったメモリからの情報のリークを引き起こす投機的実行に関連する問題に悩まされてきました。それは意図的な設計上の欠陥だったのでしょうか?言うのはほとんど不可能です。


サイドチャネルは、NSAに情報を送信するために何らかの送信機を必要としませんか?そうしないと、作業中に誰かが私のラップトップの電源レール電流を測定していることに気づくでしょう。
ドミトリーグリゴリエフ

24

電気技術者が、回路が仕様に記載されている操作を実際に実行し、他の操作を実行していないことを確認するために使用できる技術はありますか?

理論的には、はい、これは可能だと思います。ただし、複雑なCPUの場合は多くの時間がかかりますの時間と費用ます。また、設計を完全に理解および理解していない場合、アクティビティが「合法」であるかどうかを判断することはできません。

CPUは、多くのロジックセルで構成される「単なる」複雑なデジタル回路です。

金属接続を観察することにより、チップをリバースエンジニアリングし、設計を再構築することができます。これらの接続層の多くは、最大8層以上になります。

ロジックセルを認識するには、この分野の専門家が必要になります。その後、一部のソフトウェアは、それらがすべて接続されている方法を把握して、ネットリストを再構築できます。

ネットリストを作成したら、デザインを「認識」します。だからといって、それがどのように機能するかを知っているわけではありません!

特定の機能がデザインの2つのセクションをアクティブにしているのに、1つのセクションで十分なはずなので、疑わしいアクティビティが発生していると思われる可能性があります。ただし、設計では、操作を高速化するために知らない巧妙なトリックを実行します。

設計を知り理解することなく、あなたが描く結論はまだ間違っているかもしれません。CPUを設計したエンジニアのみが、すべての設計情報を持ち、CPUで実際に何が起こっているか、または何を続けるべきかを把握または推測できる可能性が最も高くなります。


77
CPUを設計したエンジニアだけが、進行中のすべてを知っています。私はたまたまこの業界で働いているエンジニアであり、この声明を非常に楽観的なものとして評価させてください:)
Eugene Sh。

18
いいえ、CPU設計者進行中のすべてを知ることはできません。そのレベルでの設計は合成ツールに依存しており、それらはHDL設計の動作を超える動作を注入する可能性があります。悪意のない例を挙げると、多くのFPGAツールを使用してロジックアナライザーでコンパイルできます。
クリスストラットン

9
「数十億個のトランジスタ」を備えたチップをリバースエンジニアリングするのは困難です。spectrum.ieee.org/semiconductors/processors/...
電圧スパイク

4
@Wilson複雑な回路(CPUを含む)には、それらの設計を所有している企業がそれらから利益を得たい(お金を稼いでいる)ため、一般に公開されていない多くのプロプライエタリ(および秘密、商標/特許でさえ)設計が含まれているためです。6502は古いデザインであり、貴重なデザイン情報はもうないので、誰でも利用できます。
ビンペルレキエ

3
@Bimpelrekkie:特許を取得していれば、当然のことながら秘密ではありません。それが特許のポイントです。一時的な独占のために秘密を交換します。
MSalters

9

さて、コンピュータープログラマーはこの問題について何もできないと思います。しかし、電気技師はどのように攻撃しますか?

バックドアを見つける良い方法はありません。ハードウェアバックドアを見つける1つの方法は、組み合わせまたは文書化されていない指示をテストすることです。これは、実際にこれを行い、x86ハードウェアで監査を行う人の良い話です。これは、チップをクラックすることなく実行できます。インテルの問題の1つ(他のチップについてはわかりません)には、実際にLinuxが実行されているプロセッサーがあるため、一部のプロセッサーでソフトウェアが実行されており、おそらくアクセスできません。

電気技術者が、回路が仕様に記載されている操作を実際に実行し、他の操作を実行していないことを確認するために使用できる技術はありますか?

ハードウェア自体を使用して機能をテストするには、テストする方法があります。x86には命令セットのドキュメント化されていない部分があるため、通常の命令でバックドアを導入するのは珍しいことです(バグが追加またはマルチ命令でバックドアを持っている場合など)。文書化されていない指示にあります。

通常の命令の機能をテストする必要がある場合は、命令の実行にかかる時間を見ることができます。命令を実行するのにかかる電力量を見て、予想とは異なるかどうかを確認します。


3
誰かがこれを行うことは不可能ではないが、そうは思わない。追加命令のような通常の命令をバックドアしたと言い、追加の命令を実行した場合、バックドアを開いたと言うことができます。その後、顧客はまさにその組み合わせを持つプログラムを開発し、彼らはそれを調べ、裏口を見つけ、誰もが怒ってあなたが訴えられます。文書化されていない指示(またはCPUに組み込まれたLinuxコンピューター)にバックドアを置く方がはるかに安全です
Voltage Spike

4
IMEはLinuxではなく、はるかに小さくシンプルなMinixを実行します。LinuxはMinixの存在に触発され、元々そのファイルシステムを使用し、ニュースグループで発表されましたが、当時はかなり異なっていて、今では非常にそうです。
クリスストラットン

5
@ user14717- 厄介な可能性は、ネイティブクライアントのような、投獄されたネイティブ実行可能ファイルのトリガーシーケンスです。しかし、データではなくコードでなければならない理由はありません。
クリスストラットン

5
@ laptop2d命令セットの理論的な文書が常に言っていることをCPUが実行しないバグ。通常、誰も訴えられません。たとえば、Intel第7世代Core i7ファミリードキュメントアップデートの正誤表セクションを読んでください。文書化されていない指示を使用すると、マルウェア研究者の警告がすぐに聞こえます。リズミカルなADDと適切なレジスタ間MOVの異常な組み合わせを使用しても、アラームがトリガーされる可能性は低くなります。
マーカスミュラー

6
@ laptop2d「CPU内に埋め込まれたLinux」ステートメントに驚きました。そのため、少し調査を行いましたが、Intel MEエンジンについてお話ししていると思います。まあ、それはCPU自体では実行されませんが、ノースブリッジチップセットで実行されます。そのことについて多くの誤報があったようです。itsfoss.com/ fact
dim

6

唯一の方法は、チップをレイヤーごとに取り除き、すべてのトランジスターを電子顕微鏡で記録し、それをある種のシミュレーションプログラムに入力して、実行を監視することです。

これは基本的に、入力と出力の測定から内部構造を再構築しようとするブラックボックスの問題です。内部構造の複雑さ、またはI / Oの数が些細なものを超えると、可能な内部状態の数が天文学的になる組み合わせの爆発があります。Googolのような数字が投げられる場所。


2
...そして、ソーシャルエンジニアリングを使用して設計を盗む方が簡単です:)
Eugene Sh。

8
いいえ。ここでの大きな間違いは、シミュレーションでは不十分だということです。正確なシミュレーションモデルを与えられたとしても、それをトリガーする方法がわからないため、慎重に隠された動作を見つけることはできません。
クリスストラットン

4
@ChrisStratton私はその間違いを呼び出すことはありませんまぶしいです。設計が物理的に通常の単純化を行うことに基づいていることは合理的な仮定です。たとえば、2つのメタライゼーショントレースを互いに近づけて、MOSFETゲートの状態を変化させるほど誘導的に結合しないようにすることです。それは、a)単純化がデザイナーが使用した物理モデルと一致しない場合、またはb)デザイナーがこれらの単純化の要件を非自明な方法で意図的に破ることによって意図的に何かを隠している場合にのみ誤りです。
マーカスミュラー

7
@ChrisStrattonああ、すみません、わかりました、私は今あなたのポイントを得ていると思います。CPUのデジタル/動作クロックモデルであっても、プログラマーの理解/仮定が単に当てはまらない場合を隠すのに十分複雑であると言います。それは本当だ。SPECTERにつながる影響を詳細に文書化することもできますが、ほとんどの人は、データまたはプログラムフローに関連する副作用をキャッシュすることを考えたことがありません。確かに!
マーカスミュラー

3
ありがとう:)あなたの議論は、ISAの正当性の正式な検証のトピック全体を取り戻します(「このISAは、実際に準拠CPUが非特権コードにRING 0特権を付与しないことを保証しますか?」)、HDL /このようなISA仕様に対するRTL(特にこのRISC-V CPUコア検証プロジェクトが気に入っています。)
マーカスミュラー

5

CPUが不正なことをしていないことを証明するのは非常に困難です。古典的な例は投票機です。それにあなたの投票のコピーを取り、後でそれをある独裁者に隠し出す単一のビットがあれば、それはある場所であなたのための生か死かもしれません。そして、数十億の中でそのようなものが1つもないことを証明するのはかなり難しいです。

物理的にチップを分離することを考えるかもしれませんので、不適切なワイヤ接続がないことを確認するのが実用的です。また、ネットワーク接続に別のチップ、または複数のチップを(異なるソースから)直列に配置して、適切な場所にのみ接続することを保証します。次に、投票が行われた後に電源を入れ直します。そして、そこに不揮発性ビットがないことを望んでいます。または不正なワイヤレス接続。しかし、あなたは自分の人生を信頼しますか?


5

データをNSAに送信するにはネットワークアクセスが必要になるため、ネットワークサービスを無効にしてOSを実行し、トラフィックのネットワークインターフェイスをチェックすることにより、このようなバックドアを簡単に見つけることができます。オープンソースOSの場合、完全なネットワークサポートを実行して、OSが正当にアクセスできるアドレスと一致しない宛先IPによる不正な接続を見つけることさえ可能です。

データ送信を伴わないRNGに基づくバックドアの有用性は非常に限られています。CPU RNGが唯一のエントロピーソースでない限り、このようなバックドアが攻撃者に利点を提供する一方で、同時に明らかではない可能性は実質的にゼロです。ラッセルのティーポットが存在する正当な理由がないにもかかわらずそこにあると主張しない限り、ハードウェアRNGバックドアにも同じ議論を適用できるはずです。


5
したがって、敵はハードウェアトロイの木馬を作成して隠すための時間、お金、スキルを持っていると想定しますが、最初に行うのはtelnet www.nsa.govですか?これは非常に単純な視点のようです。
エリオットアルダーソン

1
NSAが脆弱性を隠していた場合、はい、人々が使用したrdrandrdseed、IntelがPRNGシードの唯一のエントロピーソースとして使用したことを期待していました。Linux(カーネル)はを実行しないことを選択しました/dev/randomが、glibc / libstdc ++のcurrent std::random_device rdrand、を開くのではなく、実行時に利用可能な場合にのみ使用します/dev/randomgodboltを使用した標準ライブラリ呼び出しへのステップ
Peter Cordes

@ElliotAldersonそれでは、あなたの視点は何ですか?誰かが貴重なデータをどこかに送信せずに盗むことができるのでしょうか?
ドミトリーグリゴリエフ

@PeterCordes std::random_deviceは、暗号的に強力なRNGではありません。C ++標準では、PRNGを使用して実装することができ、毎回同じシーケンスを効率的に返すため、誰も暗号化に使用しないでください。
ドミトリーグリゴリエフ

ああ、私はそれが良いことであるという保証がないことを忘れていました、xD。これは、ある多くの実装には良いが、MinGWのは、プラットフォームが可能であるとして、それはライブラリの主な目的を破って、良い品質の乱数としてあなたを与えることを設計意図に傑出した例外です。(あなたが言うように、これ暗号ではなく、他の目的のためにPRNGをシードします)。( mingw gcc4.8.1でstd :: random_deviceを実行するたびに同じシーケンスを取得するのはなぜですか?)これは、エントロピーのないプラットフォーム(最小限の組み込みデバイス)では受け入れられますが、x86 Windowsでは受け入れられません!
ピーターコーデス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.