手机NFC通信的安全车钥匙

SmartKeys for Cyber-Cars:Secure Smartphone-based NFC-enabled Car Immobicizer

手机NFC通信的安全车钥匙

1概述

如今，智能手机的高性能平台，提供广泛的功能，并已成为我们日常生活中不可分割的一部分。日益增加的计算能力和存储能力，庞大的数量和不同种类的应用程序在应用商店。新的通信接口，近场通信（NFC），集成在智能手机中，为电子tickting、支付和访问控制提供许多部署的可能性。在这种情况下，一个新兴的趋势是集成的智能手机置身于现代汽车的系统和应用程序之间，如接入控制解锁，配置和启动车辆，控制车辆内部环境等。NFC是非常适合于这样的应用场合的，由于其数厘米的通信范围（NFC接口）提供用户的基本保证物理接近。

1.1设计模型

上图实现了车钥匙的功能：

优点：

l  安全，每一个环节都通过加密认证来实现开锁功能，充分的保证钥匙安全。

l  方便，不用携带车钥匙，只要拿着拥有NFC的手机，靠近汽车即可。

l  便捷，对于租车公司、车队的管理，只需要授权给员工，防止不法人员私配钥匙。

l  对于汽车拥有者可以很轻松的管理自己的汽车。

l  如果手机丢了，车主也无需担心汽车会丢。

缺点：

²  每个车要安装NFC-enabled固件

²  手机要携带NFC-enableddevice，朋友的手机也要携带，通用性较差。

Smart Keys for cyber-Cars的安全问题一直备受人们的怀疑，到底它能不能保证car的绝对安全，所以提出了本文，系统模型如图1所示。

既然我们提出防攻击的SmartKeys for cyber-Cars模型，那么我们首先要知道我们的对手是谁，我们怎样一个一个的解决掉。

1.2攻击模型

我们的主要目的是：阻止任何没有认证的客户端进行汽车内。

1 通信通道截获员

M-C,M-O,O-U,O-C,U-C之间都可能被监听。模型如图2所示。

2 手机上的其它软件对数据的攻击

3 对汽车上携带的NFC固件设备进行渗透和攻击

1.3要实现的目标

设计Smart Keys for Cyber-Cars的目标：

O1: O和U成功解锁，并且非常快速，提高用户体验。

O2:M能远程授权O,也能废除O。

O3:O能远程分权U,也能废除U。

O4: 很高的安全性。

 

2系统设计

2.1系统设计构架

我们的安全性体系结构，Figure 3中所示。分为两个独立的世界：一个不受信任的主机H和可信执行环境S执行环境的移动平台。H运行在移动设备上，而TrEE S建立安全硬件上。这种安全硬件可以嵌入到智能手机或连接通过标准的通信接口，向所述移动设备，它不需要任何更改商品平台。

无论是TrEE S还是Host H都是要通过TrEE Mgr来与SecureStorage进行访问的。效果图如Figure4所示。

2.2Protocol的设计

这里protocol过程总共分为了七个部分：

（1）      初始化工作

（2）      O用户注册

（3）      Token的发行

（4）      O解锁Car C

（5）      O分配权限给U

（6）      U解锁Car C

（7）      M废除O，O废除U用户

2.2.1 初始化工作

1 Smartphone初始化TrEE

Smartphone安装SmartTokenSecureapp，使用SmartTokenSecure初始化SecureStorage，这里使用{(sk_p,pk_p), cert_p证书}，见图4。这里只有Smartphone知道与sk_p对应的公钥pk_p。

2 Immobilizer NFC of Car端的初始化

Car C端装入[K^C_Auth, K^C_Enc]都会在协议验证中使用，由M管理机构完成。这里的K^C_Auth用来验证，K^C_Enc用来加密。

2.2.2 O用户注册

O在买车之前，注册自己的手机平台。M管理机构检查P上的证书cert_p，生成[K^O,M_Auth , K^O,M_Enc]，用于发行协定处理。然后，M使用SmartTokenSecureapp，利用公钥pk_p对生成的[K^C_Auth , K^C_Enc]进行加密处理，把对应的密文由SmartTokenSecure存储到SecureStorage中。

2.2.3 Token的发行

M生成[K^O_Auth, K^O_Del]，K^O_Auth用来解锁Car，K^O_Del用来分配权限给U。

σ_M:=MAC(K^C_Auth ; ID_O , K^O_Auth, K^O_Del)

T_O  :=Enc (K^C_Enc  ; ID_O , K^O_Auth, K^O_Del, σ_M)

K^O_Auth, K^O_Del ,T_O 存入SecureStorage中，这里的[K^O_Auth, K^O_Del]是通过[K^C_Auth, K^C_Enc]解析出来的。

2.2.4 O解锁Car C

2.2.5 O分配权限给U

O生成K^U_Auth，2.2.3中O有[K^O_Auth , K^O_Del]两个密钥，K^O_Auth用来解锁Car，K^O_Del用来分配权限给U。

σ_O:=MAC(K^O_Auth ; ID_U , K^U_Auth)

T_U  :=Enc (K^O_Del  ; ID_U , K^U_Auth,σ_O)

将生成的T_U 通过安全通道传递给U的SmartTokenSecureapp。

2.2.6 U解锁Car C

将T_U，T_O 传递给C，C通过K^C_EncK^C_Auth 在T_O中解码出K^O_Del，然后再T_U解码出K^U_Auth 。验证[σ_O ,σ_M]。

σ_M:=MAC(K^C_Auth ; ID_O , K^O_Auth, K^O_Del)

T_O  :=Enc (K^C_Enc  ; ID_O , K^O_Auth, K^O_Del, σ_M)

2.2.7 M废除O，O废除U用户

这里没有交代。

 

3安全硬件

SR1：安全存储。安全敏感的数据不应该访问不可信的软件组件，而存储在该平台上。

SR2：隔离。操作上安全敏感数据的系统组件必须是可信的，并从隔离不受信任的组件。此外，它必须确保安全敏感操作，如验证和委派，被触发由用户而不是恶意软件。此外，先进的使用情况下，如代表团和基于策略的访问控制，依靠安全关键用户输入，如密码和用户定义的访问控制策略。因此，对于这些使用情况下，我们需要一个额外的安全要求：

SR3：安全用户界面。用户（车主O或汽车用户U）应该能够安全地进行通信信任的组件。