[音乐]
[音乐]
同学们好， 今天我们来介绍一下 TPM 身份认证的问题。
那么 TPM 的身份认证呢，是 TPM 的很重要的一个功能。
那么我们来看一下到底应该如何认证，它是才是比较合理的。
我们首先来看一下，我们给出两个方案啊，这两个方案它存在一些安全问题。
比如说第一种方案，就是说假设每一个 TPM 都有自己的 EK。
就是都用自己唯一的 EK 对 PCR 签名。
这样做呢其实比较好实现呢，而且这个认证 也确实是因为
EK 是唯一的，所以要去认证是
能够证明它的真实性，但是因为没有完全没有去匿名， 就是说这个 EK 完全没有做隐藏。
那么所以的话，假设有一些这个 验证者相互之间串通，那么他们有可能通过合谋的方式
可以去跟踪这个 EK ，最终破解，最终破解。
第二种方案呢，就是说假设所有的 TPM
芯片 公用一对签名密钥，虽然这样做呢，就完全
实现了匿名，就是说因为所有的 TPM
都统一用一对 这个秘钥来进行这个签名和验证的话。
那么用户是能够验证你是一个可信 TPM，但是他不知道到底是谁，对吧。
这样的话确实可以实现匿名，但是这样做它带来的问题就是说， 一旦某一个
TPM 被抽取了签名私钥，那么假冒的 TPM 就
没有办法被鉴别了，从而造成整个认证体系的崩溃，也就是说所有的 这个
TPM 都不存在安全性的问题了，就都会安全性这个防线就被打破了。
所以我们来看，这样的两种方法显然不能够成为 TPM 身份 认证的一个可选方案了。
那么到底如何来实现呢？ 事实上 TPM 在 1.1 和
1.2 的两个版本里面，就采用了两种不同的这样的认证方案。
我们先来看一下，这个第一种，就是 TPM 1.1
所采用的一种 叫 Privacy CA 的这种方法，这种方法呢，
其实这两种方法主要针对的还是我们怎么样对把 EK 用这个
AIK 的这个方法证书 来进行验证，就是
其实就是指的 AIK 信任状的颁发的这样的两种方法。
我们先来看这 Privacy CA 的方法了。
那 Privacy CA 这个方案采用的是主要核心思想是一次一密。
就是我签名的时候，你每次跟我验证的时候，我都提供不同的这样的
就是密钥对给你。
那么你这样的话，每次签的都不是相同的，我采用的不是同一个 这个密钥对。
那么这样的话呢，你没有办法知道我是谁，那么 TPM
对每一次认证都会产生一对不同的 RSA 的这个签名密钥对，就是 AIK。
并且引入了一个这个 CA 证书的中心。
证书权威叫 Privacy CA， 那么对这个 AIK 进行 证明，进行证明。
那么这样做的好处呢， 就是说每次认证的时候 TPM 只要将这个
AIK 签名的这个 PCR 值， 和这个 Privacy CA
对这个 AIK 的证明发送给这个验证者就可以了。
就是说 TPM 只需要签名给这个 Privacy CA。
那么 CA 呢只要把这个，如果验证通过以后，它只要把这个 AIK
的这个 就是证明的这个证书返回给这个 TPM 就可以。
那么在这个方案里面，TPM 的合法性就是由这个 Privacy CA 来负责。
那么由于它每一次认证的时候，TPM 都是向验证者出示 AIK 公钥。
都不相同，各不相同，所以验证者呢没有办法去分辨对方是不是同一个 TPM。
对吧，就是说它每一次都不一样，所以你，你没有办法去识别它是不是来自同一个 TPM。
所以就没有办法去跟踪，这样其实就保护了它的隐私性。
这个方案其实与传统的密钥证书的颁发过程非常类似啊。
当然这里有一个基本假设，就是这个 Privacy CA 必须是可信的。
也就说，这个 CA 如果不可信，那整个这套方法就没有信任基础了。
那么这个 AIK 的密钥对不是由 Privacy CA 来生成，是由这个 TPM 来生成。
怎么样获取这个 AIK 的这个证书呢，主要是由 TPM 将这个
EK 它的信任证书 和这个平台的信任证书，还有一致性信任证书，
以及用 EK 签名过的这个 AIK 的私钥， 发给这个
Privacy CA，那么 Privacy CA 对收到这个信任状进行检查，没有，发现没有问题的时候。
就会返回给 TPM 一个 AIK 的信任状。
那么以后 这个 AIK，就是这个 TPM 要向用户，向其他的这个
用户去鉴定他们身份的真实性的时候， 就只需要用这个 AIK 去对数据签名就可以了。
那么这个方案就是我们所说的 Privacy CA 的方案。
这是这张方案的这个图，它表述的是 这个 TPM 和 Privacy CA 之间的这个交互的过程。
和这个后面的这个 Verifier，就是我们的这个挑战方。
或是说我们需要去验证这个平台是不是来自一个 TPM 可信的 TPM 芯片的时候。
它跟 TPM 进行交互的时候，主要采用的就是这个 AIK 的签名
来进行验证，这是 TPM 1.1 的一个 Privacy CA 的方案。
那么下面我们看一下，就是在这个方案提出之后呢，主要是它需要有一个 这个
Privacy CA 另外它每一次认证的时候，都要去跟这个
都要跟 Privacy CA 进行交互，所以这三者呢，它的交互 次数比较频繁，比较频繁。
那么为了减少这些，就是 认证的这样的一次一密带来的这个复杂性。
那么后面这个又有研究人员提出了一种叫直接匿名
认证方案，这个方案它主要是以这个群签名的方案为基础，
和离散对数的零知识证明为基础，我们看一下什么是 群签名，那么群签名其实就是满足这样要求的一个签名。
就是在一个群签名方案里面， 一个群体中的任何一个成员可以以匿名的方式，
代表整个群体对消息进行签名。
那么验证的时候呢， 这个可以公开验证，就是说只要用单一的群公钥来进行验证就可以了。
比如说验证的密钥是一对，那么签名呢是可以， 比如说一个群体有
n 个成员就有 n 个 这样的签名密钥，这就是群签名的这样的一种方案。
那么零知识证明 我们也用到了，那么什么是零知识证明，那么零知识证明其实说的就是
这个要被证明的这个，就是说你要向它去被证明，示证者 要向这个验证者去表明它知道某种秘密。
不仅能够让这个验证者完全确信，它的这的确知道这个秘密。
而且在证明的过程当中，它还不能够去泄露给它任何信息。
这就是零知识证明的思想。
那么 DAA 呢其实就是以这两个 技术为基础来提供的。
那么它在做这个方案的时候呢，不需要假设任何一方可信，那么前面的 Privacy CA
方案里面，这 Privacy CA 必须是可信的，对吧，这里不需要做任何假设，那么它的这个验证过程包括两个 一个是
Join ，另外一个是签名和验证方之间的这样的两个过程。
那么在这个验证环节里面，它包含了四个方面，就是四方参与。
哪四方呢，第一方是 TPM 就是芯片，第二方呢是 TPM
所在的平台， 第三方呢，是这个我们所说的直接匿名验证的这个
颁发证书的这一方，叫 Issuer，最后这个是我们的这个验证方。
这是我们刚才提到的，它的一个总体的这样一个 两个过程，那么在这个过程里面，其实这个证明者
是要向这个凭证颁发者，通过匿名凭证被加密，那么 那么只有一个
TPM 才能获得这个证书，那么证书的申请必须借助我们的 TPM。
那么在这个 Sign 和 Verify 这阶段里面，就只有 TPM 掌握了匿名凭证的这个核心秘密。
也就是通过这个零知识证明来提供这个 TPM 的 验证。
我们具体来说一下这两个过程，第一个是 Join 这个 过程，那么
Join 过程其实就是来帮助 这个 TPM 获得 AIK 证书的这样一个过程。
那么在这个过程里面，其实是这个 DAA
的这个 证书的颁发者，它要生成先要生成一个发行密钥的这样的一个
公私钥，公钥，那么把这个公私钥 发给
TPM ，那么 TPM 收到这个证书以后， 收到这个证书以后，它会生成 DAA 的私钥。
就是自己会生成一个 Privacy 的 DK，使用 EK 自己的 EK
对它进行标示，标示，然后把这些信任状传给 Issuer。
那么 DAA 的 Issuer 呢，如果验证通过以后，就会向 TPM 返回一个 CertDK。
就是对这个 DK 进行，提供一个信任状。
所以这个 TPM 就会拥有 privDK 和这个 certDK。
那么以后这个 TPM 在验证的时候，就要只要用到这两个
去向这个 Verifier 验证就可以了。
所以在签名和验证的过程里面， 那么 TPM 生成的，
就是首先要生成这个 AIK 的对，那么这个 TPM 用这个
privDK，certDK 对这个 AIK 公钥进行签名。
签名之后呢，这个 Verifier 获得这个就是我们所说的 Issuer 的这个 key
证书以后，就可以确认这个 AIK 私钥是在一个 TPM 里面。
但是它其实不知道是在哪个 TPM 里面，对吧，所以 Verifier 对 AIK 就会去颁发这样一个信任状。
信任状，就是它是信任它的。
这就是我们所说的 DAA 的这样的一个身份验证的一个方案。
那么刚才我们提到了一个 Privacy CA 的方案，还有一个就是 DAA 的直接匿名方案，这是
TPM 所提供的 两个为了保证私密性，来验证平台身份的一个
非常有效的两种方案，好，这次课讲到这儿，谢谢。
