汽车基础软件信息安全关键技术

用户身份鉴别目前主要是通过车钥匙、人脸、密码等方式，对用户的使用过程是有感知的。未来身份鉴别的方向应是让用户更少的感知身份识别，减少钥匙、密码这类的操作和输入，通过快速的生物识别方式识别用户合法性和配置映射，用户从接近车辆到进入车辆后车辆加载用户配置无需用户参与。对于设 备（如车载 ECU、路侧 RSU 等）的接入认证，一项正在研究的技术是基于其独特的、唯一的物理指纹特征进行身份验证。

机器鉴权目前在设备上的鉴权主要依赖于证书、密钥和访问仲裁，例如：在通讯中一般会依赖 TLS、SecOC 等通讯协议的认证、校验流程；进程权限、访问权限则由访问控制模块进行鉴权；在证书和密钥更新方向没有统一的方法，PKI 等系统的全自动化更新证书、密钥也没有统一规范的方案。未来应在机器鉴权方向重点做自动化更新鉴权证书和密钥的方案，并统一规范。

访问控制

访问控制是操作系统安全控制保护中重要的一环，在身份鉴别的基础上，根据身份对提出的资源访问请求加以控制，其模型如下图所示。

图3.4-12 访问控制模型

• 主体：即访问操作的执行者，一般指进程。

• 客体：即主体需要访问的资源，一般指文件、设备、服务等系统资源，在访问操作后，客体的内容可能被改变。

• 操作：访问中主体对客体的操作，如文件的读、写、执行；设备使用；服务访问等。

• 访问控制规则：规定了主体可以对哪些客体执行什么访问操作、客体由哪些主体执行什么访问操作。访问控制即是在主体对客体进行访问操作前，根据访问规则对主体的权限进行检查，确定主体有权执行后续的访问操作，并阻止主体的越权访问。目前常用的访问控制可分为自主访问控制和强制访问控制两大类。自主访问控制让客体的所有者来定义访问控制规则，管理员理论上不需要对访问控制规则进行维护。强制访问控制将主体和客体划分成不同的安全级别和类型，对每一类主体进行规则制定，规定其有权访问哪些级别或类型的客体，并拒绝所有非授权的访问。强制访问控制的规则（策略）通常由管理员制定，主体和客体的所有者无权修改规则。

下面以 Linux 系统为例对自主访问控制（DAC）和强制访问控制（MAC）进行说明。

1、Linux 系统 DAC

DAC 提供了基于 owner、group、other 角色的访问权限控制能力，基于角色可以控制对文件的读、写、执行权限。Linux 系统对其每一个用户都赋予一个用户 ID（UID）；并可以设定用户组，每个用户组可以赋予一个用户组   ID（GID），一个用户可以归类于多个不同的用户组。操作系统中的进程由用户执行，所以每一个进程都属于一个用户，也可以属于该用户对应的用户组，于是操作系统可以获得该进程的   UID 和 GID。通过 UID 和 GID，操作系统即可识别进程（访问控制主体）的身份和类型。

Linux 系统中的文件（或文件夹）属于其创建用户，也可以设定属于某一个用户组。DAC 权限系统依此将文件（访问控制客体）的操作者分成三种类型：即文件的所有者（user）、文件的所属组的用户（group）和其他用户（other，其他用户，为不属于 user 和 group 用户的所有用户）。对于文件的访问操作，DAC 系统将其分为读、写、运行三种类型，对于每一个文件，都规定好 user 用户可以执行什么操作、group 用户可以执行什么操作，以及 other 用户可以执行什么操作。而文件所属的用户，则可以自由更改文件的访问操作权限，例如对一个文件增加 group 用户的写权限，取消 other 用户的读权限等等。

这样在操作系统运行时，既可通过 UID 和 GID 来确定一个进程的身份，也可以根据文件的权限设定确定该进程对于一个文件来说属于哪种用户（user、group 还是 other），进而确定该进程是否可以对该文件执行所请求的操作。

可以看出，DAC 权限的控制策略非常简洁，所以其 DAC 检查的系统开销非常小。但是它的问题是其对客体类型和访问操作的划分粒度过大，操作系统中的各类资源，如设备、服务、套接字等，都统一划归为文件，而访问操作类型也只划分为读、写、运行三大类，这样很难实现精细管理。另一方面，Linux 系统中还存在 root 用户，该用户相当于管理员，有所有文件的一切操作权限，并可修改任意文件的归属和访问权限，这为访问控制管理带来了极大的风险，当攻击者获取了 root 权限，DAC 权限系统即被攻破。DAC 权限系统的广泛的应用于车载系统之中，它既用于嵌入式 Linux 系统，也用于基于 Linux 的Android 系统，很多其他操作系统中也有类似于 Linux 的 DAC 权限系统。

2、Linux MAC

随着芯片性能的提高，车载系统已经可以提供更多的硬件性能和系统开销，这样，为了弥补 DAC 权限系统的缺点，强制访问控制系统也被引入车载系统。MAC 提供了对系统资源访问的更高安全能力，此安全机制是限制了用户 (Subject) 对自己所创建的对象（Object）所拥有的 “控制级别” 。与 DAC 不一样， 在 MAC 中，对所有的文件系统 Objects 增加了额外的 Labels 或 Categories。在 Subjects( 用户或进程 ) 与 Objects 交互之前，它们必须对这些 Categories 或 Labels 进行合适的访问 ( 即先要进行权限判断 )。对访问的控制彻底化，对所有的文件、目录、端口的访问，都是基于策略设定的。这些策略是由管理员设定的、一般用户是无权更改的。

强制访问控制系统的代表为 SELinux，它支持多种安全策略模型，支持策略的灵活改变，使用类型增强（TE）、基于角色的访问控制（RBAC）和多级安全技术（MLS）保证系统安全。SELinux 最初由美国国家安全局（NSA）实现的强制访问系统，其可以作为安全子系统运行在 Linux、Android 或其他类似操作系统中。

SELinux 中的访问控制主体也是操作系统的进程，但与 DAC 权限系统不同的是，SELinux 根据进程本身进行主体类型划分，而不是简单的将进程归类于启动它的用户。SELinux 对每一个进程根据其执行文件进行类型标记，基本上每一个可执行文件的访问控制主体类型都不同，而多个不同的主体类型也可以标记归类于一个大类（类似与 DAC 中的组）。比如在采用 SELinux 的 Android 系统中，每一个可执行程序或守护进程都被标记成一个独立的类型，这些进程同时也可以标记归类于 coredomain（核心域）、ap- pdomain( 应用域 )，或根据其网络功能标记为 netdomain（网络域）、根据其应用签名标记为 platform_ app（平台应用）等等。

对于操作系统中的资源，SELinux 进行了细致类型划分，访问控制的客体被划分为文件、文件夹、服务、系统参数、设备等等，操作系统的每一个文件、每一个服务都被归类于一个客体类型，或者可以单独为该项资源定义一个客体类型（另外进程类型作为访问控制的主体的同时，也可以作为访问控制的客体）。与访问控制的主体一样，多个客体类型也可以被归类于某一个大类。

而对于访问控制的操作，SELinux 首先明确操作目标的类型，而后再根据操作目标划分出所有可行的操作。比如如果操作目标是文件，那么操作类型可以是读、写、执行等等；但如果目标是文件夹，那么操作类型可以是读、写、查找等等，但无法是执行。这样访问操作的类型可以涵盖操作系统中所有资源的操作子类，使精细化管理成为可能。

在明确了访问控制的主体、客体、与操作类型之后，就可以制订访问控制的策略（规则）。SELinux 的访问控制策略规定了哪些主体可以对哪些客体的什么操作目标进行什么样的操作。比如，可以规定主 体 kernel 允许对客体 app_data_file 的操作目标 file 进行读操作（策略条目为：allow kernel app_data_ file:file read）。操作系统中每一项允许主体对客体的操作，都需要有相应的 SELinux 访问策略条目规定， 否则就不符合访问控制策略。在 SELinux 开启的操作系统运行中，违背访问控制策略操作会被操作系统拒绝执行。

在车载系统中，SELinux 的访问控制策略一般需要在操作系统编译之前制订好，与操作系统源码一同编译，且与操作系统的镜像一起下载至车载设备中。正常情况下，车载系统运行时，SELinux 的访问控制策略无法被改变。这样，即使攻击者获取了操作系统的超级用户身份，其操作权限仍旧被限制在 SELinux 访问控制策略规定的范围内，大大提高了操作系统的安全性。

总的来说，以 SELinux 为代表的强制访问控制系统，与 Linux DAC 为代表的自主访问控制系统相比， 其安全性大大提高；但需要更多的维护成本来精细化定义访问控制策略，同时也牺牲了系统的自由度， 并需要比 DAC 系统更多的系统资源。在实际的车载系统中，由于车载芯片功能的增强，以及人们安全意识的提高，强制访问控制系统与自主访问控制系统常常共同存在于操作系统中，共同执行系统的访问控 制规则，维护系统安全。

DAC 和MAC 访问控制技术各有其优缺点，在实际的Linux 系统中往往同时被部署，在系统执行控制时， 一般先检测 DAC 规则，如果能通过，就继续执行 MAC 机制，只有在 DAC/MAC 检测同时通过的前提下， 主体才被允许执行访问客体的操作。

图3.4-13 访问控制流程

鉴于目前国内自主研发操作系统逐步崛起，业内建议设计统一的简易操作系统权限管理系统，且对 应用层用 Hook 的模式提供仲裁接口，以便基础软件平台的信息安全模块处理仲裁。根据目前的使用场景， 操作系统的权限仲裁接口应满足以下的功能：

• 提供用户空间的应用层 API 接口，以供用户空间的仲裁进程处理仲裁逻辑。

• Hook 收到访问请求后，应将请求内容传给仲裁进程注册的回调函数进行仲裁。

• 仲裁回调应分为文件类、网络类等。

• 仲裁范围应可控制进程 - 文件、进程 - 网络、进程 - 进程等。

安全监测

智能网联汽车安全监测是为车联网中车辆、终端设备、云端平台等构建以主动防御为核心的，以数据为驱动的车联网安全监测平台，以应对复杂的 “人 - 车 - 路 - 云” 系统协同下的车联网环境，通过各类数据的关联分析，利用人工智能等先进技术感知正在攻击或已经发生攻击的安全事件，实施主动防御机制， 实现事件快速感知定位，同时做到快速响应安全事件，降低攻击带来的直接和间接损失，保护未来出行 的健康发展。

智能网联汽车安全监测应由车载安全探针（又称入侵检测与防御系统      IDPS）和车辆安全运营中心（VSOC）两部分组成，以车联网安全监测系统形式对车辆网络安全威胁进行监测和防御，有效的实现外 防和内控，保障车联网生态下的全面信息安全。其中车载安全探针（IDPS）负责采集安全数据，可本地 化分析和执行预置安全策略，并与车联网安全监测平台进行深度关联。安全服务人员利用采集的安全数 据结合云端情报对事件进一步研判，若决定启动应急处置流程，可通过 OTA 形式更新策略下发给车端探针， 优化采集、分析与安全策略，形成闭环。