青亮，吳海波

（成都衛(wèi)士通信息產(chǎn)業(yè)股份有限公司，四川 成都 610096）

0 引言

隨著智能終端設(shè)備的性能提升和5G賦能萬物互聯(lián)，更加高效便捷智能的數(shù)字化協(xié)作逐漸成為新的工作方式?；谠贫斯蚕淼亩喽藢崟r在線文檔協(xié)同作為最常見的團(tuán)隊協(xié)作方式，可以有效提高工作效率，尤其是具備高交互需求的實時協(xié)同辦公應(yīng)用系統(tǒng)。在抗擊新冠疫情期間，實時文檔協(xié)同對于遠(yuǎn)程數(shù)據(jù)統(tǒng)計、文檔編寫、復(fù)工復(fù)會等多方面具有重大意義?，F(xiàn)有的實時文檔編輯及協(xié)同系統(tǒng)通常基于文檔明文進(jìn)行操作轉(zhuǎn)換和沖突解決，或者對傳輸通道采用https進(jìn)行加密保護(hù)，并且必須假設(shè)文檔服務(wù)器是安全可信的，用戶需要完全信賴文檔服務(wù)器。這種模式使得文檔的泄漏風(fēng)險向云端服務(wù)器集中，服務(wù)器擁有對正在協(xié)作的所有文檔的完全訪問權(quán)限，一旦進(jìn)行操作轉(zhuǎn)換或存儲的云端服務(wù)器被惡意利用，海量的文檔明文信息將在瞬間被集中竊取。然而，作為遠(yuǎn)程辦公的典型應(yīng)用代表，實時文檔協(xié)同必然涉及一些商業(yè)秘密及企業(yè)、個人隱私等敏感信息，一旦文檔數(shù)據(jù)泄露，將給企業(yè)或個人帶來重大損失。

針對用戶敏感數(shù)據(jù)的實時協(xié)同編輯，需要解決文檔編輯處理過程中的內(nèi)容泄漏問題。本文從典型實時文檔協(xié)同應(yīng)用中抽取密碼需求，結(jié)合商用密碼算法進(jìn)行研究，設(shè)計實時文檔協(xié)同加密方案，確保文檔協(xié)同數(shù)據(jù)安全。

1 實時文檔協(xié)同技術(shù)原理

1.1 實時文檔協(xié)同技術(shù)概述

實時文檔協(xié)同，是指由多人共同協(xié)作完成文檔的編寫，該機(jī)制也可引申到代碼的開發(fā)、涂鴉的創(chuàng)造等場景。傳統(tǒng)模式下的文檔協(xié)同過程存在低效和沖突解決不便的問題，參與的多方無法及時獲取他人對文檔的編輯內(nèi)容，造成文檔版本更新混亂、無法適應(yīng)完成多人協(xié)同編輯的場景。實現(xiàn)實時協(xié)同交互的核心問題是如何支持異構(gòu)環(huán)境下不同交互操作的沖突解決和最終一致性問題。自谷歌推出商用在線協(xié)同文檔已有十余年，包括騰訊文檔在內(nèi)的各類協(xié)同文檔應(yīng)用發(fā)展迅速，與之相關(guān)的一致性算法及其衍生技術(shù)一直是研究的熱點(diǎn)。操作轉(zhuǎn)換及沖突解決機(jī)制已在移動云環(huán)境下進(jìn)行了研究和應(yīng)用[1]，此外，基于操作轉(zhuǎn)換機(jī)制對數(shù)字協(xié)同系統(tǒng)進(jìn)行設(shè)計和實現(xiàn)[2-3]。

一般來說目前主要有兩類實現(xiàn)機(jī)制，一種稱之為操作轉(zhuǎn)換（Operation Transformation，OT），另一種稱之為可擴(kuò)展性無沖突復(fù)制數(shù)據(jù)類型（Conflict-free Replicated Data Type，CRDT）。Google Docs、Microsoft 365以及開源的Etherpad均使用OT作為基本技術(shù)來解決多用戶編輯沖突的問題。而CRDT于2011年從學(xué)術(shù)研究中脫穎而出，可為用戶提供對其數(shù)據(jù)的完全所有權(quán)。作為近幾年興起的一種分布式一致性算法，配合WebSocket等機(jī)制，可應(yīng)用于分布式應(yīng)用程序中，如分布式文檔協(xié)同、分布式存儲等。通過引入版本管理和操作轉(zhuǎn)換技術(shù)，解決了協(xié)同編輯的版本管理及沖突解決問題，使得在線實時協(xié)同編輯存在可能。

由于CRDT在處理復(fù)雜數(shù)據(jù)結(jié)構(gòu)時，可能存在性能問題，主要應(yīng)用于一些原型系統(tǒng)中，大多數(shù)產(chǎn)品級的實時協(xié)同編輯都基于OT技術(shù)及其改進(jìn)機(jī)制來實現(xiàn)，本文也主要基于OT機(jī)制的文檔協(xié)同進(jìn)行研究及密碼安全性設(shè)計。

1.2 實時文檔協(xié)同技術(shù)原理

在線實時協(xié)同編輯過程中，服務(wù)器的處理機(jī)制必須具備容忍不同的用戶操作亂序到達(dá)甚至丟失的情形，必須保證所有用戶最終處于一致狀態(tài)。服務(wù)器主要的處理工作如下：

（1）服務(wù)器負(fù)責(zé)監(jiān)聽和收集來自客戶端的數(shù)據(jù)變化，并利用操作轉(zhuǎn)換技術(shù)解決操作合并和沖突等問題；

（2）根據(jù)每個客戶端的修改操作，服務(wù)器及時修改存儲的文檔以獲得最新的版本；

（3）將轉(zhuǎn)換后的修改操作廣播給其他參與在線協(xié)同的客戶端，以便其他客戶端可以更新其本地副本。

對實時協(xié)同編輯最簡單的理解類似于即時通信系統(tǒng)的群組聊天，每個用戶在本地進(jìn)行文檔的修改，并將文檔的修改操作群發(fā)給群組內(nèi)其他打開這篇文檔的用戶。文檔編輯器可以看作為一個操作空間，在其中插入或刪除文本字符或富文本等信息，然后將結(jié)果保存到文件中。每次操作都將由“索引”和“值”構(gòu)成，二者共同確定所進(jìn)行的操作在文檔中的位置和內(nèi)容。例如，對于文本“TEST”，第一個字符的值為“T”，位置為0，以此類推。只需引用位置索引，就可以插入或刪除字符。其基本原理如圖1所示：

圖1 協(xié)同編輯基本原理及流程

然而在實際應(yīng)用場景中，用戶所處的終端環(huán)境及網(wǎng)絡(luò)性能存在較大差異，斷開連接、網(wǎng)絡(luò)延時等不可避免，來自不同用戶的操作有可能在各端有不同的執(zhí)行順序。相同的操作，不同的執(zhí)行順序，將會產(chǎn)生不同的結(jié)果，如圖2所示。

圖2 協(xié)同編輯亂序流程示意圖

數(shù)據(jù)一致性是實時文檔協(xié)同的最基本要求，如果通過強(qiáng)制操作按照到達(dá)服務(wù)器的時間來排序，將破壞用戶編輯當(dāng)時的上下文，產(chǎn)生不符合用戶預(yù)期的編輯效果。于是，操作變換算法便被引入。通過操作轉(zhuǎn)換，可以解決最終數(shù)據(jù)一致性的問題，如圖3所示：

圖3 協(xié)同編輯引入操作轉(zhuǎn)換示意圖

1.3 實時文檔協(xié)同加密需求

現(xiàn)有的在實時文檔協(xié)同通常只能基于文檔的明文進(jìn)行操作和沖突解決，基于OT機(jī)制的操作轉(zhuǎn)換需要依賴服務(wù)器完成。因而，服務(wù)器擁有對正在協(xié)作的所有文檔的完全訪問權(quán)限，包括文檔內(nèi)容、編輯步驟等。在此模型中，文檔服務(wù)提供商提供存儲服務(wù)，并能及時正確地處理、分發(fā)用戶的數(shù)據(jù)操作，但它可能主動或被動地讀取用戶的文檔數(shù)據(jù)，甚至可能將這些數(shù)據(jù)轉(zhuǎn)發(fā)給第三方。一些應(yīng)用采用基于HTTPS等方式來保證傳輸過程中的數(shù)據(jù)安全，但客戶端編輯的數(shù)據(jù)在到達(dá)服務(wù)器后，其處理、存儲等都基于明文操作，存在泄漏風(fēng)險。一些研究對不同場景架構(gòu)下文檔數(shù)據(jù)的安全進(jìn)行了分析，但其安全對策不適應(yīng)實時協(xié)同編輯的應(yīng)用場景[4]。部分研究則對大數(shù)據(jù)時代下數(shù)據(jù)安全防護(hù)措施與治理進(jìn)行相應(yīng)的探討[5-6]。因此，需要一種機(jī)制來實現(xiàn)文檔的“端到端”加密，能夠?qū)崿F(xiàn)在不完全可信云環(huán)境下提供用戶敏感數(shù)據(jù)保護(hù)的實時協(xié)同編輯服務(wù)。即使使用不受信任的存儲服務(wù)，也不會有文檔泄漏的風(fēng)險。方案應(yīng)滿足以下需求：

（1）機(jī)密性：需要對用戶敏感的文檔數(shù)據(jù)進(jìn)行加密保護(hù)，確保數(shù)據(jù)內(nèi)容不被服務(wù)器及非授權(quán)用戶獲取。

（2）實時性：安全方案不影響客戶端的編輯內(nèi)容能夠?qū)崟r地同步給其他客戶端。

（3）一致性：當(dāng)存在因網(wǎng)絡(luò)延時而導(dǎo)致的客戶端文檔內(nèi)容不一致時，在下一時刻網(wǎng)絡(luò)恢復(fù)正常時能夠及時同步并正確解密各個客戶端之間的編輯數(shù)據(jù)，保證各個客戶端之間內(nèi)容的一致性。

（4）靈活性：需滿足不同文檔在不同協(xié)同階段的加密需求，針對特定的用戶只允許查看特定時期、特定版本的文檔數(shù)據(jù)，對于加入?yún)f(xié)作的新用戶可控制其對文檔歷史過程的解密權(quán)限。

（5）高效性：安全的增強(qiáng)不能帶來額外的繁重計算需求，尤其是針對移動終端，需考慮其處理性能及效率。

2 輕量級實時文檔協(xié)同加密技術(shù)

2.1 縮略語描述

所涉及的縮略語及中英文描述如表1所示。

表1 縮略語描述

2.2 系統(tǒng)總體組成

系統(tǒng)總體組成如圖4所示，服務(wù)端由密鑰分發(fā)服務(wù)（包括密鑰管理服務(wù)、密鑰分發(fā)服務(wù)）、協(xié)同業(yè)務(wù)服務(wù)端（業(yè)務(wù)服務(wù)、協(xié)同處理服務(wù)）和密碼模塊組成，密鑰分發(fā)服務(wù)提供密鑰分發(fā)及管理功能，協(xié)同業(yè)務(wù)服務(wù)通過調(diào)用密碼分發(fā)服務(wù)，完成密鑰的分發(fā)，同時，將客戶端加密的文檔進(jìn)行協(xié)同操作轉(zhuǎn)換并密文存儲，再轉(zhuǎn)發(fā)密文給其他客戶端。

圖4 輕量級實時文檔協(xié)同加密方案組成

服務(wù)端的OT處理機(jī)制與通用的文檔協(xié)同服務(wù)端處理機(jī)制保持一致。為便于描述，考慮任意一條文檔操作的信息傳遞路徑如下：客戶端進(jìn)行文檔編輯，并調(diào)用密碼模塊對文檔進(jìn)行加密，密文消息到達(dá)協(xié)同服務(wù)后端時，首先進(jìn)行OT轉(zhuǎn)換，再經(jīng)過DB服務(wù)持久化，最終將操作轉(zhuǎn)換的信息推送給相關(guān)的客戶端，相關(guān)客戶端拉取密文并調(diào)用密碼模塊進(jìn)行解密操作，即可看到對方協(xié)同編輯的動作。其服務(wù)器模型如下如圖5所示：

圖5 文檔協(xié)同服務(wù)器模型

客戶端由應(yīng)用終端和密碼模塊組成，主要完成文檔本地的更新及維護(hù)，包括采集用戶的編輯操作和編輯內(nèi)容，加密本地操作負(fù)載、接收來自服務(wù)器的操作、解密接收到的操作負(fù)載并應(yīng)用到本地，客戶端模型如圖6所示：

圖6 文檔協(xié)同客戶端模型

2.3 密碼密鑰配置

方案使用的算法名稱、用途及具體參數(shù)指標(biāo)說明如表2所示：

表2 密碼算法配用

（1）對稱加密算法應(yīng)用，采用SM4算法、CBC工作模式。主要實現(xiàn)文檔數(shù)據(jù)的加密和解密功能，提供數(shù)據(jù)的機(jī)密性保護(hù)，其分組長度是128比特，密鑰長度128比特。

（2）非對稱算法應(yīng)用，采用SM2算法，主要用于數(shù)字簽名、驗簽、加密、解密以及密鑰保護(hù)。私鑰256比特，公鑰512比特。

（3）雜湊算法應(yīng)用，采用SM3算法，用于進(jìn)行摘要計算，輸出為固定長度256比特。

（4）SM4分組算法在本系統(tǒng)中主要用于對實時文檔數(shù)據(jù)源進(jìn)行加密保護(hù)，采用CBC工作模式，每個消息或文件的正文對應(yīng)一個正文加密密鑰和加密填充IV。分組填充方式采用PKCS#7標(biāo)準(zhǔn)填充方式填充。參照SM4算法標(biāo)準(zhǔn)規(guī)范《SM4分組密碼算法》。

2.4 系統(tǒng)密鑰分發(fā)及數(shù)據(jù)流程

系統(tǒng)的密鑰分發(fā)相關(guān)的控制流及數(shù)據(jù)流如圖7所示：

圖7 系統(tǒng)控制及數(shù)據(jù)流

（1）密鑰分發(fā)：客戶端選擇相應(yīng)的協(xié)同成員，發(fā)起協(xié)同文檔請求至協(xié)同服務(wù)端后，協(xié)同服務(wù)通過密鑰分發(fā)服務(wù)請求生成對應(yīng)密鑰，協(xié)同服務(wù)再將各客戶端的協(xié)同群組密鑰CGK用各端的加密公鑰CPUK加密后分發(fā)至各客戶端。加密模塊與密鑰分發(fā)服務(wù)之間的安全通道建立可以基于TLS的雙證書校驗機(jī)制來實現(xiàn)。密鑰分發(fā)服務(wù)通過訪問控制機(jī)制ACL來實現(xiàn)加密模塊請求密鑰的權(quán)限控制。

（2）文檔數(shù)據(jù)分發(fā)：協(xié)同客戶端發(fā)起操作后，將文檔加密后發(fā)到協(xié)同服務(wù)端，協(xié)同服務(wù)端進(jìn)行OT操作后，根據(jù)協(xié)同成員，推送文檔更新的消息到其他客戶端，客戶端收到推送后拉取文檔密文，再通過本地密碼模塊對文檔進(jìn)行解密操作后進(jìn)行OT轉(zhuǎn)換，并同步到本地做進(jìn)一步呈現(xiàn)。

2.5 報文協(xié)議

在不影響原有的OT機(jī)制及文件頭的原則下，僅對文件塊的載荷進(jìn)行加密，報文關(guān)鍵字段定義如圖8所示：

圖8 文件塊報文主要組成

其中：CGID表示協(xié)同群組的標(biāo)識ID；CGKV表示協(xié)同群組密鑰的版本；E(CGK,FBK)表示用協(xié)同群組密鑰對文件塊加密密鑰進(jìn)行加密保護(hù)。

2.6 主要業(yè)務(wù)流程

業(yè)務(wù)主要流程如圖9所示，描述如下：

圖9 加密實時文檔協(xié)同主要流程

客戶端在本地文檔內(nèi)容輸入后，調(diào)用密碼模塊對文檔進(jìn)行加密，即得到密文文檔：E(FBK,FB)||E(CGK,FBK)||H(FB)||CGID||CGKV。

客戶端將密文文檔傳輸至協(xié)同文檔服務(wù)端。

服務(wù)端通過操作轉(zhuǎn)換機(jī)制對加密的文檔進(jìn)行OT處理。

OT后的密文文檔通過推送發(fā)送至其他客戶端。

其他客戶端調(diào)用密碼模塊解密接口對文檔進(jìn)行解密，首先利用CGK解密FBK密文，得到FBK，即：D(CGK,EFBK)，然后利用FBK解密密文文件得到明文FB，即：D(FBK,EFile)。

其他客戶端對解密后的文檔進(jìn)行OT操作，并進(jìn)行本地呈現(xiàn)。

3 評估與分析

3.1 安全性評估

首先，只有已獲得授權(quán)的用戶才可以訪問文檔的內(nèi)容。本方案在客戶端采用對稱商用密碼算法來加密數(shù)據(jù)，在編輯階段，所有的操作負(fù)載在發(fā)送給服務(wù)器前都會被加密，因此服務(wù)器收到的操作負(fù)載都是密文形式的內(nèi)容，并以密文的形式存儲。

其次，本方案采用由我國自主設(shè)計的SM2/3/4商用密碼算法，通過對文件等數(shù)據(jù)實現(xiàn)了基于“端到端”的加密，確保了用戶業(yè)務(wù)數(shù)據(jù)的內(nèi)容安全；通過采用SSL安全通道對通信雙方的身份進(jìn)行確認(rèn)，對傳輸內(nèi)容進(jìn)行加密保護(hù)，確保了數(shù)據(jù)的傳輸安全。

再次，用于加密的對稱密鑰只在客戶端生成，且是“一次一密”的加密方式，保證了每個文檔使用的密鑰的唯一性以及在不同階段使用的密鑰的唯一性。通過對數(shù)據(jù)進(jìn)行HASH校驗的方式，確保了數(shù)據(jù)的完整性；同時通過基于證書的身份認(rèn)證技術(shù)和數(shù)據(jù)簽名驗簽確保了數(shù)據(jù)的不可否認(rèn)性。協(xié)同編輯者以及客戶端無法主動泄露密鑰，因此密鑰不會被已授權(quán)的協(xié)同編輯者以及客戶端外的對象獲取。

最后，協(xié)同群組密鑰對文檔的加密密鑰進(jìn)行保護(hù)。在進(jìn)行文檔協(xié)同的過程中，如果參與協(xié)調(diào)的成員發(fā)生變化，例如成員A被移除協(xié)同小組，則協(xié)同群組密鑰CGK將發(fā)生變更，且協(xié)同群組密鑰版本號CGKV也會發(fā)生變更。被移除協(xié)同群組的成員A在嘗試獲取新的協(xié)同群組密鑰時，將被密鑰管理服務(wù)的ACL所拒絕，從而實現(xiàn)文檔協(xié)同的權(quán)限控制機(jī)制。

3.2 系統(tǒng)性能影響

選取本方案應(yīng)用于實時文檔協(xié)同時的最長調(diào)用執(zhí)行路徑進(jìn)行分析。所謂最長調(diào)用執(zhí)行路徑，即協(xié)同業(yè)務(wù)過程中，不考慮本地密鑰緩存等優(yōu)化機(jī)制，為系統(tǒng)業(yè)務(wù)流程最長、性能損耗最大的執(zhí)行路徑。由于文檔協(xié)同的加解密均在各個客戶端本地完成。因此，需要評估對密碼安全機(jī)制所帶來的性能開銷對于業(yè)務(wù)的體驗影響。

一般來說，在一個交互性強(qiáng)的協(xié)同編輯系統(tǒng)中，每隔500ms會有一個操作產(chǎn)生，其文本數(shù)據(jù)本身非常小，一般為幾個字節(jié)到幾十字節(jié)。此外，對于協(xié)同編輯中可能出現(xiàn)的插入圖片及視頻、附件等富文本情形，需評估這些典型業(yè)務(wù)的加解密性能。選取實時文檔協(xié)同可能產(chǎn)生的典型數(shù)據(jù)類型及大小進(jìn)行評估，根據(jù)密碼模塊的實際測試結(jié)果，在Android平臺的性能表現(xiàn)如表3所示（注：由于測試設(shè)備配置不同，結(jié)果可能存在差異）。

從表3以看出，選取典型的文本、圖片視頻等數(shù)據(jù)，大小范圍從幾字節(jié)到100MB，其加解密性能都較高，常見大小的業(yè)務(wù)數(shù)據(jù)，其性能均為微秒級，因此，由于加解密性能導(dǎo)致的對業(yè)務(wù)本身的影響可以忽略。

此外，根據(jù)圖8描述的文件塊報文定義，新增的報文主要在于CGID、CGKV、E(CGK,FBK)及文件塊Hash四個字段，其增加的開銷如表4所示：

表4 方案對文件大小新增開銷

這意味著，在原有的協(xié)調(diào)機(jī)制下，其文件開銷將增加56字節(jié)，對于業(yè)務(wù)的性能及數(shù)據(jù)流量的影響幾乎可以忽略。

綜上，從業(yè)務(wù)對方案的依賴、加解密操作的性能以及方案增加的協(xié)議開銷來看，所提出的方案對原有的實時文檔協(xié)同的性能影響很小。

4 結(jié)論

針對用戶敏感數(shù)據(jù)的實時協(xié)同編輯，需要解決文檔處理過程中的內(nèi)容泄漏問題。首先對實時文檔協(xié)同的基本技術(shù)、現(xiàn)狀及加密需求進(jìn)行分析。然后，從典型實時文檔協(xié)同應(yīng)用中抽取加密需求，結(jié)合國家密碼管理局發(fā)布的商用密碼算法進(jìn)行研究，設(shè)計實時文檔協(xié)同加密方案，確保文檔協(xié)同數(shù)據(jù)安全。最后對方案進(jìn)行分析和評估。所采用的輕量的加密方式能夠完全兼容未采用加密機(jī)制的實時協(xié)同編輯服務(wù)，所有的功能和編輯操作都沒有受到影響或失效。提出的方案具備高安全、可擴(kuò)展、靈活性等優(yōu)點(diǎn)，具有較高的實用性。