3.6 可信计算平台的运行模型
TPM的运行模型需要从TPM初次通电时开始考虑，这时，往往还处于TPM的生产过程中，TPM还没有交到用户手上。TCG为TPM定义了多种运行模式（也称为状态），以适应在多种应用场景中对TPM进行部署和维护。
以TPM的配置模式为基础，可以确定平台的配置模式，从而确定系统的引用监控机和应用程序的运行模型。
在考虑平台的运行模型问题时，也要考虑系统组件与TPM及其支持的服务之间的相互作用问题。
下面介绍TPM的工作状态、平台的工作方法、平台的软件接口和TPM命令的授权验证等方面的问题。
3.6.1 TPM的工作状态
以下相互独立的操作模式可以制约TPM的行为。
（1）启用/不启用：在系统的一个引导周期内，可以对TPM进行多次启用和不启用的设置。设置为不启用时，除了报告TPM的能力和接受对PCR寄存器的更新外，TPM限制其他所有的操作；设置为启用时，TPM的所有功能都起作用。
（2）激活/不激活：不激活与不启用相似，但它允许改变TPM的操作状态（即改变属主，或现场激活）。设置为激活时，TPM的所有功能都起作用。
（3）已建立属主/未建立属主：TPM中的EK是否已存在，标志着平台的属主是否已经建立，如果TPM中已经有EK，则属主已经建立；如果TPM中还没有EK，则属主尚未建立。平台的属主可以执行包括改变操作状态在内的所有操作。
这些模式是相互独立的，但可以有重叠的效果。如果同时设置了两种模式，其中一种模式使得TPM的某些功能起作用，另一种模式使得TPM的对应的功能不起作用，则优先权赋予使得功能不起作用的模式。
TPM的很多命令对管理操作状态的策略有控制作用，这些命令由一些状态变量进行限定，这些状态变量限制对设置操作状态的命令的访问。例如，有些命令要求操作员必须在现场进行操作，借助现场操作来控制对平台的激活、启用和属主建立等状态的改动。
平台的制造商应该为平台配置默认的操作模式，该模式能够使系统处于一种保险而灵活的状态下，可方便地对属主进行配置，表3-1给出的就是这样的一种模式。
表3-1 建议平台制造商设置的默认操作模式
表3-1描述了操作状态和需要现场改变操作模式的输入控制状态，从本质上说，除了由平台属主执行的状态改变之外，其他所有的状态改变都要求通过现场操作来实施。
可以把平台的TPM临时设置为不激活，这可以通过按下键盘上的一系列按键的方法来实现，系统复位时，可以把TPM重新设置为激活。临时激活不影响永久激活的值，它为操作员在短时间的交互作用后把TPM设置为不激活提供了方便。
下面通过几个例子说明在不同的平台部署场景中设置TPM的操作模式的方法，在这些例子中，假设所有的平台在出厂时都是按照如表3-1所示的默认操作模式进行配置的。
例3.2 设一个可信计算平台归一个IT企业所有，由该IT企业负责管理，试说明使用该可信计算平台涉及的TPM操作模式配置情况。
解答：设该IT企业的资产管理部门接收该平台，将其登记造册，平台的销售商为TPM生成EK，资产管理部门建立TPM的属主，同时确定属主的授权数据，授权数据和EK的公钥记录到资产登记册中，此时，属主已经建立，可关闭“可以建立属主”标记，TPM的操作模式如下：
● 可由属主启用 = False；
● 可由任何人启用 = False；
● 可以建立属主 = False（已被改变）；
● 已经建立属主 = True（已被改变）；
● 已永久激活 = False；
● 已临时激活 = False。
把平台送到使用地点，连接到企业网络中，由资产管理部门执行远程启用，部门的技术人员对软件和管理功能进行配置，然后激活TPM。此时，TPM的操作模式如下：
● 可由属主启用 = True（已被改变）；
● 可由任何人启用 = False；
● 可以建立属主 = False；
● 已经建立属主 = True；
● 已永久激活 = True（已被改变）；
● 已临时激活 = False。
平台已经准备就绪，可以把它交给使用者使用了，此时，TPM各种功能都能够正常作用，可以进行完整性度量，可以报告平台配置。
例3.3 设一个可信计算平台归一个客户所有，试说明使用该可信计算平台涉及的TPM操作模式配置情况。
解答：销售商把平台卖给客户，并帮助客户建立属主，同时避免掌握属主的口令字符串。客户选择不启用TPM。至此，属主已经建立，可关闭“可以建立属主”标记，其他操作模式没有变化，TPM的操作模式如下：
● 可由属主启用 = False；
● 可由任何人启用 = False；
● 可以建立属主 = False（已被改变）；
● 已经建立属主 = True（已被改变）；
● 已永久激活 = False；
● 已临时激活 = False。
例3.4 设一个可信计算平台归一个客户所有，通过外包服务的方式进行管理，试说明使用该可信计算平台所涉及的TPM操作模式配置情况。
解答：销售商把平台卖给客户，把平台的管理服务外包给专业的服务公司。服务公司建立属主，并把平台设置为可进行远程管理的状态。由客户决定是否激活TPM。此时，TPM的操作模式如下：
● 可由属主启用 = True（已被改变）；
● 可由任何人启用 = False；
● 可以建立属主 = False；
● 已经建立属主 = True（已被改变）；
● 已永久激活 = False；
● 已临时激活 = False。
客户只有在与外包服务公司沟通时才能使用TPM的功能，使平台复位，并在可以执行管理功能时激活TPM，若想以匿名方式使用Internet，则可按下键盘上的一系列按键，把TPM设置为临时不激活。此时，TPM的操作模式如下：
● 可由属主启用 = True；
● 可由任何人启用 = False；
● 可以建立属主 = False；
● 已经建立属主 = True；
● 已永久激活 = True（已被改变）；
● 已临时激活 = True（已被改变）。
当客户使用Internet时，管理行为暂被阻止，客户重新启动计算机时，TPM回到已永久激活状态，管理行为又恢复正常。
当平台管理的外包服务合同到期时，客户可以换服务公司，在这种情况下，需要把“可以建立属主”的标记设为True，然后，让新的服务公司执行建立属主操作，成为新的属主。
以上几个例子仅展示了平台的几种配置选项，不同的平台部署模型具有不同的最佳操作模式配置方法。
3.6.2 平台的工作方法
当平台开始操作时，它必须从RTM开始启动，RTM掌握它自己及其他可信构件块的信息，这里所说的可信构件块就是RTS和RTR等。TPM的启动状态等价于系统的初始化状态，当平台接通电源开始启动时，RTM必须给TPM发信号，指示它启动初始化过程。TPM的初始化过程包括TPM的自检过程，该自检过程检测该TPM的各项功能是否正常。
不同的电源管理模式可以影响TPM的初始化过程，RTM负责选择和控制最合适的TPM初始化过程，TPM会根据RTM的操作做出相应的响应。以下是TPM设备可能遇到的电源管理模式。
● 初始通电：TPM必须把所有的PCR寄存器设置为零，并使控制标记复位；
● 睡眠：TPM必须把易失性状态保存到永久存储器中；
● 恢复：TPM必须恢复此前保存的状态；
● 休眠：TPM没有与此相对应的电源状态，系统必须保存易失性状态。
以上这些操作是与平台密切相关的，不同的平台可能实施不同的具体操作方法，平台相关的规范必须详细描述各种有效的平台状态及相应的TPM响应方法。
作为系统初始化操作的一部分，系统将对平台的组件和配置进行度量，不过，初始阶段的度量操作既不检测是否存在不保险的配置也不采取任何行动去阻止初始化过程的继续推进，这样的任务应该由系统中的引用监控机（如操作系统等）负责完成，
初始阶段的度量完成之后，下一步的度量将由操作系统的程序装载器实施，它在把一个程序装载到内存之前对该程序进行度量。由于操作系统帮助实施系统的完整性，对于描述软件配置中不良状态的策略，可以由操作系统的程序装载器进行度量和实施。
平台可以对应用程序进行度量，应用程序也可以对平台进行检查。应用程序可以拥有描述可信平台配置的策略，因而，它可以辨别平台的配置是否可信，如果发现有不可信的情况，它可以拒绝与平台进行交互，或者限制与平台之间的交互。
这种平台与应用程序之间的双向度量的语义可以扩展到其他平台，进而为分布式应用程序的度量提供支持。分布式应用程序的各协作方在进行协作之前可以进行跨平台的交叉检查，从而确保分布式协作的顺利进行。
3.6.3 平台的软件接口
TCG采用通用计算平台中常用的软件服务的结构层次划分思想，为可信计算平台定义了三层软件接口，它们分别是设备驱动程序库接口（TDDLI，TPM Device Driver Library Interface）、软件核心服务接口（TCSI，TSS Core Service Interface）和服务提供方接口（TSPI，TCG Service Provider Interface），可信计算平台软件层次结构如图3.8所示。
在图3.8 给出的可信计算平台软件的层次结构中，从低层到高层，TCG定义了六层内容，底层是TPM，顶层是应用程序，由低到高的其他各层依次是TPM设备驱动程序、设备驱动程序库、软件核心服务和服务提供方。其中，TPM及其设备驱动程序是内核模式的内容，其他都是用户模式的内容。
在三层接口中，最下层的接口是TDDLI，这是上层软件访问设备驱动程序库的接口，属于用户模式的接口，与直接访问内核模式的设备驱动程序的接口相比，这样的接口有以下优点：
（1）它使得TCG软件栈（TSS，TCG Software Stack）的任何一种实现都能够与任何一种TPM进行正确的通信；
图3.8 可信计算平台软件层次结构
（2）它能够为TPM应用程序提供一种独立于操作系统的接口；
（3）它使得TPM的销售商可以向用户提供用户模式的TPM软件仿真程序。
设备驱动程序库（TDDL）实现用户模式与内核模式之间的切换。不过，TDDL不处理线程级别的软件与TPM的交互，也不对TPM命令进行系列化处理，这些任务由软件栈中的高层组件去完成。另外，TPM不支持多线程的访问，只接受单线程的访问，所以，对于每个平台，在任何确定的时刻，只能有一个TDDL实例存在。
中间层的接口是TCSI，它是上层软件访问一组通用的平台服务的接口。虽然在一个平台上可以存在多个服务提供方，但是，TCSI为它们提供共同的软件核心服务，使它们可以呈现共同的行为。软件核心服务层提供以下几个核心服务。
● 环境管理：实现线程级的TPM访问，支持线程访问TPM；
● 凭证与密钥管理：存储与平台关联的凭证和密钥；
● 度量事件管理：管理事件日志记录，管理对关联的PCR寄存器的访问；
● 参数块生成：负责TPM命令的系列化、同步和处理。
软件核心服务层以系统进程的形式在用户模式中工作，可以相信它能够管理用户向TPM提供的授权信息。
最上层的接口是TSPI，这是应用程序访问TPM的C语言接口。服务提供方（TSP）层与应用程序在相同的进程地址空间中工作，有关用户授权方面的工作在这一层进行。授权操作可以通过本层的代码提供的用户接口实现，也可以通过软件核心服务层的回调（Callback）机制实现（如果是远程调用的话）。为了给最终用户提供一个一致的授权接口，本地应用程序不必提供授权服务，它们可以依靠平台中固有的服务来完成授权操作。
TSP层提供环境管理和加密处理两种服务。环境管理器通过动态的句柄来为应用程序和TSP资源的有效利用提供支持，每个句柄为一组相关的TCG操作提供一个环境，应用程序中的不同线程可以共享同一个环境，每个线程也可以拥有自己的独立环境。
为了全面利用TPM提供的保护功能，系统应该提供加密支持功能，不过，TSP层只提供平台操作所必需的相应支持，典型的支持功能包括消息摘要计算和字节流生成等。TSP层没有提供诸如大宗数据加密等方面的接口。
设备驱动程序接口（TDDLI）、软件核心服务接口（TCSI）和服务提供方接口（TSPI）确定了TCG的可信计算平台的软件接口规范。根据这些接口规范，可以方便地建立可信计算平台的软件系统及基于可信计算平台的应用系统。
TCG的可信计算平台可以在新的应用基础架构上为应用系统提供支持，也可以在现有应用基础架构上为应用系统提供支持。图3.9给出了基于TCG的可信计算平台的三种典型的应用支持方案。
图3.9 可信计算平台典型应用支持方案
在应用支持方案一中，应用系统直接建立在TCG的可信计算平台之上。在方案二中，应用系统建立在TCG的可信计算平台与一个现有的加密与安全服务的基础架构之上。在方案三中，远程应用系统建立在TCG的可信计算平台与远程过程调用（RPC，Remote Procedure Call）机制之上。
下面借助例子来简要说明应用系统通过各种接口获取可信计算平台提供的服务的基本方法。
例3.5 设一个应用系统直接建立在TCG的可信计算平台之上，应用程序根据TPM中的PCR寄存器的值和验证凭证中的值验证平台的配置，试说明验证的过程。
解答：验证过程包含以下步骤：
● 对应用程序对象进行初始化，为读取PCR寄存器的值做准备；
● 读取寄存器PCR5的值；
● 对比PCR寄存器中的值与验证凭证中的值。
在应用程序层、服务提供方层、软件核心服务层和TPM层需要实施的操作如下：
（1）应用程序层。
{
Tspi_Contest_Create( &hContext);
Tspi_Context_Connect(hContext, NULL);
Tspi_Context_GetTpmObject(hContext,&hTPM);
Tspi_TPM_PcrRead(hTPM, 5, &ulPcrValueLength, &rgbPCRValue);
Compare(correctValueOfPCR5, rgbPCRValue);
}
（2）服务提供方层。
当Tspi_TPM_Quote( )被调用时，软件核心服务层要求把用于对PCR寄存器值签名的密钥装载到TPM中，这可以由Tspi_Context_LoadKeyByUUID命令完成。
还需要生成一个能够表示要读取的PCR寄存器值的PcrComposite索引，这可由Tspi_PcrComposite_SelectPcrIndex命令完成。
该命令执行时，要调用Tcsip_Quote命令。
Tcsip_Quote命令实现对PCR寄存器值的签名和检索。
{ …
hKey=Tcsip_LoadKeyByBlob(ikey); //装载由哈希值标识的密钥
Tcsip_Quote(hKey, …); //检索签过名的PCR寄存器值
… }
软件核心服务层的命令将通过设备驱动程序库命令调用设备驱动程序。
（3）软件核心服务层。
{ …
loadKeyMsg=PBG_LoadKey(hKey); //编制TPM_LoadKey命令
quoteMsg=PBG_Quote(); //编制TPM_Quote命令
Tddli_Open(); //打开TPM通信信道
Tddli_TransmitData(loadKeyMsg); //发送命令并接收响应
Tddli_TransmitData(quoteMsg); //发送命令并接收响应
Tddli_Close(); //关闭与TPM通信的信道
… }
（4）TPM层。
接收到装载密钥（loadKeyMsg）和检索PCR寄存器值（quoteMsg）的消息时，TPM顺序地对命令块进行分析，并执行相应的操作。
例3.6 设一个应用系统建立在TCG的可信计算平台与一个现有的加密与安全服务的基础架构之上，试说明可信计算平台对应用系统的支持方法。
解答：可以调整现有的加密与安全服务基础架构（如PKCS11加密令牌接口标准的架构）中的固定令牌或智能卡存储功能接口，以便使现有架构能访问TPM设备，并利用TPM来存储和检索现有架构中需要使用的密钥（对称密钥或非对称密钥）。
例3.7 设一个远程应用系统通过本地的TCG可信计算平台获得可信计算支持，试说明远程应用系统读取本地平台上的PCR寄存器值的方法。
解答：远程的应用程序与本地的TPM进行交互。设应用程序直接与软件核心服务层（TCS）对话，TCS通过远程过程调用（RPC）机制实现。远程应用程序向它的宿主系统的TCS发出读取PCR寄存器值的命令，该TCS通过它的参数块生成器编制TPM消息（loadKeyMsg和quoteMsg），并把它们传给RPC机制。
远程系统的TCS执行的操作如下。
{ …
loadKeyMsg=PBG_LoadKey(hKey); //编制TPM_LoadKey命令
quoteMsg=PBG_Quote(); //编制TPM_Quote命令
RPC_Open(); //打开TPM通信信道
RPC_Send(loadKeyMsg); //发送命令并接收响应
RPC_Send(quoteMsg); //发送命令并接收响应
RPC_Recv(loadKeyMsg); //发送命令并接收响应
RPC_Recv(quoteMsg); //发送命令并接收响应
RPC_Close(); //关闭与TPM通信的信道
… }
远程系统的RPC机制把命令发送给本地系统的RPC机制。本地系统的RPC机制接收到远程系统发来的信息后，把它们传递给本地系统的TCS进行处理。
本地系统的TCS执行的操作如下。
{ …
RPC_Recv(loadKeyMsg); //接收命令
RPC_Recv(quoteMsg); //接收命令
Tddli_Open(); //打开TPM通信信道
Tddli_TransmitData(loadKeyMsg); //发送命令并接收响应
Tddli_TransmitData(quoteMsg); //发送命令并接收响应
Tddli_Close(); //关闭与TPM通信的信道
RPC_Send(loadKeyMsg); //发送应答信息
RPC_Send(quoteMsg); //发送应答信息
… }
这样，远程系统的TCS把请求信息发送给本地系统的TCS，本地系统的TCS把请求信息传递给本地系统的TPM，本地系统的TPM执行相应的命令，并通过本地系统的TCS和远程系统的TCS把执行命令后产生的应答信息发送给远程应用程序。
以上三个例子展示了可信计算平台的软件接口在实际应用中的基本用法，同时展示了TPM功能的基本用法。
可信计算平台中的TPM功能可以由本地应用程序直接使用，也可以由本地应用程序通过其他组件间接使用，还可以由远程应用程序远程使用。
3.6.4 TPM命令的授权验证
在可信计算平台中，TPM外部的实体通过给TPM发出命令而获得TPM提供的功能。实体向TPM发出的所有对安全或隐私有影响的命令或透露平台秘密的命令必须在得到授权的情况下才能执行。
定义3.9 确定一个发出TPM命令的实体是否拥有执行该命令的合法授权的过程称为TPM命令的授权验证。
为了通过命令的授权验证，实体在发出命令的同时必须提供一个与该命令相关的秘密，是否知道该秘密是衡量实体是否拥有相应授权的准则。
1.命令验证方法
任何实体（如进程、线程或嵌入式控制器等）都可以向TPM发出命令，为了使命令能够在可信的环境下产生可信的效果，平台需要在实体与TPM之间建立一个安全的通信信道，用于实施命令的发送和结果的返回。
可以采用面向会话的消息交换方法中的“请求-响应”语义来实现实体与TPM之间的安全通信信道，通过建立会话来确保实体在合法授权的约束下访问TPM的对象（如密钥、密钥块和离散部件等），一个会话对应一个安全的通信信道。命令授权验证会话如图3.10所示，说明了在实体与TPM之间建立用于进行命令授权验证的会话的基本原理。
由图3.10可知，一个会话由一个会话标识、一个即时随机数、一个消息摘要和一个瞬时秘密构成。一个会话的两个端点拥有相同的会话标识、不同的即时随机数。消息摘要与在两个端点之间交换的消息相对应。瞬时秘密用于把消息绑定到TPM中一个明确的命名对象上，也可以用于在消息交换过程中实现加密。
图3.10 命令授权验证会话
为了成为会话的一个端点，从而加入授权的消息交换的行列，实体必须提供一个同时用于进行身份认证和授权验证的秘密，该秘密通常是一个160 比特的口令字符串，也称为授权数据。选择长度为160比特是为了与SHA-1运算结果的长度保持一致。
授权数据可以与TPM的对象、TPM本身或命令接口相关联，分别用于验证访问TPM的对象、访问TPM或执行相应命令的合法性。
为了实现执行TPM命令时的授权验证，有必要定义有效的命令验证协议。命令验证协议可以使用基于哈希的消息认证码（HMAC，Hashed Message Authentication Code）来建立实体与TPM间的授权会话。
在会话双方共享密钥的前提下，HMAC可用于确定在会话中交换的消息是否已被篡改。消息的发送方计算原始数据的哈希值，并将原始数据和HMAC放在一个消息中传送。消息的接收方接收到消息后，重新计算所接收的数据的哈希值，检查计算所得的哈希值是否与传送的哈希值匹配。
在授权的会话中交换的一个消息可以表示成包含以下三部分内容的一个框架。
● 消息容器：标识消息的类型、长度和格式；
● TPM命令：命令名、输入/输出参数和返回代码；
● 会话状态：会话标识、控制标志和会话消息的摘要值。
在“请求-响应”协议中，会话中的TPM和发出命令的实体在把会话向前推进一步之前，都会对会话消息进行验证。会话状态中包含即时随机数，可以避免会话中的重放攻击。
2.命令验证协议
TCG为实现TPM命令的授权验证定义了五个协议，分别称为授权数据插入协议（ADIP，Authorization Data Insertion Protocol）、授权数据修改协议（ADCP，Authorization Data Change Protocol）、非对称授权修改协议（AACP，Asymmetric Authorization Change Protocol）、对象无关的授权协议（OIAP，Object-Independent Authorization Protocol）和对象相关的授权协议（OSAP，Object-Specific Authorization Protocol）。
其中，ADIP、ADCP和AACP用于创建和管理授权信息，这些信息包含在TPM控制下的对象中；OIAP和OSAP用于建立由前面三个协议支撑的授权的会话环境。
ADIP、ADCP和AACP的语义紧密地集成在TPM的管理命令之中，TPM没有为其提供一般化的接口。
OIAP和OSAP的使用方法与TPM的一般命令类似，由TPM的命令解释器负责解释，它们拥有对应的TPM命令接口和系列化方法。TPM_OIAP( )和TPM_OSAP( )命令用于对会话对象进行初始化，初始化可以得到会话对象的相应句柄，需要进行授权验证的TPM命令将会引用相关的句柄。
OIAP可以在TPM与一个外部实体之间建立一个授权的明文会话，软件核心服务层（TCS）为OIAP会话的管理提供了有力的支持。OIAP的消息交换过程如图3.11所示。
图3.11描述了TCS、OIAP会话和TPM三者之间的协同作用。如果把TPM所在的平台看做本地平台，则TCS和OIAP对象既可以在本地平台上，也可以在远程平台上。TCG重点关注TPM端点的保护，同时兼顾TCS端点的安全。OIAP消息交换主要发生在OIAP会话与TPM之间，TCS消息交换提供了一个环境，该环境描述如何使用OIAP会话。
图3.11 OIAP的消息交换过程
图3.11中的第1～5步建立一个OIAP会话，第16步和第17步清除一个会话，在一个会话中，可以处理多个TPM命令，如第6～15 步所示。TCS代理可以确定什么时候将不再有新的命令发出，于是在执行最后一个命令的消息中设置一个标志，以触发会话的清除操作。
OIAP通过为所有交换的消息计算消息认证码（MAC）来确保消息的完整性，它使用HMAC方法，以一个秘密和一个消息数据的哈希值为输入，产生一个20字节的输出。
输入中的秘密就是即时随机数，OIAP定义了两种即时随机数，分别用于一个会话的两个端点，图3.11中的会话端点在第4步和第9步交换即时随机数值，第4步还提供会话标识。
输入中的秘密与消息数据的组合的哈希值构成了会话MAC。一个会话包含如下两种逻辑结构。
（1）TPM命令：包括参数和返回码，MAC计算中实际使用的是TPM命令域的SHA-1哈希值；
（2）会话配置参数：包括会话标识、即时随机数和控制标志，在HMAC计算中会用到会话配置参数。
OSAP的思想与设计和OIAP非常相似，它在OIAP语义的基础上增加了新的约束，一方面把授权的会话绑定到TPM的对象上，另一方面使用了瞬时秘密。OSAP的消息交换过程与OIAP的消息交换过程的区别在于OSAP对OIAP消息交换过程中的以下两个步骤进行了扩充：
（1）在第2 步中标识TPM的目标对象，并提供第三个即时随机数（在OIAP使用了两个即时随机数的基础上）；
（2）在第4步中提供第四个即时随机数。
增加的即时随机数用于为会话生成瞬时秘密，该瞬时秘密用于计算MAC，还可以用于对数据进行加密。
OSAP对于更新与TPM所管理的对象相关联的敏感信息特别有用。
ADIP用于为TPM管理的对象建立新的实例，TPM_CreateWrapKey( )命令使用该协议。创建新的对象实例时，发出命令的实体可以提供一个口令字符串，由ADIP把该口令字符串与新建立的对象实例关联起来，这样，要访问该对象实例，必须提供相应的口令字符串，从而实现对象实例的授权访问。
ADIP为OSAP提供支撑，以便在实体与新对象实例（即子对象实例）的父对象实例之间建立授权的会话，使用ADIP创建对象如图3.12所示。
图3.12 使用ADIP创建对象
子对象实例的授权数据通过XOR运算借助OSAP的共享秘密进行加密，TPM借助该共享秘密通过XOR运算对授权数据密文进行解密。
ADCP用于更新TPM管理的对象的授权数据，TPM_ChangeAuth( )命令使用该协议，该协议为ADIP提供隐私性和完整性支撑，并为对子对象实例的授权访问增加OIAP（或OSAP）会话。使用ADCP更新子对象的授权数据如图3.13所示。
图3.13 使用ADCP更新子对象的授权数据
TPM管理的大多数对象都能适应“父-子”关系模型，但也有例外。例如，从逻辑意义上说，SRK是存储子系统的根，对于此类情形，TPM可以利用EK授权数据为SRK建立ADIP会话，进而兼容ADCP协议。
AACP用于实现在不让父对象实例知道子对象实例的授权数据的情况下更新子对象实例的授权数据，TPM_ChangeAuthAsymStart( )和TPM_ChangeAuthAsymFinsih( )命令使用该协议。
当多个实体共享父对象实例的授权数据时，如果某些实体没有获得访问子对象实例的授权，那么，使用ADCP就存在一定的安全威胁，对SRK的直接子对象实例的访问很有可能出现这种情形，AACP可以防止这样的威胁。