分享

车载软件架构Adaptive AUTOSAR —— 身份和访问管理和加密技术

 车载诊断技术 2024-03-19 发布于上海

车载软件架构Adaptive AUTOSAR —— 身份和访问管理和加密技术

我是穿拖鞋的汉子,魔都中坚持长期主义的汽车电子工程师(Wechat:gongkenan2013)。

老规矩,分享一段喜欢的文字,避免自己成为高知识低文化的工程师:

本就是小人物,输了就是输了,不要在意别人怎么看自己。江湖一碗茶,喝完再挣扎,出门靠自己,四海皆为家。人生的面吃一碗少一碗,人生的面见一面少一面。人生就是一次次减法,来日并不方长。自己的状态就是自己最好的风水,自己的人品就是自己最好的运气。简单点,善良点,努力点,努力使每一天都开心,不为别人,只为自己。

本文大体如下:

1、身份和访问管理

2、IAM 框架的架构

3、加密技术

一、身份和访问管理

身份和访问管理(IAM)的概念是由日益增长的安全需求驱动的,因为AUTOSAR自适应平台需要与其应用程序建立稳健且定义明确的信任关系。IAM 为自适应应用程序引入了权限分离功能,并可在受到攻击时防止权限升级。此外,IAM还使集成商能够在部署过程中提前验证自适应应用程序请求的资源访问权限。身份和访问管理为自适应应用程序在服务接口、自适应平台基础功能集群和相关模型资源上的请求提供访问控制框架。

1.1 术语

要了解该框架的工作原理,必须事先定义几个重要概念。

请参阅 RFC3198 中的"Policy-Based 管理术语"(https://tools./html/rfc3198)。

-> 访问控制决策:访问控制决定是一个布尔值,表示是否允许请求的操作。它基于调用者的身份和访问控制策略;

-> 访问控制策略:访问控制策略用于定义访问特定对象(如服务接口)时必须满足的限制条件;

-> 策略决策点(PDP):PDP 做出访问控制决策。它通过检查访问控制策略来确定是否允许自适应应用程序执行请求的任务;

-> 策略执行点 (EP):PEP 通过向 PDP 请求"访问控制决策",在自适应应用程序提出请求时中断控制流,并执行该决策;

-> 意图:意图是自适应应用程序身份的一种属性。只有当提出请求的AA 拥有该特定资源必须具备的所有已确认 Intent 时,才可访问 AUTOSAR 资源(如服务接口)。Intents 在AAs 的Application Manifest 中分配给 AAs;

-> Grant:在部署自适应应用程序期间,设计阶段请求的每个Intent 都应得到确认元模型中提供了"Grant"元素。 Grant 将支持集成商审査 Intent,但不允许部分接受 Intent;

-> 中间标识符(IntID):用于识别运行中的 POSIX-processes 和映射到建模的AUTOSAR Process 的标识符。IntID 的具体性质取决于用于验证运行中的 POSIXProcess 的机制;

image

-> 自适应应用程序 ID(AAID):自适应应用程序的建模 ID 由 AUTOSAR Process表示;

-> 自适应应用程序标识符:是AAID(即AUTOSAR Process)的参照器,,正好指向一个AAID。

1.2 框架的范围和重点:

IAM 框架为 AUTOSAR 自适应平台堆栈和自适应应用程序的开发人员提供了一种机制,以便对每个应用程序的意图进行建模,根据访问请求提供访问控制决策,并执行访问控制。IAM 的重点是提供限制自适应应用程序访问自适应平台基础接口、服务接口以及与功能集群(如 KeySlots)相关的定义明确的资源的手段。IAM 尤其不包括对 CPU或 RAM 等系统资源执行配额。

在运行期间,IAM 的过程对自适应应用程序是透明的,除非请求被拒绝并发出通知该框架旨在运行时对 AUTOSAR 资源实施访问控制。假设自适应应用程序在启动过程中通过了身份验证,而且现有的受保护运行时环境可确保自适应应用程序得到适当隔离,并防止其权限升级(即绕过访问控制)。

二、IAM 框架的架构

2.1 总体框架

IAM 架构在逻辑上将授权实体分为决定自适应应用程序是否允许访问资源的实体(PDP)和执行访问控制决定的实体(PEP)。需要限制访问其应用程序接口的功能集群需要实施 PEP,以执行 PDP 提供的访问控制决定。为此,如果自适应应用程序请求访问此类接口,PEP 将与 PDP 通信。访问控制决定将根据请求和应用程序的意图发回PER。访问控制决策所需的信息基于发起请求的自适应应用程序的应用程序清单中的意图以及策略。策略代表适用于接口的规则,即自适应应用程序为收集访问权限而必须满足的前提条件。对于受访问控制的每种资源,政策都是在功能集群规范中定义的。前言和假设

-> 1、应用程序设计/配置为具有意图(允许其访问某些资源的属性)。

-> 2、每个意图都将在部署过程中得到确认。

-> 3、部署的应用程序将进行加密签名,以便验证其真实性:

-> 4、应用程序与包含意图的应用程序清单一起部署。

-> 5、受IAM约束的自适应应用程序必须通过身份验证才能启动,其清单也必须在部署过程中通过身份验证。PEP 对请求进行解释,并要求 PDP做出策略决定(可在同- Process 中执行)。

2.2 自适应应用程序的识别

为了向 PDP 请求"策略决定",PEP 必须确定调用自适应应用程序的身份。由于每次调用都通过 Inter-ProcessCommunication 进行调解,因此中间件应支持这种识别。身份本身就是对建模 AA的引用。Intents与 PortPrototypes 绑定,因此也与SWComponentType 绑定。

IAM 框架没有完全规定 AAs 的标识。最合适的解决方案在很大程度上取决于堆栈供应商选择的操作系统和平台。许多现代操作系统都支持在通信端点上识别对等体(参见Linux 中的 SO PEERCRED、QNX 中的 getpeerid()或 Message Passing)。在不提供此类机制的平台上,实施消息级协议可能是合适的。

image

由于执行管理(Execution Management)通过建模AUTOSARProcess 来创建自适应应用程序的运行实例,因此它负责跟踪运行 Process 的属性(即运行中的自适应应用程序的PID)或分配属性,如设置专用 UID 或分配键或消息级实现的 UUIDS。执行管理应使PEPs 能够为 PEP 的每个有效请求找到建模的自适应应用程序。

PEP 应在自适应基础架构中实施,并应与调用的自适应应用程序适当隔离。PDP 不得由本身受请求操作访问控制的自适应应用程序提供。

2.3IAM 序列

->自适应应用程序(AA)启动对资源(如服务接口)的请求。

->PEP 中断控制流。

->PEP 通过 EM 解析请求 Process 的身份

->PEP 将调用者身份和请求参数传给 PD.

PDP 检查 AA 的意图是否充分,并将访问控制决定返回给 PEPPEP 通过阻止或允许请求来执行"访问控制决定"。

image

传输库与 EM 用来识别 AAs 的机制一致,在使用 POSIX-Process-IDs 的示例中,EM 跟踪在调用 fork()时从操作系统获取的 PID。EM 通过受保护的 Functional-Cluster 接口将此信息提供给 PEPS。使用 UID 时,EM 应主动设置新 POSIX-processes 的 UID

三、加密技术

AUTOSAR 自适应平台支持用于普通加密操作和安全密钥管理的 API。API支持在运行时动态生成密钥和加密任务,以及对数据流进行操作。为降低存储要求,密钥可存储在加密后端的内部或外部,并按需导入。

API 的设计支持将对安全敏感的操作和决策封装到单独的组件中,如硬件安全模块(HSM)。对密钥和密钥使用的额外保护可通过限制密钥的特定用途(如仅限解密)或限制密钥对个别应用的可用性来实现,如 IAM 所报告的那样。

在处理 TLS 和 SecOC 等加密协议时,API还可用于保护会话密钥和中间机密,具体取决于应用程序的支持。

FC Crypto 为应用程序和其他自适应 AUTOSAR 功能集群提供了一个标准化接口,用于加密和相关计算操作。这些操作包括加密操作、密钥管理和证书处理。FC Crypto 处理所有操作的实际执行,包括所有必要的配置以及请求应用程序和协议栈提供的执行之间的操作中介。标准化接口由 CryptoAPI提供。

X.509 证书管理提供程序(CMP,命名空间 ara::crypto:x509)负责X.509 证书的解析、验证、真实存储和按不同属性进行本地搜索。此外,CMP 还负责证书吊销列表(CRLS)和 Delta CRLs 的存储、管理和处理。CMP 支持在线证书状态协议(OCSP)的请求准备和响应解析。

3.1 安全架构

虽然 AUTOSAR AP 只定义了暴露给应用程序的高级加密堆栈 API,但该 API在定义时考虑了安全架构,旨在满足上述安全和功能要求。

总体架构如图 所示。在最高层,AUTOSAR AP 以及本地和混合应用程序与AUTOSAR AP 加密堆栈 API相连接。API 的实施可参考一个中央单元(加密服务管理),以跨应用一致地实施平台级任务,如访问控制和证书存储。实施还可使用加密服务管理来协调将功能卸载到加密驱动器(如硬件安全模块(HSM))。事实上,以这种方式卸载加密堆栈 API的功能有望成为一种典型的实施策略:加密驱动程序可以实现整套密钥管理和加密功能,以加快加密操作速度,保护管理密钥免受恶意应用程序的攻击。

Crypto Stack - Reference Architecture

为了实现这种分层安全架构,加密堆栈 API 不仅能执行加密和解密等典型加密操作还能提供以下本地支持:

1.使用加密密钥或密钥柄进行操作

2.在应用程序可能受损的情况下安全地管理密钥

3.限制应用程序对密钥的访问和允许的操作

3.2密钥管理架构

为了支持安全地远程管理密钥(尽管可能存在应用程序泄密),加密集成了一个密钥管理架构,在该架构中,密钥和相关数据以端到端受保护的形式进行管理。密钥可以根据现有的配置密钥以受信任的方式引入系统,也可以通过本地密钥生成以非受信任的方式引入系统。假定加密后端/驱动程序有适当的安全保护,应用程序就无法修改密钥,除非通过定义明确的授权请求(如密钥更新或撤销)。

CKI Key Management Interactions

3.3API扩展说明

需要引入新权限/策略验证逻辑或修改权限/策略验证逻辑的重要新用途和交互应与相应的新密钥使用策略标志挂钩。例如,可通过添加相应的新密钥使用策略,并在涉及这些新密钥的所有密钥管理操作中执行新逻辑,来引入具有不同所有权/权限检查的替代配置密钥。

搁笔分享完毕!

愿你我相信时间的力量

做一个长期主义者!

车载软件架构——基础软件供应商&开发工具链(二)

车载诊断协议DoIP系列 —— 协议中的简易网络拓扑概述

车载诊断协议DoIP系列 —— 协议中术语解释和定义

车载诊断协议DoIP系列 —— DoIP会话模式(安全与非安全)

车载诊断协议DoIP系列 —— DoIP应用(Application)需求

车载诊断协议DoIP系列 —— DoIP APP车辆识别和声明请求报文

车载测试Vector工具——基于DoIP的ECU/车辆的连接故障排除

电子电器架构——基于Adaptive AUTOSAR的电子电器架构简析

车载电子电器架构 —— 基于AP定义车载HPC

车载电子电器架构 —— 国产基础软件生态简介

电子电气架构——无感刷写(Vector)协议栈方案介绍

车载软件架构——基础软件供应商&开发工具链(一)

车载软件架构 —— 闲聊几句AUTOSAR OS(十一)

电子电器架构刷写方案——General Flash Bootloader

车载软件架构 —— 闲聊几句AUTOSAR OS(九)

车载诊断数据库——诊断问卷调查表与CDD关联关系

车载软件架构 —— 闲聊几句AUTOSAR OS(八)

车载软件架构 —— 闲聊几句AUTOSAR OS(七)

电子电气架构——车载DoIP通信汇总

车载软件架构 —— 闲聊几句AUTOSAR OS(六)

诊断测试工具CANoe.DiVa从入门到精通系列——开门见山

电子电气架构 —— OEM关于DTC具体实现相关见解

车载软件架构 —— 闲聊几句AUTOSAR OS(五)

车载软件架构 —— 闲聊几句AUTOSAR OS(四)

车载诊断协议 —— 诊断服务Service 11

车载软件架构 ——闲聊几句AUTOSAR OS(三)

车载软件架构 —— 闲聊几句AUTOSAR OS(二)

车载诊断协议-ISO 14229

车载诊断协议-ISO 14229 / 13400 /15765

车载软件架构——闲聊几句AUTOSAR OS(一)

电子电气架构——IP地址获取方式

车载通信架构 —— 传统车内通信网络MOST总线(光纤传输、专精多媒体)

电子电气架构——车载诊断通信参数

    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多