書き込みログのIP&リモホを見た目わからなくする方法を考えよう
サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね、
これが出来たら、乗っ取られたっていいジャン! になる。
誰か方法考えてちょ base64変換だけなら可逆だよ
MD5までやっちゃうと難しいけど ・別ユーザのデーモンで暗号する
・復号は別のサーバーで行う 付与するキーを、別鯖から取得して暗号化。
復号時にも同じく別鯖から取得して復号化。
・・・かなぁ。。。 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね 復号鍵は、どこのサーバ内にも保存せず、作業時に自分のPCから毎回送信するとか。
あるいは復号作業を自分のPCでやるとか。 復号鍵をおいちゃんのPCにだけ置いておくほうがいいと思う
でも鯖に侵入されたらログをみてIPやリモホは分からなくても、ログを消去される可能性が残るということをお忘れなく。 >>11
削除要請で裁判所からのIP開示に対応しないと駄目だから
個人のPCに復号鍵を置くのは、ちょっと。。 >>12
じゃぁ芋掘り出来る人全員に鍵持を持ってもらうってのはどうなのよ。
実際に芋堀りできる人がどれくらいいるのか分からないからなんとも言えないけど。
・・・この場合だと、「ある人から芋掘り権を剥奪する」という操作が不可能だな。鍵は全員同一のものになってしまうから。
あるいは、復号化鍵はqb7あたりにおいておいて、qb7の窓口から芋掘り。
qb7にはいられたら終わりだけど、qb7は堅牢だという前提で・・・。
芋掘り人
指示↓ ↑芋
qb7鯖 ←復号処理
指示↓ ↑暗号化芋
掲示板鯖 削除要請や裁判所がどう関係するのかわからない。
作業するのは1人だけじゃないって意味?
これは、IPアド閲覧権限者で復号鍵を共有することになるね。
この点は従来のアクセスパスワードを共有しているのと同じ。
まあ、ウェブサーバと個人PC、どちらが安全性が高いかっていうと、
色々な考え方ができるんだろうけども。
ただこれもパスワードのメモを保存するのと同じか。 確かに剥奪時の問題はあるんだけど、暗号化ログを取得するにも
何らかのアクセスパスワードがかかるはずだから、そこで制御するとか、
1年とか一定期間ごとに鍵を変えるとか。
ログ保存も永遠じゃないしな。 qb7に鍵を置くのはいいんですけど
その鍵は一定時間ごとに変更される仕組みも必要では? >>16
うん。
作業者が複数って端的に言えば済むところを、削除要請や裁判所を
持ち出すのは何か別の意味があるのかなと思っただけ。 >>18
書き方が悪かったかな。。ごめん。
まぁ、そういう事なんで複数の人が使う事を前提に考えなきゃ駄目なんだよ。
複数といっても、そんなに多くは無いと思う。 >>17
一定期間ごとに自動で鍵を作り直す・・・とか? 別サーバーで、登録したMACアドレスのみアクセスできるようにするとかはダメ? MACアドレスは参照しない方がいい。
MACアドレスは絶対にユニークな値ではないよ。
書きかえられるし。 MACアドレスの書き換えは可能だけどほぼ生IPになる
proxy使用 -> proxy鯖のMACアドレスに置き換わる
ソケット串 -> proxy同様
やらないよりはやった方がマシなレベル MACアドレスはユニークでないのはもちろん、どのレイヤーのものかを考えると…… PIE外に設置してる鯖とのやり取りが不可能になるか。
MACアドレスは忘れてくれ。 >>9
> 公開鍵方式なら、暗号化鍵は鯖内にあっても、侵入時でも安全だね
あらゆる意味でダメだろw
・ハックされて、秘密鍵側をとられたらおしまい。
・それ以前の問題として、IPアドレスなんて有限通り(32ビット)しかないんだし、しかも、ほとんど
日本発信のアドレスレンジはもっと狭い → カギ公開してたらブルートフォースで作表されてしまう。 よく考えたら、これって公開鍵暗号方式だけの問題じゃないね。
(可逆・不可逆を問わず)ハッシュ関数的なルーチン(ファンクション)かましたって、
いずれ作表されてしまう。
関数(鍵)を変えていく、としても、「そのログに対応した関数(鍵)」は一意に決まって
しまうので、逃げようがない(時間かければいずれ解かれる)。
つうことで
サーバ乗っ取られて書き込みログを見られてもokにしよう。
IPアドレスとかリモホり部分っすね
これってそもそも不可能じゃね いや「絶対」とかそういう次元の問題じゃなくて
・復号側→複数の人がIP復号化作業をする必要性があるらしいので(芋掘り、裁判所対応)
結局、パスワードで作業管理している現状とリスクレベルあんまかわらない。
・せめてログ上、IPアドレス(リモホ文字列)だけでも暗号化できないか→母集団が少なすぎて
ブルートフォースで作表できてしまう。表さえできれば、逆引きは一瞬w
詰んだ そもそも平文の母集団が少ないのは前提であって、それに対してイカに復号化を難しくするかってとこだろ
いやここでv6アドレスを使えば… そもそもPIE内でMACアドレスが重複した事件とか忘れたわけじゃないよねみんな >>32
"<適当な乱数とかめちゃくちゃな文字列>。ここからリモホ→<>i118-16-76-46.s10.a027.ap.plala.or.jp<>
118.16.76.4<>←ここまでリモホ。<適当な乱数とかめちゃくちゃな文字列>"
という超長い文字列を作ってからハッシュかける。
文字列乱数は、毎回変えれば、母集団は無限大になるので、作表は不可能。
他方、復号化したあと「人間ならば」見りゃどこがIP・リモホなのかはわかる。
どうだ?w >>34
それならログに残る本文(の一部)を使えばいいと思うの。 >>35
うむ。日付と時間含むだけでも相当散るよねw IPアドレスの母集団が少なくて、暗号化してあってもログが流出すると総当りで解読されるって言うなら、
まずIPアドレス鍵をランダムに作り、これでIPアドレス・ホスト名を暗号化する。
そのあと、別の公開鍵(固定)でIPアドレス鍵を暗号化して、暗号化IPアドレス・ホストと一緒に記録。
芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)で、IPアドレス鍵を復号化して、
これでIPアドレス・ホストを復号化。
IPアドレス鍵はランダム生成なので十分大きい母集団を持つ。これでどうよ >>37
> 芋掘り時には、秘密鍵(おいちゃんと一部の削除人保有)
結局、これって、現在のパスワード方式による芋掘りとリスクレベルはおんなじなんだよね。
暗号設計の問題じゃなくて、「体制」の問題と思う。
複数人で共通鍵を共有したら、クラッカーの攻撃で漏れるのは時間の問題。 >>38
最初の趣旨が何であったか思い返しましょう。
今回の話は、芋掘りしていない書き込みログそのものが見られても大丈夫な様に、
という所がスタートです。
芋掘り作業のパス漏洩とかはまた別レベルの話だと思います。
>>39
なるほど。
じゃあ、鍵ペア(ふつうなら、秘密鍵・公開鍵だが、今回は母集団問題があるので両方公開しない。鍵A・鍵B)
作って、
@ ログ作成時に鍵Aで暗号化(したがって、鍵Aは鯖/CGI内においてある)
A IPアドレスやリモホ文字列だと母集団問題が如実に出るので、ヘッダーとか本文の最初の2行くらいをコミコミ
で暗号化
B 鍵Bは、おいちゃんと一部削除人がローカルにもつ。鯖にはおかない。
C 必要に応じて、鍵Bを使って復号化
こんなとこか? しかし生ログが漏れた時点で時間さえかければどうにでもなっちゃうよね。 >>40
でもログの形式も判明しているのだし、書き込みの何バイトがログに入るのかも分かっている。
そうするとやっぱりIPアドレスとホストぐらいしか未知要素が入り込まないわけで、尚且つIPアドレスからホスト名は
大抵の場合求めることができる。すると、1つの書き込みの、ログのバリエーションはIPアドレスの数とだいたい同じ。
>>34みたいに、表に公開しないランダム固定長文字列をログに付けて暗号化したほうが良くない?
別に可変長でもいいけど十分長ければいいわけで、スクリプト上での扱いが固定長のほうが楽だから。
で、ログを表に公開するときもこのランダム文字列は公開しない(掘って復号した後に除く)。 User-Agent、●、P2、の情報もあるよ。
まあ、ランダムデータを混ぜる方が安全ってのはあるね。 >>41
暗号の安全性ってのは、現実的な時間で解読できなければ、
それは安全ってことなのよ。 【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。
【方法その1】
非対称鍵で暗号化する。
■ 復号鍵をサーバに置く場合
・作業スクリプトで、作業者を認証管理する。
・復号鍵を置いているサーバや作業スクリプトの安全性が頼り。
└> サーバの侵入や漏洩を前提にした暗号化に対して、復号作業サーバの安全性は前提にできるかどうか。
■ 復号鍵を作業者が各自で保有する場合
・作業スクリプトで、作業者を認証管理した上で、復号鍵を作業スクリプトに送信する。
・掲示板サーバや復号作業サーバで侵入や漏洩が起きても、暗号は安全。
・同じ復号鍵を、作業者全員が保有する。
・各作業者の情報管理が頼り。
└> ウェブサーバと個人PC、どちらが安全か。
・権限抹消された作業者から復号鍵を取りあげることができない。
├> 定期的な鍵の変更が必要か。
└> 作業スクリプトの認証で足りるか。 >>45
> 権限抹消された作業者から復号鍵を取りあげることができない。
>>37の方式で、作業者の数だけ鍵ペアを用意し、IPアドレス鍵をそれぞれの作業者の鍵Aで暗号化して
格納しておけば、抹消以後については取得できなくなるけどね。
逆を言えば、新しく権限を付与された人でも、付与以前のログは読めない。 【目的】
サーバ乗っ取られて書き込みログを見られてもokにしよう。
【方法その2】
IPアド公開掲示板へと生まれ変わる。
開示訴訟にさようなら。 siberiaの時代到来ですね
>>34-35の組み合わせがいい予感 >>47
「IPアドレス鍵」ってのがよくわからない。
鍵が膨大な数になっちゃう?
とりあえず、
復号鍵を、サーバに、作業者の数だけ別個に暗号化して置いておき、
作業者は、自分用の「暗号化された復号鍵」の復号鍵を持つ、とすればいいのか。
権限抹消時は、その人用の「暗号化された復号鍵」を削除すると。
2段階あるだけに、面倒といえば面倒だし、安全といえば安全。 >>34って独立した案なの?どれかの補足?
案なら、ハッシュの復号をどうするつもりかわからない。
IPアドレスだけじゃ、総当りで暗号化して暗号データの比較で
正解を見つけられるって懸念への補足なら、付加するのは
ランダムデータでいいんじゃないの。 >>47
IPアドレス鍵は鍵の長さに応じたバリエーションを持つ。
ちなみにIPアドレス鍵でIPアドレスを復号化するのは共通鍵暗号ね。
で、IPアドレスを暗号化した後、IPアドレスの鍵を、もう一度、別の鍵(これは非対称鍵)で暗号化して、一緒に記録。
>>51
普通「ハッシュ」っていうと不可逆なやつだよね。多分そこを誤解して>>34は書いてるんだと思う。
つまり、普通に非対称鍵で暗号化するにあたり、IPアドレスだけだと255^4しかなくてテーブルを生成するのが
容易だから、長い文字列を作ってからにすればいいじゃんってことだろ。
「適当な乱数とかめちゃくちゃな文字列」って書いてあるけど要するにランダムデータだろ。 非対称鍵暗号を採用するとしても、2ch程度の機密性なら
復号鍵を作業サーバにおいといても良いとは思うんだけどね。
侵入が前提って点は、掲示板サーバと復号作業サーバとで、
サーバパスワードは違うものを使う、
掲示板サーバと同じスクリプトを置かない、
とすれば、危険性の度合いも変わるでしょ。
削除やキャップも拠点サーバで作業するって方向みたいだし、
そういう作業用サーバは全体をbasic認証でもかけておけば、
今回の事件みたいな丸見えの危険性も低減される。
その程度で十分なんじゃないかなーと。 書き込みログ見れる人は
・2ちゃんねる ★ (裁判などのログ開示)
・削ジェンヌ ★
・FOX ★(の中の人 ログ堀キャップいっぱい所有)
・boo (串焼きスクリプト)
>>52
ハッシュでxor取ってそのあと煮るなり焼くなりすれば
同じIPからの投稿でも書き込み内容によって暗号化されたものは変わってくる あーIPアドレス鍵がやっとわかった。
IPアドレスをごまかすのに、
ランダムデータを付加するか、
鍵をランダムにして更に鍵を暗号化するか、
の違いということか。
比べると、手間のわりに利益が少ないかなあ。 自分でランダム鍵を更に暗号化の案を出しておいてアレですが、
ランダムデータ付与のほうでいいような気がします。
ランダムデータを付与して、普通に非対称な鍵で暗号化する場合は>>45の方法その1にあたる。
あとは復号化鍵をどう扱うか、だが・・・ 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。
なので、Log自体は共通鍵暗号で暗号化して、その鍵を公開鍵暗号で暗号化して
保存する方法しかないだろうと思います。(SSLのような感じ。)
ただ、Logの暗号化をbbs.cgiでやろうとするとやっかいな点が1つ。
複数起動するbbs.cgiがそれぞれ異なる鍵(乱数)でLogを暗号化すると、
鍵の扱いがとても大変になる可能性があります。
Logを暗号化して保存するデーモンのようなものを作る必要があるかも。 logbufferとかいうのがいたと思うからそれに手を加える事になるのかな こないだでたCPUはAESなら馬鹿みたいに速いんだよね。
専用ハードウェア内蔵だから >>57
> 非対称な鍵を使う暗号、例えばRSAなんかでLogを暗号化するのは無理だと思います。
> というのも、RSAのような公開鍵暗号は、AESのような共通鍵暗号に比べると
> 処理速度が3桁くらい遅いからです。たぶんサーバに与える負荷が大きすぎるかと。
そもそも「書いた瞬間に裁判所から仮処分」とか「直ちに芋掘り」とかありえない。
だから、とりあえずは生ログか、簡易な共通鍵暗号化しておいて、負荷の低い時間帯(朝5時〜9時くらい?)
に一気に暗号化すればよい。