第18章PKI之梦
18.1PKI的简短回顾
PKI:公钥基础设施（Public Key Infrastruecture）,通过它可以知道哪个公钥属于谁。
CA:证书机构（Certificate Authority），有一对公私密钥对（例如 RSA密钥对），其中公钥是公开的。由于该公钥保持长期不变，一般假定所有人都知道CA的公钥。
How to加入PKI？
用户生成自己的公私密钥对
保持私钥不公开，并把公钥PKA传给 CA，声明PKA是自己的公钥
CA证实用户的身份后，签署一个类似于"密钥PK、属于Alice"的数字声明。这个签署的声明就叫作证书，它证明密钥属于 Alice。
How to通信by PKI
在双方都相信CA公正性的前提下
A将自己的公钥和证书发给B，B可以通过CA的公钥验证证书签名
B将自己的公钥和证书发给A，A可以通过CA的公钥验证证书签名
此时双方知道彼此公钥，可运行密钥协商协议建立会话密钥
18.2PKI的例子
18.2.1全局PKI
终极梦想只是童话
全局PKI是一个非常庞大的组织，就像邮局，能够给每个用户发行公钥证书。
优势：就是每个用户仅仅需要得到一次证书，因为同样的公钥可以用在每个应用中。因为每个人都信任邮局，或信任其他任何一个成为全局CA的组织。这样所有人都可以安全地互相通信了。
18.2.2VPN访问
VPN：Virtual Private Network，允许公司雇员从家里或是旅行时从宾馆访问公司的网络。
识别：由VPN的访问接入点识别访问网络的人以及他们有何种确切的访问级别
PKI模型：公司的IT 部门扮演CA的角色，给每个雇员一个证书，使得 VPN 的访问接入点能够识别不同的雇员。
18.2.3电子银行
电子银行：允许银行客户在银行网站上进行金融交易。
识别：在应用中正确地识别客户的身份是至关重要的，就像在法庭上能提供可接受的证据一样重要。
PKI模型：银行本身就是CA，它能认证客户的公钥。
18.2.4炼油厂传感器
炼油厂传感器：可以测量几英里长的管道和通路间的温度、流速和压力之类的指标。
识别：用标准的认证技术来保证传感器数据没有被篡改，并通过PKI确认数据来自传感器
PKI模型：公司可以作为CA，为所有的传感器建立 PKI，使得每个传感器都能被控制室识别
18.2.5信用卡组织
信用卡组织：是遍布世界的数千个银行之间的合作组织。所有这些银行必须能够交换支付。
识别：采用PKI就可以让所有的银行，彼此识别身份以进行安全的交易。
PKI模型：信用卡组织就是CA，给每个银行颁发证书
18.3其他细节
PKI的各种拓展形式
18.3.1多级证书
很多情况下CA被分为多个层级,如密钥PKx属于区域机构X，它可以用来证明其他密钥
密钥证书则包含两个签名的消息:中心CA 证实区域机构密钥的授权消息和区域机构关于银行密钥的认证——证书链
缺点
证书体积变得更大，需要更多的计算来进行认证
加入系统的每个 CA 都会带来新的攻击点，降低安全性
解决方法：打破证书的层级结构
例：一旦银行有了两级证书，就把证书送到中心CA。中心CA对两级证书做验证，然后用主CA密钥签署一个银行密钥的单个证书。
18.3.2有效期
没有一种密码学密钥应该被无限期地使用
证书不该是永远有效的
CA密钥和被认证的公钥都有有效期
更新证书以保持信息的时效性
证书还要包含啥?
有效时间\有效的起始时间\证书的不同类别\证书序列号\发行日期和时间等
18.3.3独立的注册机构
公司里只有R部门才能决定谁是雇员。但IT部门要运行CA，这是一个技术工作，他们不会允许HR部门来完成。
GOOD解决方案
使用多级证书结构，让 HR 部门成为子CA
自动提供了必需的灵活性来支持多站点
一旦用户有了两级证书，他就能从中心 CA得到一级的证书
通过把双消息协议加入系统，可以消除每次检查两级证书的额外开销
BAD解决方案
把第三方加入密码协议中,使CA 和RA 被看作完全独立的实体,产生了更多的描述联系
18.4结论
这是一个理想状态的梦想，它是密钥管理的起点和终点
18.5习题
18.1 假设CA 不可信，试问这样的 CA 可能引发什么样的后果?
答:证书数据存在被不公正地篡改、假冒的风险，证书文件不可信
18.2 假设有全局 PKI，那么在多个应用间使用单一的PKI会导致何种安全问题?
答:证书被多方知道而被其中的攻击者冒用
18.3 什么样的政策或者组织上的挑战会阻碍或者阻止全局 PKI的发展?
答:国家之间的计算阻碍,标准选择上的不同
第19章PKI的现实
现实世界中，PKI的宣传总是与实际不符
19.1名字
PKI把 Alice的公钥与她的名字绑定在一起。那么，什么是名字?
故事背景
名字可以是任何一种符号，我们用它来指代某个人，或更一般地说，指代某个实体。"官方"的名字仅仅是很多名字中的一个，对很多人来说还是很少被用到的一个。
隐含条件：
每个人都有一个名字
人名可能重复
人可以有多个名字
村庄：
每个人都互相认识，人名绑定人
城镇：
人变多，许多人没见过面，人名分离
城市：
人变多，重名人更多，人更可能接触多个重名人，名字与语境有关
互联网：
人名由于重名率极高而无意义，通过邮箱或唯一编码判断，但有人使用多个邮箱，有邮箱被多人使用
现实中的名字问题
政府机构’分配‘的官方名字，由不唯一的名字、可变的地址、不可证的驾照号、可变的性别、可欺骗的生日等标识构成，不具有唯一识别性
多个国家的不同标准间的多个名字
唯一的社会安全码（身份证号），无全球唯一性、与人的联系不紧密
大型PKI问题：庞大的人口基数，很多人有相同名字，很多人想用多个名字作不同用途，带来无与伦比的复杂度
19.2授权机构
谁是有权给名字分配密钥的这个CA呢?谁赋予这个CA关于用户名字的权力?谁来决定 Alice 是一个拥有VPN访问的雇员，或者仅仅是一个访问受限的银行客户
对大多PKI来说，问题不难，如老板知道谁是雇员，谁不是雇员，银行知道谁是客户。
对于全局PKI来说，没有权力来源
规划一个PKI必须考虑授权谁来发行证书
19.3信任
世界上没有一个组织能得到所有人的信任，甚至没有一个组织能得到大多数人的信任，因此永远不会有全局 PKI。但我们可以信任我们自己
So，我们不得不用大量小型PKI
被 CA使用的信任关系都是已经存在的，而且是建立在合同关系基础上的∶ 所建立的基本信任关系都是基于已有的合同关系之上的。
19.4间接授权
系统都不关心密钥属于谁，只是想知道密钥持有者被授权做什么
多数系统使用某种访问控制列表（Access Control List，ACL），这是一个关于谁被授权做什么事的数据库。
密钥授权
对象：密钥、名字、做某事的许可权
要求：系统想要知道的是哪个密钥授权哪种行为，换句话说，特定的密钥是否有特定的许可权
方法：通过把名字和密钥绑定以及用ACL把名字和许可权绑定来解决这一问题。
导致的额外攻击点
PKI提供的名字-密钥证书
绑定名字和许可权的ACL数据库
名字混淆
技术设计是完全根据需求的幼稚表述而来的，人们考虑的问题是识别密钥持有者的身份以及谁能够访问
19.5直接授权
直接用PKI把密钥与许可权绑定，证书不再连接密钥和名字，它连接密钥和许可集合
去掉ACL和名字而避免了名字混淆问题，改变了对名字的依赖
19.6凭证系统
凭证系统是一个超级PKI，对于你做的每件事情要以签署证书的形式给出凭证
存在的问题
凭证系统是很复杂的，会带来显著的额外开销。
访问一个资源的授权也许要依靠数个证书组成的证书链来完成，而且每个证书都要被传递和检查
凭证系统会引起访问权限的细化管理。
容易把权限分成越来越小的部分，使得用户最终要花掉很多时间来决定分配给一个同事多少权限
要开发一种凭证和委托语言（credential and delegation language）
具体的授权委托对普通用户来说是过于复杂的概 念，似乎没有一种展示访问规则的方式能被用户理解。
凭证是有用而且必需的
如果使用分层的CA结构。中心CA签署关于子CA密钥的证书，如果这些证书不包含任何限制，那么每个子CA就都有无限的权利。这是很差的安全设计，我们只是增加了很多地方来存储关键的系统密钥。
19.7修正的梦想
修正后的梦想要现实的多，比原来的梦也更有效、更灵活、更安全，真悲伤
每个应用都有自己的PKI和自己的CA。
全世界包含了大量的小型PKI，每个用户同时是许多不同 PKI 的成员。
用户对每个PKI必须使用不同的密钥
为对于系统设计没有经过仔细协调的多个系统，用户不能使用相同的密钥。因此用户需要存储很多密钥，占用上万字节的存储空间
PKI的主要目的就是把密钥同凭证绑定在一起。
证书中仍然要包含用户的名字，但这主要是为了管理和审计的目的。
19.8撤销
有时一个证书不得不被撤销。也许 Bob 的计算机被黑客攻击。从而泄露了他的私钥。也许Alice被调到另一个部门或者被公司解雇了等等
问题：证书仅仅是一串位，已经在很多地方使用，而且储存在很多地方，不可能让所有人忘记
什么决定了撤销操作的需求
撤销的速度∶撤销命令发出与最后一次使用证书之间所允许的最大间隔时间是多少?
撤销的可靠性∶在某些情况下撤销不是完全有效的，这可以接受吗?什么样的遗留风险是可以接受的?
撤销的数目;撤销系统一次能处理多少撤销请求?
连接性;验证证书的过程是否为在线验证
可行的解决方案：撤销列表、短有效期以及在线证书验证
19.8.1撤销列表
撤销列表（certificate revocation list）、或称CRL，是一个包含撤销证书列表的数据库，每个验证证书的人都必须检查 CRL 数据库。看看那个证书是否已经被撤销。
过程：每个验证证书的人都必须检查 CRL 数据库。看看那个证书是否已经被撤销
优点：撤销几乎是瞬时的，也是可靠的。
缺点：CRL 系统的实现和维护都是很昂贵的，要求有自己的基础设施、管理程序、通信路径等。所需的额外功能相当可观，仅仅为了处理相对较少用到的撤销功能
19.8.2短有效期
利用已经存在的有效期机制来完成，使用证书时会从CA得到新证书
过程：每当 Alice想用她的证书时，她会从CA出得到一个新的证书。只要它是有效的，Alice就可以一直使用
优点：已经可用的证书发行机制，不需要独立的 CRL，降低系统复杂性
可行性：主要取决于应用是否要求撤销立即生效或者延迟是否可被接受。
19.8.3在线证书验证
证书状态协议（Online Certificate Status Protocol，OCSP）在一些领域（例如 Web浏览器）中已经有了很大的进展。
过程：为了验证一个证书，Alice 将证书的序列号提交给一个可信方进行查询，然后可信方在它自己的数据库中查询证书的状态，并发送一个经过签名的答复给 Alice。Alice已知可信方的公钥，所以可以验证答复的签名，如果可信方认为证书是有效的，那么 Alice 就可以知道证书并没有被撤销
优点：撤销几乎是瞬时的，也是可靠的。
缺点：验证证书时必须在线，并且可信方也成为一个故障点。但相对CRL避免了大量发布CRL的问题，也避免了客户端解析和验证 CRL。
实际使用中不如短有效期法
19.8.4撤销是必需的
没有撤销功能的PKI是相当无用的
虽然撤销很难实现，但必须实现，因为密钥肯定会被泄露
19.9PKI有什么好处
PKI目的：让Alice和Bob能生成共享密钥，用它来建立安全的信道，以便能彼此安全地通信。
实际上我们把环境建立在离线基础上，但没有一个撤销系统能完全离线工作。
但如果能在线，我们为什么不建立一个中心密钥服务器呢？
密钥服务器需要每个人实时在线。
密钥服务器是一个故障点。
PKI提供了不可否认性。
CA 根密钥被离线存储。
当然，这些不是非要不可的优势带来了更多的花费、更复杂的系统、更庞大的计算量
19.10如何选择
小型系统：密钥服务器
大型系统：PKI系统
19.11习题
19.1 如果 Alice 在不同的 PKI中采用相同密钥，会出现什么后果?
答：如果一个PKI中的密钥泄露，其他的PKI中Alice的信道也将不安全
19.2 假设一个系统中的每个设备能存储 50 条 CRL 数据。这种设计会导致何种安全问题?
答：一些CRL数据没有被记录在设备上而导致设备并不知晓证书的撤销
19.3 假设一个应用PKI的系统采用CRL。一台系统中的设备想要验证证书，但由于拒绝服务攻击而无法访问 CRL 数据库。那么这台设备可以采取哪些措施呢?试分析各种措施的优缺点。
答：可以通过其他副本得到CRL
第20章PKI的实用性
20.1证书格式
证书仅仅是带有多个必选域和可选域的数据类型。重要的是要注意特定数据结构的编码是唯一的。
20.1.1许可语言
除非你的PKI系统是最简单的那种，否则你一定会想要限制子CA 能够发行的证书。为此需要把某种限制编码到子CA的证书中
有一种语言来表示密钥的许可权，用来做何种限制由具体应用决定。
假如...
如果不能找到合理的限制条件，就应该重新考虑是否要使用PKI。
如果在证书中没有限制，那么每个子CA都会有一个主密钥，那是很不安全的设计。
如果把系统限制为单个CA，但那样就会失去很多 PKI 优于密钥服务器系统的优势。
20.1.2根密钥
CA的公钥及效期之类的数据被分配给每个参与者
自证明证书：CA对公钥签署证书，作用是将公钥吧附加数据绑在一起，包含许可权列表、有效期、联系人信息等，即为PKI的根证书
必要性：把根证书以安全的方式分配给所有的系统参与者。每个人必须知道根证书，而且必须有正确的根证书。
FIRST:计算机第一次加入PKI时，必须以安全的方式得到根证书。
验证方式：由于缺乏认证密钥，密码学上无法认证，必须保证来源安全性。用户指定本地或服务器上的文件为根证书。
问题：若CA私钥泄露，PKI必须初始化
LATER:根密钥到期后，CA会发行新的根证书。
验证方式：通过旧密钥签署认证，所以证书来源可不安全
问题：参与者可能没有得到新的根证书。
一个小问题
新的CA根证书可能有两个签名∶一个签名是用旧的根密钥签署的，使得用户能识别新的根证书;另一个（自证明的）签名是用旧密钥到期后产生的新密钥签署的。
解决方案：在证书格式中包含对多个签名的支持。或者仅仅是对同一个新的根密钥发行两个独立的证书。
20.2密钥的生命周期
它可以是CA 的根密钥，也可以是任何其他的公钥
创建
密钥生命周期的第一步是创建密钥。Alice创建一个公/私钥对，并以安全的方式存储私钥部分。
认证
Alice把她的公钥传给CA或子CA，让它来认证公钥。这时CA 决定给 Alice 的公钥赋予哪些许可权。
分发
根据具体的应用，Alice也许要在使用公钥前分发她的已认证公钥。例如，如果 Alice用自己的私钥来签名，能收到Alice签名的每一方都应该先有她的公钥。
最好的办法就是在Alice第一次使用公钥前的一段时间内分发密钥，这对于新的根证书尤为重要。例如。当CA切换成一个新的根密钥时，每个人都应该在接触到用新密钥签署的证书之前有机会知道新的根证书。
是否需要一个独立的分发阶段要根据具体的应用来决定。如果可能，应该尽量避免这一阶段，否则就要向用户解释该阶段，并且要在用户界面上可见。
主动使用
下一阶段是 Alice 主动用她的公钥进行交易。这是密钥使用的一般情况。
被动使用
主动使用阶段过后，一定会有一段时间 Alice 不再用她的密钥进行新的交易，但所有人仍然接收这个密钥。交易不是瞬时完成的，有时会有延迟。
Alice 应该停止主动地使用密钥，在密钥到期之前留出一段合理的时间，让所有待决的交易完成。
到期
密钥到期后，它不再被认为是有效的。
密钥阶段是如何进行定义的？
在证书中包含每个阶段过渡的确切时间。证书包含密钥分发阶段的开始时间、主动使用阶段的开始时间、被动使用阶段的开始时间以及有效期。
所有这些时间都必须提供给用户，因为它们影响着证书的工作方式
更灵活的方案：建立一个中心数据库，包含每个密钥的阶段。但会带来CRL使密钥立即到期的风险
额外且不必要的任务：Alice想要在几个不同的PKI中使用相同的密钥
虽然很危险但有时不可避免的例子：Alice 使用一个小的抗干扰模块，并随身携带它。这个模块包含她的私钥，并且能做数字签名所需的计算。这样的模块具有有限的存储能力，Alice关于公钥的证书能被存储在没有文件大小限制的公司内部网上，但是这个小模块不能存储无限数目的私钥。在这种情况下，Alice最终只能对多个PKI使用同样的私钥。
解决方案：保证在一个PKI中使用的签名不能在另一个PKI中使用。
最简单的解决方案：在签名的字节串中包含一些数据，用这些数据来做应用和 PKI 的唯一标识
20.3密钥作废的原因
什么限制了密钥的使用周期？
持有密钥的时间越长、使用它的次数越多，攻击者设法得到密钥的概率就越大
在攻击者得到密钥后，过去和以后的数据都有泄露的风险
短密钥周期的优势：
减少了攻击者得到密钥的机会
限制了攻击成功带来的危害
一个密钥合理的生命周期是多少？
最大值：一年
合理值：一个月以上
周期更短时应自动管理
保持密钥长期不变的最大危险也许是更换密钥功能从来没被用过，因此当要它时就不能正常运行了。一年的密钥生命周期可能是一个合理的最大值。
20.4深入探讨
密钥管理不单单是个密码学问题，而是和真实世界紧密相关的问题。
选择何种PKI以及如何配置，取决于具体应用和部署应用的工作环境。
20.5习题
20.1 你认为哪些字段需要出现在证书中，为什么?
答：用户需要知道证书有效期、有效起始时间、CA、被证实的文件、证书的摘要值等字段，这些字段保证了被签名文件的完整性和安全性
20.3 假设你已部署了一个PKI．这个PKI使用固定格式的证书。现在你需要进行系统更新。更新后的系统需要与之前原始版本的PKI以及证书格式保持向后兼容性，但是更新后的系统需要证书中有额外的字段。这种过渡会带来什么问题?在考虑到系统中的证书会更新为新格式的情况下，在最初设计系统时需要进行何种准备?
答：会导致系统中要针对旧版本做额外的安全性或功能性处理，会降低系统的处理效率。最初设计证书时应在各部分间留有升级拓展空间
标签：公钥,20,证书,19,18,CA,Alice,密钥,PKI From： https://www.cnblogs.com/charliecza/p/17362211.html