TSP是英文Trust Spanning Protocol的縮寫，翻譯為信任互聯(lián)協(xié)議。其中 ‘Spanning’ 也可以理解為 ’跨越‘，即跨越不同的信任域的協(xié)議?；ヂ?lián)網(wǎng)起源于不同的物理網(wǎng)絡(luò)之間需要 ’跨越‘ 的訴求，比如當(dāng)時(shí)的局域網(wǎng)有以太網(wǎng)(Ethernet)、Token Bus、Token Ring等多種，各自有自己的地址格式、物理介質(zhì)、和控制協(xié)議，加上局域網(wǎng)之間需要另一種廣域網(wǎng)來把它們聯(lián)接到一起，這就衍生了Inter-network 網(wǎng)絡(luò)之間的網(wǎng)絡(luò)的概念和協(xié)議(即 Internetworking Protocol 縮寫為IP)，簡稱Internet。

如果說IP協(xié)議聯(lián)接了不同的網(wǎng)絡(luò)，那么TSP協(xié)議可以理解為聯(lián)接了不同的信任域。TSP的作者最初把它叫做“信任域互聯(lián)協(xié)議”(Inter-Trust Domain Protocol or ITDP)。什么是信任域呢？信任域可以定義為一個(gè)采用統(tǒng)一的數(shù)字標(biāo)識(shí)符和信任認(rèn)證機(jī)制的計(jì)算機(jī)系統(tǒng)的集合。比如采用公開密鑰架構(gòu)(PKI)下的數(shù)字證書認(rèn)證機(jī)構(gòu)(CA)來給每個(gè)系統(tǒng)發(fā)放X.509格式證書，系統(tǒng)之間通過對(duì)X.509證書的認(rèn)證來驗(yàn)明真實(shí)身份，那么這樣的一群系統(tǒng)之間就可以互相“信任”了。在這個(gè)例子里，所謂的“信任”的基礎(chǔ)是大家都可以信任這些CA，尤其是根CA，我們把這樣的一群系統(tǒng)叫做一個(gè)信任域，信任域之內(nèi)的系統(tǒng)間的信任是可以有統(tǒng)一標(biāo)準(zhǔn)可以遵循的。

信任域可以有無數(shù)多個(gè)。即使是大家都采用同樣的PKI標(biāo)準(zhǔn)，每個(gè)不同的根CA可以派生出一個(gè)不同的信任域。同時(shí)不少應(yīng)用場景可能會(huì)采用不同的技術(shù)標(biāo)準(zhǔn)，比如證書的內(nèi)容、格式、線下的治理?xiàng)l例、甚至法律規(guī)章等都在造就不同的信任域。

單一的信任域不能完全包含整個(gè)互聯(lián)網(wǎng)里無數(shù)的系統(tǒng)和多元的應(yīng)用場景。比如，企業(yè)之間可能沒有上下附屬關(guān)系；國際之間可能無法統(tǒng)一對(duì)治理規(guī)則的認(rèn)可；針對(duì)每個(gè)個(gè)人的系統(tǒng)(或未來的AI Agent)的數(shù)量級(jí)會(huì)太大，導(dǎo)致集中由CA發(fā)布與管理證書的方式不現(xiàn)實(shí)成本高；另外單一的CA的安全風(fēng)險(xiǎn)可能太高，等等。這些因數(shù)導(dǎo)致互聯(lián)網(wǎng)中實(shí)際上采用PKI的系統(tǒng)常常是有限的，而且問題很多?；ヂ?lián)網(wǎng)的成功在于其分布式體系結(jié)構(gòu)，PKI的缺點(diǎn)則在于它的集中性，集中化的系統(tǒng)難以規(guī)?；y以接受多元化的應(yīng)用需求，系統(tǒng)維護(hù)成本不斷提高，而且有單一系統(tǒng)單點(diǎn)故障的風(fēng)險(xiǎn)。

這些新的挑戰(zhàn)需要用更加分布式的信任技術(shù)來克服。除去單一的中心化模塊才能讓整個(gè)系統(tǒng)滿足互聯(lián)網(wǎng)級(jí)別的規(guī)?；?，滿足無數(shù)種應(yīng)用場景的多元化要求，滿足區(qū)域之間數(shù)據(jù)治理的合規(guī)要求，以及克服單點(diǎn)故障的魯棒性要求，等等。

但是如果只是采用多種多個(gè)信任域，把互聯(lián)網(wǎng)分割成了一個(gè)個(gè)的孤島，那就違背的互聯(lián)網(wǎng)的初心和優(yōu)點(diǎn)了。所以我們必須同時(shí)發(fā)展一個(gè)可以讓不同的信任域能夠互聯(lián)又保持信任的機(jī)制，這就是信任互聯(lián)協(xié)議(Trust Spanning Protocol, or TSP)。

互聯(lián)網(wǎng)的原始設(shè)計(jì)本身不包含一個(gè)內(nèi)涵的信任機(jī)制，比如IP的地址和數(shù)據(jù)包內(nèi)容很容易被篡改，所以發(fā)送與接收雙方都不能確認(rèn)IP數(shù)據(jù)包是不是真的從源地址來，到目標(biāo)地址去，也不能確認(rèn)收到的數(shù)據(jù)是真實(shí)數(shù)據(jù)。因?yàn)榛ヂ?lián)網(wǎng)遍布全球的任何角落，無法在物理網(wǎng)絡(luò)層面克服這些問題，我們必須在上層協(xié)議上來解決。我們把這一類問題歸結(jié)為真實(shí)性問題(Authenticity)，包括發(fā)送和接收方的身份真實(shí)性(Identity Authenticity)，也包括數(shù)據(jù)的真實(shí)性(Message Authenticity)。對(duì)應(yīng)地講，就是我們需要一套身份標(biāo)識(shí)符及其認(rèn)證機(jī)制，加上數(shù)據(jù)簽名(或MAC)及其認(rèn)證機(jī)制。

第二類的問題是數(shù)據(jù)保密的問題(Confidentiality)。這類問題大部分開發(fā)人員和用戶都比較熟悉，即所謂的加密機(jī)制以保證沒有其他第三方可以讀到數(shù)據(jù)包中的內(nèi)容。也有人把這類問題叫做保護(hù)個(gè)人隱私，但只包括對(duì)數(shù)據(jù)內(nèi)容的隱私保護(hù)(Content Privacy)。為了準(zhǔn)確起見，我們采用私密性(Confidentiality)來表示這一類問題。我們熟悉的TLS協(xié)議就是主要用來支持私密性的。私密性一般必須首先滿足真實(shí)性，沒有真實(shí)性的話私密性也就無從談起，比如說A送一個(gè)私密信息給B，如果第三方C能夠冒充是B，那么什么加密都是沒有用的。所以我們需要把Authenticity和Confidentiality綁在一起使用。比如TLS采用X.509格式的證書來驗(yàn)證身份。

那么為什么需要設(shè)計(jì)一個(gè)新的協(xié)議而不直接使用成熟的TLS呢？首先，TLS(和相關(guān)的HTTPS協(xié)議等)采用PKI和基于X.509的證書。如上所述，這樣的系統(tǒng)無法滿足現(xiàn)代和未來互聯(lián)網(wǎng)的需求，我們希望采用分布式無中心點(diǎn)(即去中心化)的可認(rèn)證標(biāo)識(shí)符。其次，現(xiàn)有的TLS實(shí)現(xiàn)都只要求服務(wù)器端提供證書，不包括客戶端，從而導(dǎo)致客戶的認(rèn)證只能依靠微弱的密碼方式或損害隱私的聯(lián)邦認(rèn)證方式來實(shí)現(xiàn)。另外，即使采用雙向TLS，對(duì)客戶端和服務(wù)器都發(fā)證書，PKI管理的效率很低，所以證書數(shù)據(jù)的質(zhì)量非常微弱，實(shí)時(shí)性差，安全效益很低而部署成本很高。這也是X.509證書的使用沒有遍布互聯(lián)網(wǎng)的根本原因。我們認(rèn)為真正有效的解決方案需基于分布式系統(tǒng)。更重要的是，即使在某些應(yīng)用場景規(guī)模不大可以采用PKI下的X.509證書，它所提供的安全系數(shù)還是不強(qiáng)。比如TLS在認(rèn)證了證書之后通過協(xié)議產(chǎn)生一個(gè)對(duì)稱的密鑰，所以從根本上講無法區(qū)分發(fā)送方和接收方，也就不能滿足不可抵賴性。這些問題嚴(yán)重地限制可以實(shí)現(xiàn)的安全性和隱私保護(hù)的要求。

所以，我們需要一套新的更強(qiáng)的安全協(xié)議，基于分布式無中心的架構(gòu)，充分保證真實(shí)性和私密性，來作為未來應(yīng)用的安全基礎(chǔ)。這就是TSP協(xié)議設(shè)計(jì)的出發(fā)點(diǎn)。

TSP還提供了一套全新的工具來解決第三類問題：元數(shù)據(jù)的私密性(Meta-data Privacy)。這方面的問題在以前(包括TLS)的技術(shù)方案中考慮很少，但現(xiàn)在越來越影響到用戶的隱私。由于互聯(lián)網(wǎng)的底層(比如TCP/IP)沒有私密性，即使我們的應(yīng)用采用了端到端的加密，其數(shù)據(jù)流的TCP端口和IP地址等元數(shù)據(jù)還是可以在網(wǎng)上觀察到的，并且可以與其他信息聯(lián)合在一起從而了解到很多個(gè)人信息。TSP協(xié)議為解決這第三類問題提供了基于中間點(diǎn)(Intermediaries)的解決方案，即可保護(hù)元數(shù)據(jù)的私密性，又可以實(shí)現(xiàn)TSP系統(tǒng)的規(guī)?；瑵M足整個(gè)互聯(lián)網(wǎng)規(guī)模的需求。

綜上所述，在TSP協(xié)議中，真實(shí)性是首要保證的，同時(shí)可根據(jù)實(shí)際應(yīng)用需求選擇數(shù)據(jù)私密性和/或元數(shù)據(jù)私密性。TSP的主要技術(shù)特點(diǎn)可以總結(jié)為以下幾個(gè)方面：

• 多種多類可認(rèn)證標(biāo)識(shí)符(Verifiable Identifiers)，尤其包括去中心化標(biāo)識(shí)符(Decentralized Identifiers，DID)

作為信任域之間的橋梁，TSP是為多種類可認(rèn)證標(biāo)識(shí)符(Verifiable Identifier)設(shè)計(jì)的，包括去中心化的標(biāo)識(shí)符(DID)但不僅限于此。比如我們正在開發(fā)基于傳統(tǒng)X.509格式的did:x509，基于WEB的did:web，以及基于自認(rèn)證標(biāo)識(shí)符(Self-Certifying Identifier, SCID)的did:webs、did:tdw (trusted web)、和KERI AID等。未來可以出現(xiàn)更多的可認(rèn)證標(biāo)識(shí)符以滿足多元的應(yīng)用需求，只要它們滿足TSP定義的“可認(rèn)證性”的要求。

• 有方向性的信任關(guān)系(Directional Relationship)

A信任B并不代表B信任A，這是個(gè)常理，也常常是許多應(yīng)用的安全和隱私保障機(jī)制里重要的區(qū)分，但現(xiàn)有的安全體系一般都是不完全區(qū)分通訊的雙方的。TSP的基礎(chǔ)信任架構(gòu)是一種有方向性的信任關(guān)系(Directional Relationship)：A -> B，其中A和B以Verifiable Identifier來代表，而他們之間的通訊通過非對(duì)稱密鑰算法來實(shí)現(xiàn)。

• 采用基于非對(duì)稱密鑰的真實(shí)性和私密性保障(Public Key Authenticated Encryption)

同時(shí)保障真實(shí)性和私密性是大部分應(yīng)用場景的公共要求，但是以前的實(shí)現(xiàn)通常最終歸結(jié)為發(fā)送方和接收方之間的共享對(duì)稱密鑰的，從而在信任關(guān)系上無法區(qū)分他們，也不能滿足“不可抵賴性”(Non-Repudiation)。以前這樣的對(duì)稱性設(shè)計(jì)是因?yàn)樾б嬖?，?duì)稱性算法遠(yuǎn)比非對(duì)稱算法成本低，但也是源于Client/Server模式的信任關(guān)系：一般都是服務(wù)器方在主導(dǎo)從而私密性不是主要考慮。在TSP架構(gòu)下，通訊的雙方是對(duì)稱平行的。TSP采用公開密鑰認(rèn)證加密算法(Public Key Authenticated Encryption, PKAE)，基于RFC9180(HPKE)定義的格式，同時(shí)也支持開源軟件中常用的Nacl/Libsodium實(shí)現(xiàn)的Sealed Box。這兩種實(shí)現(xiàn)是基本一致的，我們希望將來他們會(huì)最終統(tǒng)一為一種兼容的實(shí)現(xiàn)。

PKAE本身仍然有一些值得重視的安全和隱私缺陷，比如在密鑰泄露時(shí)可能被第三方冒充的弱點(diǎn)(Key Compromise Inpersonation, KCI)，TSP通過發(fā)送方簽名來克服這個(gè)弱點(diǎn)。另外TSP采用ESSR算法來加強(qiáng)某些配置下的接收方不可冒充性的功能(Receiver UnForgeability, RUF)等。

結(jié)合這些非對(duì)稱性算法和協(xié)議技術(shù)，TSP為互聯(lián)網(wǎng)通訊提供了最安全又最私密的保障。

• 采用嵌套式信息包來加強(qiáng)元數(shù)據(jù)私密性(Nested Messages)

隨著互聯(lián)網(wǎng)應(yīng)用的普及，很多原先不太重要的設(shè)計(jì)細(xì)節(jié)的缺點(diǎn)浮出水面。元數(shù)據(jù)的泄露就是其中之一，包括IP、TCP、HTTPS等等協(xié)議的Header中的諸多信息。把這些元信息和其他個(gè)人信息交叉索引，尤其是采用AI算法，可以非常準(zhǔn)確地還原許多個(gè)人信息。所以個(gè)人信息的保護(hù)常常不能停留在數(shù)據(jù)內(nèi)容層面，也需要在元數(shù)據(jù)層面采取保護(hù)措施。TSP的嵌套式信息包可以隱蔽內(nèi)部真正使用的VID，避免被交叉索引算法所用。

• 采用路由信息包，通過中間點(diǎn)系統(tǒng)保證規(guī)?；瘜?shí)現(xiàn)，并同時(shí)加強(qiáng)元數(shù)據(jù)私密性(Routed Messages)

雖然點(diǎn)對(duì)點(diǎn)的信任關(guān)系是TSP協(xié)議的基礎(chǔ)，在實(shí)際部署中因?yàn)槎喾N原因，引入高性能的中間服務(wù)節(jié)點(diǎn)是至關(guān)重要的：幾乎所用的現(xiàn)代互聯(lián)網(wǎng)應(yīng)用都采用大型數(shù)據(jù)中心作為服務(wù)器；移動(dòng)手機(jī)應(yīng)用必須解決間斷性聯(lián)網(wǎng)的問題，某個(gè)服務(wù)器必須替不能永久聯(lián)網(wǎng)的節(jié)點(diǎn)作為信息存儲(chǔ)器；我們也需要解決用戶間互相發(fā)現(xiàn)的問題，大型中間服務(wù)可以幫助這方面的實(shí)現(xiàn)；同時(shí)網(wǎng)路的路由，以避開出問題的節(jié)點(diǎn)和不可信的資源等，仍然需要某種路由協(xié)議經(jīng)過中間節(jié)點(diǎn)來解決。

TSP不僅僅引入的中間點(diǎn)的結(jié)構(gòu)，同時(shí)設(shè)計(jì)了可以通過中間點(diǎn)加強(qiáng)對(duì)用戶元數(shù)據(jù)私密性保護(hù)的路由機(jī)制。TSP的路由機(jī)制為上層應(yīng)用提供在互聯(lián)網(wǎng)基礎(chǔ)上的端對(duì)端路由信息包(Routed Messages)通訊，其中的中間節(jié)點(diǎn)無需知道確切完整的路由途徑，從而為兩端的用戶提供又高性能又安全私密的通用信息包服務(wù)。如果有必要，上層應(yīng)用還可以將前一節(jié)里介紹的嵌套式信息包和路由結(jié)合在一起，更加加強(qiáng)路由協(xié)議下的元信息私密性。

• 支持最現(xiàn)代的加密和認(rèn)證算法，支持后量子計(jì)算加密和認(rèn)證算(Post-Quantum Cryptography, or PQC)

HPKE定義了一套指定加密和認(rèn)證算法的統(tǒng)一規(guī)格，因此TSP可以不僅支持現(xiàn)階段最新最現(xiàn)代的算法，而且可以在必要時(shí)快速地采用新的算法，無需TSP協(xié)議本身的改動(dòng)。這個(gè)優(yōu)點(diǎn)也包括了對(duì)后量子密碼算法的支持。TSP的另一個(gè)重要特點(diǎn)是每個(gè)TSP的數(shù)據(jù)都采用自編碼單元(Self Encoding)，這更是對(duì)協(xié)議的未來演變的高度保障(Future-Proof)。

• 采用高效益編碼系統(tǒng)

非常高效益的編碼系統(tǒng)又是另一個(gè)TSP的技術(shù)特點(diǎn)。TSP的數(shù)據(jù)包結(jié)構(gòu)(Message Structure，即用戶內(nèi)容除外的包的結(jié)構(gòu)部分)采用可組合事件流表達(dá)式(Composible Event Streaming Representation, CESR)來實(shí)現(xiàn)數(shù)據(jù)結(jié)構(gòu)的線性轉(zhuǎn)化(Serialization)。“可組合”意味著在“編碼”和“串聯(lián)“兩個(gè)操作之間的可交換性，也就是說，先編碼再串聯(lián)與先串聯(lián)在編碼會(huì)得到完全同樣的結(jié)果?？山M合性為軟件實(shí)現(xiàn)提供很多的方便，包括支持高性能的流處理實(shí)現(xiàn)。CESR同時(shí)設(shè)計(jì)了高效的編碼表，在TSP這樣高程度使用密碼操作的協(xié)議里，這種效益的成本優(yōu)勢(shì)非常明顯。另外，如上一節(jié)所述，CESR是一個(gè)完全自編碼的數(shù)據(jù)格式，它支持更好的未來可擴(kuò)張可演變性。TSP協(xié)議的內(nèi)容部分(即用戶數(shù)據(jù)主體)則可以是任何常見的協(xié)議，包括JSON、CBOR、MsgPak等。這也是自定義格式的一個(gè)優(yōu)點(diǎn)，數(shù)據(jù)單元可以采用每個(gè)應(yīng)用所需的格式而不必強(qiáng)求統(tǒng)一。

• 與網(wǎng)絡(luò)載體解耦

TSP可以完全與網(wǎng)絡(luò)載體解耦，它可以用于任何底層傳輸協(xié)議之上，也可以用在非互聯(lián)網(wǎng)載體中，比如云存儲(chǔ)、Bluetooth、NFC、甚至QR或信件等等。這樣的設(shè)計(jì)讓它的應(yīng)用面非常廣，同時(shí)開發(fā)者可以根據(jù)應(yīng)用要求作合適的調(diào)整，又不妨礙協(xié)議的信任互聯(lián)可互操作性。

• 為多種多元的上層應(yīng)用設(shè)計(jì)

TSP的設(shè)計(jì)遵循最小化的原則。作為一個(gè)互聯(lián)協(xié)議，TSP對(duì)應(yīng)用層提出的限制越小越好，TSP才能越被普遍地采用。TSP為確實(shí)需要的信任任務(wù)提供必須的互操作性服務(wù)，其他功能一律排除在外，留給應(yīng)用按具體情況來實(shí)現(xiàn)。這樣的設(shè)計(jì)理念將TSP和許多其他類似的協(xié)議區(qū)分開來，TSP只是一個(gè)工具，真正的應(yīng)用將會(huì)是應(yīng)用層軟件和TSP的結(jié)合。

• 開源協(xié)議實(shí)現(xiàn)和編程界面

TSP的開源實(shí)現(xiàn)也是一個(gè)重要的特性。TSP的SDK使用Rust語言編程，大幅提高加密和認(rèn)證代碼的可靠性和安全性，防止常見的C語言的內(nèi)存安全性弱點(diǎn)，同時(shí)又支持高效高性能。為了給常見的開發(fā)場景提供方便，TSP的開發(fā)社區(qū)也將提供相關(guān)的編程環(huán)境Bindings，比如JS、Python、WASM、C、Android、iOS等等。TSP的SDK為上層軟件提供方便又簡易安全的編程界面，讓原先非常復(fù)雜又高風(fēng)險(xiǎn)的信任協(xié)議的編程變得簡單清晰。

【1】W. Chu, S. Smith, “Trust Spanning Protocol (TSP) Specification”, Implementer’s Draft, https://trustoverip.github.io/tswg-tsp-specification.

【2】The OpenWallet Foundation TSP Lab Project, https://github.com/openwallet-foundation-labs/tsp.

【3】R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, “Hybrid Public Key Encryption”, https://datatracker.ietf.org/doc/rfc9180/. Feb 2022.

【4】Libsodium (Nacl) Documentation，https://doc.libsodium.org/.

【5】J. H. An, “Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses”, Cryptology ePrint Archive, Paper 2001/079, https://eprint.iacr.org/2001/079.

【6】M. Spony, A. Guy, M. Sabadello, D. Reed, et al, “Decentralized Identifiers (DIDs) v1.0”, https://www.w3.org/TR/did-core/. W3C Recommendation, 19 July 2022.

【7】S. Smith, K. Griffin, “Composable Event Streaming Representation (CESR)”, v1.0, https://trustoverip.github.io/tswg-cesr-specification/.

【8】D. Hardman, S. Curran, S. Curren, et al, “ Peer DID Method Specification”, v1.0, https://identity.foundation/peer-did-method-spec/.

【9】S. Curran, J. Jordan, A. Whitehead, B. Richter, “Trust DID Web - did:tdw”, Draft, https://bcgov.github.io/trustdidweb/.

【10】P. Feairheller, D. Hardman, S. Smith, L. Byrd, et al, “ToIP did:webs Method Specification v0.9.15”, https://trustoverip.github.io/tswg-did-method-webs-specification/.

【11】M. Prorock, O. Steele, O. Terbu et al, “did:web Method Specification”, 06 May 2023, https://w3c-ccg.github.io/did-method-web/.

【12】E. Scouten, W. Chu (co-Chairs), et al, “did:x509 Method Specification”, Work in progress in the Trust over IP (ToIP) X.509 based DID Task Force X5VTF. https://github.com/trustoverip/tswg-did-x509-method-specification.