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.
Moreover, despite sophisticated hardware-assisted partitioning methods such as memory protection, sandboxing or even virtualization, SBPA attacks empower an unprivileged process to successfully attack other processes running in parallel on the same processor.
それなりにシリアスだとは思うけど (スコア:5, 参考になる)
逆に言えば，例えば一人だけが使うPCのブラウザでRSAアルゴリズムを使ってSSL通信をやるとして，その暗号鍵がそのPC上でこの方法で破られるリスクは小さい(そもそもそのPC上でそんなやばいプロセスが動作できてしまう環境自体が問題)と考えられます．
勿論，
から推察するに，マルチユーザ環境において他人のRSA解読の様子が覗けてしまうとかいうあたりはかなり問題．Re:それなりにシリアスだとは思うけど (スコア:4, 参考になる)
分岐予測やパイプラインの流れに支配されるデータの動き自体がMPU SETやOS依存になりますから、盗聴者は相手のシステム(MPUだけではなくOSやミドルウェアあたりのバイナリコードも入るかな？）を確定した上で盗聴プログラムをはりつける必要がある訳で。
そうなると、この方法に依存して、なおかつ安易に考えられる、「確実な」盗聴手段は二つになる訳で、
1.特定ユーザの特定プロセスを「ストーキング」する盗聴プロセスを対でマシン内に用意しておく
2.コンパイラの最適化過程で盗聴コードが混入されるように仕込んでおく
こうなると、「どっちもどっち」と言うか、SSLなどのSecure系のShared LibやOSのコンテキストスイッチャのコードを書き換えてバックドア仕掛ける方が簡単では無いか(^_^;と言う感じがするんですけど(^_^;
今回の「発見」の肝はバックドアの隠蔽度を非常に高められる…と言うことなんでしょうかねぇ?(^_^;
ざっと読んでみた話ですが (スコア:3, 興味深い)
１）（なんらかの方法で）暗号化／複合化プロセスと同期を取ってスタート（分岐キャッシュをクリアしておく）
２）自前のプログラムで分岐を行い、前方／後方のどちらが「ヒット側」だったか（と暗号化／複合化プログラムのコードから）0/1を決定して記録
３）次のビットによる暗号化／複合化を待つ（分岐キャッシュを汚さないように注意）
…という感じなのだと思います。ただ、これだと同一キーで複数回結果を取って精度を上げないといけないと思いますが、今回のニュースでは「一回で良い」というのが大きいのでしょう。精度の高い同期の取り方が見つかったか、結果から精度の高いビット列予測が可能となったか、その両方か、ではないでしょうか。
# わかりきったキーをサービスにバンバン投げておいて、違うのが見つかったらそれを記録、とかもありそう。
もうちょっと考えてみましたが (スコア:1)
# あくまでも同一マシン上で実行出来ることが前提ですが。
HyperThreadの脆弱性のときも思ったんですけど (スコア:1, 興味深い)
ループ→常に最大（最悪）の回数ループするようにする
分岐→分岐条件に関わらず常に演算を行い、条件付代入（x86ならMOVcc）などで切り分けるようにする
として、入力が何であれ、常に同じ命令群を実行するようにコードを書くしかなさそうな気がします。
（条件付代入がない命令セットもありますが、ビット演算などの組み合わせで代用できますし）
ただそうすると、タダでさえ重い処理が常にワーストな時間がかかるようになるのと、
分岐命令を生成させないように高級言語で記述するのは面倒という問題がありそうですが。
次はSpeedStep/Cool'n'Quiet系で盗聴かなと思ったAC
実際のところ (スコア:3, 参考になる)
S = ((A*B)/R) mod N
の最後（mod N）の条件分岐が注目されているそうで、openSSL のコードは
openssl-0.9.8d/crypto/bn/bn_mont.c
の int BN_from_montgomery() にあるこの部分だと思います。
if (BN_ucmp(ret, &(mont->N)) >= 0)
{
if (!BN_usub(ret,ret,&(mont->N))) goto err;
}
> ループ→常に最大（最悪）の回数ループするようにする
> 分岐→分岐条件に関わらず常に演算を行い、条件付代入（x86ならMOVcc）などで切り分けるようにする
前者が blinding というものではないのでしょうか？（私も詳しくはない）。blinding と randomization techniques は totally useless [iacr.org] とあります。後者もサイクル数が違ったりすると付け込む隙があるかもですね。
Re:実際のところ (スコア:2, 興味深い)
なるほど、blindingというのですか。
英語も不勉強なもので（笑）、確信はないのですが「SBPA Attack に対しては blinding と randomization techniques は totally useless」ということではないのですかね。
盗聴されないための必要条件だけど、SBPA Attackに対しては無力なので十分条件にはならない…という意味に読み取れたのですが。
> 後者もサイクル数が違ったりすると付け込む隙があるかもですね。
今時のCPUの条件付代入は大抵1クロック命令なのでおそらく大丈夫かと思われます。
ただ結局はCPUごと（アーキテクチャごとではなく）に安全かどうかを確認する必要があるんでしょうね。
しかし、面倒ですね。
CPUによっては乗算命令やシフト命令なども値によって処理にかかるクロック数が違うので使用できない可能性が。
暗号化ライブラリコーディング規約（C言語版）はこんな感じですかね。
（思いつきで書いているのでテキトーですが）
1. システムコール・外部ライブラリの呼び出しは原則使用しないこと
（必要な場合はリーダーに申請して、理由と使用許可番号をコメントに記述すること）
2. while/do-whiteループは原則使用しないこと
（可変長の入力データに対応するためなどで使用した場合はリーダーに申請して、理由と使用許可番号をコメントに記述すること）
3. forループの初期値・増分値・終了値は定数のみとし必ず固定回数のループとすること
（暗号ビット長に対応するなどで可変にしたい場合はリーダーに申請して、理由と使用許可番号をコメントに記述すること）
4. if分岐/switch分岐/三項演算子（?:）は使用しないこと
代わりに処理時間固定三項演算マクロを使用すること
5. バージョン管理サーバにコミットする前にビルドを行い、対象とするCPU用の処理時間可変命令チェックツールで処理時間が可変である命令が生成されていないことを確認すること
6. 各コードのバージョン履歴には「チェック済み対象CPU」「ビルド環境情報」を記述すること
おそらくこれでは不足していると思いますが、これだけでも面倒ですね。
テストも入力値によって異なった動きをしないか確認する必要があるわけですし。
（エミュレータを作ってとりあえずの1次確認するのが楽かな？）
こんなプロジェクトに参加したくないと思ってしまったAC
PS
投稿制限があるのでここに書いてしまいますが（アカウント作れよ）、#1061625 [srad.jp]のコア数の話に関して。
コア数に対して十分なスレッドを起こしてすべてで盗聴させてその結果を統合すれば推測できそうな気がしますが、どうでしょう。
Re:ざっと読んでみた話ですが (スコア:0)
BTBでは話しが違うのかな？