学习笔记9

第18章 PKI之梦

18.1 PKI的简短回顾

• PKI是公钥基础设施（Public Key Infrastructure）的缩写，通过它可以知道哪个公钥属于谁。
• 证书机构（Certificate Authority），简称CA，用自己的私钥对证书签名，通信方使用CA的公钥对证书进行验证。

18.2 PKI的例子

18.2.1 全局PKI

• 我们设想构建一个庞大的PKI，每个用户仅仅需要得到一次证书。
• 但是这样的全局PKI是几乎不可能实现的。

18.2.2 VPN访问

• VPN（Virtual Private Net）允许用户远程访问内部网络。VPN的访问接入点必须能识别访问网络的人以及他们有何种确切的访问级别，这一点可以通过证书验证的方式来实现。

18.2.3 电子银行

• 银行允许它的客户在银行网站上进行金融交易。银行本身就是CA，它能认证客户的公钥。

18.2.4 炼油厂传感器

• 炼油厂是相当复杂的，为保证传感器数据的准确性，公司可以作为CA，为所有的传感器建立PKI，使得每个传感器都能被控制室识别。

18.2.5 信用卡组织

• 信用卡组织是遍布世界的数千个银行之间的合作组织。所有这些银行必须能够交换支付，因为在银行A有信用卡的用户必须能把钱付给在银行B开户的商家。银行A与银行B需要以某种方式处理这一交易，而且需要进行安全的通信。采用PKI就可以让所有的银行彼此识别身份以进行安全的交易。在这种情况下，信用卡组织就是CA，给每个银行颁发证书。

18.3 其他细节

18.3.1 多级证书

• 在很多情况中，CA被分成多个层级。例如，信用卡的中心组织不直接给每个银行发行证书。相反，它们有区域性机构来管理银行，这样我们就得到了一个两级的证书结构。中心CA签署一个关于区域CA公钥的证书，就好像说，密钥PK_x属于区域机构X，它可以用来证明其他密钥。然后每个区域机构就能够认证银行密钥。银行的密钥证书包含两个签名的消息：中心CA证实区域机构密钥的授权消息和区域机构关于银行密钥的认证。这样的结构叫作证书链，这样的链可以扩展到任意多级。
• 这样的多级证书结构作用巨大。它本质上把CA的功能分割成层级结构，这样的层级结构对于大多数组织来说是很容易处理的。几乎所有的PKI系统都有多级结构。这种结构的一个缺点是证书体积变得更大，需要更多的计算来进行认证。不过大多数情况下这种开销是相对小的。另一个缺点就是加入系统的每个CA都会带来新的攻击点，因此降低了整个系统的安全性。
• 对于上述这些缺点，一个尚未应用于实践的解决办法是打破证书的层级结构，这样的话，加入额外层级结构的性能代价就会变得很小。但是加入额外层级也许并不是一个好主意，多级结构的效率并不是很高。

18.3.2 有效期

• 几乎所有的证书系统都包含有效的日期和时间。过了这个日期时间之后，没有人应该接受这个证书。这就是PKI参与者需要时钟的原因。
• 很多证书的设计还包含其他数据。通常，证书中除了有有效时间，还有有效的起始时间。有的还包含证书的不同类别、证书序列号、发行日期和时间等。

18.3.3 独立的注册机构

• 要实现独立的注册机构有两种好的解决方案：
  • 第一种是使用多级证书结构，让HR部门成为子CA，这就自动地提供了必需的灵活性来支持多站点。
  • 第二种解决方案与第一种很相似，只是一旦用户有了两级证书，他就能从中心CA得到一级的证书。通过把双消息协议加入系统，可以消除每次检查两级证书的额外开销。

第19章 PKI的实现

19.1 名字

• 在PKI中，如何为每个用户分配名字是一个重要的问题。
• 这也说明了小范围特定应用的PKI比某个大型PKI工作得更好。

19.2 授权机构

• 无论何时规划一个PKI，都必须考虑授权谁来发行证书。
• 但是对于全局PKI来说，似乎没有一个权力的来源，这也是全局PKI不能奏效的一个原因。

19.3 信任

• 在PKI中，CA的可信度是最关键的。
• 世界上没有一个组织能得到所有人的信任，甚至没有一个组织能得到大多数人的信任，因此永远不会有全局PKI。由这个逻辑推出的结论就是，我们将不得不使用大量小型的PKI。
• 被CA使用的信任关系都是已经存在的，而且是建立在合同关系基础上的。

19.4 简介授权

• 大多数PKI的授权系统采用访问控制列表ACL来实现。
• 在ACL中，有三个不同的对象：密钥、名字、做某事的许可权。系统想要知道的是哪个密钥授权哪种行为，换句话说，特定的密钥是否有特定的许可权。一般的PKI通过把名字和密钥绑定以及用ACL把名字和许可权绑定来解决这一问题。但是这个做法引入了额外的攻击点：
  • 第一个攻击点是PKI提供的名字-密钥证书，
  • 第二个攻击点是绑定名字和许可权的ACL数据库，
  • 第三个攻击点是名字混淆。

19.5 直接授权

• 更好的解决方案是直接用PKI把密钥与许可权绑定，证书不再连接密钥和名字，它连接密钥和许可集合，它们只看所提供的证书和密钥是否有相应的许可权，这既直接又简单。
• 直接的授权从授权过程中去掉了ACL和名字，因此排除了上面的攻击点。
• 但是仍然不可以在证书中把关于名字的信息去掉。

19.6 凭证系统

• 凭证系统，也就是密码学家所说的超级PKI，基本的要求是，对于你做的每件事情要以签署证书的形式给出凭证。如果Alice有允许她读写一个特定文件的凭证，她就能部分或全部将授权委托给Bob。
• 例如，她可以为Bob的公钥签署一个证书，上面标明“密钥PK_Bob通过PK_Alice的授权可以读文件X”。如果Bob想要读文件X，他就要提交这个证书和Alice有权限读文件X的证明。
• 凭证系统能加入额外的特性。Aice能通过在证书中包含有效期来限制授权的有效期。Alice也可以限制Bob，使其不能将读文件X的权限再委托给他人。
• 凭证系统虽然强大，但是有以下几个原因：
  • 凭证系统是很复杂的，会带来显著的额外开销。访问一个资源的授权也许要依靠数个证书组成的证书链来完成，而且每个证书都要被传递和检查。
  • 凭证系统会引起访问权限的细化管理。
  • 需要开发一种凭证和委托语言（credential and delegation language）。
  • 具体的授权委托对于用户而言过于复杂。
• 但是在分层CA中，凭证是有用而且必需的：中心CA签署关于子CA密钥的证书，如果这些证书不包含任何限制，那么每个子CA就都有无限的权利。这是很差的安全设计。

19.7 修正的梦想

• 首先，每个应用都有自己的PKI和自己的CA。全世界包含了大量的小型PKI，每个用户同时是许多不同PKI的成员。
• 用户对于每个PKI必须使用不同的密钥，这可能需要很大的存储空间。
• PKI将密钥同凭证绑定在一起。用户许可权的重大改变会要求发行新的证书。证书中仍然要包含用户的名字，但这主要是为了管理和审计的目的。

19.8 撤销

• 在PKI中，撤销是最困难的问题。因为在撤销时，证书可能已经在很多地方使用并存储，会引发一系列影响。
• 撤销的需求主要由4个变量决定：
  • 撤销的速度：撤销命令发出与最后一次使用证书之间所允许的最大间隔时间是多少？
  • 撤销的可靠性：在某些情况下撤销不是完全有效的，这可以接受吗？什么样的遗留风险是可以接受的？
  • 撤销的数目：撤销系统一次能处理多少撤销请求？
  • 连接性：验证证书的过程是否为在线验证？
• 对于撤销问题有三种可行的解决方案：撤销列表、短有效期以及在线证书验证。

19.8.1 撤销列表

• 撤销列表（certificate revocation list），或称CRL，是一个包含撤销证书列表的数据库，每个验证证书的人都必须检查CRL数据库，看看那个证书是否已经被撤销。
• 中心CRL数据库有很好的性质，撤销几乎是瞬时完成的。一旦证书被加入CRL，就没有交易能被授权了。撤销也是很可靠的，能撤销多少证书并没有一个直接的上限。
• 但中心CRL数据库也存在一些重大不足，任何人都必须始终在线才能够检查CRL数据库。CRL数据库还引入了一个故障点（point of failure）：如果它不可用，就无法完成任何任务。
• 一种可选方案是采用分布式CRL数据库。可以用分布在世界各地的很多服务器来建立冗余的镜像数据库，并寄希望于它足够可靠。但是这样的冗余数据库的建立和维护代价都非常大，因此一般情况下不予采用。
• 还有一些系统只是把整个CRL数据库的副本送到系统的各个设备上，这是很容易做到的。可以让每个设备每隔半小时左右从web服务器上下载更新的CRL，这是以增加撤销的时间为代价的。然而，这种解决方案限制了CRL数据库的大小。

19.8.2 短有效期

• 可以使用短有效期来代替撤销列表，这可以利用已经存在的有效期机制来完成。CA只发行有效期很短的证书，时间范围是从10分钟到24小时。每当 Alice想用她的证书时，她会从CA出得到一个新的证书。只要它是有效的， Alice就可以一直使用。确切的有效期间隔能够根据应用的需求进行调整。
• 这个方案的主要优点在于，它使用的是已经可用的证书发行机制，不需要独立的CRL，这大大降低了整个系统的复杂性。为了撤销许可，你要做的仅仅是告诉CA新的访问规则。

19.8.3 在线证书验证

• 另外一种解决方法是在线证书验证。在线证书状态协议（Online certificate Status Protocol, OCSP）中已经包含了这一方法，并且在一些领域（例如web浏览器）中已经有了很大的进展。
• 为了验证一个证书， Alice将证书的序列号提交给一个可信方（比如CA或者经过委托的机构）进行查询，然后可信方在它自己的数据库中查询证书的状态，并发送一个经过签名的答复给Alice。Alice已知可信方的公钥，所以可以验证答复的签名，如果可信方认为证书是有效的，那么Alice就可以知道证书并没有被撤销。
• 在线证书验证有一些很好的性质。和CRL一样，撤销几乎是瞬时的，也是可靠的。同样，在线证书验证的一些缺点和CRL也是一样的。Alice验证证书时必须在线，并且可信方也成为一个故障点。
• 一般而言，相比于CRL，我们更青睐在线证书验证。在线证书验证避免了大量发布CRL的问题，也避免了客户端解析和验证CRL。因此，在线证书验证协议的设计，会比CRL更加简洁和具可扩展性。
• 然而在大多数情况下，在线证书验证不如短有效期方便。在线证书验证中，如果没有可信方的签名，我们就不能信任密钥。如果将签名看作一个新的关于密钥的证书，那么就相当于个使用了非常短的有效期的系统。在线证书验证的不足在于每一个验证者都必须向可信方进行查询，而在短有效期中，证明者可以对许多验证者使用同一个CA签名。

19.8.4 撤销是必需的

• 虽然撤销是难以实现的，但是在PKI系统中，必须要具备撤销的功能。

19.9 PKI有什么好处

• PKI相比密钥服务器系统的优势：
  • 密钥服务器需要每个人实时在线。如果不能连接到密钥服务器，就什么事都做不了。而在PKI中，如果使用撤销有效期，那就需要同中心服务器联系，对于使用有几个小时有效期的证书应用来说，实时在线访问和处理的需求就放宽了许多。即便使用CRL数据库，在CRL数据库不能连接时也会有规则说明怎样继续操作。
  • 密钥服务器是一个故障点。分布密钥服务器比较困难，因为它包含了系统的所有密钥。反过来，由于CRL数据库少了一些安全要求，因此更容易分布。短有效期方案使CA成为一个故障点，但大型系统总是有分层的CA，故障只会影响系统的一小部分。
  • 理论上讲，PKI提供了不可否认性。一旦Alice用她的密钥签署一个消息，她以后就不能否认自己签署过这个消息了。密钥服务器系统就不能提供这种功能。中心服务器能得到Alice的密钥，因此可以伪造任何消息，使它看起来像是Alice发送的。
  • PKI最重要的密钥是CA根密钥。这个密钥不必存储于在线的计算机上，它可以被安全地存放在离线的机器上。根密钥仅仅用于签署子CA的证书，这很少用到。与之相反，密钥服务器把主要的密钥都放在在线的计算机上。离线的计算机比在线计算机更难被攻击，因此这使得PKI相对来说更安全一些。

19.10 如何选择

• 因为PKI是复杂的，所以对于小型系统而言，使用密钥服务器方案更容易一些。
• 对于大型系统而言，我们就可以重点考虑PKI方案，但也要同密钥服务器方案做比较。必须要考虑PKI的优势是否超过了它的额外代价和复杂性。

第20章 PKI的实用性

20.1 证书格式

• 证书仅仅是带有多个必选域和可选域的数据类型，重要的是要注意特定数据结构的编码是唯一的，因为在密码学中我们常常对数据结构取散列值来进行签名或做比较。类似XML的格式允许同一数据结构有几种不同的表示方式，需要特别注意保证签名和散列函数能正常工作。此外，X.509证书仍然是一种选择，尽管它比较复杂。

20.1.1 许可语言

• 我们需要有一种语言来表示密钥的许可权，比如将某种限制编码到子CA的证书中。如果在证书中没有限制，那么每个子CA都会有一个主密钥，那是很不安全的设计。也可以把系统限制为单个CA，但那样就会失去很多PKI优于密钥服务器系统的优势。

20.1.2 根密钥

• CA对自己的公钥签署一个证书，它称为自证明，自证明的证书被称为PKI的根证书。
• 下一步要做的是把根证书以安全的方式分配给所有的系统参与者。每个人必须知道根证书，而且必须有正确的根证书。
• 计算机第一次加入PKI时，必须以安全的方式得到根证书。这很容易做到，类似于给计算机指定一个本地文件或可信任的Web服务器上的文件，然后告诉机器这就是PKI的根证书。
• 根密钥在一段时间后会到期，中心CA就要发行新的密钥。发行新的根证书更容易些，新的根证书是用旧的根密钥签署的，参与者可以从不安全的来源处下载新的根证书。由于它是用旧的根密钥签署的，因此无法被修改。唯一可能存在的问题是参与者没有得到新的根证书。
• 这里有一个实现上的小问题。新的CA根证书可能有两个签名：一个签名是用旧的根密钥签署的，使得用户能识别新的根证书；另一个（自证明的）签名是用旧密钥到期后产生的新密钥签署的。为了解决这个问题，可以在证书格式中包含对多个签名的支持，或者仅仅是对同一个新的根密钥发行两个独立的证书。

20.2 密钥的生命周期

• 以Alice的公钥为例：
  • 创建：密钥生命周期的第一步是创建密钥。Alice创建一个公私钥对，并以安全的方式存储私钥部分。
  • 认证：下一步是认证。Alice把她的公钥传给CA或子CA，让它来认证公钥。这时CA决定给Alice的公钥赋予哪些许可权。
  • 分发：根据具体的应用，Aice也许要在使用公钥前分发她的已认证公钥。
  • 主动使用：Alice用她的公钥进行交易。
  • 被动使用：主动使用阶段过后，Alice应该停止主动地使用密钥，在密钥到期之前留出一段合理的时间，让所有待决的交易完成。
  • 到期：密钥到期后，它不再被认为是有效的。

20.3 密钥作废的原因

• 当持有密钥的时间越长、使用它的次数越多，攻击者设法得到密钥的概率就越大。如果要限制攻击者得到密钥的机会，就不得不限制密钥的生命周期。实际上，就是让密钥作废。
• 还有另一个限制密钥生命周期的原因。假定一些不幸的事情发生了，攻击者得到了密钥，从而破坏了系统的安全，引起了某些危害。
• 如果采用短的生命周期有两个优势：减少了攻击者得到密钥的机会，也限制了攻击成功带来的危害。
• 一个密钥合理的生命周期要由具体情况来决定。作为一个通用法则，很少被使用或测试的功能或过程更容易失败。保持密钥长期不变的最大危险也许是更换密钥功能从来没被用过，因此当需要它时就不能正常运行了。一年的密钥生命周期可能是一个合理的最大值。
• 密钥更换需要用户的参与，而且代价较大，因此不可能经常更换。合理的密钥生命周期是一个月以上。周期更短的密钥应该进行自动管理。