加密在车机端中有很多的使用场景。具体来说，包括充电系统在内，从车机端到CAN总线，都存在一个信息加密的需求和要
求。密钥的生成和管理是车联网安全的核心需求。
由于汽车产业升级，传统汽车厂商在向面向未来的智能网联汽车厂商转变，催生出了IVI、TBOX等带有应用（APP）和互联网访问需求的车辆端系统和随之而来的数据和网联安全需求。从这个角度来说，所有带有应用和程序处理的车端系统，实际都需要对内存、缓存的数据进行加密处理，防止泄露。
针对车端的应用，需要建立认证和访问控制，防止其他应用组件（LIB、SDK）等对本应用的资源（LIB、SDK）、缓存、内存的数据进行访问读取。而车端系统对外的访问，也是可以细分为对互联网内容请求下载、语音助手后台访问、备份后台访问、云访问、V2X的车路间、车车间互访等。这些访问都是要求互联网资源的访问，所以在链路上、后台上一定包含加密传输、对端认证的需求。除此之外，隐含的还有对硬件的加密需求，比如硬盘和新能源充电桩等。
车联网安全标准体系可以细分出很多方向，今天我们主要研究车联网安全标准中的密钥安全要求。
车联网标准中《汽车整车信息安全》是所有车联网标准中覆盖极为全面的。其中，第五章和第六章前半部分对应了R155的CSMS要求，实践了ISO21434的部分要求。第六章之后的部分为标准的技术要求，详细描述了汽车整车信息安全的技术要求。这个标准几乎涵盖了车联网安全的方方面面，解决了中国因不是R155强制缔约国造成的相对应的法规标准缺失问题。
《汽车整车信息安全》中的6.8明确了密码算法的使用和管理要求。如果未使用未采用国际通用或国家标准要求，则应说明其使用的合理性。应根据不同加密算法和场景，选择合适长度和有效期的加密密钥；使用开放的、已发布的、有效的密码算法，并选择适当的参数和选项，定期检查以采取相应措施。
这个要求明确了密码算法的密钥长度和参数应该设置合理有效，密钥算法需要未经破解且密钥算法有效期需要经常检查。
对于密码模块未采用国际通用或国家标准要求，则应说明其使用的合理性。这里针对自有密码模块或者新型密码算法模块，可以自己证明其算法的有效性，然后正常使用。
《汽车整车信息安全》中第三方应用要求的7.2.1需要应对第三方应用的真实性和完整性进行检验。这就需要车辆同第三方之间要么建立专用网络通讯（VPN），要么使用TLS1.2以上进行通信。
如果使用VPN的情况，那么一般来说无外呼使用IPSEC或者OPENVPN。IPSEC是可以使用隧道模式的加密通信技术，使用IPSEC可以实现隧道加密，保护数据通信的真实性和完整性。
一般来说，车端连接后台和服务可以考虑使用IPSEC VPN隧道模式保护。但对于车企来说，维护几十万个IPSEC VPN可能是一项繁琐冗余的成本。所以相对于IPSEC VPN，业界一般会考虑使用OPENVPN技术实现隧道化通信，一样可以保护第三方应用的真实性和完整性。
OPEN VPN基于SSL协议，可通过车机端内置配置文件轻松实现拨号握手和隧道建立，而OPENVPN的配置文件可以通过软件批量下发注入到车机端中。OPENVPN具有连接鲁棒性，而且是一种CS架构的VPN，可通过后台直接管理。OPENVPN对于车辆连接后台服务器获取升级包的操作，具有直接的实际意义。一个升级文件通过OPENVPN的隧道传输到车机端，比任何其他的OTA（update on air）方式都更具有安全性。
针对互联网资源下载的操作，也可以不使用VPN。如获取音乐视频的操作。这种下载类的操作保护数据的真实性和完整性可以通过TLS1.2实现。TLS1.2其实是一种SSL VPN，但是主要面向连接，也就是服务器和客户端这种类型，具有部署灵活，应用面广的特点。理论上存在TLS降级的风险，实际应用中，可以通过部署安全措施避免。
针对与服务平台通信的身份认证试验方法，在7.2.1中的要求还包含证书认证的方法。
证书认证本质上是使用不对称密钥进行加解密的认证方法。首先汽车厂商要生成针对认证的私钥和公钥，然后根据自己的需求填写信息生成证书，将公钥包含在证书中。该证书一般包含厂商私钥的签名。公钥认证的主要方法是针对证书的签名进行验证，包含私钥签名验证和第三方签名验证。所谓私钥签名认证是利用私钥签名公钥解的原理，对证书的私钥签名进行解密操作，验证发送信息对端的真实性。第三方签名认证需要首先第三方用私钥在证书上签名，然后使用私钥签名认证，针对该签名进行检验，从而实现第三方担保的信息发送对端的真实性。
密钥管理在7.2.1中包含两个主要点，一个是密钥的定期更新，称为安全方式定期更新。一个是密钥的安全存储。定期安全更新可以认为是更换。也就是从大方向来说，对称密钥，用于数据加密的；非对称密钥，用于数据加密和证书认证的，都需要定期更新。
此前，车厂一般会在车机端存储中开辟一块“安全地带”，用于存储“密码表”和“证书”。其中的私钥也会列在表中。这样的做法不符合车联网安全的原则。一般理论上来说私钥不适合存储在车机端中，而密码表需要硬件加密方案的保护，硬件加密也是必须的。所以对非对称密钥正确的做法是存储在后台，在企业内部通过系统申请证书和公钥，并定期进行轮换，确保私钥不会出现“长期不变”的情况。
对于对称密钥，应频繁的在不依靠之前的密钥（PFS Perfect Forward Secrecy）的条件下重新生成并采用安全算法更新到数据加密的两端，如使用（DH组 Diffie Hellman Group）或在通讯中先使用公钥建立安全连接再交换密钥。对于非对称密钥，也应该不依靠之前的密钥（PFS Perfect Forward Secrecy）并定期更新私钥和公钥对，并采用安全密钥更新算法更新到数据加密的两端，如使用（DH组 Diffie Hellman Group）。
在8.1.2中提出应对存储的密钥实施安全控制，以防止V2X 数据仿冒攻击。V2X的应用中有较为繁琐的证书应用。V2X的证书一般分为四个层次，车端路端应用到车车端之间的证书一般为假名证书。
对于车厂来说，V2X的全部技术实现一般为第三方供应商提供。所以从底层来说，根据R155的要求，首先需要对供应商的代码和服务进行审查，同时同供应商签署协议保证安全。V2X的数据仿冒攻击（女巫攻击）是以公钥钥泄露为基础的攻击形式，和数据源的认证和记录有直接关系。攻击者使用泄露的密钥生成数据，然后需要穿过数据源认证才能将篡改数据发送给到V2X的数据中。所以密钥本身的访问控制、权限管理是V2X数据仿冒攻击的第一层预防，而数据源认证是防止篡改数据进入V2X网络的第二层保证。另外通过记录也可以在审计层面帮助防止V2X数据仿冒攻击。
在10.1.2中提到车辆应安全存储加密密钥，防止其被非授权访问和获取。其中主要包含两个层面的要求。一个是加密存储的密钥应该使用硬件加密的形式安全存储。通常使用存储在TEE、SE、HSM 等安全模块，也包括安全的软件存储形式。这个要求可以很好的保存存储在车机端的对称密钥和证书，但对于非对称密钥签名证书的特殊性，还是建议将非对称密钥的私钥保存在后台，然后采用硬件加密或软件加密的方式保存。
总体来说，车联网密码安全的几个主要关注点如下。一是密钥的算法选择本身需要安全可靠算法。二是密钥的访问管理，需要具有权限控制、访问控制。三是密钥的安全存储，需要有可靠的存储区域、可信的安全存储算法。四是密钥本身的安全轮换，包含对称密钥的重新生成、对称密钥的安全分发；非对称密钥的重新生成和安全分发。
从车机端角度，可以分为三个层面：一是系统层面的密码保护，包含系统账户管理和访问控制、权限管理、密码管理。二是存储层面，加密存储数据、安全存储密钥、缓存加密、内存加密。三是通讯层面，包含资源下载加密访问、隧道加密访问后台升级、加密传输数据等。
Copyright © 2005-2021 网信安全世界版权所有