了解公钥基础结构

描述

证书将标识符与公钥安全地绑定在一起。当计算机请求访问网络资源时,将根据计算机的标识授予访问权限。借助证书,访问控制代理可以通过验证证书的签名来检测请求计算机的身份是否被伪造或篡改。但是,仅提供有效的证书是不够的,因为其他人很容易捕获并使用它。访问控制代理还必须通过质询-响应身份验证控制请求计算机是否真正知道与播发证书中的公钥匹配的私钥。该过程完全证明了计算机的身份,因为私钥永远不会透露给其他计算机。

现在,让我们解决证书信任的启用问题。证书颁发机构是相互信任的第三方,可实现这种信任。证书颁发机构 (CA) 有两种类型:封闭网络上的私有 CA 和互联网上的公共 CA。公共 CA 通过在互联网上建立信任来开展业务。如果他们碰巧错误地颁发证书,他们将不信任并被排除在业务之外,因此他们往往会做得很好。私有 CA 由公司的IT 部门维护。他们的作用是为公司资产颁发证书。根据定义,这些 CA 必然是受信任的。

CA 正在颁发证书。证书颁发是计算机注册过程的一部分,其工作原理如下:

请求者(要注册的计算机)已经拥有公钥和相应的私钥,如博客 1 中所述

证书申请者生成“CSR”,又名证书签名请求。CSR 包含请求者的声明身份(计算机名称、IP 地址、服务器 URL)及其公钥。CSR 是使用请求者的私钥“自签名”的。

CA 确保请求者的身份(此过程取决于颁发策略)

CA 从 CSR 创建证书(与 CSR 的内容基本相同,具有 CA 标识和其他技术信息等附加属性,以帮助解释证书本身)

CA 使用 CA 的私有签名密钥对证书进行签名,并将签名附加到证书

证书的使用者现在可以使用 CA 证书中找到的 CA 公钥来验证其有效性。如果数字签名有效,则表示身份和公钥已由受信任的 CA 正式验证。

下图 [2] 描述了 x.509 证书的外观。它是包含技术数据的一系列字段。我们可以清楚地看到颁发者的身份、证书持有者的身份以及 CA 颁发的数字签名。

计算机

相同的证书 [2],以二进制 (DER) 格式编码:

计算机

现在,让我们看一个 Web 服务器的证书颁发策略示例。当公司需要为其 Web 服务器“www.server.com”提供证书时,他们可以通过向 CA 发送 CSR 从公共 CA 请求证书。CA 将要求 Web 服务器所有者在服务器的根目录下存放一次性使用令牌(包含随机值的文件)。服务器的合法所有者可以通过使用文件传输协议(FTP)等方式对Web服务器的内容进行特权访问来做到这一点。假设流氓玩家不能这样做。然后,CA 尝试从“www.server.com”获取此特殊文件。如果成功,则证明CSR来自服务器的合法所有者,并颁发证书。否则,不会颁发证书。因此,没有其他人可以声称“www.server.com”身份。

显然,如果网络中的所有计算机希望在相互通信时能够相互验证其证书,则必须信任相同的 CA。这意味着他们必须使用相同的 CA 证书来验证彼此的证书。事实上,CA 证书是自签名的(实际的 PKI 可能是相互认证的 CA 级联,但让我们暂时跳过它)。因此,CA 证书本质上必须是受信任的,因为它们没有经过父 CA 的认证(这将是一个永无止境的问题:谁在认证父 CA?因此,CA 证书必须安全地安装到计算机中,使其不能被任意修改。在 Windows 等操作系统上,CA 证书存储是一个安全组件,需要特殊权限才能修改。同样,在嵌入式设备中,CA 证书必须存储在具有严格写入访问控制的内存中。大多数情况下,CA 证书是预装的,不容易修改。并且存储必须不受恶意软件的影响。如果恶意 CA 可以将其 CA 证书注入计算机,则还可以颁发恶意标识。受恶意 CA 证书感染的计算机将信任这些恶意身份。对于简单的嵌入式设备,大多数情况下,将为受控制造环境中的每个设备生成证书,并与CA证书一起存储在设备中。部署后,所有这些设备将相互接受,因为它们共享相同的 CA 并拥有该 CA 颁发的证书。

总之,相互信任的 CA 与相互接受的证书颁发策略相结合,允许相互不受信任的各方相互进行身份验证。

审核编辑:郭婷

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分