数字证书原理
程序员文章站
2022-03-19 11:13:44
公钥机制面临的问题-假冒身份发布公钥
采用公钥机制进行加密传输面临的一个问题是公钥的发布。任何一个用户都可以通过网络向所有人发布伪造的公钥,如果某个用户假冒真正用户的名义发布一个公钥,在该假...
公钥机制面临的问题-假冒身份发布公钥
采用公钥机制进行加密传输面临的一个问题是公钥的发布。任何一个用户都可以通过网络向所有人发布伪造的公钥,如果某个用户假冒真正用户的名义发布一个公钥,在该假冒者被揭穿以前,他可以解读所有发向真正用户的加密消息,还可以通过签名冒充真正用户的身份。
用户A假冒用户B的身份发布一个公钥
其他用户使用假冒的公钥与用户B通信,信息内容被用户A窃取
数字证书-验证公钥所属的用户身份
在日常生活中,如果我们要验证一个人的身份,通常的做法是查看他的身份证。我们信任身份证颁发机构即*机构的公信力,因此只要验证一个人的身份证不是伪造的,我们就相信这个人的身份和身份证上所描述的是一致的。
数字证书就是一个人或者组织在网络世界中的身份证,其发证机关是证书管理机构(certificate authority,CA)。CA用自己的私钥对用户的身份信息(主要是用户名和该用户的公钥)进行签名,该签名和用户的身份信息一起就形成了证书。
使用用户身份信息生成数字签名
用户身份信息和数字签名一起组成数字证书
备注:除用户信息外,数字证书中还包括证书机构名称,证书有效期,证书的序列号,签名使用的哈希算法,公钥使用的加密算法等相关信息,参见rfc标准:RFC 2459 Internet X.509 Public Key Infrastructure
用户A把自己的证书发送给用户B。用户B使用CA的公钥对证书的签名进行验证,由于只有CA才能生成该证书,因此只要证书验证正确,即说明证书是由CA发布的,证书中用户A的公钥是值得信赖的。用户B以后就可以使用该公钥验证用户A的签名或者进行和A进行加密通信。
使用证书验证用户的身份,获取用户公钥
如何验证证书机构的公钥-证书的证书
这里有一个有趣的问题,用户B使用证书机构的公钥来验证用户A的数字证书,但如何又能够知道用户B拿到的证书机构的公钥不是伪造的呢?解决办法是再找一个证书机构对该证书机构的公钥颁发一个证书,这样形成了一个公钥证书的嵌套循环,该循环的终点就是根证书机构。根证书机构较少,其公钥可以通过安全的方式发布,如通过USB拷贝、书面文件当面移交。
数字证书认证链
Certificate:
Data:
<span style="color:#FF0000;">证书标准版本号</span>
Version: 1 (0x0)
<span style="color:#FF0000;">该证书的唯一编号</span>
Serial Number: 7829 (0x1e95)
<span style="color:#FF0000;">该证书的签名算法</span>
Signature Algorithm: md5WithRSAEncryption
<span style="color:#FF0000;">颁布本证书的证书机构</span>
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
<span style="color:#FF0000;">证书有效期</span>
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
<span style="color:#FF0000;">证书持有人的姓名、地址等信息</span>
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
<span style="color:#FF0000;">证书持有人的公钥</span>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
<span style="color:#FF0000;">证书机构对该证书的数字签名</span>
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
作者 呦呦鹿鸣,食野之芩
采用公钥机制进行加密传输面临的一个问题是公钥的发布。任何一个用户都可以通过网络向所有人发布伪造的公钥,如果某个用户假冒真正用户的名义发布一个公钥,在该假冒者被揭穿以前,他可以解读所有发向真正用户的加密消息,还可以通过签名冒充真正用户的身份。
用户A假冒用户B的身份发布一个公钥
其他用户使用假冒的公钥与用户B通信,信息内容被用户A窃取
数字证书-验证公钥所属的用户身份
在日常生活中,如果我们要验证一个人的身份,通常的做法是查看他的身份证。我们信任身份证颁发机构即*机构的公信力,因此只要验证一个人的身份证不是伪造的,我们就相信这个人的身份和身份证上所描述的是一致的。
数字证书就是一个人或者组织在网络世界中的身份证,其发证机关是证书管理机构(certificate authority,CA)。CA用自己的私钥对用户的身份信息(主要是用户名和该用户的公钥)进行签名,该签名和用户的身份信息一起就形成了证书。
使用用户身份信息生成数字签名
用户身份信息和数字签名一起组成数字证书
备注:除用户信息外,数字证书中还包括证书机构名称,证书有效期,证书的序列号,签名使用的哈希算法,公钥使用的加密算法等相关信息,参见rfc标准:RFC 2459 Internet X.509 Public Key Infrastructure
用户A把自己的证书发送给用户B。用户B使用CA的公钥对证书的签名进行验证,由于只有CA才能生成该证书,因此只要证书验证正确,即说明证书是由CA发布的,证书中用户A的公钥是值得信赖的。用户B以后就可以使用该公钥验证用户A的签名或者进行和A进行加密通信。
使用证书验证用户的身份,获取用户公钥
如何验证证书机构的公钥-证书的证书
这里有一个有趣的问题,用户B使用证书机构的公钥来验证用户A的数字证书,但如何又能够知道用户B拿到的证书机构的公钥不是伪造的呢?解决办法是再找一个证书机构对该证书机构的公钥颁发一个证书,这样形成了一个公钥证书的嵌套循环,该循环的终点就是根证书机构。根证书机构较少,其公钥可以通过安全的方式发布,如通过USB拷贝、书面文件当面移交。
数字证书认证链
一个数字证书的例子
Certificate:
Data:
<span style="color:#FF0000;">证书标准版本号</span>
Version: 1 (0x0)
<span style="color:#FF0000;">该证书的唯一编号</span>
Serial Number: 7829 (0x1e95)
<span style="color:#FF0000;">该证书的签名算法</span>
Signature Algorithm: md5WithRSAEncryption
<span style="color:#FF0000;">颁布本证书的证书机构</span>
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/emailAddress=server-certs@thawte.com
<span style="color:#FF0000;">证书有效期</span>
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
<span style="color:#FF0000;">证书持有人的姓名、地址等信息</span>
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
<span style="color:#FF0000;">证书持有人的公钥</span>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
<span style="color:#FF0000;">证书机构对该证书的数字签名</span>
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
作者 呦呦鹿鸣,食野之芩
上一篇: TrueCrypt加密之后的取证方法
下一篇: 浅析Java易遭受逆向工程攻击的原因