欢迎光临第五届中国汽车网络信息安全峰会2020!

豆荚科技谈车联网信息安全

发布日期:2020-08-15

GRCCIoVSecurity

2020-08-14 10:44:28

手机阅读

点击上方蓝色字体,关注我们

概述

伴随着车联网技术的飞速发展,其所面临的信息安全威胁日渐凸显,已引起学术界、工业界和政府部门的高度关注。作为在智能交通车载中具有典型性和先进性的车联网,较之传统的互联网,因其应用环境更加特殊、组网更加复杂、管理更加困难,其安全威胁更加突出。

 

根据不同的通信节点,可将其通信模式分为车与车(V2V)通信,车与路(V2I)通信,车与其他节点的混合通信(V2X)。车联网的出现让汽车使用者可以随时随地享受互联服务带来的便捷,同时也伴生了一系列安全问题:从数据角度出发,包括数据采集、数据运算、数据传输、数据使用、数据保存提出车联网的安全架构,重点从APP应用、算法、链路连接、安全存储、车域网、车载自组网和车载移动互联网安全,7个方面分析和面临的安全威胁。 

 

重要性:

安全可以说是一切事物的基础,没有安全作为保障,一切都是空谈,车联网也不例外。车联网可以使我们更容易的在车辆中获取各种信息,可以使我们提前知晓前方路况,同时车联网也是安全自动驾驶实现的重要前提。尽管车联网将给我们未来的汽车生活带来无尽的便利,但是不可否认的是车联网也会给我们带来一系列的新增风险和潜在威胁。如果车联网不安全了,可想而知,后果是很严重的,互联网被黑客攻击,导致大面积电脑瘫痪,如果车联网被黑客攻击了,往小了说,会造成严重的交通都塞,整个区域交通瘫痪;往大了说,电影《速度与激情8》里操作整个停车场所有车辆的镜头并非不可能出现。

 

现状:

近年来,车联网信息安全事件频发,国内外专家、学者与致力于车联网安全邻域的工程师们不断挖掘安全漏洞,竭尽全力完善漏洞技术。

  • 2015年两位美国黑客远程破解并控制了克莱斯勒的JEEP汽车,克莱斯勒因此召回了140万辆汽车,损失巨大;

  • 同年国内某汽车厂商的云服务也曾被爆存在漏洞,可导致车主信息泄露和汽车被远程控制;

  • 欧洲两所大学的研究人员表示,通过无线模块和天线,可以跟踪一个小城市里的所有车辆,跟踪成本不足50万美元;

  • 2017年伊始,车联网的安全由车辆安全转至用户的数据安全和隐私安全。6月,美国某经销商集团数据库遭到攻击,涉及多个品牌超过1000万辆汽车的销售数据泄露。12月,日产汽车官方宣布旗下的金融公司数据库数据信息遭到黑客窃取,客户的个人信息、贷款信息等都在窃取范围内。

  • 2019年特斯拉Model S入侵事件,黑客们仅通过远程入侵,就可以控制车辆的终端系统,通过Model S存在的漏洞打开车门并开走,此外还能向Model S发送“自杀”命令,在车辆正常行驶中突然关闭系统引擎。

 

纵观近些年的车联网信息安全事件,不难看出安全威胁在一点点升级,无规律可言,各个环节、各个节点都存在着安全漏洞,所以说车联网安全必须从底层硬件开始,到最终用户的应用层都要做到比安全还要安全的解决方案,底层由安全硬件HSM/SE等做最基础安全的支撑,应用层从用户的行为习惯到可信环境的保护等。由此可见,车联网的安全威胁贯穿整个安全架构,每个层级、节点都面临着众多问题,车联网安全形势有待改善,另外传统车厂对车联网安全风险识别和管理都处于起步阶段。

 

问题总结:

通过对这些事件进行分类总结,车联网信息安全问题主要集中在以下几个方面:

 

(一)汽车电子系统自身安全

HUT、T-BOX、OBD、CAN总线、ECU、传感器、多功能数字钥匙存在访问控制、非法启动、芯片漏洞、无身份认证、无硬件加密方式、算法未及时更新、通信未隔离以及远程升级漏洞等问题。


(二)远程云服务平台安全

TSP服务器、PKI服务器、OTA服务器等系统层存在漏洞,云与云,云与端的通信链路未做访问控制策略、算法未及时更新以及公网传输安全的问题已经多次出现。

  

(三)终端控制应用的安全 

移动APP成为车联网的窗口,由于开发成本低,工程师上手快和android系统本身漏洞多等特点,很容易通过技术手段破解通信秘钥、分析通信协议,并结合车联网远程控制功能干扰用户使用,同时也可对IVI进行攻击,渗透攻击车联网控制关键部件,同时移动APP用有云端的密码和账号,获取后存在安全威胁,移动终端安全间接影响车联网安全。

 

(四)敏感数据保护

目前车联网所能提供的服务正呈现快速的扩张发展,但是在隐私保护问题上并没有紧跟发展的步伐。连接互联网汽车的辅助驾驶应用可以监视驾驶员的活动,收集用户敏感信息。例如,刷脸支付,ETC辅助系统可以采集用户生物数据与银行账户敏感信息;车载导航系统服务在开通之前需要用户接受车辆位置信息反馈的条款,目的就是采集用户的位置信息,判断用户的物理位置。所以,信息安全是车联网发展的首要解决问题,信息安全技术也受到汽车领域的重视。

 

围绕车的信息安全,国际上有车联网联盟(CCC)规范,以及SAEJ3061的相关规范。ISO&SAE 21434汽车网络安全标准也在起草中。欧盟《通用数据保护条例》(GDPR)以及我国的等保2.0安全规范也都对车联网的信息安全做了相关的规定。


如下我们将就车联网信息安全中的一些技术内容与大家分期讨论。

 

目录:

1:基于TEE的TBOX安全技术

2:这么做让APP更安全

3:车联网后台安全方案

4:基于ECU微小算法---Simon与Speck

5:低配置安全存储---SHE

6:android安全相关基础知识

7:国密与其他算法的区别

8:TLS1.3比TLS1.2更安全在哪里?

9:可信执行环境(TEE)

10:没有办法的办法---白盒

11:关键ECU(HUT/GW)安全log的标准、存储和擦除

12:SecOC

13:FOTA

14:数字钥匙



基于TEE的TBOX安全技术


TBOX面临的安全威胁

车载终端TBOX(Telematics BOX),是具备数据输入输出、数据存储、计算处理以及通信等功能的车联网控制单元。TBOX与主机通过CAN总线通信,实现对车辆状态信息、控制指令、远程诊断和按键状态信息等的传递;以数据链路的方式通过后台TSP系统与PC端网页或移动端App实现双向通信。车机要联网必须有TBOX设备才能实现。

TBOX在车联网的位置:

TBOX通常采用MCU芯片上跑一个Android操作系统,搭配通信模块、GPS天线、4G天线、数据接口等外设、以及相关的应用软件。从TBOX的构成和作用,我们不难分析出其安全威胁主要来自于以下几个方面:

  • 操作系统安全威胁

类似Android这类操作系统被称为REE(富执行环境),由于本身的开放性,不具备secure boot和信任链条,注定其是非安全的操作系统。对于REE系统的文件和系统数据被窃取或篡改,用户敏感数据被窃取或篡改,操作系统的运行被非授权干扰或中断,各种攻击方式屡见不鲜。

  • 软件安全威胁

基于REE实现的App应用软件,不具有隔离性。应用软件源码或敏感数据极易被非授权访问,组件因为暴露在开放环境,很容易被攻击调用。应用软件的启动、升级和退出过程也都非常容易受到非授权干扰或中断。

  • 数据安全威胁

开放OS中,收集的数据没有基于硬件的防护,极易被拦截或篡改。数据在传输过程中被窃取或篡改,恶意数据在传输环节中被注入,在数据被用户删除后未彻底清除或未设置防回滚保护,导致数据被窃取作为攻击样本。

  • 通信安全威胁

数据通信没有信任链,总线数据和私有协议被非授权的攻击者读取,车载TBOX与TSP间通信被嗅探或攻击,使通信数据被窃取或篡改。

TEE是什么

TEE(Trusted Execution Environment 可信执行环境)最早出自于OMTP规范,ARM是TEE技术的主导者之一,其TrustZone即为是ARM公司的TEE的实现。TEE的目的增强移动设备的安全特性,从而研发的包括软件编程接口、硬件IP在内的一整套方案。芯片在软件和硬件上,有REE和TEE两个区域,分别对应富执行环境和可信执行环境。其主要思想就是在同一个CPU芯片上,通过硬件配置方式实现不同IP组件的访问控制,从而提供一个完全隔离的运行空间。ARM在芯片IP设计中已经全面支持了TEE,包括高通、联发科、三星、海思、NXP等芯片厂商都纷纷采用该架构,已经成为基于硬件安全的主流方案。

GlobalPlatform TEE 架构图:



















关于TEE的安全技术和实现,我们将会在后续有专门的章节说明,此处我们简单介绍一下TEE具备的特性。

  • 受硬件机制保护:TEE隔离于REE、只能通过特定的入口与TEE通信、并不规定某一种硬件实现方法,隔离更彻底。

  • 使用Trustzone硬件机制对外设、存储进行安全保护,且该机制仅能受控于TEE。

  • 高性能:TEE运行时使用CPU的全部性能(独占),算力足(支持国密)。

  • 快速通信机制:TEE可以访问REE的内存、REE无法访问受硬件保护的TEE内存,TEE的RAM充足。

  • TEE具有更高的特权等级。

  • TEE作为开放技术,适合标准化。目前已有GlobalPlatform(GP)标准化,可在多种平台上移植。

  • TEE擅长节点逻辑保护、外设保护、存储保护。

  • TEE中的可执行代码在执行前先要被验证(validate)。

  • 对于密钥使用安全存储机制:认证性、完整性和机密性。

基于TEE的TBOX安全方案

既然芯片上已经有了Trustzone安全设计,那么利用Trustzone上的TEE安全系统来保护TBOX,当然就会成为必然。实际上,基于TEE的TBOX安全方案已经被越来越多的OEM采用,一些TBOX相关的安全规范也正在制定中。相信随着车联网信息安全越来越受到关注,基于硬件隔离的TEE安全技术,将成为刚需。

让我们以豆荚科技公司基于TEE的TBOX安全方案为例,分析一下为什么有了TEE的TBOX更加安全。

我们可以看到,在方案中,基于TEE的安全操作系统的系统防御形成了一条安全信任链条。每一步处理都是基于这个信任链进行认证和校验,保证了系统、应用、业务、数据、通信的安全。

  • 系统安全启动

TEE的secure boot(安全启动)功能旨在保证设备软件(从硬件信任根直到系统分区)的完整性。在启动过程中,无论是在哪个阶段,都会在进入下一个阶段之前先验证下一个阶段的完整性和真实性。此过程需要绑定的信任根,也就是ROOT OF TRUST。确保BOOT ROM -> Preloader -> LK -> TEE -> BOOT启动流程安全可靠。只有具备了安全启动,安全的OTA才成为可能。

  • 应用安全

在TEE上运行的应用叫做可信应用TA(Trusted Application),TA之间实现完全的隔离,两个TA之间无法访问对方资源。而且TA的装载和调用都必须通过签名校验的过程,从而达到防篡改、防钓鱼、防重放攻击的目的。对于不同的应用来说,可以将需要安全处理的部分放在TA中执行,以此来保证应用的安全。

实际上在手机上的高安全应用如支付类应用(支付宝、微信)、生物识别应用以及DRM应用都是需要TEE的安全保护的,这在手机应用中已经成为标准。同理,在车联网的环境下,随着生物识别、支付、控车等应用场景的出现,TEE的保护无疑将成为高安全应用的**选择。

  • 硬件加解密功能

重要数据、敏感数据的保存需要加密,服务器和设备终端的信息传递需要验签名,安全应用(TA)镜像需要验证完整性和机密性。TEE基于芯片硬件的加解密算法,支持各类对称加密、非对称加密、国密算法、签名认证、HASH计算、MAC算法等,可利用芯片内置安全密钥,对数据做加解密处理。

  • 安全存储功能

重要数据(包括配置信息)保存需要加密安全存储,对于密钥等小型敏感数据,可通过TEE的安全存储功能保存在TEE安全端,确保密钥不出安全模块,REE侧无法访问,提高系统安全性。

对于较大的文件按可先经过TEE侧加密后,然后通过REE侧的文件系统,以文件形式保存,由于加密的密钥不出TEE,其安全级别大大提高。

  • 双向认证

云与端之间信息通信的安全,最重要的是服务器和终端设备之间的双向认证机制。如果终端密钥管理放在REE侧,那么是非常容易泄露的,端的安全就是无源之本。而TEE的出现,可以将端的唯一标识和相关密钥管理放在TEE侧作为安全存储,密钥不出TEE,确保整个验证流程安全可靠。

从车载终端设备安全考虑,TEE很好的解决了安全启动、安全更新、数据保护、密钥存储、身份识别、安全通讯等车载安全的主要问题。当然,汽车正在往电动化、智能化、网联化、共享化的方向快速发展,同时也面临着严峻的信息安全挑战。汽车系统安全问题无法通过单一技术方案解决,必须实施多位一体的安全方案,下一回我们将分析一下车载APP的安全,敬请关注。

这么做让车载APP更安全



背景

我们的生活、工作、学习都正在被数字化、移动化。智能手机的普及推动了手机APP的快速发展,小到沟通聊天、车票预定,大到银行理财、支付交易,各种APP层出不穷。人们对APP的功能性、多样性的积极态度远远超出了对信息安全的担忧,APP的安全方面并没有得到很好的保证,通过APP导致的信息安全事件,经常被爆出。正在兴起的车联网也未能幸免,据统计车联网信息安全约50%安全漏洞、风险,来自于车载APP。针对APP的设计与研发,需要对信息安全高度重视,做到杜渐防萌,确保用户敏感数据的安全。

车载APP攻击手段

  • 静态分析

静态分析指的是对APP安装文件的安全漏洞检测。首先获得应用程序安装包文件,即APK文件,然后通过逆向工具(如APKIDE、Dex2Jar等)进行反编译,将APK文件逆向为Java源文件或JAR文件,对其进行源代码级的解析。

常见的Java层逆向工具:Android Killer和APKIDE

Android Killer是一款可以对APK文件进行反编译的可视化工具,它能够对反编译后的Smali文件进行修改,并将修改后的文件重新进行打包形成APK文件。一旦APK文件被逆向,那么很容易对其进行篡改和注入攻击。

APKIDE也是可视化的、用于修改安卓APK文件的工具。该工具集成了 ApkTool,Dex2jar,JD-GUI 等APK修改工具,集APK反编译、APK打包、APK签名为一体,是非常便利的 APK 修改工具。

常见的NATIVE层逆向工具:IDA pro

IDA pro以其强大的功能和众多的插件成为了很多逆向分析师的**。IDA pro是商业产品。使用IDA反汇编二进制文件的目的,是利用工具得到反汇编之后的伪代码,另外,再结合file 、readelf等指令使用,可以说如虎傅翼,准确还原出源代码并非难事。

以上是Java层和Native层逆向的常用方法。静态分析的优点是无需运行代码,无需像动态分析那样改写Android系统源码,或要求用户对Android系统进行重定制和安装定制版的ROM,因此静态分析具有速度快、轻量级的优点。但是静态分析的缺点是因为无法真实模拟程序的动态运行,所以存在误报率高的问题。

  • 动态分析

由于静态分析难以满足安全人员的分析要求,天生对软件加固、混淆免疫的动态分析技术应运而生。相对于轻量级的静态分析,动态分析则是重量级的程序运行时的分析。在一般情形,需对Android系统进行重新定制与改写,包括改写安全机制;在原生Android系统中加入监视器,实时监视数据的流向;在危险函数调用时,检测所需权限等。

常见的动态分析的工具:TaintDroid

TaintDroid是变量级和方法级的污点跟踪技术工具,可对敏感数据进行污点标记,污点数据在通过程序变量、方法、文件和进程间通信等途径扩散时,对其进行跟踪审查。如果污点数据在一个泄露点(如网络接口)离开系统, TaintDroid就在日志中记录数据标记、传输数据的应用程序和数据目的地,实现对多种敏感数据泄露源点的追踪。

动态分析的优点是,检测精度较高,缺点是需要修改Android系统源码,形成用户全新裁剪的操作系统,同时需要通过更新ROM安装这种定制系统。另外还有代码覆盖率低,执行效率低下等,但是瑕不掩瑜,个人认为熟悉各种动态分析技术的核心原理也应当是安全从业人员的必备要求。

  • 其他攻击手段

恶意软件攻击:最**的三大AndroidRootExploit恶意软件是Zimperlich、Exploid和RATC(RageAgainstTheCage)。恶意软件的核心原理是砸壳或解密,然后发起“rootexploit”攻击,通过非法手段获取根权限。

提权攻击:指没有任何权限的恶意程序能够通过第三方合法APP获得所需的权限,或者说一个拥有较低(较少)权限的应用程序访问拥有较高(较多)权限的组件而不受任何限制。

中间人攻击(MITM):顾名思义,攻击者插入到原本直接通讯的双方,让双方以为还在直接跟对方通讯,但实际上双方的通讯对方已变成了中间人,信息已经是被中间人获取或篡改。

 

 

车载APP安全方案

  • APP合法性

一般情况下,车厂对自己放在应用市场的APP都有严格的审查策略、验签名机制、***ID的管理,以此来确保APP的合法性。如下是一个简单的APP生产流程图:

 

 

  1. 车厂委托APP供应商开发APP应用;

  2. APP供应商登陆车厂的***中心申请开发用的证书;

  3. 车厂将APP供应商开发完成的APP,推送到应用市场后台;

  4. 汽车用户到车厂专属的应用商店,下载自己想要的APP。


  • APP研发阶段安全策略

API接口

检查所有jar包,特别是引用第三方jar包时,一定要做接口是否安全分析,并做代码扫描,自行开发的jar包、War包需要加密处理,防止反编译、防止逆向工程。如果SO库文件的话,源代码需要进行混淆处理,增强反编译的难度。另外,对混淆策略做评估分析,防止APP性能有明显下降;同时,SO库文件还需要进行加壳处理,使SO文件无法正确反编译和反汇编。另外,API接口还需要授权绑定,防止API接口被非授权应用调用运行。

功能测试报告

APP开发过程中,单元测试报告,结合测试报告,代码review记录。

性能测试报告

关注的参数有:CPU,内存,耗电量,流量,FPS,APP的安装耗时和启动耗时。

自身安全

通过静态分析技术,识别APP自身存在的恶意行为、敏感权限、病毒木马等风险。

防代码逆向

覆盖Java、C、C++、C#、Lua、JavaScript代码,识别每项代码防逆向工程的自我保护能力。

防动态攻击

**真机运行模式,模拟调试、内存dump、注入Hook等攻击,检测APP的自我动态防御能力。

  • 本地数据

通过静态分析技术,检测APP是否存在明文密钥、证书、敏感数据、开发日志等信息。

如果条件允许的话,采用安全执行环境TEE/SE方案(SE成本更高些),密钥生成和密钥保存都放到TEE/SE可信环境下完成,来保证本地数据的安全。

如果无法采用安全执行环境方案的话,密钥的生产用key2code完成,保证密钥的安全,从而保证本地数据的安全。本地数据不管是用文件、SQLite保存都要加密保存,加密算法根据实际情况拟定,因为APP加密的数据需要到云端解密,所以需要云与端都支持的算法才行,目前传统车厂算法库是存在没有及时更新的风险的。

  • 安全UI

安全UI在支付场景下,被规范严格要求的是安全键盘。通常要求实时加密通过安全键盘的信息,隐藏键盘回显,按键水印等信息,防止第三方键盘或者系统键盘安全级别无法掌控等风险。推荐采用TEE方案的TUI,键盘的描画与输入均在TEE侧完成,可做到安全显示、安全输入、安全指示,达到防止截屏/录屏,防止数据收集,防钓鱼的目的,确保数据更安全。

由于技术具有一定的复杂度,目前还没有车厂采用基于TEE的TUI方案。目前国内的安全UI实现大多仍然是采用基于白盒加密的实现。但是在手机上金融级别的安全应用,已经使用了基于TEE的TUI实现。

 

  • 身份认证

应对登录的用户进行身份标识和鉴别,检验APP是否具备抵达认证风险的能力。

  • 通信数据

对网络通信HTTP、HTTPS等协议进行安全检测,及时发现潜在的安全漏洞,目前云与端通信基本都是SSL/TLS1.2协议、双向认证,确保云端链路的安全。如果可以的话,应升级到TLS1.3。原因与技术细节之后我们将在专门章节进行交流。

  • 内部数据

针对APP常用组件的配置进行检测,及时发现潜在的安全漏洞,避免数据泄漏问题。

  • 恶意漏洞

定期更新应用漏洞,及时发现安全风险,预警开发人员。

  • 恶意行为检测上传

车载APP安全策略除了数据加密、代码混淆、反调试等主动防护外,还需要采用动态检测 APP 异常信息,主动上报车机设备信息、调试器信息、是否越狱、修改器信息、hook 工具信息、加速器信息、外挂工具信息、攻击框架信息等恶意行为到云端服务器(车厂负责管理),作为业务风控参考指标。当APP遭受注入、调试、篡改、重签名等非法攻击行为时,云端服务器会警告用户、封号、冻结APP、甚至禁止车辆使用。


车联网后台安全方案



车联网后台,指的是相对于车端的,车联网的云平台系统。本篇我们讨论的就是车联网平台的安全方案。

车联网平台

车联网平台是提供车辆管理与信息服务的云端平台,负责车辆及相关设备信息的汇聚、计算、监控和管理;提供智能交通管控、远程诊断、电子呼叫中心、道理救援等车辆管理服务,以及天气预报、信息资讯等内容服务。

车联网平台安全现状及威胁

 

从上图可以看出车联网平台在车联网架构中的位置和作用。由于车联网平台都是基于云计算技术,云计算本身的安全问题会被引入到平台中;此外,平台也需要接入互联网,那么互联网相关的安全问题也需要关注;平台主机也需要运行操作系统,操作系统本身的漏洞带来的安全问题,平台也必须兼顾。

车联网平台常见安全策略及防护措施

  • 操作系统

车联网平台主机运行的操作系统,如:Linux、AIX等。都需要针对自己平台的业务进行裁剪,各个模块资源分配、业务量峰值、数据库的选择等。为什么需要裁剪的原因与技术细节之后我们将在专门章节进行交流。

  • 用户管理

根据用户的角色分配权限,仅授予用户所需的最小权限,做到专人专号。此外,用户登录口令随机生成20位以上、至少4种字符构成,并对口令生效日期进行记录,三个月更换一次口令;特殊口令由于不能修改的,密码强度要求随机生成30位以上,至少4种字符构成。

  • 敏感数据保护

敏感数据保护有两个方面,一方面是针对敏感数据的访问使用白名单控制,非白名单,连接端口均通过DDoS、WAF过滤;另一方面,也是关键点,则是要使用APN进行网络隔离。一般常配备有三个APN接入网络,三个APN的功能描述如下:

  • APN1负责与非车业务的交互通信;

  • APN2负责车辆控制通信,主要传输汽车控制指令等敏感数据,由于安全级别较高,仅可访问可信白名单中的IP地址,避免受到攻击者干扰;

  • APN3 负责车载娱乐通信等,主要访问公共互联网信息娱乐资源,如天气预报、新闻等。

车辆控制和车载娱乐采用隔离的方式来加强敏感数据保护,彼此之间网络完全隔离,形成三个不同安全等级的安全域,避免越权访问;同时,不同安全级别数据存储相互隔离,防止系统同时访问多个网络,避免数据交叉传播。

APN私网与云服务之间的访问通过硬件防火墙,过滤数据流,防范设备异常导致的流量异常、访问异常;管理访问通过白名单形式,单一授权;敏感数据传输通过APN2在车辆控制域中加密传输,避免外泄。加强数据使用限制,车联网数据仅作为内部数据使用,用于车辆故障诊断,拒绝与任何第三方共享用户数据,尽可能确保用户私密数据安全可控。

  • 堡垒机

堡垒机提供了一套多维度的运维操作管控与审计解决方案,使得管理人员可以全面对各种资源(如网络设备、服务器、安全设备和数据库等)进行集中账号管理、细粒度的权限管理和访问审计,帮助车联网平台提升平台内的风险控制级别。那如何定制自己的堡垒机呢?

  • 管理方便:提供一套简单直观的账号管理(包括账号的命名、密码等)、授权管理策略,管理员可快速方便地查找某个用户,查询修改访问权限。

  • 可扩展性好:当进行新系统建设或扩容时,需要增加新的设备到堡垒机时,系统应能方便的增加设备数量和设备种类。

  • 精细审计:针对传统网络安全审计产品无法对通过加密、图形运维操作协议进行为审计的缺陷,系统应能实现对RDP、VNC、X-Window、SSH、SFTP、HTTPS等协议进行集中审计,提供对各种操作的精细授权管理和实时监控审计。

  • 审计可查:可实时监控和完整审计记录所有维护人员的操作行为;并能根据需求,方便快速的查找到用户的操作行为日志,以便追查取证。

  • 安全性:堡垒机自身需具备较高的安全性,须有冗余、备份措施,如日志自动备份、带有不间断电源等。

  • 部署方便:系统应采用物理旁路,逻辑串联的模式,不需要改变网络拓扑结构,不需要在终端安装客户端软件,不改变管理员、运维人员的操作习惯,也不影响正常业务运行。

  • 硬件防火墙

硬件防火墙的硬件和软件都需要单独设计,有专用网络芯片来处理数据包;同时,采用专门的操作系统平台,从而避免通用操作系统的安全性漏洞。对软硬件的特殊要求,使硬件防火墙的实际带宽与理论值基本一致,有着高吞吐量、安全与速度兼顾的优点。定制自己的硬件防火墙,通常从两个大的方面来考虑。

一是做到最**的访问控制,即基于ACTUAL的六维一体化防护,通常有以下几点:

  • 一体化防护:从应用、用户、内容、时间、威胁、位置6个维度进行一体化的管控和防御。内容层的防御与应用识别深度结合,一体化处理。

  • 基于应用:运用多种技术手段,准确识别包括移动应用及Web应用内的6000+应用协议及应用的不同功能,继而进行访问控制和业务加速。

  • 基于用户:通过Radius、LDAP等多种用户识别手段集成已有用户认证系统简化管理。基于用户进行访问控制、QoS管理和深度防护。

  • 基于位置:与全球位置信息结合,识别流量发起的位置信息;掌控应用和攻击发起的位置,第一时间发现网络异常情况。根据位置信息可以实现对不同区域访问流量的差异化控制。支持根据IP自定义位置。

二是考虑最实用NGFW特性,即一台顶多台设备冗余,大幅降低TCO。通常包含:

  • 一机多能:集传统防火墙、VPN、入侵防御、防病毒、数据防泄漏、带宽管理、上网行为管理等功能于一身,简化部署,提高管理效率。

  • 入侵防护(IPS):超过5000种漏洞特征的攻击检测和防御。支持Web攻击识别和防护,如跨站脚本攻击、SQL注入攻击等。

  • 防病毒(AV):高性能病毒引擎,可防护500万种以上的病毒和木马,病毒特征库每日更新。

  • 数据防泄漏:对传输的文件和内容进行识别过滤。可识别多种常见文件类型,防止通过修改后缀名的病毒攻击。能对TXT、Word、Excel、PPT、PDF、RAR等30+文件进行还原和内容过滤,防止关键信息通过文件泄露。

  • SSL解密:作为代理,可对SSL加密流量进行应用层安全防护,如IPS、AV、数据防泄漏、URL过滤等。

  • Anti-DDoS:可以识别和防范SYN flood、UDP flood等多种DDoS攻击,识别500多万种病毒。

  • QoS管理:基于应用灵活的管理流量带宽的上限和下限,可基于应用进行策略路由和QoS标签着色。支持对URL分类的QoS标签着色,例如:优先转发对控制车辆的访问。

  • 负载均衡:支持服务器间的负载均衡。对多出口场景,可按照链路质量、链路带宽比例、链路权重基于应用进行负载均衡。

 

  • 安全运营中心

安全运营中心通常是一个安全大数据可视平台。为大数据提供业务和资产可视、风险和威胁可视。通过对海量数据进行多维、智能的持续分析,发现潜在的外部和内部的风险,预测即将发生的安全威胁,应该由专业团队运营。其功能概要说明如下:

  • 包括 DDoS 事件,Web 攻击,异地登录,暴力破解等攻击事件的监控和审计及木马文件的检测。

  • 对主机上存在的高危漏洞风险进行实时预警,并提供修复方案,包括系统漏洞、Web 类漏洞,帮助管理者快速应对漏洞风险。

  • 云主机日志及各个服务集群日志使用 Elasticsearch Service(ES)服务构建日志分析、异常监控。

  • 完善远程OTA更新功能,加强更新校验和签名认证,适配固件更新(FOTA)和软件更新(SOTA),在发现安全漏洞时快速更新系统,大幅降低召回成本和漏洞的暴露时间。

  • 建立车联网证书管理机制,用于智能网联汽车和用户身份验证,为用户加密密钥和登录凭证提供安全管理。

  • 开展漏洞和威胁情报共享库,在整车厂商、服务提供商及政府机构之间进行安全信息共享和整合,集中管理、分析,保证已经解决漏洞不会二次重现。

基于车联网ECU微小算法—Simon与Speck



背景

今天介绍两个分组密码族Simon和Speck。

【ECU(Electronic Control Unit)电子控制单元,又称“行车电脑”、“车载电脑”等,是汽车专用微机控制器。它和普通的电脑一样,由微处理器(MCU)、存储器(ROM、RAM)、输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。它就是汽车的大脑】。

目前在一些中高端乘用车上,不但在发动机上得到应用,在其它许多地方都有ECU的踪影。例如防抱死制动系统、四轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统、多向可调电控座椅等都配置有各自的ECU。随着汽车电子化、自动化比例的提高,ECU数量将会日益增多,线路也将日益复杂。为确保ECU之间安全地信息(数据)传输,需要先将数据(信息)解密后再进行传输。

那为何不直接用更复杂的对称算法AES呢?事实上,AES算法已经被建议在适当的时候用于轻量级应用。但对于受限制的环境而言,AES算法并不是**的选择,理由是:

1、芯片层面积不应超过2000 GE,而最小的AES实现需要2400 GE。显而易见,当芯片面积小于2400 GE时AES算法并不适合,更轻量级的Simon与Speck则成为更优选。

2、软件层, Simon与Speck拥有被关注的对小数据对称加解密能力集,AES算法不能提供小的数据长度(如AES不提供64 bit)。

所以,车联网架构中,车辆中一些配置较低、面积较小的ECU之间相互通信的过程中,为了数据的安全性、完整性,Simon与Speck是最合适的选择。

概述

分组密码族Simon和Speck,属于对称算法范畴,它们的宽度和密钥大小各不相同。尽管存在许多轻量级的块密码,但大多数都是为了在单个平台上良好运行而设计的,而并不是为了在一系列设备上提供高性能。Simon和Speck的目标是满足对安全、灵活性和可分析的轻量级块密码的需求。它们在硬件和软件平台上都有出色的性能且足够灵活,可以在给定的平台上接受各种实现,并且可以使用现有技术进行分析。两者在整个轻量级应用程序中的性能都非常好,Simon在硬件方面优化了性能,Speck在软件方面优化了性能。

分组密码Simon族:是一类特别适合于资源受限环境的轻量级分组密码,采用平衡Feistel结构。自2013年被美国国家安全局提出以来,受到学者广泛关注。与其他轻量级分组密码不同,Simon密码要求门电路小于1000。此外,设计者提供了10个版本,均可用Simon 2n/mn表示(其中:n代表字长,2n表示分组长度,mn表示密钥长度),这使得Simon在硬件和软件方面均表现出良好的性能。例如:Simon 64/128指的是Simon对64 bit明文块执行操作并使用128 bit密钥版本。该算法被设计成在硬件上非常小,并且易于在不同级别序列化,但是注意不要牺牲软件性能。

(注:Feistel密码结构,在密码学研究中,是用于分组密码中的一种对称结构。其优点在于:由于它是对称的密码结构,所以对信息的加密和解密的过程就极为相似,甚至完全一样。这就使得在实施的过程中,对编码量和线路传输的要求减少了几乎一半。)

Simon分组密码工作原理如下图:

                                                                       

                                                                               Simon轮函数原理图

分组密码Speck族: Speck系列算法也是美国安全局在2013年提出的轻量分组密码算法,该算法采用变形Feistel结构,轮函数(循环调用的函数)采用ARX模块,由循环移位、异或、模整数加法运算组成。分组密码在硬件和软件上都提供优异的性能,但是已经针对微控制器的性能进行了优化。我们对Speck的不同变体的表示法与Simon的完全类似。例如,Speck 96/144是指块大小为96 bit、密钥大小为144 bit的Speck分组密码。

Speck分组密码工作原理如下图:


Speck轮函数原理图

结束语

我们希望算法在4 bit、8 bit、16 bit和32 bit微控制器上具有优异的性能,而Simon和Speck非常适合低功耗和低能耗的实现(资源受限环境)。此外,由于Simon和Speck代码只提供加密功能(这对于轻量级应用程序是合理的),或许可在实现中包含解密算法。对于Speck来说,不成熟的实现还需要100字节左右的flash,但是通过利用加密和解密算法之间的相似性,我们可以大大减少这个数字。对于Simon来说,由于加密算法就是一种解密算法,因此其代价可以忽略不计,计算中最多就是交换首尾数据和重新排序轮密钥。

以下5个影响Simon与Speck的因素::

(1)块的大小:大的块会提高加密的安全性,但是会降低加密、解密的速度。(注:目前比较流行的这种方案是128 bit。)

(2)密钥大小:目前128 bit正逐渐取代64 bit,成为主流。

(3)轮函数循环次数:每多进行一轮循环,安全性就会有所提高。现阶段比较流行的是16轮。(注:关于轮数需要根据实际业务与安全级别而定。)

(4)子密钥的生成算法:生成算法越复杂,则会使得密码被破译的难度增强,安全性越高。

(5)轮函数的复杂度:轮函数越复杂,安全性越高。


车联网之低配置安全存储—SHE


SHE(Secure Hardware Extension)在车联网中,被应用在车端ECU中负责安全存储与安全计算。是由HIS(由Audi、BMW、Porsche、Volkswagen组成)制定的标准,中文意思“安全硬件扩展”,是对任何给定微控制器的片上扩展。它旨在将对加密密钥的控制从软件域移到硬件域,从而保护这些密钥免受软件攻击;但这并不是要取代高度安全的解决方案,如TPM芯片或智能卡等。

SHE逻辑结构如下图:

 

                                                                                              图1:SHE内部逻辑结构

上图可看出在ECU中,有一块单独的 Secure Zone。Secure Zone里是SHE模块。SHE包括Control Logic、AES、Memory、PRNG,并仅与CPU通讯。同时,SHE必须被实现为微控制器的片上外围设备。除了上图中明确指定的连接之外,SHE不能有任何其他连接。如果必须包括额外的资源以确保芯片制造过程中的正常功能,则所有端口都要求在物理上停用(如可以通过外部引脚访问)。SHE可以通过多种方式连接到CPU,如:通过专用接口或内部外围总线,互连必须以其他外设或外部实体不能修改CPU和SHE之间传输数据的方式实现。SHE不需要在特殊工艺中制造以提高安全性,也不需要采取任何措施来增强系统抵御物理攻击,如:蚀刻芯片外壳打开、差分功率分析、错误注入攻击等。

SHE设计的主要目标是:

  • 保护加密密钥免受软件攻击

  • 提供可认证的可信软件环境

  • 让安全性只依赖于底层算法的强度和密钥的机密性

  • 允许分布式密钥所有权

  • 保持灵活性高,成本低

SHE详细逻辑结构如下图:

 

                                                                                   图2:SHE的详细逻辑结构

通过图2可以看出,SHE基本由三个构建块组成:一个存储区来保存加密密钥和附加相应信息、分组密码(AES)的实现和控制逻辑将这些部件连接到微控制器的CPU上,同时SHE提供一套指令集,通过这些指令完成相关的操作。如:指令CMD_ENC_CBC就是完成对称加密操作的。

SHE主要提供以下功能:

  • 支持对称算法,AES-128(ECB、CBC)

  • CMAC的生成、验证

  • 数据压缩

  • 根密钥安全存储

  • 安全引导加载程序

  • 防止重放攻击

另外,SHE也有它的局限性:无法保护软件应用程序、不支持非对称算法、同一时间只允许一个进程访问,即:不支持并发。为什么SHE叫低配置安全存储呢?主要是与HSM比较的结论(hardware security module是一种用于保护和管理强认证系统所使用的密钥,并同时提供相关密码学操作的计算机硬件设备)。HSM按安全级别分三个等级:Full、Medium、Light,SHE应处在Full>Medium>SHE>Light,因此SHE属低配置安全存储范畴,我们认为车内ECU可以根据ECU负责业务的安全性、重要性来判断是否选择采用附带SHE的ECU,如电控自动变速器、主动悬架系统都是可以采用带SHE的ECU,完全够用,同时安全性有了硬件级别的保护、成本也得到了很好的控制。

注:HSM三个级别的说明如下:

  • Full level:用于V2X或中央网关,采用高速非对称加密;

  • Medium Level:用于ECU之间,采用低速非对称加密、高速对称加密,适用于动态通信;

  • Light Level:用于sensor、actuator,采用对称加密,适用于静态通信。

车机Android系统定制的安全注意

概述

在车联网的众多节点中,车机(head unit)可以说是最重要的一个节点,是云-车-人之间的信息枢纽,也是作为车联网信息安全的重中之重。针对车机所采用操作系统则越来越多地采用开源的Android系统来进行定制。

车机Android系统的架构

架构图示意如下:

图1:Android系统架构图

Android系统定制

Android是一个开源操作系统,在应用于车机系统的时候,为了系统的性能、体验和安全性等因素,主机厂通常对其进行深层次的定制,形成具有自己特色的车机系统。

定制工作通常包含以下四个层面:

  • 驱动层定制

  • Native层服务定制

  • Framework层服务定制

  • APK层应用定制

即,对Android架构中的各个层级进行定制时,将不需要的服务模块进行删除,增加具有自身特色需求的服务或应用,并且还需要针对配置文件进行对应的修改。

安全注意事项

对Android系统进行定制的时候,一定会考虑定制系统的安全性,下面介绍一部分注意事项供参考:

1.准备阶段

(1)准备**的补丁程序。

(2)在代码树构建初期,尽可能移除不必要的应用程序和服务。

例如:


 
2.开发阶段

(1)打开编译器警告配置。用GCC编译工具举例如下:

  • -wall-wextra:打开所有警告以帮助确保底层代码是安全的。

  • -wconversion/-Wsign-conversion:进行unsigned/sign转换时发出警告。

  • -wformat-security:警告使用表示可能存在安全问题的格式函数。

  • -werror:将所有警告转换为错误。

(2)编译器的安全设置。用GCC编译工具举例如下:

  • fstack-protector:fstack保护器。

  • fortify_source:强化资源。

  • wformat-security:格式安全。

(3)启用以下内存地址保护功能:

  • ASLR(Address space layout randomization):地址空间布局随机化,是一种针对缓冲区溢出的安全保护技术,通过对堆、栈、共享库映射等线性区布局的随机化,通过增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的。

  • 栈保护程序内核特性:用来检测栈是否遭到溢出攻击。

  • glibc指针保护。

(4)SOC GPS和陀螺仪:应受到MAC规则的保护,只允许访问Android资源管理。

(5)SOC BT和WIFI:应受到MAC规则的保护,只允许访问Android资源管理。

(6)应使用MAC规则保护SOC UART访问,以便仅允许访问CAN模块。

(7)应提供发布版本的静态代码分析报告。

例如:应在静态分析工具中验证Cert C和Cert Java规则。

3.上线阶段

(1)将root特权进程限制在最小权限。

(2)启动DEP(Data Execution Prevention数据执行预防),DEP是一组在存储器上运行额外检查的硬件和软件技术,有助于防止恶意程序码在系统上运行。

(3)禁用ADB,ADB应在生产后禁用。

(4)Android应用程序管理器只允许启动经车厂批准的应用程序。

(5)应支持关键代码和数据组件运行时的实时监视。

(6)应在运行期间监控以下组件的完整性(以下简称关键组件),举例如下:

  • SELinux策略

  • 内核代码中的DAC用户分离模块

(7)针对每个发布版本,推荐采用第三方产品来扫描已知公共漏洞(CVE)。

关于安全强化手段

为了强化设备系统的安全能力,Google在增强Android系统的安全性以外,还采用了安全计算环境TEE(Trusted Execution Environment)来强化业务的高安全需求。概要来说,主要为以下四方面:

  • 验证设备(Attestation):通过安全计算环境TEE来安全地验证该设备是否被服务商认可,从而才能进一步为这个认可设备提供服务。

  • 全盘加密(Protection):通过安全计算环境TEE中保管的密钥,来对设备上保存的数据进行全盘加密。

  • 生物信息的隐私保护(Privacy):全流程保护设备主人的个人隐私信息,确保在设备的安全计算环境TEE以外(包括Android系统)都无法获取这些隐私信息的明文。全流程包括生物信息(如指纹和人脸)的采集、存储、信息对比等各个易被攻击的环节。

  • 高安全业务的操作鉴权(Authentication):在Android Pay业务流程中,基于安全计算环境TEE实现了操作者的鉴权处理。

 

在以上安全强化手段的背后,除了需要安全计算环境TEE以外,更需要基础的密码学技术。

下一回,我们就来谈谈国密与其他密码学算法的区别,敬请关注。


国密与其他算法的区别


概述

在错综复杂的车联网中,无论从端到云、或从云到车,每个环节、每个节点的信息安全保障都离不开算法的支持,这些算法从真正意义上实现了车联网的信息安全,算法的计算能力也将直接影响车联网的性能和用户的体验。今天与大家共同讨论,关于国密算法与其他算法(即国际算法是美国的安全局发布,是现今最通用的商用算法)的差别,便于车联网的设计者们在不同的环节、节点采用**算法,从而提高产品的性价比。

国密算法

国密算法即国产密码算法,是国家密码局制定标准的一系列算法,其中包括了对称加密算法,椭圆曲线非对称加密算法,杂凑算法等,在金融领域目前主要使用公开的SM2、SM3、SM4三类算法,分别是非对称算法、哈希算法和对称算法。在车联网中,目前还没有车厂采用国密算法,但部分业内人士认为未来国密算法**是车联网领域的趋势,得国密者,得天下。

与国际算法差别

SM1是国家密码管理部门审批的分组密码算法,分组长度和密钥长度都为128比特,算法安全保密强度及相关软硬件实现性能与AES相当,该算法不公开,仅以 IP 核的形式存在于芯片中。

 

                                                                              图1:SM1与AES的比较

SM2算法和RSA算法都是公钥密码算法,SM2算法是一种更先进安全的算法,在我们国家商用密码体系中被用来替换RSA算法。SM2性能更优更安全:密码复杂度高、处理速度快、硬件性能消耗更小。

 

                                                                          图2:SM2与RSA的比较

注:1. 亚指数级算法复杂度不到指数级别的算法。

2. RSA秘钥生成慢,不建议使用。例:主频5G赫兹的话,RSA需要2-3秒的,车联网中根本无法接受,而SM2只需要几十毫秒。

SM3是摘要加密算法,该算法适用于商用密码应用中的数字签名和验证以及随机数的生成,是在SHA-256基础上改进实现的一种算法。SM3算法采用Merkle-Damgard结构,消息分组长度为512位,摘要值长度为256位。

 

                                                                       图3:SM3与Sha256的比较

SM4分组密码算法是我国自主设计的分组对称密码算法,用于实现数据的加密/解密运算,以保证数据和信息的机密性,是专门为无线局域网产品设计的加密算法。

 
                                                                   图4:SM4与3DES的比较

另外,SM7、SM9、ZUC祖冲之算法都属于国密算法范畴,但这几种算法不适用于车联网中,所以这里暂不讨论。

以上就是车联网众多节点中,为了保证各节点信息通讯安全,用到的国密算法、国际算法差别介绍。


车联网安全之TLS1.3比TLS1.2更安全在哪里


概述

在错综复杂的车联网中,云与端通信时,信息安全大多是通过TLS(Transport Layer Security)协议来保证。TLS即传输层安全性协议,其前身是安全套接层(Secure Sockets Layer,缩写SSL)安全协议。使用TLS的目的是为车联网通信提供安全及数据完整性保障。该协议由两部分组成: TLS记录协议(TLS Record)和 TLS握手协议(TLS Handshake)。较低层为TLS记录协议,位于某个可靠TLS 记录协议的传输协议(例如 TCP)上面。目前普遍采用的方案都是TLS1.2,据了解,由于技术和成本的限制,目前还没有车厂采用TLS1.3协议,不知在未来的车联网信息安全技术选择上是否会有所改变。下面,让我们从技术角度对TLS1.2和TLS1.3进行细致分析。

TLS作用

  • 所有信息都是加密传播,第三方无法窃听。

  • 具有校验机制,一旦被篡改,通信双方会立刻发现。

  • 配备身份证书,防止身份被冒充。

注:TLS 记录协议负责消息的压缩、加密以及数据的认证。

TLS位置

 

                                                                                  图1:TLS在通信链路中的位置

从图中可以看到,SSL/TSL层的加入,建立了一个安全连接(对传输的数据提供加密保护,可防止被中间人嗅探到可见的明文;通过对数据完整性的校验,防止传输数据被中间人修改)和一个可信的连接(对连接双方的实体提供身份认证)。

TLS1.2 握手

下面介绍一下,TLS 1.2协议的密钥交换流程及其缺点。

RSA密钥交换步骤如下:

1.client发起请求(Client Hello)。

2. server回复certificate。

3. client使用证书中的公钥,加密预主密钥,发给 server(Client Key Exchange)。

4. server 提取出预主密钥,计算主密钥,然后发送对称密钥加密的finished。

5. client计算主密钥,验证finished,验证成功后,发送ApplicationData了。

缺点:RSA密钥交换不是前向安全算法(私钥泄漏后,之前抓包的报文都能被解密)。

 

图2:TLS1.2的握手图解

注:图2是单向认证,TLS1.2是支持双向认证的。

TLS1.3 握手

相比TLS1.2,TLS 1.3 是按照以下方式优化握手的:

1. client发送请求(Client Hello),extension携带支持的椭圆曲线类型。且对每个自己支持的椭圆曲线类型计算公钥(POINT)。公钥放在extension中的keyshare中。

2. server回复Server Hello和certificate等;server选择的椭圆曲线参数,然后乘以椭圆曲线的base point得到公钥(POINT)。然后提取Client Hello中的key_share拓展中对应的公钥,计算主密钥。公钥(POINT)不再和之前的以协议一样放在Server Key Exchange中,而是放在Server Hello的key_share拓展中。client收到server的公钥(POINT)后计算主密钥。

 

图2:TLS1.3的握手图解

TLS 1.3 优点

  • 支持 0-RTT 数据传输,在建立连接时节省了往返时间。

  • 废弃了 3DES、RC4、AES-CBC 等加密组件,废弃了 SHA1、MD5 等哈希算法。

  • ServerHello 之后的所有握手消息采取了加密操作,可见明文大大减少。

  • 不再允许对加密报文进行压缩、不再允许双方发起重协商。

  • DSA证书不再允许在3中使用,导致与TLS1.2不兼容。

  • 3有更快的访问速度

  • TLS 1.2 需要两次往返( 2-RTT )才能完成握手。

  • TLS 1.3 协议只需要一次往返( 1-RTT )就可以完成握手。(注:使用 TLS 1.3 协议,可能会减少将近 100ms 的时间)

以上就是车联网众多节点中,云与端通信协议TLS1.2与TLS1.3的介绍。

未完待续



相关文章

【牛人访谈】陈静相 | 特斯拉“失联”凸显5G时代网联汽车信息安全问题

蔚来汽车李泉:车联网时代,如何用技术与终端守护汽车安全

王羽:《汽车自动驾驶技术路线图》 信息安全技术





SELECTED EVENTS




 

长按二维码识别关注



我就知道你“在看”


  • 电话咨询
  • 15021948198
  • 021-22306692
None