学术|制造研究ACADEMIC
（2）平台数据完整性：保存在云平台的数据应当具备完整性，不被恶意破坏，不应出现因硬件、软件等外部条件造成数据的丢失、错误。
（3）平台数据的可恢复性：用户对存储在云平台的数据进行访问时，需要无差错响应用户的请求。如果遇到安全攻击事件，应能够保证数据的可恢复性，防止因数据丢失造成的巨大损失。（4）平台数据安全方法：云平台数据安全应采用体系化的信息安全建设，从物理、网络、计算、存储、信息和应用等方面构建信息安全防御体系，并在管理方面将信息安全纳入到考虑范围，以降低数据泄漏等安全风险。
（5）车载终端数据存储：由于固件代码保存在具有永久存储功能的器件中，应考虑其是否支持加密算法，芯片中是否有保护寄存器，以及是否可以通过设置Read-only等模式对固件存储进行保护。可以增加微处理器或者微处理器内部自带的固件存储单元的固件提取难度，同时减少或禁用ECU上的JTAG、RS232和USB等对外调试接口，减少固件被读取的危险。
2.1.3 密钥安全
（1）APP安全防护：当前大多数汽车APP缺乏软件防护和安全保障，通过逆向攻击就可以看到TSP接口、参数等信息，存放在APP中的密钥、控制接口等信息均易被获取[6]，因此，应当对移动APP进行有效的防护。关于密钥的存储，由于大部分手机都没有内置eSE芯片，可采用软件白盒的方式，通过软件白盒保证数据存储和传输安全。
（2）密钥存储：可能发生白盒攻击。当前主流方式是软件白盒和硬件eSE芯片方案，将密钥通过预制或动态下发的方式存储在白盒或者eSE芯片中，这样可以有效防止白盒攻击。数据在传输的过程中也要经过白盒或eSE芯片加密后进行，保障数据的传输安全[7]。
2.2功能安全
功能安全是为防止汽车在远程升级过程中，由于意外发生造成车辆无法行驶或短时间内无法恢复的情况发生，可将其视为冗余设计[8]。
2.2.1 防变砖机制
在多个节点的情况下，远程升级时需对升级目标进行校验，防止升级错误。此外，升级管控程序需始终保证自身的可运行性，即使在升级失败的情况下，升级管控程序仍然能够保证升级可重复进行或通过调用相应的接口回滚至原版本。
2.2.2 掉电保护
系统应防止升级过程中意外掉电，掉电恢复后会自动由Boot 进入升级管理程序，从掉电处继续完成覆盖的过程。
2.2.3 回滚机制
对于软件本身存在的问题或多次无法升级成功，升级管理程序可调用特定接口，控制系统回滚至上一个版本。
2.2.4 断点续传
系统具备断网保护机制，在网络中断时记录下载点，在网络状态恢复时从未完成处继续下载。
2.3 一般性功能要求
2.3.1 升级策略
可按照时间、地区和设备数量等信息动态调整升级策略，即针对某一生产批次、某一地区和一定数量的车辆进行全时段的远程升级设定，具备动态调整能力，适应不同场景下的要求。
汽车诊断仪2.3.2 各节点要求
各节点除满足上述的信息安全和功能安全外，车载ECU、云平台和APP还应满足关于自身特殊的要求。
（1）车载ECU。车载ECU应具备Bootloader的功能，Bootloader应置于非易丢失存储区，并受到保护，禁止对其地址区进行任意修改。此外，车载ECU远程升级时需要配合安全升级机制，通过数字签名和认证机制确保固件的完整性和合法
性，对于非法固件禁止进行升级。再者，车载ECU在接收车载终端传输更新文件或更新命令时，应能够及时校验车载终端身份及权限，即对设备合法性进行认证。
（2）云平台。在软件升级过程中，云平台应能正确验证车载终端身份，识别出伪造终端，或者高风险链接链路[9]。此外，通过车载终端或其他方式采集上传到云平台中的数据，由于会涉及到车主车辆相关的私密数据，云平台需要设置访问权限，并对数据进行加密存储，以保证存储的用户隐私信息不被泄露。保存在云平台的数据还应当具备完整性，不被恶意破坏，不应出现因硬件、软件等外部条件造成数据的丢失、错误。
（3）APP。APP应当能直观将远程升级过程中相应的安装进度、安装历史等信息直观反馈给用户。此外，APP具备一般商用APP的通用特点，如密码回、注册和重置等。并且，APP还应能远程管理车载终端中已经下载的固件。
发布评论