【袁永福专栏】从可用到可信：“编辑器+CA签名”的纵深应用

来源：HIT专家网    作者：南京都昌信息科技有限公司 袁永福

随着HIT行业水平的不断提升，很多医院信息系统正在实现可信时间戳和基于硬件的CA签名，将应用系统从可用（可以使用）升级到可信（可以信任）。以此来顺应无纸化办公的趋势和高水平的信息安全等级保护评审，进一步解放医疗行业的生产力。

而我们南京都昌公司作为整个HIT体系的软件基础设施建设者，为这种发展趋势提供了底层技术支撑，推出了“编辑器+CA电子签名”技术方案。在DCWriter电子病历编辑器控件的底层添加对CA签名的支持，实现了一些强大的新功能，解决了一些技术难题，开辟了一些全新的应用场景，开拓了CA签名在HIT体系中的纵深应用。实现了病历数据从可用到可信的进化。

医院信息系统安全等级保护

说到“可信”，首先不得不提起现行的推荐性的国家标准《信息系统安全等级保护基本要求 GB/T 22239—2008》，在此原文摘录以下几条：

5.1.4.3 通信完整性（S1） 应采用约定通信会话方式的方法保证通信过程中数据的完整性。

5.1.5.1 数据完整性（S1） 应能够检测到重要用户数据在传输过程中完整性受到破坏。

6.1.5.1 数据完整性（S2） 应能够检测到鉴别信息和重要业务数据在传输过程中完整性受到破坏。

6.1.5.2 数据保密性（S2） 应采用加密或其他保护措施实现鉴别信息的存储保密性。

7.1.3.5 入侵防范（G3） 本项要求包括： c) 操作系统应遵循最小安装的原则，仅安装需要的组件和应用程序。

7.1.4.1 身份鉴别（S3） 本项要求包括： a) 应提供专用的登录控制模块对登录用户进行身份标识和鉴别；

7.1.4.7 抗抵赖（G3） 本项要求包括： a) 应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能；

                                                          b) 应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。

7.1.5.1 数据完整性（S3） 本项要求包括：

• a) 应能够检测到系统管理数据、鉴别信息和重要业务数据在传输过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施；
• b) 应能够检测到系统管理数据、鉴别信息和重要业务数据在存储过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施。

8.1.4.7 通信完整性（S4） 应采用密码技术保证通信过程中数据的完整性。

8.1.4.9 抗抵赖（G4） 本项要求包括：

• a) 应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能；
• b) 应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。

这些条款主要关注数据的完整性、数据的保密性、入侵防范、抗抵赖。

另外，原卫生部发布的《电子病历系统功能应用水平分级评价方法及标准》中的“电子病历系统应用水平分级评价项目”有以下条款：

先进的医院要通过高水平的信息安全等级保护评审，需要扎实地实现上述条款，做到信息安全方面无遗漏、无死角。而我们的“编辑器+CA签名”技术方案就是针对这些条款来帮助医院。

应用场景1：CDR（临床数据中心）

如下图所示，这是目前很多医院CDR的系统结构图：

在这个结构中，医院CDR有三个下属系统，下属系统各自安装了不同种类的CA签名功能，而且文档和CA验证数据是分离存储的。

下属系统上传到CDR中的文档是没有CA签名的，因此CDR成为一个系统安全漏洞，无法实现等保标准的5.1.5.1、6.1.5.1、6.1.5.2、7.1.5.1、8.1.4.9等条款。文档在传输过程或者已经存入CDR后都有可能被黑客、恶意代码甚至程序BUG修改文档而无法自我检测，即使人工感觉到怀疑也需要追溯到原始文档进行对比，非常不方便。此时系统只是可用，但不是可信的。

为了提高安全性，一些CDR要求下属系统上传一份病历时同时上传两个文档：一个是带CA签名的PDF文件，包括可解析数据的文件（大多是XML格式）；另外还有验证PDF签名时用的用户共钥数据包和特定验证数据包。其结构如下所示：

这个能比较完整地实现PDF签名验证，但也存在一定的问题，主要有五点：

第一， PDF格式自带的数据签名技术是国外的，中国CA公司产品生成的PDF文件采用的是国产加密算法，标准PDF阅读器是不支持，只能是中国CA公司提供的PDF阅读器才能正确查看PDF阅读器。这限制了应用范围。

第二，为了验证PDF文件，需要额外的两个数据块：一是用户给PDF添加签名时使用的公钥证书文件，另一个是CA服务器生成的校验数据块。这是因为CA验证软件需要同时使用PDF文件、共钥数据、CA验证数据三个数据包才能完成无K宝验证。此时CDR服务器需要添加字段来存储这2种新的数据块，还需要安装CA验证程序模块，而且数据上传通道也大幅增加。这显著增加了系统复杂度。

第三，CDR服务器必须要把下属使用的CA软件装全，比如此图中需要安装河北CA、上海CA、江苏CA的软件。这样服务器按装了大量非核心软件，违反了等保标准第7.1.3.5条款。

第四，PDF文件只用于人工阅读，无法用于大数据分析处理。上传的PDF文件可能只有万分之一甚至更小的概率被调阅，但仍然要长期保存（政府规定，门诊病历存15年，住院病历存30年），占据了大量的存储空间，降低系统使用效率，增加了运维工作量。

第五，上传的可解析数据文件没有做CA签名，因此基本没有保护，可以任意修改。这些数据文件大多数情况下是用于大数据统计分析的，因此少量文件被篡改了也不影响统计分析结果的大局。但是若数据文件的内容被其他病历文档引用了，则存在重大安全风险，成为安全漏洞。

比如病人在第一分院的病历中的主诉为“咳血半年”，后上传到CDR时被修改成“咳嗽一月”，后病人转院到本部，而住院病历的“现病史”中引用了CDR中的这段主诉内容“咳嗽一月”，就会出现错误的原始信息，这容易导致医疗事故，而且无法精准追责。

为了避免这种安全风险，数据文件也需要加上CA签名，则系统复杂度翻倍，成本巨大。

对CDR的改进

而我们的“编辑器+CA签名”技术方案能帮助医院解决上述问题，此时系统结构如下：

此时下属系统上传文档时，CA验证数据直接内嵌到文档中，和文档是一个整体，就自然上传到CDR服务器中。由于有3个下属系统则只需要3个数据通道。而CDR服务器无需开辟新的字段来存储CA加密数据。

“编辑器+CA签名”技术方案包含软件签名验证操作（软件签名稍候说明），无需安装专门的CA服务器即可完成较为可靠的文档内容验证工作。另外CDR本身处于各类保护之下，因此实际当中无需安装CA服务器就可比较可靠地完成文档内容验证的工作。这符合等保标准第7.1.3.5条款。

另外，文档本身是开放的XML格式，既可以在编辑器中人工阅读，也可以用于后台解析来进行大数据统计分析，提高数据使用效率。

当然在极端情况下，为了实现确定无疑的CA验证，仍然可以在服务器端安装CA验证软件，不过这样就会增加成本，降低性价比，不适用于大部分医院。

此外，为了降低CA服务器的种类要求，建议医院在规划建设全院系统时就固定一家CA系统供应商，并改造下属系统。不过编辑器也内置特定CA服务器的接口。

这样当CA嵌入文档，对现有的CDR无需做出大的改动，即可实现全流程的CA签名和验证功能，大幅提升等保标准符合程度，降低高等保的实现难度，简化系统架构。

打个比方，文档等于领导人，而CA则是保镖。保镖和被保护人有时候是分离的（比如睡觉、上厕所）。而我们的“编辑器+CA签名”就是给领导人穿上防弹衣，时刻贴身保护领导人。

应用场景2：全行业数据传输链保护

类似上述CDR的原理，“编辑器+CA签名”也能实现全行业数据传输链的保护。

现在存在很多的数据多次跨机构的流通，形成全行业的数据传输链，如下图所示：

在EMR中实现了CA签名功能达到较高的等保水平，但是在后续的数据传输链中没有CA验证，使得处处充满了安全风险。若要验证文档是否修改需要逐层回溯到原始文档，非常麻烦。如果采用数字签名的PDF文件格式，则系统复杂度非常高，基本不可行。

而采用CA签名嵌入到文档中后，则文档具有一定的自我校验，能抵抗很多安全风险，此时传输链如下图所示：

这样就能以很好的性价比来实现较高等保水平的数据传输链，开发、实施、维护方便。可以实现可信的全行业数据互联互通。

应用场景3：多重局部签名

传统CA签名方式是将文档当作一个普通二进制数据来进行整体签名，此时一个文档只产生一个签名。

而DCWriter支持局部签名，也就是对文档的一部分内容进行签名，比如针对一个输入域、单元格、表格行、表格、文档节等分别签名，当然也可以对整个文档进行签名。

而且DCWriter支持一个文档内嵌多个签名。各个签名只对各自的局部内容负责，各个签名的验证过程相互独立不干扰。由此实现多重局部签名。

多重局部签名能应用于很多业务场景。比如手术知情同意书、会诊单、公文流转等等。手术知情同意书如下图所示：

此图中处理了手写签名的部分信息。这个文档包含“医生陈述”和“患者知情选择”两个部分，对应着医生签名和患者签名。医生使用硬件K宝的形式来签名，而患者使用电子手写板或指纹形式进行签名。医生和患者签名只对各自的内容负责。

当完成签名后，“医生陈述”的内容发生任何改变都会立刻导致医生的签名无效，从而显示为右图样式，但是不会对患者签名产生任何影响，反过来也一样。

而且这种过程是可逆的，如果文档修改后又恢复原样，则对应的签名也会就会恢复。

多重局部签名是一个前所未有的功能，让文档内容管理更精细、更准确。并能用于流程表单开发，也能降低相关的开发工作量。

“编辑器+CA签名”技术方案的其他说明

1. 传统CA签名模式

如下图所示：

这是传统HIT系统实现CA功能的模式。应用系统将文档当作一个普通的二进制数据包进行CA签名，签名操作会产生一小段硬件加密数据（大多是文件内容结合签名信息产生的哈希值）用于进行签名验证，而应用系统将这个硬件加密数据块存储在数据库字段中。此时文档和加密数据是分离存储的。

文档、硬件加密数据、CA服务器三者必须联合起来才能实现可信签名和验证操作，所产生的电子信息是和纸质文件具有同等法律效力。

在传统模式下，硬件加密数据会存储在数据库字段中，当文档脱离了原先的HIT系统而分发到其他系统中去时，文档内容未变，但电子签名已经失效了。这在很大程度限制了CA签名的应用场景。

2. 验证数据内嵌到文档

在“编辑器+CA签名”中，验证签名用的验证数据是内嵌到文档中的，如下图所示：

在这里，CA服务器实现了硬件验证，DCWriter内部实现了软件验证。也就是纯靠软件进行验证，如果安装了CA服务器则使用CA服务器的时间戳；如果没安装CA服务器则采用应用服务器的时间作为时间戳。软件验证算法具有一定的强度，但不排除很小的被破解的风险。

在上述的传统CA签名模式下，文档数据和CA签名是分开保存的，而在“编辑器+CA签名”中，编辑器会将硬件验证数据和软件验证数据存储在文档内部，成为文档的一个不可分割的部分而随文档存储和分发。这使得文档本身具有很好的自我验证和抗抵赖的功能。即使软件运行环境不够安全，文档本身也能达到相当高的安全性。

使用这种新模式的CA签名，由于使用了DCWriter编辑器无需安装其他第三方，既节省了部署服务器的成本，又实现了高水平的信息安全等级保护，堪称一代高性价比的神器。

编辑器同时支持软件验证+硬件验证，来灵活地适应多种运行环境。如下图所示：

当应用系统没有安装CA服务器，则仅仅启用软件验证功能，如果安装了CA服务器则启用软件验证+硬件验证的功能。

3. 文档的流通

由于签名信息嵌入在文档中，这能实现签名数据随文档的流通而流通。在一个没有安装CA硬件的终端中打开文档，则编辑器使用软件签名验证，验证结果在绝大多数情况下是可靠的。如果安装了CA硬件则使用软件验证+硬件验证，其验证结果在法律上是可靠的。

如果在流通过程中对文档的内容做了任何修改，比如添加删除内容、修改文字样式等，都会导致验证失败。这样电子签名就脱离具体的应用系统而独立存在，比较自由可靠的流通，实现了电子签名数据的互联互通。

4. 免驱

DCWriter内置特定CA硬件驱动程序，当编辑器程序启用CA功能时，会自动设置终端电脑，使得终端电脑无需安装CA硬件的驱动程序软件，方便部署和维护。不过CA服务器仍然需要手动安装和调试。

5. 实时签名验证

DCWriter打开文档后会实时进行签名的验证，如果签名负责的内容发生任何变化，则立刻导致签名无效，并在用户界面上以醒目的方式提示用户。这提供了很好的用户体验。

6. 简化开发

编辑器内置CA签名的功能，使得开发组织在开发支持CA签名的应用系统时非常方便，能节省很多开发工作量，也不要考虑开辟字段来存储CA硬件验证数据。这给开发、实施、维护带来不小的便利。

7. 推广

再先进的技术也需要推广才能带来实际价值。都昌公司已经和全国几百家医疗软件开发商合作，形成都昌生态圈，DCWriter电子病历编辑器已经得到非常广泛的应用，整个医疗行业每天使用DCWriter产生数百万页病历文档。此时只需要升级DCWriter软件版本，然后开发商编写少量的代码来对接CA服务器，就能让医院使用我们提供的最新技术，实现更高层次的CA签名的应用。

【小结】

法律认可的可信电子签名在编辑器技术紧密配合下形成“编辑器+CA签名”就能实现CA技术在整个HIT体系中的纵深应用，让CA签名技术的价值最大化。此时数据从产生的那刻起就能时刻维护自身的完整性、保密性、入侵防范、抗抵赖。

南京都昌公司在全行业率先提供的“编辑器+CA签名”技术方案不但能帮助医院通过系统安全等级保护评审，更能在实际应用当中为数据一路保驾护航；并让很多现行的虚伪的图片签名以较低的成本升级为法律认可的CA签名。DCWriter电子病历编辑器一直为实现可信、安全、滴水不漏的HIT体系提供强大的底层支撑，新功能的应用也将为电子签名在全行业的互联互通打下坚实基础。

【作者简介】

袁永福，南京东南大学毕业，微软MVP，南京都昌信息科技有限公司创始人，长期从事电子病历编辑器控件的研发和推广工作，其产品成为编辑器细分市场的主要品牌。（邮箱：28348092@qq.com）

【责任编辑：谭啸】