開始本章之前，需要對加密技術有所了解。

在數據傳輸中，有兩點需要注意，一個是數據的保密性。如果發送方A以明文方式發送消息給接收方B，則容易被第三方C截獲并分析出其中的內容。為了提高數據的安全性，需要對消息加密。

第二點是數據的完整性。發送方A將消息加密發送給接收方B，但是如果這個過程中有第三方C截獲并且加以篡改（比如更改其中的一些bit或是更改密文塊的順序，此時C無需解密數據），然后再發送B，在B端是無法感知數據已經被破壞。這就需要有機制保證數據的完整性，即在傳輸過程中沒有被破壞。單純的數據校驗不能保證完整性，這是因為C可以根據修改后的數據重新生成校驗。

綜上，安全的數據傳輸方式是A將數據加密，并且給加密后的數據打上一個特有的標簽（tag），然后將密文和標簽一起發送給B；B接收到數據后，先要檢查標簽，看看數據是否被修改過，確認數據的完整性后再將數據解密。

常見的加密可以分為兩類，即對稱加密和非對稱加密。

• 對稱加密，也稱單密鑰加密，同一個密鑰既可以用作加密也可以用作解密。因此對稱加密的安全性不僅取決于加密算法本身，也和密鑰管理相關。采用對稱加密，收發雙方需要在通信前協商一個密鑰，并且雙方負責該密鑰的安全性。
• 非對稱加密算法使用兩把完全不同但又是完全匹配的一對鑰匙，公鑰（public key）和私鑰（private key）。加密明文時采用公鑰加密，解密密文時使用私鑰才能完成，而且發送方（加密者）知道接收方的公鑰，只有接收方（解密者）才是唯一知道自己私鑰的人。采用不對稱加密，收發雙方在通信之前，接收方必須將自己早已隨機生成的公鑰送給發送方，而自己保留私鑰，留待解密用。

CXL采用的是AES-GCM加密方式。

AES屬于對稱加密。加密技術包括兩個元素：算法和密鑰。以下圖為例，發送方將明文P（plain text）和密鑰K（key）通過加密函數，生成密文C（cipher text）；接收方在接收到密文C后，與密鑰K通過解密函數，恢復明文P。

AES是一種分組加密技術，所謂分組就是將明文P分成長度相同的若干組，每次加密一組數據，直到加密完全部的明文。在AES規范中規定，分組長度只能是128-bit。AES支持的密鑰長度可以是128-bit，192-bit或256-bit，密鑰越長，加密輪數越多，安全性越高，當然消耗的時間也越多。

再來看加密模式，因為每次只能加密一組數據，而實際的明文可能很長，會分為很多組，此時就需要對這些分組進行迭代，已完成整個明文的加密。迭代的方法就是加密模式。

說完AES，再來看看什么是MACs（Message Authentication Codes，消息認證碼）。消息認證碼是一種允許對接收到的消息進行身份驗證的信息，確保消息來自聲稱的發送者，而不是偽裝成他們的第三方，同時確保消息沒有以某種方式修改，以提供數據完整性。

消息認證碼的輸入為任意長度的消息和一個發送者與接收者之間共享的密鑰，它可以輸出固定長度的數據，這個數據稱為MAC 值。用于生成消息認證碼的密鑰與用于驗證消息認證碼的密鑰相同。從這個意義上講，它類似于對稱加密系統，并且密鑰必須由所有通信方事先商定或以某種安全方式共享。

回過頭來看AES-GCM，GCM是認證加密模式中的一種，其中G指的是GMAC，即利用伽羅華域(Galois Field，GF，有限域)乘法運算來計算消息的MAC值；C指的是CTR。

11.1 CXL IDE

CXL完整性和數據加密（Integrity and Data Encryption，IDE）定義了為傳輸CXL鏈路的數據提供機密性、完整性和重播保護的機制。加密方案與當前行業最佳實踐保持一致。它支持各種使用模型，同時提供廣泛的互操作性。CXL IDE可用于在由多個組件組成的可信執行環境（TEE）中保護流量，然而，這種組合的框架不在本規范的范圍內。

11.1.1 范圍

本章重點介紹通過鏈路傳輸的CXL.cache和CXL.mem流量傳輸，以及對控制CXL.io流量的PCIe基本規范的更新/限制。

• CXL.io IDE的定義基于PCIe的IDE規范
• CXL.cachemem IDE可以使用基于CXL.io的機制進行發現（discovery）、協商（negotiation）、設備證明（device attestation）和密鑰協商（key negotiation）。

本規范中，CXL IDE指代保護CXL.io，CXL.cache，CXL.mem數據流的機制，CXL.cachemem IDE指代保護CXL.cache，CXL.mem數據流的機制。如果沒有明確指出，則遵循PCIe規范。CXL.io基本上與PCIe IDE的要求一致。拒絕服務攻擊（denial of services）不在范圍內。

11.1.2 CXL.io IDE

CXL.io IDE遵循PCIe IDE定義。

解釋幾個名詞。IDE流（IDE stream）指的是，使用完整性和數據加密定義的機制建立的端口到端口連接，以保護兩個端口之間的TLP流量（traffic）。IDE流可以是selective IDE stream形式，IDE TLP可以在不影響其安全性的情況下流經交換機；也可以是Link stream形式，兩個端口必須在沒有中間交換機的情況下連接，也就是直連。參考下圖，端口C和G之間以及端口G和H之間的selective IDE stream在通過交換機時是安全的。

Flow-Through 指的是對switch和RC，TLP從入口端口傳遞到出口端口而不進行修改的行為。

IDE terminus，作為與一個或多個IDE流相關聯的IDE TLP的發起方或最終目的地的端口。

11.1.3 CXL.cache/CXL.mem IDE高層概覽

• 所有協議級別的重試flit都經過加密并受到完整性保護。
• 鏈路層控制flit和flit CRC沒有加密，也沒有完整性保護。
• LCRC應該在加密flit上計算。
• 任何完整性檢查失敗的數據流都應被放棄。
• 必須支持多數據頭功能。這允許將多個（最多4個）數據頭打包到一個slot中，然后緊接著是所有數據的16個slot。
• 采用256-bit密鑰的AES-GCM加解密
• 必須支持在不丟失任何數據的情況下進行密鑰刷新
• 密鑰刷新預計不經常發生。延遲/帶寬受到影響是可以接受的，但不能有任何數據丟失。
• 支持加密PCRC機制。加密PCRC集成到標準MAC檢查機制中，不消耗額外鏈路帶寬，不增加顯著額外延遲。PCRC對于CXL.cachemem IDE是強制性的，并且在默認情況下是啟用的

11.1.4 CXL.cache/CXL.mem IDE架構

• IDE應當以flit為單位，使用AES-GCM模式。AES-GCM采用三個輸入，分別為附加身份驗證數據（Additional Authentication data，AAD，在AES-GCM規范中指定為A）、明文（P）和初始化矢量（IV）。在CXL.cachemem協議中，32-bit的數據包頭作為slot 0的一部分，映射到A——它沒有加密，但受到完整性保護。Slot 0/1/2/3的映射到P，P經過加密并受到完整性保護。CXL.cachemem協議也支持僅有數據（data-only）的flit，在這種情況下，flit中的所有4個slot映射到P。
• LCRC不加密且不受到完整性保護。在flit被加密之后，對其計算CRC
• IDE flit也遵守用于檢測和糾正錯誤的鏈路層機制。
• AES-GCM可以應用于多flit聚合，這些flit組成一個MAC_Epoch。可以聚合的flit數目取決于Aggregation Flit Count。如果啟用PCRC，則32-bit的PCRC值應這些聚合的flit的末尾，以產生受完整性保護的最終P值。然而，PCRC的32-bit并不在鏈路上傳輸的。下圖顯示了在5個flit聚合MAC的情況下，flit內容到A和P的映射。圖中深灰色部分是flit header，映射到A；淺灰色部分是數據，映射到P。

• MAC是96-bit，MAC必須在H6類型的slot 0報頭中傳輸。MAC本身既沒有加密，也沒有完整性保護。下圖顯示了在5個flit聚合MAC的情況下，flit內容到A和P的映射，其中一個flit攜帶MAC。圖中橙色部分是MAC。

• 下圖給出了5個flit組成MAC Epoch示例的更詳細視圖。頂部顯示的Flit 0是在該MAC Epoch中要發送的第一個flit。該圖描繪了僅受完整性保護的標題字段，以及加密和受完整性防護的文本內容。Flit 0明文0字節0是明文的第一個字節。Flit 1明文0字節0應緊跟在Flit 0明文0字節11之后。

上面示例中，flit包頭字節映射到AAD如下圖。在上圖中，只有Flit 0，2，3有flit包頭。

11.1.5 加密的PCRC

使用系數為0x1EDC6F41的多項式進行PCRC計算。PCRC計算應從初始值0xFFFFFFFF開始。應在作為給定MAC Epoch的一部分的聚合flit中的所有明文字節上計算PCRC。PCRC計算應從flit明文內容的比特0字節0開始，并依次包括映射到明文的flit內容的每個字節的比特0-7。在跨flit內容累積32位值之后，應通過對累積值的位取1的補碼來最終確定PCRC值，以獲得PCRC[31:0]。

在發送端，PCRC值應附加到聚合的flit明文內容的末尾，進行加密并包含在MAC計算中。加密的PCRC值不在鏈路上傳輸。

在接收端，應根據接收到的解密密文重新計算PCRC值。當前MAC epoch的最后一個flit已被處理時，累積的PCRC值應與AES密鑰流比特進行異或（加密），AES密鑰流位緊跟在用于解密所接收的密碼flit的值之后。為了MAC計算的目的，該加密的PCRC值應被附加到接收到的密文的末尾。

11.1.6 CXL.cachemem加密密鑰和IV

CXL.cachemem IDE流的初始化涉及多個步驟。第一步是建立包含兩個端口的組件的標識和認證，這兩個端口充當CXL.cachemem IDE流的端點。第二步是建立IDE流的密鑰。在某些情況下，這兩個步驟可以合并。第三，配置IDE。最后，開始IDE流傳輸。

CXL.cachemem IDE可以利用CXL.io IDE機制進行設備認證和密鑰交換。CXL.cachemem IDE的IV（初始化矢量）構造應遵循CXL.io PCIe規范。根據AES-GCM規范，使用確定性結構的96-bit IV。

• [95:92]位包含子流標識符，1000b，[91:64]位均為0。相同的子流編碼用于發送和接收的flit，但端口在發送和接收流期間使用的密鑰必須不同。
• [63:0]位包含一個單調遞增的計數器。在建立IDE流時，每個子流的調用字段最初設置為值0000_0001h，并且每次使用IV時都會遞增。

11.1.7 CXL.cache/CXL.mem IDE模式

CXL.cachemem IDE支持兩種操作模式。

• Containment模式：此模式下，只有在完整性檢查通過后，數據才會發布以供進一步處理。此模式會影響延遲和帶寬。延遲影響是由于在接收并檢查完完整性值前，需要緩沖多個flit。帶寬影響是由于完整性值被頻繁發送。如果支持并啟用了containment模式，則設備（和主機）將使用Aggregation Flit Counter為5。因為此模式需要緩沖接收到的flit，所以AFC數量不會太大。
• Skid模式：滑動模式允許釋放數據進行進一步處理，而無需等待完整性值的接收和檢查。這樣可以減少完整性值的傳輸頻率。滑動模式允許接近零的延遲開銷和非常低的帶寬開銷。在此模式下，被惡意修改的數據可能會被軟件所接受和處理，但當接收并檢查完整性值后才會檢測到此類攻擊。因此，當使用此模式時，軟件和應用程序堆棧必須能夠在狹窄的時間窗口內容忍攻擊，否則結果是未定義的。如果支持并啟用了skid模式，則設備（和主機）將使用Aggregation Flit Counter為128。

11.1.7.1 完整性模式的發現和設置

每個端口應通過CXL IDE的capability寄存器枚舉其支持的模式和其它能力。所有符合本規范的設備應支持containment模式。

11.1.7.2 操作模式的協商和設置

在啟用CXL.cachemem IDE之前，在CXL IDE的capability寄存器中配置操作模式和時序參數。

11.1.8 MAC聚合規則

• MAC_Epoch：一組連續的flit用于flit聚合。給定的MAC報頭應包含恰好一個MAC_Epoch的標簽。在發送之前，發送方應在一個MAC_Epoch（最多N個flit）中積累flit上的完整性值。
• 在所有情況下，發送方必須按照與MAC Epochs相同的順序發送MAC。
• 下圖顯示了在存在背靠背協議流量的情況下，一個MAC_Epoch的MAC生成和傳輸示例。要發送或接收的最早的flit顯示在圖的頂部。因此，屬于MAC_EPOCH 1的flit 0到N-1（以黃色顯示）按該順序發送。MAC是在flit 0到N-1上計算的。

• 發送方應盡早發送包含該完整性值的MAC報頭。本規范允許在當前MAC_Epoch的最后一個flit的傳輸和該MAC_EpochMAC報頭的實際傳輸之間傳輸屬于下一個MAC_Epoch的協議flit。這可以避免由于MAC計算延遲而導致的帶寬浪費。建議發送方在MAC計算完成后立即在第一個可用的Slot 0報頭上發送MAC報頭。在所有情況下，允許在發送先前MAC_Epoch MAC之前發送當前MAC_Epoch的最多5個協議flit。上圖右側就是發送了5個當前屬于MAC_Epoch flit的情況。
• 接收方可以期望在先前MAC_Epoch的最后一個flit之后的從第一到第六個協議flit中的任一個flit接收到先前MAC_Epoch的MAC。還是對應上面的最多5個flit。

• 在containment模式中，接收方必須不釋放（即給后續的功能模塊）給定MAC_Epoch的flit，直到已經接收到包含這些flit的完整性值的MAC報頭并且完整性檢查已經通過。由于在接收先前MAC_Epoch的MAC報頭之前，接收器可以接收屬于當前MAC_Epoch的5個協議flit，因此接收方應緩沖當前MAC_Epoch的flit，以確保沒有數據丟失。
• 在skid模式中，一旦接收到flit，接收器就可以解密并釋放flit。MAC值應根據需要進行累積，并在MAC_Epoch中的MAC報頭到達時進行完整性檢查。

11.1.9提前終止MAC

當前MAC_Epoch中傳輸的Flit少于聚合Flit計數時，允許發射機提前終止MAC_Epoch并在截斷的MAC_Epoch中傳輸Flit的MAC。這是鏈路空閑（Link Idle）處理的一部分。在當前MAC_Epoch中傳輸了少于聚合Flit計數的多個協議Flit之后，鏈路可以準備進入空閑。

以下規則應適用于MAC_Epoch的提前終止和MAC的傳輸

當且僅當目前MAC_Epoch中的flit數少于Aggregation Flit Counter的數目（5或128，根據IDE模式），發送端才可以提前終止MAC。

下圖是在3個協議flit之后截斷當前MAC Epoch的示例。當前MAC Epoch中的flit可以是任何有效的協議flit，包括用于先前MAC Epoch的MAC的報頭flit。對當前MAC Epoch的MAC使用截斷MAC Flit發送。截斷的MAC flit將在當前MAC Epoch的三個協議flit之后發送，而沒有來自下一個MAC Epoch的其它協議flit。

對于在鏈路在發送Aggregation Flit Count數量后變為空閑的情況下，則不得使用如上定義的截斷MAC flit。MAC標頭必須是下一個MAC Epoch的一部分。允許使用截斷的MAC Flit提前終止此新的MAC Epoch，見下圖。規范在這里說的很拗口，直白一點就是，僅當MAC_Epoch中的flit數少于Aggregation Flit Counter的數目時才可以使用截斷的MAC flit。

在提前MAC終止和傳輸截斷MAC之后，發射機必須發送至少TruncationDelay數量的IDE空閑flit，然后才能傳輸任何協議flit。TruncationDelay計算公式如下：

TruncationDelay = Min(Remaining Flits, Tx Min Truncation Transmit Delay)

Remaining Flits= Aggregation Flit Count - Number of protocol flits received in

current MAC Epoch

11.1.10 Handshake to Trigger the Use of Keys

每個端口都公開了一個寄存器接口，軟件可以使用該接口對發送和接收密鑰及相關參數進行設置。在激活之前，這些密鑰在寄存器中保持掛起狀態。當密鑰在上游和下游端口中交換和配置時，鏈路可以主動使用先前配置的密鑰。

下面描述的機制用于將備份密鑰切換到活動狀態。

在密鑰被編程到鏈路兩側的掛起寄存器中后，每個端口上的每個發射機上都應有一個特定于設備的動作，以觸發IDE.Start鏈路層控制微片的傳輸。

在發送了IDE.Start之后，所有后續的協議flit都將受到新密鑰的保護。為了讓接收器準備好接收用新密鑰保護的微片，發送器需要在發送任何帶有新密鑰的協議flit之前，發送IDE.idle flit。表54中定義了，在發送具有新密鑰的任何協議flit之前，由寄存器字段Tx Key Refresh Time指定的flit數量。這些空閑的flit沒有被加密或受到完整性保護。發射器中的TxKey Refresh Time必須配置為高于接收器中最壞情況延遲的值，以便準備使用新密鑰，接收器通過Rx Min Key Refresh Time寄存器字段公布新密鑰。在接收到IDE.Start flit之后，接收器必須切換到使用新的密鑰。IDE.start flit應針對協議flit進行排序。在鏈路級retry的情況下，接收器應在處理IDE.start flit并切換到新密鑰之前完成先前發送的協議flit的retry。

11.1.11 錯誤處理

CXL IDE不會影響或是要求對鏈路CRC錯誤處理和鏈路retry流程進行任何更改。

有關CXL.cachemem錯誤的詳細信息記錄在CXL IDE的Error Status寄存器中。當檢測到CXL.cachemem IDE錯誤時，也會設置Uncorrectable Error Status寄存器中的相應位，并使用標準的CXL.cachemem協議錯誤信號機制發出錯誤信號。

在檢測到完整性失敗時：

• 在錯誤報告寄存器中記錄完整性檢查失敗，并使用標準CXL.cachemem協議錯誤信號機制發出錯誤信號。
• 丟棄任何緩沖的協議flit，并丟棄所有后續的數據流，直到鏈路重置。
• 設備應防止密鑰或用戶數據泄露。設備可能需要實現清除數據/狀態的機制，或者具有訪問控制以防止機密泄露。

以下情況必須視為完整性失敗：

• 當鏈路不處于安全模式時接收到MAC包頭
• 未收到預期的MAC包頭
• 接收到未預期的截斷MAC Flit
• 在截斷MAC flit之后，協議flit的接收時間早于預期
• 密鑰切換后，協議flit的接收時間早于預期

我的理解，以上的情況均為可能鏈路收到攻擊。

11.1.12 交換機支持

支持CXL.cachemem IDE的CXL交換機必須支持用于CXL.io的Link Stream IDE。

交換機可以選擇性地支持CXL.io的Selective Stream IDE。對于CXL.io，CXL交換機可以僅支持流通（flow-through）模式下的Selective Stream IDE。在這種情況下，不能在主機端啟用CXL.cachemem IDE。

對具有多VCS功能的交換機，可以在每個根端口的基礎上啟用CXL IDE。但是，一旦任何根端口啟用了CXL IDE，從交換機到支持CXL IDE的MLD設備的下游鏈路就必須啟用鏈路IDE。因此，來自未啟用CXL IDE的根端口的數據流將被加密，并在交換機和設備之間受到完整性保護。

總結：本章內容為CXL數據加解密。CXL采用AES-GCM模式進行數據加解密，CXL.io的IDE基本與PCIe的IDE一致，因此本章主要是對CXL.cachemem IDE進行約束。