公钥基础设施

攻击公钥加密

  1. 假设由Bob和Alice两个用户，他们之间想要通信，必须首先进行密钥交换：
  • 使用公钥密码，Alice只需要将她的公钥发给Bob，Bob可以生成一个密钥，并用Alice的公钥加密后发送给Alice，由于Alice是唯一可以解密的人，窃听这个通信的攻击者是无法获得密钥的。
  1. 中间人攻击：
  • 假设Mallory是一个攻击者，她可以截获Alice与Bob之间的通信并实施攻击：
    在这里插入图片描述
  • Mallory实施攻击的过程如下：
    1. Mallory截获Alice发送的公钥，用自己的公钥代替Alice的公钥发送给Bob。
    2. Bob无法判断公钥的来源，因为消息看起来是来自Alice的，因此他用收到的公钥加密自己生成的随机密钥。
    3. Mallory截获Bob的加密消息，由于消息是用她的公钥加密的，因此她可以解密消息，获得随机密钥，随后，她用Alice的公钥将随机密钥加密后发送个Alice。
    4. Alice可以解密消息，获得随机密钥，然后Alice与Bob就可以用该密钥来加密他们之间的通信。
  • 由于Mallory以及获得了这个密钥，因此她可以解密Alice与Bob之间的整个通信，并且可以修改他们的通信数据，Alice与Bob之间的通信安全完全被破坏。
  1. 防御中间人攻击
  • 中间人攻击的基本问题是Bob收到声称是Alice的公钥，但他没有办法判别这个公钥是否属于Alice。
  • 数字签名也是基于公钥密码学的，它用签名者的私钥签名，任何知道签名者公钥的人都可以验证它，如果消息的内容被篡改，数字签名就失效了。
  • 可以用数字签名技术防御中间人攻击，因此之前的Alice和Bob可以找一个信任方对他们的身份进行验证，Alice可以到DMV办公室出示她的身份证并提交她的公钥，她必须亲自到DMV办公室，从而保证没有其他人可以截获这个流程，在验证完ID后，DMV办公室会准备一个数字文件，其中包含Alice的名字和公钥，以及一些其他信息，如过期时间等，DMV办公室为这个数字文件进行数字签名，这个数字文件和数字签名称为证书。
  • 现在，当Alice发送他的公钥给Bob时，Alice也发送整个证书给Bob，因此公钥与一个经信任机构验证过的名字一起发过来，Mallory仍然可能截获证书，但是她不能用自己的公钥代替Alice的公钥且仍然保持Alice的名字，那将使DMV的签名无效，，如果他将自己的证书发给Bob,Bob将不知道这个公钥属于Alice，因此会终止通信，Mallory没有办法获得一个包含她的公钥和Alice名字的证书，因为作为信任机构知道Mallory不是Alice，它会拒绝签发这样的证书。
  • 为了验证DMV在Alice证书上的签名，Bob需要获得DMV的公钥，但是他不能通过网络获得，因为这又得面临潜在的中间人攻击，他也必须亲自到DMV办公室以获得它的公钥。
  1. 公钥基础设施
  • 两个重要组件：
    1. 认证机构（CA）：他们负责验证用户的身份并且提供经由他们签名的数字证书。
    2. 数字证书：他提供了一个公钥以及与这个公钥相关的信息，认证机构需要在数字证书上签名以证明它核实过证书的内容，数字证书也称为公钥证书。

公钥证书

  1. 公钥证书由公钥和它的拥有者，以及认证机构的签名组成。证书接收者可以验证签名以确保证书的完整性，在认证成功后，接收者可以得到公钥真正拥有者。
  2. X.509数字证书
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0e:c3:4e:77:02:57:00:4f:ad:cc:f4:a2:f5:19:d6:0c
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 Extended Validation Server CA
        Validity
            Not Before: Jan  9 00:00:00 2020 GMT
            Not After : Jan 12 12:00:00 2022 GMT
        Subject: businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=3014267, C=US, ST=California, L=San Jose, O=PayPal, Inc., OU=CDN Support, CN=www.paypal.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ab:9a:c4:47:e6:4f:4b:f0:7a:29:6f:9a:1d:6b:
                    4e:d5:04:0e:b2:02:ed:8d:d1:a9:ae:d5:da:20:8c:
                    7e:8a:49:1a:3c:09:13:f7:72:ee:2e:40:e0:29:41:
                    02:78:97:55:f8:06:0d:7b:2a:e3:e0:b3:e5:64:f2:
                    de:b8:b8:35:e1:c5:7c:eb:12:e3:68:47:74:6c:bc:
                    04:25:33:09:17:28:e0:c9:3a:b2:4e:65:50:d0:4a:
                    e4:3b:b2:e1:2e:82:45:cb:52:05:3b:a4:b7:37:eb:
                    c8:29:fc:43:67:cc:66:a9:e5:9f:22:1b:1b:f7:86:
                    36:35:9b:45:f5:0f:6c:3d:1d:15:55:5d:fe:ca:7d:
                    5c:ef:1d:76:b7:f0:59:85:89:1a:c9:d2:bf:58:bc:
                    26:9c:11:75:60:cb:59:e6:74:18:ee:0e:06:bc:54:
                    a1:47:f9:f5:b5:c0:be:ad:6d:ee:dd:99:b6:50:ed:
                    85:33:f5:bd:93:4b:66:a9:08:f0:67:c7:bd:42:24:
                    c2:3b:e3:7f:f1:e2:51:62:b5:51:ae:21:a8:24:d9:
                    c9:ed:d3:b4:60:17:6a:0c:78:69:c1:96:ad:62:1d:
                    18:11:a6:ea:f4:83:eb:2d:ae:b0:be:2e:56:9d:cf:
                    9d:2c:70:5a:df:b2:1e:3a:c7:e4:23:e3:3b:58:e1:
                    fd:9d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:3D:D3:50:A5:D6:A0:AD:EE:F3:4A:60:0A:65:D3:21:D4:F8:F8:D6:0F

            X509v3 Subject Key Identifier: 
                F0:1E:F5:E3:EE:33:53:69:54:6A:27:40:E0:CE:84:B6:69:68:4B:9E
            X509v3 Subject Alternative Name: 
                DNS:www.paypal.com, DNS:login.paypal.com, DNS:history.paypal.com, DNS:www.paypalobjects.com, DNS:pics.paypal.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl3.digicert.com/sha2-ev-server-g2.crl

                Full Name:
                  URI:http://crl4.digicert.com/sha2-ev-server-g2.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.114412.2.1
                  CPS: https://www.digicert.com/CPS
                Policy: 2.23.140.1.1

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2ExtendedValidationServerCA.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                                3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
                    Timestamp : Jan  9 00:41:33.309 2020 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:F6:D8:70:6F:DE:F3:A1:DF:10:DF:94:
                                78:E6:27:98:A9:7C:60:D1:C2:09:7D:39:DE:18:E6:4B:
                                D4:79:F7:FB:00:02:21:00:A5:B9:13:F3:F6:69:AB:70:
                                DC:D0:F3:AD:1F:EF:FA:4F:57:0E:38:00:6C:48:A8:78:
                                99:9C:8C:32:94:97:21:24
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                                46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
                    Timestamp : Jan  9 00:41:33.535 2020 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:FF:91:95:F6:47:8B:41:58:C0:BD:19:
                                73:8B:9F:98:A0:5C:F2:9A:24:22:2A:F2:64:0F:48:B7:
                                DE:40:22:8D:DC:02:20:4B:9A:A9:F1:79:A3:01:65:10:
                                CA:BC:FC:24:F5:0A:9D:9A:1A:05:10:F0:2E:0C:EF:CC:
                                A9:AF:24:84:13:29:A0
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : EE:4B:BD:B7:75:CE:60:BA:E1:42:69:1F:AB:E1:9E:66:
                                A3:0F:7E:5F:B0:72:D8:83:00:C4:7B:89:7A:A8:FD:CB
                    Timestamp : Jan  9 00:41:33.381 2020 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:08:FE:99:AB:2F:BE:95:36:08:E0:23:F7:
                                FA:0D:EE:50:A2:46:00:51:D3:F4:8A:75:8C:74:62:02:
                                A4:53:5C:8A:02:20:13:8A:4C:E6:E2:C7:0D:38:39:EB:
                                49:29:D4:23:43:4C:FA:4B:01:8C:D2:DB:CB:7F:39:4C:
                                84:14:E4:A4:DD:24
    Signature Algorithm: sha256WithRSAEncryption
         95:06:8c:5c:1c:39:aa:19:33:0c:70:58:7f:94:2b:a4:71:be:
         f7:13:4e:23:73:f0:a8:7c:35:16:0e:e2:be:59:56:3d:8c:5d:
         fa:8c:fb:dd:de:8e:34:a3:6a:b3:86:5b:29:52:4a:5f:f7:cb:
         1f:33:b8:c8:60:3b:30:72:94:fc:61:df:5d:80:2f:f9:8f:ad:
         f3:85:98:2a:e8:ed:6c:02:e1:3e:d0:cc:ef:68:36:4e:ae:51:
         6d:ca:2e:7b:ae:a3:79:3d:27:67:74:15:4d:cf:c9:1d:a1:f9:
         43:69:ce:66:b2:eb:ec:c4:31:48:27:d9:2d:e2:eb:f4:72:0a:
         73:23:d1:9c:5d:8e:34:b2:95:a3:a8:09:16:ce:2f:bf:d1:f8:
         47:bd:c1:6d:36:7e:3a:9c:58:c1:47:40:92:8e:b6:32:97:89:
         5e:fb:46:c3:3d:2c:06:46:23:86:2a:6c:d2:3a:18:3e:3a:2b:
         fc:c3:3a:c0:17:6a:4c:32:f5:d2:a8:a9:a3:5f:2a:53:c9:bf:
         88:9f:0f:c6:74:63:7d:83:17:49:60:72:d2:cb:c9:b8:02:58:
         f7:d9:f0:3c:fe:1f:4d:fb:eb:43:a0:fa:58:9e:19:1c:b7:6c:
         45:ec:0c:b9:0d:4a:09:be:76:68:35:48:62:5c:82:3c:80:e4:
         e7:7b:66:f7
  • Issuer：这个域提供签发证书的认证机构的信息。
  • Subject：这个域提供该证书拥有者的信息。
  • Subject Public Key Info：这个域包含实际的公钥。
  • Signature Algorithm：这个域包含签发者的数字签名。
  • Validity：这个域定义了证书的有效时间。
  • Serial Number：每一个证书都有一个独特的序列号，这个序列号位于证书的开头部分。
  • Extension：新版本的X.509证书包含可选拓展域。
  1. 从真实服务器获取证书
  • 下面的openssl s_client命令开启一个HTTPS客户端，并且连接到Paypal网站，使用-showcerts选项可以打印处所有从Paypal服务器接收到的证书：
[07/19/20]seed@VM:~$ openssl s_client -showcerts -connect www.paypal.com:443 < /dev/null
  • 上面的命令不打印证书的原始内容，而是打印已被编码的内容，X.509证书使用的使二进制数据，其中有很多不能打印的字符，也无法复制粘贴。
  • 我们将得到证书的内容，保存在pem文件中：
[07/20/20]seed@VM:~$ cat paypal.pem 
-----BEGIN CERTIFICATE-----
MIIHmTCCBoGgAwIBAgIQDsNOdwJXAE+tzPSi9RnWDDANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDEwOTAwMDAwMFoXDTIyMDExMjEy
MDAwMFowgdwxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
EwczMDE0MjY3MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8G
A1UEBxMIU2FuIEpvc2UxFTATBgNVBAoTDFBheVBhbCwgSW5jLjEUMBIGA1UECxML
Q0ROIFN1cHBvcnQxFzAVBgNVBAMTDnd3dy5wYXlwYWwuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq5rER+ZPS/B6KW+aHWtO1QQOsgLtjdGprtXa
IIx+ikkaPAkT93LuLkDgKUECeJdV+AYNeyrj4LPlZPLeuLg14cV86xLjaEd0bLwE
JTMJFyjgyTqyTmVQ0ErkO7LhLoJFy1IFO6S3N+vIKfxDZ8xmqeWfIhsb94Y2NZtF
9Q9sPR0VVV3+yn1c7x12t/BZhYkaydK/WLwmnBF1YMtZ5nQY7g4GvFShR/n1tcC+
rW3u3Zm2UO2FM/W9k0tmqQjwZ8e9QiTCO+N/8eJRYrVRriGoJNnJ7dO0YBdqDHhp
wZatYh0YEabq9IPrLa6wvi5Wnc+dLHBa37IeOsfkI+M7WOH9nQIDAQABo4IDuzCC
A7cwHwYDVR0jBBgwFoAUPdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFPAe
9ePuM1NpVGonQODOhLZpaEueMGcGA1UdEQRgMF6CDnd3dy5wYXlwYWwuY29tghBs
b2dpbi5wYXlwYWwuY29tghJoaXN0b3J5LnBheXBhbC5jb22CFXd3dy5wYXlwYWxv
YmplY3RzLmNvbYIPcGljcy5wYXlwYWwuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNybDA0oDKg
MIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNy
bDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8MHow
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEFBQcw
AoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4dGVu
ZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIBfgYKKwYB
BAHWeQIEAgSCAW4EggFqAWgAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80O
yA3cEAAAAW+Hv9N9AAAEAwBIMEYCIQD22HBv3vOh3xDflHjmJ5ipfGDRwgl9Od4Y
5kvUeff7AAIhAKW5E/P2aatw3NDzrR/v+k9XDjgAbEioeJmcjDKUlyEkAHYAVhQG
mi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ0N0AAAFvh7/UXwAABAMARzBFAiEA
/5GV9keLQVjAvRlzi5+YoFzymiQiKvJkD0i33kAijdwCIEuaqfF5owFlEMq8/CT1
Cp2aGgUQ8C4M78yprySEEymgAHUA7ku9t3XOYLrhQmkfq+GeZqMPfl+wctiDAMR7
iXqo/csAAAFvh7/TxQAABAMARjBEAiAI/pmrL76VNgjgI/f6De5QokYAUdP0inWM
dGICpFNcigIgE4pM5uLHDTg560kp1CNDTPpLAYzS28t/OUyEFOSk3SQwDQYJKoZI
hvcNAQELBQADggEBAJUGjFwcOaoZMwxwWH+UK6RxvvcTTiNz8Kh8NRYO4r5ZVj2M
XfqM+93ejjSjarOGWylSSl/3yx8zuMhgOzBylPxh312AL/mPrfOFmCro7WwC4T7Q
zO9oNk6uUW3KLnuuo3k9J2d0FU3PyR2h+UNpzmay6+zEMUgn2S3i6/RyCnMj0Zxd
jjSylaOoCRbOL7/R+Ee9wW02fjqcWMFHQJKOtjKXiV77RsM9LAZGI4YqbNI6GD46
K/zDOsAXakwy9dKoqaNfKlPJv4ifD8Z0Y32DF0lgctLLybgCWPfZ8Dz+H03760Og
+lieGRy3bEXsDLkNSgm+dmg1SGJcgjyA5Od7Zvc=
-----END CERTIFICATE-----
  • 把PEM文件解码为原始二进制数据，解密结果无法用文本编辑器查看，需要使用二进制文件查看器，例如ghex和bless。
[07/20/20]seed@VM:~/.../pki$ openssl x509 -in paypal.pem -outform der > paypal.der
[07/20/20]seed@VM:~/.../pki$ ls
paypal.der  paypal.pem
  • 直接查看X.509证书的原始二进制数据和Base64编码后的数据，看到的都是乱码，可以用以下命令把这些乱码转换成可读的形式：
[07/20/20]seed@VM:~/.../pki$ openssl x509 -in paypal.pem -text -noou

认证机构

  1. 认证机构（CA）是一个可信的、能够签发数字证书的实体，在签发证书之前，CA需要验证证书申请者的身份。
  2. CA核心功能有两个：
  • Subject域验证：数字证书的重要组成部分是Subject域，Subject域由证书拥有者的身份信息组成，在签发证书之前，CA需要确认证书申请者拥有或代表Subject域内注册的身份。在许多公钥证书中，SUbject域包含一个域名，CA需要检查申请者是否拥有该域名。
  • 签名数字证书：一旦CA验证了证书申请者的身份，它就可以用私钥为这个证书生成一个数字签名，这个数字签名实际上将证书中的公钥和它的拥有者绑定在一起，任何对证书的篡改都将使证书失效，任何人只要拥有CA的公钥就可以验证证书的真伪。
  1. 申请数字证书的过程如下：首先银行和ModelA需要生成各自的“公钥-私钥”对，然后，银行生成一个证书签名请求，其中包含获得证书需要的域名和公钥，银行提交请求给ModelCA,ModelCA会对请求中的信息进行验证，包括验证bank32是否属于该银行。
  2. 一旦所有信息被验证，ModelCA会用自己的私钥生成一个数字证书，这个数字证书将交给银行，银行部署基于HTTPS的网络服务器。
  3. ubuntu进行模拟：
  • 用openssl创建一个CA，签名时，openssl会使用一个默认的配置文件（/usr/lib/ssl/openssl.cnf)，该文件中以及配置了需要的文件夹和文件的名字。根据这些配置我们创建如下文件夹及文件，serial文件包含证书的序列号，可以将1000或任意数字放在文件夹中来初始化序列号。
[07/20/20]seed@VM:~/.../pki$ mkdir demoCA
[07/20/20]seed@VM:~/.../pki$ cd demoCA/
[07/20/20]seed@VM:~/.../demoCA$ mkdir certs crl newcerts
[07/20/20]seed@VM:~/.../demoCA$ touch index.txt serial
[07/20/20]seed@VM:~/.../demoCA$ echo 1000 > serial
  • 为ModelCA生成公钥-私钥对和证书：为了验证CA生成的证书，需要用到CA的公钥，因此每一个CA都需要有自己的数字证书，如果CA是一个中间CA，那么它的证书由其他CA颁发，如果CA是一个根CA，则需要自己给自己颁发公钥证书，也就是自己在公钥证书上签名，这样的证书称为自签名证书。
  • 下面需要为ModelCA创建公钥-私钥对，并且为它生成一个自签名的证书：
[07/20/20]seed@VM:~/.../demoCA$ openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout modelCA_key.pem -out modelCA_cert.pem
Generating a 4096 bit RSA private key
..................................................................++
................++
writing new private key to 'modelCA_key.pem'
Enter PEM pass phrase:
3070285504:error:28069065:lib(40):UI_set_result:result too small:ui_lib.c:823:You must type in 4 to 1024 characters
3070285504:error:0906406D:PEM routines:PEM_def_callback:problems getting password:pem_lib.c:110:
3070285504:error:0907E06F:PEM routines:DO_PK8PKEY:read key:pem_pk8.c:130:
  • 公钥和私钥对存储在受密码保护的文件modelCA_key.pem中，选项-x509指明生成一个自签名的公钥证书，而不是一个整数请求，自签名的证书保存在modelCA_cert.pem中，该证书在3650天内有效。
  • 为了获得X.509证书，银行首先需要生成自己的公钥-私钥对，这可以由以下的opensl命令实现：
[07/20/20]seed@VM:~/.../demoCA$ openssl genrsa -aes128 -out bank_key.pem 2048
Generating RSA private key, 2048 bit long modulus
..+++
.................................+++
e is 65537 (0x10001)
Enter pass phrase for bank_key.pem:
Verifying - Enter pass phrase for bank_key.pem:
  • 以上命令生成一个名为bank_key.pem的文件，这个文件由用户设置的密码保护，如果没有-aes128选项则不需要密码保护，可以用下面指令查看bank_key.pem的实际内容：
[07/20/20]seed@VM:~/.../demoCA$ openssl rsa -noout -text -in bank_key.pem 
Enter pass phrase for bank_key.pem:
Private-Key: (2048 bit)
modulus:
    00:d4:71:89:e6:0e:dc:f1:b4:05:25:fe:88:f4:6f:
   	...
publicExponent: 65537 (0x10001)
privateExponent:
    00:86:e0:2e:b4:a8:eb:0d:69:45:7b:81:c6:61:aa:
    1b:fa:63:0c:3f:25:2a:e7:1b:d5:ab:fb:8a:0c:99:
  	...
    c4:41
prime1:
    00:f4:e0:28:45:0d:a7:be:8d:c1:f8:1f:5a:2a:0e:
    ad:78:27:22:0d:94:bc:9f:c7:43:89:01:c5:07:f8:
   	..
prime2:
    00:de:18:34:3b:73:bc:61:93:e7:86:da:36:d0:33:
    ad:76:e8:23:bb:89:fc:1f:2e:59:60:fd:97:d1:27:
   ...
exponent1:
    6c:c0:c8:e1:b2:28:d7:96:39:99:2a:c3:6e:7e:4a:
    48:5c:88:e1:23:37:8a:76:82:e5:ec:25:47:5e:d5:
  	..
exponent2:
    54:63:92:05:3d:16:c9:64:ef:c6:77:c7:f8:18:8a:
  ..
coefficient:
    00:ee:2e:62:31:8d:09:ec:db:61:cc:34:87:4e:01:
    9d:7a:a8:23:3c:00:1e:2b:6e:79:b3:d1:c0:ad:3c:
	..
  • 可以看到，bank_key.pem除了包含公钥、私钥、模数的质因子，还包含一些数字，例如指数1、指数2和系数，这些数用来对解密进行优化的。
  • 为了从CA处获得公钥证书，银行需要创建一个证书签名请求，请求中包含银行的公钥与其身份的细节，请求中包含银行的公钥与其身份的司机，如机构的名称，地址与域名等，可以用下面的命令生成基于bank_key.pem的证书请求信息。
[07/20/20]seed@VM:~/.../demoCA$ openssl req -new -key bank_key.pem 
-out bank.csr -sha256
Common Name (e.g. server FQDN or YOUR name) []:bank32.com
  • openssl程序会要求提供主题信息，如公司名、地址、邮件等，在常用名CN域，使用bank32.com，把生成的证书签名请求保存在bank.csr中，这是一个经过编码的文件，可以允许下面命令查看该文件：
[07/20/20]seed@VM:~/.../demoCA$ openssl req -in bank.csr -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CN, ST=Henan, L=XINyang, O=bank, OU=bank, CN=bank32.com/emailAddress=125686568@qq.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d4:71:89:e6:0e:dc:f1:b4:05:25:fe:88:f4:6f:
                    9e:91:c9:9a:20:19:da:91:a3:58:7f:b0:00:d6:6e:
                    97:53:30:8f:bf:ca:bb:6d:af:8e:69:55:97:92:99:
                    73:1b:f9:8c:34:43:3a:d6:12:d6:14:03:6b:b5:2c:
                    19:9b:d2:ec:7a:1b:78:7b:e0:6e:05:90:44:7f:89:
                    08:8c:42:8e:af:90:95:df:dc:94:a6:c5:48:92:14:
                    de:09:b6:93:c4:a4:0c:19:31:2f:58:dd:25:4b:83:
                    da:c7:b8:ae:4a:f8:05:6d:9e:f9:76:76:0b:39:74:
                    bd:14:94:f7:8c:a1:c3:43:0b:40:05:3a:e5:d4:67:
                    09:89:5b:d3:ad:b2:bc:dc:5a:85:45:5a:a2:b0:32:
                    46:bd:1c:d0:96:7d:f2:7f:74:ae:36:d3:af:fc:ad:
                    1c:c6:36:c1:05:8e:37:a6:09:28:27:a7:91:a1:20:
                    71:4d:55:b6:59:d7:d3:6d:2e:a6:9c:ed:f7:37:6c:
                    d8:9e:10:02:34:69:ef:b8:7c:b1:51:bf:0f:58:a3:
                    85:44:57:a4:0e:27:0a:e7:40:cd:eb:81:36:dd:56:
                    7d:d7:4e:eb:c4:6a:41:89:cb:87:ec:4a:21:b5:68:
                    68:88:d5:4a:1b:d2:af:b2:17:6d:94:44:dd:13:0e:
                    e8:e7
                Exponent: 65537 (0x10001)
        Attributes:
            unstructuredName         :unable to print attribute
            challengePassword        :unable to print attribute
    Signature Algorithm: sha256WithRSAEncryption
         19:cc:98:6b:bc:3b:e7:f7:cf:9c:d2:b0:43:d7:37:94:10:99:
         d7:8a:b1:75:61:26:04:fe:46:a2:d8:96:39:40:3e:c5:0e:9b:
         d7:03:47:88:93:2f:a4:14:5c:27:19:70:db:33:c7:25:48:95:
         5e:e9:10:4a:09:51:35:3c:4f:45:dc:61:61:96:88:b4:a0:cf:
         dd:9c:89:43:4d:6d:f3:61:ff:b8:e0:22:97:9e:c7:04:5b:78:
         6e:51:71:b0:5a:15:eb:f4:c6:13:54:8d:2e:b0:15:0a:77:c2:
         4f:b2:f9:21:aa:2a:b2:be:ce:85:bb:fc:37:1f:de:39:e8:28:
         b8:1e:34:29:d4:16:0b:49:58:ee:74:7e:8d:74:a4:03:e6:25:
         e7:d3:c2:6a:83:fe:2c:62:5a:1a:ab:60:53:52:09:d1:60:2a:
         7d:4e:17:e7:c1:e4:00:16:69:aa:4f:69:3c:1c:e9:57:3e:0a:
         5d:da:31:65:e0:1b:47:6b:79:39:ef:18:e2:2c:ac:d5:5e:40:
         33:27:24:cc:1a:6f:a4:0d:3a:c2:bb:11:78:19:42:3e:cf:2a:
         f8:17:0e:f5:55:ef:1e:16:5b:38:aa:8d:6e:a1:91:e9:94:33:
         d2:8d:91:7a:7e:4d:21:9c:2d:cc:6c:c1:6b:de:71:39:6c:6a:
         28:83:36:20
  • 上面的证书签名请求中也包含一个数字签名，这个签名是由申请者用自己的私钥生成的，这个签名的目的是证明申请者的确知道请求中公钥所对应的私钥，通过校验这个签名，CA可以确信请求中的公钥的确属于申请者。
  • 在现实世界中，银行在提交CSR文件给CA，CA在验证完CSR中的信息后，会给银行签发一个X.509证书，在本模拟实验，省略了验证这一步，直接使用下面的命令来生成证书：
seed@VM:/home/seed/code/pki/demoCA$ openssl ca -in bank.csr -out bank_cert.pem 
-md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem 
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for modelCA_key.pem:
I am unable to access the ./demoCA/newcerts directory
./demoCA/newcerts: No such file or directory
  • 报错，显示没有newcerts这个目录，应该是文件路径解析出了问题，我们把配置文件复制到当前文件夹下，修改dir=./demoCA为dir=./，然后指定该文件为配置文件：
seed@VM:/home/seed/code/pki/demoCA$ openssl ca -in bank.csr -out bank_cert.pem 
-md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem -config openssl.cnf 
Using configuration from openssl.cnf
Enter pass phrase for modelCA_key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4096 (0x1000)
        Validity
            Not Before: Jul 20 07:16:05 2020 GMT
            Not After : Jul 20 07:16:05 2021 GMT
        Subject:
            countryName               = CN
            stateOrProvinceName       = Henan
            organizationName          = bank
            organizationalUnitName    = bank
            commonName                = bank32.com
            emailAddress              = 125686568@qq.com
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                F6:ED:8E:BA:02:57:30:30:5C:F3:5A:73:86:D8:4D:62:34:09:78:3D
            X509v3 Authority Key Identifier: 
                keyid:7A:4D:24:90:8F:48:52:A6:F4:C8:B4:B0:38:AC:27:C7:98:9C:69:7E

Certificate is to be certified until Jul 20 07:16:05 2021 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  1. 在网络服务器中部署公钥证书
  • 一旦银行收到数字证书，他就可以在HTTPS网站中部署该证书，为了使用openssl自带的服务器，需要将银行的私钥文件和公钥证书合并到一个文件中，然后使用命令启动服务器，服务器监听4433端口：
[07/20/20]seed@VM:~/.../demoCA$ cp bank_key.pem bank_all.pem
[07/20/20]seed@VM:~/.../demoCA$ cat bank_cert.pem >> bank_all.pem 
[07/20/20]seed@VM:~/.../demoCA$ openssl s_server -cert bank_all.pem -accept 4433 -www
Enter pass phrase for bank_all.pem:
Using default temp DH parameters
ACCEPT
ACCEPT
ACCEPT
  • 上述opensll命令启动一个HTTPS网站服务器，为了可以通过https://bank32.com访问该服务器，需要添加条目到客户端的/etc/hosts文件中，从而将主机名bank32.com映射到网站服务器的IP地址，为了方便实验，网站服务器在本机，及127.0.0.1.
    在这里插入图片描述
  • 使用火狐浏览器访问，显示这个连接不安全，这是因为浏览器没有modelCA的公钥，因此它们不能验证银行证书中的签名，浏览器有一个它信任的CA列表，但是很明显，ModelCA不在列表中，如果CA是不可信的，那么CA签发的证书也是不可信的。
  • 为了进入信任列表，需要让浏览器开发者认为ModelCA是可信的CA，火狐浏览器允许用户手动添加CA证书到它的信任列表中。
    在这里插入图片描述
  • 添加完成之后，再次访问https://bank32.com:4433浏览器不再显示错误，能成功接收到来自服务器的响应。
    在这里插入图片描述
  • 除了使用浏览器，也可以使用openssl s_client命令访问网络服务器，这个命令可以输出大量调试信息，这对于观察客户端域服务器之间的交互相当有帮助：
[07/20/20]seed@VM:~$ openssl s_client -connect bank32.com:4433
CONNECTED(00000003)
depth=0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify error:num=21:unable to verify the first certificate
  • 因为客户端程序无法获得签发者ModelCA的证书，所以它不能验证bank32.com的证书，使用-CAfile选项告诉客户端程序ModelCA的证书。
[07/20/20]seed@VM:~/.../demoCA$ openssl s_client -connect bank32.com:4433 -CAfile modelCA_cert.pem 
CONNECTED(00000003)
depth=1 C = CN, ST = Henan, L = xinyang, O = bank, OU = bank, CN = bank, emailAddress = bank@qq.o\08co
verify return:1
depth=0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify return:1
---
  1. 使用Apache部署HTTPS
  • 为了建立一个HTTPS网站，只需配置Apache服务器，让它知道从哪里得到私钥和证书即可，添加下面的VirtualHost条目到Apache服务器配置文件default-ssl.conf中：
<VirtualHost _default_:443>
                ServerName bank32.com
                DocumentRoot /var/www/html
                DirectoryIndex index.html

                SSLEngine On
                SSLCertificateFile /home/seed/code/pki/demoCA/bank_cert.pem
                SSLCertificateKeyFile /home/seed/code/pki/demoCA/bank_key.pem
        </VirtualHost>
  • ServerName指定网站的URL，DocumentRoot指定网站文件的存放位置，还需要把公钥证书和私钥的文件名告诉Apache服务器，修改完Apache服务器，需要运行以下命令启动SSL，一旦部署成功，此时所有服务器与浏览器之间的流量都将被加密。
[07/20/20]seed@VM:~/.../demoCA$ sudo apachectl configtest
AH00112: Warning: DocumentRoot [/var/www/seedlabclickjacking] does not exist
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
[07/20/20]seed@VM:~/.../demoCA$ sudo a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  service apache2 restart
[07/20/20]seed@VM:~/.../demoCA$ sudo a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  service apache2 reload
[07/20/20]seed@VM:~/.../demoCA$ sudo service apache2 restart
Enter passphrase for SSL/TLS keys for bank32.com:443 (RSA): ****

根与中间CA

  1. 根CA和自签名证书
  • 为了验证根CA签发的证书，需要有根CA的公钥，问题是如何安全的获取它，因为中间人攻击的问题，不能要求根CA把它的公钥发给用户，或通过其他人发给用户。
  • 根CA的公钥通常通过一些特殊渠道分发给用户，它们被预装进操作系统、浏览器或者其他软件，这些软件为根CA的公钥进行担保，只要信任这些软件，那么也就信任了这些软件伴随而来的公钥。
  • 根CA的公钥也存储在一个X.509证书中，但是这个证书并没有被其他CA签名，而是自签名，在自签名的X.509证书中，证书签发者和拥有着是同一个实体。
  • 根CA可以将证书签发功能委派给其他信任的中间CA，然而这些中间CA的公钥不一定被外界所知，因此根CA必须为它们的公钥进行担保，也就是为了中间CA签发公钥证书，这样中间CA才可以为其他用户签发证书。
[07/20/20]seed@VM:~/.../demoCA$ openssl s_client -showcerts -connect www.alibaba.com:443

---
Certificate chain
 0 s:/C=CN/ST=ZheJiang/L=HangZhou/O=Alibaba (China) Technology Co., Ltd./CN=*.alibaba.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
MIImajCCJVKgAwIBAgIMGEmABohi7zhwIKNtMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMjAwNzA5MDIyMjAyWhcNMjEwMzE3MDYwNDU3WjB6MQswCQYDVQQGEwJD
TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
...
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
...
-----END CERTIFICATE-----
  • 以上结果显示来自alibaba.com的所有证书，其中包含两个证书，第一个是Alibaba公司的证书，它是由名为GlobalSign Organization Validation CA - SHA256 - G2的CA签发的，这是一个中间CA。第二个整数是该中间CA自己的证书，它是由另一个名为GlobalSign Root CA，这是一个根CA。
  • 客户端会通过以下步骤验证Alibaba公司证书：
    1. 检查根CA是否存在浏览器的信任列表中，如果在，说明浏览器已经有了根CA的公钥。
    2. 用根CA的公钥验证中间CA的证书。
    3. 用中间CA的公钥验证Alibaba公司的证书。
  • 可以用openssl手动验证证书链，将Alibaba公司的证书保存为文件Alibaba.pem,将中间CA的证书保存为文件GlobalSign-G2.pem。从浏览器中获得GlobalSign Root CA的自签名证书，并将它保存为Global SignRootCA.pem，然后运行下面的命令验证Alibaba公司的证书。
$ openssl verify -verbose -CAfile GlobalSignRootCA.pem -untrusted GlobalSign-G2.pem
Alibaba.pem
  • 选项-untrusted提供了一个证书链，该链的最后一个元素必须是域名服务器的证书，-CAfile选项提供了一个可信任的CA证书，把根CA的证书放在这里，它被用来验证证书链中的第一个证书，在验证完第一个证书后，第一个证书中的公钥来验证第二个证书，以此类推，如果整个证书链被成功验证，OK将被打印出来。
  1. 为中间CA制作证书
  • 一个CA可以用openssl为中间CA签发证书，中间CA也需要生成一个证书请求（modelIntCA.csr),并将请求发送到一个可信CA，这个CA根据请求，用下面的命令生成一个证书：
#中间CA生成自己的公钥和私钥
[07/20/20]seed@VM:~/.../demoCA$ openssl genrsa -aes128 -out modelIntCA_key.pem 2048
#中间CA生成公钥证书请求
[07/20/20]seed@VM:~/.../demoCA$ openssl req -new -key modelIntCA_key.pem -out modelIntC
A.csr -sha256
#根CA给中间CA颁发公钥证书
[07/20/20]seed@VM:~/.../demoCA$ openssl ca -in modelIntCA.csr -out modelIntCA_cert.pem -md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem -extensions v3_ca -config openssl.cnf
  • 上面的证书签发命令与签发服务器证书的命令基本相似，但它包含了一个-extensions v3_ca选项，这个选项会让openssl将证书拓展项中的CA字段设置为TRUE，该字段指明这个证书是否能来验证其他证书。
  • 非CA证书的CA字段的值是FALSE，表示这个证书不能用来验证其他证书，也就是该证书的拥有者不能充当一个CA，如果非CA证书的拥有者为一些实体签发了证书，这些证书将无法被验证，因为签发者的证书不是一个CA证书。
  1. Apache服务器的部署
  • 如果网络服务器的证书是由中间CA颁发的，当客户端请求它的证书时，它应该给出所有涉及中间CA的证书，这些证书都应该放在一个文件中，并在Apache服务器配置文件default-ssl.conf的SSLCertificateFile条目中表明文件名：
 <VirtualHost _default_:443>
                ServerName bank32.com
                DocumentRoot /var/www/html
                DirectoryIndex index.html

                SSLEngine On
                SSLCertificateFile /home/seed/code/pki/demoCA/bank_cert2.pem
                SSLCertificateKeyFile /home/seed/code/pki/demoCA/bank_key.pem
        </VirtualHost>
  • 注意此时的bank_cert2.pem中应该包括两个公钥证书，第一个是bank32的，第二个modelIntCA的，二者顺序不能颠倒。
  1. 获取google浏览器的可信CA。
  • 进入settings页面，输入管理证书。
    在这里插入图片描述

防御中间人攻击

  • 假设Alice想要用HTTPS访问example.com，她在浏览器中输入https://example.com，浏览器会与example.com服务器执行一个SSL握手协议，该服务器会返回它的证书，当存在一个中间人攻击时，攻击者可以拦截此握手协议。攻击者可以做以下几件事：
    1. 攻击者转发真实证书
    • 如果攻击者转发来自eaxmple.com的真实证书给用户Alice，这个证书将通过验证，Alice的浏览器将用证书中的公钥加密一个密钥，由于攻击者不知道相应的密钥，他们将不会能解密被加密的密钥，这个密钥会用来在Alice与服务器之间建立一个SSL会话，一旦会话建立，攻击者就无法在做什么。
    1. 攻击者制作假证书
    • 攻击者可以伪造一个example.com的证书，但是其中存放的是自己的公钥，没有任何一个CA会签发这样的证书，因为攻击者不是example.com的合法拥有者。
    • 攻击者也可以自己为假证书签名，创建一个自签名证书，然而， 当Alice的浏览器接收到一个证书时，它会把该证书当成一个根CA的证书，但这个假的根CA证书并不被浏览器所信任，浏览器将显示警告，并让用户决定是中断连接还是继续访问，如果用户选择中断连接，该攻击将失败；如果用户忽视警告并继续访问，攻击将成功。
    1. 攻击者发送自己的证书
    • 攻击者也可以发送自己的合法证书给Alice，在这个证书Subject域不能是example.com，因为攻击者不拥有example.com，攻击者只能在Subject域放入自己的合法身份（例如attacker32.com），一旦该证书到达Alice的浏览器，浏览器将用已经预装的可信证书区验证它，这个验证将通过，因为攻击者的证书是有效的，但这里还会有一个附加的验证。
    • 浏览器需要知道证书的Subject域中的域名是否与用户的目的相同，注意Alice在浏览器中输入的是https://eaxample.com，因此浏览器知道Alice的目的是访问example.com，但是证书的Subject域是attacker32，这个不匹配导致浏览器立即中断握手协议。
  • 在SSL握手期间，浏览器会进行两个重要的验证，第一个验证是核对接收到的证书是否有效，一个有效的证书能确保证书中公钥属于Subject域描述的主体，但是不能说明这个主体是否是用户想要访问的网站。第二个验证的目的，它检查的通用名称域是否域网站名一致。
  • 在用户和HTTPS网站通信中可以插入中间人的，这种中间人叫HTTPS代理，它可以截获并检测浏览器与服务器之间的HTTPS流量，这是一个实实在在的中间人攻击。
  • HTTPS代理它为用户访问的每一个HTTPS网站创建一个假证书，假证书是由HTTPS代理签发的，显示，浏览器不能验证这些假证书，因为它没有HTTPS代理的公钥，但如果将HTTPS代理的证书添加到浏览器的信任列表，浏览器就有了HTTPS代理的公钥，并把它当成一个根CA来看待，用它来验证所由它签名的证书，因为用户自愿把HTTPS代理当成可信任的根CA，因此HTTPS代理并不算是攻击者。

在公钥基础设施上实施攻击

  1. PKI依赖的4个关键性校验和安全保证：
  • CA的认证：为了抵御中间人攻击，对于客户端来说，知道接收到的公钥是否属于目的服务器很重要，由于不能相信公钥拥有者声称的所有者信息，因此不得不依赖于第三方CA获知公钥的实际拥有者。
  • 证书的安全：一旦CA验证了公钥拥有者的身份，CA将为这个拥有者生成一个证书，证书一定不能被修改，这是由单向哈希值和数字签名算法保证的。
  • 预加载的可信证书的验证：证书的完整性是由CA的签名保护的，为了验证这个签名，需要CA的公钥，这个公钥要么被客户端预加载，要么由另一个CA的签名保护，只有可信的公钥才会被预加载。
  • 用户确认：客户端需要确认证书中的Subject域与用户想访问的目的地一致。
  1. 对CA认证过程的攻击
  • CA的作用是确认公钥属于一个特定的主体，它的工作分为两部分：1.验证证书申请者与证书Subject域中主体之间的关系。2. 对证书做签名。
  • 如果CA在主体认证上没有做好工作，或者验证过程不安全，攻击者就能够获得一个伪造的证书，证书中存放的是攻击者的公钥，但Subject域缺失攻击目标的域名，有个这个假证书，攻击者可以针对目标网站实施中间人攻击。
  1. 对签名过程的攻击
  • 一旦CA验证了证书请求的Subject域，它会用私钥签发证书，如果CA的私钥被泄漏，攻击者可以签发一个Subject域为任意数据的证书，这会生成有效但虚假的证书。
  • CA的私钥不应该暴露出来，大部分CA把私钥存在特殊硬件设备中，这些设备是防篡改的，而且需要物理接触才能得到密钥，它一般存储在受着严密监视和保护的地方。
  1. 对算法的攻击
  • 数字证书依赖域两种类型的算法：单向哈希函数和数字签名。证书的签名实际上是对证书的单向哈希值进行签名，一个好的单向哈希函数应该有两个属性：单向属性和抗碰撞属性。抗碰撞属性确保很难找到两个内容不同但有相同哈希值的消息。
  • 抗碰撞性弱的算法，攻击者可以准备两个版本的证书请求，版本A的Subject域存放example.com，版本B的Subject域存放attacker32.com，这两个证书虽然内容不同，但可以生成相同的哈希值，因为攻击者不拥有example.com，所以如果攻击者给CA发送版本A，CA将不会签署该请求，但是如果攻击者发送版本B，CA会签署该请求，因为签署用的只是哈希值，再版本B上签名其实也是在版本A上签名
  • 当CA在给证书签名时，CA可以增加一些不可预测的数据，例如序列号，使得攻击者不大可能实现准备两个内容不同但哈希值相同的证书。
  1. 对用户确认的攻击
  • 在验证服务的证书后，客户端能够确信证书是有效的并且证书的名称是认证过的，但是客户端不知道该实体是否是用户想要交互的对象。因此这里需要一个用户确认的过程。

数字证书类型

  1. 域名验证型证书
  • 对于DV证书来说，CA验证域名记录以核对域名是否属于申请者，这个过程一般称为域控制验证（DCV），是通过WHOIS（一个在线存储域名注册信息的资料库）中获取的信息来验证包含证书请求中的域名。
  • DCV一般使用下列方法：
    1. 通过电子邮件：CA首先获取证书请求中域名注册的邮箱，然后发送一封邮件给这个邮箱，这封邮件包含一个链接，如果它被点击，域名验证就通过了，即CA相信申请者的确拥有该域名。
    2. 通过HTTP：在这个方法中，CA把证书请求的哈希值发给申请者，申请者应该创建一个以哈希值命名的文件，并把该文件放在请求域名的网络服务器中。
    3. 通过DNS：在这个方法中，CA把证书请求的哈希值发给申请者，申请者需要在请求域名的DNS服务器中增加一条CNAME记录，CNAME记录的值就是该哈希值。
  1. 机构验证型证书
  • 出了验证域名外，还需要验证：
    1. 域名控制验证
    2. 申请者的身份和地址
    3. 申请者和机构的关系
    4. 机构的地址
    5. 机构的WHOIS的记录
    6. 机构的电话号码
  1. 拓展验证型证书
  • 需要验证：
    1. 域名控制验证
    2. 验证证书请求中涉及的身份、机构、签名以及和申请者直接的关系
    3. 验证组织的物理地址和电话号码
    4. 验证组织实际业务的存在性，确保机构知道申请日期还在开展业务
    5. 验证机构合法性，确保机构过去没有非法或不良记录。
  • 浏览器通常维护一个单独的、可以验证EV证书的列表，一个CA想要称为EV-compliant列表的一部分，他必须要遵循所有标准，对它的基础设施实行严格的安全保护，而且需要第三方审计向浏览器供应商证明它的安全性。