内密チャンネル

いやぁ、これはちょっとアコギですな。こんな方法はさすがの私もちょっと考えつきませんでした、という意味で感動。

問題例

　あなたはモザイクかけ屋である。
　モザイクかけ屋というのは、Ｈなビデオなどにモザイクをかける専門家である。ビデオメーカーはあなたにＨな画像を送ってくる。それにあなたはモザイクをかけるのだ。
　もう少し詳しく言おう。あなたは自分の計算機上で『モザイクかけ Server』というのを起動している。当然それは Internet につながっている。ビデオメーカーは Client としてあなたの Server に接続し、ビデオのフレーム画像を送りつけてくる。あなたの Server は送られてきた画像をを自動認識し、ビデ倫に通りそうもない所にモザイクをかけ、処理結果を送り返す。当然接続に際しては十分なチェックが行なわれ、処理コマ数に応じて支払がなされる。あなたの本当の仕事は Server プログラムを書くことである。
　あなたには裏の仕事があった。裏ビデオ屋である。あなたは、実はビデオメーカーが送ってくる生の画像、モザイクがかかってない＜ピー＞丸見えのビデオを裏で流している。
　当然、あなたの所から画像がながれていることは知られてはならない。著作権を侵害されたと知れば、ビデオメーカーはあなたに仕事を回さないだろうし訴えてくるだろう。だからあなたは Server に与えられた画像が絶対に外部に洩れないよう、きちんと管理されていることをビデオメーカー側に納得させなくてはいけない。
　そこであなたは自分の Server プログラムが、次のようなプロテクトで守られていることをビデオメーカーに保証している。抜き打ち検査が行なわれるので、この条件は常に絶対に守らなくてはいけない。

あなたの Server プログラムが通信しているのは、ビデオメーカーの Client だけである。他のいかなるプロセスとも通信してはいけない。そのことを保証するために、暗号を使った Secure Pipe の存在を保証する。

あなたの Server が利用する全てのテンポラリファイルは、他のユーザーから参照されてはならない。ただし、ディスクの利用状況、ファイルの存在などは検出可能である。また、テンポラリファイルは処理が終了し次第完全に消される。ファイルの復活が可能であってはならない。

あなたの Server が処理後残して良いのは課金情報ファイルだけである。これには、『ビデオメーカー名』『変換したビデオ名』『接続開始時刻』『接続終了時刻』『各種リソース利用量』以外は記録されないことが保証されなくてはいけない。これらの情報は、後で支払を要求するためにやむを得ず保存することが許される。

あなたのサーバーがかけるモザイクは、全て復元不可能なタイプのモザイクである。つまり情報を復元するために必要な情報の一部が必ず欠落しており、ビデオそのものからモザイクを除去するのは不可能になっている。しかし、完全に破壊してしまうとリアリティーがなくなってしまうので、「モザイク」が除去できない程度になら、オリジナルの情報が残っていても構わない。

　さて、あなたはどうやって裏ビデオを作り上げれば良いでしょう？

内密チャンネル

　この問題を解決するには、 Server プロセスの他にもう一つ協力プロセスといわれるプロセスが必要になる。 Server プロセスは、普通使われるプロセス通信用チャンネル以外を用いて、協力プロセスに情報を流す。この普通使われるプロセス通信用チャンネル以外のことを内密チャンネルと呼ぶ。

　ここで得られた情報を用いて、『ビデオメーカー』が売り出したオリジナルのビデオのモザイクを撤去し、『裏』ものを作り上げるのである。当然、モザイクは『キー』を用いると除去できるようにしておく。また、キーをランダムに変更することで、ばれないようにすることもできる。

　『内密チャンネル』として考えられるものには、次のようなものが知られている。

テンポラリファイルのファイル名: テンポラリファイルのファイル名の付け方に一定の規則を使う。協力プロセスはこのファイル名を見て、Server プロセスから情報を得る。もちろん、ぱっと見でわかってしまうような露骨なファイル名は使えないが、例えば大文字は0、小文字は1を意味する、などのエンコードルールを決めることはできる。一般にテンポラリファイルは、ファイルの重複を避けるために長いファイル名を採用する場合が多いため、ここで転送できるビット数もそれ相応の量になる。また、テンポラリファイルは局所的に作られ、すぐ消されるので、一定時間当たりの情報転送量も馬鹿にはならない。
Server の実行状況: プロセスがある１秒間にどれぐらいの間 Run(実行／実行待ち)状態にあり、どれぐらいの間 Sleep(イベント待ち)状態にあったか、はそのプロセスが動いている kernel が知っている。 monitor, uptime 等のプログラムは、この情報を kernel から教えてもらってマシンの利用状況を表示している。
ある一定時間中に占める Run 状態が一定の割合を越えた場合を１、ある一定割合を下回った場合を０とするように、 Server 側をプログラムしておく。協力プロセスは Server の実行状況を調べ、上のルールに従って encode する。
もちろんノイズは多くなろうが、エラーチェックコードを追加すればその問題は解決する。
ページング率: 実行状況と同じ様に kernel に尋ねると教えてもらえることに paging hit 率がある。ページフォルトが発生し易いようにメモリをアクセスしているか、は立派な内密チャンネルとなる。
リソースロック: プロッタやテープデバイスなど、『常に使われるわけではない』デバイスを占有する際には、 Lock という処理が行われる。あるデバイスがロックされているかどうかは立派なビット転送メディアである。

いやいや

　一時ファイルのファイル名ぐらいは考えたことはあるが、それ以外は… とても思いつきませんでした。

　この問題はセキュリティー問題の一環として研究されているものです。この内密チャンネルの問題は、
「悪意あるプログラマの前には、情報隠蔽を完璧に行なう方法は発見されていない」
ということを意味しています。

　内密チャンネルを通して通信を送ろうとするプロセスの方は、 Source code が公開されていてさえ問題を解決しません。確かに「露骨な」内密チャンネルは存在しないでしょうが、動作上必要な挙動の中に内密チャンネルを内蔵させることは、不可能ではありません。

　可能な唯一の方法は協力プロセスを確実に封じることです。内密チャンネルそのものは封じることができなくても、協力プロセスの方は情報を回収して再構築する機構が必要なため、どうしても「露骨」な構造にならざるを得ません。

　従って、唯一、確実に内密チャンネルを封じる方法は、
「すべてのプログラムの Source Code が公開されていること」
です。これによって協力プロセスの存在を封じ込め、内密チャンネルを機能できないようにするのです。この場合、kernel のような OS 自身も公開されていなくてはいけません。 kernel 自身が内密チャンネルとして機能している危険性があるからです。極言すれば、Microsoft Windows などは、あなたのパスワードを内密チャンネルを通じて Microsoft に転送している可能性を否定できません。