← RFC Reference

RFC 8551: Đặc tả Thông báo S/MIME 4.0

Tại sao điều này tồn tại

S/MIME 3.2 (RFC 5751, xuất bản năm 2010) đã vững chắc cho thời đại của nó, nhưng mật mã học tiến bộ:

• Chế độ CBC thiếu xác thực. AES-CBC (mặc định S/MIME 3.2) mã hóa dữ liệu nhưng không phát hiện được giả mạo. Kẻ tấn công có thể sửa đổi văn bản mã hóa theo những cách tạo ra những thay đổi có thể dự đoán trong văn bản rõ. AES-GCM cung cấp mã hóa xác thực — bất kỳ sửa đổi nào cũng được phát hiện.
• Kích thước khóa RSA tiếp tục phát triển. RSA-2048 được coi là mức tối thiểu ngày hôm nay, và RSA-4096 rất phổ biến. Mật mã đường cong elip (ECDSA, ECDH) cung cấp bảo mật tương đương với các khóa nhỏ hơn nhiều, giảm kích thước tin nhắn và thời gian tính toán.
• SHA-1 bị phá vỡ. S/MIME 3.2 vẫn cho phép SHA-1 để tương thích ngược. S/MIME 4.0 không dùng SHA-1 hoàn toàn cho chữ ký.
• Bảo vệ tiêu đề. S/MIME 3.2 chỉ ký/mã hóa nội dung tin nhắn. S/MIME 4.0 thêm cơ chế để bảo vệ tiêu đề (Subject, From, v.v.) bên trong phong bì mã hóa.

Cách hoạt động

Cấu trúc MIME và gói CMS vẫn giống như S/MIME 3.2. Các thay đổi nằm ở các thuật toán và khả năng được thương lượng giữa người gửi và người nhận.

Những gì thay đổi từ 3.2 thành 4.0

Mã hóa xác thực (AES-GCM)

Thay đổi quan trọng nhất là chuyển từ AES-CBC sang AES-GCM như thuật toán mã hóa nội dung bắt buộc:

• AES-CBC mã hóa các khối độc lập. Kẻ tấn công lật một bit trong văn bản mã hóa gây ra những thay đổi có thể dự đoán trong văn bản rõ đã giải mã. Mà không có kiểm tra tính toàn vẹn riêng biệt, người nhận có thể không phát hiện được giả mạo.
• AES-GCM (Chế độ Galois/Bộ đếm) kết hợp mã hóa với thẻ xác thực được tích hợp. Bất kỳ sửa đổi nào đối với văn bản mã hóa sẽ khiến giải mã hoàn toàn thất bại. Đây là mã hóa xác thực — bạn nhận được tính bảo mật và tính toàn vẹn trong một hoạt động duy nhất.

Mật mã đường cong elip

S/MIME 4.0 làm cho ECDSA (để ký) và ECDH (để thỏa thuận khóa) bắt buộc phải thực hiện cùng với RSA:

Khóa EC nhỏ gọn hơn rất nhiều so với khóa RSA ở mức bảo mật tương đương. Đối với email, điều này có nghĩa là chữ ký nhỏ hơn và các khối vận chuyển khóa mã hóa nhỏ hơn, giảm kích thước tin nhắn.

Bảo vệ tiêu đề

S/MIME 4.0 xác định một cách để đưa các bản sao được bảo vệ của tiêu đề email (Subject, From, To, Date) bên trong nội dung MIME được ký hoặc mã hóa. Các tiêu đề bên ngoài vẫn có thể nhìn thấy để định tuyến và hiển thị, nhưng các bản sao được bảo vệ bên trong cho phép người nhận xác minh rằng tiêu đề không bị sửa đổi khi đang chuyển:

-- Bên trong nội dung S/MIME mã hóa --
Content-Type: message/rfc822

Subject: Kết quả quý độc quyền
From: cfo@example.com
To: board@example.com
Date: Wed, 12 Mar 2025 09:00:00 -0400

(nội dung nội dung mã hóa...)

Trình khách của người nhận so sánh các tiêu đề bên trong với các tiêu đề bên ngoài và cảnh báo nếu chúng khác nhau.

Chi tiết kỹ thuật chính

RSA-OAEP so với RSA PKCS#1 v1.5

S/MIME 3.2 sử dụng RSA PKCS#1 v1.5 để vận chuyển khóa. Sơ đồ đệm này dễ bị tấn công kiểu Bleichenbacher. S/MIME 4.0 khuyên dùng RSA-OAEP (Tối ưu hóa Đệm Mã hóa Bất đối xứng), có thể chứng minh được an toàn chống lại các cuộc tấn công chọn bản mã. Những người gửi NÊN sử dụng RSA-OAEP khi người nhận biểu thị hỗ trợ qua khả năng S/MIME của họ.

Thuộc tính khả năng S/MIME

Khi ký một tin nhắn, người gửi bao gồm một thuộc tính SMIMECapabilities liệt kê các thuật toán họ hỗ trợ. Người nhận sử dụng điều này để chọn các thuật toán được hỗ trợ chung mạnh nhất cho các tin nhắn được mã hóa trả lời. S/MIME 4.0 cập nhật thứ tự khả năng được khuyến nghị:

1. AES-256-GCM
2. AES-128-GCM
3. AES-256-CBC (để tương thích ngược)
4. AES-128-CBC (để tương thích ngược)

Tương thích ngược

Các tác nhân S/MIME 4.0 PHẢI có khả năng nhận và xử lý các tin nhắn S/MIME 3.2. Khi gửi, chúng nên sử dụng các thuật toán S/MIME 4.0 (AES-GCM, ECDSA) khi khả năng của người nhận biểu thị hỗ trợ, và quay lại các thuật toán 3.2 nếu không. Thuộc tính SMIMECapabilities điều khiển quá trình thương lượng này.

Những sai lầm phổ biến

• Sử dụng AES-CBC khi AES-GCM có sẵn. Nếu người nhận hỗ trợ S/MIME 4.0, luôn ưu tiên AES-GCM. CBC mà không có kiểm tra tính toàn vẹn dễ bị tấn công đệm tiên tri.
• Bỏ qua RSA-OAEP. Nếu bạn vẫn sử dụng RSA để vận chuyển khóa, hãy sử dụng đệm OAEP. PKCS#1 v1.5 có những yếu điểm đã biết và chỉ nên sử dụng để tương thích ngược với những người nhận cũ.
• Không quảng cáo khả năng S/MIME. Nếu các tin nhắn được ký của bạn bỏ qua thuộc tính SMIMECapabilities, những người nhận sẽ cho rằng mẫu số chung thấp nhất khi trả lời bằng thư mã hóa.
• Bỏ bê bảo vệ tiêu đề. S/MIME 4.0 xác định bảo vệ tiêu đề, nhưng nhiều trình khách không triển khai nó. Nếu bạn dựa vào các dòng Chủ đề được bảo vệ, hãy xác minh rằng trình khách của người nhận thực sự kiểm tra các tiêu đề bên trong.
• Giả sử hỗ trợ chứng chỉ EC phổ biến. Mặc dù S/MIME 4.0 yêu cầu hỗ trợ ECDSA/ECDH, nhiều trình khách được triển khai (đặc biệt là các phiên bản Outlook cũ hơn) chỉ hỗ trợ RSA. Cấp chứng chỉ kép nếu khả năng tương tác là rất quan trọng.
• Vẫn ký với SHA-1. SHA-1 không dùng trong S/MIME 4.0. Các trình khách hiện đại có thể từ chối chữ ký SHA-1 hoặc hiển thị cảnh báo. Sử dụng SHA-256 tối thiểu.

Tác động khả năng giao hàng

• Những cân nhắc tương tự như S/MIME 3.2. Mã hóa S/MIME làm cho nội dung tin nhắn không rõ ràng với các máy chủ trung gian và bộ lọc thư rác. Điều này có thể gây ra vấn đề giao hàng nếu các cổng nhận không thể kiểm tra nội dung để tuân thủ chính sách.
• Chữ ký nhỏ hơn với EC. Chữ ký đường cong elip nhỏ gọn hơn khoảng 1/10 so với chữ ký RSA-2048. Đối với thư ký có khối lượng lớn, điều này giảm đáng kể băng thông và kích thước tin nhắn.
• Tương thích cổng doanh nghiệp. Nhiều cổng email công ty giải mã S/MIME tại chu vi để quét tuân thủ, sau đó mã hóa lại cho người nhận. Đảm bảo cổng của bạn hỗ trợ các thuật toán S/MIME 4.0 nếu bạn triển khai chúng.
• Lợi thế quy định. Các tổ chức tuân theo GDPR, HIPAA hoặc các quy định tài chính có thể yêu cầu mã hóa xác thực (AES-GCM) thay vì mã hóa không được xác thực (AES-CBC). Tuân thủ S/MIME 4.0 có thể là một yêu cầu để kinh doanh với các thực thể được quy định.

Related RFCs