要約

  • PBMAC1使用時、MacDataのDigestAlgorithmIdentifierがPBMAC1を示し、KDFとMAC方式の両方を入れ子のパラメーターで運ぶ。
  • HMAC-SHA-256を用いるPBKDF2、明示的なkeyLength、終端文字やBOMを付けない直接UTF-8が基準になる。
  • RFCは構文と検証を定めるが、普遍的な実装対応、製品認証、あらゆる脅威モデルへの十分性を証明するものではない。

PFXの完全性境界はauthSafeコンテンツに対するMACである。PBMAC1では、MacDataのDigestAlgorithmIdentifierが、パスワードベースの鍵導出関数とメッセージ認証方式をパラメーター内に示す。KDFとMACは別々の選択であり、受信側は両方をセキュリティー上重要な入力として解析しなければならない。

旧来のMacDataフィールドであるmacSaltとiterationsは、互換性のために残されることがある。RFC 9879はPBMAC1処理ではこれらを無視する一方、古い形状を先に検査する実装に対応するため、書き出し側には空でない値とゼロでない値の符号化を勧めている。それらをPBMAC1の実際のソルトや反復回数として使う理由にはならない。両実装が別の入力を採用すれば、検証は一致しない。

必須の基準はHMAC-SHA-256によるPBKDF2である。この用途ではPBKDF2パラメーターにkeyLengthを明示しなければならず、省略を受け入れたり、受信側が値を暗黙に補ったりしてはならない。パスワードは終端ヌル文字もバイト順マークも付けず、直接UTF-8バイトへ変換する。これは従来のPKCS #12パスワード表現とは異なるため、古い変換を残す移行は危険である。

KDFとMACのアルゴリズム識別子、パラメーター、鍵長を検証する必要がある。HMAC-SHA-1は推奨されず、PBMAC1では出力が160ビット以下のダイジェストアルゴリズムが禁止される。20オクテット未満の派生鍵も拒否することが勧められる。これは弱いパスワードを強化する主張ではなく、機密性を与える機能でもない。対象は完全性保護である。

scryptは任意対応であり、必須の共通分母ではない。対応する場合も、メモリー、計算量、並列度、時間制限などのリソースコストを導出前に検証する必要がある。どのコストが全環境に十分かはRFCから導けず、稼働中の実装がPBMAC1を対応するとも言えない。

移行は読み取り側と書き出し側を同時に調整する。書き出し側は入れ子のPBMAC1パラメーター、明示的なkeyLength、直接UTF-8、許容されたアルゴリズムを生成する。旧フィールドは互換性のため残せても、PBMAC1のセキュリティー入力ではない。読み取り側は入れ子を検証し、弱い値や欠落を拒否し、コストを上限内に収める。旧形式の受け入れには期限と撤去条件を設けるべきだ。

出典