2022年12月，我們宣布推出新版Geo Key Manager封閉測(cè)試。我們希望幫助客戶安全、靈活地按地理位置控制私鑰分發(fā)，Geo Key Manager v2(GeoV2)便是我們?yōu)榇送瞥龅牡谝淮a(chǎn)品。第一版系統(tǒng)（即Geo Key Manager v1）是在2017年作為一個(gè)研究項(xiàng)目推出的，但隨著客戶需求的變化，以及我們自身規(guī)模的擴(kuò)大，我們意識(shí)到，我們需要大力改進(jìn)才能提升用戶體驗(yàn)。
我們?cè)谑褂肎eo Key Manager v1(GeoV1)時(shí)，面臨幾項(xiàng)主要挑戰(zhàn)，其中一項(xiàng)是訪問控制策略不靈活。客戶需要更豐富的數(shù)據(jù)本地化，這往往是因監(jiān)管問題所致。目前，能夠迅速限制訪問敏感關(guān)鍵資料的需求正在不斷增加。Geo Key Manager v1的底層密碼技術(shù)是基于身份的廣播加密和基于身份的撤銷，模擬基于屬性的加密(ABE)的一個(gè)功能子集。換成一個(gè)成熟的ABE方案后，解決了我們?cè)L問控制策略不靈活的問題，為我們的系統(tǒng)提供了一個(gè)更安全的基礎(chǔ)。
我們以前的方案在一開始就凍結(jié)參與的數(shù)據(jù)中心和策略集，從而限制了未來的靈活性，而使用ABE，系統(tǒng)很容易適應(yīng)未來的需求。實(shí)例化后增加額外的數(shù)據(jù)中心提升了性能，我們充分利用這一優(yōu)勢(shì)，極大地簡(jiǎn)化了屬性和策略變更的處理過程。此外，GeoV1還面臨一些復(fù)雜的性能問題，導(dǎo)致較高的尾部延遲和痛苦的手動(dòng)密鑰輪換過程。GeoV2解決了GeoV1存在的這些挑戰(zhàn)和限制。
雖然本文重點(diǎn)討論的是我們的地理密鑰管理解決方案，但這些經(jīng)驗(yàn)也可應(yīng)用于其他訪問控制需求。傳統(tǒng)上，訪問控制解決方案是使用一個(gè)高度可用的中央機(jī)構(gòu)來控制對(duì)資源的訪問。ABE則能夠避免這種單點(diǎn)故障，大家很快便可見證。據(jù)我們所知，目前沒有基于ABE的大型訪問控制系統(tǒng)，希望我們的討論可以啟發(fā)工程師，鼓勵(lì)他們考慮使用ABE作為訪問控制的替代方案，盡量減少對(duì)中心化機(jī)構(gòu)的依賴。為了促進(jìn)采納這一方案，我們?cè)谖覀兊拈_源加密庫CIRCL中加入了我們的ABE實(shí)現(xiàn)方式。
一些不夠令人滿意的嘗試
在討論GeoV2之前，我們先來探討一下我們要解決的問題。
例如：一家大型歐洲銀行希望只將他們的TLS私鑰存儲(chǔ)在歐盟內(nèi)部。這家銀行是Cloudflare的客戶，即我們代表該銀行執(zhí)行TLS握手。我們需要為他們終止TLS，以便我們對(duì)DDoS攻擊提供最佳防護(hù)，通過緩存提高性能，支持web應(yīng)用程序防火墻等。
為了終止TLS，我們需要訪問它們的TLS私鑰1。處理API流量的控制平面將客戶上傳的私鑰與全球所有機(jī)器共有的主公鑰加密。然后，它將密鑰放入全球分布式KV存儲(chǔ)Quicksilver。這意味著世界上每個(gè)數(shù)據(jù)中心的每臺(tái)機(jī)器都有這個(gè)客戶的TLS私鑰的本地副本。因此，每個(gè)數(shù)據(jù)中心的每臺(tái)機(jī)器都有每位客戶的私鑰的副本。
客戶上傳他們的TLS證書和私鑰，并存儲(chǔ)在數(shù)據(jù)中心
然而，這家銀行希望其密鑰僅存儲(chǔ)在歐盟的數(shù)據(jù)中心。為實(shí)現(xiàn)這一目的，我們有三種方案。
第一種方案是確保只有歐盟的數(shù)據(jù)中心可以接收密鑰并終止握手。所有其他機(jī)器將TLS請(qǐng)求代理到歐盟的服務(wù)器進(jìn)行處理。這就需要只給每臺(tái)機(jī)器提供Quicksilver中存儲(chǔ)的整個(gè)密鑰集的一個(gè)子集，而Cloudflare多年來的核心設(shè)計(jì)決策就是假設(shè)整個(gè)數(shù)據(jù)集都復(fù)制在每臺(tái)機(jī)器上，這是需要解決的挑戰(zhàn)。
將客戶密鑰限制在歐盟數(shù)據(jù)中心內(nèi)
第二種方案是將密鑰存儲(chǔ)在核心數(shù)據(jù)中心而非Quicksilver。這樣我們便能每次都執(zhí)行適當(dāng)?shù)脑L問控制策略，確保只有某些機(jī)器可以訪問某些密鑰。但這違背了構(gòu)建全球網(wǎng)絡(luò)的初衷：減少延遲，避免核心發(fā)生單點(diǎn)故障。
將密鑰存儲(chǔ)在核心數(shù)據(jù)中心
但核心數(shù)據(jù)中心需要運(yùn)行復(fù)雜的業(yè)務(wù)邏輯來執(zhí)行策略
第三種方案是使用公鑰加密。每個(gè)數(shù)據(jù)中心都有自己的密鑰對(duì)，而不是一個(gè)主密鑰對(duì)。該核心將客戶的私鑰和允許使用該私鑰的每個(gè)數(shù)據(jù)中心的密鑰加密。在這個(gè)例子中，只有歐盟的機(jī)器能夠訪問該密鑰。假設(shè)有500個(gè)數(shù)據(jù)中心，每個(gè)數(shù)據(jù)中心有50臺(tái)機(jī)器。假設(shè)這500個(gè)數(shù)據(jù)中心中，有200個(gè)位于歐盟。以前100個(gè)1kB的密鑰共需消耗100 x 500 x 50 x 1 kB（全球），現(xiàn)在將變成200倍，在最糟糕的情況下甚至可能消耗500倍。因此，每臺(tái)機(jī)器存儲(chǔ)密鑰所需的空間又增加了一個(gè)全新的因素——以前，存儲(chǔ)空間就是客戶密鑰注冊(cè)數(shù)量的函數(shù)；現(xiàn)在，存儲(chǔ)空間雖然也是客戶密鑰數(shù)量的函數(shù)，但還要乘以數(shù)據(jù)中心的數(shù)量。
為每個(gè)數(shù)據(jù)中心分配唯一的密鑰
并將客戶密鑰與歐盟數(shù)據(jù)中心的密鑰封裝起來
遺憾的是，這三種方案都有各自的缺點(diǎn)。它們要么需要改變Cloudflare架構(gòu)的基本假設(shè)，放棄使用高度分布式網(wǎng)絡(luò)的優(yōu)勢(shì)，要么需要成倍地增加該功能使用的存儲(chǔ)空間。
通過再次深入研究第三種方案后發(fā)現(xiàn)，為什么不為每個(gè)數(shù)據(jù)中心創(chuàng)建兩個(gè)密鑰對(duì)，而只創(chuàng)建一個(gè)唯一密鑰對(duì)呢？一對(duì)為所有歐盟數(shù)據(jù)中心共有，另一對(duì)為所有非歐盟數(shù)據(jù)中心共有。這樣一來，核心就只需要對(duì)客戶的密鑰進(jìn)行兩次加密，而不是為每個(gè)歐盟數(shù)據(jù)中心分別加密。對(duì)歐盟的這家銀行來說，這是一個(gè)很好的解決方案，但一旦我們開始添加額外的策略，它就不能擴(kuò)展了。試想：紐約市的一個(gè)數(shù)據(jù)中心可能有一個(gè)策略的密鑰“country:US”，另一個(gè)策略的密鑰“country:US or region:EU”，另一個(gè)策略的密鑰“not country:RU”，以此類推......您已經(jīng)發(fā)現(xiàn)，這實(shí)在太復(fù)雜了。而且，每次配置新的數(shù)據(jù)中心時(shí)，都必須重新評(píng)估所有策略，并分配適當(dāng)?shù)拿荑€。
每個(gè)策略一個(gè)密鑰與策略否定
Geo Key Manager v1：基于身份的加密和廣播加密
1978年發(fā)明了RSA，拉開了現(xiàn)代公鑰密碼學(xué)時(shí)代的序幕，但任何人只要使用過GPG或參與過證書機(jī)構(gòu)就知道，管理連接密鑰和用戶身份的公鑰基礎(chǔ)設(shè)施非常困難。1984年，Shamir提出，有沒有可能創(chuàng)建一個(gè)公鑰加密系統(tǒng)，這個(gè)公鑰可以是任何字符串。他提出這個(gè)問題是為了簡(jiǎn)化電子郵件管理。Alice可以不使用Bob的公鑰將發(fā)送給Bob的電子郵件加密，而是對(duì)Bob的身份bob institution.org加密。最終，在2001年，Boneh和Franklin想出了有效的實(shí)現(xiàn)方式。
1993年，F(xiàn)iat和Naor首次提出了廣播加密。您可以向所有人發(fā)送相同的加密信息，但只有擁有正確密鑰的人才能解密。回到我們的第三種方案，與其用每個(gè)歐盟數(shù)據(jù)中心的密鑰來封裝客戶的密鑰，我們可以使用廣播加密來創(chuàng)建單個(gè)客戶密鑰加密，只有歐盟的數(shù)據(jù)中心可以解密。這樣就解決了存儲(chǔ)問題。
Geo Key Manager v1結(jié)合使用基于身份的廣播加密和基于身份的撤銷來實(shí)現(xiàn)訪問控制。簡(jiǎn)而言之就是為每個(gè)區(qū)域和每個(gè)數(shù)據(jù)中心位置指定一組身份。然后，每臺(tái)機(jī)器都會(huì)為其所在地區(qū)和位置頒發(fā)一個(gè)基于身份的私鑰。然后就可以用三個(gè)集來控制對(duì)客戶密鑰的訪問：要加密的地區(qū)集、這些地區(qū)內(nèi)要排除的位置集，以及這些地區(qū)外要包括的位置集。例如，通過將客戶的密鑰加密，可以在除幾個(gè)特定位置外的所有地區(qū)以及這些地區(qū)以外的幾個(gè)指定位置使用密鑰。本文詳細(xì)討論了這一方法的所有實(shí)質(zhì)內(nèi)容。
遺憾的是，這個(gè)方案不能充分響應(yīng)客戶的需求；在最初的加密設(shè)置中，使用的參數(shù)（例如地區(qū)、數(shù)據(jù)中心及其屬性的列表）都嵌入在系統(tǒng)中，難以變更。更糟糕的是，由于英國脫歐，因此還要將英國排除在歐盟地區(qū)之外，或根據(jù)客戶需要的最新合規(guī)標(biāo)準(zhǔn)支持一個(gè)新的地區(qū)。此外，由于使用預(yù)先確定的靜態(tài)位置列表，難以快速撤銷機(jī)器訪問。亦或，無法為設(shè)置之后新配備的數(shù)據(jù)中心分配解密密鑰，使其無法加快請(qǐng)求速度。這些限制促使我們?cè)贕eo Key Manager中使用基于屬性的加密(ABE)。
基于屬性的加密
2004年，Amit Sahai和Brent Waters提出了一個(gè)基于訪問策略的新型密碼系統(tǒng)，稱為基于屬性的加密(ABE)。從本質(zhì)上講，消息的加密是針對(duì)訪問策略而非身份。用戶獲發(fā)私鑰是由其自身屬性決定的，只有當(dāng)用戶的屬性與策略相符時(shí)，才能解密消息。與傳統(tǒng)加密方法相比，這可實(shí)現(xiàn)更加靈活精細(xì)的訪問控制。
公鑰加密大事記
該策略可以附加到密鑰或密文上，得到ABE的兩個(gè)變體：基于密鑰策略屬性的加密(KP-ABE)和基于密文策略屬性的加密(CP-ABE)。兩者之間存在權(quán)衡取舍，但功能相當(dāng)，因?yàn)樗鼈兓閷?duì)偶。我們來重點(diǎn)討論CP-ABE，它與現(xiàn)實(shí)世界中的訪問控制更相近。試想在一家醫(yī)院，醫(yī)生的屬性是“role:doctor”和“region:US”，而護(hù)士的屬性是“role:nurse”和“region:EU”。如果文件的加密策略是“role:doctor or region:EU”，則醫(yī)生和護(hù)士均可解密該文件。換而言之，ABE就像一把神奇的鎖，只有具備相應(yīng)屬性的人才能打開。
根據(jù)不同的屬性，可以有許多不同的ABE方案。我們選擇的方案必須滿足幾個(gè)要求：
否定我們希望能夠支持由AND、OR和NOT組成的布爾公式，即非單調(diào)的布爾公式。雖然幾乎每個(gè)方案都會(huì)處理AND和OR，但能處理NOT的比較少見。而否定可更輕松屏蔽某些國家/地區(qū)或機(jī)器。
重復(fù)屬性例如策略“organization:executive or(organization:weapons and clearance:top-secret)”。在該策略中，屬性“organization”重復(fù)了兩次。如果支持重復(fù)，制定策略時(shí)便更容易表達(dá)，靈活性也更高，這極具意義。
安全防御所選密文攻擊大多數(shù)方案的呈現(xiàn)形式都是，只有當(dāng)攻擊者未選擇要解密的消息時(shí)才安全(CPA)。有標(biāo)準(zhǔn)方法可將這類方案轉(zhuǎn)換成“即使有攻擊者操縱密文也安全”的方案(CCA)，但它不會(huì)自動(dòng)轉(zhuǎn)換。我們?cè)谒x方案中應(yīng)用了著名的Boneh-Katz轉(zhuǎn)換，讓該方案能夠應(yīng)對(duì)此類攻擊，提供安全防護(hù)。我們即將發(fā)文提供證據(jù)，證明端到端方案的安全性。
否定特別值得進(jìn)一步討論。一個(gè)滿足條件的屬性被否定時(shí)，其名稱必須保持不變，但其值必須不同。就像數(shù)據(jù)中心說：“我有一個(gè)國家，但絕對(duì)不是XX”，而不是“我沒有國家”。這似乎與直覺相悖，但也因此，解密時(shí)無需檢查每個(gè)屬性的值，還可以安全地逐步推出屬性?；谶@些標(biāo)準(zhǔn)，我們最終選擇了Tomida等(2021)提出的方案。
要實(shí)現(xiàn)如此復(fù)雜的加密方案可能極具挑戰(zhàn)。作為傳統(tǒng)公鑰密碼學(xué)基礎(chǔ)的離散日志假設(shè)并不足以滿足ABE的安全要求。ABE方案必須確保密文和基于屬性的秘鑰的安全，而傳統(tǒng)的公鑰密碼學(xué)只對(duì)密文施加安全限制，而密鑰只是一個(gè)整數(shù)。為了實(shí)現(xiàn)這一點(diǎn)，大多數(shù)ABE方案均使用雙線性配對(duì)（一種數(shù)學(xué)運(yùn)算）來構(gòu)建。
我們進(jìn)行配對(duì)操作的速度決定了實(shí)現(xiàn)的基準(zhǔn)性能。在解密過程中，配對(duì)特別高效，并用于結(jié)合基于屬性的密鑰與密文來恢復(fù)明文。為此，我們依托我們的開源密碼套件庫CIRCL高度優(yōu)化的配對(duì)實(shí)現(xiàn)，我們?cè)谥暗牟┛椭性敿?xì)討論了這一點(diǎn)。此外，各種密鑰、屬性和嵌入訪問結(jié)構(gòu)的密文使用矩陣和矢量來表達(dá)。我們編寫了線性代數(shù)例程來處理矩陣運(yùn)算，例如乘法、轉(zhuǎn)置、逆運(yùn)算，這些都是根據(jù)需要來操作結(jié)構(gòu)。我們還增加了序列化、廣泛的測(cè)試和基準(zhǔn)分析。最終，我們實(shí)現(xiàn)了對(duì)CCA2安全方案的轉(zhuǎn)換。
除核心密碼學(xué)之外，我們還必須決定如何表達(dá)和聲明策略。最終我們決定為API使用字符串。雖然對(duì)程序來說，字符串可能沒有結(jié)構(gòu)那么方便，但我們方案的用戶無論如何都要實(shí)現(xiàn)一個(gè)解析器。我們?yōu)樗麄儗?shí)現(xiàn)解析器似乎是獲得更穩(wěn)定的接口的好方法。這意味著，我們的策略語言的前端是由布爾表達(dá)式組成的字符串，例如“country:JP or(not region:EU)”，后端則是一個(gè)由線和門組成單調(diào)布爾線路。單調(diào)布爾線路僅包括AND門和OR門。為了處理NOT門，我們?yōu)榫€分配了正值或負(fù)值。每個(gè)NOT門都可以直接放在線上，因?yàn)榈履Ω稍试S將“not(X and Y)”等公式轉(zhuǎn)換為“not X or not Y”，析取也是如此。
該API演示如下。中央機(jī)構(gòu)運(yùn)行Setup來生成主公鑰和主密鑰。訪問策略允許的任何人都可以使用主公鑰將消息加密。中央機(jī)構(gòu)持有的主密鑰則用于根據(jù)用戶的屬性為其生成密鑰。屬性本身可以帶外提供。在我們的案例中，我們依靠機(jī)器配置數(shù)據(jù)庫來提供和驗(yàn)證屬性。這些基于屬性的密鑰通過TLS等方式安全分配給用戶，并用于解密密文。該API還包括檢查解密能力和從密文中提取策略的輔助函數(shù)，可以提高可用性。
publicKey, masterSecretKey := cpabe.Setup()policy := cpabe.Policy{}policy.FromString("country: US or region: EU")ciphertext := publicKey.Encrypt(policy, 【】byte("secret message"))attrsParisDC := cpabe.Attributes{}attrsParisDC.FromMap(map【string】string{"country": "FR", "region": "EU"}secretKeyParisDC := masterSecretKey.KeyGen(attrsParisDC)plaintext := secretKeyParisDC.Decrypt(ciphertext)assertEquals(plaintext, "secret message")
回到我們?cè)瓉淼睦印＿@一次，中央機(jī)構(gòu)持有主密鑰。每個(gè)數(shù)據(jù)中心的每臺(tái)機(jī)器都向中央機(jī)構(gòu)提交其屬性集，中央權(quán)威機(jī)構(gòu)經(jīng)驗(yàn)證后，為該特定機(jī)器生成一個(gè)獨(dú)特的基于屬性的密鑰。機(jī)器首次啟動(dòng)時(shí)，如果必須輪換密鑰，或如果一個(gè)屬性發(fā)生了變化，就會(huì)頒發(fā)密鑰，但絕不會(huì)在TLS握手的關(guān)鍵過程中頒發(fā)。這個(gè)解決方案還能防止串通，即兩臺(tái)不具備相應(yīng)屬性的機(jī)器不能通過結(jié)合它們的密鑰來將不能單獨(dú)解密的密鑰解密。例如，一臺(tái)具有屬性“country:US”和另一臺(tái)具有屬性“security:high”的機(jī)器，它們不能串通起來將策略“country:US and security:high”解密。
最重要的是，這個(gè)解決方案可以無縫擴(kuò)展，響應(yīng)機(jī)器變更。如果增加了一臺(tái)新機(jī)器，中央機(jī)構(gòu)可以簡(jiǎn)單地為其頒發(fā)一個(gè)密鑰，因?yàn)樵摲桨覆槐卦谠O(shè)置時(shí)預(yù)先確定參與者，這一點(diǎn)與以前基于的身份廣播方案不同。
密鑰分發(fā)
客戶可以在上傳TLS證書時(shí)指定策略，中央機(jī)構(gòu)將根據(jù)指定的策略使用主公鑰將其私鑰加密。加密后的客戶密鑰將寫入Quicksilver，然后分發(fā)到所有數(shù)據(jù)中心。在實(shí)踐中，這里有一層間接性，我們將在后面的章節(jié)中繼續(xù)討論。
使用主公鑰加密
用戶訪問客戶的網(wǎng)站時(shí)，首先收到請(qǐng)求的數(shù)據(jù)中心的TLS終止服務(wù)會(huì)從Quicksilver獲取客戶的加密私鑰。如果服務(wù)的屬性與策略不符，則解密失敗，請(qǐng)求將被代理到最近的、與策略相符的數(shù)據(jù)中心。無論哪個(gè)數(shù)據(jù)中心，只要能成功將密鑰解密，就會(huì)執(zhí)行簽名，完成TLS握手。
使用基于屬性的密鑰解密（簡(jiǎn)化版）
下表總結(jié)了上述各解決方案的優(yōu)缺點(diǎn)：
性能特征
我們受ECRYPT啟發(fā)，總結(jié)了一些測(cè)量來描繪方案的性能。我們將屬性“size”設(shè)置為50，這遠(yuǎn)高于大多數(shù)應(yīng)用程序的需要，但可以作為基準(zhǔn)測(cè)試的最壞情況參考。我們?cè)谂鋫溆⑻貭柨犷7-10610U CPU 1.80GHz的筆記本電腦上進(jìn)行測(cè)量，并將結(jié)果與2048位安全的RSA、X25519和我們以前的方案進(jìn)行比較。
不同的基于屬性的加密方案優(yōu)化了不同的性能特征。有些可能可快速生成密鑰，而另一些可能優(yōu)先考慮快速解密。在我們的案例中，我們只關(guān)心快速解密，因?yàn)橹挥羞@個(gè)環(huán)節(jié)位于請(qǐng)求的關(guān)鍵路徑上。其他事情都發(fā)生在帶外，而帶外開銷是可以接受的。
基于屬性的訪問控制(ABAC)簡(jiǎn)介
我們使用基于屬性的加密來實(shí)現(xiàn)所謂的基于屬性的訪問控制(ABAC)。
ABAC源自更熟悉的基于角色的訪問控制(RBAC)。為了理解ABAC的重要性，我們簡(jiǎn)單討論一下它的起源。1970年，美國國防部推出了自主訪問控制(DAC)。DAC是Unix文件系統(tǒng)的實(shí)現(xiàn)方式。但是，如果您想限制再共享，只有DAC是不夠的，因?yàn)橘Y源的所有者可能在中央管理員不同意的情況下授權(quán)其他用戶訪問資源。為了解決這一問題，美國國防部推出了強(qiáng)制訪問控制(MAC)。DRM就是一個(gè)很好MAC示例。即使文件擁有者也無權(quán)與他人分享。
RBAC是對(duì)MAC某些方面的實(shí)現(xiàn)。ABAC是RBAC的延伸。2017年，NIST確定了RBAC的標(biāo)準(zhǔn)，以應(yīng)對(duì)越來越多不受角色限制的用戶特征，例如時(shí)間、用戶代理等。
然而，RBAC/ABAC只是一種規(guī)范。雖然它們傳統(tǒng)上是用一個(gè)中央機(jī)構(gòu)來控制對(duì)某些資源的訪問，但并非必須如此?；趯傩缘募用苁窃诜植际较到y(tǒng)中實(shí)現(xiàn)ABAC的優(yōu)良機(jī)制。
密鑰輪換
雖然可能很容易把所有問題都?xì)w咎于DNS，但在這場(chǎng)競(jìng)賽中，更換密鑰也是強(qiáng)有力的競(jìng)爭(zhēng)對(duì)手。由于Geo Key Manager v1的密鑰輪換過程非常依賴人工操作，且容易出錯(cuò)，所以我們打算在不影響可用性的情況下進(jìn)行強(qiáng)大而簡(jiǎn)單的密鑰輪換，這是Geo Key Manager v2明確的設(shè)計(jì)目標(biāo)之一。
為了方便密鑰輪換，改善性能，我們?yōu)榭蛻舻拿荑€封裝（加密）過程引入了一層間接性。客戶上傳他們的TLS私鑰時(shí)，我們不用主公鑰加密，而是生成一個(gè)X25519密鑰對(duì)，即策略密鑰。然后，中央機(jī)構(gòu)將這個(gè)新產(chǎn)生的策略密鑰對(duì)的公共部分及其相關(guān)的策略標(biāo)簽添加到一個(gè)數(shù)據(jù)庫中，然后再根據(jù)相關(guān)訪問策略，使用主公鑰將策略密鑰對(duì)的私有部分加密?？蛻舻乃借€便通過公共策略密鑰得以加密，并保存在Quicksilver中。
用戶訪問客戶的網(wǎng)站時(shí)，收到請(qǐng)求的數(shù)據(jù)中心的TLS終端服務(wù)會(huì)獲取與客戶訪問策略相關(guān)的加密策略密鑰。如果機(jī)器的屬性與策略不符，則解密失敗，請(qǐng)求將被轉(zhuǎn)發(fā)到最近的、條件相符的數(shù)據(jù)中心。如果解密成功，則使用策略密鑰將客戶的私鑰解密，并完成握手。
然而，策略密鑰并不是為每位客戶的證書上傳而生成。如下圖所示，如果客戶請(qǐng)求的是系統(tǒng)中已經(jīng)存在的策略，因此也存在一個(gè)相關(guān)的策略密鑰，那么將重復(fù)使用該策略密鑰。由于大多數(shù)客戶使用相同的幾個(gè)策略，例如限制在某一個(gè)國家/地區(qū)，或限制在歐盟，與客戶密鑰相比，策略密鑰的數(shù)量要少幾個(gè)數(shù)量級(jí)。
策略密鑰
這種策略密鑰共享對(duì)密鑰輪換幫助極大。如果主密鑰被輪換（機(jī)器密鑰也隨之輪換），只需要將少數(shù)用于控制客戶密鑰訪問的策略密鑰重新加密，而不需要將每位客戶的密鑰重新加密。這降低了計(jì)算和帶寬要求。此外，在TLS終端服務(wù)中緩存策略密鑰，通過減少關(guān)鍵路徑中的頻繁解密需求來提高性能。
這與混合加密相似。在混合加密中，公鑰加密法用于建立一個(gè)共享的對(duì)稱密鑰，然后使用對(duì)稱密鑰加密數(shù)據(jù)。差別在于，策略密鑰不是對(duì)稱密鑰，而是X25519密鑰對(duì)——一個(gè)基于橢圓曲線的非對(duì)稱方案。雖然沒有AES等對(duì)稱方案那么快，但傳統(tǒng)的橢圓曲線加密技術(shù)比基于屬性的加密要快得多。這里還有一點(diǎn)優(yōu)勢(shì)：中央服務(wù)不需要通過訪問密鑰資料來將客戶密鑰加密。
穩(wěn)健的密鑰輪換的另一組成部分涉及維護(hù)多個(gè)密鑰版本。最新的密鑰生成用于加密，但最新和以前的版本可用于解密。我們使用一個(gè)狀態(tài)系統(tǒng)來管理密鑰轉(zhuǎn)換和安全刪除舊密鑰。我們還部署了廣泛監(jiān)測(cè)系統(tǒng)，如果任何機(jī)器沒有使用適當(dāng)?shù)拿荑€生成，就會(huì)提醒我們。
大規(guī)模尾部延遲
Geo Key Manager存在高尾部延遲問題，這有時(shí)會(huì)影響可用性。Jeff Dean的文章The Tail at Scale（《大規(guī)模尾部延遲》）很有啟發(fā)性，說明以Cloudflare的規(guī)模，即使p99延遲升高也會(huì)造成損害。盡管我們對(duì)服務(wù)的服務(wù)器和客戶端組件進(jìn)行了改造，但并沒有考慮p99延遲問題。這些改造（例如從Worker池切換到每個(gè)請(qǐng)求一個(gè)Goroutine）確實(shí)簡(jiǎn)化了服務(wù)，因?yàn)閯h除了數(shù)千行代碼。分布式跟蹤能夠確定延遲發(fā)生在客戶端發(fā)送請(qǐng)求和服務(wù)器接收請(qǐng)求之間，但我們無法進(jìn)一步確定。去年我們甚至寫了一篇博客，介紹了我們的排查嘗試，但沒有得出具體的解決方案。
最后，我們意識(shí)到，客戶端和服務(wù)器之間存在一層間接性。我們世界各地的數(shù)據(jù)中心規(guī)模相差很大。為了避免小型數(shù)據(jù)中心被連接淹沒，大型數(shù)據(jù)中心將使用Go net/rpc庫安排各臺(tái)中間機(jī)器將請(qǐng)求代理到其他數(shù)據(jù)中心。
一旦我們將中間服務(wù)器的轉(zhuǎn)發(fā)功能納入追蹤范圍，問題就一清二楚了。發(fā)出請(qǐng)求和處理請(qǐng)求之間有一個(gè)很長(zhǎng)的延遲。然而，此代碼只是對(duì)一個(gè)內(nèi)置庫函數(shù)的調(diào)用。它為什么要將請(qǐng)求延遲呢？
最終我們發(fā)現(xiàn)，將請(qǐng)求序列化時(shí)，有一個(gè)鎖無法解鎖。net/rpc包不支持流，但我們?cè)趃RPC出現(xiàn)之前編寫的面向數(shù)據(jù)包的自定義應(yīng)用程序協(xié)議確實(shí)支持流。為了解決這一問題，我們執(zhí)行了一個(gè)請(qǐng)求，并等待序列化函數(shù)的響應(yīng)。雖然這可快速完成代碼編寫，但它造成了性能瓶頸，因?yàn)槊看沃荒苻D(zhuǎn)發(fā)一個(gè)請(qǐng)求。
我們的解決方案是使用協(xié)調(diào)通道，讓多個(gè)請(qǐng)求執(zhí)行，同時(shí)等待響應(yīng)。在我們推出之時(shí)，我們發(fā)現(xiàn)尾部延遲已大為降低。
在澳大利亞的遠(yuǎn)程colo中修復(fù)RPC故障的結(jié)果
遺憾的是，我們無法將光速提高（至少目前如此）?？蛻羧绻Ｍ麄兊拿荑€只保存在美國，但他們的網(wǎng)站用戶卻在地球的另一面，那就不得不忍受一些延遲，因?yàn)樾枰M(jìn)行越洋傳輸。但由于有會(huì)話票證，這些延遲只會(huì)影響新的連接。
正常運(yùn)行時(shí)間也顯著增加。加密啟動(dòng)之后才配置的數(shù)據(jù)中心現(xiàn)可加入系統(tǒng)，這也意味著不符合特定策略的數(shù)據(jù)中心會(huì)有更多符合條件的鄰居，可以將簽署請(qǐng)求轉(zhuǎn)發(fā)給這些鄰近的數(shù)據(jù)中心。這增加了系統(tǒng)冗余，對(duì)于沒有最佳互聯(lián)網(wǎng)連接的地區(qū)的數(shù)據(jù)中心特別有利。下圖表示在兩天時(shí)間中，全球每臺(tái)機(jī)器進(jìn)行的成功探測(cè)。對(duì)于GeoV1，我們發(fā)現(xiàn)，限制在美國和歐盟地區(qū)的策略的網(wǎng)站一度降到98%以下；而對(duì)于GeoV2，正常運(yùn)行時(shí)間可用性很少降到99.99%以下。
不同密鑰配置的正常運(yùn)行時(shí)間（GeoV1在美國和歐盟
以及GeoV2在美國、歐盟和印度）
總結(jié)
親愛的讀者，感謝您堅(jiān)持閱讀到這里。應(yīng)用密碼學(xué)也經(jīng)歷了漫長(zhǎng)的發(fā)展才走到今天，但只有少數(shù)研究成果能夠走出實(shí)驗(yàn)室，獲得實(shí)際采用。彌合研究與現(xiàn)實(shí)的差距，有助于實(shí)現(xiàn)以創(chuàng)新方式保護(hù)敏感數(shù)據(jù)。過去幾年中，基于屬性的加密本身已經(jīng)變得更加高效、更具特色。希望本文能給您啟發(fā)，鼓勵(lì)您考慮使用ABE來解決自己的訪問控制需求，特別是如果您處理的是一個(gè)分布式系統(tǒng)，且不想依賴一個(gè)高度可用的中央機(jī)構(gòu)。我們已經(jīng)在CIRCL中公開了我們的CP-ABE實(shí)現(xiàn)的開源代碼，并計(jì)劃撰文提供更多細(xì)節(jié)。
希望這一新的密碼學(xué)技術(shù)基礎(chǔ)將使Geo Key Manager產(chǎn)品大為改進(jìn)。除存儲(chǔ)私鑰外，我們還計(jì)劃使用這種基于ABE的機(jī)制來存儲(chǔ)其他類型的數(shù)據(jù)。我們正在努力提高其操作便捷性，并進(jìn)行通用化處理，供內(nèi)部服務(wù)部門使用。
致謝
特別感謝Watson Ladd在Cloudflare任職期間為本項(xiàng)目做出的巨大貢獻(xiàn)。
Cloudflare
專欄
閩公網(wǎng)安備 35010202001226號(hào)
