パスワードを忘れた? アカウント作成
4756 story

トランスメタ、Crusoeに暗号命令を追加 55

ストーリー by Oliver
本当に速いのか 部門より

von_yosukeyan 曰く、 "日経エレクトロニクスオンラインの記事[要無料登録]によると、トランスメタはTM5800に暗号命令を追加したと発表した。
この命令は、CrusoeのネイティブなVLIWとして実装され、暗号鍵や認証データを保存する専用のスペースや暗号用アクセラレーターをチップ内部に持つ。このため、x86命令から見えない仕様になっており、セキュリティーの向上が期待できるという。VPNなどの利用を想定しているため、当初はDESに対応するがAESなど他のアルゴリズムにも対応可能だという。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by yanagi (6075) on 2003年01月19日 3時50分 (#238311) ホームページ 日記
    最近のTransmetaはターゲットがPCから組込みに
    なってるようだけど、これもその一環かな。

    この手の回路をCPUが持つのって組込みの方から
    見るとどの程度、便利なんでしょうか。
    なんか別個にその手のチップが乗っかってるの
    しかみたことないんですけど。
    --
    やなぎ
    字面じゃなく論旨を読もう。モデレートはそれからだ
    • Re:組込み (スコア:3, 参考になる)

      by von_yosukeyan (3718) on 2003年01月19日 6時17分 (#238351) ホームページ 日記
      例えば、保険の営業のお姉さんとか、製薬会社のMRの方が持ち歩いてるタッチパネルの端末など、本社の基幹系システムと機密データを外出先でやり取りする端末なんかですと、現状営業拠点でデータを端末にダウンロードして持ち歩くわけなんですが、情報の鮮度とかで問題になるわけで、一部ではダイアルアップでデータだけやり取りしてますが、セキュリティー上問題があるし、限られた通信速度/端末の処理速度ではアプリケーションの開発が結構大変だと思うんですが、高速回線で満足できる速度で暗号処理ができれば、センター側のターミナルサーバーでアプリケーションの処理までやってしまって、回線経由で端末に画面だけリアルタイムに飛ばすなんてこともできそうですし、CPUのハードウェア的に暗号処理層が実装されてると、端末を紛失したときにリバースエンジニアリングされる危険性が低くなるとか、そんなのどうなんでしょう?
      親コメント
      • Re:組込み (スコア:1, 興味深い)

        by Anonymous Coward on 2003年01月19日 12時36分 (#238441)
        1文で書かないで、句点をいくつか入れて欲しかったですぅ。
        素晴らしい事が書かれているのに、息継ぎが大変だったので。。。。。
        親コメント
      • by bushidoh (12670) on 2003年01月19日 23時44分 (#238757)
        高速回線が端末化には必要だと書かれている様に読みました。しかし、56k で AT&T VNC は十分に動作しましたよ。
        親コメント
      • 速度的な問題やリバースエンジニアリングの問題はそんなに重要ではないです。
        別にMPUに入れなくても、大規模なPLDか中規模のASICが一個あればDES程度ならば余りある筈です。(3DESやBlowfishだとどーだろ?)

        どっちかというと重要なのは消費電力と実装面積でして、いままでのMPUと同じ面積・同等の消費電力で暗号のようなややこしい機能が実装出来るのは、メーカ側から見て非常においしいです。

        しかも、CMSの機能を使えば、複数の暗号に対応出来たりデバッグも容易に出来ますからね。更に、メンテナンス性と言うアドバンテージも出来る


        親コメント
    • Re:組込み (スコア:2, 参考になる)

      by cyber205 (4374) on 2003年01月19日 4時49分 (#238331) ホームページ 日記
      >この手の回路をCPUが持つのって組込みの方から
      >見るとどの程度、便利なんでしょうか。

      同じ機能でチップが減れば、部品調達、コストダウンに有利。
      配線引かなくて済むから手間も省けるし、設計ミスもしにくい。

      チップにセキュリティというと、PentiumIIIの
      プロセッサシリアルナンバーを思い出しますね、個人的には…。

      生にシリアルナンバーを出さなければ、
      それはそれでセキュリティ確保に使えるかなと思ってみたり。
      親コメント
      • by Mc.N (3705) on 2003年01月19日 10時00分 (#238376) 日記
        PentiumIIIのプロセッサシリアルナンバーを思い出しますね
        私も最初、そう思いました。以下の記事を見る限り、どちらかと言えば MMX のような特定の機能の命令拡張に近いのかな、と考えています。
        -----
        [Transmeta、Centrino対策はCrusoeへのセキュリティ技術組み込み!?]
        http://pcweb.mycom.co.jp/news/2003/01/15/50.html
        -----
        上記の記事で私が気になったのは「アーキテクチャの柔軟性」です。これってやっぱり Intel の Microcode のようなものを仕込んで、CPU 自体の機能 up でもする気なのかな、と。ただあの会社のことですから、この手の仕様は一般に公開しないだろうから、一般の開発者は、手軽にこれらの機能を使えないのではないかと危惧しています。

        #どうせなら算術で求めない良質な RGN (Random Number Generator) を CPU 自体に組み込んで欲しい、に一票。
        --
        Mc.N
        親コメント
        • > 上記の記事で私が気になったのは「アーキテクチャの柔軟性」です。これってやっぱり Intel の
          > Microcode のようなものを仕込んで、CPU 自体の機能 up でもする気なのかな、と。
          > ただあの会社のことですから、この手の仕様は一般に公開しないだろうから、一般の開発者は、
          > 手軽にこれらの機能を使えないのではないかと危惧しています。

          x86 系の石は、Intel の AMD も内部は RISC アーキです。
          x86 命令列を RISC コアの解釈する命令(μOP とか RISC86)に変換している。
          ただ、この変換ルーチンはハードウェア化されており変更不能。

          Crusoe のコアは VLIW アーキテクチャです。
          x86 命令列を VLIW コアが解釈できるものに変換している。
          この部分が Code Morphing Software(CMS)。
          これが変更可能になっている点が、前者と異なる柔軟性です。

          CMS の仕様などは一般の開発者には提供しないでしょう。
          CMS は、相応な技術(プロセッサ・コンパイラ)を持っている人
          でも気軽に使えるようなものではないと思われます。

          > #どうせなら算術で求めない良質な RGN (Random Number Generator) を CPU 自体に組み込んで欲しい、に一票。

          御存知だと思うのですが、
          インテルは 810E チップセット以来に半導体素子の熱雑音を利用した
          再現性のない物理乱数発生器をすでに組み込んでいます。

          でも、この機能を実現するには熱雑音で駆動する特殊な回路が必要に
          なります。プロセッサ側にそういうハードがないと、CMS や Microcode
          のようなソフトウェアの変更で対応するのは無理ですよ。
          --
          コンタミは発見の母
          親コメント
        • > #どうせなら算術で求めない良質な RGN (Random NumberGenerator) を CPU 自体に組み込んで欲しい、に一票。

          ホント、欲しいですよねえ、これ。

          ちなみに、確か1、2年前に非常に高精度の乱数を発生出来る回路が開発されたように記憶していますが、
          その価格は確か数千万円だったような…
          • Re:真の乱数 (スコア:2, 興味深い)

            by cloudy (1160) on 2003年01月19日 17時44分 (#238560)
            真に予測不可能な乱数列をハードディスクの回転ゆらぎから生成するという論文があります。 特別なハードウェアなしに実装できるけど、生成速度は毎分100bitsというところらしい。
            Cryptographic Randomness from Air Turbulence in Disk Drives, [std.com]
            Don Davis, Ross Ihaka and Philip Fenstermacher
            CRYPTO'94 に載ったもの。たぶんSpringer-VerlagのLecture Noteシリーズになってる。
            親コメント
            • by G7 (3009) on 2003年01月19日 19時05分 (#238584)
              >生成速度は毎分100bitsというところらしい。

              計算機が稼動してる時間じゅう、裏でずっとbit生成をやり続け、
              得た値を順次キャッシュしていったら、遅さはなんとかカバーできませんかね?

              #キャッシュの置き場はもちろんハードディスク、ということで…
              親コメント
              • by Anonymous Coward
                >>生成速度は毎分100bitsというところらしい。
                >
                >計算機が稼動してる時間じゅう、裏でずっとbit生成をやり続け、
                >得た値を順次キャッシュしていったら、遅さはなんとかカバーできませんかね?
                >
                >#キャッシュの置き場はもちろんハードディスク、ということで…

                するとお約束でHDDが乱数だらけ・・・と。
                乱数マニアには堪りませんな。
              • by Dobon (7495) on 2003年01月20日 1時33分 (#238815) 日記
                あの~~そんな本物の乱数を使って暗号化したら、
                使い道が限られてしまいますよ?

                これは共通キー暗号の素朴な形なので、あまり使われていません。
                (政府の最高レベルの暗号に使われる程度)
                何故使われないかというと、共通キーなのでキーの配布(送付)を
                安全な別ルートで行う必要があるためです。

                # 技術計算とかで使うなら話は別です。
                # それをチップに組み込むか?は別の話ですが。
                --
                notice : I ignore an anonymous contribution.
                親コメント
              • by cloudy (1160) on 2003年01月20日 2時06分 (#238847)
                あの~~そんな本物の乱数を使って暗号化したら、
                使い道が限られてしまいますよ?

                公開鍵暗号系であっても、メッセージ本体は古典的な暗号系で秘密鍵で暗号化しておいて、その秘密鍵を公開鍵暗号でencodeしていっしょに送るというのが普通ではありませんか。

                そしてそのとき使われる秘密鍵は1回限りの使い捨てで、「真の乱数列」から生成されますよね。擬似乱数だと、一回前の秘密鍵から次の鍵を推測される怖れがありますから。

                なお、100bit/分であっても、それをタネにしてより長い乱数列を得ることができるので(ただしあまり延ばすと危険)、実用上は十分のようです。

                親コメント
              • by Dobon (7495) on 2003年01月21日 1時38分 (#239496) 日記
                >メッセージ本体は古典的な暗号系で秘密鍵で暗号化しておいて
                 普通は、この部分に疑似乱数を使用します。
                 で、その種となる「短い数列」を公開暗号で処理して送ります。

                生の鍵を送らない理由は、
                1.生の鍵を暗号化して送るくらいなら最初から全文を公開鍵で暗号化した方が楽。(乱数を使う意味がないでしょ?)
                2.公開鍵暗号は計算量が結構多いため、長文を暗号化すると時間を食う。
                3.非常に簡単な乗積合同法でも実用に耐える疑似乱数が得られます。
                (ビット数256とか512で乱数生成した場合)

                # PGPの実装を参照してください。
                --
                notice : I ignore an anonymous contribution.
                親コメント
          • >ちなみに、確か1、2年前に非常に高精度の乱数を発生出来る回路が開発されたように記憶していますが、

            東芝のランダムマスター [toshiba.co.jp]のことかな?
            親コメント
  • 大昔 (スコア:1, 興味深い)

    by Anonymous Coward on 2003年01月19日 9時56分 (#238374)
    輸入されたSunのマシンの中を見ると、「外国向け」と称してPCB上にパターンだけになったDESチップのはずれた跡があったのを思い出しますな。もちろん日本でのお話。
    • by saitoh (10803) on 2003年01月19日 18時15分 (#238571)
      Sun3のころは、DESチップ用のICソケットが空になっている だけだったけど。OSも SUN OS x.y_EXPORTという、暗号系を抜いた バージョンだった。
      親コメント
  • クルーソーのメリットにCMSのバージョンアップで
    パフォーマンスの改善、機能拡張が行えるってのありませんでしたか?
    でも既存の機種でCMSが頻繁にバージョンアップされてるのって見た事無い気がする。
    PCメーカーが悪いのかな。
    そうであれば、ユーザにはメリットが享受されてない感じですよね。

    CMSのバージョンアップでx86エミュレーション速度アップってのも見た気が…。
    • by Anonymous Coward on 2003年01月19日 11時57分 (#238426)
      はい、メーカには配られています>アップデータ。

      WindowsXPに対応して高速化させたアップデータなども
      Crusoe側は各メーカに送ってありますが、
      ユーザのアップデート作業失敗の危険性があるので、
      これを現Crusoeユーザに配布するということはまず無いというのが
      現状です。

      実際、XP対応アップデートをするだけで、
      非常に高速になるそうなのですが……
      親コメント
      • > ユーザのアップデート作業失敗の危険性があるので、
        > これを現Crusoeユーザに配布するということはまず無いというのが
        > 現状です。
        もったいない話ですね。 だったら、
        1. 原則、メーカーに送ってUpdateしてもらう(有
        • メーカーは2.を恐れていると思うので、1.だけでもいいんですけどね。

          ところで、CMSのアップデートって、BIOSのアップデートと同じ作業だと思っていたのですが、
          BIOSアップデートとは異なる、より危険度の高い作業なんでしょうか?
          • by g_maeda (6110) on 2003年01月19日 13時43分 (#238461)
            一番恐れているのは「実際、XP対応アップデートをするだけで、
            非常に高速になるそうなのですが……」という点ではないでしょうか。

            モデル間の序列を飛び越えて当時の上位機種より高速になったりすると、メーカーとしてはいろいろと厄介ではないかと思います。
            親コメント
            • > 当時の上位機種より高速になったりすると

              全く同等の機械で CPU だけ Crusoe と Intel を選択できる機械、なんてなかったし、そもそも一社でいくつも Crusoe 載せている機械をラインアップしているところまずなんかないんだから杞憂すぎかと。

              # 上位もなにもない Casio だけが実施しているじゃないか、と言われそうなので AC
          • BIOSアップデートは最悪失敗しても裏バンクにROMでリカバリ用BIOSを仕込んだりすれば済むけど、CMSのアップデートを失敗するとCPU自身が一切のコードが実行できなくなってしまうから危険度は高いですね。Crusoeネイティブ命令で書かれたプログラムを実行させる仕掛みたいなのがあればリカバリできそうだけどx86互換性のためにそういうことはできなくしてありそう…。(ちゃんと調べてないけど。)
            親コメント
            • そら通常では結線していない(してるかもしれないが)裏口ぐらいあるでしょう。

              でないと、タダの鉄くずになりますよ。
              開発中にそんなことになったら困るから裏口はあるでしょう。
              で、製品版でないかというと、CMSアッ
          • 1.だけ実践するとケチだの、ぼったくりだの、「不実う」だの
            言われるので、やらないんじゃないのでしょうか。
      • >> はい、メーカには配られています

        って、すでに製品として完成したPCに対するアップデータなんですか?2000年初頭のCrusoeの発表時のTransmeta社の誰かのインタビューで「ユーザやPCベンダが後からCMSを変更するようなことは可能なのか」と聞かれて「技術的には後からCMSをアップデートすることは不可能
    • by pantora (11989) on 2003年01月19日 14時40分 (#238484)
      やはり、配られていたんですね。
      最新機種だと、コードモーフィングの性能が
      飛躍的にあがっていますけど。
      Debianつっこむ為にLOOX買ったんですが、2002年WinMeモデル
      かなり遅い。Pentium II 300より遅い。
      調べたところCASIOのFIVA向けだとダウンロードできそうですが、
      富士通LOOX向けはないんでしょか?
      ためしにFIVA用のCMSを突っ込んでみるのもありですが...

      人柱精神旺盛なので情報希望。
      --
      PCにECC Registeredメモリの利用を推奨します。
      親コメント
      • by kamuy (1690) on 2003年01月19日 15時16分 (#238498) ホームページ 日記
        「人柱」と表明しているならば、まずは実際に突っ込んでみて、その結果を公表するのが正しい方向性かと。
        人柱道とは、そうそう甘いものではないのですよ。ええ。
        (ホントかよ? (笑))
        --
        -+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
        親コメント
        • by pantora (11989) on 2003年01月19日 15時57分 (#238521)
          >「人柱」と表明しているならば、まずは実際に突っ込んでみて、
          >その結果を公表するのが正しい方向性かと。

          FIVAのCMSもダウンロードできることはわかったが、
          URLわからなかったり...(笑)
          --
          PCにECC Registeredメモリの利用を推奨します。
          親コメント
          • by pantora (11989) on 2003年01月19日 19時39分 (#238600)
            FIVAのCMSをダウンロードできたが、
            現在のLOOXのCMSより古い。
            CMS 4.1.8以上どっかにないかなー。
            --
            PCにECC Registeredメモリの利用を推奨します。
            親コメント
    • 新しい CMS 欲しーーーい。

      出せコラ! Toshiba
      # Fiva にすれば良かったのか。。。
      親コメント
      • 欲しいですねぇ。VaioU1のレスポンス悪すぎ。Windows2000に再インストールしようかマジで悩んだもんなぁ。
        LavieMXとそんなに体感変らんってどういうことよ。いかにCrusoeの古いCMSがXPに合ってないかがよくわかるよなぁ。
        親コメント
        • >VaioU1のレスポンス悪すぎ。

          U3は少々バージョンのあがったCMSがはいってるはずですけど、
          レスポンスの差はどんな程度なんでしょうね?
          #店頭でU3触った限りではよく分からん・・・。
          #自分のU1は不要な機能をOFFにしてそれなりには動くけど、
          #アプリケーションの起動の遅さはどうにもなんない・・・(汗)。
          --
          ---- redbrick
          親コメント
          • >U3は少々バージョンのあがったCMSがはいってるはずですけど、

            すみません、誤情報です(汗)。
            #完全にわたしの勘違いです(汗)。

            CMS用メモリ容量アップの差しかないですね(汗)。
            CMSバージョンアップなんてないない。
            --
            ---- redbrick
            親コメント
  • by masahikoi (1183) on 2003年01月19日 13時44分 (#238462)
    規格は違うけど、Palladium 対応ハードウェアってこんな感じになる予定なんですよねえ。Palladium の場合は OS からアクセスできる暗号化チップを追加搭載、ですけど。

    先取り? 対抗?? それとも方向性 (オープンかプロプライエタリかとかじゃなくて) は違うんだろうか???
  • x86命令から見えないってことは、普通に考えると、x86系のOS上で動くアプリケーションへのインターフェースは無い、ということですよね?

    つまりこの機能は、x86系OSでの使用を前提としているNote PCではなく、専用OSを搭載した携帯端末での利用を想定しているんでしょうか? yanagi氏の言うように [srad.jp]、これからTransmetaはそういう方向へシフトしていく、ということ?

    疑問符ばかりですが、私ゃ普通に一日バッテリーで使えるNotePCが欲しいんで、Transmetaには期待してたんですよ。これからはCPUじゃなくてバッテリー方面(燃料電池とか)に期待するしかないのかなぁ…

    • 使用時間 (スコア:3, 興味深い)

      by white (2295) <{white} {at} {niu.ne.jp}> on 2003年01月19日 16時47分 (#238536) ホームページ
      使用時間ってことでなら、Transmetaは既に頑張り尽くしてしまった、って気がするんです。重要なのは「システム全体の消費電力」。以前はこのうちCPUの占める割合が極端に大きかった。既にCrusoeはこの割合を極端に下げてくれたわけで。

      100のうちの40を5に下げるのは劇的ですが、下がった65のうちの5を躍起になって下げようとしても、これは大した効果がない。むしろ頑張るべきは次のネックを下げること、なんじゃないでしょうか。液晶回りがどうとか、よく聞きますけどね。
      親コメント
      • by okayusan (6238) on 2003年01月19日 19時13分 (#238586) 日記
        CPUの消費電力への要請がシビアでなくなってきた という話はうなづけるものがあります。
        が、トランスメタの今年期待の新プロセッサ TM8000(ASTRO)は、現CrusoeTM5800より 性能が高まる(Pen4-M 1.8GHz相当!)だけでなく、 消費電力も抑えられるようですね。
        こんな記事 [impress.co.jp] があります。
        親コメント
      • by ma_kon2 (9679) on 2003年01月20日 10時07分 (#238967) 日記
        たしかに,有機ELなど,やるべきことはありますけどもね。
        グラフィックチップもね。
        あ,あとはOSも見直してくれないと(笑)。
        親コメント
    • <「使える」「NotePC」の定義にもよると思いますが>
      Sony Vaio/U + バッテリパックL で、
      電源のことを全く意識しないで一日中使えますよ。
      </「使える」「NotePC」の定義にもよると思いますが>
      親コメント
  • by Anonymous Coward on 2003年01月19日 6時12分 (#238346)
    「中身の検証ができなければ、某国政府の益になるような罠を
     仕掛けられている恐れが高い」

    として、中華な国は採用しないだろう。
    • by kamuy (1690) on 2003年01月19日 12時44分 (#238444) ホームページ 日記
      中国のメーカで採用 [zdnet.co.jp]されているようです。
      まあ、「第二位」のメーカであるらしいので、積極策に打って出ようということなのでしょうが。
      --
      -+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
      親コメント
    • by Y.. (7829) on 2003年01月19日 6時30分 (#238354) 日記
      >この命令は、CrusoeのネイティブなVLIWとして実装され、
      >暗号鍵や認証データを保存する専用のスペースや暗号用
      >アクセラレーターをチップ内部に持つ。
      アクセラレータと暗号専用領域の提供だから暗号プログラムつくるために仕様が公開されるわけだ
      暗号プログラムはBIOSにでもおさまるのかな?

      罠の仕掛ける余地はないんじゃないかなぁ
      罠を仕掛けられるとしたらBIOS…?
      親コメント
    •  たしかにファームウェアとしてのCMSにバックドアを仕掛けられればやりたい放題ですな。OSより上位だし。
       あの国なら本気でやりかねんし…。
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...