経路の暗号化とデータの暗号化では要件が異なる

数学ガール・シリーズを読んでる途中だが，気になる記事を見つけたので。

以前の記事で紹介した「情報処理」2020年7月号内の PPAP 座談会で妙に Firefox Send を推してるなぁ，と思っていたが（笑），実は件のサービスが一時停止に追い込まれているらしい。

• 無償のファイル送信サービス“Firefox Send”が一時停止中 ～マルウェアによる悪用が増加 - 窓の杜

なんでも

“Firefox Send”が利用する“send.firefox.com”というドメインは比較的信頼されており、スパムメールフィルターをパスしてしまったり、警戒心の高いユーザーでさえも気を許してクリックしてしまう可能性がある。

とのこと。

私は今回の件で Firefox Send 側に瑕疵があるとは思わない。 でも詐欺（social engineering）の温床になるのであれば，最悪は閉鎖せざるを得ないだろう。 ニンともカンとも，お気の毒なことである。

暗号化の手段

あるデータを暗号化技術によってオンラインで安全に運ぶための手段としては，大きく2つある。

1. 経路の暗号化
2. データの暗号化

例えば TLS (Transport Layer Security) は典型的な「経路の暗号化」である。 暗号化メッセージング・サービスも基本的には「経路の暗号化」によってメッセージの秘匿を達成している。

Firefox Send は一見「データの暗号化」に見えるかもしれないが，実は「経路の暗号化」に分類できる。 何故なら Firefox Send はデータ送受信のエンド・ポイントには介入しないからだ。 ここに犯罪者の付け入る余地がある。

経路の暗号化の4要件

経路の暗号化の要件には以下の4つがある。

1. 機密性（Confidentiality）
2. 完全性（Integrity）
3. 認証（Authentication）
4. 否認可能（Deniability）

経路の暗号化の場合，セッション中になりすましや改ざんがないことは勿論だが，セッション終了後のいかなる時点でも内容が再生されないこと，が要求される。 そのためには「否認可能」であることが必要なのだ。

「否認可能」を達成する方法としては PFS (Perfect Forward Secrecy) を組み込む手がある。 また，暗号技術そのものではないが，セッション中のトラフィック・データやログなどを正しく破棄する運用が必要である。 まぁ，ログはそもそも取らないのが最善なのだが。

データの暗号化の4要件

一方，データの暗号化の要件は経路の暗号化の要件とは少し異なっている。

1. 機密性（Confidentiality）
2. 完全性（Integrity）
3. 認証（Authentication）
4. 否認防止（Non-repudiation）

見ての通り，注目は4番目の「否認防止」である。

「否認防止」とは，「データを送った」という事実を送信側が否定できないこと，を指す。 もっと簡単に郵便の比喩で言うなら「内容証明付き」のデータにするということである。

これを達成するには永続的（証明（certification）された公開鍵がセッションやドメインを超えて有効であること）な鍵で電子署名すればよい。

データの暗号化を端折ってはいけない

注意すべきは「否認可能」と「否認防止」は要件としては真逆である点だ。

もし Firefox Send で送るデータに最低でも（経路の暗号化とは異なる鍵で）電子署名を付与していれば多少はリスクを軽減できたかもしれない。 まぁ URL で釣る（phishing）のはオンライン詐欺の常套手段なので，そもそも URL を渡すアイデアが微妙なのかもしれないけど。

公開鍵暗号方式を利用した暗号化を面倒臭がる人は多く¹，これを隠蔽または回避するために（経路の暗号化のみで）データの暗号化を端折るサービスやアプリケーションが多いが，データを（暗号化技術を使って）安全に受け渡ししたいのなら端折ってはいけない。

ブックマーク

• Mozillaがファイル転送サービスのFirefox SendとメモアプリのFirefox Notesの開発を断念 | TechCrunch Japan : やはり閉鎖になったか…

参考図書