西门子STEP 7 Professional 安全通信

2018年6月30日15:01:36 发表评论 186 阅读

10.1.3.4.1 安全通信的基础知识

10.1.3.4.1.1 安全通信的基础知识

在 STEP 7 (TIA Portal) V14 及更高版本和固件版本 V2.0 及更高版本的 S7-1500 CPU 中,设计了大量的安全通信选项。
“S7-1500 CPU”是指 S7-1500F、S7-1500T、S7-1500C 系列 CPU 和 S7-1500pro CPU 和 ET200SP CPU。
简介
“安全”(secure) 属性用于识别以 Public Key Infrastructure ( PKI ) 为基础的通信机制(例如, RFC 5280 ,用于 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile )。 Public Key Infrastructure ( PKI ) 是一个可签发、发布和检查数字证书的系统。在 PKI 使用签发的数字证书来确保计算机通信安全。如果 PKI 采用非对称密钥加密机制,则可对网络中的消息进行数字签名和加密。
在 STEP 7 (TIA Portal) 中组态用于安全通信的组件,将使用一个非对称密钥加密机制,使用一个公钥 ( Public Key ) 和一个私钥 ( Private Key ) 进行加密。并使用 TLS ( Transport Layer Security ) 作为加密协议。 TLS 是 SSL ( Secure Sockets Layer ) 协议的后继协议。
安全通信的目标
安全通信用于实现以下目标:
  • 机密性
    即,数据安全/无法窃取。
  • 完整性
    即,接收方和发送方所接收/发送的消息完全相同,未经更改。消息在传输过程中未发生更改。
  • 端点认证
    即,端点的通信伙伴确实为声明的本人且为数据应到达的通信端。验证伙伴方的身份。
在过去,这些目标通过与 IT 和联网的计算机相关。而如今,包含有敏感数据的工业设备和控制系统同样面临信息安全高风险。这是因为,这些设备它们同样实现了网络互联,因而必须满足严格的数据交换安全要求。
在过去,往往会采用单元保护机制,通过防火墙或 VPN 连接保护自动化单元安全(如,使用安全模块),而如今同样如此。
但是,在越来越的应用中,需要通过企业内部网或公共网络以加密形式将数据传送到外部计算机。
安全通信的通用原则
无论采用何种机制,安全通信都基于 Public Key Infrastructure ( PKI ) 理念,包含以下组成部分:
  • 非对称加密机制。该机制用于:
    • 使用公钥或私钥对消息进行加密/解密。
    • 验证消息和证书中的签名。
      发送方/证书所有方通过自己的私钥对消息/证书进行签名。接收方/验证者使用发送方/证书所有方的公钥对签名进行验证。
  • 使用 X.509 证书传送和保存公钥。
    • X.509 证书是一种数字化签名数据,根据绑定的身份对公钥进行认证。
    • X.509 证书中还包含详细信息以及使用公钥的限制条件。例如,证书中公钥的生效日期和过期日期。
    • X.509 证书中还以安全的形式包含了证书颁发方的相关信息。
在后续的章节中,将简要介绍在 STEP 7 (TIA Portal) 中管理证书和编写 secure Open User Communication ( sOUC ) 通信指令等所需的基本知识。
STEP 7 中的安全通信
在 STEP 7 V14 及其更高版本中,提供了安全通信的组态和操作所需的 PKI 。
示例:
  • Hypertext Transfer Protokoll ( HTTP ) 通过 TLS ( Transport Layer Security ) 协议变为 Hypertext Transfer Protokoll Secure ( HTTPS )。由于 HTTPS 中集成了 HTTP 和 TLS 协议,因此在相应的 RFC 中,又称为“ HTTP over TLS ”。在浏览器中,可清楚地看到所用的协议为 HTTPS :浏览器地址栏中 URL 为“https:// ”,而非“ http:// ”,这也指明了这点。在大多数浏览器中,这类的安全连接将突出显示。
  • Open User Communication 变为 secure Open User Communication 。这种通信方式的底层协议同样为 TLS 。
  • 电子邮件服务提供商同样支持基于“ Secure SMTP over TLS ”协议进行访问,从而提高电子邮件通信的安全性。
下图显示了通信层中的 TLS 协议。

西门子STEP 7 Professional 安全通信-1

采用 OPC UA 的安全通信
固件版本 V2.0 及更高版本的 S7-1500 CPU 中,具有 OPC UA 服务器功能。OPC UA Security 中也涉及使用 X.509 数字证书进行认证、加密以及数据完整性检查,并且同样采用 Public Key Infrastructure ( PKI )。根据应用的具体要求,可选择不同的安全等级来确保端点安全。我们将在一个单独章节中,对 OPC UA 服务器功能进行介绍。

10.1.3.4.1.2 通过加密确保数据机密

消息加密是数据安全的一项重要措施。在通信过程中,即使加密的消息被第三方截获,这些潜在的侦听者也无法访问所获取的信息。
在进行消息加密时,采用了大量的数学处理机制(算法)。
所有算法都通过一个“密钥”参数,对消息进行加密和解密。
  • 算法 + 密钥 + 消息 => 密文
  • 密文 + 密钥 + 算法 =>(明文)消息
对称加密
对称加密的关键在于,两个通信伙伴都采用相同的密钥对消息进行加密和解密,如下图所示:Bob 使用的加密密钥与 Alice 使用的解密密钥相同。这正是我们常说的,双方共享一个秘密(即,安全密钥),且通过该密钥对消息进行加密和解密。

西门子STEP 7 Professional 安全通信-2

Bob 采用对称密钥对消息进行加密
Alice 采用对称密钥对加密后的消息进行解密
该过程类似于一个公文箱,发送方和接收方使用同一把钥匙打开或锁上该公文箱。
  • 优势:对称加密算法(例如, AES 、 Advanced Encryption Algorithm )的速度较快。
  • 缺点:如何将密钥发送给接收方,而不会落到其他人手中?此为密钥分发问题。如果收到的消息数量足够大,则可推算出所用的密钥,因此必须定期更换。
如果通信伙伴比较多,则需分发大量的密钥。
非对称加密
在非对称加密技术中使用一对密钥:一个公钥和一个私钥。与 PKI 相关,它还被称为公钥过程或仅 PKI 过程。通信伙伴(下图中的 Alice)拥有一个私钥和一个公钥。公钥对所有人公开。即,任何通信伙伴都可以获得该公钥。拥有公钥的通信伙伴可对发送给 Alice 的消息进行加密。即下图中的 Bob。
Alice 的私钥为她自己所有而不公开,用于对发送给她的密文进行解密。

西门子STEP 7 Professional 安全通信-3

Alice 将其公钥提供给 Bob。无需采取防范措施即可实现该过程:只要确定采用的是 Alice 的公钥,所有人都可以发消息给 Alice。
Bob 使用 Alice 的公钥对消息进行加密。
Alice 使用私钥对 Bob 发送的密文进行解密。由于仅 Alice 拥有私有且未公开,因此只有她才能对该消息进行解密。通过私钥,Alice 可以对使用她所提供的公钥加密的消息进行解密,而不仅仅只是 Bob 的消息。
该系统与邮箱类似,所有人都可以向邮箱发送消息,但只有拥有密钥的人才能删除这些消息。
  • 优势:使用公钥加密的消息,仅私钥拥有者才能进行解密。由于在解密时需要使用另一密钥(私钥),而且加密的消息数量庞大,因此很难推算出解密密钥。这意味着,公钥无需保持机密性,而这与对称密钥不同。
    另一大优点在于,公钥的发布更为方便快捷。在非对称密钥系统中,接收方将公钥发送到发送方(消息加密方)时无需建立专用的安全通道。因此,与对称加密过程相比,可减少管理密钥所需的工作量。
  • 缺点:算法复杂(如,RSA,以三位数学家 Rivest、Shamir 和 Adleman 的名字的首字母命名),因此性能低于对称加密机制。
实际通信中的加密过程
在实际通信过程中(如,与 CPU Web 服务器通信和开发式用户安全通信),通常在相关的应用层之后使用 TLS 协议。例如,应用层采用的协议为 HTTP 或 SMTP ,详细信息见前文所述。
例如, TLS ( Transport Layer Security ) 混合采用非对称加密和对称加密(混合加密)机制确保数据通过 Internet 进行安全传输,并支持以下子协议:
  • TLS Handshake Protocol 对通信伙伴进行身份验证,并在非对称加密的基础上对后续数据传输所需的算法和密钥进行协商
  • TLS Record Protocol 采用对称加密机制对用户数据加密以及进行数据交换。
无论是非对称加密还是对称加密,这两种数据安全加密机制在安全性方面没有明显差异。数据安全等级取决于设置的参数,如所选密钥的长度等等。
加密使用不当
通过位串,无法指定公钥的身份。欺瞒者可使用他们自己的公钥声明为其他人。如果第三方使用该公钥将其认作是指定的通信伙伴,则将导致机密信息被窃取。之后,欺瞒者再使用自己的密钥对这些本消息进行解密,虽然这些消息本不应发送给他们。最终,导致敏感信息泄露,落入他人之手。
为了有效预防此类错误的发生,该通信伙伴必须确信与正确的通信伙伴进行数据通信。此类信任关系是通过 PKI 中的数字证书建立的。

10.1.3.4.1.3 通过签名确保数据的真实性和完整性

由能够截获服务器与客户端之间的通信并将自身伪装成客户端或服务器的程序实施的攻击称为中间人攻击。如果未能检测到这些程序的真实身份,它们会通过 S7 程序获取重要信息或设置 CPU 中的值,进而导致设备或工厂遭受攻击。可使用数字证书避免此类攻击。
在安全通信过程中,所用的数字证书符合 International Telecommunication Union ( ITU ) 的 X.509 标准。该证书用于检查(认证)程序、计算机或组织机构的身份。
如何通过证书建立信任关系
X.509 证书主要用于将带有证书主题数据的身份(例如,电子邮件地址或计算机名称)与身份的公钥绑定在一起。身份可以是个人、计算机,也可以是机器设备。
证书由证书颁发机构( Certificate Authority , CA )或证书所有者签发。而 PKI 系统则指定了用户信任证书颁发机构及其所签发证书的规则。
证书认证过程:
  1. 要获取一份证书,需要向与证书颁发机构相关联的注册机构提交一份证书申请。
  2. 证书颁发机构将基于既定标准对该申请和申请人进行评估。
  3. 如果可以清晰识别申请人的身份,则证书颁发机构将签发一份已签名的证书进行确认。申请人现成为证书持有者。
在下图中,对这一过程进行了简要说明。但不涉及 Alice 对该数字签名的检查过程。

西门子STEP 7 Professional 安全通信-4

自签名证书
自签名证书是指,由证书所有者而非独立的证书颁发机构签名的证书。
示例:
  • 用户也可以自己创建证书并签名,对发送给通信伙伴的消息进行加密。在上述示例中,Bob(而非 Twent)可以使用私钥对自己的证书进行签名。之后,Alice 可使用 Bob 的公钥检查该签名是否与 Bob 的公钥相匹配。该过程可用于简单的工厂内部数据加密通信。
  • 例如,Root 证书是一种由证书颁发机构 (CA) 签署的自签名证书,其中包含颁发者的公钥。
自签名证书的特性
自签名证书的证书持有者和“ Issuer ”(签发者)的属性“ CN ”( Common Name of Subject ) 完全相同:用户已完成对证书的签名。证书颁发机构的字段“ 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 over TLS ),以确保 Web 浏览器地址栏中的证书同样属于该 URL 所指定的 Web 服务器。
如何生成并验证签名
非对称密钥可用于证书的验证:在“ MyCert ”证书示例中,介绍了具体的“签名”与“验证签名”过程。
生成签名:
  1. “ MyCert ”证书的签发者使用一个特定的哈希函数(例如, SHA-1 , Secure Hash Algorithm ),根据证书数据生成一个哈希值。
    该 HASH 值是一个长度固定的位串。HASH 值长度固定的优势在于,签名的时间始终相同。
  2. 之后,证书的签发者再使用由这种方式生成的 HASH 值和私钥,生成一个数字签名。通常采用 RSA 签名机制。
  3. 数字签名将保存在证书中。此时,证书已签名。
验证一个签名:
  1. “ MyCert ”证书的认证方将获得由证书签发者签发的证书和公钥。
  2. 使用签名时所用的哈希算法(例如, SHA-1 ),根据证书数据生成一个新的哈希值。
  3. 然后,将该哈希值与通过证书签发者的公钥以及签名算法确定的哈希值进行比较,以验证证书的签名。
  4. 如果签名验证结果为正,则表示证书持有者的身份以及完整性(即,证书内容的可靠性和真实性)均通过验证。拥有该公钥(即,证书颁发机构的证书)的任何人均可对该签名进行检查,进而证明该证书确实由该证书颁发机构签发。
下图显示了 Alice 如何采用 Twent(代表证书颁发机构,CA)证书中的公钥,验证 Bob 的公钥签名。因此,在验证时仅需要验证证书颁发机构颁发的证书的可用性。验证会在 TLS 会话中自动执行。

西门子STEP 7 Professional 安全通信-5

签名消息
上文介绍的签名与验证方法同样使用 TLS 会话对消息进行签名和验证:
如果发送方基于一条消息生成一个哈希值并使用私钥对该哈希值进行签名,之后将其添加到原始消息中,则消息接收方即可对消息的完整性进行检查。接收方使用发送方的公钥对该 HASH 值进行解密,并将其与所收到消息中的 HASH 进行比较。如果这两个值不同,则表示该消息在传送过程中被篡改。
Root 证书的证书链
PKI 证书通常按层级进行组织:层级顶部由根证书构成。这些证书并非由上证书颁发机构签名。根证书的证书持有者和证书签发者完全相同。根证书享受绝对信任。它们是信任的“锚点”,因此对于接受方,其必须用作绝对证书。此类证书存储在专门存储受信证书的区域。
根证书用于对下级证书颁发机构颁发的证书(即,所谓的中间证书)进行签名。从而实现从 Root 根证书到中间证书信任关系的传递。由于中间证书可对诸如 Root 证书之类的证书进行签名,因此这两种证书均称为“CA 证书”
这种证书签名层级可通过多个中间证书进行延伸,直至最底层的实体证书。最终实体证书即为待识别用户的证书。
验证过程则反向贯穿整个层级结构:综上所述,先通过签发者的公钥确定证书签发者并对其签名进行检查,之后再沿着整条信任链确定上证书签发者的证书,直至到达根证书。
结论:无论组态何种安全通信类型,每台设备中都必需包含一条到 Root 证书的中间证书链(即证书路径),对通信伙伴的最低层实体证书进行验证。

10.1.3.4.1.4 使用 STEP 7 管理证书

STEP 7 V14(及更高版本)连同 S7-1500-CPU(固件版本为 2.0 及更高版本)支持 Internet PKI (RFC 5280)的范围为,确保 S7-1500 CPU 能够与同样支持 Internet PKI 的设备进行通信。
例如,会因此而使用 X.509 证书来验证前文介绍的证书。
STEP 7 V14 及更高版本采用的 PKI 与 Internet PKI 类似。例如,证书吊销列表 (CRL) 不受支持。
创建或分配证书
对于具有安全属性的设备(例如,固件版本为 V2.0 或更高版本的 S7-1500 CPU),可以在 STEP 7 中针对不同的应用创建相应的证书。
在 CPU 巡视窗口的以下区域内,可创建新的证书或选择现有的证书:
  • “保护和安全 > 证书管理器”(Protection & Security > Certificate manager)- 用于生成或分配所有类型的证书。对于安全的开放式用户通信,创建证书所使用的默认设置为 TLS 证书。
  • “Web 服务器 > 安全”(Web server > Security) - 用于生成和分配 Web 服务器证书。
  • “OPC UA > 服务器 > 安全”(OPC UA > Server > Security)- 用于生成或分配 OPC UA 证书

西门子STEP 7 Professional 安全通信-6

“保护和安全 > 证书管理器”(Protection & Security > Certificate manager) 区域的特性
只有在巡视窗口的该区域,才能在全局(即,项目级)证书管理器和局部(即,设备特定的)证书管理器之间进行切换(选项“使用证书管理器的全局安全设置”(Use global security settings for certificate manager))。该选项确定了您是否有权访问项目中的所有证书。
  • 如果在全局安全设置中  使用证书管理器,则只能访问 CPU 的局部证书存储器。例如,您无权访问导入的证书或根证书。如果没有这些证书,则可用的功能有限。例如,您只能创建自签名的证书。
  • 如果在全局安全设置中未使用证书管理器并以管理员身份登录,则有权访问全局(项目级)证书存储器。例如,您可以向 CPU 分配导入的证书,也可以创建项目 CA(项目的证书颁发机构)签发并且签名的证书。
下图显示了在激活 CPU 巡视窗中的“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 选项后“全局安全设置”(Global security settings) 在项目树中如何显示。

西门子STEP 7 Professional 安全通信-7

如果您双击项目树中全局安全设置下的“用户登录”(User login) 并进行登录,则还会显示“证书管理器”(Certificate manager) 行。
双击“证书管理器”(Certificate manager) 行,您便有权访问项目中的所有证书,这些证书分别列入选项卡“CA”(证书颁发机构)、“设备证书”(Device certificates) 以及“受信证书和根证书颁发机构”(Trusted certificates and root certification authorities)。

西门子STEP 7 Professional 安全通信-8

私钥
STEP 7 在生成设备证书或服务器证书(最终实体证书)时会生成私钥。根据是否在全局安全设置使用证书管理器,可确定以加密形式存储私钥的位置:
  • 如果使用全局安全设置,则私钥将以加密形式存储在全局(项目级)证书存储器中。
  • 如果未使用全局安全设置,则私钥将以加密形式在局部(CPU 特定的)证书存储器中。
解密数据等操作所需的私钥显示在全局安全设置中证书管理器的“设备证书”(Device certificates) 选项卡的“私钥”(Private key) 列。
下载硬件配置时,会将设备证书、公钥和私钥下载至 CPU。
注意
选项“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 会影响之前使用的私钥:如果在未在全局安全设置中使用证书管理器的情况下创建了证书,然后将该选项更改为使用证书管理器,则私钥会丢失,证书 ID 会发生变化。系统会发出警告,提示您注意这种情况。因此,在开始组态时,指定证书管理所需的选项。

10.1.3.4.1.5 证书管理示例

如前文所述,每种类型的安全通信都需要使用证书。在以下章节中,举例说明如何使用 STEP 7 进行证书管理,从而满足开放式用户安全通信的要求。
在下文中,就哪些设备是参与通信的伙伴进行了区分。为通信参与者提供所需证书的相应步骤分别进行了介绍。需要固件版本为 2.0 或更高版本的 S7-1500 CPU 或者 S7-1500 软件控制器。
通常,以下情况适用:
建立安全连接(“握手”)时,通信伙伴通常只会传送其最终实体证书(设备证书)。
因此,验证已传送设备证书所需的 CA 证书必须位于相应通信伙伴的证书存储器中。
说明
在 CPU 中,必须设置当前的日期/时间。
使用安全通信(如,HTTPS、安全 OUC、OPC UA)时,需确保相应模块为当前时间和当前日期。否则,模块将所用的证书评估为无效,同时不进行安全通信。
两个 S7-1500 CPU 之间安全的开放式用户通信
两个 S7-1500 CPU PLC_1 和 PLC_2 应通过安全的开放式用户通信交换数据。
使用 STEP 7 生成所需的设备证书,然后将其分配给 CPU,如下所述。
STEP 7 项目证书颁发机构(项目的 CA)用于对设备证书进行签名。
在用户程序中根据证书 ID 对证书进行引用(TCON 通信指令组合相关的系统数据类型,例如 TCON_IPV4_SEC)。STEP 7 在生成或创建证书时会自动分配证书 ID。

西门子STEP 7 Professional 安全通信-9

操作步骤
STEP 7 自动将所需的 CA 证书连同硬件配置下载到参与通信的 CPU 中,使两个 CPU 均存在证书验证要求。因此,您只需为相应的 CPU 生成设备证书即可,其余工作由 STEP 7 完成。
  1. 选择 PLC_1,并激活“保护和安全”(Protection & Security) 区域中的“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 选项。
  2. 以用户身份登录项目树的“全局安全设置”(Global security settings) 区。对于新项目,首次登录时默认采用“管理员”身份。
  3. 返回到“保护与安全”(Protection & Security) 部分中的 PLC 1 中。在“设备证书”(Device certificates) 表格中,单击“证书持有者”(Certificate holder) 列的一个空行,添加新的证书。
  4. 单击下拉列表中的“添加”(Add) 按钮,选择证书。
    “生成新证书”(Generate new certificate) 对话框随即打开。
  5. 保留该对话框中的默认设置。这些设置专用于开放式用户安全通信(用途:TLS)。
    提示信息:扩展证书持有者的预设名称(在这种情况下,为 CPU 名称)。为了更好地进行区分,需要管理大量设备证书时,建议保留默认的 CPU 名称。
    示例: PLC_1/TLS 变为 PLC_1-SecOUC-Chassis17FactoryState 。
  6. 编译组态。
    设备证书和 CA 证书是组态的一部分。
  7. 为 PLC_2 重复上述步骤。
在接下来的步骤中,需要创建用户程序以进行数据交换,并下载组态以及相应的程序。
使用自签名证书而非 CA 证书
创建设备证书时,可选择“自签名”(Self-signed) 选项。无需登录全局安全设置即可创建自签名证书。不建议执行该过程,因为通过这种方法创建的证书不会存在于全局证书存储器中,因此不会直接分配给伙伴 CPU。
如前文所述,应谨慎选择证书持有者的名称,这样才会毫无疑问地为设备分配合适的证书。
无法通过 STEP 7 项目的 CA 证书验证自签名的证书。要确保自签名证书可通过验证,需要将通信伙伴的自签名证书加入每个 CPU 的可信伙伴设备列表中。为此,必须已激活选项“使用证书管理器的全局安全设置”(Use global security settings for certificate manager),并以用户身份登录全局安全设置。
要将通信伙伴的自签名证书添加到 CPU 中,请按以下步骤操作:
  1. 选择 PLC_1,并导航至“保护和安全”(Protection & Security) 区域的“伙伴设备证书”(Certificates of partner devices) 表。
  2. 单击“证书持有者”(Certificate holder) 列的空行,打开下拉列表,以便添加或选择证书。
  3. 从下拉列表中选择通信伙伴的自签名证书,并确认选择。
在接下来的步骤中,需要创建用户程序以进行数据交换,并下载组态以及相应的程序。
S7-1500 CPU(作为 TLS 客户端)与外部设备(作为 TLS 服务器)之间安全的开放式用户通信
例如,两个设备将通过 TLS 连接或 TLS 会话交换数据,从而交换配方、生产数据或质量数据:
  • S7-1500 CPU (PLC_1) 作为 TLS 客户端;CPU 采用安全的开放式用户通信
  • 外部设备(例如,制造执行系统 (MES))作为 TLS 服务器
作为 TLS 客户端,S7-1500 CPU 建立与 MES 系统的 TLS 连接/会话。

西门子STEP 7 Professional 安全通信-10

TLS 客户端
TLS 服务器
为验证 TLS 服务器,S7-1500 CPU 需要 MES 系统的 CA 证书:根证书以及中间证书(如果适用,用于验证证书路径)。
需要将这些证书导入 S7-1500 CPU 的全局证书存储器中。
要导入通信伙伴的证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要导入的证书选择匹配表(根证书颁发机构的受信证书)。
  3. 右键单击该表,打开快捷菜单。单击“导入”(Import),导入所需证书或所需 CA 证书。
    通过导入过程,相关证书会收到证书 ID,并会在下一步中被分配给模块。
  4. 选择 PLC_1,并导航至“保护和安全”(Protection & Security) 区域的“伙伴设备证书”(Certificates of partner devices) 表。
  5. 单击“证书持有者”(Certificate holder) 列的空行,以添加导入的证书。
  6. 从下拉列表中选择通信伙伴的所需 CA 证书,并确认选择。
此外,MES 系统还会要求提供 CPU 的设备证书来验证 CPU(即,TLS 客户端)。在这种情况下,CPU 的 CA 证书必须对 MES 系统可用。将证书导入 MES 系统的前提条件是,先从 CPU 的 STEP 7 项目中导出 CA 证书。请按以下步骤操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要导出的证书选择匹配表(CA 证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“导出”(Export)。
  5. 选择证书的导出格式。
在接下来的步骤中,需要创建用户程序以进行数据交换,并下载组态以及相应的程序。
S7-1500 CPU(作为 TLS 服务器)和外部设备(作为 TLS 客户端)之间安全的开放式用户通信
如果 S7-1500 CPU 用作 TLS 服务器,并且外部设备(例如,ERP 系统(企业资源规划系统))建立 TLS 连接/会话,则您需要以下证书:
  • 对于 S7-1500 CPU,使用私钥生成设备证书(服务器证书),并将其与硬件配置一同下载。生成服务器证书时,可使用选项“由证书颁发机构签名”(Signed by certificate authority)。
    密钥交换需要使用私钥,如示例“基于 TLS 的 HTTP”的图所示。
  • 对于 ERP 系统,需要导出 STEP 7 项目的 CA 证书,并将其导入/下载至 ERP 系统。基于 CA 证书,ERP 系统将在建立 TLS 连接/会话过程中检查从 CPU 传送到 ERP 系统的 S7-1500 服务器证书。

西门子STEP 7 Professional 安全通信-11

TLS 服务器
TLS 客户端
前文对所需操作进行了介绍。
通过 S7-1543-1 CP(作为电子邮件客户端)实现的安全的开放式用户通信(基于 TLS 的 SMTP)
S7-1500 CPU 可使用通信指令 TMAIL-C 通过 CP 1543-1 与电子邮件服务器建立安全连接。
借助系统数据类型 TMail_V4_SEC、TMail_V6_SEC 和 TMail_QDN_SEC,可以指定电子邮件服务器的伙伴端口,进而通过“基于 TLS 的 SMTP”访问电子邮件服务器。

西门子STEP 7 Professional 安全通信-12

实现安全的电子邮件连接的前提条件是,将根证书和中间证书从电子邮件服务器(提供方)导入至 STEP 7 项目的全局证书存储器。将这些证书分配至 CP 后,CP 会检查由电子邮件服务器在通过该证书建立 TLS 连接/会话时发送的电子邮件服务器的服务器证书。
请按以下步骤操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要导入的证书选择匹配表(根证书颁发机构的受信证书)。
  3. 右键单击该表,打开快捷菜单。单击“导入”(Import),导入所需证书或所需 CA 证书。
    通过导入过程,相关证书会收到证书 ID,并会在下一步中被分配到 CP。
  4. 选择 CP 1543-1,并导航至“安全”(Security) 部分中的“伙伴设备证书”(Certificates of partner devices) 表。
  5. 单击“证书持有者”(Certificate holder) 列的空行,以添加导入的证书。
  6. 从下拉列表中选择电子邮件服务器所需的 CA 证书,并确认选择。
在接下来的步骤中,需要创建用户程序以实现 CPU 的电子邮件客户端功能,并下载组态以及相应的程序。

10.1.3.4.1.6 示例:基于 TLS 的 HTTP

下图显示了如何使用介绍的机制在 S7-1500 CPU 的 Web 浏览器和 Web 服务器之间创建安全通信。
首先介绍如何更改 STEP 7 中的选项“仅允许通过 HTTPS 进行访问”(Permit access only through HTTPS)。自 STEP 7 V14 起,您可以影响固件版本为 V2.0 及更高版本的 S7-1500 CPU Web 服务器的服务器证书:此服务器证书采用该版本及更高版本的 STEP 7 生成。
此外,还显示了使用 PC 的 Web 浏览器通过加密的 HTTPS 连接调用 CPU 的 Web 服务器网站时采用的过程。
使用固件版本为 V2.0 及更高版本 S7-1500 CPU 的 Web 服务器证书
对于固件版本 V2.0 及以下版本的 S7-1500 CPU,设置 Web 服务器属性时,如果无特殊要求,需设置为“只允许通过 HTTPS 访问”(Permit access only with HTTPS)。
对于此类 CPU,您无需参与证书的处理过程;CPU 将自动为 Web 服务器生成所需证书。
对于固件版本 V2.0 及更高版本的 S7-1500 CPU,STEP 7 会为 CPU 生成服务器证书(最终实体证书)。在 CPU 的属性中为 Web 服务器分配服务器证书(“Web 服务器 > 服务器安全”(Web server > Server security))。
由于服务器证书名称始终预设,因此 Web 服务器的简单组态没有任何变化:激活 Web 服务器并激活选项“仅允许使用 HTTPS 进行访问”(Permit access only with HTTPS) - STEP 7 会在编译期间使用预设名称生成服务器证书。
无论您是否在全局安全设置中使用证书管理器:STEP 7 都具备生成服务器证书所需的全部信息。
此外,您还可以确定服务器证书的属性,例如名称或有效期等。
说明
在 CPU 中,必须设置当前的日期/时间。
使用安全通信(如,HTTPS、安全 OUC、OPC UA)时,需确保相应模块为当前时间和当前日期。否则,模块将所用的证书评估为无效,同时不进行安全通信。
下载 Web 服务器证书
将硬件配置下载到 CPU 中时,还会自动加载 STEP 7 生成的服务器证书。
  • 如果您在全局安全设置中使用证书管理器,则项目的证书颁发机构(CA 证书)会对 Web 服务器的服务器证书进行签名。下载时,项目的 CA 证书也会自动加载。
  • 如果未在全局安全设置中使用证书管理器,则 STEP 7 会生成服务器证书作为自签名证书。
通过 CPU 的 IP 地址对 CPU 的 Web 服务器进行寻址时,每次 CPU 中以太网接口的 IP 地址发生更改时,都必须生成新的服务器证书并加载(最终实体证书)。这是由于 CPU 的身份随 IP 地址一同更改。根据 PKI 规则,该身份必须进行签名。
如果使用域名(如,“ myconveyer-cpu.room13.myfactory.com ”)而非 IP 地址对 CPU 进行寻址,则可避免这一问题。为此,需要通过 DNS 服务器对 CPU 的域名进行管理。
为 Web 浏览器提供一份 Web 服务器的 CA 证书
在 Web 浏览器中,通过 HTTPS 访问 CPU 网站时,需安装该 CPU 的 CA 证书。如果未安装证书,则将显示一条警告消息,不建议访问该页面。要查看该页面,需显式“添加例外情况”。
有效的 root 证书(证书颁发机构),可从 Web 服务器“简介”(Intro) Web 页面的“下载证书”(Download certificate) 中下载。
在 STEP 7 中,可采用另一种方式:使用证书管理器,将项目的 CA 证书导出到 STEP 7 中的全局安全设置中。之后,再将 CA 证书导入浏览器中。
安全通信的过程
下图简要说明了通信的建立方式(“握手”),并着重介绍了数据交换(此处,通过 HTTP over TLS )所用密钥的协商过程。
然而,该过程在理论上适用于以使用 TLS 为基础的所有通信选项,即,也适用于安全的开放式用户通信(请参见安全通信基础)。

在本示例图中并不涉及 Alice 端(浏览器端)对 Web 服务器所发送证书的验证措施。Alice 能否信任传送的 Web 服务器证书,并因此而信任该 Web 服务器的身份以及允许数据交换,取决于验证结果。
验证 Web 服务器可靠性的步骤如下:
  1. Alice 必须获得所有相关证书颁发机构的公钥,即,必须拥有整个证书链,才能对该 Web 服务器证书(即,Web 服务器的最终实体证书)进行验证。
    Alice 的证书存储器中通常包含所需的根证书。安装 Web 浏览器时,将自动安装所有可信的 Root 证书。如果她没有根证书,则需要从证书颁发机构下载该证书并将其安装到浏览器的证书存储器内。证书颁发机构还可以是该 Web 服务器所处的设备。
    可通过以下几种方式获得中间证书:
    • 服务器本身以签名消息的方式将所需中间证书连同其最终实体证书一并发送给 Alice,这样,Alice 即可对证书链的完整性进行检查。
    • 在这些证书中,通常包含证书签发者的 URL。Alice 可通过这些 URL 加载所需的中间证书。
    在 STEP 7 中处理证书时,始终假设您已将所需中间证书和根证书导入到项目中,并已将其分配给模块。
  2. Alice 使用这些证书的公钥,对证书链中的签名进行验证。
  3. 对称密钥必须已生成并且已传送至 Web 服务器。
  4. 如果采用域名寻址 Web 服务器,则 Alice 需要根据 RFC 2818 中定义的 PKI 规则验证该 Web 服务器的身份。由于该 Web 服务器的 URL(在这种情况下,为“Fully Qualified Domain Name ”( FQDN ))保存在 Web 服务器的最终实体证书内,因此 Alice 可对该 Web 服务器的身份进行验证。如果字段“ Subject Alternative Name ”中的证书项与浏览器地址栏中的一致,则通过验证。
之后,即可通过对称密钥进行数据交换,如上图所示。

10.1.3.4.2 全局安全设置

在全局证书管理器中,简要概括了项目中使用的所有证书(例如,CA 证书),以及与证书持有者、签发方、有效性以及是否存在私钥及私钥使用情况相关的信息。若拥有相应的授权,您还可以管理项目证书。
激活全局安全设置
只有在项目中针对至少一个设备激活激活全局安全设置后,全局安全设置才可见。为此,在 CPU 特定的局部证书管理器中,提供了“使用证书管理器的全局安全设置”(Use global security settings for certificate manager) 复选框:

该复选框位于巡视窗口中带安全功能的设备常规设置的“保护和安全 > 证书管理器”(Protection & Security > Certificate manager) 下。
原理
CA 证书由证书颁发机构签发,设备证书通常由此证书而来。
证书颁发机构可以是:
  • STEP 7:如果“证书持有者”和“签发方”相同,则为自签发证书;即,由 STEP 7 签发的证书。
  • 较高级别的证书颁发机构:这些外部证书属于项目外证书,可导入和存储到 STEP 7 的证书存储器中。
由这两个证书颁发机构之一创建的证书始终有一个私钥,以便从它们可获得设备证书。
全局安全证书管理器的功能
全局安全证书管理器中提供以下功能供用户选择:
  • 导入新证书和证书颁发机构。
  • 例如,导入 SSL 证书(仅限 CP x43-1 高级版)以进行 FTP 通信。
  • 导出项目中使用的证书和证书颁发机构。
  • 更新过期的证书和证书颁发机构。
  • 替换现有证书颁发机构。
  • 添加受信证书和证书颁发机构。
手动删除导入的证书。
说明
下载组态
替换或更新证书后,必须将组态下载到相应的设备。替换或更新 CA 证书后,必须将组态下载至相应的设备。
说明
安全模块上的当前日期和时间
使用安全通信(例如 HTTPS)时,要确保相应设备具有当前时间和当前日期。否则,使用的证书将无法评估为有效,且安全通信不会工作。
激活证书管理器的全局安全设置后,必须登录全局安全设置,或者您需具备管理员权限。否则,您没有足够的用户权限来编辑全局证书。如果您不登录或者您没有足够的权限,则您无法访问全局证书管理器。
角色和权限
如果为您分配了预定义的角色“管理员”(Administrator) 或“标准”(Standard),或者为您分配了具有相关授权的其它已定义角色,则您可以组态安全设置。您可以在项目树的“全局安全设置 > 用户管理 > 角色”(Global security settings > User administration > Roles) 下查看角色,或者如果您具备相应的权限,则可对其进行编辑。
您可以通过管理员身份创建新角色和新用户,并在用户管理中为彼此分配用户和角色。
要求
您必须以管理员身份通过用户登录的方式登录到全局安全设置。
操作步骤
若要编辑用户和角色,请按照以下步骤进行操作:
  1. 在项目浏览器中,转至全局安全设置的用户管理。
  2. 选择要更改的角色或创建一个新角色。
  3. 在权限列表中编辑所选角色的权限。
可导入和导出证书以及相关的私钥。证书只能通过全局证书管理器进行导入。证书还可通过 CPU 特定的局部证书管理器进行导出。
可采用以下文件类型导入或导出证书:
  • 对于不含私钥的证书,采用的文件类型为 CER 、 DER 、 CRT 或 PEM
  • 对于包含私钥的证书,采用的文件类型为 P12 ( PKCS12 )。
要求
导入包含私钥的证书时,您可能需要访问密码。
导入证书
若要导入证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要导入的证书选择匹配表(根证书颁发机构的 CA 证书、设备证书、受信证书)。
  3. 右键单击该表,打开快捷菜单。
  4. 单击“导入”(Import)。
  5. 选择证书的导入格式:
    • 对于不含私钥的证书,格式为 CER 、 DER 、 CRT 或 PEM 。
    • 对于包含私钥的证书,格式为 P12 ( PKCS12 归档)。
  6. 单击“打开”(Open),导入证书。
必须以手动方式将导入的证书分配给所需设备或模块。
导出证书
若要导出证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要导出的证书选择匹配表(根证书颁发机构的 CA 证书、设备证书、受信证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“导出”(Export)。
  5. 选择证书的导出格式:
    • 对于不含私钥的证书,格式为 CER 、 DER 、 CRT 或 PEM 。
    • 对于采用 DER 编码的证书块列表,格式为 CRL
    • 对于包含私钥的证书,格式为 P12 ( PKCS12 归档)。
  6. 单击“保存”(Save),导出证书。
此外,还可以直接从 CPU 特定的局部证书管理器中导出证书。
可选择的文件格式
符合 RFC 5280 证书标准 X.509 V3 的 X.509 证书可使用不同的文件扩展名以不同格式导入或导出:
例如,您可以更新证书,以通过导入的证书或新证书更新损坏的证书。
操作步骤
若要更新证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要更新的证书选择匹配表(CA 证书、设备证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“更新”(Renew)。
  5. 可以在更新证书的对话框中编辑所选证书的数据。
  6. 单击“确定”(OK) 时,会使用更改后的值更新证书。
更新证书时,会使用带有新值的证书替换旧证书。通过更新证书,不会生成证书颁发机构的签名查询。
可以使用其它证书更换现有证书。
操作步骤
若要更换证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要替换的证书选择匹配表(根证书颁发机构的 CA 证书、设备证书、受信证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“更换”(Replace)。
  5. 在用于更改证书颁发机构的对话框中,可使用新证书更换项目的现有 CA 证书或 CA 组证书。
将再次衍生“涉及的证书”(Certificates involved) 表列出的所有证书。
可通过 Windows 证书对话框概览显示的所有证书数据
操作步骤
若要显示证书数据,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要显示的证书选择匹配表(根证书颁发机构的 CA 证书、设备证书、受信证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“显示”(Display)。
结果
在窗口中显示与所选证书相关的各种信息:
  • 证书的常规信息
  • 证书的详细信息
  • 证书路径的相关信息
可以删除不再需要或者已经损坏的证书。
操作步骤
若要删除证书,请按照以下步骤进行操作:
  1. 打开项目树中全局安全设置下的证书管理器。
  2. 为要删除的证书选择匹配表(根证书颁发机构的设备证书、受信证书)。
  3. 单击右键,打开所选证书的快捷菜单。
  4. 单击“删除”(Delete)。
说明
为项目预留的 CA 证书以及自动分配至 CP 的证书无法删除。
还可以直接在 CPU 特定的局部证书管理器中删除证书。证书随后会保留在项目的全局安全管理器中,但不再用于设备。

10.1.3.4.3 安全的开放式用户通信

下文章节介绍如何通过 TCP 在两个 S7-1500 CPU 之间建立安全的开放式用户通信。在该过程中,一个 S7‑1500 CPU 用作 TLS 客户端(建立主动连接),另一个 S7‑1500 CPU 用作 TLS 服务器(建立被动连接)。
在两个 S7-1500 CPU 之间建立安全 TCP 连接
为了在两个 S7‑1500 CPU 之间建立安全的 TCP 通信,需要在各个 CPU 中创建系统数据类型为 TCON_IPv4_SEC 的数据块,执行参数分配以及直接以指令进行调用。TCON 指令支持系统数据类型 TCON_QDN_SEC。
要求:
  • 两个 S7-1500 CPU 的固件版本最低为 V2.0
  • TLS 客户端和 TLS 服务器具备所需的全部证书。

TLS 客户端的设置
若要在 TLS 客户端中建立安全的 TCP 连接,请按照以下步骤进行操作:
  1. 在项目树中,创建一个全局数据块。
  2. 在该全局数据块中,定义一个数据类型为 TCON_IP_4_SEC 的变量。为此,需在“数据类型”(Data type) 字段中输入字符串“TCON_IP_V4_SEC”。
    以下示例中显示了全局数据块“Data_block_1”,其中,定义了数据类型为 TCON_IP_V4_SEC 的变量“SEC 连接 1 TLS 客户端”(SEC connection 1 TLS Client)。

  3. 在“起始值”(Start value) 列设置 TCP 连接的连接参数。例如,在“RemoteAddress”中输入 TLS 服务器的 IPv4 地址。
  4. 在“起始值”(Start value) 列设置安全通信的参数。
    • “ActivateSecureConn”:激活该连接的安全通信。如果该参数的值为 FALSE,则将忽略后面的安全参数。此时,可建立一个非安全的 TCP 或 UDP 连接。
    • “TLSServerCertRef”:自身 X.509-V3 证书的 ID。
    • “TLSClientCertRef”:例如,输入值“1”。将引用 TIA Portal 项目的 CA 证书 (SHA1)。
  5. 在程序编辑器中,创建一个 TCON 指令。
  6. 将 TCON 指令的 CONNECT 参数与 TCON_IP_V4_SEC 数据类型的变量进行互连。
TLS 服务器的设置
若要在 TLS 服务器中建立安全的 TCP 连接,请按照以下步骤进行操作:
  1. 在项目树中,创建一个全局数据块。
  2. 在该全局数据块中,定义一个 TCON_IP_V4_SEC 数据类型的变量。
    以下示例中显示了全局数据块“Data_block_1”,其中定义了数据类型为 TCON_IP_V4_SEC 的变量“SEC 连接 1 TLS 服务器”(SEC connection 1 TLS Server)。

  3. 在“起始值”(Start value) 列设置 TCP 连接的连接参数。例如,在“RemoteAddress”中输入 TLS 客户端的 IPv4 地址。
  4. 在“起始值”(Start value) 列设置安全通信的参数。
    • “ActivateSecureConn”:激活该连接的安全通信。如果该参数的值为 FALSE,则将忽略后面的安全参数。此时,可建立一个非安全的 TCP 或 UDP 连接。
    • “TLSServerReqClientCert”:要求 TLS 客户端提供 X.509-V3 证书。输入值“true”。
    • “TLSServerCertRef”:自身 X.509-V3 证书的 ID。
    • “TLSClientCertRef”:例如,输入值“1”。将引用 TIA Portal 项目的 CA 证书 (SHA1)。
  5. 在程序编辑器中,创建一个 TCON 指令。
  6. 将 TCON 指令的 CONNECT 参数与 TCON_IP_V4_SEC 数据类型的变量进行互连。
weinxin
plc入门知识问答
所有PLC工程师都会关注的微信公众账号,只需输入您的问题,就会有答案

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: