第14讲 PoP检查.pptVIP

PKI技术 回顾 一般情况下，用户的密钥都是自己生成 用户只将公钥交给CA 公钥?CA 经过传输介质 可能是网络、文件CopyPaste等 或者经过了RA 有没有可能出现问题？ 公钥传输可能出现问题 传输错误 公钥信息的错误，不能被人工检测到 不像其他信息 例如，名字和工作单位的错误，操作员可以看出来 对于操作员，公钥信息是随机bit串，无法检查 公钥在传输的中间过程被人替换 操作员也是无法检查的（随机的01 bit串） 第三方生成 密钥也有可能是由第三方代为生成的 一般，就是密钥管理机构 私钥只有订户和密钥管理机构知道 CA不知道，CA如何确定订户拥有私钥？ 同样，公钥有没有可能被替换？ 或者说，订户真的拥有相应的私钥？ 密钥管理中心的分发失误 混淆了2个不同的订户 如何检查到？ POP Proof of Possession (POP) of Private Key 私钥的拥有证明 证明订户拥有“其提交的公钥相对应的私钥”的证据 注意： 该证据不能泄漏私钥信息 该证据不能损坏订户利益 CA在签发、发布证书之前，应该进行POP检查 前提是：CA不允许知道用户的私钥 各种POP的方式（密钥用途不同） PKCS#10格式 签名密钥Signature Key 加密密钥Encryption Key 密钥协商密钥Key Agreement Key PKCS Public-Key Cryptography Standards PKCS RSA公司制定的一系列标准 PKCS#10 Certification Request Syntax Standard 一种证书请求的数据格式 订户用来向RA/CA请求证书 PKCS#10 利用PKCS#10数据格式，可以实现POP检查 目前的版本是V1.7 PKCS#10消息 请求者给出 Name－X.500 DN 公钥信息 使用自己的私钥对其请求消息进行签名 注意：这时候订户还没有证书 并且按一定的格式编码 如图 PKCS#10消息的使用 PKCS#10 RA/CA使用用户提交的公钥来检查其PKCS#10消息中的签名是否有效 有效，则认为用户拥有相应的私钥 拥有私钥才能够产生签名 无效，POP检查失败 PKCS#10消息格式 就是经过签名的数据 具体信息在certificationRequestInfo中 验证签名时，要从certificationRequestInfo获得subjectPublicKeyInfo PKCS#10的特点 只能用于签名算法密钥 因为必须进行签名操作 虽然目前常用的公钥算法都能同时用于签名和加解密，问题仍然需要考虑 也有可能是设备的限制 带有的信息不够多 只有Name和Public Key 其他信息要以Attribute方式（如用户希望的有效期） 因为PKCS#10是1次传输的，不能对付攻击者将密钥替换（要使用安全信道传输） 如下图 替换攻击 如图，攻击者在中间替换 CA/RA的POP检查仍然正确 PKCS#10消息的传输 要有安全的信道，如 使用CA证书加密 其他的POP方式 因为PKCS#10格式的缺点，出现了其他方式的POP检查方式 但，PKCS#10仍然是非常流行的 历史原因 PKCS#10出现的时间很早 RSA公司的影响力 格式简单 过程简单 不需要多次来回消息 各种POP的方式（密钥用途不同） PKCS#10格式 签名密钥Signature Key 加密密钥Encryption Key 密钥协商密钥Key Agreement Key 签名密钥 签名密钥的POP是相对简单的 要求订户在证书请求消息中进行签名 会要求对更多的内容进行签名 参考RFC 2511 Internet X.509 Certificate Request Message Format 直接要求申请者对申请消息进行数字签名 原理上，和PKCS#10类似 只是“被签名的数据”的格式不一样 同样的问题 同样也有PKCS#10的问题 替换攻击 所以，应该要求信道本身是可靠的 或者是面对面的传递 各种POP的方式（密钥用途不同） PKCS#10格式 签名密钥Signature Key 加密密钥Encryption Key 密钥协商密钥Key Agreement Key 加密密钥 直接方式 在签发证书前，CA/RA生成随机的挑战信息，使用订户的“未被证实”的公钥加密，发送给要求订户解密 如果订户能够正确解密 拥有相应私钥 CA签发证书，并发布 间接方式 加密密钥 直接方式 间接方式 CA不做检验，直接签发订户证书 使用订户公钥，对证书加密，发送给订户 订户响应明文形式的、自己的证书 RA/CA在资料库上发布订户证书 间接方式 很适合于密钥管理机构的方式 CA从密钥管理机构得到公钥 从订户得到其他信息 签发