一种基于国密算法的实时文档协同机制

青亮，吴海波

（成都卫士通信息产业股份有限公司，四川 成都 610096）

0 引言

随着智能终端设备的性能提升和5G赋能万物互联，更加高效便捷智能的数字化协作逐渐成为新的工作方式。基于云端共享的多端实时在线文档协同作为最常见的团队协作方式，可以有效提高工作效率，尤其是具备高交互需求的实时协同办公应用系统。在抗击新冠疫情期间，实时文档协同对于远程数据统计、文档编写、复工复会等多方面具有重大意义。现有的实时文档编辑及协同系统通常基于文档明文进行操作转换和冲突解决，或者对传输通道采用https进行加密保护，并且必须假设文档服务器是安全可信的，用户需要完全信赖文档服务器。这种模式使得文档的泄漏风险向云端服务器集中，服务器拥有对正在协作的所有文档的完全访问权限，一旦进行操作转换或存储的云端服务器被恶意利用，海量的文档明文信息将在瞬间被集中窃取。然而，作为远程办公的典型应用代表，实时文档协同必然涉及一些商业秘密及企业、个人隐私等敏感信息，一旦文档数据泄露，将给企业或个人带来重大损失。

针对用户敏感数据的实时协同编辑，需要解决文档编辑处理过程中的内容泄漏问题。本文从典型实时文档协同应用中抽取密码需求，结合商用密码算法进行研究，设计实时文档协同加密方案，确保文档协同数据安全。

1 实时文档协同技术原理

1.1 实时文档协同技术概述

实时文档协同，是指由多人共同协作完成文档的编写，该机制也可引申到代码的开发、涂鸦的创造等场景。传统模式下的文档协同过程存在低效和冲突解决不便的问题，参与的多方无法及时获取他人对文档的编辑内容，造成文档版本更新混乱、无法适应完成多人协同编辑的场景。实现实时协同交互的核心问题是如何支持异构环境下不同交互操作的冲突解决和最终一致性问题。自谷歌推出商用在线协同文档已有十余年，包括腾讯文档在内的各类协同文档应用发展迅速，与之相关的一致性算法及其衍生技术一直是研究的热点。操作转换及冲突解决机制已在移动云环境下进行了研究和应用[1]，此外，基于操作转换机制对数字协同系统进行设计和实现[2-3]。

一般来说目前主要有两类实现机制，一种称之为操作转换（Operation Transformation，OT），另一种称之为可扩展性无冲突复制数据类型（Conflict-free Replicated Data Type，CRDT）。Google Docs、Microsoft 365以及开源的Etherpad均使用OT作为基本技术来解决多用户编辑冲突的问题。而CRDT于2011年从学术研究中脱颖而出，可为用户提供对其数据的完全所有权。作为近几年兴起的一种分布式一致性算法，配合WebSocket等机制，可应用于分布式应用程序中，如分布式文档协同、分布式存储等。通过引入版本管理和操作转换技术，解决了协同编辑的版本管理及冲突解决问题，使得在线实时协同编辑存在可能。

由于CRDT在处理复杂数据结构时，可能存在性能问题，主要应用于一些原型系统中，大多数产品级的实时协同编辑都基于OT技术及其改进机制来实现，本文也主要基于OT机制的文档协同进行研究及密码安全性设计。

1.2 实时文档协同技术原理

在线实时协同编辑过程中，服务器的处理机制必须具备容忍不同的用户操作乱序到达甚至丢失的情形，必须保证所有用户最终处于一致状态。服务器主要的处理工作如下：

（1）服务器负责监听和收集来自客户端的数据变化，并利用操作转换技术解决操作合并和冲突等问题；

（2）根据每个客户端的修改操作，服务器及时修改存储的文档以获得最新的版本；

（3）将转换后的修改操作广播给其他参与在线协同的客户端，以便其他客户端可以更新其本地副本。

对实时协同编辑最简单的理解类似于即时通信系统的群组聊天，每个用户在本地进行文档的修改，并将文档的修改操作群发给群组内其他打开这篇文档的用户。文档编辑器可以看作为一个操作空间，在其中插入或删除文本字符或富文本等信息，然后将结果保存到文件中。每次操作都将由“索引”和“值”构成，二者共同确定所进行的操作在文档中的位置和内容。例如，对于文本“TEST”，第一个字符的值为“T”，位置为0，以此类推。只需引用位置索引，就可以插入或删除字符。其基本原理如图1所示：

图1 协同编辑基本原理及流程

然而在实际应用场景中，用户所处的终端环境及网络性能存在较大差异，断开连接、网络延时等不可避免，来自不同用户的操作有可能在各端有不同的执行顺序。相同的操作，不同的执行顺序，将会产生不同的结果，如图2所示。

图2 协同编辑乱序流程示意图

数据一致性是实时文档协同的最基本要求，如果通过强制操作按照到达服务器的时间来排序，将破坏用户编辑当时的上下文，产生不符合用户预期的编辑效果。于是，操作变换算法便被引入。通过操作转换，可以解决最终数据一致性的问题，如图3所示：

图3 协同编辑引入操作转换示意图

1.3 实时文档协同加密需求

现有的在实时文档协同通常只能基于文档的明文进行操作和冲突解决，基于OT机制的操作转换需要依赖服务器完成。因而，服务器拥有对正在协作的所有文档的完全访问权限，包括文档内容、编辑步骤等。在此模型中，文档服务提供商提供存储服务，并能及时正确地处理、分发用户的数据操作，但它可能主动或被动地读取用户的文档数据，甚至可能将这些数据转发给第三方。一些应用采用基于HTTPS等方式来保证传输过程中的数据安全，但客户端编辑的数据在到达服务器后，其处理、存储等都基于明文操作，存在泄漏风险。一些研究对不同场景架构下文档数据的安全进行了分析，但其安全对策不适应实时协同编辑的应用场景[4]。部分研究则对大数据时代下数据安全防护措施与治理进行相应的探讨[5-6]。因此，需要一种机制来实现文档的“端到端”加密，能够实现在不完全可信云环境下提供用户敏感数据保护的实时协同编辑服务。即使使用不受信任的存储服务，也不会有文档泄漏的风险。方案应满足以下需求：

（1）机密性：需要对用户敏感的文档数据进行加密保护，确保数据内容不被服务器及非授权用户获取。

（2）实时性：安全方案不影响客户端的编辑内容能够实时地同步给其他客户端。

（3）一致性：当存在因网络延时而导致的客户端文档内容不一致时，在下一时刻网络恢复正常时能够及时同步并正确解密各个客户端之间的编辑数据，保证各个客户端之间内容的一致性。

（4）灵活性：需满足不同文档在不同协同阶段的加密需求，针对特定的用户只允许查看特定时期、特定版本的文档数据，对于加入协作的新用户可控制其对文档历史过程的解密权限。

（5）高效性：安全的增强不能带来额外的繁重计算需求，尤其是针对移动终端，需考虑其处理性能及效率。

2 轻量级实时文档协同加密技术

2.1 缩略语描述

所涉及的缩略语及中英文描述如表1所示。

表1 缩略语描述

2.2 系统总体组成

系统总体组成如图4所示，服务端由密钥分发服务（包括密钥管理服务、密钥分发服务）、协同业务服务端（业务服务、协同处理服务）和密码模块组成，密钥分发服务提供密钥分发及管理功能，协同业务服务通过调用密码分发服务，完成密钥的分发，同时，将客户端加密的文档进行协同操作转换并密文存储，再转发密文给其他客户端。

图4 轻量级实时文档协同加密方案组成

服务端的OT处理机制与通用的文档协同服务端处理机制保持一致。为便于描述，考虑任意一条文档操作的信息传递路径如下：客户端进行文档编辑，并调用密码模块对文档进行加密，密文消息到达协同服务后端时，首先进行OT转换，再经过DB服务持久化，最终将操作转换的信息推送给相关的客户端，相关客户端拉取密文并调用密码模块进行解密操作，即可看到对方协同编辑的动作。其服务器模型如下如图5所示：

图5 文档协同服务器模型

客户端由应用终端和密码模块组成，主要完成文档本地的更新及维护，包括采集用户的编辑操作和编辑内容，加密本地操作负载、接收来自服务器的操作、解密接收到的操作负载并应用到本地，客户端模型如图6所示：

图6 文档协同客户端模型

2.3 密码密钥配置

方案使用的算法名称、用途及具体参数指标说明如表2所示：

表2 密码算法配用

（1）对称加密算法应用，采用SM4算法、CBC工作模式。主要实现文档数据的加密和解密功能，提供数据的机密性保护，其分组长度是128比特，密钥长度128比特。

（2）非对称算法应用，采用SM2算法，主要用于数字签名、验签、加密、解密以及密钥保护。私钥256比特，公钥512比特。

（3）杂凑算法应用，采用SM3算法，用于进行摘要计算，输出为固定长度256比特。

（4）SM4分组算法在本系统中主要用于对实时文档数据源进行加密保护，采用CBC工作模式，每个消息或文件的正文对应一个正文加密密钥和加密填充IV。分组填充方式采用PKCS#7标准填充方式填充。参照SM4算法标准规范《SM4分组密码算法》。

2.4 系统密钥分发及数据流程

系统的密钥分发相关的控制流及数据流如图7所示：

图7 系统控制及数据流

（1）密钥分发：客户端选择相应的协同成员，发起协同文档请求至协同服务端后，协同服务通过密钥分发服务请求生成对应密钥，协同服务再将各客户端的协同群组密钥CGK用各端的加密公钥CPUK加密后分发至各客户端。加密模块与密钥分发服务之间的安全通道建立可以基于TLS的双证书校验机制来实现。密钥分发服务通过访问控制机制ACL来实现加密模块请求密钥的权限控制。

（2）文档数据分发：协同客户端发起操作后，将文档加密后发到协同服务端，协同服务端进行OT操作后，根据协同成员，推送文档更新的消息到其他客户端，客户端收到推送后拉取文档密文，再通过本地密码模块对文档进行解密操作后进行OT转换，并同步到本地做进一步呈现。

2.5 报文协议

在不影响原有的OT机制及文件头的原则下，仅对文件块的载荷进行加密，报文关键字段定义如图8所示：

图8 文件块报文主要组成

其中：CGID表示协同群组的标识ID；CGKV表示协同群组密钥的版本；E(CGK,FBK)表示用协同群组密钥对文件块加密密钥进行加密保护。

2.6 主要业务流程

业务主要流程如图9所示，描述如下：

图9 加密实时文档协同主要流程

客户端在本地文档内容输入后，调用密码模块对文档进行加密，即得到密文文档：E(FBK,FB)||E(CGK,FBK)||H(FB)||CGID||CGKV。

客户端将密文文档传输至协同文档服务端。

服务端通过操作转换机制对加密的文档进行OT处理。

OT后的密文文档通过推送发送至其他客户端。

其他客户端调用密码模块解密接口对文档进行解密，首先利用CGK解密FBK密文，得到FBK，即：D(CGK,EFBK)，然后利用FBK解密密文文件得到明文FB，即：D(FBK,EFile)。

其他客户端对解密后的文档进行OT操作，并进行本地呈现。

3 评估与分析

3.1 安全性评估

首先，只有已获得授权的用户才可以访问文档的内容。本方案在客户端采用对称商用密码算法来加密数据，在编辑阶段，所有的操作负载在发送给服务器前都会被加密，因此服务器收到的操作负载都是密文形式的内容，并以密文的形式存储。

其次，本方案采用由我国自主设计的SM2/3/4商用密码算法，通过对文件等数据实现了基于“端到端”的加密，确保了用户业务数据的内容安全；通过采用SSL安全通道对通信双方的身份进行确认，对传输内容进行加密保护，确保了数据的传输安全。

再次，用于加密的对称密钥只在客户端生成，且是“一次一密”的加密方式，保证了每个文档使用的密钥的唯一性以及在不同阶段使用的密钥的唯一性。通过对数据进行HASH校验的方式，确保了数据的完整性；同时通过基于证书的身份认证技术和数据签名验签确保了数据的不可否认性。协同编辑者以及客户端无法主动泄露密钥，因此密钥不会被已授权的协同编辑者以及客户端外的对象获取。

最后，协同群组密钥对文档的加密密钥进行保护。在进行文档协同的过程中，如果参与协调的成员发生变化，例如成员A被移除协同小组，则协同群组密钥CGK将发生变更，且协同群组密钥版本号CGKV也会发生变更。被移除协同群组的成员A在尝试获取新的协同群组密钥时，将被密钥管理服务的ACL所拒绝，从而实现文档协同的权限控制机制。

3.2 系统性能影响

选取本方案应用于实时文档协同时的最长调用执行路径进行分析。所谓最长调用执行路径，即协同业务过程中，不考虑本地密钥缓存等优化机制，为系统业务流程最长、性能损耗最大的执行路径。由于文档协同的加解密均在各个客户端本地完成。因此，需要评估对密码安全机制所带来的性能开销对于业务的体验影响。

一般来说，在一个交互性强的协同编辑系统中，每隔500ms会有一个操作产生，其文本数据本身非常小，一般为几个字节到几十字节。此外，对于协同编辑中可能出现的插入图片及视频、附件等富文本情形，需评估这些典型业务的加解密性能。选取实时文档协同可能产生的典型数据类型及大小进行评估，根据密码模块的实际测试结果，在Android平台的性能表现如表3所示（注：由于测试设备配置不同，结果可能存在差异）。

从表3以看出，选取典型的文本、图片视频等数据，大小范围从几字节到100MB，其加解密性能都较高，常见大小的业务数据，其性能均为微秒级，因此，由于加解密性能导致的对业务本身的影响可以忽略。

此外，根据图8描述的文件块报文定义，新增的报文主要在于CGID、CGKV、E(CGK,FBK)及文件块Hash四个字段，其增加的开销如表4所示：

表4 方案对文件大小新增开销

这意味着，在原有的协调机制下，其文件开销将增加56字节，对于业务的性能及数据流量的影响几乎可以忽略。

综上，从业务对方案的依赖、加解密操作的性能以及方案增加的协议开销来看，所提出的方案对原有的实时文档协同的性能影响很小。

4 结论

针对用户敏感数据的实时协同编辑，需要解决文档处理过程中的内容泄漏问题。首先对实时文档协同的基本技术、现状及加密需求进行分析。然后，从典型实时文档协同应用中抽取加密需求，结合国家密码管理局发布的商用密码算法进行研究，设计实时文档协同加密方案，确保文档协同数据安全。最后对方案进行分析和评估。所采用的轻量的加密方式能够完全兼容未采用加密机制的实时协同编辑服务，所有的功能和编辑操作都没有受到影响或失效。提出的方案具备高安全、可扩展、灵活性等优点，具有较高的实用性。