１−４： 課題-2
黒田 歩は、放流されたwormに宛てた自滅コードを目の前のワークステーションに設定すると、自分の机に戻ろうとした。ワークステーションが置かれている部屋から出るころには、ビープ音は止んでいた。
自分の机に戻り、書架から本を二冊取り出した。一冊はFORTH 83-Standardに関するもの、もう一冊は公開鍵暗号に関するものだった。
記号処理――あるいは文字列処理と言った方が適切だろうか――に関する機能に重点を置いた、FORTHに似た言語。それは黒田 歩が学部時代から設計を続け、何十回と仕様を改訂し続けてきた言語だった。FORTHの実装はシンプルであり、コンパクトである。その仕様と実装をもう一度確認したかった。研究ノートを開き、自分が設計し続けている言語の最新の――だが一年前の――仕様と照し合わせた。この目的のためには、ノートに記録された仕様よりも、かなりシンプルに、そしてコンパクトにできそうだった。だからこそ、この言語につけている仮の名前を、wormのための言語の名前にはしたくなかった。
そして、公開鍵暗号については、実行系が固定されているのであれば、認証局に送るハッシュ値を記録しておき、そのハッシュ値を認証局に送ることは可能だろう。
ならば、ダウンロードのたびに一部を――それはコメントであってもかまわない――書き換えた実行系を、発行局から得るとともに、認証局の公開鍵を用いてハッシュ値を求め、そのハッシュ値を認証局に送るか。
あるいは、この部分を逆にする方がいいのだろうか。サーバの公開鍵を認証局に登録する方法とする。発行局はダウンロードのたびに一部を書き換えた実行系をサーバに与えるとともに、サーバは自身の秘密鍵によるハッシュ値を求め、それを認証局で公開鍵を用いて検証すればいい。
それはできるように思えた。ただ、黒田 歩にとって公開鍵暗号はまだ目新しいものであり、どちらの使い方が本来の使い方として想定されているのかの判断が――本を眺めても――つかなかった。だが、この機能をサーバに埋め込んだなら、wormの実行系を見えにくくはできるように思えた。すくなくとも、サーバのパッケージには実行系は含まれない。最初から危険な状態ではない。サーバのメンテナに多少の負荷がかかるとしても。改変に手間がかかるようになるだけだとしても。
こういう、wormに似たものがすでにあるとして、それではどのような方法を取っっているのだろう。RFCの一覧を確認してみる価値、あるいは必要はあるだろう。そのようなものが存在しないとしても、参考になるものはあるかもしれない。ともかく、SSHは参考として確認する候補には挙げられるだろう。
黒田 歩は開いていた二冊の本を持ち、ワークステーションの前に戻った。ftpでRFCの一覧をIANAからダウンロードした。一覧をviで開き――それはモード付きであるために誤った改変を避けるためだった――、SSHを検索した。だが、一覧にはSSHの文字列はなかった。もちろん、SSHという文字列が現れているとは限らなかった。そこで "Secure Shell" で検索した。それでも一覧には見つからなかった。
「RFCに既にあるかと思ったが」
その想定は、根拠がないものではなかった。ポート番号が小さい。それだけで根拠としては十分であるように思えた。
先に研究室のワークステーションにSSHをインストールした際の、ソースとドキュメントから、デフォルトのポート番号を確認し、もう一度RFCの一覧に戻った。しかし、やはりSSHについてのRFCはないように思えた。
黒田 歩はIANAにもう一度ftpでアクセスし、ポート番号の一覧をダウンロードした。ポート番号からの確認の方が簡単だろうと思ったからだった。しかし、その一覧にもSSHは載っていなかった。
「となると、SSHのポート番号はIANAに予約済ではない? こんなに若い番号なのに?」
黒田 歩はSSHのドキュメントをviで開いた。
黒田 歩は、情報カードに「RFCを確認」と書いた。
「大袈裟な話になるな」
黒田 歩は、研究ノートを前にして呟いた。
「だいたい、発行局と認証局の確実さはどう確保する？ それに、発行局に一回要求を出したなら、実行系は手に入る。結局、実行される実行系を確実にするには程遠い」
手順を面倒にする方法であれば、なくもなかった。wormの機能において必要とされた部分ごとに実行系をスライスし、ダウンロードと認証を行なう。それでも、結局のところ実行系の全体は再現されるだろう。
