1.名词解释
- 数字签名:在ISO7498-2标准中定义为:"附加在数据单元上的一些数据,或是对数据单元所作的密码变换,这种数据和变换允许数据单元的接收者用以确认数据单元来源和数据单元的完整性,并保护数据,防止被人(例如接收者)进行伪造"。
- PKCS#7:也叫做加密消息的语法标准,由RSA安全体系在公钥加密系统中交换数字证书产生的一种加密标准。PKCS#7描述数字证书的语法和其他加密消息——尤其是,数据加密和数字签名的方法,也包含了算法。当使用PKCS#7进行数字签名时,结果包含签名证书(一列相关证书撤回列表)和已证明路径上任何其他证书。如果使用PKCS#7加密数据,通常包含发行者的参考消息和证书的序列号,它与用于解密已加密数据的公共密钥相关。
2.PKCS#7标准定义
-
数据:字节或8位元组串。
-
签名设计:随加密数据摘要一起的数据。一个信息摘要是一个哈希算法的结果(术语摘要和散列是相同定义的)。使用信息摘要保证原始消息在传输过程中没有被篡改,并确认发送者的身份。
-
封装数据:密文加上公钥能够解密数据。用这种方法保持消息内容对所有人保密,都是信任收件人。
-
签名和加密数据:有公钥的加密内容和双重加密的消息摘要。
-
摘要数据:数据加上消息摘要。
-
单独的加密数据:在这种情况,加密数据的公钥必须通过其他机制传输。
3.类型
1.CertificateRevocationList
CertificateRevocationLists 类型给定一个证书撤销列表的集合。它表示集合中包含足够的信息来决定集合中的证书是否是”hot listed”的,但是可能有多于必要的证书撤销列表,也可能少于必要的。
CertificateRevocationLists::= SET OF CertificateRevocationList
2.ContentEncryptionAlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier类型确定一个内容加密算法比如DES。一个内容加密算法支持加密和解密操作。加密操作用一个内容加密密钥把一个8位字节串(消息)映射为另一个8位字节串(密文)。解密操作和加密操作相反。由上下文确定使用哪 个操作。
ContentEncryptionAlgorithmIdentifier::= AlgorithmIdentifier
3.DigestEncryptionAlgorithmldentifier
DigestAlgorithmIdentifier类型确定一个消息摘要算法。例如MD2和MD5。一个消息摘要算法把一个8位字节串(消息)映射位另一个8位字节串(消息摘要)。
DigestAlgorithmIdentifier::= AlgorithmIdentifier
4. DigestEncryptionAlgorithmIdentifier
DigestEncryptionAlgorithmIdentifier类型确定一个摘要加密算法(可用来加密消息摘要)。 一个例子就是PKCS #1的rsaEncryption。一个摘要加密算法支持加密和解密操作。加密操作用一个摘要加密密钥把一个8位字节串(消息摘要)映射为另一个8位字节串(加了密的摘要)。解密操作和加密操作相反。由上下文确定使用哪 个操作。
DigestEncryptionAlgorithmIdentifier::= AlgorithmIdentifier
5.ExtendedCertificateOrCertificate
ExtendedCertificateOrCertificate类型指定一个PKCS #6扩展证书或者一个X.509证书。这一类型遵循PKCS #6 第6节推荐的语法:
ExtendedCertificateOrCertificate::= CHOICE {
certificate Certificate, -- X.509
extendedCertificate [0] IMPLICITExtendedCertificate
}
4.通用语法
参照此标准,实体间内容交换的通用语法在内容上结合了一个content type。 该语法应有ASN.1类型的 ContentInfo:
ContentInfo::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BYcontentType OPTIONAL }
ContentType::= OBJECT IDENTIFIER
类型ContentInfo的域有以下意义:
-
contentType 简要说明该内容的类型。它是一个对象标识符,即它是一个由定义内容类型的权威机构分配的唯一整数串。这一标准定义了六种内容类型:(见Section14): data, signedData,envelopedData, signedAndEnvelopedData, digestedData, 和 encryptedData。
-
content就是内容. 域是可选的,如果该域不存在,它的intended value一定由其他方式给出。它的类型和contentType的对象标识符一起定义。
注:当一个ContentInfo值是诸如signed-data、signed-and-enveloped-data、或者digested-data的内部内容,一个消息摘要算法就应用于该内容的DER编码的字节上。当一个ContentInfo值是enveloped-data或signed-and-enveloped-data 的内部内容,一个内容加密算法就应用于该内容的定长BER编码的字节上。
5.Signed-data 内容类型
signed-data内容类型由任意类型的内容和加密的(0或多个签名者)消息摘要组成
标准应用:
- 表示一个签名者对该内容类型数据的数字签名
- 发布证书和crl
签名数据的产生过程有如下几步:
- 对于每一个签名者,他用自己的消息摘要算法计算出摘要值
- 对于每一个签名者,消息摘要和相关的信息用自己的私钥加密
- 对于每一个签名者,把加密的消息摘要和其他的签名者特定信息放入SignerInfo值中。每个签名者的证书、crl以及那些并不对应任何签名者的信息也在这一步被收集进来。
- 把所有签名者的信息摘要算法、他们的SignerInfo值和内容一起放进SignedData值中。
5.1SignedData类型
signed-data内容类型应该是ASN.1 类型的 SignedData:
SignedData::= SEQUENCE {
version Version,//1
digestAlgorithmsDigestAlgorithmIdentifiers,
contentInfo ContentInfo,
certificates
[0]IMPLICIT ExtendedCertificatesAndCertificates
OPTIONAL,
crls
[1] IMPLICITCertificateRevocationLists OPTIONAL,
signerInfos SignerInfos
}
DigestAlgorithmIdentifiers::=
SET OF DigestAlgorithmIdentifier
SignerInfos::= SET OF SignerInfo
类型SignedData的域有以下几点意义:
- version是指语法的版本号,这一标准中版本应该为1 。
- digestAlgorithms是消息摘要算法标识符的集合。 可以包含任意数量的元素,包括0。每一个元素标识一种消息摘要算法(和任何相应的参数),内容就是用某个签名者的算法进行摘要运算的。该集合旨在(以任何顺序)列出所有签名者使用的消息摘要算法以方便one-pass签名验证。这一消息摘要处理过程在Section 9.3中有描述。
- contentInfo是被签名内容。它可以包含任意一种定义了的内容类型。
- certificates是PKCS#6扩展证书和X.509证书的集合。它表示集合足以包含从可识别的“根”或“顶级CA”到signerInfo域中所有签名者的证书链。可能有多于必要的证书,并且可能有足够的证书来包含链(从两个或多个独立的顶级CA)。 也可能有少于必要的证书,比如验证签名有一个替换的方法来获得必要的证书(e.g., 从一个先前证书集合中)。
- crls是证书撤销列表的集合。它表示集合包含足够的信息来决定certificates域中的证书是否是“hot listed”的,但这不是必须的。 可能有多于必要的crl,也可能有少于必要的crl。
- signerInfos是每个签名者信息的集合。其中可有任意数量的元素,包括0。
5.2 SignerInfo 类型
每个签名者的信息都早SignerInfo中呈现
SignerInfo::= SEQUENCE {
version Version,//是指语法的版本号,这一标准中版本应该为1
issuerAndSerialNumberIssuerAndSerialNumber,
digestAlgorithmDigestAlgorithmIdentifier,
authenticatedAttributes
[0] IMPLICIT Attributes OPTIONAL,
digestEncryptionAlgorithm
DigestEncryptionAlgorithmIdentifier,//标识用签名者私钥加密消息摘要和相关信息的摘要加密算法
encryptedDigest EncryptedDigest,//是用签名者私钥加密消息摘要和相关信息后的结果
unauthenticatedAttributes//是不被签名者签名(i.e.鉴别的)的属性的集合
[1] IMPLICIT Attributes OPTIONAL }
EncryptedDigest::= OCTET STRING
- issuerAndSerialNumber通过颁发者的可辨别名和颁发序列号来指定签名者的证书(及签名者的可辨别名和公钥)。
- digestAlgorithm指定对内容和待鉴别属性(若存在的话)进行摘要计算的信息摘要算法(及相应的参数)。它应该存在于高级SignerInfo值的digestAlgorithms域中。信息摘要的处理在Section9.3中描述。
- authenticatedAttributes是经由签名者签名(i.e.鉴别的)的属性的集合。 该域是可选的,但是当被签名的ContentInfo的content type不是data类型时该域必须存在。如果该域存在,它必须包含至少两个属性:
- PKCS #9 content-type 属性,当ContentInfo的content type值被签名时。
-
PKCS #9 message-digest 属性,当值是内容的消息摘要时(见下面)。
建议在PKCS实现中仅产生版本1的SignedData 值。既然版本0兼容的PEM签名方法已废弃,建议PKCS实现仅接受版本1的SignedData 值。
5.3 消息摘要处理
- 初始的输入是ContentInfo的content域中的DER编码的内容字节。仅仅是该域的DER编码的内容字节进行摘要计算,而不包括 identifier字节或length字节。
- 消息摘要依赖于authenticatedAttributes域是否存在。当该域不存在时,结果就是内容的消息摘要值。然而当该域存在时,结果是包含authenticatedAttributes中的属性值的完全DER编码的消息摘要。既然Attributes值必须当作和内容的content type、消息摘要一样的属性被包含,那些值就间接的包含在结果中
- 当待签名内容的content type是data且authenticatedAttributes域不存在时仅该数据的值(e.g.,文件的内容)进行摘要计算。这样有一个优点,就是在加密处理前无需知道待签名的内容的长度。这个方法和PEM兼容。
5.4摘要加密的处理
- 输入:消息摘要处理的结果和摘要算法标识符(或object identifier)。
- 加密密钥:签名者的私钥
- 结果密钥对DigestInfo类型值的BER编码
DigestInfo::= SEQUENCE {
digestAlgorithmDigestAlgorithmIdentifier,
digest Digest
}
Digest::= OCTET STRING
- digestAlgorithm标识用来计算内容和鉴别属性的摘要的消息摘要算法(和相应的参数)。它应该和SignerInfo的digestAlgorithm 域有同样的值。
- digest是消息摘要处理的结果。
6.Enveloped-data 内容类型
6.1 组成
- 加密内容和加密的一个或者多个接收者的内容加密密钥组成。
6.2 组建过程
- 随机产生一个对应于特定对称加密算法的内容加密密钥K1
- 用K1加密内容得到密文E
- 用接收者的公钥对k进行机密得到。
- 对与每一个接受者将K2和接受者的其他信息放入Recipientinfo
- 将所有接收者的RecipientInfo值和密文E放入EnvelopedData值中。
6.3 Envelop-data 类型
EnvelopedData::= SEQUENCE {
version Version,
recipientInfos RecipientInfos,// 每个接收者信息的集合
encryptedContentInfo EncryptedContentInfo //密文
}
RecipientInfos::= SET OF RecipientInfo
EncryptedContentInfo::= SEQUENCE {
contentType ContentType,//指示内容的类型
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContentOPTIONAL //标识内容加密算法
}
EncryptedContent::= OCTET STRING
6.4RecipientInfo类型
- 每个接收者信息用RecipientInfo类型表示:
RecipientInfo::= SEQUENCE {
version Version,
issuerAndSerialNumber IssuerAndSerialNumber,//通过特定的号码和数字指定受者的证书
//指定用接收者公钥加密内容加密密钥的密钥加密算法
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey //被接受者加密密钥加密后的内容密钥
}
EncryptedKey::= OCTET STRING
7.Signed-and-enveloped-data 内容类型
7.1 组成
- 由任意类型的加密内容、加了密的一个/多个接收者的内容加密密钥和双重加密的一个/多个签名者的消息摘要。
- “双重加密”由签名者私钥的加密和内容加密密钥的加密组成。
7.2 组件过程
- 随机产生一个对应于特定加密算法的内容加密密钥k1
- 内容加密密钥用每个接受者的公钥加密得到,密钥k2
- 对与每一个接受者将K2和接受者的其他信息放入Recipientinfo
- 对于每一个签名者,他用自己的消息摘要算法计算出摘要值 (如果两个签名者使用同样的算法,那么摘要值只需计算一次) 。
- 对于每一个签名者,消息摘要S和相关的信息用自己的私钥加密得到Sp,结果再用k1加密得到SE
- 对于每一个签名者,把双重加密的消息摘要和其他的签名者特定信息放入SignerInfo值中
- 用k1加密原文P得到密文E
- 把所有签名者的消息摘要算法、所有签名者的SignerInfo值、所有接收者的RecipientInfo值和密文E一起放入SignedAndEnvelopedData
7.2.3打开信封并验证签名
- 用接收者的私钥解密钥K2得到密钥K1,并用内容加密密钥K1解开加密的内容得到原文P。
- 每个签名者双重加密的消息摘要SE用K1解得到SP,结果再用签名者公钥解密Sp得到摘要S,恢复的消息摘要S再和独立计算的消息摘要进行比较。
- 注: signed-data和enveloped-data内容类型有序结合通常比SignedAndEnvelopedData 更情愿被使用,除非有意考虑PEM加密处理的兼容性。
7.3 SignedAndEnvelopedData 类型
SignedAndEnvelopedData::= SEQUENCE {
version Version,// 1
recipientInfos RecipientInfos, //
digestAlgorithmsDigestAlgorithmIdentifiers,//消息摘要算法标识符的集合
encryptedContentInfoEncryptedContentInfo,//加密内容
//PKCS#6扩展证书何X509证书的集合
certificates [0]IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
//是证书撤销列表的集合
crls [1] IMPLICIT CertificateRevocationListsOPTIONAL,
signerInfos SignerInfos //每个签名者信息集合
}
- 注:摘要处理过程中都没使用DER编码
8. Digested-data内容类型
8.1 组成
- digested-data内容类型由任意类型的内容和内容的消息摘要组成。
8.2 组建过程
- 使用消息摘要算法对内容计算摘要
- 把消息摘要算法、消息摘要和内容放入DigestdData中.
DigestedData::= SEQUENCE {
version Version,
digestAlgorithmDigestAlgorithmIdentifier,//标识对内容进行摘要计算的消息摘要算法
contentInfo ContentInfo,//对其进行摘要计算的内容。可以是任意定义的内容类型。
digest Digest // digest是消息摘要计算的结果。
}
Digest::= OCTET STRINGD
9.Encrypted-data内容类型
- encrypted-data内容类型由任意类型的加密内容组成。 encryptedContentInfo是加了密的内容信息
EncryptedData::= SEQUENCE {
version Version,// version是指语法的版本号,这一标准中版本应该为0。
encryptedContentInfoEncryptedContentInfo// encryptedContentInfo是加了密的内容信息
}
9.数字签名与数字信封
1. 数字签名
-
指用户利用自己的私钥对原始数据的哈希摘要进行加密所得的数据。数字签名定义两种互补的运算:一种用于签名,另一个用于验证。“私钥签名,公钥验证”。
-
签名:发送方用特殊的hash算法,由明文中产生固定长度的【摘要】,然后利用自己的私钥对形成的摘要进行加密,这里加密后的数据就是数字签名。
-
验证:接受方利用发送方的公钥解密被加密的摘要得到结果A,然后对明文也进行hash操作产生摘要B.最后,把A和B作比较。此方式既可以保证发送方的身份正确性,又可以保证数据在传输过程中不会被篡改。
2.数字信封
- 数字信封的功能类似于普通信封。普通信封在法律的约束下保证只有收信人才能阅读信的内容;数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。
- 数字信封中采用了单钥加密体制和公钥密码体制。信息发送者首先利用随机产生的【对称密钥】加密信息(因为非对称加密技术的速度比较慢),再利用接收方的【公钥】加密对称密钥。在传递信息时,信息接收方要解密信息时,必须先用自己的私钥解密加密的对称密钥,得到对称密钥,才能利用对称密钥解密所得到的信息。
- 数字信封既发挥了对称加密算法速度快、安全性好的优点,又发挥了非对称加密算法密钥管理方便的优点。
3.应用示例
- 为了保证信息传送的真实性、完整性和不可否认性,需要对要传送的信息进行数字加密和数字签名。其传送过程如下:
发送者A:
-
A准备要传送的 数字信息(明文)
-
A对数字信息(明文)进行哈希(hash)运算,得到一信息摘要。
-
A用自己的【私钥(SK)】对信息摘要进行加密得到A的数字签名,并将其附在数字信息上。(数字签名)
-
A随机产生一个对称密钥,并用此密钥对要发送的信息(明文)进行加密,形成密文。(对称加密)
-
A用B的【公钥(PK)】对刚才随机产生的加密密钥进行加密得到encKey,将加密后的DES密钥连同密文一起传送给B。(数字信封)
接收者B:
-
B收到A传送过来的密文和加过密的DES密钥,先用自己的私钥(SK)对encKey进行解密,得到对称密钥。
-
B然后用对称密钥对受到的密文进行解密,得到明文的数字信息,然后将对称密钥抛弃(即密钥作废)。
-
B用A的公钥(PK)对A的数字签名进行解密,得到信息摘要。
-
B用相同的has算法对收到的明文再进行一次hash运算,得到一个新的信息摘要。
-
B将收到的信息摘要和新生成的信息摘要进行比较,如果一致,说明收到的信息没有被修改过。