一種基于國(guó)密算法的實(shí)時(shí)文檔協(xié)同機(jī)制

青亮，吳海波

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 縮略語(yǔ)描述

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

表1 縮略語(yǔ)描述

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ù)通過(guò)調(diào)用密碼分發(fā)服務(wù)，完成密鑰的分發(fā)，同時(shí)，將客戶端加密的文檔進(jìn)行協(xié)同操作轉(zhuǎn)換并密文存儲(chǔ)，再轉(zhuǎn)發(fā)密文給其他客戶端。

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

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

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

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

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

2.3 密碼密鑰配置

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

表2 密碼算法配用

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

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

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

（4）SM4分組算法在本系統(tǒng)中主要用于對(duì)實(shí)時(shí)文檔數(shù)據(jù)源進(jìn)行加密保護(hù)，采用CBC工作模式，每個(gè)消息或文件的正文對(duì)應(yīng)一個(gè)正文加密密鑰和加密填充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é)同文檔請(qǐng)求至協(xié)同服務(wù)端后，協(xié)同服務(wù)通過(guò)密鑰分發(fā)服務(wù)請(qǐng)求生成對(duì)應(yīng)密鑰，協(xié)同服務(wù)再將各客戶端的協(xié)同群組密鑰CGK用各端的加密公鑰CPUK加密后分發(fā)至各客戶端。加密模塊與密鑰分發(fā)服務(wù)之間的安全通道建立可以基于TLS的雙證書校驗(yàn)機(jī)制來(lái)實(shí)現(xiàn)。密鑰分發(fā)服務(wù)通過(guò)訪問(wèn)控制機(jī)制ACL來(lái)實(shí)現(xiàn)加密模塊請(qǐng)求密鑰的權(quán)限控制。

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

2.5 報(bào)文協(xié)議

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

圖8 文件塊報(bào)文主要組成

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

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

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

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

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

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

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

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

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

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

3 評(píng)估與分析

3.1 安全性評(píng)估

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

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

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

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

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

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

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

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

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

表4 方案對(duì)文件大小新增開銷

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

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

4 結(jié)論

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