轉載測試 自己總結了一下TSS的相關資料，簡介一共分為五大部分：
1. TPM Internals
2. TPM Device Driver(TDD)
3. TCG Device Driver Library(TDDL)
4. TCG Core Services(TCS)
5. TCG Service Provider(TSP)
0. TSS簡介
TSS是與TPM進行交互的核心軟件部件，TSS的設計規范由TCG頒布，到目前為止版本號為1.2，並且廠商自行設計的TSS必須符合TSS1.2標准。TSS的構成如圖所示，那么TSS的設計目的有以下四個方面：
（1）為應用程度提供到TPM功能服務的單入口點；
（2）提供對TPM的同步訪問；
（3）按標准構建字節流隱藏應用程序所構建的命令流；
（4）TPM資源的管理。
一般說來，TSS就是使用戶可以使用TPM所提供的相關服務，這些服務包括：完整性度量及報告、認證功能和加、解密服務等。
一、TPM Internals
TPM的內部構造，只介紹主要的幾個部分，如下
1. I/O
管理流經通信總線的信號流，典型的 LPC總線 (Low PinCount Bus)。
2. Execution Engine
是一個微控制器，用於對命令碼的校驗、解析及執行，並控制內部執行流。（類似於PC中的CPU）
3. SHA-1 Engine (160 bits)
主要被TPM使用，作為其可信的哈希算法。在平台啟動過程中，其接口暴露在TPM外以進行度量工作，由CRTM使用，但不由應用程序使用。未來的TPM版本會加入更多的哈希算法。
4. RNG
TPM內部的隨機源，偽隨機生成器。用於生成Nonce , 密鑰等。
5. RSA Engine and Key Generator
用於非對稱密鑰的生成(RSA；存儲SK及AIK 密鑰大小 >= 2048)，它支持 512, 1024, 2048 bit的密鑰，規范中建議使用2048位的密鑰。RSA密鑰生成遵循PKCS #1標准，在規范中其RSA公鑰必須是0x10001。RSA密鑰在使用的時候要加載到TPM內部。
6. Volatile Memory
里面包括：密鑰槽(10個)、 PCR值(24個)，密鑰句柄、授權會話句柄等。（類似於PC中的內存）
7. Non-Volatile Memory
包括EK(2048bit)、EK證書，SRK(2048bit)及屬主(Owner)授權數據(160bit)等。（類似於PC中的硬盤）
8. Opt-In
平台屬主決定是否使用TPM。（類似於PC中的power鍵）
PS:括號中的"類似於"只是幫助理解TPM的內部構造。另外提一下，TPM+CRTM+TSS構成了可信平台的子系統，該子系統可以用在PC、PDA、mobilephone、PS3、XBOX等通信設備系統中，增強該系統的安全性及可信性。
TDD這一部分就不介紹，具體可參見TIS標准。
二、TDDL
TDDL是TSS用於和TPM通信的組件，它是運行於用戶空間的第一個TSS組件，提供了內核模式到用戶模式的轉換。在TSS規范中，它也處於TCS和TDD之間，為TCS提供接口TDDLi，這里TDDLi是一個單線程同步接口，發送到TDDLi的TPM命令都已經被串行化。那么對於直接訪問TPM設備的程序，TDDLi提供了7個功能函數，用於和TDD進行通信。這些函數包括：
Tddli_Open()、Tddli_Close()、Tddli_TransmitData(…)、…
值得說明的是，TDDL必須僅提供對TCS的鏈接。在這一部分，主要對TPMCommands以及授權協議作一下介紹。
1.TPMCommands
下面來具體介紹一下TPM Command。TPMCommands就是TPM可以直接理解的命令，用這些命令可以直接訪問TPM，如圖：
這樣一個簡單的詢問PCR數量的命令交互過程就完成了。傳輸以及接受到的命令流都是以圖中十六進制方式表示的。
2. 授權協議（Authorization Protocols）
授權是指，能夠證明請求者擁有執行某個TPM功能和使用某些對象的許可。用雙方共享秘密(授權數據 )進行證明，無其他方式。
授權數據是一個在用戶和TPM之間共享的160bit秘密值，該秘密值由用戶創建，可以看做是password。SRK及TPMOwner的授權數據要保存在TPM內部非易失性存儲區內，而其他對象的授權數據則要與其自身進行綁定。當我們在編寫關於TPM程序的時候，授權數據在策略對象里設置。
在TPM中授權協議有很多，僅介紹其中有代表性的兩個協議：對象無關授權協議(OIAP)以及對象相關授權協議(OSAP)。
（1）ObjectIndependent Authorization Protocol (OIAP)
為提高效率而設計，在一個授權會話中可以驗證一個或多個不同的對象；
驗證的過程使用雙方共享的秘密值(授權數據)；
（2）ObjectSpecific Authorization Protocol (OSAP)
在一個授權會話中僅對一個對象進行操作；
設置或重新設置授權數據的時候使用該協議；
下面用一個例子來說明這兩個協議的使用，該例子說明的是一個密鑰的創建-》加載-》使用整個過程所使用的授權協議，如圖所示：
總的說來，這兩個協議基於的是傳統的"挑戰-響應"認證方法，比較容易理解。
三、TCG Core Service
此部分將詳細介紹TCS核心服務，為什么要有這個服務呢？首先分析一下TPM所存在的一些缺陷，如下：
（1）一次只有一個操作可以進行；
（2）由於硬件的限制，TPM處理速度很慢；
（3）有限的資源，包括密鑰槽、授權槽等；
（4）只能通過一個驅動程序與其進行串行通信；
（5）本地軟件與之通信是有限制的。
針對這些缺陷，TCS采取如下的方法：
（1）可以對多個TPM待處理的操作進行排隊；
（2）對於不需要TPM處理的操作，TCS可以自行作出響應；
（3）對TPM有限資源進行管理，可看做是無限的資源；
（4）將輸入輸出的數據進行相應的轉換；
（5）可以對資源提供本地的或者遠程的調用方式。
那么TCS的特點又有哪些呢？
（1）TCS是一個后台服務（類似於Linux下的daemon，或者windows下的system service）;
（2）它為TSP提供標准的接口TCSi（稍后介紹）；
（3）TCG標准中，TCS是唯一一個可以直接訪問TPM的實體；
（4）每個TPM僅對應一個TCS（注意：TCS並不提供加解密功能）；
（5）對TPM有限的資源進行管理（密鑰、證書管理，以及上下文的管理）；
（6）TCS負責調度要操作的TPM命令（注意：每個操作都是原子操作，並且允許多線程訪問）；
（7）TCS將上層的命令轉換為TPM命令格式。
對於（4）~（7）這四個特點來說，我們可以將TCS視為一個軟件的TPM。就其本質來說，TCS就是一個管理服務。
1. TCS Interface(TCSi)
它類似於C語言接口（說C接口只是為了方面討論而定義的基准，其實並不是這么做。真正的TCS接口定義在TSS發布的.wsdl文件中，實為Web服務。），允許多個線程訪問TCS，每個操作都是原子操作，它作為系統進程存在，TSP與之的通信有可能是RPC，如圖。
2. Manager Services
用文字敘述較為困難，做了幾個圖來具體介紹一下TCS所提供的管理服務，如圖：
（注意：這里的Persistent Storage與之后介紹的TSP層的PersistentStorage不是同一個貯存區，他們各自有其貯存區，在TCS層僅有一個貯存區，而在TSP層則針對不同的用戶有不同的貯存區。
