01.引 入
随着汽车技术的飞速发展,智能化、网联化已成为不可逆转的趋势,车辆与外界的通信和数据交换变得日益频繁且复杂。这种趋势在带来便利性的同时,也使得信息安全问题愈发凸显,成为不容忽视的挑战。
一旦车辆系统遭受黑客攻击或数据泄露,后果将不堪设想。用户的个人隐私可能因此曝光于公众视野,面临被滥用的风险。更为严重的是,车辆可能会被恶意控制,导致行驶轨迹偏离、功能失效等严重安全问题,进而对道路使用者的生命财产安全构成巨大威胁。这种潜在的危害不仅损害了用户的利益,也对整个汽车产业的健康发展造成了不利影响。
因此,加强汽车信息安全防护显得尤为迫切。我们必须采用先进的加密技术,确保数据传输过程中的机密性和完整性;制定严格的安全协议,规范数据交换的行为和流程;并引入高效的证书管理机制,验证通信双方的身份和权限。通过这些措施,我们可以确保数据的传输、存储和处理都处于安全可控的状态,从而有效防范信息安全风险。
02.应用场景
在汽车通信中,为了保证信息安全,多个场景都可以用到证书和密钥来保证通信、数据的机密性与完整性:
- 车辆与智能手机的通信
车辆与智能手机之间的通信,用于实现远程控制、状态查询、数据共享等功能。需要确保通信数据的安全性、隐私性和完整性,防止数据被泄露或篡改。证书用于验证车辆和智能手机的身份,确保通信双方都是合法的。密钥用于加密通信数据,保护数据的机密性和完整性,同时防止未经授权的访问。
- 车辆与云平台的通信
车辆与云平台之间的通信,用于实现远程监控、数据分析、软件更新等功能。很多车辆与手机的通信也要是经过云平台处理的。同样需要确保通信数据的安全性、完整性和可靠性,防止数据被窃取、篡改或伪造。证书用于验证车辆和云平台的身份,确保通信双方都是合法的。
密钥用于加密通信数据,同时防止中间人攻击等安全风险。
- 车辆内部通信
车辆内部各个 ECU 之间的通信,比如车辆通信大数据、日志等信息汇总。需要确保通信数据的真实性、完整性和实时性,防止数据被恶意攻击或篡改。
- 软件更新和固件升级(OTA)
OEM 需要定期对其生产的汽车进行软件更新和固件升级,以确保汽车的性能和安全。在这个过程中,证书和密钥可以用于确保更新和升级过程中的数据安全,同时需要密钥来验证安装包的合法性与完整性。
03.证书与密钥
证书
证书是一种由认证机构(CA)颁发的电子文档,用于证明公钥持有者的身份。它包含以下关键信息:
公钥:证书中最重要的部分,用于加密数据或验证签名。
证书持有者信息:包括证书持有者的名称、组织、国家等身份信息。
证书颁发机构(CA)信息:包括 CA 的名称、签名等,用于验证证书的真实性。
有效期:证书的有效期限,过期后需要重新颁发。
证书序列号:CA 为每个证书分配的唯一编号。
签名:CA 使用其私钥对证书内容进行的数字签名,用于验证证书未被篡改。
证书的主要作用是确保公钥与公钥持有者的身份正确匹配,防止中间人攻击等安全问题。
密钥
密钥是加密算法中使用的参数,用于对数据进行加密或解密,或对数据进行签名和验证签名。
密钥分为对称密钥和非对称密钥两种:
对称密钥:加密和解密使用相同的密钥。常见的对称加密算法包括 AES、DES 等。
非对称密钥:包括公钥和私钥一对。公钥用于加密数据或验证签名,私钥用于解密数据或生成签名。常见的非对称加密算法包括 RSA、ECC 等。
在公钥基础设施(PKI)中,非对称密钥尤其重要。公钥可以公开给任何人,而私钥必须保密。通过私钥和公钥的配对使用,可以实现数据的机密性、完整性和身份认证。
证书与密钥之间存在密切的关系:
证书包含公钥:证书是公钥的载体,用于证明公钥的合法性。
私钥用于签名:私钥用于生成数字签名,证明信息的完整性和发送者的身份。
证书验证:通过验证证书中的签名,可以确保证书未被篡改,从而验证公钥的真实性。
格式
从文件编码的角度来看,证书和密钥主要可以分为两大类格式:
一类是 PEM(Privacy Enhanced Mail)格式,它采用 Base64 ASCII 编码方式,是一种纯文本格式,便于阅读和传输,同时也便于在不同系统间进行交换和存储。
另一类是 DER(Distinguished Encoding Rules)格式,它是一种二进制格式,结构紧凑且高效,通常用于需要高效存储和传输的场景。
在实际应用中,CRT、CER、KEY 等证书和密钥文件,它们各自遵循特定的结构规范,在存储为物理文件时,可以根据需要选择 PEM 格式或 DER 格式。
具体来说,CER 格式通常用于 Windows 系统中的证书文件,它符合 Windows 系统对证书文件的特定要求。CRT 格式则更多地用于 Linux 系统中的证书,它包含了公钥和主体信息等关键内容,是 Linux 系统中常见的证书格式。而 KEY 格式则主要用于密钥文件,特别是私钥的存储,它与证书文件一一对应,共同构成了数字证书的核心部分。
打个比方来说,CER、CRT、KEY 等证书和密钥文件就像是论文、说明书等文档,它们都有各自规定的行文格式与规范。而 PEM 和 DER 格式则相当于这些文档的存储格式,就像是 txt 格式和 word 格式一样,它们决定了文档如何被存储和呈现。
此外,还有一些其他常见的证书文件格式,如 CSR(Certificate Signing Request,证书签名请求)文件。证书申请者在生成私钥的同时,也会生成一个 CSR 文件,这个文件包含了申请者的公钥和身份信息等内容。将 CSR 文件提交给证书颁发机构后,证书颁发机构会使用其根证书的私钥对 CSR 文件进行签名,从而生成一个包含公钥的证书文件,也就是颁发给用户的证书。
.key 文件则是私钥的存储格式,它与证书文件一一配对,共同构成了数字证书的基础。而.crt、.cert、.cer 等文件后缀则通常用于表示证书文件,它们可以是二进制格式的 DER 文件,也可以是文本格式的 PEM 文件。这些文件只包含证书信息,不保存私钥。一般来说,Linux 系统更倾向于使用.crt 后缀的证书文件,而 Windows 系统则更常使用.cer 后缀的证书文件。
另外,还可以将多级证书导入同一个证书文件中,形成一个包含完整证书链的证书文件。这样做的好处是可以简化证书的管理和使用,提高系统的安全性和可靠性。
最后,还有一种特殊的文件格式是.pkcs12、.p12 或.pfx 文件,它们采用二进制格式存储,同时包含了证书和私钥(通过.crt 或.cer 文件与私钥.key 文件合成)。这些文件通常会有密码保护,以确保私钥的安全性。
04.通信加密:SSL 单向认证
SSL 单向认证主要是车辆客户端去验证服务器的合法性,这个过程服务器需要 CA 证书、server 证书、server 私钥,客户端需要 CA 证书。
整个过程可以参考下图:
SSL 单向认证流程
在 SSL 单向认证过程中,首先客户端向服务器发起 HTTPS 连接请求,并附上自身支持的 SSL/TLS 协议版本、对称加密算法列表及生成的随机数 A;接着服务器回应,确认双方支持的协议版本和加密算法,并附上自身的安全证书(含公钥)及生成的随机数 B;然后客户端验证服务器证书的有效性,包括检查证书是否过期、是否被吊销、是否可信以及证书域名与请求域名是否一致,验证通过后,客户端生成一个预主密钥(随机数 C),使用服务器证书中的公钥加密后发送给服务器;最后服务器使用私钥解密得到预主密钥,双方基于这三个随机数通过相同密钥交换算法计算出相同的对称加密密钥,用于后续的数据加密通信。在此过程中,仅服务器进行身份验证,客户端无需提供证书。
05.通信加密:SSL 双向认证
SSL 双向认证是验证服务器和车辆客户端的合法性,服务器需要 CA 证书、server 证书、server 私钥,客户端需要 CA 证书,client 证书、client 私钥。
整个过程可以参考下图:
SSL 双向认证流程
车辆作为客户端向服务器发送 SSL 连接请求,服务器返回包含公钥和证书颁发机构信息的数字证书给客户端,车辆客户端验证该证书的有效性和真实性后,生成一个随机密钥用服务器的公钥加密发送给服务器,服务器解密得到密钥后,服务器也会要求车辆客户端发送其证书,车辆客户端发送后服务器验证其合法性和有效性,确认双方身份后,双方使用该密钥进行加密通信,从而确保通信的安全性和真实性。
06.加签与验签
加签与验签最经典的则是对 OTA 数据包的处理,车辆云平台下发数据包前对其进行加签,再经过双向验证的加密通道将数据下发到车辆端,车端在执行升级前需要经过对其的验签过程,以保证数据包的完整性。
加签原理
加签,发送方会先对数据进行加密,生成一个独特的数字签名,随后将这个签名与原始数据捆绑在一起,一并发送给接收方。这里的数字签名,实质上是一个基于特定加密算法计算得出的值,它的生成离不开私钥的参与,而验证其真实性时,则需借助相应的公钥。
加签流程大致可以分为以下四个步骤:
第一步,选择哈希算法。这一步骤至关重要,因为哈希算法将直接用于生成原始数据的哈希值。哈希值,作为一个固定长度的字符串,能够唯一地代表输入数据,确保数据的唯一性和不可篡改性。
第二步,计算哈希值。发送方会利用选定的哈希算法,对原始数据进行哈希运算,从而生成一个哈希值。
第三步,使用私钥加密哈希值。为了生成数字签名,发送方会运用其私钥,对之前计算得出的哈希值进行加密处理。
第四步,发送数据与数字签名。最后,发送方会将原始数据和加密后的数字签名一同发送给接收方,以供后续验证使用。
验签原理
验签,则是接收方在收到数据后,为确保数据的完整性和真实性而采取的一系列验证措施。这一过程同样离不开发送方的公钥。
验签流程同样包含四个关键步骤:
第一步,选择哈希算法。接收方需要选择与发送方相同的哈希算法,以确保后续哈希值计算的一致性。
第二步,计算哈希值。接收方会利用选定的哈希算法,对接收到的原始数据进行哈希运算,得出一个哈希值。
第三步,使用公钥解密数字签名。为了验证数字签名的真实性,接收方会运用发送方的公钥,对接收到的数字签名进行解密处理,从而得到解密后的哈希值。
第四步,比较哈希值。最后,接收方会将解密后的哈希值与自己计算得出的哈希值进行对比。如果两者完全吻合,那么就可以断定数据在传输过程中保持完整,且未被篡改。这一过程确保了数据的真实性和可靠性。
07.证书密钥配置模拟
本小节使用 openssl 模拟演示下后台服务器端及车辆端的证书和密钥的生成
CA 私钥与证书
可使用下述指令生成私钥,来模拟 CA 私钥;
openssl genrsa -out rs_pri.pem 512
可使用下述指令生成证书,来模拟 CA 证书,在这个过程需要填写机构的信息:
openssl req -new -x509 -key rs_pri.pem -out cacert.pem -days 3650
查看证书内容:
服务器的配置
先利用上述指令生成服务器的私钥:server.pem;
再使用服务器的私钥生成服务器的 CSR:server.csr
使用 CA 证书签署服务器证书:server.crt
openssl x509 -req -days 36500 -sha256 -CA cacert.pem -CAkey rs_pri.pem -CAcreateserial -in server.csr -out server.crt
车辆客户端配置
车辆的 ECU 通常会内置云平台提供的 CA 证书,在 ECU 第一次通电、联网时,生成私钥以及 CSR,通过 PKI 流程向云平台,也就是服务器端申请公钥证书,服务器生成后会返回给车辆端,本次测试直接生成了,忽略 PKI 申请流程:
$ openssl genrsa -out client.pem 512
$ openssl req -new -sha256 -key client.pem -out client.csr
$ openssl x509 -req -days 36500 -sha256 -CA cacert.pem -CAkey rs_pri.pem -CAcreateserial -in client.csr -out client.crt
车辆客户端申请下来的公钥证书与后台服务端的证书内容对比大概如下:
SSL 双向验证比单向验证多的就是服务端要验证车辆端的合法性,就是验证公钥证书中的时间有效期、包含的身份信息、签发机构等信息。
END
作者:不可说
来源:汽车电子与软件
推荐阅读:
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。)