Skip to content

Latest commit

 

History

History
166 lines (120 loc) · 27.8 KB

第15章-密钥管理.md

File metadata and controls

166 lines (120 loc) · 27.8 KB

密钥管理

使用TPM设计一个密钥管理系统时需要考虑很多事情。如果密钥用于重要的操作，比如加密或者身份认证，使用一个提供标准方法来管理密钥的架构很重要，同时这个架构还要考虑到硬件损坏的情况。这样一个密钥管理架构必须能够处理密钥生成，密钥分发，密钥备份，密钥销毁。TPM的从架构设计上一直注意这些功能。这一章描述了各种各样选项，它们用于一个密钥生命周期的各个步骤中。

密钥生成

当我们生成一个密钥时，需要考虑的最重要的是密钥是否真得是随机产生的。如果选择了一个比较差的随机数发生器，那么生成的密钥就会不安全。其次就是要考虑保证密钥信息的机密性。TPM被设计成可以免受软件攻击。设备厂商可以选择保护硬件，但是这不是设计规范要求的。但是，TPM的设计允许密钥的分离创建，这是指用于创建密钥的熵在TPM内部和外部都有存储，这样一来，当不使用TPM时，即使有人可以物理上接触到TPM，密钥也是安全的。

密钥在TPM中有三种存在形式。密钥可以由一个种子生成，由TPM的随机数发生器生成，或者被导入到TPM中。主密钥是通过TPM中的种子生成的。用于生成EK的种子与背书密钥组织架构有关，并且终端用户不太可能去修改它。

另一方面，与存储密钥组织架构相关的种子子在TPM收到TPM_Clear命令时就会改变。这个操作可以由使用平台组织架构的BIOS执行，或者由终端用户使用字典攻击复位口令来实现。

第10章我们已经说明，主密钥使用TIPS认可的KDF生成，KDF会将主种子和密钥模板组合起来做哈希。密钥生成的模板被分为两部分。第一部分是对密钥类型的描述——是否是一个签名密钥，具体的算法和密钥大小，等等。另外一部分描述的是密钥生成命令用于生成密钥的熵值从哪里来。大多数情况下，第二部分被设置成全0（TCG基础设施工作组公布的EK模板中有）。但是，如果用户不相信TPM内部的熵发生器，他们可以使用这个功能将密钥的熵分开，也就是密钥生成分割。

密钥分割是一个密码学构造，它包含两部分熵——每一部分都有与最终密钥相同的熵值——用于生成密钥。这两个中的任何单独一个都不能提供哪怕是一个比特的最终密钥的熵——所以这两者都是必需的。这样一来，一个可以独立于TPM存储，另外一个则存储在TPM中。

对于一个主密钥来说，一部分分割值是密钥对应组织架构的种子，这存在于TPM中。另外一部分存储在TPM之外的密钥模板中，当不使用时它可以被存储在安全的地方（比方说存储在智能卡中）。

主存储密钥有一个与之关联的对称密钥，它和主存储密钥一起生成。主密钥同样由主种子和外部引进的熵派生而来。只要与组织架构相关的种子没有变化，使用相同的密钥模板总会产生相同的主秒哟和相关的对称密钥。因为这两种密钥都使用密钥模板，如果熵由模板提供，那模板中的熵也就是一部分分割的熵。

为什么会有人分割一个密钥呢？主要的原因通常是用户担心有人可能会拿到这两部分分割密钥的一个。他们同时也担心TPM的种子在灌进TPM设备时，有人可能会保留一个副本，或者他们还会担心有人会分解TPM，就像多年前有人对英飞凌的TPM1.2芯片做的一样。这些攻击大多数是幻想狂想到的——在仅仅破坏几个TPM之后，对英飞凌芯片的攻击就成功了，并且花费超过20万美元。但是，要知道的是，安全领域的人往往都倾向于是幻想狂。

生成主密钥可能会花费相对较长的时间（如果密钥是RSA密钥），或者是几乎瞬间完成（如果是ECC密钥）。如果密钥生成需要很长时间，用户可能会决定将密钥存储在TPM的持续性内存中，这是通过TPM2_EvictControl命令来实现的，这个命令要求相关的组织架构授权。在这种情况下，密钥就会被分配一个持续性handle，并且重新上电不会影响这个密钥的存在。这个密钥可以使用相同的命令被擦出。用户可以根据所担心攻击的不同，决定是否让密钥变成持续性的密钥。

如果一个用户担心TPM的种子可能已经不安全了，那他们就会担心主密钥也不安全了。如果主密钥不安全了，所有存储在这个主密钥之下的密钥都不安全。在这种情况下，用户可以通过模板使用密钥分割来引入他们自己的熵，并且让密钥变成持续性的密钥，然后将密钥的模板委托给攻击者访问不到的地方。这样就阻止了知道TPM种子的攻击者拿到主密钥秘密信息（没有另外一部分熵）。

除此之外的另一种选择是，一个主密钥只能被用于创建另外一个存储子密钥。这个存储密钥被加载到TPM中的主密钥下。然后被转变成持续性密钥。这个密钥和TPM1.2的SRK类似。这个密钥是由TPM的随机数发生器生成，而不是种子。但是，因为它会以加密的形式短暂地出现在TPM以外的地方，在它被重新 加载到TPM以前，如果主密钥被攻破还是会有被攻击的风险。

如果用户担心TPM会遭受物理攻击，他们应该选择在密钥模板中加入第二部分的熵，也就是种子的生成来源。并且由种子生成主密钥以后不要将主密钥配置成持续性密钥。（如果主密钥被存储在TPM中，那么一个物理攻击可能会恢复它。）这种应用场景下，每次TPM重新上电以后，所有主密钥的踪迹都会消失。当然这会很难管理，因为密钥的模板必须保持机密性（很有可能在USB密钥中），并且独立于TPM，然后在每次TPM重新生成密钥时再导出到TPM中。

类似的，对于一个彻底的幻想狂来说，他不仅担心TPM的种子并且还不相信TPM的随机数发生器，一个外部密钥可以通过可信的熵源生成，然后被加密从而被导入到TPM的一个主密钥（或者是任何其他存储密钥）中并且被配置成持续性密钥；然后将主密钥擦除。如果这个用户还担心他们的系统被窃并将TPM解体然后恢复秘密信息，那他们不应该将密钥配置成持续性的，而是再每次TPM重新上电以后重新做以上复杂的工作。

应用案例：为不同的用户创建不同的SRK

如果一个系统有几个用户，他们可能想要完全不同的几组密钥。如果有这样的需求，他们可能需要全部生成自己的SRK（独立的限制性存储密钥）。如果他们再各自的密钥模板中使用不同的用于产生主种子的熵，那这就很容易实现。为了确保每个用户都生成不同的密钥，用于生成密钥的模板必须是明显不同的。比如说，他们可以使用用户秘密信息的哈希作为密钥模板的熵值。但是，不同的用户还是有可能选择相同的用户秘密信息（就跟两个完全不相干的人完全有可能设置相同的登陆密码一样）。或许让TPM使用它的硬件随机数发生器来为每个用户创建SRK更好。


拇指规则

只有三种原因让密钥变成持续性密钥。密钥是RSA密钥，所以重新生成可能会花费不合理的很长时间；密钥的生成可能使用了密钥模板中的熵，但是这个熵并不总是可用的，或许是TPM外部没有足够的持续性空间来存储密钥模板。如果TPM是用于资源受限的环境中，那有可能是第二种情况，比方说再启动过程中。在其他情况下，密钥应在在必要的时候重新生成。这与TPM1.2的设计不同，因为在TPM2.0的设计中，密钥加载使用对称密钥解密，因此这个过程会很快。

模板

有标准的秘钥模板用于创建秘钥，通常情况下使用这些模板比自己创建模板更合理。因为模板会使用强度匹配的算法。在选择对称秘钥的时候你可能会使用强度不匹配的算法。因为TPM2.0使用对称秘钥加载其他秘钥，而不是像TPM1.2中一样使用非对称秘钥。因此，我们可以设计一套系统，系统使用比用于主秘钥的非对称秘钥强度更高的对称秘钥。一旦实现了这样的系统，由TPM产生的秘钥就不会面临非对称秘钥或者算法强度弱的风险。

密钥树：将密钥保存在具有相同算法的密钥树中

尽管从技术上来说，可以混用不同的算法——使用一种算法创建一个秘钥，然后用一个不同算法的秘钥保护这个秘钥——这是一个不好的习惯（首先，已经看到了，TSS的FAPI就不允许这样做）。这样做有问题的原因是，一组秘钥的整体强度是由其中强度最弱的秘钥决定的。这样就意味着，不但不应该混用算法，而且秘钥链（就是一个秘钥加密后面的秘钥，这样组成的链式结构）也应该尽量短。如果秘钥链中的任何一个秘钥被破坏了，那所有在这个秘钥后面的秘钥也都被破坏了。所以在面对暴力攻击时，一个由四个秘钥组成的秘钥链的强度是一个单独秘钥的四分之一。（当然了，如果使用的秘钥强度合理，这个4就不重要了。）

你想要秘钥链变长的原因可能是管理性。一个用户可能想要将他所有的秘钥或者是一部分秘钥从一台机器复制到另外一台机器上，或者将将秘钥复制到其他的系统上。为了操作简单，用户更愿意使用另外系统上的公钥仅仅加密一个秘钥——就是秘钥树最顶端的秘钥，然后将加密的秘钥复制到其他系统上的合适位置。

你可能想要将企业秘钥与个人秘钥分开，以及将企业中不同部门的秘钥分开，如图15-1所示。尽管如此，这个秘钥树的深度还是越浅越好。

图 15-1 秘钥树示例

密钥复制

在图15-1的密钥树中，有可能被复制的密钥是个人密钥，企业密钥，金融密钥（个人或者企业），娱乐密钥，HR密钥。为了让密钥可以被复制，在创建密钥时就需要将它们配置成可复制的，并且密钥还需要有一个需要包含TPM2_PolicyCommandCode命令的Policy，TPM2_PolicyCommandCode指定的命令为TPM2_Duplicate。在大多数情况下，一个用户会创建两种复制Policy——一种用于个人密钥，另外一种用于商业密钥——并将它们分别与一个个人可复制密钥（Personal Duplicable Key）和一个用于商业的可复制密钥（Business Duplicable Key）关联起来。

如果我们不想让一个密钥被复制，可以设置属性为fixedParent。如果一个密钥想独立于它的父密钥SDK或者UDK被复制，那么这个密钥本身也必须有一个可以允许复制的Policy。

在TPM1.2中，不太可能创建一个只能复制到一部分指定的新密钥下的密钥。在TPM2.0中，使用TPM2_DuplicationSelect就可以达到这个目的。这个密令允许你精确地指定密钥将被复制到哪一个父密钥下。这个密令主要与PolicyAuthorize结合使用。通过PolicyAuthorize操作，一个IT组织可以修改用于备份的复制密钥（意思是说，这个秘钥可以作为另一个秘钥的复制操作的目的地）。如果IT组织在一个指定的服务器上备份了密钥，但是服务器坏掉了，IT可以通过TPM2_DuplicationSelect命令选择一个新的服务器，然后向员工发送一个签名过的Policy，这个Policy可以允许他们将自己的秘钥备份到新的服务器上。这样一来，通过更换新的备份服务器来避免员工将他们的秘钥备份到个人电脑上（这样可能就不安全了）。

因为TPM2_Duplicate和TPM2_DuplicationSelect命令不能够使用口令或者HMAC授权，所以为了复制一个秘钥，你必须首先启动一个Policy会话，然后满足包含TPM2_PolicyCommandCode命令的Policy分支，这个分支又与TPM2_Duplicate或者TPM2_DuplicationSelect相关联。然后就可以执行合适的命令将秘钥复制到新的父秘钥下。

应用案例：将一组服务器看成一个服务器

在这个案例中，一组SSL服务器中的机器可以作为另外一台机器故障转移的对象或者用于负载均衡。公司不想让用户知道他们正在连接哪一台服务器——实际上用户也不关心这个。因此公司需要在这些服务器上部署相同的密钥用于网页服务。（这也就意味着公司只能为这个密钥准备一个证书，而不是每台服务器一个。）

公司会创建一个可复制的密钥，密钥使用包含PolicyAuthorize命令的Policy。然后使用与PolicyAuthorize命令相关的私钥签名几个TPM2_DuplicationSelect命令，不同的服务器对应一个签名。一个用户认证这个密钥，然后在每一台服务器上复制一份证书，并最终使用TPM2_Import命令将密钥导入到其他的服务器上。这时候，所有的服务器对于用户来说都是一样的。

操作步骤：

1. 使用TPM2_PolicyAuthorize命令，一个企业签名密钥A，以及SSL的policyRef创建一个Policy，我们称为P。
2. 使用Policy P在初始的SSL服务器上创建一个可复制密钥B。
3. 在所有其他的SSL服务器上使用TPM2_Create命令创建限制性存储密钥SRK(i)。
4. 使用公司的私钥A签名TPM2_PolicyDuplicateSelect，并指定SRK(i, Public)作为秘钥复制的目的地。针对每个SRK做一次这个操作。
5. 在初始的SSL服务器上使用TPM2_VerifySignature命令针对每个签名的Policy生成相应的Ticket。这写Ticket使得签名过的Policy用于秘钥复制。
6. 在初始的SSL服务器上针对每一个Policy，通过以下的步骤为其他的服务器创建可复制的秘钥：
  1. 使用TPM2_Load命令加载公司的签名秘钥A的公钥。
  2. 使用TPM2_LoadExternal加载SRK(i, Public)。
  3. 使用TPM2_StartAuthSession命令启动一个Policy会话。
  4. 执行TPM2_PolicyDuplicateSelect，并选则SRK(i, Public)作为秘钥复制的目的地。
  5. 执行TPM2_PolicyAuthorize，传递Policy，SSL的policyRef，以及SRK(i)对应的Ticket。
  6. 执行TPM2_Duplicate命令，传递已加载的SRK(i, Public)，以及新创建的公司签名秘钥B的Handle。
  7. TPM2_Duplicate命令的结果就是加密过的公司签名秘钥B。将它发送到SRK(i)对应的服务器上。
  8. 在包含SRK(i)的服务器上将复制的秘钥B Import到自己的TPM中。
7. 将公司签名秘钥B的证书复制到各个服务器上。

此时，所有服务器上的秘钥B都是相同的，它可以用于SSL认证和通信。

密钥分发

在某些情况下，一些密钥需要在系统初始配置很久之后分发出去。这时，系统能够安全的分发密钥就显得很重要了。TPM的设计可以让密钥分发变得简单。当每个系统在初始配置时，系统会产生一个不可复制的存储秘钥，中央管理系统会记录这个秘钥以及秘钥所在系统的名称（或者是系统的序列号）。Active Directory或者LDAP数据库可以做这件事情。另外，在本地平台初始配置时，会将中央管理系统中一个签名私钥对应的公钥备份到平台上。后续，如果中央管理系统想要分发一个HMAC秘钥到本地平台时，会执行以下步骤：

  1. 中央管理系统的IT部门使用TPM2_GetRandom创建一个HMAC秘钥。
  2. 中央管理系统使用目标系统的存储公钥加密上述的HMAC秘钥。
  3. 中央管理系统的IT部分使用自己的签名私钥对加密的HMAC签名。这就让本地系统可以确认它接收到的内容是经过授权的。
  4. 加密的HMAC秘钥和相应的签名被发送到本地系统。
  5. 本地系统使用初始配置时备份的中央系统的签名秘钥的公钥验证签名。（如果你愿意，可以通过TPM2_LoadExternal加载公钥，然后通过TPM2_VerifySignature来验证签名。）
  6. 本地系统使用TPM2_Import命令将加密的HMAC秘钥导入到TPM中，然后得到一个可以加载的，包含HMAC秘钥的数据块。
  7. 当用户需要使用HMAC秘钥时，本地系统使用TPM_Load命令加载这个HAMC秘钥，然后就可以正常使用来。此时，一个本地系统就从中央管理系统得到一个HMAC秘钥，并且这个秘钥全程没有在本地系统的内存中以明文的方式出现过。

密钥激活

因为TPM拥有从种子创建和重复创建密钥的能力，所以在系统初始配置阶段可以使用多个密钥模板，并由中央IT系统备密钥模板和密钥的公共部分。然后中央IT系统可以重启TPM从而删除系统上的密钥。这样一来，当一个系统被分发到最终的用户时，系统上并没有可用的密钥。

之后，当IT想要激活这些密钥时，它只需要向对应的系统发送密钥模板，系统就可以通过TPM2_CreatePrimary命令重新创建密钥。需要注意的是密钥模板中包含密钥的Policy，但是没有密钥的口令，口令是在每次重新创建密钥的时候设置的。如果中央IT系统希望避免使用口令授权密钥的访问，它可以通过配置模板中的两个比特位来实现：userWithAuth和adminWithPolicy。这两个位的设置可以使密钥不能通过口令访问。如果userWithAuth设置位False，并且adminWithPolicy为True，这样口令就不能做任何事情了。

如果使用上述的技术重新生成密钥，密钥的模板需要包含熵。没有这个模板，密钥就不能被重新创建，因此中央管理系统可以确保客户端在收到模板之前不会使用这个密钥。

还有一种激活密钥的方式，这与TPM1.2的方式类似：使用可迁移的密钥。当一个密钥被复制时，你可以对它双重加密：一次使用新的父密钥加密，一次使用一个对称密钥在复制密令操作完成以后加密。这就产生了一个经过双重加密的数据块。外面一层加密可以由新的父密钥的私钥解密。内层加密使用一个对称密钥。在这种情况下，当我们执行TPM2_Import命令时，TPM必须已经加载新的父密钥的私钥；这个私钥的handle将传递到TPM2_Import命令，同时还有一个秘密信息。这个秘密信息用于计算内层加密的对称密钥，然后用于解密内存加密数据。这个过程如下：

  1. 中央管理系统生成一个可复制密钥。
  2. 使用对称密钥选项复制这个密钥到客户端系统。对称密钥选项是指TPM2_Duplicate函数的encryptionKeyIn参数。
  3. 中央管理系统签名密钥数据块并发送到客户端系统，但是IT要负责安全保存encryptionKeyIn参数。
  4. 当IT管理员想要客户端系统使用这个被复制的密钥时，提供encryptionKeyIn，从而使客户端系统能够通过TPM2_Import命令成功导入密钥。

密钥销毁

一旦密钥被创建以后，有时候能够成功销毁它也很重要。一个例子就是，如果一个用户将要卖掉多余的或者回收再利用一个电脑，并且他希望确保系统上的加密数据和密钥不再可用。TPM提供了多种容易实现的密钥销毁方式。

如果要销毁的米要是主密钥，最简单的销毁方式就是修改用于创建这个主密钥的密钥组织架构的种子（通常是存储密钥组织架构）。TPM2_Clear可以清除存储密钥组织架构的种子。这个清除TPM的操作会销毁所有与密钥组织架构相关的不可复制密钥，清除密钥组织架构下的所有密钥，并且修改种子，这样就阻止了之前所有与这个组织架构相关的主密钥被重新创建。这个命令还会清除背书密钥组织架构，但是不修改它的种子（EK和设备厂商的证书仍然有效）。可复制的密钥再也不能被加载到系统中，如果它们已经被复制到另外一个系统中，那它们可能没有被删除。

如果上述的极端操作步骤不是必须的（或许只有在相关机器需要借用给另外一个雇员，或者多个雇员使用相同的机器的情况下），那么在有所准备的情况下，可以通过别的途径销毁一个密钥。举例来说，如果一个主密钥是由模板中的熵生成的，并且被配置成持续性密钥的，那么销毁这个密钥需要做的仅仅是销毁密钥模板及其所有副本，然后将主密钥从持续性存储中删除。一旦完成这个操作，这个主要就消失了，并且它不能被重新创建。因为不同的主密钥下可以有不同的密钥树，所以这就提供了一种在不影响其他密钥树的情况下销毁一个特定密钥树的方式。当时系统有多个用户在使用同一个TPM时，这种能力显得尤其重要。

TPM可以销毁在TPM之外产生的密钥，这些密钥创建以后被导入到TPM并配置成持续性密钥。如果TPM之外的密钥副本被销毁了（意识是说这个密钥已经成功地被导入到TPM之后），那仅仅需要将这个密钥从持续性内存中删除就可以销毁这个密钥了。

综合实例

这一小节展示了两个不同商业类型如何管理TPM实体的例子。我们先由一个适用于小的商业类中的简单例子开始介绍，然后再讨论适用于大型企业的案例。

示例1：简单的密钥管理

一个设备终端用户会控制所有他们自己的密钥。假设用户有两种系统：一个主系统，和一个用于备份密钥的备份系统。以下是用户管理密钥的操作步骤：

  1. 使用标准的不可复制密钥模板在两个系统上分别创建一个SRK。属性userWith为True，adminWithPolicy为False，并且使用一个空Policy。这就意味着Policy功能被关闭，用户可以使用口令授权SRK的访问。用户在使用TPM2_CreatePrimary命令创建SRK时将口令设置成熟悉的口令。
  2. 在SRK下创建一个可复制的存储密钥（DSK）。使用TPM2_Create命令来创建这个密钥。userWithAuth属性设置成True，并且adminWithPolicy设置成True。这就允许使用口令授权密钥访问，以及使用Policy授权密钥复制。（记住，密钥只能通过Policy来授权复制操作。）这个密钥的Policy包含一个分支Policy，这个分支Policy在包含TPM2_PolicyCommandCode命令并选择TPM2_Duplicate。同时还包括TPM2_PolicyAuthValue，也就是说这个Policy还要求用户输入密钥的口令来复制这个密钥。
  3. 加载DSK新的父密钥的公钥（也就是另外一个的SRK的公钥）。
  4. 将DSK复制到备份系统上包含以下操作：创建一个Policy会话，执行TPM2_PolicyCommandCode命令，并且传入参数TPM2_PolicyDuplicate，然后执行TPM2_PolicyAuthValue。然后使用DSK的口令启动一个HMAC会话。执行TPM2_Duplicate命令的时候会引用这两个会话，还需要传递DSK的handle以及备份系统SRK公钥的handle。这个命令会产生一个包含被复制密钥的数据块并且使用TPM可以导入的方式加密，TPM可以导入的意思就是备份系统的TPM中有SRK的私钥，而加密是使用SRK的公钥加密的，所以就可以解密这个数据块。
  5. 将数据快移动到备份系统上，使用TPM2_Import命令将密钥导入到备份系统上。这个命令又会产生另外一个数据块，它可以在需要的时候加载到TPM中。
  6. 当在主系统上创建DSK的子密钥后，可以通过上述相同的方式将新密钥复制到备份系统上，然后就可以通过备份的DSK加载到TPM中，并使用它们。
  7. 为了让主系统退役，使用TPM2_Clear以及LockOut口令来清除TPM的存储密钥组织架构。
  8. 为了将所有的密钥迁移到一个新的系统上，首先在新的主系统上创建SRK。
  9. 重复上述由步骤4开始的密钥复制过程。这时候，新的父密钥反过来是新的主系统上的SRK。
  10. 将所有的密钥数据块导入到新的主系统上。

示例2：一个公司的IT组织，使用使能TPM2.0的Windows系统

在这个案例中，企业不想使用那些可能被外部知道的EK。企业想要在系统交付之后使用自己的EK，但是需要使用OEM的EK证明这个系统是真实的。企业会按照以下步骤来准备（配置）每一个系统：

  1. 使用TPM2_CreatePrimary和TCG基础设施工作组的标准EK模板创建OEM EK。然后将这个新生成的密钥和跟随系统一起被提供的设备厂商的EK证书比较。当然还要使用设备厂商的公钥验证这个EK证书。
  2. 执行TPM2_Clear命令来清除TPM的存储和EK组织架构。
  3. 在一个可信的环境中，清除OEM的EK，要求TPM产生一个随机数，并将这个随机数作为熵值重新填入EK模板中，然后读取EK模板中的密钥公共部分，组成公司自己EK的证书。
  4. 将存储组织架构，背书组织架构，以及字典攻击的授权值修改成随机值，并将这些随机值存储到LDAP服务器上。
  5. 创建一个限制性加密密钥并配置成持续性的密钥，这个密钥作为SRK。它的授权值和Policy都为空。所以任何人都可以使用。
  6. 创建一个限制性签名密钥并配置成持续性的密钥，这个密钥作为AIK。它的授权值和Policy都为空，这样一来TNC软件就可以使用它了（TCG Trusted Network Connect）。
  7. 将SRK的公钥复制一份到相关的LDAP上。
  8. 为AIK创建一个证书（怎么做？？？），这个证书在本地系统和LDAP系统上都有一份。
  9. 使用AIK引用PCR值，然后将它们与系统标准的测量值比较。
  10. 修改软件和系统配置，从而满足企业自己的需求。
  11. 使用AIK引用系统配置修改过的PCR值，然后将它们存储到LDAP上。这些值会被作为标准的测量值被使用。
  12. 使用TPM创建虚拟智能卡。然后配置Windows VPN服务器从而使它接收AIK的证书。
  13. 使用TPM创建另外一个虚拟智能卡。然后配置一个RADIUS服务器允许它使用WPA2的企业模式连接企业的无线网。（Remote Authentication Dial-In User Service）
  14. 创建一个32字节长的NV索引，然后将企业IT组织的公钥哈希值存储到这个NV中。这个密钥的Policy只允许使用这个密钥写这个索引值（？？？）。后续这个密钥会用于在软件被安装之前检查这个企业IT组织是否允许安装这个软件。
  15. 安装Wave用于在每次启动之后报告PCR的测量值，如果PCR不正确时还要向IT组织发送警告。（另一种方式是，可以使用StrongSwan VPN，这个服务只有在PCR值匹配的情况下授权网络访问。）
  16. 创建一个可以允许复制密钥到IT备份服务器的Policy，并且使用IT的私钥签名这个Policy。
  17. 用户的老板提供一个可以在用户不在时使用密钥的Policy。
  18. 当用户拿到系统之后，他可以创建一个可复制的限制性解密（存储）密钥，密钥的父密钥用户存储用户所有的企业密钥。密钥的Policy是第16，17步中两个Policy OR的结果。但在配置Policy之前，用户需要结合第14步中的公钥哈希值验证Policy的签名。
  19. 用户将他们自己的可复制存储密钥备份到IT组织的备份服务器上，将加密过的密钥备份到自己系统的一般备份区域。
  20. 如果用户离开或者这个机器需要被回收，使用所有者的授权告知系统需要执行TPM2_Clear命令，从而删除所有存储在系统上的密钥。OEM的EK可以用于重新完成上述的步骤。
  21. 如果用户转到新的系统上工作，或者他原有系统的主板损坏挂了，将步骤18中的备份密钥重新复制到新的系统上，然后将密钥数据块从备份服务器拷贝到新系统上。这样一来用户就可以重新工作了。

总结

现在你已经看到了TPM用于密钥管理的功能，它可以根据用户的需求实现非常简单或者非常复杂的密钥管理方案。这些需求可以是具有幻想狂的企业担心间谍活动，包括窃取机器等，一直到正常的家庭用户，他们仅仅希望自己的密钥在自己的家庭系统上安全存储。通过精心设计密钥组织架构并正确地设置密钥的授权和Policy，你就可以保持密钥安全可用。