「CPUの高速化技術を悪用したRSA鍵盗聴が可能か」記事へのコメント

それなりにシリアスだとは思うけど

[Vorspiel (2391)]

アブストラクト [iacr.org]だけ読んでの話ですが，(以下引用)

We prove that a carefully written spy-process running simultaneously with an RSA-process, is able to collect during one \emph{single} RSA signing execution almost all of the secret key bits.

つまり，RSAによる暗号化処理を行っているのと同じマシンで解読プロセスを走らせられることが大前提，という時点で攻撃手段はそれなりに絞られるかと．
逆に言えば，例えば一人だけが使うPCのブラウザでRSAアルゴリズムを使ってSSL通信をやるとして，その暗号鍵がそのPC上でこの方法で破られるリスクは小さい(そもそもそ

Re:それなりにシリアスだとは思うけど

[Artane. (1042)]

私もPDFの本文を斜めで読んでの感じなんですが、
分岐予測やパイプラインの流れに支配されるデータの動き自体がMPU SETやOS依存になりますから、盗聴者は相手のシステム(MPUだけではなくOSやミドルウェアあたりのバイナリコードも入るかな？）を確定した上で盗聴プログラムをはりつける必要がある訳で。

そうなると、この方法に依存して、なおかつ安易に考えられる、「確実な」盗聴手段は二つになる訳で、

1.特定ユーザの特定プロセスを「ストーキング」する盗聴プロセスを対でマシン内に用意しておく
2.コンパイラの最適化過程で盗聴コードが混入されるように仕込んでおく

こうなると、「どっちもどっち」と言うか、SSLなどのSecure系のShared LibやOSのコンテキストスイッチャのコードを書き換えてバックドア仕掛ける方が簡単では無いか(^_^;と言う感じがするんですけど(^_^;
今回の「発見」の肝はバックドアの隠蔽度を非常に高められる…と言うことなんでしょうかねぇ?(^_^;

ざっと読んでみた話ですが

[superfox (31908)]

「分岐予測に使うキャッシュの保護に問題」というのは、別のユーザプロセスから間接的に分岐状態が予測出来てしまうことを指しているようです。スパイプロセスが１ビットの記録にかかる時間は暗号化／複合化の時間に比べてはるかに少なくてすむので

１）（なんらかの方法で）暗号化／複合化プロセスと同期を取ってスタート（分岐キャッシュをクリアしておく）
２）自前のプログラムで分岐を行い、前方／後方のどちらが「ヒット側」だったか（と暗号化／複合化プログラムのコードから）0/1を決定して記録
３）次のビットによる暗号化／複合化を待つ（分岐キャッシュを汚さないように注意）

…という感じなのだと思います。ただ、これだと同一キーで複数回結果を取って精度を上げないといけないと思いますが、今回のニュースでは「一回で良い」というのが大きいのでしょう。精度の高い同期の取り方が見つかったか、結果から精度の高いビット列予測が可能となったか、その両方か、ではないでしょうか。

# わかりきったキーをサービスにバンバン投げておいて、違うのが見つかったらそれを記録、とかもありそう。

もうちょっと考えてみましたが

[superfox (31908)]

あまりにもズバリ求められそうなので怖くなってきました…。

# あくまでも同一マシン上で実行出来ることが前提ですが。