车联网通信安全之 SSL/TLS 协议

前言

在当今日益智能的汽车旅行中,我们可以实现移动遥控,打开车辆,启动通风,查看车辆周围的图像,也可以通过OTA(空中下载技术)升级机器硬件、更新地图包等。自动驾驶技术也可以使车辆根据道路的状况自动协助驾驶、加速和刹车。

然而，每次升级我们使用经验功能,存在潜在致命的安全漏洞。Tencent安全科恩实验室向外界揭示了如何使用 3/4G网络或WiFi网络,不从远处接触,入侵智能汽车,实现了车辆信号灯 、 显示屏 、 门锁及刹车的远程控制.不仅如此，攻击者甚至可以利用某些已知的漏洞来获取智能汽车的自动驾驶控制,控制车辆的方向.

因此,在构建网络平台时,我们应该充分认识到通信安全、认证、数据安全的重要性,并适当利用相关加密认证和其他技术手段提供安全。

本文将介绍SSL/TLS协议在网络通信安全中的应用,希望人们对SSL/TLS的作用有更清晰和更直观的理解。此外，我们将详细解释SSL/TLS的配置,确保每个人都正确使用SSL/TLS,实现安全性保障。

MQTTS协议用于网络安全通信

MQTTS协议基于MQTT协议,并包含基于SSL/TLS的层( 传输层安全）的加密协议，它确保终端与网络平台之间的通信是加密的。但是如果SSL/TLS不正确配置,还有许多安全风险。真正想要使用好的SSL/TLS,我们需要知道SSL/TLS已经解决了哪些问题,也有初步了解SSL/TLS中使用的加密技术。

通常,通信过程需要以下四个特性被视为安全的:保密性、完整性、认证和不可驳斥性。

机密性

保密是安全的沟通的基础,丢失机密任何听信的人都可以轻易地访问关键的隐私信息,如您的登录密码、支付密码等。实现保密的最常用的手段是加密,因此,窃听器只能获取一个毫无意义的加密数据 string,只有持有钥匙的人才能将消息恢复到正确的原始信息。根据钥匙的使用方法,加密方法可以分为对称加密和非对称加密。对称加密是指使用相同的密钥加密和解密,不对称加密是指加密和解密时使用不同的密钥。

对称加密是由于双方通信使用相同的密钥去解密,因此,不可避免地会出现一个关键的交付问题,也就是说,我需要对方能够解密我过去发送的邮件,我必须告诉对方我在加密时使用的钥匙,但如何确保与另一方同步时,钥匙不会泄露?这是对称加密密钥交付问题.

目前的通用解决方案是使用不对称加密和Diffie-Hellman键交换算法。不对称加密的核心是生成一对键.一个是公钥，一个是私钥，公钥用于加密，它是公开的，可以向任何人发送,供使用,私钥用于解密，不参与通信过程，需要被妥善保管，这解决了关键的交付问题。Diffie-Hellman Key Exchange Algorithm(英语:Diffie-Hellman Key Exchange Algorithm) 核心思想是互相通信并交换一些公共信息,以便可以计算相同的共享键。偷窃者获取这个公共信息,但无法计算相同的密钥。Diffie-Hellman算法的一个优点是没有不对称加密性能问题。尽管解决了关键交付问题,但暗号不均匀,但不对称加密算法的运行速度远远低于不对称加密算法的运行速度。它们甚至可以变小成数百倍。虽然保障了安全，但它严重影响了沟通的效率,丧失了实用性。因此,在实际应用中,对称加密和非对称加密经常结合起来。换句话说,使用伪随机数生成器生成对话键后,用公钥加密并发送给另一方,另一方接收秘密消息,用私人密钥解密会议密钥,后续 通讯 将 完全 使用 会议 键 。这解决了关键的交付问题,本文还解决了不对称加密所引起的性能问题。这种方法常被称为混合加密。

完整性

只有保密才能实现安全的通信,攻击者仍然可以篡改和伪造消息的内容,接收者无法确定消息是否来自正确的发送者,也无法确定解密后的书面声明是否没有改变。尽管针对加密文本进行改编的难度有所增加,例如,文本的数据结构在修改后很有可能受到损坏,在这种情况下,接收者很容易拒绝声明。但是,仍然存在一个可能性,即解密明消息中一些具有随机属性的字段的值在操作后会发生变化。例如,电动机速度场的值从500变为718,有几个位到位的变化,如果接收机正常接受这些消息,它可能带来意想不到的危险。

因此，我们 还 需要 在 保密 基础 上 进一步 确保 信息 的 完整性 。常见的做法是使用单向散布函数来计算消息的散布值,然后与散布值一起发送消息给接收者。单个散布函数可以确保消息的改变为1位。也有很高的概率产生不同的阵列值。因此接收器可以计算消息的散布值,然后比较接收的散射值来确定数据是否被操纵。

身份认证

但可惜的是，当攻击者同时伪造消息和相应的阵列值时,接收器仍然无法检测伪装.所以我们不仅仅是需要确认消息的完整性,还必须核查消息是否来自合法的发送者,这意味着认证也是需要的。在这一点上,我们需要使用消息认证代码,消息认证代码仍然基于单向散布函数,但它的输入除了原始信息之外,它还包括发送者和接收者之间共享的钥匙。由于消息认证代码本身并不保证消息的保密性,所以在实际使用中，非对称加密通常与消息认证代码结合,同时 满足 保密 、 完整 和 认证 的 要求,这个机制也被称为认证加密(AEAD)。具体怎么使用上，已经 提出 了 若干 方案 :

1. 加密和MAC:首先用对称密码加密消息,然后计算消息的MAC值,然后将两者结合起来发送给收件人。
2. MAC然后加密:首先计算消息的MAC值,然后同时通过对称加密加密消息和MAC值,然后发送加密的消息给接收者。
3. 然后加密MAC:首先用对称密码加密加密加密的讯息,然后计算加密的讯息的MAC值,然后将两者结合起来发送给接收者。

在很长一段时间内，SSL/TLS已经采用了第二个方案,但事实上,所有这些计划都已经证明有安全漏洞。在SSL/TLS历史中,POODLE和Lucky13攻击被用于解决MAC中的漏洞,然后加密程序。目前,行业建议使用AEAD算法,SSL/TLS 1.版本3也正式废除了其他加密方法,只支持AEAD加密。

不可否认

现在，我们保证了消息的保密,同时,它可以识别伪造和操纵,但由于消息认证代码的核心是双方共享的密钥的沟通,于是出现了新的问题,也就是说,它不能向第三方证明,也不能阻止它否认。假设鲍勃接到爱丽丝的讯息,为了向第三方证明这封信确实是由爱丽丝寄来的,你需要告诉第三方只有两个人知道的钥匙,这显然增加了继续使用这一关键通信的安全风险。同时，即使第三方得到钥匙,也无法得出有效的结论,例如,鲍勃可以声称这个消息是由爱丽丝构造的。因为爱丽丝也有同样的钥匙。

因此，我们还需要引入数字签名机制,它的原理非常类似于不对称的秘密,又正好相反。数字签名要求发件人以私钥签名消息,然后把信件和签名寄给收件人,接收器使用相应的公钥验证签名,确认合法发件人签字.因为只有持有私钥的人才能附上正确的签名,因此,发件人从不否认。公共密码只用来验证签名,所以你可以把它发送给任何你想要的人。也许这里的敏感读者心里有些疑虑,是的，获取公钥的人如何确认公钥真的来自他或她所期望的通信对象?如果攻击者假装是发送者,然后把公共钥匙交给接收机,这可以通过不破坏数字签名算法来实现。

我们已经陷入了僵局,数字签名被用来伪造、伪造和否认身份信息。但在此之前,我们必须从未被伪造的发件人手中取得未更改的公开密码。到了这一步，我们只能利用外部力量,委托认可的第三方,这就是我们现在所说的认证机构或CA,它给每个公共钥匙签名,形成公钥证书。显而易见的是，认证机构需要努力工作,以确保其私人钥匙不会被盗,确保数字签名有效性。虽然认证机构的私人密钥仍有泄漏的可能性,甚至认证机构本身也会被攻击者欺骗,我们仍然无法获得绝对的安全,但事先要相信一些知名认证机构,总是比从一个新的通讯对象中获取和信任他的公共钥匙更可靠。

以上这些密码技术，它们共同构成了现代安全通信的基石。SSL/TLS是世界上最广泛使用的加密通信方法。结合了上述的对称加密、非对称加密、消息认证代码、数字签名、伪随机数生成器等加密技术。提供通信安全。考虑到加密技术是一个不断增长的发展趋势,或者说,目前似乎可靠的加密算法,第二天可以宣布失败,因此,SSL/TLS并不强制使用某种加密技术,相反,它提供了一种叫做密码套件的机制,当密码技术发现有弱点时,它可以随时作为一部分替换,当然,先决条件是客户和服务端使用相同的密码技术。这还扩展了SSL/TLS手握协议,使用 协商 的 代码 套 是 该 协定 部分 的 主要 任务 之一 。

为了保证SSL/TLS的安全,必须避免使用被攻击或被确认为弱的加密算法,避免使用可预测的伪随机数生成器,并确保每个算法尽可能安全(短板效应)。

因此,如何正确选择密码套件也成为保障安全的重要环节。 下面,我还将简要地介绍当前推荐的加密技术和加密算法,并希望这些方法能帮助读者找到丢失的密码套件:

• 在对称加密算法中,RC4、DES和3DES已经被认为是不安全的。目前只推荐使用AES和ChaCha20。ChaCha20是一个由谷歌设计的加密算法,如果CPU或软件不支持AES指令集,ChaCha20比AES更好的性能。

• AES对称加密算法只能加密固定长度的文本.如果你想加密任何长度的文本,我们还需要使用集群模式。早期的欧洲央行、欧洲央行、欧洲央行、欧洲央行、欧洲央行和其他集团化模型都存在安全漏洞。目前建议使用GCM、CCM和Poly1305。

• 通常使用的不对称加密算法是 DH 、 RSA 和 ECC 。因为 DH 和 RSA 没有展望未来的安全,目前不推荐使用,TLS1.在3中,DH和RSA算法被直接废除,相反, 安全性和性能明显优于RSA的ECC算法.它有两个子算法，ECDHE用于钥匙交换,ECDSA用于数字签名。但需要注意的是，由于ECDHE/DHE不提供认证,因此,服务器应该启用客户端证书的验证。
• 至于散布算法,MD5和SHA-1以及我们所知的算法都被认为是不可靠的,并不能再使用。 目前建议使用SHA256或更高版本。

了解推荐的加密技术后,也许我们想修改客户端或服务端的密码套件配置,然而,现在我们可能发现这些密码套件的名称仍然很难理解。例如,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,其中,TLS只是一项协议,ECDHE代表了关键交换算法,ECDSA指认证算法,AES_256_CBC代表批发加密算法,SHA384代表消息认证代码MAC算法。这通常是TLS1.2的密码包命名格式,这是TLS1。由于TLS1.3只接受使用ECDHE算法的钥匙交换,并使用ECDSA认证,因此,它的密码包名可以简化为TLS_AES_256_GCM_SHA384格式。

从安全的角度来看,个人推荐TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384和TLS_AES_256_GCM_SHA384。然而,鉴于目前仍有许多基于RSA的证书使用,因此,我们还需要根据自己的情况选择是否继续使用TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。

建立一种典型的安全认证系统架构

基于PKI/CA的数字证书系统是解决网络安全的关键步骤,是大多数汽车公司典型的安全管理系统。

1. 基于数字证书的身份识别:通过ICP/CA系统建立严格的证书管理和使用标准,为网络应用和终端发布数字证书,结合虚拟和真实身份,解决身份识别和独特性问题(可以在一台机器或一台机器中实现);
2. 所有数据交互只由终端的身分标识识别,以证明身份标识的正确性,并防止第三方恶意入侵;
3. 基于数字证书安全功能,它提供各种功能,如身份识别、认证、数据解密、数字签名和验证,以满足网络中的多业务安全要求,如TSP和OTA。

运输网络平台安全通信交互过程,一般在运输结束时申请终端证书,在下载和完全安装后,MQTTS安全协议要求与云平台建立安全的连接。在云端,我们可以选择在云制造商的负荷平衡产品,LB层基于自建的Nginx/HAProxy或MQTT Broker层为认证识别,同时,使用 proxy_protocol v2,通过调用PKI/CA统一认证接口对机器末端的证书的ID信息、用户名密码和CN/SN信息进行唯一的认证。取得单一成员或单一类型单一成员安全认证。

MQTTS通信中单向或双向认证的配置方法

SSL/TLS连接认证认证是另一方的身份,是否是一个可靠的通讯对象,认证是基于通信对象提供的证书。在大多数情况下,客户端被认证到服务端,这就是所谓的单向认证。因此,双重认证的概念是基于单一认证,服务器验证了客户端的身份。

认证的原则其实很简单,以单向认证为例，最简单的例子是服务器在SSL/TLS手握阶段发送服务器证书,客户端验证证书是否由信任的CA机构发出,也就是说,在信任的CA证书中使用公钥来验证服务器证书中的数字签名的合法性。当然,大多数事情比这更复杂,也就是说, 服务端证书不是由最高级别的CA机构直接发出的,它由根级机构为下级机构的公开密码进行数字签名,形成中间的CA证书,这种关系是多层次的,尽可能安全地保护根证书。在大多数情况下,普通CA机构的根和中间CA证书已经嵌入到我们的操作系统中,只有在少数情况下,您需要自己添加一个可靠的CA证书。

多级证书或证书链认证过程比较复杂,但是如果我们理解上述证书签字逻辑,事实上,它很容易理解。或者以单向认证为例,如果客户端只信任根CA证书,然后,服务器需要在手握阶段将服务器证书和根证书发送到所有中间的CA证书之间。只有客户端才能获得完整的证书链,您可以通过您的根CA证书层级验证,中核证书缺乏导致不完整的证书链或中核证书中包含错误,所有这些都导致了信任链的破裂,无法认证。

如果客户端除了根CA证书之外还持有中间CA证书的一部分,服务器也可以避免在认证过程中发送这些中间CA证书,以提高握手效率。

因此，当我们配置单向认证时,您需要在服务器上指定一个服务器证书和一个中间的CA证书(optional),和服务侧私钥文件。客户端需要信任相应的根CA证书,通过CA根证书管理工具连接或添加到信任列表时,可以指定信任方法。通常客户端库还提供了一个验证选项,允许您选择是否验证证书,关闭end-to-end认证直接创建加密的TLS连接,如果证书没有验证。但是这会造成中间人袭击的安全风险,因此, strongly recommend to enable peer authentication.

在启用端到端认证后,客户端通常检查服务器证书中的域名(SAN字段或CN字段)是否与他/她连接到服务器的域名匹配。

双向身份验证的配置方法只基于单向身份验证。在服务端上,启用人对人身份验证意味着启用非双向身份验证,参照服务端证书的配置方法可以正确配置客户端证书。

通用TLS选项

当使用EMQX来配置SSL/TLS连接时,通常有一些选项,如证书文件、密钥文件等,为了帮助人们更好地理解这些选项如何配置,接下来我们将简洁的汇编和介绍这些常见的TLS选项:

• 用于指定服务端或客户端证书和中间的CA证书的证书文件,当需要指定多个证书时,通常将它们合并为一个证书文件。
• 用于指定服务端或客户端私钥文件。
• cacertfile,用于指定Root CA证书,客户端需要配置此选项来验证单向认证的服务端证书,服务端需要配置此选项来验证双向认证的客户端证书。
• 验证,以指定是否启用端到端验证。 客户端通常在启用同行认证后,会检查连接的域名是否与服务器证书中的域名匹配。
• fail_if_no_peer_cert，这是服务端的一个选项,通常在服务端被启用时用于同行身份验证,设置为错误以允许客户端不发送证书或发送空证书,它相当于同时开放的单向和双向认证,这增加了中间人攻击的风险。
• 在握手时,通信器将版本选项中指定的版本发送给另一个通信器,然后切换到两个通信器所支持的最高版本。
• 注意:避免使用上面提到的密码套件或被认为是脆弱安全的其他密码套件,在使用包含ECDSA签名算法的密码套件时,应特别注意您的证书是否属于ECC类型。
• server_name_indication，服务器名称指示，这是一个客户端选项。通常使用当客户端启用在另一端验证并连接但不匹配服务器证书中的域名的服务器域时。例如,服务器证书中的域名是 abc.com,客户端的连接是123.com,然后,当 connecting.com表明它相信域名通过证书检查时,客户端需要指定 server_name_indication 为 abc 。或者设置服务器_name_indication以禁用此检查,但这增加了中间人攻击的风险。通常不建议这样做。

示例

为了方便的演示,我们将使用EMQX(4.3.0或以上)作为服务端,使用Erlang的ssl:connect/3功能作为EMQX控制面板的客户端。

单向认证

修改EMQ X配置如下:

启动EMQ X并输入控制面板:

使用ssl:connect/3函数连接:

双向认证

为了尽快解决这个问题,这里将继续使用服务端证书作为客户证书,这将有严重的安全风险,请禁止在生产环境中使用这种证书!

修改EMQ X配置如下:

启动 EMQ X 并进入控制台，然后使用ssl:connect/3函数连接:

结语

工业及资讯科技部颁布的《网络安全及数据安全标准体系建设指引》中明确指出,建立网络安全和数据安全标准体系.在汽车网络领域,网络通信安全和数据安全将得到越来越多的关注。它是提高网络企业竞争力的关键因素之一。希望通过本文，读者可以学习如何使用SSL/TLS协议,在实际业务场景中正确应用,实现网络通信安全.

来源:网络通信安全的SSL/TLS协议 | EMQ

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/29421.html。