暗号化したクラスファイル
Toshikazu Takikawa
質問があります。
あらかじめクラスファイルを暗号化しておき、実行時に復号化して処理をする
手法は有りますか？
またそのような論文や製品等は有りますか？
＜質問の背景＞
javaのクラスファイルは逆コンパイラによって解析されてしまいます。
オブフスケータによってある程度は難読化されますが、それでも
しつこいハッカーには解読されてしまうでしょう。
そこでクラスファイルを暗号化しておいて、実行時に復号化すれば
よいと思いました。
＜すでに調べたこと＞
（１）javaのオブジェクトに対する署名・暗号化の論文は見つけましたが、
クラスファイル自体に関する署名・暗号化の論文や資料は見つかりません。
（２）製品でKeelというのが有ります。これはクラスファイルを暗号化
するようなのですが、詳細がわかりません。
NISHIMOTO Keisuke
Toshikazu Takikawa wrote:
>
> あらかじめクラスファイルを暗号化しておき、実行時に復号化して処理をする
> 手法は有りますか？
> またそのような論文や製品等は有りますか？
すべてのクラスを暗号化できるかどうかはわかりませんが、重要な部分
だけ暗号化するだけでよいのであればそういうクラスローダを作れば可
能ですね。
java.lang.ClassLoader#defineClass(
String name, byte[] data, int offset, int length)
を実装すればいいでしょう。
暗号化する方法については、JCE
http://java.sun.com/products/jce/index.html などを利用すればいい
のかもしれません。＃ライセンスに注意してください。
ただし、Java Applet や Java Web Start などのアプリケーションの場
合 ClassLoader は制限を受けるので要注意です。
> ＜すでに調べたこと＞
> （２）製品でKeelというのが有ります。これはクラスファイルを暗号化
> するようなのですが、詳細がわかりません。
こちらはしりません。
開発ソフトの一部の機能のようですね。
Taki
早速の回答ありがとうございます。
"NISHIMOTO Keisuke" <keis...@itrek-jp.com> wrote in message
> すべてのクラスを暗号化できるかどうかはわかりませんが、重要な部分
> だけ暗号化するだけでよいのであればそういうクラスローダを作れば可
> 能ですね。
>
> java.lang.ClassLoader#defineClass(
> String name, byte[] data, int offset, int length)
>
> を実装すればいいでしょう。
クラスローダをオーバーライトするのですね。
この手法だとユーザクラスローダをオーバーライトする形になるので、
最初のクラスローダ（システムクラスローダ）には応用ができませんね。
システムクラスローダで暗号化してあるクラスを読み込む手法を
研究している方やその論文を探しています。ご存じありませんか？
滝川敏一
Toshikazu Takikawa
CT4T...@asahi-net.or.jp
NISHIMOTO Keisuke
Taki wrote:
>
> "NISHIMOTO Keisuke" <keis...@itrek-jp.com> wrote in message
>
>>java.lang.ClassLoader#defineClass(
>> String name, byte[] data, int offset, int length)
>>
>>を実装すればいいでしょう。
>
> クラスローダをオーバーライトするのですね。
> この手法だとユーザクラスローダをオーバーライトする形になるので、
> 最初のクラスローダ（システムクラスローダ）には応用ができませんね。
> システムクラスローダで暗号化してあるクラスを読み込む手法を
> 研究している方やその論文を探しています。ご存じありませんか？
システムクラスローダを作ればいいのでは？
例えば、boot classpath を差し替えれば可能だと思います。
Taki
"NISHIMOTO Keisuke" <keis...@itrek-jp.com> wrote in message
news:3D63405...@itrek-jp.com...
>
> システムクラスローダを作ればいいのでは？
sunのソースを見て、Ｃで実装されているシステムクラスローダを
真似て自分のシステムクラスローダを作るということでしょうか？
> 例えば、boot classpath を差し替えれば可能だと思います。
NISHIMOTO Keisuke
目的はなんでしょうか？
どんな環境で動作させようとしているのでしょう。
そのあたりがわかれば、別の回答もでてくると思います。
＃例えば、Java Applet などは 署名付 の Jar ファイルなどが
＃使えたりしますよ。
Taki wrote:
>
> "NISHIMOTO Keisuke" <keis...@itrek-jp.com> wrote in message
> news:3D63405...@itrek-jp.com...
>
>>システムクラスローダを作ればいいのでは？
>
> sunのソースを見て、Ｃで実装されているシステムクラスローダを
> 真似て自分のシステムクラスローダを作るということでしょうか？
そういう細かいことは自分でお調べるのがいいと思います。
また素朴な疑問なんですが、どうしてもシステムクラスローダで
なければならないんでしょうか？
運用面などで、カバーできたりしませんか？
Narita Takaoki
<3D6354FF...@itrek-jp.com>の記事において
keis...@itrek-jp.comさんは書きました。
> 目的はなんでしょうか？
> どんな環境で動作させようとしているのでしょう。
この辺分からないとなんとも言いようがないですが、そういうクラスフ
ァイルを扱えるようにしても、それを扱うクラスローダをやる気満々の
クラッカーに渡してしまったら、ほとんど解除の手段をのし付けてあげ
てやっているのと変らない気がするのですが、違うでしょうか？
本質的には、根性とやる気と技術のある相手に対するなら、暗号化され
た byte code 列を直に実行するような VM でもないと、 reflect とか
そっちまで手を入れるならいざしらず、クラスファイルの暗号化だけで
はあんまり有効とは言いがたい気がするです。
# まあ、安直に逆コンパイラは出来なくはなるですが。
> そのあたりがわかれば、別の回答もでてくると思います。
それじゃ不十分て意見もあり得るわけですし。
--
成田 隆興 ＠ エー・アイ・ソフト株式会社ソリューシュン開発部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
NISHIMOTO Keisuke
Narita Takaoki wrote:
>
> <3D6354FF...@itrek-jp.com>の記事において
> keis...@itrek-jp.comさんは書きました。
>
>>目的はなんでしょうか？
>>どんな環境で動作させようとしているのでしょう。
>
> この辺分からないとなんとも言いようがないですが、そういうクラスフ
略
> # まあ、安直に逆コンパイラは出来なくはなるですが。
おっしゃることはわかりますし、殆ど同意するのですが、結局何が
目的で暗号化するのかなのかはっきりしないので、はっきり答える
ことができないというところに問題があると思います。
>>そのあたりがわかれば、別の回答もでてくると思います。
>
> それじゃ不十分て意見もあり得るわけですし。
もちろんです。
Taki
いろいろとお世話になります。
> >>目的はなんでしょうか？
> >>どんな環境で動作させようとしているのでしょう。
> >
> > この辺分からないとなんとも言いようがないですが、そういうクラスフ
> 略
> > # まあ、安直に逆コンパイラは出来なくはなるですが。
>
> おっしゃることはわかりますし、殆ど同意するのですが、結局何が
> 目的で暗号化するのかなのかはっきりしないので、はっきり答える
> ことができないというところに問題があると思います。
私が目的を明確にしていなかったのが問題のようですね。
すみません。
＜目的について＞
目的は電子政府などのシステムをjavaで開発したとき、それを
ハッキングされないようなもを作り上げることです。
作り上げた製品を逆コンパイルしてはならないという
項目を契約時に盛り込んだとしても、ハッカーに対しては
意味がありません。
私が想定しているハッカーは以下の通りです。
（１）クラスファイルを逆コンパイルする普通のハッカー
（２）暗号化されているクラスファイルを復号化して
さらに逆コンパイルする上級ハッカー
このうち（１）に関しては暗号化したクラスファイルを
用いることによりハッカーの悪戯を防止できます。
（２）に関しては暗号化の手法を最新にしたり定期的に
鍵を更新していれば防ぐことができます。
暗号化したクラスファイルを用いることにより
ほとんど解析が不可能なシステムが完成します。
こういうのを作り上げたいと考えております。
＜これまでにわかったこと＞
ユーザクラスローダをオーバーライトさせて、
暗号化されているクラスファイルを復号化して
読み込む部分を作り上げればいい。
＜問題として残ったこと＞
システムクラスローダはオーバライトできないので、
その部分をどうにかしなくてはならない。
＜知りたいこと＞
最初の投稿にも書いたのですが、
このような研究をしている方や論文があれば
教えていただきたい。
＃処理の方法を知りたいのではなく
＃そのような処理をしている論文の存在を知りたいのです。
以上
Hoshi Takanori
In article <3d6439b7$0$27764$44c9...@news2.asahi-net.or.jp>
"Taki" <CT4T...@asahi-net.or.jp> writes:
> 私が目的を明確にしていなかったのが問題のようですね。
まだまだ不明確だと思いますよ。と言うか、質問の目的が
a. すでに Java を使って製品を作ることが決まっていて、その上で
できるだけ crack されないようにする方法を知りたい。
b. 企画段階の調査、または純粋な研究として、Java の cracking に
対する耐性を知りたい。
のどちらか？ という、＊いちばん重要なこと＊ が分かりません。
＃ 残りを読む限り b. っぽいので、以下、b. という前提で書きます。
＊＊
> ＜目的について＞
> 目的は電子政府などのシステムをjavaで開発したとき、それを
> ハッキングされないようなもを作り上げることです。
簡単に「Java で開発する」とおっしゃってますが、Java プログラムを
どこで動かすのかによって答えはぜんぜん変わってきます。
可能性としては、
・server 側で動かす。
・役場などの安全な (と思われる) 場所に置いた、専用の端末で動かす。
・家庭や職場などの、一般のパソコンで動かす。
などが考えられるわけですが、どうやら一般のパソコンで動かすことを
前提としている (というか、失礼ながら、Java の使い道はそれしか
ないと思ってらっしゃるように読めます。) ようなので、それについて
コメントすると、
> （２）に関しては暗号化の手法を最新にしたり定期的に
> 鍵を更新していれば防ぐことができます。
どんなに暗号を強化しても、実行する際にはいったん復号化する必要が
あるわけで、一般のパソコンで動く (≒ cracker が Java VM の動作を
コントロールできる) 以上、crask するのはそれほど難しくないと
思います。
＃ これは別に Java だから、と言うわけではなくて、どんな言語で
＃ 書かれていても、一般のパソコンで動かす以上は同じことです。
電子商取引なら、完全な防御はあきらめて、あとは保険でカバーする、
というのもありかも知れませんが、電子政府だとそうはいきませんよね。
＊＊
セキュリティを考える場合には、システム全体を評価する必要があって、
「クラスファイルの暗号化」などの個々の要素技術は、「それをどこに
どう使うか？」ということを抜きにして考えても無意味だと思います。
ほし
Narita Takaoki
<3d6439b7$0$27764$44c9...@news2.asahi-net.or.jp>の記事において
CT4T...@asahi-net.or.jpさんは書きました。
> ＜目的について＞
> 目的は電子政府などのシステムをjavaで開発したとき、それを
> ハッキングされないようなもを作り上げることです。
これでも良くわかりません。
私が本当に知りたいのは、
0.クラスファイルの内容を秘匿することで何を守りたいのか
1.いつまで守りたいのか
2.そのシステム(クラスファイル)は弘布するのか
3.もしくは特定ユーザに領布するのか
4.一般から容易にそのクラスファイルにアクセス可能なものな
のか
です。
> 作り上げた製品を逆コンパイルしてはならないという
> 項目を契約時に盛り込んだとしても、ハッカーに対しては
> 意味がありません。
このように書かれていることから、2 もしくは多数のユーザあての 3 で
あり、4 は容易にアクセス可能と判断しました。
で、最大の焦点は 0 なんです。例えば、
イ) セキュリティーホールをクラッカーが見つけられることで
セキュリティー上の脅威にシステムが晒されることを防が
んがため
ロ) 技術的優位保護のため
などが簡単に思いつきます。ただ、ロは
> 私が想定しているハッカーは以下の通りです。
> （１）クラスファイルを逆コンパイルする普通のハッカー
> （２）暗号化されているクラスファイルを復号化して
> さらに逆コンパイルする上級ハッカー
>
> このうち（１）に関しては暗号化したクラスファイルを
> 用いることによりハッカーの悪戯を防止できます。
> （２）に関しては暗号化の手法を最新にしたり定期的に
> 鍵を更新していれば防ぐことができます。
と書かれているから無いのでしょう。
すでに書いたように、復号するためのクラスファイル(そういうクラスロ
ーダ)もアクセス可能であるのとしたら、特に上級者でなくとも用意に復
号できると思います。そういう事に使える仕組みがすでに Java の根幹
の部分にありますから。
# 詳しい部分はほしさんがすでに書かれていますし、それに加えて
# java.lang.reflect パッケージのメソッド一覧でも眺められれば私が
# 以前書いたことも分かろうかと。
> 暗号化したクラスファイルを用いることにより
> ほとんど解析が不可能なシステムが完成します。
ですので、ここまでの話しではこれは成り立ちません。
> ＜これまでにわかったこと＞
> ユーザクラスローダをオーバーライトさせて、
> 暗号化されているクラスファイルを復号化して
> 読み込む部分を作り上げればいい。
もちろん単にこういうことをしてみたいというなら別ですが。
もしくは、セキュリティーレベルの要求や、運用上での秘密保全期間が
短期である(解析が終わる前に次のクラスファイルがリリースされるとか)
とかで、この程度でも良いとかはあるでしょうけれど。
あ、でも一度復号の仕組みを組み上げればすぐ復号自体は出来るように
なるから、運用上の秘密保全期間にはこれをやっても何の得もないっす
ね。
> ＜知りたいこと＞
> 最初の投稿にも書いたのですが、
> このような研究をしている方や論文があれば
> 教えていただきたい。
> ＃処理の方法を知りたいのではなく
> ＃そのような処理をしている論文の存在を知りたいのです。
おそらく上記のごとき理由でそういうことは普通考えないだろうから(別
の理由で似たことをやる可能性はあるけれど)、無いのではなかろうか。
# 別の理由とは、jar よりもっと、もーっと圧縮率が良いアーカイブで
# 独自にやりたいぞー！とかね。
クラスファイルの配布経路がネットとかで横取り可能だから暗号化した
いというなら、普通は暗号化するソケットでも通すだろうし。
Narita Takaoki
<ak1tdd$du1$1...@news01.highway.ne.jp>の記事において
tak...@aisoft.co.jpさんは書きました。
> 0.クラスファイルの内容を秘匿することで何を守りたいのか
:
> で、最大の焦点は 0 なんです。例えば、
>
> イ) セキュリティーホールをクラッカーが見つけられることで
> セキュリティー上の脅威にシステムが晒されることを防が
> んがため
こっち目的なら、穴探しのためにもオープンにしてみんなに探してもら
った方が良いのでは。もちろん、クラッカーが穴探しにかける労力以上
のものを自らかけることが出来るのなら、隠すことも意味がありますが。
そうでないなら、最近の潮流としては、オープンソースでみんなで叩い
て、みんなで直すってのが多いっすよね。
Taki
"Hoshi Takanori" <ho...@sra.co.jp> wrote in message
news:HOSHI.02A...@ext54.sra.co.jp...
> > 私が目的を明確にしていなかったのが問題のようですね。
>
> まだまだ不明確だと思いますよ。と言うか、質問の目的が
>
> a. すでに Java を使って製品を作ることが決まっていて、その上で
> できるだけ crack されないようにする方法を知りたい。
>
> b. 企画段階の調査、または純粋な研究として、Java の cracking に
> 対する耐性を知りたい。
>
> のどちらか？ という、＊いちばん重要なこと＊ が分かりません。
>
> ＃ 残りを読む限り b. っぽいので、以下、b. という前提で書きます。
すみません。この点について明確にしておりませんでした。
ご推測通り b. です。
現時点では製品などを開発するつもりは無く、全くの研究レベルの話です。
単純に「クラスファイルを暗号化してはどうか」と思いつきのレベルです。
>
> 簡単に「Java で開発する」とおっしゃってますが、Java プログラムを
> どこで動かすのかによって答えはぜんぜん変わってきます。
>
> 可能性としては、
> ・server 側で動かす。
> ・役場などの安全な (と思われる) 場所に置いた、専用の端末で動かす。
> ・家庭や職場などの、一般のパソコンで動かす。
> などが考えられるわけですが、どうやら一般のパソコンで動かすことを
> 前提としている (というか、失礼ながら、Java の使い道はそれしか
> ないと思ってらっしゃるように読めます。) ようなので、それについて
> コメントすると、
この点についても明確にしておりませんでした。先ほども述べたとおり
思いつきレベルなので、どこでjavaを動かすかも想定はしておりません。
ただ私の頭の中にあったのは、ご指摘の家庭や職場などの
一般のパソコンで動かすことが大部分を占めていました。
最初の投稿にも明記したとおり、ただ単純にこのような
研究をしている論文があるかどうかを知りたいのです。
> どんなに暗号を強化しても、実行する際にはいったん復号化する必要が
> あるわけで、一般のパソコンで動く (≒ cracker が Java VM の動作を
> コントロールできる) 以上、crask するのはそれほど難しくないと
> 思います。
>
> ＃ これは別に Java だから、と言うわけではなくて、どんな言語で
> ＃ 書かれていても、一般のパソコンで動かす以上は同じことです。
そうなんですか。私はハッカーでは無いので（またそのような技術もないので）
よくわかりませんが、ｃ言語（コンパイル系の言語）などで書かれたアプリケーショ
ン
はハッキングが難しいと思ったのですが、そうではないようですね。
一般的にパソコンで実行されているものはハッキングされてしまうのですね。
私の認識は、
（ソースコード）<<（中間言語へのコンパイル言語）<<（コンパイル系言語）
＃－－－－＞こっちへ行くほど難しい
でしたが、考えを改めます。
> 電子商取引なら、完全な防御はあきらめて、あとは保険でカバーする、
> というのもありかも知れませんが、電子政府だとそうはいきませんよね。
そうですね。おっしゃる通りです。
> セキュリティを考える場合には、システム全体を評価する必要があって、
> 「クラスファイルの暗号化」などの個々の要素技術は、「それをどこに
> どう使うか？」ということを抜きにして考えても無意味だと思います。
ということはシステム全体で考えるべきだと、．．．
おっしゃることはわかります。
でも、私の知りたいのは、
最初の投稿にも明記したとおり、ただ単純にこのような
研究をしている論文があるかどうかを知りたいのです。
Taki
"Narita Takaoki" <tak...@aisoft.co.jp> wrote in message
news:ak1tdd$du1$1...@news01.highway.ne.jp...
> > ＜目的について＞
> > 目的は電子政府などのシステムをjavaで開発したとき、それを
> > ハッキングされないようなもを作り上げることです。
>
> これでも良くわかりません。
>
> 私が本当に知りたいのは、
>
> 0.クラスファイルの内容を秘匿することで何を守りたいのか
> 1.いつまで守りたいのか
> 2.そのシステム(クラスファイル)は弘布するのか
> 3.もしくは特定ユーザに領布するのか
> 4.一般から容易にそのクラスファイルにアクセス可能なものな
> のか
>
> です。
ご指摘の項目について明確にしておりませんでした。
すみません。
もともとこの質問は、私の思いつきに依るところが多く
詳細については検討しておりません。
ただ単に技術的にクラスファイルを暗号化してはどうかという
発案がベースになっております。
私の知りたいことは、このようなアイデアが研究されているか否かです。
> すでに書いたように、復号するためのクラスファイル(そういうクラスロ
> ーダ)もアクセス可能であるのとしたら、特に上級者でなくとも用意に復
> 号できると思います。そういう事に使える仕組みがすでに Java の根幹
> の部分にありますから。
復号するためのクラスファイル（そういうクラスローダ含む）は暗号化して
おこうと考えております。じゃあそのファイルを復号化するのはなに？
と疑問に思われるかもしれませんが、それは、別のコマンドで行おうと
考えております。コマンドレベルで復号化してその標準出力をJVM
に食わせればうまくいくと考えております。
Toru Watanabe
滝川さん> 私の知りたいことは、このようなアイデアが研究されているか否かです。
論文ではありませんが、特にJavaで書かれたコードについて、逆コンパイル、
リバースエンジニアリング等を困難にすることを目的とした特許があるので、
御覧下さい。
URL : http://www.ipdl.jpo.go.jp/Tokujitu/tjsogodb.ipdl?N0000=101
にアクセスして、
文献種別 : A
文献番号 : 2002-514333
で検索できます。
この特許では、暗号化は用いられていません。
まず、暗号化は、復号化できない(鍵を持っていない)人が、暗号化された内容
を解析できないようにするための手段である事に注意してください。
成田さん> すでに書いたように、復号するためのクラスファイル(そういうクラスロ
成田さん> ーダ)もアクセス可能であるのとしたら、特に上級者でなくとも用意に復
成田さん> 号できると思います。そういう事に使える仕組みがすでに Java の根幹
成田さん> の部分にありますから。
成田さんのおっしゃるように、クラッカーが復号化手段を持っている時点で暗
号化は無力です。
滝川さん> 復号するためのクラスファイル（そういうクラスローダ含む）は暗号化して
滝川さん> おこうと考えております。じゃあそのファイルを復号化するのはなに？
滝川さん> と疑問に思われるかもしれませんが、それは、別のコマンドで行おうと
滝川さん> 考えております。コマンドレベルで復号化してその標準出力をJVM
滝川さん> に食わせればうまくいくと考えております。
滝川さんの考えでは、2重に暗号化するようですが、クラッカーは自分で復号
化する必要はありませんよ。実行すれば、勝手に復号化してくれるのですから。
そして、その復号化されたコードは、一時領域なり、記憶装置なりにのっかる
ので、後はそこから復号化された物を取り出せばいいだけです。
一般的なUnixプラットホームでは実行中のプロセスのメモリイメージをいつで
も取得できますよ。
また特に機密性を要求されるようなコードの場合、そのソースコードを知って
いる人が、リークするような場合や、最初の復号に用いられる鍵が漏洩する場
合も考慮する必要があります。
話がすこし戻りますが、
滝川さん> 目的は電子政府などのシステムをjavaで開発したとき、それを
滝川さん> ハッキングされないようなもを作り上げることです。
滝川さん> 作り上げた製品を逆コンパイルしてはならないという
滝川さん> 項目を契約時に盛り込んだとしても、ハッカーに対しては
滝川さん> 意味がありません。
このような目的の場合、サーバ側のシステムに機密コードを置き、クライアン
ト側のプログラムおよび、クライアントーサーバ間のプロトコルはむしろ公開
してしまうのが良いと考えられます。
例えば、JavaではJ2EEと言うEnterpriseアプリケーションの基盤があります。
J2EEでは、サーバ側にJava Servlet(JSP)(+EJB)を置き、クライアントはWebブ
ラウザと言うような構成を取ります。これは前記した様に、プロトコルもクラ
イアントアプリケーションも公開されています(いくつかのブラウザは非公開
ですが)。
また、クライアント側をリッチクライアントにする(Appletや、Javaアプリケー
ション)場合は、J2EEサーバとのやり取りを、SOAPで行う方法もあります。
この場合もプロトコルやクライアントソースコードを公開しても全く問題ない
様に、サーバ側アプリケーションを作成することが可能です。
これらの場合、サーバ側のセキュリティについては、十分に注意する必要が
ありますが。
最後に、IPAのサイトに、滝川さんの研究に役立ちそうな情報がいろいろ
あると思います。一度御覧になってみると良いです。
http://www.ipa.go.jp/security/
http://www.ipa.go.jp/security/products/software.html
http://www.ipa.go.jp/security/awareness/vendor/software.html
http://www.ipa.go.jp/security/awareness/vendor/programming/index.html
渡辺
ka...@sra-tohoku.co.jp
<3d648bbd$0$27777$44c9...@news2.asahi-net.or.jp>の記事において
CT4T...@asahi-net.or.jpさんは書きました。
[ばっさり略]
>> 研究をしている論文があるかどうかを知りたいのです。
プログラムの実行方法が人間にわかるのであれば、
人間が解読することも可能。
(Java VMだろうとp-codeだろうとx86だろうと関係なし)
ので、
本当にやる気のあるハッカーに耐えるようにするには
耐タンパー性のハードウェアを使わないとダメとゆーのが定説のよーです。
(横文字はtamper-proof hardwareですかな＞識者)
実際はアルゴリズムではなく復号鍵を埋めておくことが多いようですが。
暗号関係より電子著作権関係の論文のほうが多いかも。ゼニからんでるので。
--
kabe
Taki
> かべ＠ＳＲＡ東北％横やり
横やりおおいに結構です。ご指摘ありがとうございます。
> [ばっさり略]
> >> 研究をしている論文があるかどうかを知りたいのです。
>
> プログラムの実行方法が人間にわかるのであれば、
> 人間が解読することも可能。
> (Java VMだろうとp-codeだろうとx86だろうと関係なし)
> ので、
> 本当にやる気のあるハッカーに耐えるようにするには
> 耐タンパー性のハードウェアを使わないとダメとゆーのが定説のよーです。
> (横文字はtamper-proof hardwareですかな＞識者)
> 実際はアルゴリズムではなく復号鍵を埋めておくことが多いようですが。
行き着くところは耐タンパー性のあるハードウエアで対処するしかないのですね。
> 暗号関係より電子著作権関係の論文のほうが多いかも。ゼニからんでるので。
わかりました。電子著作権関連でもう一度特許や論文を調べてみます。
貴重なご意見ありがとうございました。
Taki
> 論文ではありませんが、特にJavaで書かれたコードについて、逆コンパイル、
> リバースエンジニアリング等を困難にすることを目的とした特許があるので、
> 御覧下さい。
>
> URL : http://www.ipdl.jpo.go.jp/Tokujitu/tjsogodb.ipdl?N0000=101
> にアクセスして、
>
> 文献種別 : A
> 文献番号 : 2002-514333
> で検索できます。
ありがとうございます。調べてみます。
> 滝川さんの考えでは、2重に暗号化するようですが、クラッカーは自分で復号
> 化する必要はありませんよ。実行すれば、勝手に復号化してくれるのですから。
> そして、その復号化されたコードは、一時領域なり、記憶装置なりにのっかる
> ので、後はそこから復号化された物を取り出せばいいだけです。
> 一般的なUnixプラットホームでは実行中のプロセスのメモリイメージをいつで
> も取得できますよ。
私のアイデアは２重に暗号化するわけではありません。
メールだけでは説明しにくいんですけど。すみません私の説明能力が劣って
いるせいですね。
UNIXプラットフォームではメモリイメージをいつでも取得できるのですか。
勉強になります。貴重なご意見ありがとうございます。
> 最後に、IPAのサイトに、滝川さんの研究に役立ちそうな情報がいろいろ
> あると思います。一度御覧になってみると良いです。
>
> http://www.ipa.go.jp/security/
> http://www.ipa.go.jp/security/products/software.html
> http://www.ipa.go.jp/security/awareness/vendor/software.html
> http://www.ipa.go.jp/security/awareness/vendor/programming/index.html
ありがとうございます。調査してみます。