來源 | 中國計算機學會
本文将從資料安全防護的重大戰略需求出發，聚焦資料安全搜尋、加密資料庫技術等前沿領域，深入探讨加密資料庫的發展現狀，揭示其設計過程中存在的安全性和性能方面的挑戰，并提出未來關于加密資料庫建設的一些願景。
加密資料庫體系及核心需求
資料是驅動數字經濟發展最核心動力，此觀念已然成為行業共識。以資料為基礎的大資料、雲計算、物聯網、區塊鍊、人工智能等資料科學在智慧城市更新、國家重大基建産業發展等方面發揮着重要的作用。考慮到資料作為核心生産要素的重要地位，保護資料的安全和隐私不容忽視。它關乎國家安全，尤其資料科學與工業生産的互相融合使得資料安全的影響蔓延到軍事、金融、醫療、教育等各個領域。在此背景下，學界和工業界都已經開始大力推動大資料安全戰略布局，各國政府也都相繼出台各項法律法規以規範保障資料的安全使用和生産，如我國的《網絡安全法》、《密碼法》等。
然而，近年來頻頻暴發的資料洩露事件表明，資料安全保護的現狀仍不容樂觀。據IBM安全機構釋出的消息稱，僅在過去的一年裡，由于資料洩露事件造成的平均經濟損失高達386萬美元[1]。為了最大程度防止資料隐私洩露，保障資料在整個生命周期内（包括：存儲、傳輸以及處理/運作）的安全性成為迫切需要解決的問題。對于資料存儲和傳輸過程中的安全保護，已經有了諸多受到業界認可的國内外安全标準和算法，比如AES、國密及TLS等。這些技術的使用可以極大降低資料在靜态存儲及流轉時的風險。
但是對于資料運作時的保護，卻仍存在很大的局限性。随着資料成為不可或缺的核心生産要素，其在生産使用過程中的相關安全隐患也逐漸顯露出來。具體來說，在諸多應用場景中，程式運作時記憶體中的資料仍然是以明文方式存在的，給了來自内部/外部攻擊者可乘之機。為了保護運作時的資料安全，就要求做到資料“可用”但“不可見”。這不僅有助于抵禦來自上述内部/外部的攻擊者，達到資料的縱深安防保護，也能夠盡最大可能地保留資料作為生産要素的原生價值[2]。
目前，資料全生命周期的安全保護（尤其是運作時安全）是當今資料安全行業内（學界和工業界）公認的熱點問題。随着應用場景對資料安全要求的不斷提高，資料運作時安全的技術方向和發展趨勢日新月異，湧現出了像同态加密、安全多方計算、可搜尋加密、可信硬體等優質的安全防護技術。這些熱點技術側重點各異，正在學界和工業界的一同推進下飛速發展。不僅有來自谷歌、微軟等開源庫的分享，也有國内阿裡牽頭，針對安全多方計算國際标準的推動。這些努力極大推進了資料安全建設的步伐，維護了資料安全生産的穩定性。
本文拟從推動資料運作時安全的戰略需求出發，聚焦加密資料庫這一前沿領域，深入介紹相關可行性技術路線的發展現狀，包括可搜尋加密技術以及近年來趨于成熟的可信硬體技術等。與此同時，我們也将針對相關技術路線所面臨的不足和挑戰，展望潛在研究方向，并探讨關于加密資料庫建設的一些未來願景。
可搜尋加密的誕生與發展
如圖1所示，可搜尋加密主要解決的是加密資料庫的安全檢索問題。其主要過程如下：（1）資料擁有者在本地加密資料并上傳到加密資料庫伺服器。（2）資料庫伺服器在不可見“查詢請求明文”和“資料内容明文”的情況下，仍然能夠進行“加密”查詢操作，并将比對的結果（密文）集傳回給使用者。
實作這類可搜尋加密的密碼學工具種類繁多，大緻包括：（1）屬性保護加密算法(Property-Preserving Encryption，PPE)，包括保序加密(Order-Preserving Encryption，OPE；Order-Revealing Encryption，ORE)、确定性加密(Deterministic Encryption，DTE)等；（2）同态加密(Fully / Somewhat Homomorphic Encryption，HE)；（3）不經意随機通路機制(ORAM)；（4）功能加密(Functional Encryption)；（5） 對稱可搜尋加密(Searchable Symmetric Encryption，SSE)。在上述各種安全設計中，PPE 在功能和效率上有突出的表現，卻洩露了更多資訊；ORAM、HE 能提供較強的安全性保證，但相應的性能方面仍然有待加強。相比之下，SSE能平衡效率和安全性。
基于對稱密鑰的可搜尋加密
對稱可搜尋加密(SSE)[3]的設計思想來源于在明文上基于索引的搜尋機制。給定明文資料集，資料擁有者首先建構基于明文關鍵詞/文檔的逆序搜尋索引(inverted index)，該索引記錄與關鍵詞相比對的檔案集合。例如：K1→{F1, F4, F2}記錄了包含關鍵詞K1的文檔集合{F1, F4, F2}。然後，利用單向函數以及對稱密鑰工具，将該搜尋索引加密，生成一個可以搜尋的加密索引結構，同時也對資料集進行加密。加密索引的内容并不涉及資料本身的明文資訊，僅描述了關鍵詞與檔案集的映射關系。注意到該加密索引資料結構在搜尋查詢之前是加密狀态，僅當接收到合法授權的加密查詢請求時，才能打開對應項目進行檢視。在後續的查詢過程中，對于任意一個搜尋請求，可以通過一個安全的單向函數（如基于密鑰的僞随機函數），将明文查詢請求（如K1）轉變成密文請求token(K1)。對應的加密索引項目token(K1)被打開後，與該token對應的檔案集辨別1、4、2被暴露出來，這樣伺服器可以将加密檔案F1、F4、F2 傳回。在整個查詢過程中，查詢請求明文和資料内容對伺服器是不可見的。
在過去的近二十年裡，學界和業界的專家學者們為可搜尋加密在功能、效率和安全性方面的完善付出了很多的努力，極大地推動了可搜尋加密的發展程序[4~7]。針對一些前沿難點都有了相應的代表性技術方案予以支撐，諸如：（1）支援增、删、改的動态可搜尋加密方案；（2）支援範圍查詢、k-近鄰查詢、多關鍵詞查詢、布爾查詢、排序查詢、近似查詢等豐富查詢功能的加密方案；（3）大規模加密資料的搜尋部署，資料I/O對性能的影響等。
可搜尋加密安全定義下的洩露函數及相關攻擊
上述示例中，針對整個查詢過程，伺服器雖然看不見明文資料，但仍然可以觀察到一些資訊，包括：（1）搜尋模式，它記錄着重複的搜尋查詢；（2）通路模式，滿足搜尋查詢的（加密）檔案集，即查詢結果。直覺上，這些資訊并不洩露加密的資料内容，它們可以看作是為了讓伺服器更快地達到搜尋查詢目的，而不得不犧牲掉的一些“輔助”資訊。在密碼學中，這些資訊的具體定義源于相關的洩露函數(leakage functions)。安全的密碼學方案要求除洩露函數定義的資訊以外，不洩露有關資料集的額外資訊，即洩露是被允許且可控的。
基于可控洩露的安全性模型自提出以來便被運用在各種可搜尋加密方案中。然而，這些洩露真的可控嗎？挖掘被允許的資訊洩露（如搜尋結果集/通路模式等）是否可能暴露相關明文資料特征？是否會對資料本身的機密性有影響呢？2012年，Islam等人的工作首次表明了在掌握一定先驗知識的情況下，敵手可以通過SSE中的可允許洩露的通路模式分析出相應的查詢内容，開啟了洩露濫用攻擊(Leakage-Abuse Attack，LAA)的先河[8]。此後，越來越多的方案被指出存在類似安全性缺陷。
1. 通路模式洩露攻擊。CCS’15（ACM計算機與通信安全大會）提出的基于查詢結果長度的攻擊，針對CCS’06提出的允許通路模式洩露的SSE方案的安全性，給出了第一個較為系統性的研究[9]。
如圖2所示，明文索引裡關鍵詞“chair”“food”“score”所對應的結果集的大小分别為4、4、3。此時，若敵手觀察到一個加密查詢token其傳回結果的數量是3（唯一長度），則敵手可以直接推斷出該token所對應的查詢内容為“score”。同時，在已知該token查詢結果的基礎上，若敵手發現另一個加密查詢傳回的結果中有兩個檔案與“score”的查詢重合，即共現文檔數(co-occurrence count)為2，則可以斷定該查詢的内容為“chair”。上述攻擊統稱為計數攻擊(count attack)，即利用可搜尋加密通路模式中提取的搜尋結果長度和多個搜尋結果間共現模式的唯一性，作為判斷依據來推斷出相應的查詢内容。
2. 範圍查詢洩露攻擊。除了通路模式，可搜尋加密同時還存在其他的洩露函數，它們同樣可以被用來恢複查詢相關的密文資料内容。比如支援範圍查詢(range search)的可搜尋加密（例如 ORE、OPE），它們同時還洩露查詢結果集合之間的順序關系。下面介紹關于範圍查詢的洩露攻擊示例[10]。如圖3所示，給定某加密表，ID列指row ID，Value列指加密後的資料值，拟通過查詢語句中的where條件範圍查詢來篩選相關資料。這些值加密後，都是不洩露大小關系的。搜尋結果本身，比如查詢請求1(Query 1)傳回的結果{2,3,5,7}也不洩露結果集内資料值之間的大小關系。但是查詢語句中的範圍查詢條件“<” 是有可能被允許觀察到的。根據這一特性，敵手可以通過有限次的範圍查詢，完全或部分重構加密資料集的大小順序。例如，敵手觀測到查詢請求2(Query 2)的傳回結果{2, 3, 5, 7, 8}包含查詢請求1的結果集，則可以推測出檔案8所對應的值最大。此時，假設敵手還掌握其他背景資訊（比如已知部分明文資料庫資訊作為參考），可以進一步推測出加密資料的具體值。
3. 2D範圍查詢攻擊。在前期範圍查詢的基礎上，Falzon等人提出了針對2D範圍内k鄰近查詢的攻擊方案[11]。顧名思義，2D查詢傳回指定區域内的所有點。如圖4左圖所示，在明文情況下拟查詢某城市區域[(1,7),(1,4)]内的酒店資訊，伺服器應傳回酒店H1、H3；相應的，若給定酒店位置資訊的加密表（如圖4右圖所示），針對同樣的範圍查詢，在密文情況下，假設伺服器傳回該查詢結果為p2、p3。假設敵手觀察到的所有結果中，傳回長度為2的查詢結果分别為{p1, p2}、{p2, p3}、{p3, p4}。注意到，p1、p3必然分布在p2的兩端，否則應該存在結果{p1, p3}，進而可以确定存在一條直線路徑 p1→p2→p3。同理有p2→p3→p4，進而推斷p1→p2→p3→p4為完整的直線路徑。若背景資訊表明該路徑上的點對應于一條街道上的酒店，假設從遠到近分别為：H3、H1、H4、H2，則敵手可以通過該順序路徑恢複加密表中資料集與明文所對應酒店間的關系。如p1、p2、p3、p4 分别為H3、H1、H4、H2 或者H2、H4、H1、H3。該方法還可以拓展成支援多條路徑的推斷攻擊。
此外，還有針對查詢分布的不同假設，以及利用搜尋模式來輔助攻擊的方法，這裡不再詳述。
上述案例表明，現有的可搜尋加密方案普遍存在洩露濫用攻擊的安全隐患。這些隐患不僅僅影響資料的安全性，如果不給予足夠的重視與防範，一旦被敵手惡意地放大利用，更可能演變成實際部署中的重大資料洩露事故。鑒于此，針對可搜尋加密安全性強化的研究，逐漸成為研究者近年來關注的焦點。
可搜尋加密的安全性強化與挑戰
對于目前已知的攻擊，學界已開始研究如何消除由這些允許的資訊洩露所帶來的安全性隐患。一個比較經典的設計就是使用填充(padding)來隐藏可搜尋加密方案的查詢結果集的數量資訊(volume)[12]。如圖5所示，中間圖表示資料庫中各關鍵詞（橫坐标）所對應的volume大小（縱坐标）。不難發現，圖中大部分關鍵詞都具有唯一的volume大小。而volume的資訊在資料加密前後是不變的，是以，敵手可以通過觀察各查詢傳回結果的volume大小來推斷出查詢的内容[9]。
為了隐藏該資訊，最直覺的方法就是通過将虛假檔案填充到原資料庫中，使得所有的關鍵詞都有相同的volume大小，如圖5右圖所示。這樣，從volume的大小方面來看，敵手就無法區分不同的關鍵詞，但是這種做法需要引入大量的虛假填充檔案，會造成較大的存儲和通信開銷。為了解決這個問題，也有學者提出局部的填充方案，即先将關鍵詞分組（比如每組C個關鍵詞）再填充，使每一組的C個關鍵詞都具有相同的volume大小。這樣，每一組内的關鍵詞從volume的角度是無法區分的。使用者可以根據自己的需求選取每一組關鍵詞的數量，以權衡相應的安全強度和存儲開銷（C越大，填充越多，存儲開銷大，安全性越高）。
上述例子通過volume填充，在一定程度上緩解了針對volume洩露所帶來的壓力。但是目前加密資料庫的洩露函數形式紛繁複雜，濫用攻擊方式層出不窮。僅僅針對查詢結果集的數量資訊做防護是遠遠不夠的，敵手仍有可能從其他角度進行攻擊，比如不同關鍵詞在同一檔案内同時出現的關系。為了全面防範這類攻擊，我們需要對可搜尋加密的安全洩露問題有更深刻的了解。如何更全面地度量可控資訊洩露的現實含義并提出相關攻防設計，将成為可搜尋加密技術應用在未來實際部署過程中必須要解決的重難點問題之一。
建構加密資料庫系統的探索
作為保障資料生産資料的安全基石，建構一個安全可靠的加密資料庫系統有着十分重要的戰略意義。可搜尋加密技術作為最相關的一類密碼學原語，是該安全系統研發道路上的一個重要組成部分，為資料安防保護奠定了重要的理論基礎。我們在不斷追求其在查詢方面安全性強化的同時，也要考慮到來自系統和應用/業務邏輯支撐等各方面的挑戰，在“豐富的查詢功能”以及“高效的查詢性能”方面，不斷探索新的可行性技術路線。
近年來，随着可信硬體技術的發展，一些用于實作可信執行環境 (Trusted Execution Environment，TEE)的技術也趨于成熟，并逐漸進入學界和工業界的視野，例如ARM TrustZone和Intel SGX。研究人員在探索如何打造一個全功能的加密資料庫的技術手段上，也從早期的純密碼學方案逐漸過渡到與可信硬體相結合的方向上，拟借助可信硬體技術來構造功能和性能完備的潛在解決方案[13~17]。
基于可信硬體的加密資料庫系統
Intel推出的基于硬體的TEE技術稱為SGX，它允許開發者對程式進行劃分，将需要保護的部分運作在一個稱為Enclave的可信執行區域内，Enclave外部被劃分為不可信區域。硬體會保護可信執行區域内部不受其他來自不可信區域的非法通路。這樣的設計讓SGX的可信計算基(Trusted Computing Base，TCB)非常小，僅需包含硬體和運作在Enclave内的代碼。但這導緻程式執行的過程中需要在可信部分和不可信部分之間來回切換，即頻繁地進出Enclave。SGX在實體記憶體中劃分了一段空間用于存儲Enclave的代碼和資料。目前，該實體記憶體空間的上限為256MB，SGX使用了頁交換的方式來突破實體記憶體大小的限制。
相比于前述基于純密碼學工具的設計思路，基于可信硬體的加密資料庫拟具備如下優點，主要包括：（1）TEE内部資料天然地具有私密性和完整性的保護；（2）TEE能提供更豐富的功能和更好的性能，避免了複雜且功能受限的密碼學方案設計。例如使用OPE/ORE加密方案時，僅能進行範圍查詢，并不能支援資料庫查詢中的所有運算符。而基于可信硬體的方案不需要建構複雜的密碼學方案，在可信硬體内部可以直接進行安全可信的明文處理。相比之下，可信硬體能支援更複雜的加密資料查詢與計算，并且性能也更優。
可信硬體給加密資料庫帶來靈活、高效計算性能的同時也面臨着諸多問題。首先，TEE本身存在安全性隐患，一方面是因為硬體上可能存在漏洞，另一方面是可信硬體在設計時沒有考慮側信道攻擊，比如Intel SGX明确表明不防禦側信道攻擊。雖然這些攻擊需要的條件較為苛刻，但也一定程度地影響了TEE的安全性。其次，如果運作在TEE内的代碼本身存在漏洞，則仍可以被攻擊者利用，破壞資料庫的安全性。運作在TEE内的代碼越多，其存在漏洞的可能性越大。是以，我們希望能盡可能少地把系統子產品放到TEE中，保證一個較小的TCB。最後，可信硬體的使用不可避免地會引入額外開銷， 例如程式進出Enclave以及資料的頁交換等。
如果希望将TEE應用在加密資料庫上，需要克服上述缺陷，尤其是安全性和性能的問題。這與如何切分程式，即把哪部分代碼和資料放到Enclave内緊密相關。通常，資料庫由很多子產品組成，包括請求的解析器、計劃生成器、計劃執行器、日志子產品等。這些子產品還可以再進一步細分，除了代碼子產品，還有表格、索引子產品等。要把哪些子產品放入Enclave内是利用Enclave實作加密資料庫的一大難點問題。例如，當把計劃執行器的代碼、表格和索引資料放入Enclave時，整個查詢執行的過程以及使用者表中的資料都能得到保護。但是使用者的查詢語句以及表結構的隐私就無法顧及。把更多的代碼子產品和資料放入Enclave中可以保護更多的内容，但相應的TCB也将變大，同時還可能會帶來性能問題。除了安全性和性能，使用Enclave還需要有工程難度的考量。這是由于Enclave對内部程式存在一定的限制，放到Enclave裡的代碼往往需要一定的修改才能夠正常使用。基于這些思考，我們介紹兩種代表性的設計思路示例，并分析其優缺點和可行性。
基于安全資料庫管理系統的設計
基于Enclave實作安全加密資料庫最直接的思路就是利用Enclave保護資料庫管理系統，EnclaveDB[13]。此類方案一般假設Enclave支援的實體記憶體足夠大。如圖6所示，基于這個假設，EnclaveDB将SQL server的記憶體資料庫管理引擎連同所有的敏感資料，包括表和表上的索引，都儲存在Enclave記憶體中。在每個加密表上支援的各種操作都預先由使用者本地編譯優化，生成編譯後的查詢(compiled queries)，在資料庫初始化階段一同加載到Enclave中。使用者的查詢請求經過代理子產品時，代理子產品會對查詢中的敏感資料加密，發送到SQL server上。如果查詢是關于敏感資料的，就會通過調用儲存在Enclave内的compiled queries執行查詢，否則就像普通資料庫一樣由Enclave外部的SQL server處理。
從安全的角度來看，将完整的記憶體資料庫引擎以及資料都放在Enclave，既保護了使用者資料的私密性和完整性，又保護了資料庫引擎自身的各種中繼資料、中間資料等資訊，具有較高的安全性。從性能角度來看，資料放在Enclave内的方案，合理利用了Enclave自身的硬體加密和校驗機制；同時基于Enclave記憶體足夠大的假設，整個資料處理邏輯都在Enclave内，Enclave進出的開銷與待處理的資料大小無關。但是以目前硬體的發展速度來看，要在實際應用中滿足Enclave記憶體足夠大的假設（例如支援動辄上百GB的使用者資料表），仍然面臨諸多技術挑戰，需要學界和業界的共同努力，以及可信硬體提供商的大力投入與研發支援。
基于Enclave安全運算的設計
第二種基于Enclave的加密資料庫設計，是僅利用Enclave進行安全資料運算處理[15]，與上一種設計思路相反，它旨在把盡量少的子產品放入Enclave内。如圖7，這類方案大多基于資料庫插件擴充的方式，通過擴充定義各種加密資料類型，并針對性地定制對應的表達式操作函數，例如大小比較、運算、數學函數、哈希(hash)計算等，進而實作基于Enclave的加密資料庫的查詢與計算。在Enclave内部的安全運算，保證了相關加密資料在運作時的安全性。這種方式可以友善地內建在現有的各種資料庫上，無須對原來的資料庫系統做較大的改動。
下面我們通過示例來說明基于Enclave安全運算的加密資料庫處理查詢請求的流程。考慮如下查詢語句：SELECT SUM(c_balance) FROM customer WHERE c_city = ‘0xaef5306c’，即需要查詢隸屬某市的（c_city=‘0xaef5306c’，城市名是密文）所有消費者(customer)的賬戶餘額（c_balance，餘額是密文）總和(SUM（c_balance）)。系統首先會周遊所有的消費者，然後通過Enclave中的比較函數判斷某消費者是否屬于某市，獲得比較結果True或者False，傳回給資料庫。在獲得滿足城市條件的資料記錄之後，資料庫再不斷調用Enclave中的加法函數，周遊這些消費者的餘額進行累加，最後計算出加密的餘額總和并傳回給資料庫。注意到，整個查詢任務執行過程中，需要進出Enclave的次數和待處理資料量有關，是以在資料量較大時，Enclave進出開銷較高。
在上述過程中，由于Enclave内的資料被保護，資料庫本身并不知道查詢的某市到底對應哪個城市。但是因為每次Enclave的傳回結果（該條目的城市是否比對c_city = ‘0xaef5306c’）是外部可見的，這些結果洩露了加密資料之間的關系。這就意味着這種設計面臨着前述可搜尋加密方案中普遍存在的洩露濫用攻擊(LAA)的安全隐患。若敵手有先驗知識，是可能通過觀察查詢，推斷出某些密文資料及其相關明文資料間的關聯性或其他特定資訊的。
從應用角度來看，上述設計方案實作簡單，對諸如PostgreSQL支援插件擴充的資料庫來說，隻需要以插件形式擴充即可，不需要改動代碼。移植到其他的資料庫，也隻需要非常少的修改。從性能角度看，由于Enclave内部隻是加密資料表達式的計算，基本不存在記憶體交換，是以頁交換開銷非常低。但是資料需要加解密的次數以及進出Enclave的次數均與待處理的資料量關聯，在資料量較大時加解密開銷和Enclave進出開銷較高。在安全層面，此類設計無法像基于Enclave的安全資料庫管理系統那樣保證資料完整性。更重要的是，在查詢的過程中洩露了很多加密資料關系資訊。是以，其安防力度比一般使用Enclave的應用場景要弱，不能普适性地滿足資料保護，尤其是高敏感資料的安全需求。
近期，我們課題組也對基于可信硬體的加密資料庫系統進行了前沿探索。聚焦在範圍查詢，我們提出了一種混合索引結構的設計——HybrIDX[18]，可實作加密的範圍查詢，并抵禦相關的各類洩露濫用攻擊的安全隐患。其核心思想是依靠可信硬體，将加密比較操作移至可信賴的Enclave安全區，以協助安全範圍查詢處理，并同時降低甚至混淆不必要的資訊洩露，在安全性和效率方面都有顯著提升。
結語
随着資料科學的迅猛發展，保護核心生産要素的安全需求給加密資料庫的建構帶來了前所未有的挑戰。雖然近年來可搜尋加密理論飛速發展，可信硬體技術慢慢崛起，讓我們看到了加密資料庫領域逐漸邁向成熟商業化的可能性，但将加密資料庫真正落地并得到廣泛應用，仍需要學界和業界的共同努力與長期探索。圍繞核心安全技術攻關、系統架構标準制定以及資料庫系統安全測評等方面，加密資料庫的發展仍面臨許多關鍵挑戰：
- 盡管Enclave在一定程度上為資料的使用提供了安全環境，但是Enclave和外部互動仍然會給加密資料庫帶來安全隐患，甚至造成潛在的資料資訊洩露威脅[19]。此外，如何劃分資料庫子產品，更好地權衡安全性、性能和工程難度，也是打造基于可信硬體加密資料庫系統的一個重要難點。面對這些制約安全和性能的瓶頸，怎樣進行針對性技術攻關、優化更新和改造，是掃清加密資料庫推廣道路上障礙的關鍵。
- 已有資料庫系統種類繁多，如何推進加密資料庫技術的廣泛部署，實作相關産品架構及其生态應用的安全更新，需要各界企事業機關以及科研院校的協同參與，開展相關标準的制定工作。不論是雲資料庫服務還是本地部署，都需要建立一整套成熟的架構及部署标準，進而更廣泛地推進加密資料庫技術落地，促進相關産業生态的發展。這也是目前需要關注與思考的重要課題。
- 為了提升資料安全監管能力，保證資料産業的健康發展，我們還應該意識到确立一套完備的資料庫安全評估體系的重要性。該評估體系應符合我國相關法律對密碼産品定級以及自主可控的要求，能夠有助于我們定性、定量地評估各個系統子產品及相關狀态下資料庫的安全等級（例如查詢量、洩露函數、可信硬體安全保護力度等），起到安全評估乃至實時防護警示的作用。
這些問題是推動加密資料庫發展的挑戰，同時也是未來研究的契機。展望未來，我們堅信經過領域同行的共同努力，加密資料庫必定能夠有所突破并應用到生産生活的方方面面，助力實作穩定、高效的網絡空間安全以及良好生态的願景。
（參考文獻略）
任 奎
CCF進階會員。浙江大學求是講席教授， 網絡空間安全研究中心主任。主要研究方向為物聯網安全、資料安全和隐私保護、人工智能安全。 [email protected]
王 聰
CCF專業會員。香港城市大學教授。主要研究方向為資料安全、隐私保護、機密計算及其安全應用。 [email protected]