ちいさな金庫を作った話 (3) — できることと、できないこと
※ 注意書き この記事はシリーズ「ちいさな金庫を作った話」の第3回です。 技術系の話なので、面白くはありません。
1.
「サーバーが中身を読めない、未来からも読まれない、自分のためのファイル受け渡しツール」を作る。
そう決めて始めた個人プロジェクトだったけれど、いざ手を動かし始めると、最初に思っていたほど単純な話ではなかった。
技術的に難しい、という意味ではない。世の中の良くできた部品を組み合わせれば、暗号の処理そのものは数日で形になる。
難しかったのは、判断の方だった。
「ここはどう設計するべきか」を考え始めるたびに、思いがけない落とし穴が現れて、その都度、最初の設計を書き直すことになった。
2.
最初に書いた仕組みは、こんなものだった。
ファイルを暗号化する。鍵をかける。そして、その鍵を URLに埋め込んで 、受け取り手に送る。
「鍵が入った特別なURL」を渡す。受け取った人は、そのURLを開けば自動的にファイルが解錠されて表示される。シンプルで便利だ。
実際、似たような仕組みのサービスは世の中にいくつかある。動く。便利だ。
でも、しばらく作業を進めているうちに、ふと気がついてしまった。
URLというものは誰かに送る瞬間に、そのメッセージアプリやメールの中を通過する。LINEなり、Slackなり、Gmailなり。そしてそれらはサーバーに保存される。サーバーは中身を読める。
つまり、わたしが「サーバーには中身を読ませない」と頑張って暗号化した結果が、URLという形で、別のサーバーには丸見えの状態で流れていく。
これは矛盾だ。
しかも、ここで前回の話に戻る。収穫攻撃 だ。誰かがその URL を傍受して保管しておけば、未来に量子コンピューターが完成したとき、その URL から鍵を取り出して、保管されている暗号文を解読できる。
「ハイブリッドの最新暗号を使っています」と胸を張っても、URLが裸で流れていたら、結局意味がない。
書き始めたばかりのコードを、いったん全部捨てることにした。
3.
書き直した設計は、こうだ。
ファイルを受け取りたい人(以下、受信者)が、自分のブラウザの中で、自分専用の 鍵のペア を作る。鍵には「公開鍵」と「秘密鍵」という二つの役割がある。
公開鍵は世界に見せていい。本当に誰に見られても問題ない。 秘密鍵は受信者のブラウザの奥深くに保存されて、外には絶対に出ない。
ファイルを送りたい人(以下、送信者)は、受信者の 公開鍵 を受け取って、それを使ってファイルを暗号化する。
公開鍵で暗号化されたものは、対応する秘密鍵でしか開かない。
このマジックのおかげで、ファイルがどこに保存されても、URLが誰に見られても、肝心の秘密鍵を持っているのは受信者本人だけだから、解読されない。
URLにはもう鍵を入れない。URLはただの「サーバーのどこに置いてあるかの番地」を示すだけだ。番地が漏れても、鍵がなければ箱は開かない。
ここまで考えて、ようやく、最初の「サーバーが中身を読めない」「未来からも読まれない」という思想が、設計の中で一貫した。
4.
もうひとつ、捨てた機能がある。
最初は、ファイルを受け取った受信者のブラウザで、画像や動画やPDFを その場でプレビュー表示 する機能を入れるつもりだった。便利だし、当たり前にあるべき機能のように思える。
でもよく考えたら、これも変な話だった。
「サーバーに保存させない」「ディスクに書き込ませない」「メモリの中だけで扱う」と謳っているのに、プレビューのためにブラウザの画像表示機能や動画再生機能にデータを渡したら、そこから先はブラウザの仕事になる。
ブラウザはどう振る舞うか分からない。一時ファイルを書くかもしれない。サムネイル用のキャッシュを残すかもしれない。OS の機能経由で、スクリーンショットが自動で撮られるかもしれない。
つまり、わたしが 「メモリの中だけ」と言いながら、ブラウザに任せた瞬間に、その約束は事実上、わたしの手を離れている。
これも矛盾だ。
なので、プレビュー機能は実装しないことにした。受信者は、メタデータ(ファイル名、サイズ、送信時刻)だけを画面で見る。中身を見たければ、自分の意志で「保存」ボタンを押して、普段使っている画像ビューアやPDF閲覧ソフトでファイルを開く。
「保存しない、というのは、本当に保存しないということ」 。
便利さを少し失う代わりに、思想の一貫性を守った。
5.
最後に、運用上のひとつの工夫について書く。
このツールでは、受信者が無事にファイルを受け取って解読できたその瞬間、サーバー側のファイルは自動的に削除される。
理由はシンプルだ。
サーバー上に長く置いておくほど、何らかの形で漏洩するリスクが増える。受信者が受け取ったら、もうそのファイルがサーバー上に存在する必要はない。むしろ、存在し続けることが危険だ。
受け取った瞬間に消える郵便ポスト、と表現してもいい。世界で一つだけのコピーが、世界で一人だけに届く。それで配達は完了する。中継地に痕跡を残さない。
これも、新しいアイデアではない。昔、Firefox が一時期やっていた送信サービスや、Wormhole という別のツールが、同じ発想を採用していた。
ありがたく真似をさせてもらった。
6.
そんなふうに、書いては捨て、考えては書き直し、いくつかの便利さを諦めながら、ひとつの道具ができあがった。
名前は Personal PQC Drive とつけた。「PQC」は「Post-Quantum Cryptography」、つまり「量子コンピューターのあとの暗号」という意味。
機能はシンプルだ。受信者が自分のブラウザで鍵を作る。その公開鍵を送信者に渡す。送信者はファイルを暗号化してアップロードする。受け取った URL を受信者に伝える。受信者は URL を開く。ファイルが解読される。サーバー上のファイルは消える。
それだけ。
ファイル一個を送るだけのことに、これだけの仕組みを使う。たぶん、ほとんどの人にとってはやり過ぎだ。
でも「やり過ぎ」を一度ちゃんとやってみたかった。何を妥協していて、何を妥協していないのか、自分で全部分かっている道具を、一度持っておきたかった。
7.
正直に書いておかなければならないことがある。
このツールでも防げないことが、いくつかある。
受信者のパソコンが、最初からウイルスに感染していたら暗号は無力だ。せっかく安全に届いたファイルが、開いた瞬間に盗まれるかもしれない。
受信者が自分の秘密鍵を失ったら、ファイルは永遠に開かなくなる。これは、検閲フリーであることの代償でもある。
受信者本人が、受け取ったファイルを別の場所に転送してしまったら、その先のセキュリティは、もうわたしのツールの管轄外だ。
「完璧な暗号」と「人間の運用」の間には、いつも溝がある。
その溝を、技術だけで埋めることはできない。
8.
ここまでの話を、なぜ書いたか。
最初に書いた通り、X で誰かのアカウント凍結の話を見たことがきっかけだった。気の毒だな、と思った。そして自分にも起こりうるな、とも思った。
「自分の大事なものを、いつ消えるか分からない場所に預けている」というこの不安は、特殊な誰かの問題ではない。わたしのスマートフォンの中の写真も、あなたのクラウド上の文書も同じ条件下にある。
世界中の頭のいい人たちが、この問題に取り組んでいる。NIST も Google も Cloudflare も Apple も。何年もかけて、新しい暗号の標準が決まり、世界の通信に少しずつ組み込まれていっている。
わたしのような個人エンジニアにできることは、ほんのささやかなことだ。誰かを救うアプリではない。世界を変える発明でもない。
でも、ひとつだけ言えることがある。
「自分のデータが、自分のものである」という当たり前のことを、当たり前にしておくための仕組みは、本気で考えれば、個人の範囲でも作れる時代になっている。
それを実際に手を動かして確認できたことが、このプロジェクトの一番の収穫だった。
道具は GitHub に置いた。MIT ライセンスなので、誰でも好きに使っていい。ただし、わたし自身は商用サービスとして運用するつもりはない。あくまで、自分のための、個人プロジェクトだ。
明日、また Google のアカウントが凍結された人の話が流れてくるかもしれない。そのとき、ちょっとだけ落ち着いていられるための、自分への保険のようなものだと思っている。
もし将来、誰かが量子コンピューターで世界中の暗号通信を解読し始める日が来たら、そのとき初めて、この個人プロジェクトの意義が本物になるのかもしれない。
そんな日が来ないことを願いながら、しかし、来てもいいように、わたしは今日も、自分のためのささやかな箱を作っている。
技術的な詳細を知りたい方は、こちらをどうぞ。 https://github.com/anthamayfair11/personal-pqc-drive
(完)
