午後十一時四十二分。
イトは黒い保管箱の三つの鍵穴を見つめていた。
中央には、青い新型key。
左には、すり減ったbrass key。
右は空いている。
箱の表面には、白く日付が浮かんでいた。
OPEN AFTER 2046
「二十年守るなら、いちばん新しい鍵だけにすればいい」
イトはbrass keyを抜き、blue keyだけを奥まで挿した。
保管箱の一面が青く光る。
次の瞬間、復旧端末が赤くなった。
night backup starts 00:00
future vault READY
recovery terminal NO COMMON PROFILE
restore test BLOCKED
time remaining 18 min新しい鍵は入った。
古い記録を開く道は、消えた。
今日読めない暗号文も、明日まで捨てられるとは限らない
保管箱には、町の通信設備を写した画像、見学者名簿、古い設定、未公開の調査記録が入る予定だった。
最長の保存期間は三十年。
「量子computerが今夜来るわけじゃないのに、急ぐ必要ある？」
ユイは、箱に付いていた小さなlogを開いた。
encrypted traffic collected today
readable today no
stored for later yes
future decryption capability unknown暗号文をいま読めなくても、収集して保存することはできる。
将来、現在使われる一部の公開鍵暗号を破れる能力が現れたとき、保存していた通信を解読しようとする。
このriskをharvest now, decrypt laterと呼ぶ。
量子computerがいつ実現するかを当てる話ではない。
risk window
data lifetime
+ migration time
compared with
uncertain threat arrival秘密を長く保つ必要があり、移行にも長い時間がかかるなら、「実機ができたら始める」では遅い可能性がある。
新しい標準は、一つの万能鍵ではない
NISTは2024年、最初の三つのPQC標準を確定した。
FIPS 203 ML-KEM key establishment
FIPS 204 ML-DSA digital signature
FIPS 205 SLH-DSA digital signatureML-KEMは、公開channel上で共有secretを確立するためのkey-encapsulation mechanismだ。
ML-DSAとSLH-DSAは、改ざん検知や署名者の認証に使うdigital signatureだ。
「PQC対応」と一語で書いても、通信の鍵確立、certificate、code signing、firmware署名、保存鍵の保護では役割が違う。
blue keyを全ての鍵穴へ挿すことはできない。
よくある誤解：最新のPQC algorithmへ一括交換すれば、移行は終わる
algorithmが標準化されても、実際のsystemは一つではない。
protocol、library、certificate、hardware、service、partner、復旧端末が互いに依存している。
新しい鍵や署名は、message、public key、ciphertext、signatureのsizeや処理条件も従来と同じとは限らない。
片側だけを替えれば、通信できないことがある。
古いbackupを復元できなくなることもある。
移行の入口は、導入buttonではなくcryptographic inventoryだ。
where used
system / app / service / device / data flow
what used
algorithm / protocol / key / certificate / library
why and how long
confidentiality / integrity / authentication
data lifetime / key lifecycle
who and what depends on it
owner / vendor / partner / recovery pathkey materialそのものを台帳へ並べるのではない。
どこで、何の目的で、誰の責任で暗号を使い、何とつながるかを記録する。
夜間backupまで十八分。三つの選択
future vaultはblue keyで待機している。
復旧端末は接続できない。
今夜のbackupは、午前零時から三十分だけ動く。
A：残りのsystemもnew-onlyへ切り替える
表面上は最短でPQC対応になる。
しかし、見つけていないdependencyまで同時に壊し、backupは書けても復元できない状態を作るかもしれない。
B：blue keyを抜き、調査を無期限に延期する
今夜のbackupは守れる。
一方、三十年残すdataも同じpriorityで先送りし、HNDL riskと長いmigration lead timeを放置する。
C：現在設定を戻し、inventoryを作り、最長寿命dataの経路だけcanaryへ分ける
まず復旧可能性を戻す。
用途、owner、data lifetime、dependencyが分かった対象だけをtest laneへ置く。
productionへ触れる前に、接続、署名、backup、restore、rollbackを確かめる。
イトはblue keyへ伸ばした手を止めた。
「新しい鍵を抜くんじゃない。新しい鍵しかない状態をやめる」
イトが一括交換を閉じ、試験laneを開く
イトはfuture vaultをpauseした。
brass keyを元のrecovery slotへ戻し、blue keyは捨てず、透明なcanary caseへ移す。
変更前snapshotから、復旧端末のprofileを戻す。
rollback duration 43 sec
recovery connection RESTORED
production writes 0
backup window remaining 16 min戻る道を確かめてから、ラボ内を調べる。
browserとserverのTLS。
VPNとSSH。
mail certificate。
codeとfirmwareのsignature。
NASのbackup key。
外部serviceのcertificate chain。
offline restore terminal。
壁へ、発見した用途を一枚ずつ貼る。
cryptographic uses found 11
owner confirmed 9
owner missing 2
data lifetime >= 20 years 3
replaceable now 6
vendor update required 3
unknown dependency 2「十一個のalgorithmじゃないよ」
ユイが訂正した。
「十一箇所の使われ方。ひとつの箇所でも、複数のalgorithmとserviceが関わる」
canaryで、algorithmではなく経路を試す
三十年残す記録の転送経路を、最初の優先対象にする。
ただし本番の保管箱へ直接は書かない。
同じ条件を持つtest vaultを作り、実装が正式にsupportするPQC profileでkey establishmentを試す。
独自にalgorithmを混ぜない。
複数方式を組み合わせる構成や従来方式との併用は、protocolと製品が定義し、相互運用を確認できる場合だけtest対象にする。
イトは、成功条件を先に固定した。
new client sessions 12 / 12
backup writes 5 / 5
restore reads 5 / 5
signature verification 5 / 5
legacy recovery terminal 0 / 1
rollback test PASS
production change 0testを走らせる。
新しいclientは十二回つながった。
五つのsampleは、書き込み、復元、署名確認まで通る。
旧復旧端末だけは、最初のmessageを受け取れない。
「PQCが失敗した？」
イトは前夜なら、そう書いていた。
今度はinventoryのdependency欄を開く。
component legacy recovery terminal
failure unsupported negotiated profile
owner facilities team
vendor update unavailable
decision isolate and replace
deadline before production migration新方式全体を戻すのでも、旧端末を無視して進むのでもない。
canary laneは残す。
旧端末は本番の復旧責任を持つため、隔離だけで「移行済み」にせず、交換ownerとdeadlineを置く。
午前零時。
今夜のproduction backupは、復旧確認済みのcurrent pathで始まった。
同時にtest vaultでは、blue keyのcanaryが監視付きで続く。
Crypto agilityは、鍵を頻繁に替えることではない
暗号の前提は、これからも変わり得る。
crypto agilityは、protocol、application、software、hardware、infrastructureで使う暗号を、securityと稼働を保ちながら交換・適応できる能力を指す。
設定項目を増やすだけでは足りない。
agility needs
discover usage
separate algorithm from application logic
test interoperability and performance
stage deployment
revoke / roll back safely
prove legacy retirement選択肢が多すぎれば、弱い方式へ戻されるdowngrade riskも増える。
したがって「何でも切替可能」ではなく、許すprofile、移行期間、終了条件を管理する。
PQCへの移行は、PQCだけのための一度きりのprojectではない。
次の交換にも耐えられるよう、暗号を発見し、差し替え、戻し、古いものを閉じる仕組みを残す。
三つ目の鍵穴には、鍵ではなくowner札が入った
backupの進捗が100%になる。
イトは、保管箱の三つ目の空いた鍵穴を見た。
そこへ新しいalgorithm keyを足す代わりに、小さなowner札を差した。
future vault owner Yui
recovery owner facilities team
retirement proof pending
next review 30 daysblack boxの表示は、MIGRATEDにはならなかった。
STAGED — RECOVERY VERIFIED
未来を守る仕事は、今夜終わらない。
ただし、誰が次の扉を閉じるかは、もう空欄ではなかった。
そのときユイの端末が短く鳴った。
公開していない観測noteが、cloud同期の待ち列へ入っている。
送信buttonは押していない。
screenには、理由だけが出ていた。
local model unavailable
fallback route selected
upload pendingイトはnetwork cableへ手を伸ばした。
次回、ピコルート第105話。
ユイの未公開ノートが、送信前に雲へ並んだ｜端末AIなら秘密は外へ出ない？