Figure 15.8, lấy từ RFC 2045 là tóm tắt của một thông điệp multipart phức tạp. Thông điệp gồm năm phần: hai đoạn plain text mở đầu, một thông điệp multipart nhúng, một phần richtext, và một thông điệp kết thúc không chứa ký tự ASCII. Thông điệp nhúng multipart gồm 2 phần được hiển thị song song, một tấm hình và một mảnh audio.
Figure 15.8. Example MIME Message Structure
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com>
Subject: A multipart example Content-Type: multipart/mixed;
Đây là phần đầu của thông địêp multipart. Ứng dụng đọc định dạng multipart sẽ lược bỏ phần này. Nếu bạn đọc văn bản này, bạn có thể muốn thay đổi trình đọc mail để nó hiển thị thông điệp multipart hợp lý.
--unique-boundary-1
...một vài đoạn văn bản hiển thị ở đây
[Chú ý là những dòng trống ở trên không có nghĩa là những trường header, mà nó là văn bản ký tự USASCII. Sẽ ghi rõ ở phần kế tiếp]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts.
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here....
--unique-boundary-2 Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... base64-encoded image data goes here.... --unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched
This is <bold><italic>richtext.</italic></bold> <smaller>as defined in RFC 1896</smaller>
Isn't it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1
Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Additional text in ISO-8859-1 goes here ... --unique-boundary-1—
Mội khái niệm quan trọng trong MIME và S/MIME là canonical form. Canonical form là một định dạng thích hợp với kiểu nội dung (content type) đuợc chuẩn hoá để sử dụng giữa các hệ thống. Nó trái ngược với native form, là định dạng riêng biệt cho từng hệ thống cụ thể. Bảng 15.5, từ RFC 2049, sẽ làm sáng tỏ vấn để này:
Table 15.5. Native and Canonical Form Native
Form native được sử dụng, khi thích hợp thì quy ước local end-of-line cũng Phần body được tạo ra trong định dạng native của hệ thống. Bộ ký tự được sử dụng. Phần body có thể là file văn bản kiểu UNIX, hoặc là một hình ảnh mành hoá Sun, một file chỉ mục VMS, dữ liệu audio ở định dạng phụ thuộc vào hệ thống được lưu trong bộ nhớ, hoặc bất kì thứ gì thích hợp với mô hình cục bộ cho việc trình bày vài dạng thông tin. Về cơ bản, dữ lệiu được tạo ra dưới dạng “native” mà thích hợp với kiểu được chỉ rõ bằng kiểu media.
Canonical
Form bảng ghi và thông tin thuộc tính file, được chuyển đổi sang dạng tiêu Toàn bộ phần body, bao gồm thông tin “out-of-band” như là độ dài chuẩn (canonical form) chung. Kiểu media cụ thể của phần thân (body) cũng như những thuộc tính liên quan của nó quyết định tính chất của dạng tiêu chuẩn được sử dụng. Việc chuyển đổi sang dạng tiêu chuẩn thích hợp có thể liên quan đến chuyển đổi bộ ký tự, biến đổi của dữ liệu audio, việc nén, hoặc những hoạt động khác của các kiểu media.Tuy nhiên, nếu như việc chuyển đổi bộ ký tự có liên quan, thì phải hiểu ý nghĩa của kiểu media do nó có liên quan mật thiết với việc chuyển đổi bộ ký tự (liên quan đến ý nghĩa ngữ pháp của các ký tự trong kiểu text hơn là “plain”)
S/MIME Functionality
S/MIME rất tương đồng với PGP. Cả hai đều đưa ra cách ký và mã hoá thông điệp.Trong phần này, chúng ta sẽ mô tả ngắn gọn về khả năng của S/MIME. Sau đó, chúng ta sẽ xem chi tiết hơn bằng ví dụ về những định dạng thông điệp và chuẩn bị thông điệp.
Chức năng (Functions)
• Đóng gói dữ liệu: Bao gồm nội dung đã mã hoá của bất kì kiểu dữ liệu và những khoá mã hoá nội dung đã được mã hoá cho một hoặc nhiều người nhận.
• Ký dữ liệu: Tạo chữ ký số bằng cách lấy tóm tắt thông điệp (message digest) của nội dung được ký và mã hoá nó bằng base64. Một thông điệp đã được ký chỉ có thể xem được bởi người nhận với hỗ trợ của S/MIME • Xoá dữ liệu ký: Muốn ký dữ liệu thì phải có chữ ký điện tử. Tuy nhiện,
chỉ có chữ ký số được mã hoá bằng base64. Cho nên, nguời nhận nếu không có S/MIME có thể xem nội dung thông điệp mặc dù họ không thể xác thực chữ ký.
• Ký và đóng gói thông điệp: Những thực thể chỉ được ký hoặc chỉ được mã hoá có thể lồng nhau, như vậy dữ liệu đã được mã hoá có thể được ký và dữ liệu đã được ký hoặc dữ liệu clear-signed có thể được mã hoá.
Giải thuật mật mã (Cryptographic Algorithms)
Bảng 15.6 tổng hợp những giải thuật được sử dụng trong S/MIME.S/MIME sử dụng thuật ngữ sau, lấy từ RFC 2119 để chỉ mức độ cần thiết của thuật toán:
• Phải: Định nghĩa là yêu cầu bắt buộc của đặt tả. Thực thi phải bao gồm đặc điểm hặc chức năng này để phù hợp với đặc tả.
• Nên: Có thể bỏ qua đặc điểm hay chức năng này trong nhưng trường hợp cụ thể, nhưng tốt hơn là nên có.
Table 15.6. Cryptographic Algorithms Used in S/MIME
Chức năng Yêu cầu
Tạo và mã hoá tóm tắt thông điệp để sử dụng làm chữ ký điện tử
PHẢI hỗ trợ SHA-1
Người nhận NÊN hỗ trợ MD5 cho tương thích ngược
Bên gửi và nhận PHẢi hỗ trợ DSS Bên gửi NÊN hỗ trợ mã hoá RSA
Bên nhận NÊN hỗ trợ xác thực chữ ký RSA với độ dài khoá từ 512bit đến 1024bit.
Table 15.6. Cryptographic Algorithms Used in S/MIME
Chức năng Yêu cầu
Mã hoá khoá phiên để truyền cùng thông điệp
Bên gửi và nhận NÊN hỗ trợ Diffie-Hellman. Bên gửi và nhận PHẢI hỗ trợ mã hoá RSA với độ dài khoá từ 512 đến 1024 bit.
Mã hoá thông điệp để truyền cùng với khoá phiên một lần
Bên gửi và nhận PHẢI hỗ trợ mã hoá triple DES
Bên gửi NÊN hỗ trợ mã hoá AES. Bên gửi NÊN hỗ trợ mã hoá RC2/40 Tạo mã xác thực thông điệp Bên nhận PHẢI hỗ trợ HMAC với SHA-1
Bên nhận NÊN hỗ trợ HMAC với SHA-1
S/MIME kết hợp chặt chẽ với ba thuật toán khoá công khai. Chuẩn chữ ký số (DSS) mô tả ở chương 13 là giải thuật dùng cho chữ ký số. S/MIME đưa ra Diffie- Hellman như la giải thuật dùng cho mã hoá khoá phiên. Thực ra, S/MIME sử dụng một phiên bản khác của Diffie-Hellman là ElGamal để giải/mã hoá (xem Problem 10.6). Để thay đổi, RSA (mô tả trong chương 9) có thể dùng để mã hoá khoá phiên và chữ ký. Tất cả những giải thuật này cũng dùng trong PGP và cung cấp khả năng bảo mật cao. Về hàm băm để tạo chữ ký số, đặc tả yêu cầu SHA-1 160bit nhưng khuyến cáo người nhận hỗ trợ MD5 128bit để tương thích ngược với những phiên bản cũ của MD5, như vậy nên dùng SHA-1 hơn.
Để mã hoá thông điệp, thuật toán DES 3 khoá (tripleDES) được khuyến khích dùng, nhưng những thực thi phải hỗ trợ RC2 40bit tuy là giải thuật yếu hơn nhưng cho phép làm đúng với những điều khiển US export.
Đặc tà S/MIME bao gồm thảo luận thủ tục để quyết định sử dụng thuật toán mã hoá nào. Thực ra,bên gửi đưa ra hai quyết định. Thứ nhất, bên gửi sử dụng thuật toán mã hoá mà bên nhận có thể giải mã được.Thứ hai, nếu bên nhận chỉ có thể chấp nhận nội dung mã hoá yếu, bên gửi phải quyết định có nên sử dụng mã hoá yếu không. Để hỗ trợ quá trình quyết định này, bên gửi có thể thông báo khả năng giải mã của nó theo
thứ tự ưu tiên của thông điệp mà nó gửi. Bên nhận có thể lưu thông tin đó lại để sử dụng sau.
Bên gửi phải tuân theo thứ tự những luật sau:
1. Nếu bên gửi có một danh sách khả năng giải mã ưu tiên từ người nhận, thì NÊN chọn khả năng ưu tiên cao nhất trong danh sách để sử dụng.
2. Nếu bên gửi không có danh sách ưu tiên, thì những thông điệp tiếp theo NÊN sử dụng thuật toán mã hoá tương tự như thuật toán của thông điệp cuối cùng nhận được từ bên nhận
3. If the sending agent has no knowledge about the decryption capabilities of the intended recipient and is willing to risk that the recipient may not be able to decrypt the message, then the sending agent SHOULD use tripleDES. Nếu bên gửi không biết những khả năng giải mã của bên nhận, mà cũng không cần biết là bên nhận có giải mã được hay không, thì bên gửi NÊN sử dụng tripleDES.
4. Nếu bên gửi không biết những khả năng giải mã của bên nhận, mà cũng không cần biết là bên nhận có giải mã được hay không, thì bên gửi PHẢI sử dụng RC2/40
Nếu một thông điệp được gửi đến nhiều người nhận mà không thể sử dung cùng một thuật toán mã hoá, thì bên gửi sẽ gửi hai thông điệp. Tuy nhiên, trong trường hợp đó phải chú ý khả năng bảo mật của thông điệp vì phiên bản copy có độ bảo mật thấp.
Thông điệp S/MIME (S/MIME Messages)
S/MIME sử dụng nhiều kiểu nội dung (content type) MIME mới như trong bản 15.7. Tất cả kiểu ứng dụng (application type) mới sử dụng PKCS. PKCS chỉ ra một tập các đặc tả bảo mật khoá công khai đưa ra bởi RSA Laboratories và hỗ trợ cho S/MIME.
Table 15.7. S/MIME Content Types Kiểu Kiểu phụ Tham số smime Mô tả
Table 15.7. S/MIME Content Types Kiểu Kiểu phụ Tham số smime Mô tả
phần: một là thông điệp, còn lại là chữ ký.
Application pkcs 7- mime
signedData Thực thể S/MIME đã được ký pkcs 7-
mime envelopedData Thực thể S/MIME đã được mã hoá pkcs 7-
mime
degenerate signedData
Thực thể chỉ chứa khoá công khai pkcs 7-
mime CompressedData Thực thể S/MIIME đã được nén pkcs 7-
signature
signedData Kiểu nội dung của phần phụ chữ ký của một thông điệp multipart/signed.
Chúng ta sẽ xem xét lần lượt những kiểu này sau khi xem quy trình chuẩn bị chung cho thông điệp S/MIME
Bảo vệ thực thể MIME (securing a MIME entity)
S/MIME bảo vệ thực thể MIME bằng chữ ký, mã hoá hoặc cả hai. Thực thể MIME có thể là toàn bộ thông điệp(trừ header RFC), hoặc nếu kiểu nội dung MIME là multipart thì thực thể MIME là một hoặc nhiều phần nhỏ của thông điệp. Việc chuẩn bị thực thể MIME được thực hiện theo quy tắc. Sau đó, thực thể MIME cộng với vài dữ liệu bảo mật liên quan được xử lý bởi S/MIME để tạo ra đối tựợng PKCS. Đối tượng PKCS được xem như nội dung thông điệp và được gói trong MIME (cung cấp thêm header MIME thích hợp). Quá trình này rõ hơn khi ta xem ví dụ và đối tượng cụ thể.
Trong tất cả trường hợp, thông điệp gửi đi sẽ được chuyển đổi sang dạng tiêu chuẩn. Với kiểu và kiểu phụ cụ thể, dạng tiêu chuẩn tương ứng sẽ được sử dụng cho nội dung thông điệp. Với thông điệp multipart, dạng tiêu chuẩn thích hợp sẽ được sử dụng cho mỗi phần phụ.
Cần đặc biệt lưu ý khi mã hóa truyền tải. Trong hầu hết trường hợp, áp dụng mã hóa bảo mật sẽ sinh ra một đối tượng, một phần hay toàn bộ đối tượng này được biểu diễn dưới dạng dữ liệu nhị phân bất kì.Sau đó, nó được gói trong thông điệp MIME, và lúc này sẽ áp dụng mã hóa truyền tải (base64). Tuy nhiên, trong trường hợp là thông điệp multipart đã được ký, nội dung thông điệp trong các phần phụ không bị thay đổi trong quá trình xử lý bảo mật. Trừ khi nội dung dưới dạng 7bit, nó sẽ được mã hóa bằng base64 hoặc quoted-printable, như vậy áp dụng chữ ký sẽ không làm thay đổi nội dung.
Bây giờ chúng ta sẽ xem xét từng kiểu nội dung của S/MIME
EnvelopedData
Kiểu phụ application/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ố type-mime duy nhất. Trong tất cả trường hợp, thực thể kết quả (được xem là một đối tượng) được biểu diễn dưới dạng Basic Encoding Rules(BER), dạng này được định nghĩa trong ITU-T Recommendation X.209. Định dạng BER bao gồm những chuỗi 8bit bất kì và như vậy nó là dữ liệu nhị phân. Đối tượng sẽ được mã hoá chuyển đổi bằng base64 bên trong thông điệp MIME,
Sau đây là những bước chuẩn bị một thực thể envelopedData MIME:
1. Tạo một khoá phiên giả ngẫu nhiên (pseudorandom) cho thuật toán mã hoá đồng bộ cụ thể.
2. Với mỗi người nhận, mã hoá khoá phiên với khoá công khai RSA của họ. 3. Với mỗi người nhận, chuẩn bị một khối RecipientInfo chứa một định danh
của chứng chỉ khoá công khai của họ, định danh của thuật toán được dùng để mã hoá khóa phiên, và khoá phiên đã được mã hoá.
4. Mã hoá nội dung thông điệp với khóa phiên.
Khối RecipientInfo và nội dung đã được mã hoá cấu thành nên envelopedData. Thông tin này sau đó được mã hoá thành base64. Sau đây là một thông điệp ví dụ (bao gồm header RFC 822):
Content-Type: application/pkcs7-mime; smime-type=enveloped- data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
Để giải mã thông điệp, đầu tiên người nhận phải bỏ bớt phần mã hoá base64, sau đó dùng khoá bí mật của họ để phục hồi khoá phiên. Cuối cùng, nội dung thông điệp được phục hồi bằng khoá phiên.
SignedData
Kiểu signedData có thể được sử dụng với một hoặc nhiều người ký.Sau đây là nhưng bước chuẩn bị một thực thể MIME signedData:
1. Chọn một thuật toán tóm tắt thông điệp (SHA hoặc MD5)
2. Thực hiện tính toán tóm tắt thông điệp, hoặc hàm băm của thông điệp được ký.
3. Mã hoá tóm tắt thông điệp bằng khoá bí mật của người ký.
4. Chuẩn bị một khối SignerInfo chứa chứng chỉ khoá công khai của người ký, định danh của thuật toán tóm tắt thông điệp, định danh của thuật toán dùng để mã hoá tóm tắt thông điệp, và tóm tắt thông điệp đã được mã hoá. Thực thể signedData bao gồm một dãy các khối chứa định danh thuật toán tóm tắt thông điệp, thông điệp được ký, và SignerInfo. Thực thể signedData có thể bao gồm một tập chứng chỉ khoá công khai tạo thành một chuỗi từ gốc chấp nhận (root recognized) hoặc quyền xác nhận cấp cao đến người ký. Thông tin này sau đó được mã hoá sang base64. Sau đây là một thông điệp ví dụ (bao gồm header RFC 822):
Content-Type: application/pkcs7-mime; smime-type=signed- data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
Để phục hồi thông điệp và xác nhận chữ ký, đầu tiên người nhận lược bỏ phần mã hoá base64. Sau đó khoá công khai của người ký được dùng để giải mã tóm tắt thông điệp. Người nhận tính toán tóm tắt thông điệp và so sánh nó với tóm tắt thông
Clear Signing
Clear signing có được bằng cách sử dụng kiểu nội dung multipart với kiểu phụ signed. Như đã đề cập, quá trình ký này không liên quan đến quá trình biến đổi thông điệp được ký, như vậy thông điệp được gửi “in the clear”. Người nhận có tính năng của MIME mà không cần tính năng của S/MIME để đọc được thông điệp sắp tới.
Một thông điệp multipart/signed có hai phần. Phần đầu có thể là bất kì kiểu MIME nào nhưng phải được chuẩn bị để không bị thay đổi trong quá trình truyền từ nguồn đến đích. Như vậy, nếu phần đầu không phải là 7bit, thì nó phải được mã hoá bằng base64 hoặc quoted-printable. Sau đó phần này sẽ được xử lý tương tự như signedData, nhưng trong trường hợp này một đối tượng với định dạng signedData được tạo ra và nó có một trường nội dung thông điệp để trống. Đối tượng này là một chữ ký tách rời. Sau đó nó được mã hoá chuyển đổi bằng base64 để trở thành phần thứ hai của thông điệp multipart/signed. Phần thứ 2 có một kiểu nội dung MIME của ứng dụng và một kiểu phụ pkcs7-signature. Đây là thông điệp ví dụ: