來源 | 中國計算機學會
本文將從數據安全防護的重大戰略需求出發，聚焦數據安全搜索、加密數據庫技術等前沿領域，深入探討加密數據庫的發展現狀，揭示其設計過程中存在的安全性和性能方面的挑戰，並提出未來關於加密數據庫建設的一些願景。
加密數據庫體系及核心需求
數據是驅動數字經濟發展最核心動力，此觀念已然成為行業共識。以數據為基礎的大數據、雲計算、物聯網、區塊鏈、人工智能等數據科學在智慧城市升級、國家重大基建產業發展等方面發揮著重要的作用。考慮到數據作為核心生產要素的重要地位，保護數據的安全和隱私不容忽視。它關乎國家安全，尤其數據科學與工業生產的相互融合使得數據安全的影響蔓延到軍事、金融、醫療、教育等各個領域。在此背景下，學界和工業界都已經開始大力推動大數據安全戰略佈局，各國政府也都相繼出臺各項法律法規以規範保障數據的安全使用和生產，如我國的《網絡安全法》、《密碼法》等。
然而，近年來頻頻暴發的數據洩露事件表明，數據安全保護的現狀仍不容樂觀。據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]