S / MIME là gì? bảo mật email điện tử

Đa dụng Internet Mail Extension (S / MIME) là một bảo vệ nâng cấp lên tiêu chuẩn định dạng e-mail Internet MIME dựa trên công nghệ của RSA Data Security. Mặt dù cả PGP và S / MIME đều theo tiêu chuẩn IETF, có vẻ như S / MIME sẽ trở thành tiêu chuẩn ngành cho mục đích sử dụng thương mại và tổ chức, trong khi PGP sẽ vẫn là lựa chọn để bảo mật e-mail cá nhân cho nhiều người dùng. S / MIME được định nghĩa trong một số tài liệu — quan trọng nhất là RFCs 3370, 3850, 3851 và 3852.

Các bài viết liên quan:

• 20 năm làm SEO: Lược sử SEO
• Mã hóa mật mã: các khái niệm cơ bản
• Hướng dẫn mã hóa địa lý hình ảnh cho SEO Local
• Tìm hiểu về mã hóa cổ điển
• Mã hóa công khai( public key)
• PGP (Pretty Good Privacy) là gì ?

Để hiểu S / MIME, trước tiên chúng ta cần có hiểu biết chung về định dạng e-mail cơ bản mà nó sử dụng, đó là MIME. Nhưng để hiểu được tầm quan trọng của MIME, chúng ta cần quay trở lại tiêu chuẩn định dạng e-mail truyền thống, RFC 822, vẫn đang được sử dụng phổ biến. Phiên bản gần đây nhất của đặc tả định dạng này là RFC 5322 (Định dạng tin nhắn Internet). Theo đó, phần này trước tiên cung cấp giới thiệu về hai tiêu chuẩn trước đó và sau đó chuyển sang thảo luận về S / MIME.

RFC 5322

RFC 5322 xác định định dạng cho các tin nhắn văn bản được gửi bằng thư điện tử. Nó đã là tiêu chuẩn cho các tin nhắn văn bản dựa trên Internet và vẫn được sử dụng phổ biến. Trong ngữ cảnh RFC 5322, các thư được xem như có một phong bì và nội dung. phong bì chứa bất kỳ thông tin nào cần thiết để thực hiện việc truyền và phân phối. Nội dung soạn đối tượng được chuyển đến người nhận. RFC Tiêu chuẩn 5322 chỉ áp dụng cho các nội dung. Tuy nhiên, tiêu chuẩn nội dung bao gồm một tập hợp các trường tiêu đề có thể được sử dụng bởi hệ thống thư để tạo phong bì và tiêu chuẩn này nhằm tạo điều kiện thuận lợi cho việc thu thập thông tin như vậy bởi các chương trình.

Cấu trúc tổng thể của một thông báo tuân theo RFC 5322 rất đơn giản. Một thông báo bao gồm một số dòng tiêu đề (tiêu đề) theo sau là không văn bản chặt chẽ (phần thân). Tiêu đề được ngăn cách với phần nội dung bằng một dòng trống. Nói cách khác, thư là văn bản ASCII và tất cả các dòng cho đến dòng trống đầu tiên được giả định là dòng tiêu đề được phần tác nhân người dùng của hệ thống thư sử dụng.

Dòng tiêu đề thường bao gồm một từ khóa, theo sau là dấu hai chấm, tiếp theo là các đối số của từ khóa; định dạng cho phép một dòng dài được chia thành nhiều dòng. Các từ khóa được sử dụng thường xuyên nhất là Từ, Đến, Chủ đề và Ngày. Đây là một thông báo ví dụ:

Ngày: 11 tháng 07 năm 2009 2:15:49 CH EDT

Từ:
"My name"
<ws@shore.net>

Chủ đề: Cú pháp trong RFC 5322 
Tới: abc@Other-host.com
Cc: cde@Yet-A Another-Host.com

Xin chào. Phần này bắt đầu phần nội dung thư thực, được phân tách với tiêu đề thư bằng một dòng trống.
Một trường khác thường thấy trong các tiêu đề RFC 5322 là Message-ID. Trường này chứa một số nhận dạng duy nhất được liên kết với thông báo này.

Multipurpose Internet Mail Extensions

Phần mở rộng Thư Internet Đa năng (MIME) là phần mở rộng cho khuôn khổ RFC 5322 nhằm giải quyết một số vấn đề và hạn chế của việc sử dụng Giao thức Truyền Thư Đơn giản (SMTP), được định nghĩa trong RFC 821 hoặc một số giao thức truyền thư khác và RFC 5322 cho thư điện tử. [PARZ06] liệt kê danh sách tiếp theo hạn chế lược đồ SMTP / 5322.

1. SMTP không thể truyền các tệp thực thi hoặc các đối tượng nhị phân khác. Một số lược đồ đang được sử dụng để chuyển đổi các tệp nhị phân thành một dạng văn bản có thể được sử dụng bởiHệ thống thư SMTP, bao gồm lược đồ UNIX UUencode / UUdecode phổ biến. Tuy nhiên, không có tiêu chuẩn nào trong số này là tiêu chuẩn hoặc thậm chí là tiêu chuẩn trên thực tế.
2. SMTP không thể truyền dữ liệu văn bản bao gồm các ký tự ngôn ngữ quốc gia, vì chúng được biểu thị bằng mã 8 bit có giá trị từ 128 thập phân trở lên và SMTP được giới hạn ở ASCII 7 bit.

3. Máy chủ SMTP có thể từ chối thư trên một kích thước nhất định.
4. Cổng SMTP dịch giữa ASCII và mã ký tự EBCDIC không sử dụng một tập hợp các ánh xạ nhất quán, dẫn đến các vấn đề về dịch thuật.
5. Cổng SMTP tới mạng thư điện tử X.400 không thể xử lý dữ liệu phi văn bản có trong thư X.400.
6. Một số triển khai SMTP không tuân thủ hoàn toàn các tiêu chuẩn SMTP được xác định trong RFC 821. Các vấn đề thường gặp bao gồm:
   • Xóa, thêm hoặc sắp xếp lại ký tự xuống dòng và nguồn cấp dữ liệu
   • Cắt bớt hoặc gói các dòng dài hơn 76 ký tự
   • Loại bỏ khoảng trắng ở cuối (ký tự tab và dấu cách)
   • Khoảng đệm các dòng trong một tin nhắn có cùng độ dài
   • Chuyển đổi các ký tự tab thành nhiều ký tự khoảng trắng

MIME nhằm giải quyết những vấn đề này theo cách tương thích với các triển khai RFC 5322 hiện có. Đặc điểm kỹ thuật được cung cấp trong RFCs 2045 đến 2049.

Xem thêm Tìm hiểu về Selenium & thuật ngữ cơ bản Selenium

Đặc tả MIME bao gồm các yếu tố sau.

1. Năm tin nhắn mới các trường tiêu đề được xác định, có thể được bao gồm trong một RFC Tiêu đề 5322. Các trường này cung cấp thông tin về nội dung của thư.
2. Một số định dạng nội dung được xác định, do đó tiêu chuẩn hóa các biểu diễn hỗ trợ thư điện tử đa phương tiện.
3. Mã hóa truyền được định nghĩa cho phép chuyển đổi bất kỳ nội dung nào thành một dạng được bảo vệ khỏi sự thay đổi của hệ thống thư.

Trong tiểu mục này, chúng tôi giới thiệu năm trường tiêu đề thư. Hai phần phụ tiếp theo đề cập đến các định dạng nội dung và mã hóa chuyển giao.

Năm trường tiêu đề được xác định trong MIME là

• MIME-Version: Phải có giá trị tham số 1.0. Trường này chỉ ra rằng thông báo tuân theo RFCs 2045 và 2046.
• Content-Type: Mô tả dữ liệu có trong phần thân với đầy đủ chi tiết mà tác nhân người dùng nhận có thể chọn một tác nhân hoặc cơ chế thích hợp để đại diện cho dữ liệu cho người dùng hoặc xử lý dữ liệu theo cách phù hợp.
• Content-Transfer-Encoding: Cho biết kiểu chuyển đổi đã được sử dụng để thể hiện phần nội dung của thư theo cách có thể chấp nhận được cho việc vận chuyển thư.
• Content-ID: Được sử dụng để xác định duy nhất các thực thể MIME trong nhiều ngữ cảnh.
• Content-Description: Một văn bản mô tả đối tượng với cơ thể; điều này hữu ích khi đối tượng không thể đọc được (ví dụ: dữ liệu âm thanh).

Bất kỳ hoặc tất cả các trường này có thể xuất hiện ở trạng thái bình thường Tiêu đề RFC 5322. Việc triển khai tuân thủ phải hỗ trợ các trường MIME-Version, Content-Type và Content- Transfer-Encoding; các trường Content-ID và Content-Description là tùy chọn và có thể bị người nhận bỏ qua khi triển khai.

Xem thêm Kiểm tra lỗ hổng bảo mật Weak Encryption

MIME CONTENT TYPES

Phần lớn đặc tả MIME liên quan đến định nghĩa của nhiều loại nội dung. Điều này phản ánh sự cần thiết phải cung cấp các cách thức chuẩn hóa để xử lý nhiều loại biểu diễn thông tin trong môi trường đa phương tiện.

Bảng 18.3 liệt kê các loại nội dung được chỉ định trong RFC 2046. Có bảy loại nội dung chính khác nhau và tổng cộng 15 loại phụ. Nói chung, kiểu nội dung khai báo kiểu dữ liệu chung và kiểu con chỉ định một định dạng cụ thể cho kiểu dữ liệu đó.

Đối với loại nội dung văn bản, không cần phần mềm đặc biệt nào để có được ý nghĩa đầy đủ của văn bản ngoài sự hỗ trợ của bộ ký tự được chỉ định. Kiểu con chính là văn bản thuần túy, chỉ đơn giản là một chuỗi ký tự ASCII hoặc ký tự ISO 8859. Kiểu con được làm giàu cho phép định dạng linh hoạt hơn.

Kiểu nhiều phần chỉ ra rằng phần thân chứa nhiều phần độc lập. Trường tiêu đề Loại-Nội dung bao gồm một tham số (được gọi là ranh giới) xác định dấu phân cách giữa các phần nội dung. Ranh giới này không được xuất hiện trong bất kỳ phần nào của thư. Mỗi ranh giới bắt đầu trên một dòng mới và bao gồm hai dấu gạch nối theo sau là giá trị đường biên. Ranh giới cuối cùng, chỉ racuối phần cuối, cũng có hậu tố là hai dấu gạch nối. Trong mỗi phần, có thể có một tiêu đề MIME thông thường tùy chọn.

Đây là một ví dụ đơn giản về một thông báo nhiều phần chứa hai phần — cả hai đều bao gồm văn bản đơn giản (lấy từ RFC 2046).

Từ: Nathaniel Borenstein <nsb@bellcore.com> Tới: Ned Freed <ned@innosoft.com>
Chủ đề: Tin nhắn mẫu MIME-Phiên bản: 1.0
Loại nội dung: nhiều phần / hỗn hợp; ranh giới = "ranh giới đơn giản"
Đây là phần mở đầu. Nó sẽ được bỏ qua, mặc dù nó là một nơi thuận tiện cho các nhà soạn thư để bao gồm một ghi chú giải thích cho những người đọc không tuân thủ MIME.
—Danh giới đơn giản

Đây là văn bản thuần ASCII được nhập ngầm. Nó KHÔNG kết thúc bằng dấu ngắt dòng.
—Danh giới đơn giản
Loại nội dung: văn bản / thuần túy; charset = us-ascii

Đây là văn bản ASCII thuần túy được nhập rõ ràng. Nó KHÔNG kết thúc bằng dấu ngắt dòng.
—Danh giới đơn giản—
Đây là phần kết. Nó cũng được bỏ qua.

Có bốn kiểu con của kiểu đa phần, tất cả đều có cùng một cú pháp tổng thể. Loại phụ nhiều phần / hỗn hợp được sử dụng khi có nhiều bộ phận cơ thể không rõ ràng cần được nhóm lại theo một thứ tự cụ thể. Đối với kiểu con đa phần / song song, thứ tự của các phần không có ý nghĩa. Nếu hệ thống của người nhận phù hợp, nhiều phần có thể được trình bày song song. Ví dụ: một phần hình ảnh hoặc văn bản có thể được kèm theo lời bình luận bằng giọng nói được phát trong khi hình ảnh hoặc văn bản được hiển thị.

Đối với kiểu phụ nhiều phần / thay thế, các phần khác nhau là những bản diễn tả khác nhau của cùng một thông tin. Sau đây là một ví dụ:

Từ: Nathaniel Borenstein <nsb@bellcore.com> Tới: Ned Freed <ned@innosoft.com>
Chủ đề: Thư văn bản được định dạng MIME-Phiên bản: 1.0
Nội dung-Loại: nhiều phần / thay thế; ranh giới = ranh giới42
—Boundary42

Nội dung-Loại: văn bản / đơn giản; charset = us-ascii

... phiên bản văn bản thuần túy của tin nhắn ở đây ....


—Boundary42
Loại nội dung: văn bản / được bổ sung chi tiết

.... RFC 1896 văn bản / phiên bản làm giàu của cùng một thông báo ở đây ...
— Boundary42—

Trong kiểu phụ này, các bộ phận được sắp xếp theo thứ tự ưu tiên ngày càng tăng. Đối với ví dụ này, nếu hệ thống người nhận có khả năng hiển thị thư ở định dạng văn bản / được bổ sung chi tiết, điều này được thực hiện; nếu không, định dạng văn bản thuần túy sẽ được sử dụng.

Loại phụ đa phần / tiêu hóa được sử dụng khi mỗi bộ phận cơ thể liên kết với nhau được đặt trước dưới dạng thông báo RFC 5322 với tiêu đề. Kiểu con này cho phép xây dựng một thông báo có các phần là các thông điệp riêng lẻ. Ví dụ: người kiểm duyệt của một nhóm có thể thu thập các tin nhắn e-mail từ những người tham gia, nhóm các tin nhắn này và gửi chúng trong một tin nhắn MIME đóng gói.

Loại thông báo cung cấp một số khả năng quan trọng trong MIME. Kiểu con message / rfc822 chỉ ra rằng phần thân là toàn bộ thông báo, bao gồm cả phần đầu và phần nội dung. Mặc dù tên của kiểu con này, thông điệp được đóng gói có thể không chỉ là một thông báo RFC 5322 đơn giản mà còn là bất kỳ thông báo MIME nào.

Thông báo / kiểu con một phần cho phép phân mảnh một thông báo lớn thành một số phần, các phần này phải được tập hợp lại tại đích. Đối với loại phụ này, ba tham số được chỉ định trong trường Content-Type: Message / Partial: id chung cho tất cả các đoạn của cùng một thông báo, số thứ tự duy nhất cho mỗi đoạn và tổng số đoạn.

Kiểu phụ nội dung thông báo / ngoại thân chỉ ra rằng dữ liệu thực tế được kết nối trong thông báo này không được chứa trong nội dung. Thay vào đó, phần thân chứa thông tin cần thiết để truy cập dữ liệu. Cũng như các kiểu thông báo khác, kiểu con mes- sage / external-body có một tiêu đề bên ngoài và một thông điệp được đóng gói với tiêu đề riêng của nó. Trường cần thiết duy nhất trong tiêu đề bên ngoài là trường Loại-Nội dung, trường này xác định đây là loại phụ thư / nội dung bên ngoài. Tiêu đề bên trong là tiêu đề thư cho thư được đóng gói. Trường Content-Type trong tiêu đề bên ngoài phải bao gồm một tham số kiểu truy cập, cho biết phương thức truy cập, chẳng hạn như FTP (giao thức truyền tệp).

Loại ứng dụng đề cập đến các loại dữ liệu khác, thường là dữ liệu nhị phân không liên kết hoặc thông tin được ứng dụng dựa trên thư xử lý.

MIME TRANSFER ENCODINGS

Thành phần chính khác của đặc tả MIME, ngoài đặc tả kiểu nội dung, là định nghĩa về các mã hóa truyền cho nội dung thông báo. Mục tiêu là cung cấp phân phối đáng tin cậy trên phạm vi môi trường lớn nhất.

Tiêu chuẩn MIME xác định hai phương pháp mã hóa dữ liệu. Trường Nội dung- Truyền- Mã hóa thực tế có thể nhận sáu giá trị, như được liệt kê trong Bảng 18.4. Tuy nhiên, ba trong số các giá trị này (7bit, 8bit và nhị phân) chỉ ra rằng không có mã hóa nào được thực hiện nhưng cung cấp một số thông tin về bản chất của dữ liệu. Đối với chuyển khoản SMTP, sẽ an toàn khi sử dụng hình thức 7bit. Các dạng 8bit và nhị phân có thể được sử dụng trong các bối cảnh vận chuyển thư khác. Một giá trị Mã hóa-Chuyển-Nội dung khác là x-token,

cho biết rằng một số lược đồ mã hóa khác được sử dụng mà tên sẽ được cung cấp. Đây có thể là một chương trình dành riêng cho nhà cung cấp hoặc dành riêng cho ứng dụng. Cả haicác lược đồ mã hóa thực tế được xác định là có thể in được trích dẫn và base64. Hai lược đồ được định nghĩa để cung cấp sự lựa chọn giữa một kỹ thuật truyền về cơ bản là con người có thể đọc được và một kỹ thuật an toàn cho tất cả các loại dữ liệu theo cách nhỏ gọn hợp lý. 

Mã hóa truyền có thể in được trích dẫn rất hữu ích khi dữ liệu bao gồm phần lớn các octet tương ứng với các ký tự ASCII có thể in được. Về bản chất, nó đại diện cho các ký tự không an toàn bằng cách biểu diễn hệ thập lục phân của mã của chúng và

giới thiệu ngắt dòng có thể đảo ngược (mềm) để giới hạn dòng thông báo trong 76 ký tự.

Mã hóa truyền base64, còn được gọi là mã hóa radix-64, là một mã phổ biến để mã hóa dữ liệu nhị phân tùy ý theo cách không thể xâm phạm đến quá trình xử lý của các chương trình truyền tải thư. Nó cũng được sử dụng trong PGP và được mô tả trong Phụ lục 18A.

A MULTIPART EXAMPLE

Lấy từ RFC 2045, là phác thảo của một thông điệp nhiều phần phức tạp. Tin nhắn có năm phần được hiển thị nối tiếp: hai phần văn bản thuần túy giới thiệu, một tin nhắn nhiều phần được nhúng, một phần văn bản phong phú và một tin nhắn văn bản được đóng gói trong bộ ký tự không phải ASCII. Tin nhắn đa phần được nhúng có hai phần được hiển thị song song: một hình ảnh và một đoạn âm thanh.

CANONICAL FORM

MỘTnkhái niệm quan trọng trong MIME và S / MIME là ở dạng chuẩn. Biểu mẫu chính tắc là một định dạng, phù hợp với loại nội dung, được tiêu chuẩn hóa để sử dụng giữa các hệ thống. Điều này trái ngược với biểu mẫu gốc, là một định dạng có thể đặc biệt đối với một hệ thống cụ thể. Bảng 18.5, từ RFC 2049, sẽ giúp làm rõ vấn đề này.

S/MIME Functionality 

Về chức năng chung, S / MIME rất giống với PGP. Cả hai đều cung cấp khả năng ký và / hoặc mã hóa tin nhắn. Trong phần phụ này, chúng tôi tóm tắt ngắn gọn khả năng S / MIME..

FUNCTIONNS S / MIME cung cấp các chức năng sau.

• Dữ liệu được phong bì: Bao gồm nội dung được mã hóa thuộc bất kỳ loại nào và các khóa mã hóa nội dung được mã hóa cho một hoặc nhiều người nhận.
• Dữ liệu đã ký: Chữ ký điện tử được hình thành bằng cách lấy bản tóm tắt thông báo của nội dung được ký và sau đó mã hóa nội dung đó bằng khóa riêng của người ký. Nội dung cộng với chữ ký sau đó được mã hóa bằng cách sử dụng mã hóa base64. Chỉ người nhận có khả năng S / MIME mới có thể xem tin nhắn dữ liệu đã ký.
• Dữ liệu có chữ ký rõ ràng: Cũng như dữ liệu đã ký, chữ ký điện tử của nội dung được hình thành. Tuy nhiên, trong trường hợp này, chỉ có chữ ký điện tử được mã hóa bằng base64. Như một kết quả, người nhận không có  S / MIME có khả năng xem nội dung , mặc dù họ không thể xác minh chữ ký.
• Dữ liệu đã ký và được bao bọc: Các thực thể chỉ được ký và chỉ được mã hóa có thể được lồng vào nhau, để dữ liệu được mã hóa có thể được ký và dữ liệu đã ký hoặc dữ liệu được ký rõ ràng có thể được mã hóa.

CRYPTOGRAPHIC ALGORITHMS

Bảng 18.6 tóm tắt các thuật toán mật mã được sử dụng  S/ MIME. S/ MIME sử dụng thuật ngữ sau lấy từ RFC 2119 (từ khóa được sử dụng trong RFC để chỉ ra mức yêu cầu) để chỉ định mức yêu cầu để xác định yêu cầu cấp độ:

• MUST:  Định nghĩa là một yêu cầu tuyệt đối của đặc điểm kỹ thuật. Việc triển khai phải bao gồm tính năng hoặc chức năng này để phù hợp với đặc điểm kỹ thuật.
• SHOULD:  Có thể có những lý do hợp lệ trong những trường hợp cụ thể để bỏ qua tính năng hoặc chức năng này, nhưng chúng tôi khuyên bạn nên triển khai bao gồm tính năng hoặc chức năng.

S / MIME kết hợp ba thuật toán khóa công khai. Tiêu chuẩn Chữ ký Số (DSS) được mô tả trong Chương 13 là thuật toán ưu tiên cho chữ ký điện tử. S / MIME liệt kê Diffie-Hellman là thuật toán ưa thích để mã hóa khóa phiên; trên thực tế, S / MIME sử dụng một biến thể của Diffie-Hellman cung cấp

Hình 18.6 Cryptographic Algorithms Used in S/MIME

mã hóa / giải mã, đã biếttrong vai ElGamal (Chương 10). Để thay thế, RSA, được mô tả trong Chương 9, có thể được sử dụng cho cả chữ ký và mã hóa khóa phiên. Đây là các thuật toán tương tự được sử dụng trong PGP và cung cấp mức độ bảo mật cao. Đối với hàm băm được sử dụng để tạo chữ ký điện tử, đặc điểm kỹ thuật yêu cầu SHA-1 160-bit nhưng khuyến nghị hỗ trợ bộ thu cho MD5 128-bit để tương thích ngược với các phiên bản cũ hơn của S / MIME. Như chúng ta đã thảo luận trong Chương 11, có mối quan tâm chính đáng về tính bảo mật của MD5, vì vậy SHA-1 rõ ràng là lựa chọn thay thế ưu tiên.

Để mã hóa tin nhắn, khuyến nghị sử dụng DES ba khóa ba khóa (tripleDES), nhưng các triển khai tuân thủ phải hỗ trợ RC2 40 bit. Sau đó là một thuật toán mã hóa yếu nhưng cho phép tuân thủ các kiểm soát xuất khẩu của Hoa Kỳ.

Đặc tả S / MIME bao gồm một cuộc thảo luận về quy trình để quyết định sử dụng thuật toán mã hóa nội dung nào. Về bản chất, một đại lý gửi có hai quyết định để thực hiện. Đầu tiên, tác nhân gửi phải xác định xem tác nhân nhận có khả năng giải mã bằng cách sử dụng một thuật toán mã hóa nhất định hay không. Thứ hai, nếu đại lý nhận chỉ có khả năng chấp nhận nội dung được mã hóa yếu, tác nhân gửi phải quyết định xem có chấp nhận gửi bằng mã hóa yếu hay không. Để hỗ trợ quá trình quyết định này, tác nhân gửi có thể thông báo khả năng giải mã của nó theo thứ tự ưu tiên cho bất kỳ thông báo nào mà nó gửi đi..

Các quy tắc sau, theo thứ tự sau, phải được tuân theo bởi một tác nhân gửi.

1. Nếu tác nhân gửi có danh sách các khả năng giải mã ưu tiên từ người nhận dự định, nó NÊN chọn khả năng giải mã đầu tiên (ưu tiên cao nhất) trong danh sách mà nó có thể sử dụng.

2. Nếu tác nhân gửi không có danh sách các khả năng như vậy từ người nhận dự định nhưng đã nhận được một hoặc nhiều thông điệp từ người nhận, thì thông báo gửi đi NÊN sử dụng cùng một thuật toán mã hóa như đã được sử dụng trên thông điệp đã ký và mã hóa cuối cùng nhận được từ đó người nhận dự định.
3. Nếu tác nhân gửi không có kiến ​​thức về khả năng giải mã của người nhận dự định và sẵn sàng mạo hiểm rằng người nhận có thể không giải mã được thông điệp, thì tác nhân gửi NÊN sử dụng ba DES.
4. Nếu tác nhân gửi không có kiến thức về khả năng giải mã của người nhận dự định và không sẵn sàng mạo hiểm rằng người nhận có thể không giải mã được tin nhắn, thì tác nhân gửi PHẢI sử dụng RC2 / 40.

Nếu một tin nhắn được gửi đến nhiều người nhận và không thể chọn một thuật toán mã hóa chung cho tất cả, thì tác nhân gửi sẽ cần gửi hai tin nhắn. Tuy nhiên, trong trường hợp đó, điều quan trọng cần lưu ý là tính bảo mật của thông báo dễ bị tổn thương khi truyền một bản sao có độ bảo mật thấp hơn.

S/MIME Messages 

S / MIME sử dụng một con số mới MIME loại nội dung, thể hiện trong Bảng 18.7. Tất cả các loại ứng dụng mới đều sử dụng PKCS chỉ định. Điều này đề cập đến một tập hợp các thông số kỹ thuật mật mã khóa công khai do Phòng thí nghiệm RSA phát hành và được cung cấp cho nỗ lực S / MIME.

Chúng tôi lần lượt xem xét từng điều này sau khi lần đầu tiên xem xét các quy trình chung để chuẩn bị thông điệp S / MIME.

SECURING A MIME ENTITY

S / MIMEbảo mật một thực thể MIME bằng chữ ký, mã hóa hoặc cả hai. Thực thể MIME có thể là toàn bộ thư (ngoại trừ tiêu đề RFC 5322) hoặc nếu kiểu nội dung MIME là nhiều phần, thì thực thể MIME là một hoặc nhiều phần con của thư. Thực thể MIME được chuẩn bị theo các quy tắc thông thường để chuẩn bị tin nhắn MIME. Sau đó, thực thể MIME cộng với một số dữ liệu liên quan đến bảo mật, chẳng hạn như số nhận dạng thuật toán và chứng chỉ, được S / MIME xử lý để tạo ra thứ được gọi là đối tượng PKCS. Một đối tượng PKCS sau đó được coi là nội dung thư và được bao bọc trong MIME (được cung cấp với các tiêu đề MIME thích hợp). Quá trình này sẽ trở nên rõ ràng khi chúng ta xem xét các đối tượng cụ thể và cung cấp các ví dụ.

Trong mọi trường hợp, thông báo được gửi sẽ được chuyển sang dạng chuẩn. Cụ thể-thông thường, đối với một loại và loại phụ nhất định, biểu mẫu chính tắc thích hợp được sử dụng cho nội dung thông báo. Đối với thông báo nhiều phần, biểu mẫu chuẩn thích hợp được sử dụng cho mỗi phần con.

Việc sử dụng mã hóa chuyển giao cần được chú ý đặc biệt. Đối với hầu hết các trường hợp, kết quả của việc áp dụng thuật toán bảo mật sẽ là tạo ra một đối tượng được biểu diễn một phần hoặc toàn bộ trong dữ liệu nhị phân tùy ý. Sau đó, điều này sẽ được bao bọc trong một thông báo MIME bên ngoài và mã hóa truyền có thể được áp dụng tại thời điểm đó, thường là base64. Tuy nhiên, trong trường hợp thư được ký nhiều phần (được mô tả chi tiết hơn ở phần sau), nội dung thư trong một trong các phần con không thay đổi theo quy trình bảo mật. Trừ khi nội dung đó là 7bit, nội dung đó phải được mã hóa bằng base64 hoặc có thể in được trích dẫn để không có nguy cơ thay đổi nội dung mà chữ ký đã được áp dụng.

Bây giờ chúng ta xem xét từng loại nội dung S / MIME..

Hình 18.7 S/MIME Content Types

ENVELOPEDDATA

Loại phụ ứng dụng / pkcs7-mime được sử dụng cho một trong bốn loại xử lý S / MIME, mỗi loại có một tham số kiểu smime duy nhất. Trong mọi trường hợp, thực thể kết quả (được gọi là đối tượng) được biểu diễn dưới dạng được gọi là Quy tắc mã hóa cơ bản (BER), được định nghĩa trong Khuyến nghị ITU-T

X.209. Định dạng BER bao gồm các chuỗi octet tùy ý và do đó là dữ liệu nhị phân. Một đối tượng như vậy sẽ được mã hóa bằng base64 trong thông điệp MIME bên ngoài. Đầu tiên, chúng ta xem xét dữ liệu phong bì.

Các bước để chuẩn bị một thực thể MIME dữ liệu được bao bọc là

1. Tạo khóa phiên ngẫu nhiên giả cho một mã hóa đối xứng cụ thể algorithm (RC2 / 40 hoặc tricầu xin DES).
2. Đối với mỗi người nhận, hãy mã hóa khóa phiên bằng khóa RSA công khai của người nhận.
3. Đối với mỗi người nhận, hãy chuẩn bị một khối được gọi là RecipientInfo chứa mã định danh của chứng chỉ khóa công khai của người nhận, 4 số nhận dạng của thuật toán được sử dụng để mã hóa khóa phiên và khóa phiên được mã hóa.
4. Mã hóa nội dung tin nhắn bằng khóa phiên.

Các khối RecipientInfo theo sau là nội dung được mã hóa tạo thành Dữ liệu được mã hóa. Thông tin này sau đó được mã hóa thành base64. Một thông báo mẫu (không bao gồm các tiêu đề RFC 5322)

Nội dung-Loại: ứng dụng / pkcs7-mime; smime-type = được bao bọc-dữ liệu; name = smime.p7m
Nội dung-Chuyển-Mã hoá: base64
Content-Disposition: tập tin đính kèm; filename = smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

Để khôi phục tin nhắn đã mã hóa, trước tiên người nhận gỡ bỏ base64 mã hóa. Sau đó, khóa riêng của người nhận được sử dụng để khôi phục khóa phiên. Cuối cùng, nội dung tin nhắn được giải mã bằng khóa phiên.

SIGNEDDATA

Kiểu biểu tượng dữ liệu đã ký có thể được sử dụng với một hoặc nhiều người ký. Để rõ ràng, chúng tôi giới hạn mô tả của chúng tôi trong trường hợp của một chữ ký điện tử duy nhất. Các bước để chuẩn bị một thực thể MIME đã ký Dữ liệu là

1. Lựa chọn một thuật toán thông báo thông báo (SHA hoặc MD5).
2. Tính toán thông báo tóm tắt (hàm băm) của nội dung được ký.
3. Mã hóa thông báo thông báo bằng khóa cá nhân của người ký.
4. Chuẩn bị một khối được gọi là SignerInfo chứa chứng chỉ khóa công khai của người ký, số nhận dạng của thuật toán thông báo thông báo, số nhận dạng của thuật toán được sử dụng để mã hóa thông báo thông báo và thông báo thông báo trung gian được mã hóa.

Thực thể SignData bao gồm một loạt các khối, bao gồm một mã định danh thuật toán thông báo thông báo, thông báo đang được ký và SignerInfo. Thực thể SignData cũng có thể bao gồm một tập hợp các chứng chỉ khóa công khai đủ để tạo thành một chuỗi từ cơ quan cấp chứng chỉ gốc hoặc cấp cao nhất được công nhận đến người ký. Thông tin này sau đó được mã hóa thành base64. Một thông báo mẫu (không bao gồm các tiêu đề RFC 5322) là

Content-Type: application/pkcs7-mime; smime-type=signeddata; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75

Để khôi phục thư đã ký và xác minh chữ ký, trước tiên người nhận loại bỏ mã hóa base64. Sau đó, khóa công khai của người ký được sử dụng để giải mãtóm lược thông điệp. Người nhận tính toán một cách độc lập thông báo thông báo và so sánh nó với thông báo thông báo đã được giải mã để xác minh chữ ký.

CLEAR SIGNING

Việc ký kết rõ ràng đạt được khi sử dụng kiểu nội dung nhiều phần với kiểu con đã ký. Như đã đề cập, quá trình ký kết này không liên quan đến việc chuyển đổi thông điệp được ký, để thông điệp được gửi “rõ ràng”. Vì vậy, người nhận có khả năng MIME nhưng không có khả năng S / MIME có thể đọc tin nhắn đến.

Một tin nhắn nhiều phần / đã ký có hai phần. Phần đầu tiên có thể là bất kỳ kiểu MIME nào nhưng phải được chuẩn bị để nó không bị thay đổi trong quá trình chuyển từ nguồn đến đích. Điều này có nghĩa là nếu phần đầu tiên không phải là 7bit, thì nó cần được mã hóa sử dụng base64 hoặc có thể in được trích dẫn. Sau đó, phần này được xử lý theo cách tương tự như signData, nhưng trong trường hợp này một đối tượng có định dạng signData được tạo ra có trường nội dung thư trống. Đối tượng này là một chữ ký tách rời. Sau đó, nó được mã hóa bằng cách sử dụng base64 để trở thành phần thứ hai của thông điệp đa phần / có chữ ký. Phần thứ hai này có kiểu nội dung MIME của ứng dụng và kiểu phụ của chữ ký pkcs7. Đây là một tin nhắn mẫu:

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
—boundary42
Content-Type: text/plain
This is a clear-signed message.
—boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
—boundary42—

Tham số giao thức chỉ ra rằng đây là một thực thể được ký kết rõ ràng gồm hai phần. Tham số micalg cho biết loại thông báo thông báo được sử dụng. Người nhận có thể xác minh chữ ký bằng cách lấy thông báo tóm tắt của phần đầu tiên và so sánh nó với thông báo tóm tắt được khôi phục từ chữ ký trong phần thứ hai.

REGISTRATION REQUEST

Thông thường, một ứng dụng hoặc người dùng sẽ nộp đơn cho cơ quan cấp chứng chỉ cho public-key chứng chỉ. Application/pkcs10 S/MIME được sử dụng để chuyển một yêu cầu chứng nhận. Yêu cầu chứng nhận bao gồm khối RequestInfo chứng nhận, theo sau là mã định danh của thuật toán mã hóa khóa công khai, theo sau là chữ ký của khối chứng nhận certificateRequestInfo được thực hiện bằng khóa riêng của người gửi. Khối certificateRequestInfo bao gồm tên của chủ thể chứng chỉ (thực thể có khóa công khai sẽ được chứng nhận) và biểu diễn chuỗi bit cho khóa công khai của người dùng.

CERTIFICATES-ONLY MESSAGE

MỘT chỉ có thể gửi tin nhắn chứa chứng chỉ hoặc danh sách thu hồi chứng chỉ (CRL) theo yêu cầu đăng ký. Thông báo là một kiểu / kiểu ứng dụng / pkcs7-mime với tham số kiểu smime là suy biến. Các bước liên quan cũng giống như các bước để tạo thông báo Dữ liệu đã ký, ngoại trừ việc không có nội dung thông báo và trường signerInfo trống.

S/MIME Certificate Processing 

S / MIMEsử dụng chứng chỉ khóa công khai phù hợp với phiên bản 3 của X.509 (xem Chương 14). Về mặt nào đó, lược đồ quản lý khóa được S / MIME sử dụng là sự kết hợp giữa hệ thống phân cấp chứng chỉ X.509 nghiêm ngặt và mạng tin cậy của PGP. Như với mô hình PGP, người quản lý S / MIME và / hoặc người dùng phải định cấu hình từng máy khách với danh sách các khóa đáng tin cậy và với danh sách thu hồi chứng chỉ. Có nghĩa là, khả năng đáp ứng là cục bộ để duy trì các chứng chỉ cần thiết để xác minh chữ ký gửi đến và mã hóa các thông điệp gửi đi. Mặt khác, các chứng chỉ được ký bởi các cơ quan cấp chứng chỉ.

USER AGENT ROLE

MỘT Người dùng S / MIME có một số chức năng quản lý khóa để thực hiện.

• Key generation: Người dùng của một số tiện ích quản trị liên quan (ví dụ: một tiện ích liên quan đến quản lý mạng LAN) PHẢI có khả năng tạo các cặp khóa Diffie-Hellman và DSS riêng biệt và NÊN có khả năng tạo các cặp khóa RSA. Mỗi cặp khóa PHẢI được tạo từ một nguồn khôngđầu vào ngẫu nhiên xác định và được bảo vệ theo cách an toàn. Tác nhân người dùng NÊN tạo các cặp khóa RSA có độ dài trong khoảng từ 768 đến 1024 bit và KHÔNG ĐƯỢC tạo độ dài dưới 512 bit.
• Registration: Khóa công khai của người dùng phải được đăng ký với cơ quan cấp chứng chỉ để nhận được chứng chỉ khóa công khai X.509.
• Certificate storage and retrieval: Người dùng yêu cầu quyền truy cập vào danh sách chứng chỉ cục bộ để xác minh chữ ký đến và mã hóa các thông điệp gửi đi. Một danh sách như vậy có thể được duy trì bởi người dùng hoặc bởi một tổ chức quản trị địa phương nào đó thay mặt cho một số người dùng.

VERISIGN CERTIFICATES

Có một số công ty cung cấp dịch vụ của cơ quan cấp chứng chỉ (CA). Ví dụ, Nortel đã thiết kế một giải pháp CA doanh nghiệp và có thể cung cấp hỗ trợ S / MIME trong một tổ chức. Có một số CA dựa trên Internet, bao gồm VeriSign, GTE và Bưu điện Hoa Kỳ. Trong số này, được sử dụng rộng rãi nhất là dịch vụ VeriSign CA, một mô tả ngắn gọn về dịch vụ mà chúng tôi hiện cung cấp.

VeriSign cung cấp dịch vụ CA nhằm tương thích với S / MIME và nhiều ứng dụng khác.VeriSign phát hành chứng chỉ X.509 với tên sản phẩm là VeriSign Digital ID. Tính đến đầu năm 1998, hơn 35.000 trang web thương mại đang sử dụng ID kỹ thuật số của máy chủ VeriSign và hơn một triệu ID kỹ thuật số của người tiêu dùng đã được cấp cho người dùng trình duyệt Netscape và Microsoft.

Thông tin có trong ID kỹ thuật số phụ thuộc vào loại ID kỹ thuật số và việc sử dụng nó. Ở mức tối thiểu, mỗi ID kỹ thuật số chứa

• Khóa công khai của chủ sở hữu
• Tên hoặc bí danh của chủ sở hữu
• Ngày hết hạn của ID kỹ thuật số
• Số sê-ri của ID kỹ thuật số
• Tên của tổ chức chứng nhận đã cấp ID kỹ thuật số
• Chữ ký số của tổ chức cung cấp dịch vụ chứng thực chữ ký số đã cấp ID số

ID kỹ thuật số cũng có thể chứa thông tin khác do người dùng cung cấp, bao gồm

• Địa chỉ nhà
• Địa chỉ email
• Căn bản thông tin đăng ký (quốc gia, mã zip, tuổi và giới tính)

VeriSign cung cấp ba cấp độ hoặc lớp bảo mật cho các chứng chỉ khóa công khai, như được tóm tắt trong Bảng 18.8. Người dùng yêu cầu chứng chỉ trực tuyến tại trang Web của VeriSign hoặc các trang web tham gia khác. Yêu cầu Lớp 1 và Lớp 2 được xử lý trực tuyến và trong hầu hết các trường hợp, chỉ mất vài giây để phê duyệt. Một cách ngắn gọn, các quy trình sau đây được sử dụng.

• Đối với ID kỹ thuật số Lớp 1, VeriSign xác nhận địa chỉ e-mail của người dùng bằng cách gửi thông tin nhận mã PIN và ID kỹ thuật số đến địa chỉ e-mail được cung cấp trong ứng dụng.
• Đối với ID kỹ thuật số Lớp 2, VeriSign xác minh thông tin trong ứng dụng thông qua so sánh tự động với cơ sở dữ liệu người tiêu dùng ngoài

Bảng 18.8 Các lớp chứng chỉ khóa công khai của Verisign

IA = Cơ quan phát hành

CA = Cơ quan cấp giấy chứng nhận

PCA = Cơ quan cấp chứng chỉ chính công khai VeriSign PIN = Số nhận dạng cá nhân

LRAA = Quản trị viên Cơ quan Đăng ký Địa phương

thực hiện tất cả các kiểm tra được liên kết với ID kỹ thuật số loại 1. Cuối cùng, xác nhận được gửi đến địa chỉ bưu điện được chỉ định để cảnh báo người dùng rằng ID kỹ thuật số đã được cấp dưới tên của họ.

• Vì ID kỹ thuật số Lớp 3, VeriSign yêu cầu mức độ đảm bảo danh tính cao hơn. Một cá nhân phải chứng minh danh tính của mình bằng cách cung cấp các chứng chỉ có công chứng hoặc nộp đơn trực tiếp.

Tăng cường Security Services

Theo bài viết này, ba dịch vụ bảo mật nâng cao đã được đề xuất trong một dự thảo Internet. Các chi tiết này có thể thay đổi và các dịch vụ bổ sung có thể được thêm vào. Ba dịch vụ là

• Signed receipts: Có thể yêu cầu biên nhận đã ký trong đối tượng SignedData. Việc gửi lại biên nhận đã ký sẽ cung cấp bằng chứng về việc gửi thư cho người khởi tạo thông điệp và cho phép người khởi tạo chứng minh với bên thứ ba rằng người nhận đã nhận được thông báo. Về bản chất, người nhận ký toàn bộ thông điệp gốc cộng với chữ ký ban đầu (của người gửi) và thêm ký tên mới để tạo thành một thông điệp S / MIME mới.
• Security labels: Nhãn bảo mật có thể được bao gồm trong thuộc tính đã xác thực- utes của một đối tượng SignedData. Nhãn bảo mật là một tập hợp thông tin bảo mật liên quan đến tính nhạy cảm của nội dung được bảo vệ bởi gói S / MIME. Các nhãn có thể được sử dụng để kiểm soát truy cập, bằng cách chỉ ra người dùng nào được phép truy cập vào một đối tượng. Các mục đích sử dụng khác bao gồm mức độ ưu tiên (bí mật, bí mật, hạn chế, v.v.) hoặc dựa trên vai trò, mô tả loại người nào có thể xem thông tin (ví dụ: nhóm chăm sóc sức khỏe của bệnh nhân, đại lý thanh toán y tế, v.v.).
• Secure mailing lists: Khi người dùng gửi một tin nhắn cho nhiều người nhận, cần phải có số lượng xử lý xác nhận cho mỗi người nhận, bao gồm cả việc sử dụng khóa công khai của mỗi người nhận. Người dùng có thể yên tâm với công việc này bằng cách sử dụng các dịch vụ của S / MIME Mail List Agent (MLA). MLA có thể nhận một tin nhắn đến, thực hiện mã hóa dành riêng cho người nhận cho từng người nhận và chuyển tiếp tin nhắn. Người khởi tạo thông báo chỉ cần gửi thông báo đến MLA với mã hóa được thực hiện bằng khóa công khai của MLA.