TIểu luận môn CHỨNG THỰC SỐ TÌM HIỂU CHUẨN MÃ HÓA DỮ LIỆU DES

HỆ THỐNG CHỨNG THỰC SỐ KTMT02
1
MỤC LỤC
I. CRYPTOGRAPHIC MESSAGE SYNTAX STANDARD 3
1.Tổng quan chung 3
2. Các thành phần được sử dụng 3
2.1. CertificateRevocationLists 3
2.2. ContentEncryptionAlgorithmIdentifier 3
2.3. DigestAlgorithmIdentifier 4
2.4. DigestEncryptionAlgorithmIdentifier 4
2.5. ExtendedCertificateOrCertificate 4
2.6. ExtendedCertificatesAndCertificates 4
2.7. IssuerAndSerialNumber 5
2.8. KeyEncryptionAlgorithmIdentifier 5
2.9. Version 5
3. Cú pháp chung 5
4. Dạng nội dung dữ liệu 6
5. Loại dạng dung dữ liệu được ký 6
5.1 Dạng SignedData 7
5.2 Dạng SignerInfo 8
5.3 Quá trình message-digest 9
5.4 Quá trình mã hóa 10
5.5 Khả năng tương thích với Privacy-Enhanced Mail 11
6. Enveloped _các loại nội dung dữ liệu 12
6.1. Các loại EnvelopedData 13
6.2. RecipientInfo type 14
6.3. Nội dung quá trình mã hóa 14
6.4. Key-mã hóa quá trình 16
7. Các loại nội dung Signed-and-enveloped-data 16
7.1. SignedAndEnvelopedData Các loại nội dung ký kết-và-bao-dữ liệu có kiểu ASN.1 18
7.2. Digest_quá trình mã hóa 19

7.3. Khả năng tương thích với Privacy-Enhanced Mail 19
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
2
8. Digested-data content type 20
9. Encrypted-data content type 21
10. Đối tượng nhận dạng 22
II. CHUẨN MÃ HÓA DỮ LIỆU DES (DATA ENCRYPTION STANDARD) 24
1. Giới thiệu chung về DES 24
2. Mô tả thuật toán 25
3.Hoán vị khởi đầu 26
4. Khoá chuyển đổi 27
5. Hoán vị mở rộng 28
6. Hộp thay thế S 28
7. Hộp hoán vị P 30
8. Hoán vị cuối cùng 31
9. Giải mã DES 31
10. Phần cứng và phần mềm thực hiện DES 32
11. Sự an toàn của DES 32
12. Tranh luận về DES 33
13. DES trong thực tế 35
III. DEMO 356
TÀI LIỆU THAM KHẢO 47
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
3
I. CRYPTOGRAPHIC MESSAGE SYNTAX STANDARD
Tiêu chuẩn này mô tả cú pháp chung cho dữ liệu mà có thể có mật mã, áp dụng cho nó,
chẳng hạn như chữ ký số và phong thư kỹ thuật số.
1.Tổng quan chung
Các phần sau trình bày về các dạng hữu dụng (useful), cú pháp chung, sáu dạng nội
dung và nhận dạng đối tượng.

Dạng nội dung này có hai lớp : cơ bản và nâng cao. Loại nội dung trong dạng cơ bản
chỉ chứa dữ liệu, không có mật mã nâng cao. Hiện nay, một trong những nội dung loại này là
của lớp cơ bản. Các loại nội dung trong lớp nâng cao có chứa nội dung của một số loại (có thể
mã hóa), và mã hóa nâng cao khác.
Ví dụ, dữ liệu bao phủ nội dung có thể chứa (mã hóa) nội dung dữ liệu đã ký, mà cũng
có thể chứa nội dung dữ liệu. Bốn loại nội dung không chứa dữ liệu thuộc các lớp nâng cao.
Các loại nội dung trong lớp nâng cao do đó sử dụng sự đóng gói, tạo ra các điều khoản bên
ngoài và bên trong nội dung.
2. Các thành phần được sử dụng
2.1. CertificateRevocationLists
Các dạng CertificateRevocationLists cho một tập hợp các chứng nhận thu hồi các danh
sách. Nó được dự định rằng các thiết lập có chứa đủ thông tin để xác định xem liệu các chứng
nhận,cái mà được thiết lập có liên quan đến “hot list”,nhưng có thể có nhiều danh sách chứng
nhận được thu hồi hơn mức cần thiết, hoặc có thể ít hơn mức cần thiết.
CertificateRevocationLists ::= SET OF CertificateRevocationList
2.2. ContentEncryptionAlgorithmIdentifier
Các dạng ContentEncryptionAlgorithmIdentifier xác định một thuật toán mã hóa nội
dung như thuật toán DES. Một một thuật toán mã hóa nội dung hỗ trợ mã hóa và giải mã các
hoạt động(operation). Hoạt động mã hóa sắp đặt một chuỗi octet (tin nhắn) đến một chuỗi
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
4
octet khác (bản mã) dưới sự kiểm soát của một khóa mã hóa nội dung. Hoạt động giải mã là
nghịch đảo của hoạt động mã hóa.
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
2.3. DigestAlgorithmIdentifier
Các dạng DigestAlgorithmIdentifier xác định một thuật toán message-digest. Ví dụ
như thuật toán MD2 và MD5.
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
2.4. DigestEncryptionAlgorithmIdentifier
Các dạng DigestEncryptionAlgorithmIdentifier xác định một thuật toán digest-

encryption dưới dạng một message digest có thể được mã hóa. Ví dụ thuật toán mã hóa RSA
PKCS #1. Một thuật toán digest-encryption hỗ trợ mã hóa và giải mã các hoạt
động(operation). Hoạt động mã hóa sắp đặt một chuỗi octet (tin nhắn) đến một chuỗi octet
khác (bản mã) dưới sự kiểm soát của một khóa digest-encryption. Hoạt động giải mã là
nghịch đảo của hoạt động mã hóa.
DigestEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
2.5. ExtendedCertificateOrCertificate
Các dạng ExtendedCertificateOrCertificate có hai loại hoặc là PKCS #6 gia hạn giấy
chứng nhận hay chứng nhận X.509. Dạng này theo cú pháp giới thiệu trong phần 6 của
PKCS#6:
ExtendedCertificateOrCertificate ::= CHOICE { certificate Certificate, X.509
extendedCertificate [0] IMPLICIT ExtendedCertificate }
2.6. ExtendedCertificatesAndCertificates
Các dạng ExtendedCertificatesAndCertificates cho một tập hợp mở rộng các chứng
nhận và giấy chứng nhận X.509. Nó được đự định rằng các thiết lập đủ để chứa các chuỗi từ
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
5
“root” hay “top-level certification authority” được công nhận cho tất cả những người ký giấy
chứng nhận người mà đưa ra thiết lập có liên quan, nhưng có thể có nhiều giấy chứng nhận
hơn mức cần thiết, hay ít hơn mức cần thiết.
ExtendedCertificatesAndCertificates ::= SET OF ExtendedCertificateOrCertificate
2.7. IssuerAndSerialNumber
Các dạng IssuerAndSerialNumber xác định một giấy chứng nhận bởi tên phân biệt của
người phát hành giấy chứng nhận và một tổ chức phát hành cụ thể số serial của giấy chứng
nhận.
IssuerAndSerialNumber ::= SEQUENCE { issuer Name,serialNumber
CertificateSerialNumber }
2.8. KeyEncryptionAlgorithmIdentifier
Các dạng KeyEncryptionAlgorithmIdentifier xác định một thuật toán khóa mã
hóa(key-encryption) theo đó một khóa mã hóa nội dung có thể được mã hóa. Một ví dụ là

thuật toán mã hóa RSA PKCS#1. Một thuật toán khóa mã hóa(key-encryption) hỗ trợ mã hóa
và giải mã các hoạt động của nó. Hoạt động mã hóa sắp đặt một chuỗi octet (tin nhắn) đến
một chuỗi octet khác (khóa được mã hóa) dưới sự kiểm soát của một khóa key-encryption.
Hoạt động giải mã là nghịch đảo của hoạt động mã hóa.
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
2.9. Version
Các dạng version cho biết một số phiên bản cú pháp.
Version ::= INTEGER
3. Cú pháp chung
ContentInfo ::= SEQUENCE {contentType ContentType,content [0] EXPLICIT ANY
DEFINED BY contentType OPTIONAL }
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
6
ContentType ::= OBJECT IDENTIFIER
ContentType cho biết các dạng nội dung.Bao gồm sáu dạng nội dung sau : data,
signedData, envelopedData, signedAndEnvelopedData, digestedData, và encryptedData.
Content là nội dung. Kiểu dữ liệu này là tùy chọn và nếu không có mặt của nó, giá trị
dự định của nó phải được thay bởi kiểu dữ liệu cùng loại khác. Dạng của nó được xác định
cùng với đối tượng nhận diện cho ContentType.
4. Dạng nội dung dữ liệu
Các dạng nội dung dữ liệu chỉ là một chuỗi octet. Nó có kiểu dữ liệu ASN.1 :
Data ::= OCTET STRING
Dạng nội dung dữ liệu được dự định để chỉ đến chuỗi octet tùy ý, chẳng hạn như tập
tin văn bản ASCII. Những chuỗi như vậy không cần có bất kỳ cấu trúc nội bộ nào( mặc dù
chúng có thể, chúng thậm chí có thể được mã hóa bởi thuật toán DER.).
5. Loại dạng dung dữ liệu được ký
Các dạng nội dung dữ liệu được ký bao gồm bất kỳ loại nội dung nào và nội dung
message digest được mã hóa cho nhiều người ký hoặc không ai cả. Message digest cho một
người ký là một chữ kỹ số trên nội dung cho người ký đó. Bất kỳ dạng nội dung nào có thể
được ký bởi bất kỳ số người ký song song. Hơn nữa, cú pháp có một trường hợp suy biến mà

không có người ký tên vào nội dung. Các trường hợp suy biến cung cấp một phương tiện phổ
biến các danh sách chứng nhận và thu hồi chứng nhận.
Dự kiến ứng dụng điển hình của loại nội dung dữ liệu được ký sẽ được đại diện bởi
một chữ ký số của người ký trên nội dung của dạng nội dung dữ liệu. Một ứng dụng tiêu biểu
sẽ được phổ biến danh sách các chứng nhận và thu hồi chứng nhận.
Quá trình mà ký dữ liệu được xây dựng liên quan đến các bước sau:
Đối với mỗi người ký, message digest được tính toán dựa trên nội dung thuật toán
message digest với một người ký cụ thể.( Nếu có từ hai người ký sử dụng cùng một thuật toán
message digest, sau đó message digest cần được tính toán cho chỉ một người trong số họ được
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
7
sử dụng). Nếu người ký đang chứng thực bất kì thông tin nào khác ngoài nội dung, nội dung
của message digest và bất kì thông tin nào khác được digest với thuật toán message digest của
người ký và kết quả sẽ trở thành “message digest”.
Đối với mỗi người ký, message digest và liên kết thông tin được mã hóa với khóa
private của người ký.
Đối với mỗi người ký, message digest được mã hóa và thông tin người ký cụ thể khác
được thu thập thành một giá trị SignerInfo. Danh sách chứng nhận và thu hồi chứng nhận cho
mỗi người ký, và những người không tương ứng với bất kỳ người ký nào được thu thập trong
bước này.
Thuật toán message digest và những giá trị SignerInfo cho tất cả người ký được thu
thập liên quan đến nội dung giá trị SignData.
Một người nhận xác minh chữ ký bằng cách giải mã message digest được mã hóa cho
mỗi người ký với khóa công khai của người ký, sau đó so sánh các message digest được thu
hồi với tính độc lập message digest. Khóa công khai của người ký là phần hoặc được chứa
trong một chứng nhận bao gồm thông tin người ký, hoặc được tham chiếu bởi tên phân biệt
công ty phát hành và một số tổ chức phát hành cụ thể mà nhận ra duy nhất giấy chứng nhận
cho khóa công khai.
5.1 Dạng SignedData
Các dạng nội dung chữ ký dữ liệu(signed-data) :

SignedData ::= SEQUENCE {version Version,digestAlgorithms
DigestAlgorithmIdentifiers,contentInfo ContentInfo,certificates[0] IMPLICIT
ExtendedCertificatesAndCertificates OPTIONAL,crls[1] IMPLICIT
CertificateRevocationLists OPTIONAL,signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::=SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
DigestAlgorithms là một tập hợp message-digest,nhận dạng thuật toán digest. Có thể
có bất kỳ số lượng thành phần trong tập hợp, bao gồm cả số không. Mỗi yếu tố xác định thuật
toán message-digest và theo đó nội dung được digest cho một số người ký.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
8
ContentInfo là nội dung được ký. Nó có thể có bất kỳ dạng nội dung được xác định.
Crls là một tập hợp danh sách thu hồi chứng nhận. Nó xem xét có đủ thông tin để xác
định có hay không các chứng nhận trong danh sách chứng nhận “hot listed” , nhưng như vậy
thường không cần thiết. Có thể có nhiều danh sách chứng nhận thu hồi hơn mức cần thiết và
có thể có ít hơn danh sách chứng nhận thu hồi hơn mức cần thiết.
SignerInfos là tập hợp thông tin của mỗi người ký. Có thể có bất kỳ yếu tố nào trong
tập hợp, bao gồm số không.
5.2 Dạng SignerInfo
Thông tin mỗi người ký được đại diện trong dạng SignerInfo :
SignerInfo ::= SEQUENCE {version Version,issuerAndSerialNumber
IssuerAndSerialNumber,digestAlgorithm DigestAlgorithmIdentifier,authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier, encryptedDigest EncryptedDigest,
unauthenticatedAttributes[1] IMPLICIT Attributes OPTIONAL }
EncryptedDigest ::= OCTET STRING
Version là số phiên bản cú pháp. Nó sẽ là một phiên bản của tài liệu này.
IssuerAndSerialNumber quy định cụ thể giấy chứng nhận của người ký( và do đó phân
biệt tên người ký và khóa công khai) theo tên phân biệt công ty phát hành và số serial cụ thể
của tổ chức phát hành.

DegestAlgorithm xác định các thuật toán message-digest( và bất kỳ các thông số có
liên quan) theo đó nội dung và các thuộc tính xác thực (nếu có) được digest. Nó sẽ là một
trong số những phần trong digestAlgorithms của giá trị SignerInfo.
AuthenticateAttributes là một tập các thuộc tính được ký bởi người ký.
DigestEncyptionAlgorithm xác định thuật toán mã hóa message-digest ( và bất kì các
thông số có liên quan) theo đó message digest và những thông tin liên quan được mã hóa với
khóa private của người ký.
EncryptedDigest là kết quả của việc mã hóa message digest và thông tin liên quan với
khóa private của người ký.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
9
UnauthenticatedAttributes là một tập các thuộc tính mà không phải ký(tức là,chứng
thực) bởi người ký. Lĩnh vực này là tùy chọn.
5.3 Quá trình message-digest
Quá trình message-digest tính toán một message digest hoặc là nội dung được ký hoặc
nội dung liên quan đến thuộc tính xác thực của người ký. Trong cả hai trường hợp, đầu vào
cho quá trình message-digest là “giá trị” của nội dung được ký. Cụ thể, đầu vào ban đầu là nội
dung chuỗi octet của mã DER của lĩnh vực nội dung của giá trị ContentInfo mà quá trình ký
được áp dụng.Chỉ nội dung octet của mã DER của trường này được digest, không phải là
nhận dạng octet hay chiều dài octet.
Kết quả của quá trình message-digest phụ thuộc vào trường authenticatedAttributes là
hiện diện. Khi trường này vắng mặt, kết quả chỉ là nội dung message-digest. Khi trường này
hiện diện, tuy nhiên, kết quả là message-digest của mã DER hoàn thiện của giá trị Attribute
chứa trong trường authenticatedAttributes.
Khi nội dung được ký có chứa dạng dữ liệu và trường authenticatedAttributes vắng
mặt, sau đó chỉ cần giá trị của dữ liệu(nội dung các file) được digest. Điều này có lợi thế rằng
chiều dài cảu nội dung được ký không cần phải được biết trước quá trình mã hóa. Phương
thức này tương thích với Privacy-Enhanced Mail.
Mặc dù nhận diện octet và chiều dài octet không được digest, chúng vẫn được bảo vệ
bởi thành phần cùng chức năng khác. Chiều dài octet được bảo vệ bởi bản chất của thuật toán

message-digest từ khi nó là cách giả định tính toán không khả thi để tìm bất kỳ hai khác biệt
tin nhắn của bất kỳ chiều dài nào có cùng message-digest.Hơn nữa, giả sử rằng dạng nội dung
duy nhất xác định nhận dạng octet, các định danh octet được bảo vệ hoàn toàn trong một hai
cách sau:hoặc bao gồm dạng nội dung trong thuộc tính xác thực, hoặc bằng cách sử dụng
PEM-tương thích thay thế trong đó có nghĩa là các dạng nội dung dữ liệu.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
10
5.4 Quá trình mã hóa
Các đầu vào cho quá trình mã hóa - giá trị cung cấp cho các thuật toán mã
hóa của người ký - bao gồm các kết quả của quá trình mã hóa thông điệp (không chính
thức, các "thông báo ") và các mã hóa thuật toán nhận dạng (hoặc đối tượng định danh) .Kết
quả của quá trình mã hóa là mã hóa với khóa riêngcủa người ký của các mã hóa BER của
một giá trị của loại DigestInfo:
DigestInfo ::= SEQUENCE { digestAlgorithm DigestAlgorithmIdentifier, digest
Digest }
Digest ::= OCTET STRING
Các loại DigestInfo có ý nghĩa sau đây:
DigestAlgorithm xác định các thông điệp mã hóa thuật toán(và bất kỳ các thông số liên
quan), theo đó các nội dung và cácthuộc tính xác thực được mã hóa. Nó sẽ giống
như các trường digestAlgorithm của giá trị SignerInfo cấp trên.
Mã hóa là kết quả của quá trình mã hóa thông điệp.
Chú ý.
1. Sự khác biệt duy nhất giữa quy trình chữ ký được định nghĩa ở đây và chữ ký
của các thuật toán xác định trong PKCS # 1 là có chữ ký có đại diện là chuỗi bit, cho phù
hợp với X.509 các chữ ký vĩ mô. Ở đây, mã hóa tin mã hóa tạo ra được chuỗi octet.
2. Các đầu vào cho quá trình mã hóa thông thường sẽ có 30 octet hoặc ít
hơn . Nếu digestEncryptionAlgorithm là PKCS # 1 của rsaEncryption, sau đó điều này có
nghĩa rằng các đầu vào có thểđược mã hóa trong một khối miễn là độ dài của mô đun RSA ít
nhất là 328 bit, điều này hợp lý và phù hợp với các khuyến nghị về độ an toàn .
3. Một tin nhắn, mã hóa thuật toán nhận dạng được bao gồm trong giá

trị DigestInfo để hạn chế thiệt hại do việc thỏa hiệp của một thông điệp mã hóa thuật toán. Ví
dụ, giả sử một đối thủ có thể tìm thấy thư với một tin nhắn MD2 cho mã hóa. Kẻ thù sau đó
có thể giả mạo một chữ ký bằng cách tìm một tin nhắn với thông điệp cùng MD2 mã
hóa là một trong những người ký tên trước đây đã ký kết, và trình bày chữ ký trước đây là chữ
ký trên các tin nhắn mới. Cuộc tấn công này sẽ thành công nếu người ký trước đây sử
dụng MD2, vì giá trị DigestInfo chứa các thông điệp mã hóa thuật toán. Nếu người ký không
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
11
bao giờ sử dụng thuật toán MD2 và luôn luôn sử dụng MD5, khi đó các sự thỏa hiệp
của MD2 sẽ không ảnh hưởng đến người ký. Nếu giá trị DigestInfochỉ chứa thông điệp mã
hóa, tuy nhiên, sự thỏa hiệp của MD2 sẽ ảnh hưởng đến người ký tên sử dụng bất kỳ thông
báo-mã hóa thuật toán nào.
4. Thực tế cho thấy rằng các giá trị DigestInfo không rõ ràng vì nó không cho biết
liệu các trường có chỉ chứa nội dung mã hóa của thông điệp hay thông tin mã hóa hoàn toàn
của trường authenticatedAttributes. Nói cách khác, nó có thể cho một đối thủ để chuyển
đổi một chữ ký trên các thuộc tính xác thực chỉ về nội dung bằng cách thay đổi các nội
dung được mã hóa DER của trường authenticatedAttributes, và sau đó loại
bỏ các trường authenticatedAttributes. (Việc chuyển đổi ngược lại là có thể, nhưng đòi
hỏi rằng nội dung được mã hóa DER của một giá trị thuộc tính xác thực, đó là khó xảy ra.) sự
mơ hồ này không phải là một vấn đề mới, cũng không phải là quan trọng nhất,như là bối
cảnh chung để ngăn chặn sự lạm dụng.
Thật vậy, nó cũng có thể cho một đối thủ để chuyển đổi mộtchữ ký trên chứng
chỉ hoặc danh sách thu hồi Giấy chứng nhận chomột trong đó dường như chỉ về nội dung dữ
liệu đã ký.
5.5 Khả năng tương thích với Privacy-Enhanced Mail
Khả năng tương thích với các loại quá trình MIC-ONLY và MIC-CLEAR
trong PEM xảy ra khi các kiểu nội dung của các giá trị ContentInfo được ký kết là dữ liệu,
không có thuộc tính xác thực, tin nhắn, phân loại thuật toán là md2 hoặc md5, và thuật
toán mã hóa phân loại làPKCS # 1 của rsaEncryption. Trong tất cả những điều kiện, thông
điệp được mã hóa phân loại được sản xuất ở đây phù hợp với một sản xuất trong PEM bởi vì:

1. Các giá trị đầu vào tin nhắn, phân loại thuật toán trong PEM là giống như trong tài
liệu này khi không có các thuộc tính xác thực. MD2 và MD5 trong PEM
giống như md2 và md5.
2. Giá trị mã hóa với khóa riêng của người ký trong PEM (theoquy định tại RFC 1423)
là tương tự như trong tài liệu này khi không có các thuộc tính xác thực. RSA tin-key mã
hóa trong PEM là giốngnhư rsaEncryption của PKCS # 1.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
12
Các phần khác trong nội dung các loại ký kết dữ liệu (giấy chứng nhận, CRLs, nhận
dạng thuật toán, vv) có thể dễ dàng dịch sang từ các thành phần tương ứng của PEM.
6. Enveloped _các loại nội dung dữ liệu
Các kiểu nội dung dữ liệu bao gồm các nội dung được mã hóa của bất kỳ loại
hình và nội dung các khóa mã hóa mật mã cho một hoặc nhiều người nhận. Sự kết
hợp của nội dung được mã hóa và khóa mã hóa nội dung mã hóa cho người nhận là một "
digital envelope " cho người nhận. Bất kỳ loại nội dung nào cũng có thể được bao bọc cho bất
kỳ số lượng người nhận song song.
Dự kiến ứng dụng điển hình của các loại nội dung bao-dữ liệu sẽ được đại diện
cho một hoặc nhiều người nhận về nội dung của dữ liệu, mã hóa, dữ liệu, hoặc các loại nội
dung ký kết dữ liệu.
Quá trình mà dữ liệu được xây dựng bao gồm các bước sau:
1. Một khóa mã hóa nội dung cho một thuật toán mã hóa nội dung cụ thể được tạo
ra ngẫu nhiên.
2. Đối với mỗi người nhận, các khóa mã hóa nội dung đượcmã hóa với khóa công
cộng của người nhận.
3. Đối với mỗi người nhận, mã hóa nôi dung của các khóa và các thông tin người
nhận cụ thể khác thu thập được thành một giá trị RecipientInfo
4. Nội dung được mã hóa với khóa mã hóa nội dung. (Nội dung mã hóa có thể yêu
cầu rằng nội dung được đệm thêm vào một bội số của một khối với kích thước nào
đó; xem Phần 10,3 thảo luận).
5. RecipientInfo _Các giá trị cho tất cả những người nhận được thu thập cùng

với các nội dung được mã hóa thành một giá trị EnvelopedData.
Một người nhận mở phong bì bằng cách giải mã một trong các phím mã hóa nội
dung mã hóa với khóa riêng của người nhận và giải mã nội dung mã hóa với khóa mã hóa nội
dung phục hồi. Chìa khóa private của người nhận được tham chiếu bởi một cái tên công ty
phát hành tốt và một số tổ chức phát hành cụ thể nối tiếp mà nhận ra duy nhất giấy chứng
nhận cho các khoá công khai tương ứng.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
13
Phần này được chia thành bốn phần. Phần đầu tiên mô tả cácEnvelopedData loại cấp
cao, phần thứ hai mô tả RecipientInfo loại thông tin mỗi người nhận, và thứ ba và phần thứ
tư mô tả nội dung, mã hóa và khóa mã hóa các quy trình.
Loại nội dung không tương thích với Privacy-Enhanced Mail (mặc dù một số quá trình
được định nghĩa là tương thích với PEM đối tác của họ), vì Privacy-Enhanced Mail luôn
luôn liên quan đến chữ ký số.
6.1. Các loại EnvelopedData
EnvelopedData ::= SEQUENCE {version Version, recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo }
RecipientInfos ::= SET OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE { contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, encryptedContent
[0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
Các lĩnh vực loại EnvelopedData có ý nghĩa sau đây:
EnvelopedData là phiên bản số cú pháp. Nó sẽ là 0 cho phiên bản của tài liệu.
RecipientInfos là một bộ sưu tập của mỗi người nhận thông tin. Phải có ít
nhất một phần tử trong bộ sưu tập.
EncryptedContentInfo là nội dung thông tin được mã hóa.
Các lĩnh vực loại EncryptedContentInfo có ý nghĩa sau đây:
ContentType cho biết các loại nội dung.
ContentEncryptionAlgorithm xác định các thuật toán mã hóanội dung (và bất kỳ thông

số liên quan) theo đó nội dung được mã hóa.
Quá trình mã hóa nội dung được mô tả trong mục 10.3.Thuật toán này là như
nhau cho tất cả người nhận.
EncryptedContent là kết quả của mã hóa nội dung. Lĩnh vực này là tùy
chọn, và nếu trường không có, giá trị dự định của nó phải được cung cấp bởi các phương
tiện khác.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
14
Lưu ý.
Thực tế là lĩnh vực recipientInfos đến trước khi các trường encryptedContentInfo làm
cho nó có thể xử lý một giá trị EnvelopedData trong một truyền đơn.
6.2. RecipientInfo type
Mỗi thông tin người nhận được đại diện trong loại RecipientInfo :
RecipientInfo ::= SEQUENCE {version Version, issuerAndSerialNumber
IssuerAndSerialNumber, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
EncryptedKey ::= OCTET STRING
Các lĩnh vực loại RecipientInfo có ý nghĩa sau đây:
Version là phiên bản số cú pháp. Nó sẽ là 0 cho phiên bảncủa tài liệu.
IssuerAndSerialNumber quy định cụ thể của người nhận giấy chứng nhận (và do
đó tên phân biệt của người nhận và khoá công khai) theo tên công ty phát hành tốt và tổ chức
phát hành cụ thể số.
KeyEncryptionAlgorithm xác định các thuật toán mã hóa khóa(và bất kỳ liên quan
đến các thông số), theo đó các phím mã hóa nội dung được mã hóa với khóa công cộng của
người nhận. Quá trìnhmã hóa chính được mô tả trong mục 10.4.
EncryptedKey là kết quả của mã hóa nội dung quan trọnghóa với khóa công
cộng của người nhận
6.3. Nội dung quá trình mã hóa
Các đầu vào cho quá trình mã hóa nội dung là "giá trị " của nội dung đang được bao
bọc. Cụ thể, đầu vào là các octet nội dung của một mã hóa BER xác định độ dài của lĩnh

vực nội dung của cácgiá trị ContentInfo mà quá trình bao phủ được áp dụng. Chỉ có octetnội
dung của các mã hóa BER được mã hóa, không phải là nhận dạng octet hoặc octet độ
dài, những octet khác không có đại diện tại tất cả.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
15
Khi nội dung được bao bọc có kiểu dữ liệu nội dung, sau đó chỉ cần giá trị của dữ
liệu (ví dụ, các nội dung của file) được mã hóa.Điều này có ưu điểm là độ dài của nội
dung được mã hóa không cần phải được biết trước quá trình mã hóa. Phương pháp nàytương
thích với việc đảm bảo sự tăng cường sự riêng tư của Mail.
Các định danh octet và độ dài các octet không được mã hóa. Độ dài các octet có
thể được bảo vệ hoàn toàn bởi quá trình mã hóa, phụ thuộc vào các thuật toán mã
hóa. Các định danh không octet bảo vệ tại tất cả, mặc dù chúng có thể được thu
hồi từ các kiểu nội dung, giả định rằng các loại nội dung duy nhất xác định danh
tánh octet. Rõ ràng bảo vệ nhận ạng và octet độ dài đòi hỏi các loại ký-và-bao-nội dung dữ
liệu được sử dụng, hoặc là tiêu hóa dữ liệu và các loại nội dung bao dữ liệu được áp
dụng trong kế.
Ghi chú.
1. Lý do mà một mã hóa dài hạn BER được yêu cầu là các bit chỉ có chiều dài là không
xác định thời hạn hoặc không được ghi lại bất cứ nơi nào trong các loại nội dung bao-dữ
liệu. Xác định độ dài mã hóa thích hợp hơn cho các loại đơn giản như các chuỗi octet, do
đó, mã hóa xác định độ dài được chọn.
2. Một số thuật toán mã hóa nội dung giả định chiều dài đầu vào là một bội số
của octet k, với k> 1, và để cho các ứng dụng xác định một phương pháp để xử lý đầu
vào có độ dài không phải là một bội số của octet k. Đối với các thuật toán như vậy, phương
pháp sẽ được kéo cho đầu vào ở cuối đuôi với k - (k mod m) octet tất cả k có giá trị -
(l mod k), trong đó l là chiều dài của đầu vào. Nói cách khác, đầu
vào được đệm ở cuối đuôi với một trong những chuỗi kí tự sau:
01 if l mod k = k-1
02 02 if l mod k = k-2
.

.
.
k k k k if l mod k = 0
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
16
Đệm này có thể được loại bỏ rõ ràng từ đầu vào tất cả được đệm và không
có chuỗi đệm là một hậu tố khác. Phương pháp này đệm được xác định nếu và chỉ
nếu k <256; phương pháp k lớn hơn là một vấn đề mở cho nghiên cứu thêm.
6.4. Key-mã hóa quá trình
Các đầu vào cho quá trình mã hóa khóa - giá trị cung cấp cho cácthuật toán mã
hóa khóa của người nhận - chỉ là "giá trị" của khóa mã hóa nội dung.
7. Các loại nội dung Signed-and-enveloped-data
Các loại nội dung ký kết-và-bao-dữ liệu bao gồm các nội dung được mã hóa của bất
kỳ loại, nội dung các khóa mã hóa mật mã cho một hoặc nhiều người nhận, và giải mã cho
một hoặc nhiều người ký tên. Các "đôi mã hóa" bao gồm một mã
hóa với khóa riêng của người ký tên tiếp theo là một mã hóa với khóa mã hóa nội dung.
Sự kết hợp của nội dung được mã hóa và khóa mã hóa nội dung mã hóa cho người
nhận là một "kỹ thuật số phong bì" cho người nhận. Các tin nhắn được mã hóa đơn
phương thu hồi mã hóa cho người ký là một "chữ ký số" vào nội dung thu hồi cho người
ký đó.Bất kỳ loại nội dung có thể được bao bọc cho bất kỳ số lượng người nhận và chữ ký
của bất kỳ số lượng người ký tên song song.
Dự kiến ứng dụng điển hình của kiểu nội dung đã ký kết-và-bao-dữ liệu sẽ được đại
diện cho một trong những người ký chữ ký số và một hoặc nhiều người nhận "phong bì kỹ
thuật số trên nội dung của các kiểu nội dung dữ liệu.
Quá trình Signed-and-enveloped-data được xây dựng bao gồm các bước sau:
1. Một khóa mã hóa nội dung cho một thuật toán mã hóa nội dung cụ thể được tạo ra
ngẫu nhiên.
2. Đối với mỗi người nhận, các khóa mã hóa nội dung được mã hóa với khóa công
cộng của người nhận.
3. Đối với mỗi người nhận, nội dung, mã hóa mật mã khóa và các thông tin người nhận

cụ thể khác được thu thập vào một RecipientInfovalue
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
17
4. Đối với mỗi người ký, một tin nhắn tiêu hóa được tính vào nội dung với một người
ký thông điệp cụ thể tiêu hóa thuật toán. (Nếu có từ hai người ký tên sử dụng cùng một thông
điệp tiêu hóa thuật toán, sau đó thông báo mã hóa cần được tính toán để chỉ một trong số đó.
5. Đối với mỗi người ký, thông báo liên quan đến mã hóa và thông tin được mã hóa
với khóa riêng của người ký, và kết quả là mã hóa với khóa mã hóa nội dung. (Các mã hoá
thứ hai có thể yêu cầu rằng các kết quả của việc mã hóa đầu tiên được đệm thêm vào một bội
số của một số kích thước khối.
6. Đối với mỗi người ký, thông báo gấp đôi mã hóa tiêu hóa và các thông tin cụ thể
của người ký được thu thập vào một giá trị SignerInfo
7. Nội dung được mã hóa với khóa mã hóa nội dung.
8. Thông điệp-mã hóa thuật toán cho tất cả những người ký tên, giá trị SignerInfo cho
tất cả những người ký tên và các giá trị RecipientInfo cho tất cả những người nhận được thu
thập cùng với các nội dung được mã hóa thành một giá trị SignedAndEnvelopedData
Một người nhận mở phong bì và xác nhận chữ ký theo hai bước. Thứ nhất, một trong
các phím mã hóa nội dung mã hóa được giải mã với khóa riêng của người nhận, và các nội
dung mã hóa được giải mã với khóa mã hóa nội dung phục hồi. Thứ hai, thông điệp được mã
hóa gấp đôi tiêu hóa cho mỗi người ký tên là giải mã với khóa mã hóa nội dung phục hồi, kết
quả là giải mã với khóa công khai của người ký, và thông báo thu hồi tiêu hóa được so sánh
với một thông báo độc lập tính toán tiêu hóa.
Phím nhận tin và người ký khóa công khai được chứa hoặc tham chiếu.
Phần này được chia thành ba phần.
Phần đầu tiên mô tả các SignedAndEnvelopedData loại cấp cao nhất và phần thứ hai
mô tả quá trình mã hóa, giải mã.
Phần thứ ba tóm tắt phù hợp với Privacy-Enhanced Mail
Lưu ý.
Các loại nội dung ký kết-và-bao-dữ liệu cung cấp các cải tiến mã hóa tương tự
nhưnhững hệ quả từ sự kết hợp của các ký tự dữ liệu và các loại nội dung bao-dữ liệu.

Tuy nhiên, kể từ khi loại ký-và-bao-dữ liệu nội dung không có chứng thực hoặc chưa
được xác định các thuộc tính, cũng không cung cấp bao bọc của người ký thông
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
18
tin khác với chữ ký, sự kết hợp của các ký tự dữ liệu và các loại nội dung bao dữ liệu thường
được ưa chuộng hơn các loại nội dung Signed AndEnvelopedData, trừ khi khả năng tương
thích với các loại quá trình mã hóa trong Privacy-Enhanced Mailtrong dự định.
7.1. SignedAndEnvelopedData
Các loại nội dung ký kết-và-bao-dữ liệu có kiểu ASN.1
SignedAndEnvelopedData:
SignedAndEnvelopedData ::= SEQUENCE { version Version, recipientInfos
RecipientInfos, digestAlgorithms DigestAlgorithmIdentifiers, encryptedContentInfo
EncryptedContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL, crls[1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos
SignerInfos }
Các lĩnh vực loại SignedAndEnvelopedData có ý nghĩa sau đây:
Phiên bản là phiên bản số cú pháp. Nó sẽ là 1 cho phiên bản của tài liệu.
RecipientInfos là một bộ sưu tập của mỗi người nhận thông tin, như trong Mục 10.
Phải có ít nhất một phần tử trong bộ sưu tập.
DigestAlgorithms là một bộ sưu tập của tin nhắn, tiêu hóa thuật toán nhận dạng, như
trong Mục 9. Quá trình tiêu hóa thông điệp tương tự như trong Mục 9 trong trường hợp khi
không có các thuộc tính xác thực.
EncryptedContentInfo là nội dung được mã hóa, như trong Mục 10. Nó có thể có bất
kỳ các loại nội dung quy định.
Giấy chứng nhận là một bộ PKCS # 6 mở rộng các chứng chỉ và giấy chứng nhận
X.509, như trong Mục 9.
CRLs là một tập hợp các danh sách thu hồi chứng chỉ, như trong Mục 9.
SignerInfos là một bộ sưu tập của mỗi người ký thông tin. Phải có ít nhất một phần tử
trong bộ sưu tập. SignerInfo giá trị có cùng một nghĩa như trong Mục 9 ngoại trừ lĩnh vực
encryptedDigest.

Ghi chú.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
19
1. Thực tế là các recipientInfos và digestAlgorithms trường đến trước khi các trường
contentInfo và lĩnh vực signerInfos ra sau khi nó làm cho nó có thể xử lý một giá trị
SignedAndEnvelopedData trong một truyền đơn.
2. Sự khác biệt giữa SignedAndEnvelopedData phiên bản và phiên bản 0
SignedAndEnvelopedData (được xác định trong PKCS # 7, phiên bản 1.4) là lĩnh vực CRLs
được cho phép trong phiên bản 1, nhưng không phải trong phiên bản 0. Ngoại trừ sự khác biệt
trong số phiên bản, phiên bản 0 SignedAndEnvelopedData giá trị được chấp nhận như là
1values . Do đó có thể thực hiện quá trình SignedAndEnvelopedData giá trị của một trong
hai phiên bản như thể họ đang phiên bản 1 giá trị. Đó là đề nghị triển khai PKCS chỉ tạo ra
phiên bản 1 SignedAndEnvelopedData giá trị, nhưng được chuẩn bị để xử lý
SignedAndEnvelopedData giá trị của phiên bản 2.
7.2. Digest_quá trình mã hóa
Các đầu vào cho quá trình giải mã, mã hóa là giống như trong Mục 9, nhưng quá trình
đó là khác nhau. Cụ thể, quá trình này liên quan đến hai bước. Thứ nhất, đầu vào cho quá
trình này là cung cấp cho các thuật toán mã hóa tiêu hóa của người ký, như trong Mục 9. Thứ
hai, kết quả của bước đầu tiên là mã hóa với khóa mã hóa nội dung.Không có mã hóa DER
giữa hai bước, đầu ra "giá trị" bởi bước đầu tiên là đầu vào trực tiếp đến bước thứ hai.
Quá trình này tương thích với các loại quá trình mã hóa trong Privacy-Enhanced Mail.
Lưu ý. Mục đích của bước thứ hai là để ngăn chặn kẻ thù hồi phục thông tin mã hóa của nội
dung. Nếu không, một kẻ thù sẽ có thể xác định một danh sách các nội dung ứng cử viên (ví
dụ, "Có" hoặc "Không") là nội dung thực tế bằng cách so sánh sự tiêu hóa thông điệp của
mình vào tin nhắn thực sự được mã hóa.
7.3. Khả năng tương thích với Privacy-Enhanced Mail
Khả năng tương thích với các loại quá trình mã hóa của PEM xảy ra khi các kiểu nội
dung của các giá trị ContentInfo được ký kết và bao trùm là dữ liệu, tin nhắn, tiêu hóa thuật
toán là md2 hoặc md5, thuật toán mã hóa nội dung là DES trong chế độ CBC, thuật toán mã
HỆ THỐNG CHỨNG THỰC SỐ KTMT02

20
hóa tiêu hóa là PKCS # 1 của rsaEncryption, và các thuật toán mã hóa khóa PKCS # 1 của
rsaEncryption. Trong tất cả những điều kiện, thông điệp được mã hóa gấp đôi tiêu hóa và các
nội dung được mã hóa mã hóa khóa phù hợp với những người sản xuất trong PEM vì lý do
tương tự như nêu trong mục 9.5, cũng như những điều sau đây:
1. Các giá trị đầu vào đến các thuật toán mã hóa nội dung trong PEM là giống như
trong tài liệu này. DES trong chế độ CBC giống như desCBC.
2. Các giá trị đầu vào đến các thuật toán mã hóa khóa trong PEM là giống như trong
tài liệu này (xem Phần 10,4). RSA khoá công khai mã hóa trong PEM là giống như
rsaEncryption PKCS # 1.
3. Quá trình mã hóa hai lần áp dụng cho các thông điệp tiêu hóa trong tài liệu này và
PEM là như nhau.
Các bộ phận khác của các loại nội dung ký kết-và-bao-dữ liệu (giấy chứng nhận,
CRLs, nhận dạng thuật toán, vv) có thể dễ dàng dịch sang và từ các thành phần tương ứng của
PEM. (CRLs được thực hiện trong một tin nhắn PEM riêng.)
8. Digested-data content type
Các loại nội dung giải mã dữ liệu bao gồm các nội dung của bất kỳ loại nào và một tin
nhắn tiêu hóa của nội dung.
Dự kiến ứng dụng điển hình của kiểu nội dung tiêu hóa, dữ liệu sẽ được cho thêmtính
toàn vẹn nội dung của kiểu dữ liệu nội dung, và rằng kết quả sẽ trở thành đầu vàonội dung
cho các loại nội dung bao-dữ liệu.
Quá trình mà giải mã dữ liệu được xây dựng bao gồm các bước sau:
1. Một tin nhắn mã hóa được tính vào nội dung với một tin nhắn, giả mã thuật toán.
2. Thông điệp-giải mã thuật toán và thông tin giải mã được thu thập cùng với các nội
dung vào một giá trị DigestedData.
Một người nhận xác minh thông tin giải mã bằng cách so sánh các thông điệp giải mã
với một thông báo độc lập tính toán giải mã.
Các kiểu nội dung dữ liệu giải mã có trách nhiệm ASN.1 DigestedData loại:
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
21

DigestedData ::= SEQUENCE { version Version, digestAlgorithm
DigestAlgorithmIdentifier,contentInfo ContentInfo,digest Digest }
Digest ::= OCTET STRING
Các lĩnh vực loại DigestedData có ý nghĩa sau đây:
Phiên bản là phiên bản số cú pháp. Nó sẽ là 0 cho phiên bản của tài liệu.
DigestAlgorithm xác định các thông điệp giải mã thuật toán (và bất kỳ thông tin liên
quan đến các thông số), theo đó nội dung được giải mã. (Quá trình giải mã thông điệp tương
tự như trong Mục 9 trong trường hợp khi không có các thuộc tính xác thực.)
ContentInfo là nội dung đó được giải mã. Nó có thể có bất kỳ các loại nội dung quy
định.
Digest là kết quả của quá trình giải mã thông điệp.
Lưu ý.
Thực tế là digestAlgorithm đến trước các trường contentInfo và các việc giải mã
khi nó làm cho nó có thể xử lý trong một giá trị DigestedData trong một truyền đơn.
9. Encrypted-data content type
Các loại nội dung mã hóa dữ liệu bao gồm các nội dung được mã hóa của định dạng
nào. Không giống như các loại nội dung bao-dữ liệu, các loại nội dung mã hóa dữ liệu đó
không có người nhận cũng không mã hóa nội dung các khóa mã hóa. Các phím được cho
là được quản lý bởi các phương tiện khác.
Dự kiến ứng dụng điển hình của kiểu nội dung mã hóa dữ liệu sẽ được mã hóa nội
dung của các loại nội dung dữ liệu cho việc lưu trữ địa phương, có lẽ nơi mà các khóa mã
hóa là một mật khẩu.
Các loại nội dung mã hóa dữ liệu EncryptedData loại ASN.1:
EncryptedData ::= SEQUENCE { version Version, encryptedContentInfo
EncryptedContentInfo }
Các thành phần loại EncryptedData có ý nghĩa sau đây:
Version là phiên bản số cú pháp. Nó sẽ là 0 cho phiên bản của tài liệu.
EncryptedContentInfo là nội dung thông tin được mã hóa, như trong Mục 10.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
22

10. Đối tượng nhận dạng
Tài liệu này định nghĩa bởi bảy đối tượng nhận dạng: PKCS-7, dữ
liệu, signedData envelopedData,, signedAndEnvelopedData, digestedData, vàEncryptedData.
Các đối tượng nhận dạng PKCS-7 xác định tài liệu này.
pkcs-7 OBJECT IDENTIFIER ::={ iso(1) member-body(2) US(840) rsadsi(113549)
pkcs(1) 7 }
Các đối tượng nhận dạng dữ liệu, bao gồm : signedData, envelopedData,signed
ndEnvelopedData, digestedData, và EncryptedData, xác định, tương ứng, các dữ liệu, ký
kết, dữ liệu, bao bọc dữ liệu, ký kết-và-bao-dữ liệu, tiêu hóa, dữ liệu, và các loại dữ liệu được
mã hóa nội dung quy định trong mục 8-13.
data OBJECT IDENTIFIER ::= { pkcs-7 1 }
signedData OBJECT IDENTIFIER ::= { pkcs-7 2 }
envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 }
signedAndEnvelopedData OBJECT IDENTIFIER ::={ pkcs-7 4 }
digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 }
encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 }
Những định danh đối tượng được định để được sử dụng trong lĩnh vực contentType
của một giá trị của loại ContentInfo (xem Phần 5). Các loại thành phần nội dung, trong đó có
cú pháp kiểu nội dung cụ thể bất kỳ được xác định bởi contentType, sẽ có kiểu dữ liệu
ASN.1, SignedData, EnvelopedData, SignedAndEnvelopedData, DigestedData, và
EncryptedData, tương ứng. Những định danh đối tượng cũng dự định được sử dụng trong một
thuộc tính nội dung kiểu PKCS # 9.
Lịch sử sửa đổi
Phiên bản 1.0-1.3
1.0-1.3 phiên bản đã được phân phát cho người tham gia RSA Data Security, Key
Cryptography trong cuộc họp tiêu chuẩn vào tháng Hai và tháng Ba năm 1991.
Phiên bản 1.4
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
23
Phiên bản 1.4 là một phần của phiên bản 03 tháng 6 năm 1991 phát hành ra công

chúng của PKCS.
Phiên bản 1.5
Phiên bản 1.5 kết hợp thay đổi một số biên tập, bao gồm các cập nhật của các tài liệu
tham khảo và lịch sử sửa đổi. Những thay đổi nội dung sau đây đã được thực hiện:
o Phần 6: loại CertificateRevocationLists được thêm vào.
o Mục 9.1: cú pháp SignedData được sửa đổi. Các phiên bản mới cho phép phổ biến
các danh sách thu hồi Giấy chứng nhận cùng với chữ ký. Nó cũng cho phép các chứng chỉ
phổ biến và thu hồi Giấy chứng nhận danh sách, mà không có bất kỳ chữ ký nào.
o Mục 9.2: cú pháp SignerInfo được sửa đổi. Các phiên bản mới bao gồm một thông
điệp giải mã quá trình mã hóa tương thích với Privacy-Enhanced Mail theo quy định tại
RFC1423.
o Phần 9.3: Ý nghĩa của "sự mã hóa DER của trường authenticatedAttributes" được
làm rõ là "mã hóa DER của giá trị thuộc tính."
o Mục 10,3: đệm phương pháp cho các thuật toán mã hóa nội dung được mô tả.
o Mục 11.1: cú pháp SignedAndEnvelopedData được sửa đổi. Các phiên bản mới cho
phép phổ biến các danh sách thu hồi chứng chỉ.
o Mục 13: mã hóa dữ liệu kiểu nội dung được thêm vào.
Đây là loại nội dung bao gồm các nội dung được mã hóa của định dạng nào.
o Mục 14: EncryptedData đối tượng nhận dạng được thêm vào.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
24
II. CHUẨN MÃ HÓA DỮ LIỆU DES (DATA ENCRYPTION STANDARD)
1. Giới thiệu chung về DES
Chuẩn mã hoá dữ liệu DES được Văn phòng tiêu chuẩn của Mỹ (U.S National Bureau
for Standards) công bố năm 1971 để sử dụng trong các cơ quan chính phủ liên bang. Giải
thuật được phát triển tại Công ty IBM dựa trên hệ mã hoá LUCIFER của Feistel.
DES là thuật toán mã hoá khối (block algrithm), với cỡ của một khối là 64 bít. Một
khối 64 bít bản rõ được đưa vào, sau khi mã hoá dữ liệu đưa ra là một khối bản mã 64 bít. Cả
mã hoá và giải mã đều sử dụng cùng một thuật toán và khoá.
Khoá mã có độ dài 64 bít, trong đó có 8 bít chẵn lẻ được sử dụng để kiểm soát lỗi. Các

bít chẵn lẻ nằm ở các vị trí 8, 16, 24, , 64. Tức là cứ 8 bít khoá thì trong đó có 1 bít kiểm
soát lỗi, bít này qui định số bít có giá trị “1” của khối 8 bít đó theo tính bù chẵn.
Nền tảng để xây dựng khối của DES là sự kết hợp đơn giản của các kỹ thuật thay thế
và hoán vị bản rõ dựa trên khoá. Đó là các vòng lặp. DES sử dụng 16 vòng lặp, nó áp dụng
cùng một kiểu kết hợp của các kỹ thuật trên khối bản rõ 16 lần (Như hình vẽ)Thuật toán chỉ
sử dụng các phép toán số học và lôgíc trên các số 64 bít, vì vậy nó dễ dàng thực hiện vào
những năm 1970 trong điều kiện về công nghệ phần cứng lúc bấy giờ. Ban đầu, sự thực hiện
các phần mềm kiểu này rất thô sơ, nhưng hiện tại thì việc đó đã tốt hơn, và với đặc tính lặp đi
lặp lại của thuật toán đã tạo nên ý tưởng sử dụng chíp với mục đích đặc biệt này.
HỆ THỐNG CHỨNG THỰC SỐ KTMT02
25
Tóm lại DES có một số đặc điểm sau:
♦ Sử dụng khoá 56 bít.
♦ Xử lý khối vào 64 bít, biến đổi khối vào thành khối ra 64 bít.
♦ Mã hoá và giải mã được sử dụng cùng một khoá.
♦ DES được thiết kế để chạy trên phần cứng.
DES thường được sử dụng để mã hoá các dòng dữ liệu mạng và mã hoá dữ liệu được lưu trữ
trên đĩa.
2. Mô tả thuật toán
DES thực hiện trên từng khối 64 bít bản rõ. Sau khi thực hiện hoán vị khởi đầu, khối
dữ liệu được chia làm hai nửa trái và phải, mỗi nửa 32 bít. Tiếp đó, có 16 vòng lặp giống hệt
nhau được thực hiện, được gọi là các hàm ƒ, trong đó dữ liệu được kết hợp với khoá. Sau 16