第53話で、イトはcertificate name mismatchを無視しなかった。
known targetとmatching certificateを確かめ、TLS handshakeが完了してからapplication dataを送った。
そのprotected recordを作るmachineの奥に、今度はplaintext card、ciphertext tray、key holderが並んでいる。
archive releaseまで、あと六十秒。
イトはplaintext cardを読み、自作のshuffle wheelへ差した。
三文字ずつ順番を入れ替える。
出てきたcardは、確かに読みにくい。
「これなら暗号化できた。rule cardも一緒に置けば、あとで戻せる」
イトはshuffle ruleをciphertext trayの横へ置こうとした。
読めない見た目だけでは、暗号化にならない
ピコはwheelにもrule cardにも触れず、三つのtest trayを机へ出した。
イト
読めなくして、元へ戻せるなら暗号化じゃないの？
ピコ
誰でも同じruleで戻せるなら、secretはどこにある？
イト
ruleを秘密にすればいい？
ピコ
方式を隠すことと、secret keyを管理することを分けよう
この話のplaintext、key、nonce、associated data、ciphertext、tamper traceは、外のInternetから切り離した学習fixtureだ。
real customer data、live password、production key、public endpointは使わない。
暗号の数学、AES内部、key derivation、rotation、HSM、full-disk encryption製品差、end-to-end encryptionの各service保証は再現しない。
見るのは、入力、secret、出力、復号結果の境界だけだ。
encryptionは、plaintextをciphertextへ変える
NISTのCryptographic Standards and Guidelinesは、cryptographic primitives、algorithms、schemesをFIPSやSpecial Publications等で扱っている。
暗号化は「それらしく文字を崩す演出」ではない。
定義されたalgorithmへ、守りたいplaintextと必要なcryptographic materialを渡し、ciphertextを得る処理だ。
復号は、そのciphertextを正しい条件でplaintextへ戻す処理になる。
このfixtureでは、modern applicationでconfidentialityと改ざん検出を一緒に扱うauthenticated encryptionを使う。
algorithmをイトがその場で発明しない。
reviewされたlibraryが提供する固定fixtureだけを呼ぶ。
encodingは、secretなしで表現を変える
イトは二枚目のcardをBase64 encoderへ通した。
文字列は別の見た目へ変わった。
しかしdecode buttonを押すと、secret keyを一度も求めず元へ戻った。
RFC 4648 Base-N Encodingsは、Base64などのencodingとdecodingを定める。
これはbyte列を扱いやすい文字表現へ変える仕組みで、見た目が読みにくくてもconfidentialityを作るsecretにはならない。
「decodeできる人をkey holderだけに制限する」という構造ではない。
Base64にしたpasswordやtokenを、暗号化済みと判断しない。
hashは、復号する暗号文ではない
三枚目のcardはhash machineへ入った。
出てきたのは固定長のdigest cardだ。
同じ入力を照合する手がかりにはなるが、ciphertextをkeyでdecryptしてoriginal plaintextへ戻す操作とは違う。
暗号化、encoding、hashは、見た目が変わるという一点だけで同じ箱へ入れない。
password保存にはpassword hashing固有の設計があり、この回のgeneral-purpose encryption fixtureでpasswordを復号可能に保存しない。
イトは三枚のoutputへ別々の札を付けた。
encodingはdecodeできる表現。
hashはdigest。
encryptionのoutputがciphertextだ。
authenticated encryptionには、四つのinputがある
RFC 5116のAEAD interfaceでは、authenticated encryption operationへsecret key K、nonce N、plaintext P、associated data Aを渡し、ciphertext Cまたは処理不能の結果を得る。
secret keyは、authorizedな処理だけが使えるよう守るcryptographic secretだ。
plaintextは、隠したい元data。
associated dataは、暗号化せずintegrity / authenticityを確認したいcontextに使える。
nonceはnumber used onceの入口で、passwordでも追加のsecret keyでもない。
このfixtureが使うAEADでは、同じkeyで別々のencryptionを行うたびdistinct nonceを渡す。
nonceはciphertextと一緒に保存・transportできる場合がある。
大事なのは「隠すこと」ではなく、選んだalgorithmの条件どおりreuseしないことだ。
RFC 5116は、同じkeyとnonceを再利用すると、algorithmによってはconfidentialityとauthenticityを大きく損なうと説明する。
keyは、ciphertextの隣へ無防備に置かない
イトはblue key tokenをciphertext trayへ載せた。
それなら復号machineがすぐ使える。
だが、archiveを読める人が同じ権限でkeyも取り出せるなら、archiveだけを盗まれたときの境界が増えない。
NISTのKey Management guidanceは、cryptographic keying materialの保護と、生成・配布・保存・利用・破棄を含むmanagementを暗号利用の一部として扱う。
「ciphertextとkeyは必ず別のmachineへ置く」という一律の配置ruleではない。
どの脅威から何を守るかを決め、keyへのaccessをdataへのaccessと同じ無防備な境界へ落とさない。
このclosed fixtureでは、ciphertextはarchive tray、secret keyはseparate protected holderへ置く。
イトの前に、三つの選択肢が開く
archive releaseまで、あと三十秒。
A fixed shuffleを暗号化として公開する
見た目は読みにくい。
しかし同じruleを知れば、secret keyなしで全cardを戻せる。
B 自作algorithmを秘密にし、key cardもarchiveへ同梱する
戻す材料は揃う。
だが方式の秘密へ依存し、archiveを取られた境界でkeyも一緒に渡す。
C vetted AEAD fixtureを使い、secret keyを別holderへ置き、distinct nonceで結果をtestする
plaintext、key、nonce、contextの役割を分ける。
correct conditionでoriginalへ戻るか、wrong keyとtamperを拒否するかをrelease前に観察する。
ピコはAのcoverにもCのstart buttonにも触れなかった。
「読めないcardを作るんじゃない。誰がどの条件で戻せるかを残す」
イトはCを選んだ。
自分でshuffle wheelのcoverを閉じ、rule cardをaccepted trayから外した。
plaintextをfixture inputへ差し、generated secret keyをseparate protected holderへ移す。
同じkeyで未使用のnonceをcounterから一つ取り、archive versionをassociated-data holderへ置いた。
最後に、イトがstart buttonを押した。
correct conditionだけが、originalへ戻った
machineはciphertextとnonceをarchive trayへ出した。
public railへ出たplaintext cardは0。
イトはcopyしたfixtureへ、同じciphertext、correct key、nonce、associated dataを渡した。
authenticated decryptionはplaintextを返す。
元cardとbyte-for-byte comparatorで一致した。
次に、別のkeyへ差し替える。
resultはFAIL。
wrong-key plaintextは0。
modified ciphertextは、trusted plaintextへしない
イトはciphertext copyの一bitだけをtamper switchで変更した。
correct key、元と同じnonce、同じassociated dataを渡す。
RFC 5116のauthenticated decryptionが返すoutputは、authenticatedなplaintextか、inputがauthenticではないことを示すFAILのどちらかだ。
modified copyはFAILになった。
途中まで復号した文字列をaccepted plaintextとして出さない。
original ciphertextはaccepted。
wrong keyはrejected。
modified ciphertextもrejected。
workbenchへ四つのobservable resultが残った。
公開railのplaintextは0。
correct decryptはoriginalと一致。
wrong-key plaintextは0。
modified plaintext deliveryも0。
archive release lampがgreenになった。
暗号化が守るのは、決めたboundaryまで
data in transitでは、TLSなどのprotocolが通信中のrecordを守るために暗号を使う。
data at restでは、storage、file、database field、backupなど、定めた保存boundaryへ暗号化を使う場合がある。
ただし「暗号化済み」というlabelだけでは、何から守るかは分からない。
endpointで復号したあとのdataをmalwareが読むかもしれない。
authorized accountが画面で見るかもしれない。
keyへ同じ権限で到達できるかもしれない。
backupだけ暗号化され、temporary fileはplaintextかもしれない。
algorithm、key management、implementation、access control、endpoint、backup / recoveryを別々に確認する。
「暗号化してあるから全部安全」へ戻らない。
読めない文字ではなく、復号条件を残す
机には、六つの証拠が残った。
closedにした自作shuffle wheel。
archiveへ出さなかったplaintext。
protected holderへ分けたsecret key。
同じkeyでreuseしないnonce。
correct conditionだけでoriginalへ戻ったciphertext。
wrong keyとmodified copyのFAIL tray。
暗号化を見た目の読みにくさで判断しない。encodingとhashを分け、reviewされたscheme / libraryを使い、plaintext、secret key、nonce、context、ciphertextの役割を保つ。authenticated decryptionでwrong keyや変更されたciphertextをtrusted plaintextとして通さず、key accessをdata accessと同じ無防備な境界へ置かない。
「鍵は、文字をぐちゃぐちゃにする飾りじゃない。戻してよい条件を分けるものだった」
イトはciphertextをpublic archive railへ送り、blue key tokenはprotected holderへ残した。
railの先で、ciphertext cardは大きなtunnelへ吸い込まれた。
だがtunnelの入口と出口の外には、別のrouteが見えている。
暗号化するVPNは、どこからどこまでを包むのだろう。
次回：tunnelは、Internet全部を消さない
イトはVPN switchを入れ、map上の一本のrouteがsealed tunnelへ変わるのを見た。
「これでInternetのどこへ行っても、全部同じ安全になる？」
ピコはdestination cardを伏せず、tunnelの二つのendpointだけを照らした。
次回、ピコルート第55話。
イトは、VPNでInternet全部が安全になると決めなかった｜tunnelはどこまで？