ブラウザの「砂上の楼閣」：クライアントサイド暗号化の幻想と、XSSという名の鍵泥棒
「ブラウザ側で暗号化すれば安全だ」。この言葉を信じているアーキテクトがまだいるのなら、今すぐその設計図を破り捨てるべきだ。
セキュリティの現場で我々が対峙するのは、教科書に載っている「理想的な暗号プロトコル」ではない。メモリ上のビット反転、JITコンパイラの最適化バグ、そして何より、アプリケーション層に潜むクロスサイトスクリプティング（XSS）という、制御不能な「実行環境の汚染」である。
クライアントサイド暗号化は、多くの場合、セキュリティ上の気休めに過ぎない。なぜなら、その暗号化を司るスクリプト自体が、同じオリジン内で動く攻撃者の悪意あるコードによって容易に改ざんされるからだ。
XSSが「鍵管理」を無効化するメカニズム
格納型やDOM型のXSSを許した瞬間、ブラウザのメモリ空間は攻撃者の支配下に入る。たとえ SubtleCrypto API を使って暗号化を実装したとしても、攻撃者は以下の手順で鍵を無効化する。
1. フック（Hooking）: window.crypto.subtle.encrypt を上書きし、平文のまま外部サーバーへ送信する。
2. メモリダンプ: コンソールやデバッガを介さずとも、JavaScriptの ArrayBuffer を直接操作し、メモリ上に展開された鍵データを特定して抽出する。
3. イベントリスナーの乗っ取り: ユーザーが鍵を入力した瞬間の input イベントを監視し、キーストロークを盗聴する。
鍵を LocalStorage に保存してはいけないことは周知の事実だが、SessionStorage や変数（メモリ上）であっても、XSSが存在すれば無力である。ブラウザのサンドボックスは、同じオリジン内での権限分離を保証しないからだ。
鍵管理のベストプラクティス：鍵を「持ち込ませない」設計
「クライアントサイドで暗号化し、サーバーは復号できない」というゼロ知識証明的なアプローチを本気で実装するなら、以下のアーキテクチャが最低限の防衛ラインとなる。
1. 鍵の派生にWeb WorkerとContent Security Policy (CSP) を活用する
メインスレッドに鍵を置くのは自殺行為だ。暗号化処理を独立した Web Worker に分離し、メインスレッドからのDOMアクセスを遮断する。また、厳格なCSPを設定し、インラインスクリプトや外部からの不正な通信を徹底的に排除する。
// worker.js: メインスレッドから隔離された暗号化エンジン
self.onmessage = async (event) => {
const { data, key } = event.data;
// メモリ保護のため、処理終了後は即座にkeyをゼロクリアする仕組みが必要
const encrypted = await crypto.subtle.encrypt(
{ name: “AES-GCM”, iv: crypto.getRandomValues(new Uint8Array(12)) },
key,
new TextEncoder().encode(data)
);
self.postMessage(encrypted);
};
2. 鍵は「セッションごとの使い捨て」かつ「短命」に
Web Crypto APIの extractable: false プロパティを必ず活用せよ。これにより、鍵の生データはJavaScript側から直接読み出せなくなる。
// 鍵のインポート時に抽出不可（extractable: false）を設定
const key = await crypto.subtle.importKey(
“raw”,
keyBuffer,
{ name: “AES-GCM” },
false, // 鍵の抽出を禁止
[“encrypt”, “decrypt”]
);
アーキテクトへの警鐘：耐量子時代を見据えた防衛層
現在、我々が実装しているAES-256やRSAは、量子コンピュータの時代には脆弱になる可能性がある。耐量子暗号（PQC: Post-Quantum Cryptography）への移行を検討する際、クライアントサイドのパフォーマンスは致命的な障壁となるだろう。
生成AIの登場により、プロンプトインジェクションと同様のロジックで、複雑な暗号化ロジックをリバースエンジニアリングする攻撃も現実味を帯びている。AIは数行の難読化されたJavaScriptを解析し、暗号化のアルゴリズム的な脆弱性を見つけ出す。
結論：防御の多層化と「脆弱性前提」の設計
クライアントサイド暗号化を「唯一の防衛策」と考えるのは危険な幻想だ。以下を肝に銘じてほしい。
- XSSは根絶できないという前提で動く: DOMPurifyを用いた厳格な出力エンコードを徹底し、信頼できない入力値は決してスクリプト実行パスに乗せない。
- 鍵はブラウザに永続化させない: 必要な時にバックエンドから受け取り、利用後はメモリから即座に消去する（ゼロフィル）。
- サーバーサイドの監査を疎かにしない: 暗号化はあくまでクライアントの機密保護であり、サーバーサイドでの入力検証や権限チェックを代替するものではない。
真のセキュリティとは、脆弱性が存在することを前提に、攻撃者が「コストに見合わない」と判断して撤退するまで、いかに泥臭い障壁を積み重ねられるかにかかっている。スマートなコードを書く前に、攻撃者の視点でメモリの深淵を覗く。それこそが、我々エンジニアに求められる責務だ。
コメント