要約

  • RFC 1969では、あるPPPパケットの最後の暗号文ブロックが次のパケットのCBC入力になる。状態を毎回運ばない効率と、直前パケットへの依存が一体化した。
  • 最初の状態は、平文で交渉された64ビットnonceを共有DES鍵で暗号化して作る。nonceも16ビット連番も観測可能な制御情報であり、認証タグではない。
  • N-1を失うとNは復号不能になる。しかしNの暗号文が届いていれば、その末尾でN+1から再開できる。回復したのは鎖であり、N-1とNの平文ではない。

復号できない暗号文の価値

RFC 1969の損失回復は、受信機に少し変わった規律を要求する。パケットN-1が失われ、Nだけが届いたとする。Nを平文に戻すにはN-1の最終暗号文ブロックが必要なので、復号はできない。それでもNの暗号文そのものは、次の計算に使える。

CBCでは、現在の暗号文を解いた結果に一つ前の暗号文をXORして平文を得る。RFC 1969は「一つ前」を同じパケットの直前ブロックだけに限定せず、パケット境界を越えて継続した。したがってNの最後のブロックを保存できれば、N+1の最初の平文ブロックに必要な入力がそろう。

ここで二つの欠損を区別しなければならない。N-1は通信路から消えた。Nは届いたが読めない。N+1から通常の復号に戻れるとしても、前の二つの平文が生成されたわけではない。RFCの見出しにある“Recovery after Packet Loss”は暗号状態の再同期を指し、データ回収やアプリケーション配送を意味しない。

パケットを状態境界にしなかった設計

RFC Editorの記録によれば、RFC 1969は1996年6月のInformational文書である。PPP Encryption Control Protocolに対し、DESをCBCモードで使う具体的なデータ・プロトコルを示した。ECP一般の交渉過程はRFC 1968の領域であり、本稿はECPがOpenedになった後の片方向データ列だけを見る。

最初のパケット以外では、新しい初期化ベクトルをパケットごとに送らない。送信機は前のパケットの最終暗号文ブロックを次のC[0]にし、受信機も同じ順序を再現する。これによって暗号文の連続性が保たれ、同じ平文断片が各パケットの先頭に現れても単純な同型になりにくい。

同時に、単独のパケットは自己完結しなくなる。PPPフレームとして境界が見えていても、その暗号内容を読むための状態は一つ前にある。効率は「何を送らなくてよいか」で測れるが、回復コストは「何を失うと次まで読めなくなるか」で現れる。RFC 1969は両者を一つの鎖で結んだ。

公開nonceは秘密の代用品ではない

DESE設定オプションは10オクテットで、TypeとLengthに続いて8オクテットのInitial Nonceを含む。受信側が提示したnonceを、相手がその方向の最初のパケットに使う。文書は毎回のECP交渉で異なる値を提示することを推奨し、1970年からの秒数と秒内ナノ秒を組み合わせる例まで示す。

nonceは交渉中に平文で見える。最初のCBC入力はnonceそのものではなく、56ビット共有鍵kを使ったE[k](nonce)である。受信側も、自分が提示したnonceと共有鍵から同じ値を再計算する。二番目以降は前パケット末尾がこの役割を継ぐ。

つまり、nonceは開始状態の新鮮さ、鍵は機密性、暗号文末尾は継続性を担当する。役割を混ぜると証拠が膨らむ。nonceを観測しても秘密を知ったことにはならず、nonceが一致しても相手の組織的身元を証明しない。

さらにRFC 1969は、共有秘密をどう両端へ届けるかを仕様外に置いた。通常は手動設定であり、PPP認証やMultilink Endpoint Identifierを秘密選択の材料にしてもよい、と述べるだけである。復号成功は互換な鍵と状態が存在したという実装上の証拠だが、命名された主体の署名ではない。

連番が検出するのは順序の穴

DESEデータ・パケットには16ビットの明示的Sequence Numberが付く。ECPがOpenedになった最初のパケットを0として順に割り当て、受信側は不連続を損失として検出する。跨パケットCBCでは、この番号が「今見ている暗号文が、保存した状態の直後か」を判断する手掛かりになる。

しかし番号は内容を検査しない。RFC 1969は番号を認証するMACを定義せず、暗号文の改変、再送、切り貼り、送信元の身元を保証しない。欠番の原因も特定できない。物理的損失、順序入れ替え、ローカル破棄、能動攻撃は、いずれも観測された系列を乱し得る。

後継のRFC 2419は、その限界を明文化した。対象はconfidentialityだけであり、integrity、authentication、nonrepudiationを提供しない。replay、cut-and-paste、active tamperingに対してメッセージが変更されなかった保証もない。

連番は無力なのではない。意味が限定されている。片方向のDESE系列で期待した順番と観測値がずれたことを知らせる。それ以上の権威を持たせないことが、正しい運用である。

MRUに現れる八オクテットの都合

DESのブロックは8オクテットである。PPPのProtocol fieldとInformation fieldを合わせた平文が8の倍数でなければ、暗号化前に埋める必要がある。RFC 1969は、内側に長さを持つIP、IPX、XNS、CLNPではランダムな末尾を許し、末尾追加で意味が壊れるbridgingなどにはself-describing paddingを使う構成だった。

この条件分岐は実装判断を招く。自己記述式の方法はRFC 1570に由来する。「明示長を持つプロトコル」を両端が同じように分類できなければ、暗号計算は一致しても、復号後にどこまでをデータとするかが食い違う。すでに8オクテット境界にある平文でも、末尾が1,2のようにpaddingに見える場合は、誤削除を避けるため丸ごと8オクテット足すことがある。

MRUへの影響も小さくない。PFCが有効で、元のMRUが8の倍数なら、最大データと1オクテットProtocol fieldの組合せに7オクテットのpaddingが必要になる。さらに2オクテットのSequence Numberが加わり、外側プロトコルの効果も含めてDESEのInformation fieldは元より10オクテット大きくなり得る。DESEを選んだからといってMRUは自動的に増えない。PPPオプションは独立だからである。

取代の理由は3DES化ではなく、解釈の統一

RFC 2419の情報ページはRFC 1969をobsoletesとする。新文書の差分節は、全平文パケットへ同じself-describing paddingを適用し、PPPのSDPオプションとは独立させ、最大値を8に固定したと説明する。不正なpadding配列を受けた場合はフレームを破棄すべきともした。

旧規則と新規則では同じ復号結果の解釈が変わり得る。そのためDESE-bisにはECP Type 3が新しく割り当てられ、旧Type 1はdeprecatedになった。RFC 2419実装は旧値を提案してはならず、受け取ればConfigure-Rejectしなければならない。IANAのPPP登録表も現在、Type 1をDeprecated (DESE)、Type 3をDESE-bisとして示す。

これはDESから3DESへの置換ではない。PPP Triple-DESは別のRFC 2420、別のECP Type 2である。RFC 2419の中心はpaddingの相互運用修正、新番号による旧実装との静かな混在防止、Standards Track化、そして安全範囲の明確化だった。

輸出規制が残した文章上の化石

RFC 1969はDESを広く実装されたモデルと評価する一方、米国輸出法のためcompilation-ready source codeを本文へ入れられないと記した。RFC 2419にも同じ文が残った。これは暗号ソフトウェアの公開とプロトコル記述が異なる制約を受けた時代の直接的な痕跡である。

ここから言えるのは、法的環境が標準文書の内容に影響したことだけだ。特定製品の輸出可否、特定コードの合法性、実装の所在や普及は導けない。ソースがないことを、実装がない証拠にも、安全である証拠にもしてはならない。

IETF DatatrackerとRFC Editorは文書の来歴と地位を示す。一方、取得時にRFC 1969のerrataページから利用できる本文を得られなかったため、errataがゼロだとは主張しない。

緑の表示を五つの受領記録へ分解する

監査記録は少なくとも五段に分けるべきだ。ECPの方向・Type・nonce・鍵参照、観測したSequence Numberと欠番、実際に使った直前暗号文末尾、復号とpadding除去、そしてRFC 1661に従うPPP受理と上位層への引渡しである。アプリケーションの完了受領は、そのさらに先にある。

DESEが直接説明するのは暗号計算までである。復号できてもpaddingが不正なら破棄され得る。PPPが受け取っても、アプリケーション処理は失敗し得る。Sequence Numberが穴を正確に知らせても、失われた業務の意味は分からない。

Heng LuのRunning-Code Primacyは、文書と稼働状態を別々の証拠として接続する。Minimum Initial Specificationは、フィールドに必要以上の権威を与えない。Reality LayersとReality, Not Advocacyは、記号を結果へ昇格させず、動機を創作せずに構造を示す編集姿勢を与える。これらはプロトコル史の典拠ではない。