アカウント名:
パスワード:
プロトコルが解析されたのは正しいと思う。けど、perfect dark architectureを読む限りでは、暗号鍵は見つけ出すような使いかたされてないっぽいよ。# 以下、公開されてる文書が正しいと仮定して説明。
perfect darkはファイルの流通が3段構えになってる。1. 「ファイル」を暗号化して分散ハッシュ放流する。(暗号化されたファイルだけ先に流す)2. 「ファイル名+暗号鍵」を分散ハッシュ放流する。(ファイル名と暗号鍵だけ)3. 「ファイル名+暗号鍵」は、ランダムワード&検索ワードでノードにどんどん集められる(ネットワーク上に拡散する)# ファイル名+暗号鍵は「仮身」と呼ばれてる。こいつからは担当ノードしかわからないっぽい。# ファイルの実態は「実身」と呼ばれてる。この場所は、担当ノードがIPアドレスを押さえてるっぽい。「仮身」と呼ばれるものにファイルの暗号鍵が含まれてってのは公言されてる。見つけるまでもない。
(ネットエージェントが言うところの「キー情報」が「仮身」にあたるのであれば)「キー情報」を収集しても暗号化されたファイルを持ってるIPアドレスはわからない。これが「単純なクローラでは所有者が分かりません」って事になるんだと思う。ネットエージェントがやってるのはたぶん次のステップ。1. 「仮身」をもりもり集める2. 「仮身」から算出した担当ノードにもりもり問い合わせ。3. 担当ノードから返されるIPアドレスと、さっきの「仮身」を紐づけて記録
ただし、perfect dark architectureによると(原理は不明だけど)ピア接続要求を、一定確率で黙って中継するらしい。これはまんま中継してるので、接続要求を出した側からは判断できない。つまり、ファイル実態の場所を管理してる担当ノードが、中継を期待して「ファイル実態を持ってないノード」のIPアドレスを返してる可能性がある。これだとファイル実態とIPアドレスをマッピングできない。(いくつか嘘が混じってることになる)# まあ、クライアントばらせば分かる事なので、ネットエージェントが言ってないならそんなことしてないんだろうけど:p
> >ハードコードすることで秘密鍵が共有できているなら,> >鍵交換する必要がないですよね?>> 意味がわかりません。
公開鍵暗号化を使う必要もなくて、AESでもDESでもいいじゃんってことでは?
Wikiを読む限り交換される際に始めて暗号化されているようなので、 ファイル受信側:公開鍵Pと秘密鍵S(RSA)を生成し、Pを送信 ファイル送信側:共通鍵C(AES)を生成し、Pで暗号化して送信 これでCを使ってファイルを暗号化する、という教科書的な方法だと思います。
そんなことをやっても何の意味もない。クローラーが生成した公開鍵を「ファイル送信側」に送れば、「ファイル送信側」がその鍵を元に暗号化してクローラーに送信してしまう。(意味わかる?)
ちなみにこういうのはman-in-the-middle attackとは言わない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
暗号が破られたわけじゃない (スコア:5, 参考になる)
プロトコルが解析された
暗号鍵が(プログラム中から)見つけ出された
あたりが正しい。
これ豆知識な。
一応訂正しとくけども (Re:暗号が破られたわけじゃない (スコア:3, 参考になる)
プロトコルが解析されたのは正しいと思う。
けど、perfect dark architectureを読む限りでは、暗号鍵は見つけ出すような使いかたされてないっぽいよ。
# 以下、公開されてる文書が正しいと仮定して説明。
perfect darkはファイルの流通が3段構えになってる。
1. 「ファイル」を暗号化して分散ハッシュ放流する。(暗号化されたファイルだけ先に流す)
2. 「ファイル名+暗号鍵」を分散ハッシュ放流する。(ファイル名と暗号鍵だけ)
3. 「ファイル名+暗号鍵」は、ランダムワード&検索ワードでノードにどんどん集められる(ネットワーク上に拡散する)
# ファイル名+暗号鍵は「仮身」と呼ばれてる。こいつからは担当ノードしかわからないっぽい。
# ファイルの実態は「実身」と呼ばれてる。この場所は、担当ノードがIPアドレスを押さえてるっぽい。
「仮身」と呼ばれるものにファイルの暗号鍵が含まれてってのは公言されてる。見つけるまでもない。
(ネットエージェントが言うところの「キー情報」が「仮身」にあたるのであれば)「キー情報」を収集しても暗号化されたファイルを持ってるIPアドレスはわからない。
これが「単純なクローラでは所有者が分かりません」って事になるんだと思う。
ネットエージェントがやってるのはたぶん次のステップ。
1. 「仮身」をもりもり集める
2. 「仮身」から算出した担当ノードにもりもり問い合わせ。
3. 担当ノードから返されるIPアドレスと、さっきの「仮身」を紐づけて記録
ただし、perfect dark architectureによると(原理は不明だけど)ピア接続要求を、一定確率で黙って中継するらしい。
これはまんま中継してるので、接続要求を出した側からは判断できない。
つまり、ファイル実態の場所を管理してる担当ノードが、中継を期待して「ファイル実態を持ってないノード」のIPアドレスを返してる可能性がある。
これだとファイル実態とIPアドレスをマッピングできない。(いくつか嘘が混じってることになる)
# まあ、クライアントばらせば分かる事なので、ネットエージェントが言ってないならそんなことしてないんだろうけど:p
Re: (スコア:0)
ただ,RSAを使っているらしいので,鍵をプログラムに
埋め込む必要はないはずです.
Perfect Dark wiki より
> 通信は、公開鍵交換(RSA-1024)、秘密鍵でAES暗号鍵を暗号化・交換、
> AES暗号鍵で暗号化通信を開始、となっています。
> 自動アップデートは当方が秘密鍵を持っており、ソフトに公開鍵が組み込まれています。
> 電子署名を確認してからアップデートを行うので、安全性は高いと考えています。
ノード間の認証はできないはずなので,Man-in-the-middle のような,
プロトコル的な攻撃かもしれません.
Re: (スコア:0)
Re: (スコア:0)
そんなわけはない。peer to peer でRSAを使うなら、一方に公開鍵、もう一方には秘密鍵が当然に入っているわけで。
(公開鍵暗号ってだけで凄い万能とか思っちゃう人、まだいるんだね。)
Re: (スコア:0)
通信時に鍵交換ができるならば,
鍵データをプログラムにハードコードする
必要はないので,リバースエンジニアリングで
鍵を抜き取ることはできないはず,
ということを意図していました.
Re: (スコア:0)
だいたい、
> Man-in-the-middle のような,プロトコル的な攻撃かもしれません.
どうしてここで man-in-the-middle なんて出てくるんですか。
守りたい目的は何ですか?通信内容の盗聴を防止することですか?違うでしょ。
目的は、当該ソフトのpeerに成り済まして当該P2Pネットワークに参加されるのを防ぐこと
でしょ?
man-in-the-middleは正当な通信当事者2者の間に入る攻撃手法の名称ですから、当該ソフトのpeerに成り済まして当該P2Pネットワークに参加するのに、middleも糞もない、自分自身が通信当事者なのですから。(わかりませんか?)
Re: (スコア:0)
ハードコードすることで秘密鍵が共有できているなら,
鍵交換する必要がないですよね?
>目的は、当該ソフトのpeerに成り済まして当該P2Pネットワーク
>に参加されるのを防ぐことでしょ?
てっきり,ノード間の通信内容を秘匿にしたいのかと思っていました.
たぶん,これが,話がかみ合わない理由ですね.
Re: (スコア:0)
> >ハードコードすることで秘密鍵が共有できているなら,
> >鍵交換する必要がないですよね?
>
> 意味がわかりません。
公開鍵暗号化を使う必要もなくて、AESでもDESでもいいじゃんってことでは?
Re: (スコア:0)
Re: (スコア:0)
ハードコーディングされてないと言えると思います。
perfect darkについて詳細を知らないのでなんともいえないですが、
Wikiを読む限り交換される際に始めて暗号化されているようなので、
ファイル受信側:公開鍵Pと秘密鍵S(RSA)を生成し、Pを送信
ファイル送信側:共通鍵C(AES)を生成し、Pで暗号化して送信
これでCを使ってファイルを暗号化する、という教科書的な方法だと思います。
今回の件ですが、たぶんファイルの情報をやりとりする部分だけは
暗号化されてないか、簡単な暗号化だったので解読できた、ってことではないでしょうか?
で、それを収集して解析した、ってことだと思います。
Re: (スコア:0)
そんなことをやっても何の意味もない。クローラーが生成した公開鍵を「ファイル送信側」に送れば、「ファイル送信側」がその鍵を元に暗号化してクローラーに送信してしまう。(意味わかる?)
ちなみにこういうのはman-in-the-middle attackとは言わない。
Re: (スコア:0)
いや、だから別ACだと・・・。
私が言いたいのは、単にあなたがハードコーディングが絶対されている、みたいな論調だったので、
それを否定しただけです。
man-in-the-middle attackでないというのもわかってますよ。
それとこれが成りすましの防衛にはならないことも。
なので今回の件は、ファイル送受信の暗号解読が主な方法ではなくて、
プロトコルを解析した上でクローラーがなりすまして情報を収集する、
という方法を取ったのだと思ってるのですが、それについてはどうでしょうか?
それとも、perfect darkが成りすましを防衛する完全な手段を取っていたという情報をお持ちでしょうか?
Re: (スコア:0)