摘要
本论文分别从通信安全原则、端到端的通信协议设计、基于安全平台的外部通信设计、应用风险分析几个方面，对安全通信开发涉及的风险点及应对措施进行了探讨。
关键词
安全通信 风险 措施
1 概述
对基于计算机技术的铁路信号控制系统，安全通信通常承载了控制系统的安全关键输入和输出，是安全产品开发中的一项重要内容。
安全控制系统中的一个重要概念是故障-安全。在传统的继电式控制系统中，通常将继电器的落下侧定义为安全侧，使用重力继电器的重力属性达到内在的故障-安全的目的。对基于计算机技术的控制系统，通信数据作为安全关键输入及输出，也应定义适当的安全行为和数据安全侧，满足系统的故障-安全原则。本文对安全通信的故障安全原则进行了讨论。
安全通信的第二个重要概念是端到端的协议设计。为了防护非置信通信系统引入的故障，需设计安全通信协议对安全关键数据进行防护。安全通信标准对端到端的协议设计提出了明确的要求。本系列论文对安全通信标准进行了解读分析，对常用安全通信协议实现的方案及比较进行了讨论。本文对端到端的协议设计进行了总结描述。
安全系统应在安全平台上实现。安全平台通常由3个或者4个CPU节点构成，基于安全平台的安全通信实现是端到端协议设计之外的扩展，基于安全平台实现的设计要点在本系列论文中进行了详细探讨。
安全通信层为安全关键的应用服务。安全通信层为通信本身可能造成的错误进行防护，应用业务应对由通信造成的其他属性进行分析和考虑，如通信延时等。本系列论文对通信延时引入的风险及防护措施进行了探讨。
2 安全通信原则
本章从通信故障安全、实现设计的独立性及数据防护三个方面对安全通信原则进行了探讨。
2.1. 通信故障安全原则
2.1.1 应明确定义通信发送方的安全侧行为为“不发送数据”。
开发者通常默认通信发送方的安全侧行为为“不发送数据”。由于系统死机或断电的行为即为“不发送数据”，因此明确定义发送方的安全侧行为为“不发送数据”是有必要的。
但由于对某些非周期的安全通信缺乏分析，“不发送数据”可能意味着风险。开发者应对每一项安全通信进行风险分析，在定义发送方的安全侧行为为“不发送数据”的前提下，接收方应有相应的机制导向安全。
应在应用接口规范中进行定义，以使得通信双方均明确该行为。
2.1.2 应明确定义通信接收方“导向安全”的判断标准。
对于周期通信数据，接收方判断“导向安全”的标准通常为“无有效数据”。对于这种情况，需注意以下几点：
1)需根据系统级性能分析或安全分析，合理定义容忍周期或时间。
2)对于冗余通信处理，应尤其注意导向安全的标准为“应用无有效数据”，而不是通信信道故障。
对于非周期通信数据，应根据应用情况，合理定义“导向安全”的标准。
应在应用接口规范中进行定义，以使得通信双方均明确该行为。
2.1.3 应明确定义通信接收方“导向安全”时的安全侧行为，包括数据安全侧以及系统安全反应。
通信接收方符合“导向安全”的标准时，应明确定义系统的安全反应，可能包括：
1) 通信数据刷新为预定义的安全侧。
2) 通信连接主动断开，以使得随后接收的数据不能立刻判定有效。
3) 系统的其他反应，如错误报告、倒机、退出运行、重启等。
应在应用接口规范中进行定义，以使得通信双方均明确该行为。
2.2. 独立性原则
2.2.1 通信相关安全功能的实现不应依赖于非安全部件。
通信相关的安全功能，如协议封装、数据校验、安全反应措施等，不应依赖于非安全部件。推荐的方式是进行端到端的通信，将数据传输网络定义为非安全系统，通信相关的安全功能都应在安全部件中完成。
2.2.2 从非安全部件到安全部件的安全关键数据，应进行应用数据的风险分析，确定适当的防护措施。
非安全部件产生的数据流为非置信数据。本条款是为了防护由非安全部件产生的数据流对系统安全关键功能的影响。
非安全部件向安全部件的安全关键数据流需通过协议进行防护。除此之外，非安全部件的应用数据为非置信数据，需对应用层数据的故障模式进行分析，并根据故障后果，在安全部件中实施适当的防护措施。典型的防护措施包括：
1) 对数据进行有效性检查（如数据值的合法范围检查）；
2) 对数据进行逻辑正确性检查（如联锁逻辑层对进路选择命令进行逻辑正确性检查）；
3) 对数据进行二次确认（如联锁逻辑层发起对道岔单操命令的二次确认请求）。
2.2.3 安全通信应采用与非安全通信不同的数据校验方式。
是为了防护非安全通信数据由于传输信道错误被传输至安全通信信道，并能被解析及错误使用的风险，安全通信应采用与非安全通信不同的数据校验方式。对应用于封闭环境的安全通信，由于非安全设备产生的数据是非置信数据，因此这是一个可能的风险。对应用于开放环境的安全通信，由于环境本身引入的数据伪装的风险也需要防护，因此不需要额外考虑该风险。
一个典型的校验方式为：如使用CRC码校验技术，可采用不同的校验长度，或使用不同的校验多项式。
2.3. 数据防护原则
2.3.1 内部及外部安全通信应采用通信协议进行数据防护。通信协议的设计可采用以下三种方式之一。
1) 根据通信环境和需求，采用适当的成熟通信协议。
2) 根据通信机制引入的可信故障模式，针对该故障模式设计防护措施。
3) 设计私有通信协议，并经过分析，可完整防护EN50159提示的七种通信风险。
2.3.2 通信数据完整性防护的范围应包含安全相关的所有字段。
通信数据完整性防护的范围应包含通信源ID、目标ID、时间戳或序列号等安全校验相关的所有字段，不应仅对应用数据进行防护。
2.3.3 安全关键的通信配置数据应在运行时定期检测数据未被破坏。
本条款是为了防止安全关键的配置数据被非预期的修改，导致危险的通信输出。配置数据被破坏的原因可能为内存故障，或由于程序缺陷导致的内存越界。
3 端到端通信协议设计
为了防护非置信通信系统引入的故障，需设计安全通信协议对安全关键数据进行防护。
安全通信标准对端到端的协议设计提出了明确的要求。本系列论文对安全通信标准进行了解读分析，对常用安全通信协议实现的方案及比较进行了讨论。
成熟通信协议具有防护完善的特点，但同时对资源需求较高，包括CPU、通信带宽等。而在特定系统的产品开发中，经常会遇到CPU的运算能力、存储空间、程序运行空间等限制，以及通信链路带宽的限制，例如RS232的115200bps、CAN的1Mbps等。因此，基于特定通信方式进行安全通信协议设计有时是不可避免的。对于这种情况，需对特定的传输环境、网络连接方式、通信机制进行风险分析，根据需要考虑的风险，制定通信协议的安全需求。本系列论文对如何基于风险分析的方法在特定系统进行通信协议设计进行了讨论。
需要注意的是，对于采用成熟通信协议的方案，需根据应用考虑适用的协议，如通信环境、通信频率、瞬间故障处理及协议的其他特性。对基于特定系统实施简化的通信协议设计，在通信媒介及特性改变时，需要重新分析安全通信协议的适用性。
4 基于安全平台的外部通信设计
基于安全平台上实现的安全通信除需考虑端到端协议之外，还需考虑在安全平台上实现安全通信带来的安全性、可靠性、冗余处理等一系列问题。安全平台通常由3个（三取二结构）、4个（二乘二取二结构）或6个（具备前置通信单元的二乘二取二结构）CPU节点构成，本文仅对基于二乘二取二平台的安全通信实现进行讨论。
为防护通信单点故障对整系统可靠性带来的影响，需考虑外部通信数据的冗余。不同的通信冗余设计涉及到不同的安全通信网组网结构及外部通信数据冗余的实现方式。此外，外部通信设计需考虑二乘二取二结构下系统在通信故障时的无缝切换，以及双系输入数据的同步处理。
对该论题的详细讨论参见本系列论文。
5 应用风险分析
在具备通信协议防护的基础上，应用进行通信架构设计和协议使用过程中，需进行系统级的风险分析。本章重点针对以下几个方面进行了探讨。
1) 应根据通信协议的特性进行风险分析。例如，对于允许数据丢失的通信协议，需意识到在一个或多个数据丢失的情况下，通信数据的变化将被忽略；对于允许数据一个或多个周期延时的通信协议，在达到可容忍的安全反应时间之前，通信数据的变化将被忽略。
2) 通信节点对自身身份的正确识别是进行安全通信的前提。通信节点对自身身份识别错误通常会导致严重的安全风险。通信节点对自身身份的识别应作为安全功能，进行功能风险分析, 将防护措施纳入安全需求。
3) 在系统方案初期对这些需求尽早进行识别，对大系统的设计是非常必要的。尤其是一些反应时间或性能要求较苛刻的安全功能，尽早分析和识别时间延时需求及性能需求，有利于向各子系统的通信可容忍延时进行合理分配和控制、进行全局的数据流优化等。对输入数据的延时应考虑从“数据产生源节点”到“数据使用节点”的累计延时；对于多个数据来源共同构成数据输入的情况，应分析各输入来源变化次序不确定性带来的风险。本系列论文对该问题进行了详细的探讨。