パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • アブストラクト [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上でこの方法で破られるリスクは小さい(そもそもそ

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

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

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

      こうなると、「どっちもどっち」と言うか、SSLなどのSecure系のShared LibやOSのコンテキストスイッチャのコードを書き換えてバックドア仕掛ける方が簡単では無いか(^_^;と言う感じがするんですけど(^_^;
      今回の「発見」の肝はバックドアの隠蔽度を非常に高められる…と言うことなんでしょうかねぇ?(^_^;
      • 「分岐予測に使うキャッシュの保護に問題」というのは、別のユーザプロセスから間接的に分岐状態が予測出来てしまうことを指しているようです。スパイプロセスが1ビットの記録にかかる時間は暗号化/複合化の時間に比べてはるかに少なくてすむので

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

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

        # わかりきったキーをサービスにバンバン投げておいて、違うのが見つかったらそれを記録、とかもありそう。
        • 不勉強で各暗号系の処理がどのようになっているかは知らないんですが、結局のところ

          ループ→常に最大(最悪)の回数ループするようにする
          分岐→分岐条件に関わらず常に演算を行い、条件付代入(x86ならMOVcc)などで切り分けるようにする

          として、入力が何であれ、常に同じ命令群を実行するようにコードを書くしかなさそうな気がします。
          (条件付代入がない命令セットもありますが、ビット演算などの組み合わせで代用できますし)

          ただそうすると、タダでさえ重い処理が常にワーストな時間がかかるようになるのと、
          分岐命令を生成させないように高級言語で記述するのは面倒という問題がありそうですが。

          次はSpeedStep/Cool'n'Quiet系で盗聴かなと思ったAC
          • 実際のところ (スコア:3, 参考になる)

            by superfox (31908) on 2006年11月21日 0時44分 (#1061599)
            ここの解説 [iacr.org]によれば、RSA に用いられるモンゴメリ乗算

            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] とあります。後者もサイクル数が違ったりすると付け込む隙があるかもですね。
            親コメント
            • by Anonymous Coward on 2006年11月21日 2時24分 (#1061629)
              > 前者が blinding というものではないのでしょうか?(私も詳しくはない)。blinding と randomization techniques は totally useless [iacr.org] とあります。

              なるほど、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]のコア数の話に関して。

              コア数に対して十分なスレッドを起こしてすべてで盗聴させてその結果を統合すれば推測できそうな気がしますが、どうでしょう。
              親コメント

物事のやり方は一つではない -- Perlな人

処理中...