CCC联盟数字车钥匙(十)——UWB安全性

2023-12-09 12:52

本文主要是介绍CCC联盟数字车钥匙(十)——UWB安全性,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

本节介绍CCC联盟UWB数字钥匙相关(适用和强制)安全性要求。设备OEM应使用NFC作为后备机制,以防UWB和BLE模块的操作受到干扰。UWB中基于加扰时间戳序列(STS)避免了被中继的可能,进而保障了安全测距。

22.1 加密

本节详细介绍了前面介绍的各种安全功能中确定的各种加密函数。

基于加密DRBG构建STS

在前面的文章中介绍了MAC协议、STS索引增加:

  • MAC协议(测距会话和MAC控制信道)
  • STS索引增量(规则、增量和更新)

22.1.1 从DRBG推导STS序列

STS基于DRBG算法生成。
STS的推导遵循[33]第15.2.9.1节和图15-7b所述的顺序。生成STS的目的在文中作出说明,IEEE 802.15.4-2020中定义的以下参数映射到本规范中定义的相应参数,如下所示:

phyHrpUwbStsVCounter=SaltedHash[0:32]
phyHrpUwbStsVUpper96=SaltedHash([64:64])||((SaltedHash[32:32]+STS_Index) & 0xffffffffff)
phyHrpUwbStsKey=dURSK[0:128]

对于每个STS的生成,32位计数器用phyHrpUwbStsVCounter初始化。
SaltedHash[0:128]STSIndex[0:32]Counter[0:32](与IEEE 32位计数器相同,初始化为0)用于推导phyHrpUwbStsVUpper96phyHrpUwbStsVCounter

21.1.2 SP0帧加密

SP0应使用[31]第9.3节所述的AES-CCM* 算法进行加密。与要求加密数据长度>0的CCM的NIST规范不同,IEEE 802.15 CCM*实现仅允许身份验证CCM(如[31]中使用的安全级别被设置为1、2或3)。

STS_index 加密(SP0 Pre-POLL):

  • 算法:如[31]第9.3节所述的AES-CCM*。
  • 模式:加密和认证[31](安全等级6-ENC-MIC64)。
  • K(key)=**mUPSK1[0:128]**
    • N(Nonce)=Source Adress | Frame Counter | Nonce Security Level如[31]第9.3.2.1节所述。
    • 递增帧计数器(Frame Counter),有效载荷中的STS_Index。

注意:对于测距会话,密钥mUPSK1是静态的。

时间戳加密(SP0 Final_data 时间戳帧):

  • 算法:AES-CCM*如[31]第9.3节所述。
  • 模式:加密和认证[31](安全等级6-ENC-MIC64)。
  • K(key)=dUDSK,其中dUDSK在本小节后面定义。
  • N(Nonce)=Source Adress | Frame Counter | Nonce Security Level如[31]第9.3.2.1节所述。
  • 递增帧计数器(Frame Counter)。

注意:IV/Key重复的概率无关紧要,因为每个测距块的密钥dUDSK应更新。

22.1.3 密钥派生函数(KDFS)

协议的加密功能应通过以下级联的KDF建立,如图22-1所示。有关具体密钥派生信息,请参阅后续章节。
image.png可以看到,在CCC的派生函数中,基于STS_Index0与协商的配置参数,共同构成了加密派生中的Salted Hash,而实时递增的STS Index则用于整个CCC的会话中。
设备的长地址、FrameCounter等均用到Pre-Poll与Final Data中,同时Final Data中将包含测距过程的时间戳信息。数据段的加密均采用CCM*算法。

22.1.3.1 mUPSKs密钥派生

目的: 保护STS_Index
发生于: 每个会话一次
加密:
mUPSK1[0:128]=CMAC(URSK, 0x00000001 || 0x5550534B(“UPSK”) || 0x00 || 0x000000 ||0x00000180)
mUPSK2[128:128]=CMAC(URSK,0x0000002 || 0x5550534B || 0x00 || 0x000000 || 0x00000180)
mUPSK2[0:128]=CMAC(URSK, 0x0000003 || 0x5550534B || 0x00 || 0x000000 || 0x00000180)

CMAC=AES256-CMAC as PRF, r=32, h=128

参考: 参见计数器模式下[4]KDF的5.1
注意: ASCII(0x5550534B)="UPSK”,类似于FiRa派生函数中的派生标签
mUPSK1用于加密SP0 Pre-POLL的数据段的加密。
mUPSK2用于导出KeySource和UWB地址。
而生成的DUSK则用于SP0 Final Data数据的加密。

22.1.3.2 SaltedHash密钥派生

目的: 保持测距配置的完整性
发生于: 每次测距配置协商调用一次
加密:
Salt[0:128]=CMAC(URSK,0x00000001 || 0x53414C54(“SALT”) || 0x00 || 0x000000 || 0x00000080)
CMAC=AES256-CMAC as PRF,r=32,h=128

**参考:**参见计数器模式下[4]KDF的5.1
PaddedSalt[0:256]=0x000..0000 || Salt
RangingConfiguration=Selected_Protocol_Version || Selected_UWB_Config_Id || UWB_Session_Id || STS_Index0 || Number_Responder_Nodes || Session_RAN_Multiplier || Number _Slot_per_Round || Numeric_Chaps_per_Slot || Selected _PulseShape_Combo
SaltedHash=CMAC(PaddedSalt, RangingConfiguration)
CMAC=AES256-CMAC作为PRF,r=32,h=128
注意: ASCII(0x53414C54)=“SALT”
测距配置参数在第20.5.2节中有详细描述。

22.1.3.3 mURSK密钥派生

目的: Ranging Keys Seed derivation (测距密钥种子生成)
**发生次数:**每个会话一次
加密:
mURSK[128:128]= CMAC(URSK, 0x00000001 || 0x5552534B || 0x00 || 0x000000 || 0x00000100)
mURSK[0:128]= CMAC(URSK, 0x00000002 || 0x5552534B || 0x00 || 0x000000 || 0x00000100)
CMAC=AES256-CMAC as PRF, r = 32, h=128
**参考: **参见计数器模式下[4]KDF的5.1
**注意:**ASCII (0x5552534B)=“URSK”

22.1.3.4 dURSK/dUDSK密钥派生(KDF_cascade definition)

**目的:**测距密钥生成(Ranging Keys)
发生于: KDF每个测距循环(ranging cycle)执行一次 (before “POLL”)
加密:
URSK_KT[128:128]=CMAC(mURSK, 0x00000001 || 0x5552534B5F4B54 || 0x00 || 7'b0 || STS_Index[31] || .. 7'b0 || STS_Index[16] || 7'b0 || STS_Index[15] || ..7'b0 || STS_Index[1] || 7'b0 || STS_Index[0] || 0x00000100)
其中7’b0表示7个二进制“0” S T S _ I n d e x = S T S _ I n d e x k ( I , R o u n d _ I d x k ( i ) , P r e _ P O L L ) STS\_Index = STS\_Index^k(I, Round\_Idx^k(i), Pre\_POLL) STS_Index=STS_Indexk(I,Round_Idxk(i),Pre_POLL)
URSK_KT[0:128]=CMAC(mURSK, 0x00000002 || 0x5552534B5F4B54 || 0x00 || 7'b0 || STS_Index[31] || .. 7'b0 || STS_Index[16] || 7'b0 || STS_Index[15] || .. 7'b0 || STS_Index[1] || 7'b0 || STS_Index[0] || 0x00000100)
dURSK[0:128]=CMAC(URSK_KT, 0x00000001 || 0x5552534B || 0x00 || SaltedHash || 0x000000 || 0x00000080)
dUDSK[0:128]=CMAC(URSK_KT, 0x00000001 || 0x5544534B || 0x00 || SaltedHash || 0x000000 || 0x00000080)
CMAC=AES256-CMAC as PRF, r=32, h=128
**参考:**参见计数器模式下[4]KDF的5.1
注意:
ASCII (0x5552534B5F4B54)=“URSK_KT”
ASCII (0x5552534B)=“URSK”
ASCII (0x5544534B)=“UDSK”

22.1.4 测距恢复之间的UWB跟踪预防

为了保护在恢复之间相同的UWB测距会话被跟踪,以下值应在会话设置或接收到RR-RS消息时导出(派生):

  • KeySource(4字节)
  • Destination Short Address(2字节)
  • Source Long Address(8字节)
22.1.4.1 UWB Addresses KDF

**目的:**Deriving UWB Address(UAD)
**发生次数:**测距设置和恢复
**加密:**UAD[0:128]=CMAC(mUPSK2,0x00000001 || 0x554144 || 0x00 || STSIndex0[0:32] || 0x00000080)
一些地址应保留用于广播:

  • 对于KeySourceLowKeySourceHigh和目标短地址:0xFFFF和0xFFFE是保留值。
  • 对于源长地址:0xFFFFFFFFFFFFF是一个保留值。

如果计算的UAD与预留值相匹配,则应使用以下方法来翻转高位:

function SetUpperBitToZeroIfReserved(bytes [X...0]) {if(bytesAreReserverd(bytes)) {bytes[X...X-7] = bytes[X...X-7] & 0x7f}return bytes
}

注意:索引表示法仍然是指位索引。

SetUpperBitToZeroIfReserved重新映射以下条目,并保留其他未修改的条目。
图片.png
第一个地址应该有误,0xFFFF重映射之后应为:0x7FFF。

KeySourceLow[0:16] = SetUpperBitToZeroIfReserved(UAD[112:16])
KeySourceHigh[0:16] = SetUpperBitToZeroIfReserved(UAD[96:16])
DestinationShortAddress[0:16] = SetUpperBitToZeroIfReserved(UAD[80:16])
SourceLongAddress[0:64] = SetUpperBitToZeroIfReserved(UAD[16:64])

CMAC = AES256-CMAC as PRF, r = 32, h=128

ASCII (0x554144) = “UAD”
最新的STSIndex0是在会话设置或恢复协商的。

22.1.4.2 Key Source for Auxiliary Security Header

4-byte的密钥源的值通过以下方式获得:
KeySource[0: 32] = KeySourceHigh || KeySourceLow


持续更新,系列教程,收藏关注吧!

1、CCC联盟——UWB PHY
2、CCC联盟数字车钥匙(一)——UWB MAC概述
3、CCC联盟数字车钥匙(二)——UWB MAC时间网格
4、CCC联盟数字车钥匙(三)——UWB MAC时间网格同步及Hopping
5、CCC联盟数字车钥匙(四)——UWB MAC协议
6、CCC联盟数字车钥匙(五)——UWB MAC STS索引
7、CCC联盟数字车钥匙(六)——BLE连接概述
8、CCC联盟数字车钥匙(七)——BLE连接流程
9、CCC联盟数字车钥匙(八)——BLE配对相关字段
10、CCC联盟数字车钥匙(九)——Passive Entry

这篇关于CCC联盟数字车钥匙(十)——UWB安全性的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/473805

相关文章

从去中心化到智能化:Web3如何与AI共同塑造数字生态

在数字时代的演进中,Web3和人工智能(AI)正成为塑造未来互联网的两大核心力量。Web3的去中心化理念与AI的智能化技术,正相互交织,共同推动数字生态的变革。本文将探讨Web3与AI的融合如何改变数字世界,并展望这一新兴组合如何重塑我们的在线体验。 Web3的去中心化愿景 Web3代表了互联网的第三代发展,它基于去中心化的区块链技术,旨在创建一个开放、透明且用户主导的数字生态。不同于传统

usaco 1.2 Name That Number(数字字母转化)

巧妙的利用code[b[0]-'A'] 将字符ABC...Z转换为数字 需要注意的是重新开一个数组 c [ ] 存储字符串 应人为的在末尾附上 ‘ \ 0 ’ 详见代码: /*ID: who jayLANG: C++TASK: namenum*/#include<stdio.h>#include<string.h>int main(){FILE *fin = fopen (

AIGC6: 走进腾讯数字盛会

图中是一个程序员,去参加一个技术盛会。AI大潮下,五颜六色,各种不确定。 背景 AI对各行各业的冲击越来越大,身处职场的我也能清晰的感受到。 我所在的行业为全球客服外包行业。 业务模式为: 为国际跨境公司提供不同地区不同语言的客服外包解决方案,除了人力,还有软件系统。 软件系统主要是提供了客服跟客人的渠道沟通和工单管理,内部管理跟甲方的合同对接,绩效评估,BI数据透视。 客服跟客人

NC 把数字翻译成字符串

系列文章目录 文章目录 系列文章目录前言 前言 前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家。点击跳转到网站,这篇文章男女通用,看懂了就去分享给你的码吧。 描述 有一种将字母编码成数字的方式:‘a’->1, ‘b->2’, … , ‘z->26’。 现在给一串数字,返回有多少种可能的译码结果 import java.u

34465A-61/2 数字万用表(六位半)

34465A-61/2 数字万用表(六位半) 文章目录 34465A-61/2 数字万用表(六位半)前言一、测DC/AC电压二、测DC/AC电流四、测电阻五、测电容六、测二极管七、保存截图流程 前言 1、6位半数字万用表通常具有200,000个计数器,可以显示最大为199999的数值。相比普通数字万用表,6位半万用表具有更高的测量分辨率和更高的测量准确度,适用于精度比较高的测

超级 密码加密 解密 源码,支持表情,符号,数字,字母,加密

超级 密码加密 解密 源码,支持表情,符号,数字,字母,加密 可以将表情,动物,水果,表情,手势,猫语,兽语,狗语,爱语,符号,数字,字母,加密和解密 可以将文字、字母、数字、代码、标点符号等内容转换成新的文字形式,通过简单的文字以不同的排列顺序来表达不同的内容 源码截图: https://www.httple.net/152649.html

两个长数字相加

1.编程题目 题目:要实现两个百位长的数字直接相加 分析:因为数字太长所以无法直接相加,所以采用按位相加,然后组装的方式。(注意进位) 2.编程实现 package com.sino.daily.code_2019_6_29;import org.apache.commons.lang3.StringUtils;/*** create by 2019-06-29 19:03** @autho

关于字符串转化为数字的深度优化两种算法

最近在做项目,在实际操作中发现自己在VC环境下写的字符串转化为整型的函数还是太过理想化了,或者说只能在window平台下软件环境中运行,重新给大家发两种函数方法: 第一个,就是理想化的函数,在VC环境下充分利用指针的优越性,对字符串转化为整型(同时也回答了某位网友的答案吖),实验检验通过: #include <stdio.h> #include <string.h> int rayatoi(c

Oracle 数据库中 字符型字段 按数字排序

由于需要维护表里面的值,id主键是字符串型,保存的都是数字,每次都要看好久,才知道新增id,用哪个数字; 遇到了一个主键排序的问题。字符型的主键,保存的都是数字,数据导过来以后发现数据排序都是乱的,就想着按数字规则排序。 但发现to_number总是报错,就想着里面应该是有字符存在。后来使用了正则关系式,问题解决。 以下是正则关系式的两种用法,记录下来: 方法一: select * fr