本文撰寫於 2017 年 12 月，所有資訊皆以當時情況為依據。另外，我們會持續改善客戶資料的保護機制，因此 Google Cloud 的安全性政策和系統未來可能會調整。
資訊長層級摘要
- Google 的應用程式層傳輸安全性 (ALTS) 是 Google 所開發的雙向驗證和傳輸加密系統，通常用於保護 Google 基礎架構內部遠端程序呼叫 (RPC) 通訊的安全。應用程式層傳輸安全性 (ALTS) 在概念上與雙向驗證傳輸層安全標準 (TLS) 類似，但應用程式層傳輸安全性 (ALTS) 經過特別設計和最佳化，以符合 Google 資料中心環境的需求。
- 應用程式層傳輸安全性 (ALTS) 信任模型經過特別設計，適合類似雲端的容器化應用程式。身分是連結至實體，而不是特定伺服器名稱或主機。這個信任模型有利於在各個主機之間順利複製微服務、平衡負載以及重新排程。
- ALTS 仰賴兩個通訊協定：握手通訊協定 (支援工作階段恢復) 和記錄通訊協定。這些通訊協定會控制工作階段的建立、驗證、加密和恢復方式。
- 應用程式層傳輸安全性 (ALTS) 是 Google 在內部使用的自訂傳輸層安全性解決方案，為了順應我們的實際工作環境需求，與業界標準 TLS 之間存有一些權衡與取捨。詳情請參閱權衡與取捨一節。
簡介
Google 的實際工作環境系統包含一組微服務1，這些服務每秒可發出 O(1010) 個遠端程序呼叫 (RPC)。如果 Google 工程師安排了實際工作環境工作負載2 的排程，根據預設，由該工作負載發出或接收的任何 RPC 都會受到 ALTS 的保護。這項完全不需設定的自動防護是由 Google 的應用程式層傳輸安全性 (ALTS) 提供。除了自動保護 RPC 以外，ALTS 還有利於在各個實際工作環境機器之間複製服務、平衡負載以及重新排程。本文將說明 ALTS，並探討其在 Google 實際工作環境基礎架構中的部署方式。
目標對象：本文的目標對象，是想瞭解 Google 如何大規模執行驗證和傳輸安全性作業的基礎架構安全性專家。
必備條件：除了本簡介外，我們假定讀者對於 Google 的叢集管理方式有基本的瞭解。
應用程式層級的安全性和 ALTS
從網路瀏覽器到 VPN，許多應用程式都仰賴安全的通訊協定 (例如傳輸層安全標準 (TLS) 和 IPSec) 來保護傳輸中的資料3。而 Google 則是選擇採用 ALTS，在應用程式層級執行雙向驗證和傳輸加密系統來保護 RPC 通訊。應用程式層級的安全性可讓應用程式具有經過驗證的遠端對等身分，而這個身分可用來實作精細的授權政策。
為什麼不使用 TLS？
現今大部分的網際網路流量都是使用 TLS 加密，因此 Google 使用 ALTS 這類自訂安全性解決方案似乎並不尋常。Google 在 2007 年開始開發 ALTS，當時 TLS 支援的許多舊型通訊協定並不符合我們的最低安全性標準。我們可以考慮採用 TLS 元件並實作需要的部分，這樣也能設計屬於自己的安全性解決方案；但相較於改造現有系統，從頭開始建構更適合 Google 的全新系統，而且好處更多。此外，ALTS 更適合我們的需求，且一直比舊型 TLS 更安全。以下列出傳輸層安全標準 (TLS) 和應用程式層傳輸安全性 (ALTS) 的主要差異。
- 採 HTTPS 語意的傳輸層安全標準 (TLS) 和應用程式層傳輸安全性 (ALTS) 的信任模型4 有顯著的差異。在 TLS 中，伺服器身分會與特定名稱和對應的命名配置繫結。在 ALTS 中，相同的身分可與多個命名配置搭配使用。這種程度的間接性提供了更多彈性，並大幅簡化在主機之間複製微服務、平衡負載和重新排程的流程。
- 相較於 TLS，ALTS 的設計和實作方式較簡單，因此更容易透過手動檢查原始碼或大規模漏洞檢查的方式監控錯誤和安全性漏洞。
- ALTS 使用通訊協定緩衝區將其憑證和通訊協定訊息序列化，TLS 則是使用以 ASN.1 編碼的 X.509 憑證。我們的實際工作環境服務，大多是使用通訊協定緩衝區進行通訊 (偶爾會進行儲存)，因此 ALTS 較適合 Google 的環境。
ALTS 的設計
ALTS 的設計宗旨，是要成為穩定性高且可信任的系統，讓使用者只需執行少量操作即可進行服務對服務驗證和安全性作業。為了達到這個目標，ALTS 的設計融入了下列特性：
- 透明度：應用程式層可以存取 ALTS 設定。根據預設，服務 RPC 是受 ALTS 保護。這可讓應用程式開發人員將心力集中在服務函式邏輯，不必分神顧慮憑證管理或安全性設定。在建立服務對服務連線的期間，ALTS 會為應用程式提供經過驗證的遠端對等身分，這個身分可用來進行精細的授權檢查和稽核作業。
- 先進的加密編譯：ALTS 使用的加密編譯基元和通訊協定都是最新版本，可應付最新的已知攻擊。ALTS 是在 Google 控管的機器上執行，表示支援的加密編譯通訊協定都可輕鬆升級及快速部署。
- 身分模型：ALTS 主要是依身分而非主機名稱執行驗證。Google 的每一個網路實體 (例如企業使用者、實體機器，或實際工作環境服務或工作負載) 都有相關聯的身分。服務之間的通訊會經過雙向驗證。
- 金鑰發布：ALTS 要能順利運作需要每個工作負載都具有一個身分，而這個身分是以一組憑證表示。這些憑證會在初始化期間部署到各個工作負載，且使用者不需進行任何操作。同時，系統會為機器和工作負載建立憑證的信任根和信任鏈。系統可自動輪替和撤銷憑證，應用程式開發人員不需進行任何操作。
- 擴充性：ALTS 旨在提供高度擴充性，以因應 Google 基礎架構的龐大規模。為了滿足這項要求，我們開發了有效率的工作階段恢復功能。
- 長期連線：驗證金鑰交換密碼編譯作業的運算成本相當高昂。為了因應 Google 基礎架構的規模，在初始 ALTS 握手後，連線可持續較長的時間，以提高整體的系統效能。
- 簡易性：TLS 預設支援舊版通訊協定，且具有回溯相容性。ALTS 則簡單許多，因為 Google 會控管用戶端以及具 ALTS 原生支援能力的伺服器。
ALTS 信任模型
ALTS 主要是依身分而非主機來執行驗證。Google 的每一個網路實體 (例如企業使用者、實體機器，或實際工作環境服務) 都有相關聯的身分。這些身分會嵌入 ALTS 憑證，並在建立安全連線期間用於進行對等驗證。我們理想的模型是將實際工作環境服務當做實際工作環境實體執行，並可由我們的網站穩定性工程師 (SRE) 代管5。這些實際工作環境服務的開發版本則做為測試實體執行，並可由 SRE 和開發人員管理。
例如，假設某個產品有兩個服務：「service-frontend」和「service-backend」。SRE 可發布這些服務的實際工作環境版本：「service-frontend-prod」和「service-backend-prod」。開發人員則可發布這些服務的開發版本「service-frontend-dev」和「service-backend-dev」以進行測試。實際工作環境服務的授權設定會設為不信任服務的開發版本。
ALTS 憑證
ALTS 憑證有三種，每一種都是以通訊協定緩衝區訊息格式表示。
- 主憑證：是由遠端簽署服務簽署，用於驗證握手憑證。主憑證包含與主要私密金鑰相關聯的公開金鑰，例如 RSA 金鑰組合。這組私密金鑰是用於簽署握手憑證。這類憑證在與下述的 ALTS 政策搭配使用時，基本上是受限的中繼憑證授權單位 (CA) 憑證。主憑證通常是核發給實際工作環境機器和容器化工作負載排程器 (例如 Borgmaster6)。
- 握手憑證：由主要私密金鑰在本機建立和簽署。這個憑證包含在 ALTS 握手 (建立安全連線) 期間使用的參數，例如靜態 Diffie-Hellman (DH) 參數和握手加密。此外，握手憑證還包含來源主憑證，即與簽署握手憑證的主要私密金鑰相關聯的主憑證。
- 恢復金鑰：用來加密恢復票證的密鑰。這組金鑰是以繼續作業識別碼 IDR 來識別，在同一個資料中心區塊以相同身分執行的所有實際工作環境工作負載，都會共用一組專屬識別碼。如要進一步瞭解在 ALTS 繼續工作階段的資訊，請參閱繼續工作階段一節。
圖 1 顯示 ALTS 憑證鏈，其中包含簽署服務驗證金鑰、主憑證和握手憑證。簽署服務驗證金鑰是 ALTS 的信任根，並安裝在我們實際工作環境和企業網路中所有的 Google 機器上。
圖 1：應用程式層傳輸安全性 (ALTS) 憑證鏈
在應用程式層傳輸安全性 (ALTS) 中，簽署服務會認證主憑證，而後者會認證握手憑證。由於握手憑證的建立頻率高於主憑證，因此這個架構可降低簽署服務的負載。Google 經常輪替憑證，尤其是握手憑證7。握手憑證持有的金鑰交換組合是靜態的，而頻繁輪替憑證可以彌補靜態金鑰交換組合的不足8。
核發憑證
為了參與 ALTS 安全握手，網路上的實體必須使用握手憑證佈建。首先，核發者會取得由簽署服務簽署的主憑證，並視需要將主憑證傳送至實體。接著，系統會建立握手憑證，並使用相關聯的主要私密金鑰簽署。
一般而言，如果是要核發憑證給機器和使用者，則核發者是我們的內部憑證授權單位 (CA)；如果是要核發憑證給工作負載，則核發者是 Borgmaster。不過，核發者可以是任何其他實體，例如測試資料中心區塊的受限 Borgmaster。
圖 2 說明簽署服務如何用於建立主憑證。建立流程包含下列步驟。
圖 2：憑證核發流程
- 憑證核發者傳送憑證簽署要求 (CSR) 至簽署服務，要求簽署服務為身分 A 建立憑證。這個身分可以是企業使用者或 Google 實際工作環境服務的身分等等。
- 簽署服務將憑證核發者 (包含在 CSR 中) 設為要求者 (在這個情況下為憑證核發者) 並進行簽署。先前提過，所有的 Google 機器都已安裝對應的簽署服務公開 (驗證) 金鑰。
- 簽署服務傳回已簽署的憑證。
- 系統為身分 A 建立握手憑證，並使用與主憑證相關聯的私密金鑰簽署。
如上述流程所示，使用 ALTS 時，憑證的核發者和簽署者是兩個不同的邏輯實體。在這個情況下，核發者是憑證核發者實體，而簽署者則是簽署服務。
ALTS 中的憑證有三種常見的類別：使用者、機器和工作負載。以下各節將概述這些憑證在 ALTS 中分別是如何建立及使用的。
使用者憑證
Google 使用 ALTS 來保護使用者向實際工作環境服務發出的 RPC。如要發出 RPC，使用者必須提供有效的握手憑證。例如，如果小愛想使用應用程式發出受 ALTS 保護的 RPC，她可以向我們的內部 CA 進行驗證。她可以使用自己的使用者名稱、密碼和雙重驗證，向 CA 進行驗證。完成這項作業後，小愛會取得 20 個小時內有效的握手憑證。
機器憑證
Google 資料中心的每一台實際工作環境機器都有機器主憑證。這個憑證是用來為該機器上的核心應用程式 (例如機器管理 Daemon) 建立握手憑證。機器憑證內嵌的主要身分指的是機器的一般用途。例如，用來執行各種實際工作環境和開發工作負載的機器可具有不同的身分。主憑證只能由執行已驗證軟體堆疊的機器使用；在某些情況下，這項信任是奠基於自訂安全性硬體9。實際工作環境機器主憑證是由 CA 核發，且每幾個月就會輪替。此外，所有握手憑證每幾個小時就會輪替。
工作負載憑證
ALTS 的一大優點，在於它是以工作負載身分的概念運作，這樣有利於在各個機器之間複製服務、平衡負載以及重新排程。在 Google 的實際工作環境網路中，我們是使用稱為 Borg10 的系統來大規模管理叢集及分配機器資源。Borg 核發憑證的方式，與 ALTS 採用無關機器的工作負載身分有關。
我們實際工作環境網路中的每個工作負載都是在 Borg 區塊中執行。每個區塊都包含邏輯集中式控制器 Borgmaster，以及幾個在該區塊的各個機器上執行的代理程式程序 Borglet。工作負載是透過 Borgmaster 核發的相關聯工作負載握手憑證來初始化。圖 3 說明搭配 Borg 使用 ALTS 時的工作負載憑證流程。
圖 3：Google 實際工作環境網路中的握手憑證建立流程
Borgmaster 現可為需要使用 ALTS 的工作負載進行排程。當用戶端安排工作負載以特定身分在 Borg 上執行時，就會發生下列步驟。
- 每個 Borgmaster 都已預先安裝機器主憑證和相關聯的私密金鑰 (未顯示於圖中)。
- ALTSd11 產生 Borgmaster 握手憑證，並使用主機器私密金鑰簽署憑證。這個握手憑證可讓 Borgmaster 發出受 ALTS 保護的 RPC。
- Borgmaster 建立基礎工作負載主憑證和對應的私密金鑰。Borgmaster 會發出受 ALTS 保護的 RPC，要求簽署服務簽署這個基礎工作負載主憑證。因此，簽署服務會在這個憑證中將 Borgmaster 列為核發者。
- Borgmaster 確認用戶端是否已獲授權，可將工作負載以其設定中指定的身分來執行。如果確實已獲授權，Borgmaster 會在 Borglet 上安排 Borg 工作負載，並核發工作負載握手憑證及其對應的私密金鑰。這個憑證與基礎工作負載主憑證相鏈結。接著，工作負載握手憑證及其私密金鑰會透過 Borgmaster 和 Borglet 之間受 ALTS 保護的雙向驗證管道，在安全的情況下提供給 Borglet。Borgmaster 約每兩天就會輪替基礎工作負載主憑證，並為所有執行中的工作負載重新核發握手憑證。此外，凡是在相同區塊中做為相同使用者執行的工作負載，都會獲得由 Borgmaster 佈建的同一繼續作業金鑰和識別碼 (IDR)。
- 如果工作負載需要發出受 ALTS 保護的 RPC，就會在握手通訊協定中使用工作負載握手憑證。在進行握手以啟動工作階段繼續作業時，IDR 也會用到。如要進一步瞭解 ALTS 中的工作階段恢復功能，請參閱工作階段恢復一節。
強制執行 ALTS 政策
ALTS 政策是一份文件，當中列出哪些核發者已獲授權，可為哪些身分核發特定類別的憑證。這項政策會發佈至我們實際工作環境網路中的每一台機器。例如，ALTS 政策允許 CA 核發憑證給機器和使用者，也允許 Borgmaster 核發憑證給工作負載。
我們發現，相較於在核發憑證期間強制執行政策，在驗證憑證期間強制執行政策比較有彈性，因為這樣可針對不同類型的部署作業強制執行不同的政策。例如，我們可能想讓測試叢集中的政策較實際工作環境叢集中的政策寬鬆。
在 ALTS 握手期間，憑證驗證作業包括檢查 ALTS 政策。這項政策可確保接受驗證的憑證中所列的核發者有權核發該憑證。如果核發者無權核發該憑證，憑證會遭拒，且握手流程會失敗。圖 4 說明在 ALTS 中強制執行政策的方式。這裡接續圖 2 的情境，假設小麥 (想升級自己權限的企業使用者) 要向網路管理員核發主憑證；網路管理員可重新設定網路，是權力龐大的身分。根據 ALTS 政策，小麥當然無權執行這項作業。
圖 4：憑證核發及使用流程
- 小麥為網路管理員身分核發主憑證，並要求簽署服務簽署。這與圖 2 的前三個步驟類似。
- 小麥使用與所建立的主憑證相關聯的主要私密金鑰，在本機為網路管理員建立及簽署握手憑證。
- 如果小麥嘗試使用所建立的握手憑證冒用網路管理員身分，ALTS 政策強制執行者 (位在小麥嘗試通訊的對等端) 會封鎖這項作業。
撤銷憑證
在 Google，憑證如果過期或列在我們的憑證撤銷清單 (CRL) 中就會失效。本節將說明 Google 內部憑證撤銷機制的設計。
核發給企業使用者的所有憑證都有每日到期時間戳記，強制使用者每天重新進行驗證。許多核發給實際工作環境機器的憑證並未使用到期時間戳記。如果使用時間戳記來讓實際工作環境憑證失效，可能會因時鐘同步問題而造成服務中斷，因此我們避免採用這種做法，而改為使用 CRL 做為憑證輪替和事件/回應處理作業的可靠來源。圖 5 說明 CRL 的運作方式。
圖 5：使用 RevocationID 建立主憑證的流程
- 當我們 CA 的某個執行個體初始化時12，該執行個體會與 CRL 服務聯繫並要求取得撤銷 ID 範圍。撤銷 ID 是長度為 64 位元的 ID，由兩個部分組成，分別是 8 位元的憑證類別 (例如使用者或機器憑證) 和 56 位元的憑證 ID。CRL 服務會選擇某個 ID 範圍，並將這個範圍傳回 CA。
- CA 收到主憑證要求後，會建立該憑證，並從這個範圍中選擇一個撤銷 ID 嵌入憑證。
- 同時，CA 將新的憑證對應至此撤銷 ID，並將這項資訊傳送至 CRL 服務。
- CA 核發主憑證。
握手憑證會獲指派哪個撤銷 ID，取決於憑證的使用方式。例如，核發給真人企業使用者的握手憑證會繼承使用者主憑證的撤銷 ID。如果是核發給 Borg 工作負載的握手憑證，則會依 Borgmaster 的撤銷 ID 範圍指派撤銷 ID。這個 ID 範圍是由 CRL 服務指派給 Borgmaster 的，其流程類似圖 5。對等端只要參與了 ALTS 握手，就會檢查 CRL 檔案的本機複本，確認遠端對等憑證尚未遭到撤銷。
CRL 服務會將所有撤銷 ID 彙整成單一檔案，這個檔案可推送至使用 ALTS 的 Google 機器。雖然 CRL 資料庫有數百 MB，但由於採用了各種壓縮技巧，因此產生的 CRL 檔案只有幾 MB。
ALTS 通訊協定
ALTS 仰賴兩個通訊協定：握手通訊協定 (支援工作階段恢復) 和記錄通訊協定。本節提供各個通訊協定的概要資料。這些概要資料不應視為通訊協定的詳細規格。
握手通訊協定
ALTS 握手通訊協定是基於 Diffie-Hellman 的驗證金鑰交換通訊協定，並且支援完全正向密碼 (PFS) 和工作階段恢復功能。ALTS 基礎架構會確保每個用戶端和伺服器都有憑證，當中包含其各自的身分和鏈結至信任簽署服務驗證金鑰的橢圓曲線 Diffie-Hellman (ECDH) 金鑰。在 ALTS 中，PFS 預設為不啟用，因為即使 PFS 未用於握手，系統也會經常更新這些靜態 ECDH 金鑰以更新正向密碼。在握手期間，用戶端和伺服器會以安全的方式交涉共用傳輸加密金鑰及該加密金鑰要保護的記錄通訊協定。例如，用戶端和伺服器可能會同意使用 128 位元的金鑰，透過 AES-GCM 保護 RPC 工作階段。握手包含四則序列化通訊協定緩衝區訊息，相關總覽請見圖 6。
圖 6：ALTS 握手通訊協定訊息
- 用戶端傳送「ClientInit」訊息來啟動握手。這則訊息包含用戶端的握手憑證，並會列出握手相關加密方式和用戶端支援的記錄通訊協定。如果用戶端嘗試恢復已終止的工作階段，訊息會包含恢復 ID 和已加密的伺服器恢復票證。
收到「ClientInit」訊息後，伺服器會驗證用戶端憑證。如果憑證有效，伺服器會從用戶端提供的清單中選擇握手加密方式和記錄通訊協定。伺服器會結合使用「ClientInit」訊息中的資訊和自己的本機資訊，計算 DH 交換結果。計算結果會做為金鑰導出函式13 的輸入值，與通訊協定的轉錄內容搭配使用，以產生下列工作階段密鑰：
- 用於加密及驗證酬載訊息的記錄通訊協定密鑰 M。
- 要在日後工作階段的恢復票證中使用的恢復密鑰 R。
- 驗證者密鑰 A。
伺服器會傳送 ServerInit 訊息，當中含有其憑證、所選握手加密方式、記錄通訊協定，以及選用的已加密恢復票證。
伺服器傳送包含握手驗證者的「ServerFinished」訊息14。這個驗證者的值是使用雜湊式訊息驗證碼 (HMAC) 計算而來，而 HMAC 是透過預先定義的位元字串和驗證者密鑰 A 得出。
用戶端收到「ServerInit」後，就會驗證伺服器憑證、像伺服器一樣計算 DH 交換結果，並導出相同的 M、R 和 A 密鑰。用戶端會使用導出的 A 驗證收到的「ServerFinished」訊息中的驗證者值。握手流程到這個階段，用戶端可開始使用 M 加密訊息。由於用戶端現可傳送已加密的訊息，因此 ALTS 可說是有一個 RTT 握手通訊協定。
在握手結束時，用戶端會傳送「ClientFinished」訊息，當中有透過不同的預先定義位元字串計算得出的類似驗證者值 (請見步驟 3)。如有需要，用戶端可加入已加密的恢復票證以用於日後的工作階段。伺服器收到並驗證這則訊息後，ALTS 握手通訊協定就會結束，且伺服器可開始使用 M 加密及驗證後續的酬載訊息。
記錄通訊協定
握手通訊協定一節說明了 Google 如何使用握手通訊協定交涉記錄通訊協定密鑰。這個通訊協定密鑰是用來加密及驗證網路流量。執行這些作業的堆疊層就稱為 ALTS 記錄通訊協定 (ALTSRP)。
ALTSRP 包含一套加密配置，並有各種金鑰大小和安全性功能。在握手期間，用戶端會傳送依偏好順序排序的偏好配置清單。伺服器會選擇用戶端清單中符合伺服器本機設定的第一個通訊協定。這種配置選擇方法可讓用戶端和伺服器有不同的加密偏好，同時讓我們逐步導入 (或移除) 加密配置。
訊框
訊框是 ALTS 中的最小資料單位。視其大小而定，每個 ALTSRP 訊息可包含一或多個訊框。每個訊框都包含下列欄位：
- 長度：32 位元的未簽署值，以位元組表示訊框的長度。這個長度為 4 位元組的欄位不會計入訊框總長。
- 類型：32 位元的值，表示訊框的類型，例如資料訊框。
- 酬載：經過驗證且視需要經過加密的實際傳送資料。
訊框的長度上限為 1MB 加 4 個長度位元組。目前 RPC 通訊協定的訊框長度上限更短，因為較短的訊框所需要的緩衝用記憶體也較少。此外，如果潛在的攻擊者發動阻斷服務 (DoS) 攻擊，企圖使伺服器停擺，大型訊框也可能會遭攻擊者利用。除了限制訊框長度外，我們還限制可使用相同記錄通訊協定密鑰 M 加密的訊框數量。視用於加密和解密訊框酬載的加密配置而定，這個上限會有所不同。一旦達到上限，連線就必須關閉。
酬載
在 ALTS 中，每個訊框都包含完整性受保護並視需要經過加密的酬載15。至本文的發佈時間為止，ALTS 支援下列模式：
- AES-128-GCM、AES-128-VCM：AES-GCM 和 AES-VCM 模式，分別包含 128 位元金鑰。這些模式分別使用 GCM 和 VCM 配置16 來保護酬載的機密性和完整性。
- AES-128-GMAC、AES-128-VMAC：這些模式分別支援使用 GMAC 和 VMAC 的完整性限定保護功能來進行標記運算。酬載是以純文字形式傳輸，並包含可保護其完整性的加密編譯標記。
Google 會根據威脅模型和效能要求使用不同的保護模式。如果通訊的實體是在由 Google 控制或第三方代表 Google 控制的實體界線內，則會使用完整性限定保護功能。視其資料的機密性而定，這些實體仍可選擇升級至經過驗證的加密。如果通訊的實體不在由 Google 控制或第三方代表 Google 控制的實體界線內，且通訊是透過廣域網路傳輸，則無論所選模式為何，我們都會自動將連線安全防護機制升級為經過驗證的加密。當資料傳輸至由 Google 控制或第三方代表 Google 控制的實體界限之外時，因為無法採取相同的嚴密安全防護措施，因此 Google 會採取其他保護機制。
每個訊框都會分別受完整性保護，並視需要經過加密。對等的兩端都保有要求和回應計數器，這些計數器在一般作業期間會保持同步。如果伺服器收到順序錯誤或重複的要求，加密編譯完整性驗證就會失敗，導致要求遭捨棄。同樣地，用戶端會捨棄重複或順序錯誤的回應。此外，相較於將計數器的值納入訊框標頭中，讓對等的兩端保有計數器還可節省額外的傳輸中位元組。
工作階段恢復
ALTS 可讓使用者恢復先前的工作階段，而不必執行繁重的非對稱加密編譯作業。工作階段恢復是 ALTS 握手通訊協定的內建功能。
應用程式層傳輸安全性 (ALTS) 握手可讓用戶端和伺服器安全地交換 (及快取) 可用來繼續日後連線的繼續作業票證17。每個快取繼續作業票證都會依繼續作業識別碼 (IDR) 編入索引，在同一個資料中心區塊以相同身分執行的工作負載都有一組專屬識別碼。這些票證是使用與對應識別碼相關聯的對稱金鑰來加密。
ALTS 支援下列兩種繼續工作階段作業：
伺服器端工作階段繼續作業：用戶端建立並加密繼續作業票證，當中包含伺服器身分和導出的繼續作業密鑰 R。握手結束時，繼續作業票證會透過「ClientFinished」訊息傳送至伺服器。在日後的工作階段中，伺服器可選擇透過「ServerInit」訊息將票證傳回用戶端，藉此繼續工作階段。收到票證後，用戶端可復原恢復密鑰 R 和伺服器的身分，並使用這些資訊恢復工作階段。
IDR 與身分相關聯，而非特定連線。在 ALTS 中，多個用戶端可在同一資料中心使用相同的身分。這樣用戶端就能夠在先前未通訊過的伺服器恢復其工作階段 (例如，負載平衡器將用戶端傳送至執行相同應用程式的不同伺服器)。
用戶端工作階段恢復：握手結束時，伺服器會透過「ServerFinished」訊息，將經過加密的恢復票證傳送至用戶端。這個票證包含恢復密鑰 R 和用戶端的身分。用戶端可使用這個票證，針對共用相同 IDR 的任何伺服器，繼續與這些伺服器的連線。
工作階段恢復後，系統會使用恢復密鑰 R 導出新的工作階段密鑰 M′、R′ 和 A′。M′ 是用來加密和驗證酬載訊息，A′ 是用來驗證「ServerFinished」和「ClientFinished」訊息，R′ 會封裝在新的恢復票證中。請注意，同一個恢復密鑰 R 一律不會重複使用。
優缺點
金鑰破解冒用攻擊
就設計上而言，ALTS 握手通訊協定容易受到金鑰破解冒用 (KCI) 攻擊。如果有心人士破解工作負載的 DH 私密金鑰或恢復金鑰，就能使用金鑰以其他工作負載冒充此工作負載18。我們的恢復威脅模型中明確包含這類攻擊，因為我們希望由特定身分的執行個體核發的恢復票證也能由該身分的其他執行個體使用。
ALTS 握手通訊協定有另一種可防範 KCI 攻擊的版本，但只有在不需要恢復的環境中才值得使用。
握手訊息的隱私
ALTS 的設計不會掩飾哪些身分正在進行通訊，因此不會加密任何握手訊息來隱藏對等端的身分。
完全正向密碼
ALTS 支援完全正向密碼 (PFS)，但不會預設啟用這項功能。我們會改為頻繁輪替憑證，為大部分的應用程式建立正向密碼。使用 TLS 1.2 (和先前的版本) 時，無法利用 PFS 功能保護繼續作業的工作階段。如果 ALTS 啟用了 PFS，繼續作業的工作階段也就能享有 PFS 保護。
零往返繼續作業
TLS 1.3 提供不需往返 (即零往返 (0-RTT)) 的工作階段恢復功能，但這類恢復的安全性較低19。我們決定不在 ALTS 中加入 0-RTT 選項，因為 Google 的 RPC 連線通常效期較長。因此，雖然可縮短管道設定延遲時間，但 0-RTT 握手會帶來額外的複雜度及/或降低安全性，這樣並不划算。
更多參考資料
- 如要進一步瞭解 Google 如何加密傳輸中的資料，請參閱 Google Cloud 中的傳輸加密白皮書。
- 如要概略瞭解 Google 技術基礎架構如何將安全性納入設計考量，請參閱 Google 基礎架構安全性設計總覽。