采用 OPC UA 的安全通信固件版本V2.0 及更高版本的 S7-1500 CPU 中，具有 OPC UA 服务器功能。OPC UA Security 中也涉及使用X.509 数字证书进行认证、加密以及数据完整性检查，并且同样采用 Public KeyInfrastructure(PKI)。根据应用的具体要求，端点安全可选择不同安全等级。我们将在一个单独章节中对 OPC UA 服务器功能进行介绍。PG/HMI间安全通信在 V17 及以上版本中集成有Zui新型控制器和Zui新型 HMI 设备，TIA Portal、STEP 7 和WinCC的主要组件可实现创新型 PG/PC 和 HMI 标准安全通信（简称为 PG/HMI 通信）。更多信息有关 OPC UA的更多信息，请参见“将 S7-1500 用作 OPC UA 服务器 (页 180)”部分。有关安全编程设备/HMI通信的更多信息，请参见“PG/HMI 间安全通信 (页 87)”部分。46通信功能手册, 11/2023,A5E03735819-AL通信服务5.6 安全通信5.6.1.2 设备相关的安全功能传输层安全 (TLS)是一种广泛使用的安全协议，可提高传输数据的安全性。对于自动化系统S7-1500，TLS 用于以下基于证书的应用的安全通信：• Web服务器（HTTPS 协议框架）• 安全的开放式用户通信 (OUC)，包括安全电子邮件（TMAIL_C 指令）• PG/HMI间安全通信TLS 负责对所列应用的客户端和服务器之间的通信进行身份验证和加密并保证完整性，例如CPU 的 Web 服务器和显示 CPU的诊断网页的 Web 浏览器之间的通信。OPC UA 服务器和 OPC UA 客户端应用实际上并不直接使用TLS，但使用的加密过程类似。 TLS 不断发展进步，产生了各种 TLS版本，这些版本在支持的密码套件（标准化加密方法集）和性能方面存在区别。互联网工程任务组 (IETF) 负责 TLS协议的描述。以下相关性适用：• TLS 1.3 对应于 RFC 8446 • TLS 1.2 对应于 RFC5246此外，并非每个设备都支持 RFC 中定义的所有加密方法。因此，建立连接后，客户端和服务器协商一个双方都支持的方法(Handshake) 以及要使用的参数。支持的 TLS 版本 (S7-1500)下表显示了给定 CPU 固件版本中支持的 TLS版本。CPU 固件版本 支持的 TLS 版本V3.0 TLS 1.2、TLS 1.3V2.9 TLS 1.2、TLS 1.3V2.8... V2.0 TLS 1.2创建证书时支持的加密方法和参数要为新证书生成公钥，请在 TIA Portal中设置加密方法和加密参数。这些证书参数与具体设备和所使用的应用程序相关一种可能性：在 CPU 属性中，转到“保护和安全 >证书管理器”(Protection & Security >Certificate manager)并生成新的设备证书。可以在“生成证书”(Generate Certificates) 对话框的“证书参数”(CertificateParameters) 下找到加密方法和加密参数的设置。示例：RSA 2048 代表加密密钥长度为 2048 位的非对称 RSA加密方法。通过加密确保数据机密消息加密是数据安全的一项重要措施。在通信过程中，即使加密的消息被第三方截获，这些潜在的侦听者也无法访问所获取的信息。在进行消息加密时，采用了大量的数学处理机制（算法）。所有算法都通过一个“密钥”参数，对消息进行加密和解密。•算法 + 密钥 + 消息 => 密文• 密文 + 密钥 + 算法=>（明文）消息对称加密对称加密的关键在于，两个通信伙伴都采用相同的密钥对消息进行加密和解密，如下图所示：Bob使用的加密密钥与 Alice使用的解密密钥相同。即，我们常说的双方共享一个密钥，可通过该密钥对消息进行加密和解密。该过程类似于一个公文箱，发送方和接收方使用同一把钥匙打开或锁上该公文箱。•优势：对称加密算法（如，AES、Advanced Encryption Algorithm）的速度较快。•缺点：如何将密钥发送给接收方，而不会落到其他人手中？此为密钥分发问题。如果截获的消息数量足够大，则可推算出所用的密钥，因此必须定期更换。如果通信伙伴比较多，则需分发的密钥数量巨大。非对称加密在非对称加密技术中使用一对密钥：一个公钥和一个私钥。与PKI 一同使用时，又称为公钥加密系统，简称 PKI 加密系统。通信伙伴（下图中的Alice）拥有一个私钥和一个公钥。公钥对所有人公开。即，任何通信伙伴都可以获得该公钥。拥有公钥的通信伙伴可对发送给 Alice的消息进行加密。即下图中的 Bob。Alice 的私钥为她自己所有而不公开，用于对发送给她的密文进行解密。① Alice将其公钥提供给 Bob。无需采取防范措施即可实现该过程：只要确定采用的是 Alice 的公钥，所有人都可以发消息给 Alice。②Bob 使用 Alice 的公钥对消息进行加密。③ Alice 使用私钥对 Bob 发送的密文进行解密。由于仅 Alice拥有私有且未公开，因此只有她才能对该消息进行解密。通过私钥，Alice 可以对使用她所提供的公钥加密的消息进行解密，而不仅仅只是Bob 的消息。图 5-8 非对称加密该系统与邮箱类似，所有人都可以向邮箱发送消息，但只有拥有密钥的人才能删除这些消息。•优势：使用公钥加密的消息，仅私钥拥有者才能进行解密。由于在解密时需要使用另一密钥（私钥），而且加密的消息数量庞大，因此很难推算出解密密钥。这意味着，公钥无需保持机密性，而这与对称密钥不同。另一大优点在于，公钥的发布更为方便快捷。在非对称密钥系统中，接收方将公钥发送到发送方（消息加密方）时无需建立专用的安全通道。与对称加密过程相比，密钥管理工作量相对较少。•缺点：算法复杂（如，RSA，以三位数学家 Rivest、Shamir 和 Adleman的名字的首字母命名），因此性能低于对称加密机制。实际通信中的加密过程在实际通信过程中（如，与 CPU Web服务器通信和开发式用户安全通信），通常在相关的应用层之后使用 TLS 协议。例如，应用层采用的协议为 HTTP 或SMTP，详细信息见前文所述。例如，TLS (Transport Layer Security)混合采用非对称加密和对称加密（混合加密）机制确保数据通过 Internet 进行安全传输，并支持以下子协议：• TLSHandshake Protocol，对通信伙伴进行身份验证，并在非对称加密的基础上对数据传输所需的算法和密钥进行协商• TLSRecord Protocol采用对称加密机制对用户数据加密以及进行数据交换。无论是非对称加密还是对称加密，这两种数据安全加密机制在安全性方面没有明显差异。数据安全等级取决于设置的参数，如所选密钥的长度等等。加密使用不当通过位串，无法指定公钥的身份。欺瞒者可使用他们自己的公钥声明为其他人。如果第三方使用该公钥将其认作是指定的通信伙伴，则将导致机密信息被窃取。之后，欺瞒者再使用自己的密钥对这些本消息进行解密，虽然这些消息本不应发送给他们。Zui终，导致敏感信息泄露，落入他人之手。为了有效预防此类错误的发生，该通信伙伴必须确信与正确的通信伙伴进行数据通信。此类信任关系是通过PKI中的数字证书建立的。通过签名确保数据的真实性和完整性由能够截获服务器与客户端之间的通信并将自身伪装成客户端或服务器的程序实施的攻击称为中间人攻击。如果未能检测到这些程序的真实身份，则将造成诸如S7 程序、CPU中设定值等重要信息泄漏，进而导致设备或工厂遭受攻击。可使用数字证书避免此类攻击。在安全通信过程中，所用的数字证书符合International Telecommunication Union (ITU) 的X.509标准。该证书用于检查（认证）程序、计算机或组织机构的身份。如何通过证书建立信任关系X.509证书主要用于将带有证书的数据身份（如，电子邮件地址或计算机名称）与公钥中的身份绑定在一起。身份可以是个人、计算机，也可以是机器设备。证书由证书颁发机构（CertificateAuthority，CA）或证书主体签发。而 PKI 系统则指定了用户信任证书颁发机构及其所签发证书的规则。证书认证过程：1.要获取一份证书，需要向与证书颁发机构相关联的注册机构提交一份证书申请。2. 证书颁发机构将基于既定标准对该申请和申请人进行评估。3.如果可以清晰识别申请人的身份，则证书颁发机构将签发一份已签名的证书进行确认。申请人现成为证书主体。在下图中，对这一过程进行了简要说明。但不涉及Alice 对该数字签名的检查过程。示例：• 用户也可以自己创建证书并签名，对发送给通信伙伴的消息进行加密。在上述示例中，Bob（而非Twent）可以使用私钥对自己的证书进行签名。之后，Alice 将使用 Bob 的公钥检查该签名是否与 Bob的公钥相匹配。该过程可用于简单的工厂内部数据加密通信。• 例如，根证书是一种由证书颁发机构 (CA)签署的自签名证书，其中包含证书颁发机构的公钥。自签名证书的特性自签名证书的证书主体“CN”(Common Name ofSubject) 和“Issuer”属性相同：用户已完成对证书的签名。字段“CA” (Certificate Autority)需设置为“False”；自签名证书不得用于对其它证书进行签名。自签名证书未包含在 PKI 系统中。证书内容符合 X.509 V3标准（同样用于 STEP 7 和 S7-1500 CPU）要求的证书通常包含以下元素：• 公钥•证书主体（即，密钥持有者）的详细信息。如，Common Name (CN) of Subject 。•各种属性，如序列号和有效期等等• 证书颁发机构 (CA) 的数字签名，用于证实信息的正确性。除此之外，还包含以下扩展详细：•指定公钥的使用范围(Key Usage)，如签名或密钥加密。在开放式用户安全通信中，使用 STEP 7创建一个新证书时，可从用途列表中选择相应的条目，如“TLS”。• 指定 Subject Alternative Name(SAN)，用于与 Web 服务器进行安全通信 (HTTP overTLS)，以确保 Web 浏览器地址栏中的证书同样属于该 URL所指定的 Web服务器。如何生成并验证签名非对称密钥可用于证书的验证：在“MyCert”证书示例中，介绍了具体的“签名”与“验证签名”过程。生成签名：1.“MyCert”证书的签发者使用一个特定的哈希函数（例如，SHA-1，SecureHashAlgorithm），根据证书数据生成一个哈希值。该 HASH 值是一个长度固定的位串。HASH值长度固定的优势在于，签名的时间始终相同。2. 之后，证书的签发者再使用由这种方式生成的 HASH值和私钥，生成一个数字签名。通常采用 RSA 签名机制。3. 数字签名将保存在证书中。此时，证书已签名。