Tại sao PasswordRecipient của CMS sử dụng KEK?

Khi đang sử dụng openssl cms -encrypt -pwri_password, nó tuân theo quy trình được mô tả trong RFC 3211, chuyển mật khẩu do người dùng cung cấp vào một KDF, nhưng sau đó, thay vì sử dụng đầu ra của KDF đó để mã hóa nội dung, thay vào đó, nó sử dụng khóa đó làm KEK để mã hóa khóa mã hóa nội dung thực (CEK), đó là sau đó đi kèm với nội dung:

TRÌNH TỰ (2 phần tử)
  ĐỊNH DẠNG ĐỐI TƯỢNG 1.2.840.113549.1.7.3 dữ liệu được bao bọc (PKCS #7)
  [0] (1 phần tử)
    TRÌNH TỰ (3 phần tử)
      SỐ LƯỢNG 3
      BỘ (1 phần tử)
        [3] (4 mục)
          SỐ LƯỢNG 0
          [0] (2 phần tử)
            BỘ NHẬN DẠNG ĐỐI TƯỢNG 1.2.840.113549.1.5.12 pkcs5PBKDF2 (PKCS #5 v2.0)
            TRÌNH TỰ (2 phần tử)
              CHUỖI OCTET (8 byte) D81093AEE45462EE
              SỐ LƯỢNG 2048
          TRÌNH TỰ (2 phần tử)
            ĐỊNH DẠNG ĐỐI TƯỢNG 1.2.840.113549.1.9.16.3.9 pwriKEK (Thuật toán S/MIME)
            TRÌNH TỰ (2 phần tử)
              BỘ NHẬN DIỆN ĐỐI TƯỢNG 1.2.840.113549.3.7 des-EDE3-CBC (Thuật toán mã hóa RSADSI)
              CHUỖI OCTET (8 byte) BB96EE7A71BA5792
          CHUỖI OCTET (32 byte) 569E1E845BA33D24D4243ED28B265B0974C486B813E6B9582B014D7E53DD01B9
      TRÌNH TỰ (3 phần tử)
        Dữ liệu NHẬN DẠNG ĐỐI TƯỢNG 1.2.840.113549.1.7.1 (PKCS #7)
        TRÌNH TỰ (2 phần tử)
          BỘ NHẬN DIỆN ĐỐI TƯỢNG 1.2.840.113549.3.7 des-EDE3-CBC (Thuật toán mã hóa RSADSI)
          CHUỖI OCTET (8 byte) 05AD3B1BDCB767CC
        [0] (16 byte) 7FA32912ECCCD7C421D4F122FD1ED172

Các trạng thái đặc điểm kỹ thuật (nhấn mạnh thêm):

§1.2.1 Cơ sở lý luận

Gói khóa dựa trên mật khẩu Là quy trình gồm hai giai đoạn, giai đoạn đầu tiên trong đó mật khẩu do người dùng cung cấp được chuyển đổi thành KEK nếu được yêu cầu và giai đoạn thứ hai trong đó KEK được sử dụng để mã hóa CEK.

Nhưng tôi không rõ ràng về tại sao mã hóa CMS dựa trên mật khẩu được thực hiện thông qua quy trình hai giai đoạn này. Nó có bảo vệ bằng cách nào đó chống lại các lỗ hổng sắp được phát hiện trong KDF trong tương lai không?

KDF đã triển khai muối, do đó, đầu ra của nó rõ ràng đã được bảo mật trước ví dụ: bảng cầu vồngâ vậy lợi thế đằng sau mô hình CEK có nguồn gốc từ mật khẩu này là gì trên chỉ đơn giản là sử dụng đầu ra của KDF trực tiếp như CEK?

CMS chỉ tuân theo một thiết kế tiêu chuẩn.

CMS cho phép một tin nhắn được mã hóa cho nhiều người nhận. Các mã hóa nội dung sử dụng khóa được tạo ngẫu nhiên, CEK. Đối tượng CMS chứa một Khóa được mã hóa blob cho mỗi người nhận. Mỗi blob EncryptedKey chứa CEK được mã hóa bằng một phương thức có thể khác nhau đối với từng người nhận.

Cơ chế hai cấp này là tiêu chuẩn để mã hóa thư có nhiều người nhận.Có một khóa mã hóa nội dung duy nhất (CEK): nếu nội dung được mã hóa riêng cho từng người nhận, điều này sẽ nhân kích thước của thư và công việc mã hóa được thực hiện theo số lượng người nhận. Mỗi người nhận phải có khả năng lấy được CEK bằng cách nào đó, nhưng nói chung, những người nhận khác nhau có các bộ bí mật được thiết lập sẵn khác nhau (ví dụ: họ biết các mật khẩu khác nhau hoặc họ có các khóa riêng tư khác nhau). Vì vậy, một tin nhắn với N người nhận chứa N blobs, mỗi trong số đó có thể đọc được bởi một người nhận khác nhau.

Hơn nữa, cơ chế hai cấp này cũng là tiêu chuẩn bất cứ khi nào có liên quan đến mật khẩu, ngay cả khi có một người dùng duy nhất phải giải mã dữ liệu. Người dùng thường xuyên muốn thay đổi mật khẩu. Nếu CEK được lấy từ mật khẩu, việc thay đổi mật khẩu sẽ yêu cầu mã hóa lại dữ liệu. Vì vậy, thay vào đó, mật khẩu chỉ được sử dụng để mã hóa CEK.