用于保护移动设备与设备的首次联系建立的方法和系统与流程

文档序号:14652155发布日期:2018-06-08 22:03阅读:180来源:国知局
用于保护移动设备与设备的首次联系建立的方法和系统与流程

本发明涉及一种用于保护移动设备与设备的首次联系建立的方法和系统。



背景技术:

移动设备经由WLAN或者蓝牙(Bluetooth)(LE,Low Energy(低能量))与其它设备、例如车辆,在不直接进入车辆的情况下并且在车辆不能预先例如经由因特网为新的参与方做好准备的情况下耦合成为了挑战。

蓝牙提供各种配对机制,然而,当这些配对机制不包含所谓的带外(Out-of-band)确认,即不使用人员通道对连接进行认证时,这些配对机制是不安全的。在没有这种通道的情况下,中间人攻击是可能的,也就是说,于是不确定汽车或者移动设备与谁或者什么建立了连接。对于WLAN连接也存在同样的情况。在不进入车辆并且没有在那里的代码或者PIN的显示可能性的情况下,不能进行带外确认。

这种情形例如可能在汽车共享系统中发生。已知的汽车共享系统不与实际车辆系统、例如防盗锁集成,并且解决了关于改造解决方案的问题,这非常复杂。

DE 10 2009 042141 A1公开了一种具有无线通信设备、车辆和提供密钥的服务器的系统。不仅需要通信设备、而且需要车辆与服务器进行连接。

DE 10 2013 225 742 A1公开了一种用于确定电子装置的用户是否是授权的车辆用户的方法。为此,在中央服务器中确定用户是否能够执行车辆操作。如果是这种情况,则允许用户执行关于车辆的其它请求。

US 2010/0 111307 A1公开了一种用于确定并且控制会话密钥的光传输网络中的带内信号装置。

DE 198 11 833 A1公开了一种借助Diffie-Hellman方法和公钥加密方法的组合使用Diffie-Hellman协议与端对端验证的密钥交换协议,而未公开典型的Diffie-Hellman协议与签名协议的组合。



技术实现要素:

现在,本发明要解决的技术问题是,改善借助移动设备对设备的首次访问。

该技术问题通过根据权利要求1的方法或根据权利要求8的系统来解决。

提出了一种基于移动设备中和设备中的对称密钥的方法。

根据本发明的用于保护移动设备与设备的首次联系建立的方法,其中,所述设备设置有通过信任机构引入的对称密钥,包括步骤:

-通过信任机构将对称密钥引入所述移动设备中;

-在所述移动设备中和在所述设备中利用共同密钥的结果在建立联系时执行密钥交换方法;

-在所述移动设备中经由共同密钥利用对称密钥生成第一签名;

-在所述设备中经由共同密钥利用对称密钥生成第二签名;

-将第一签名传输到所述设备,并且将第二签名传输到所述移动设备;

-在所述移动设备中通过利用对称密钥对第二签名进行加密验证来对所述设备进行认证;

-在所述设备中通过利用对称密钥对第一签名进行加密验证来对所述移动设备进行认证;以及

-在相互成功进行认证时,继续进行联系建立,或者当至少一个认证失败时,中止联系建立。

根据本发明的方法具有如下优点:先前未与设备、例如车辆耦合的其它参与方设备或者移动设备也能够作为密钥被授权安全使用,更确切地说,不需要接近第二设备。因此,现在,任意设备、例如智能电话可以作为用于设备、例如车辆的数字密钥(Digital Key)来使用。因此,特别地为汽车共享提供根据本发明的方法。另一个优点是,由于所述方法的结构,可以排除中间人攻击,这使安全性提高。还有利的是,设备不需要与中央服务器或者因特网进行连接,因为在车辆中已经存在所需要的加密材料。仅需要连接到移动设备。根据本发明的方法提供传输技术的耦合系统与附加的认证机制的加密安全连接。设备或者车辆中的加密材料结合所提出的方法代替配对方法的PIN确认。由此,不需要像通常那样接近设备或者车辆,以输入或者确认PIN或者密钥。另一个优点是,由此可以对已经存在的、在外部预先给定的方法进行扩展,而不需要对其进行改变。

信任机构例如可以是车辆制造商或者例如汽车共享服务的服务供应商的受保护的服务器。信任机构可以是公钥基础架构PKI的组成部分,例如验证机构。将密钥引入移动设备中也可以在执行密钥交换方法之后进行。作为密钥交换方法,可以使用常见的方法,例如Diffie-Hellman。

可以假设传输技术具有安全密钥交换方法(SAV),然而安全密钥交换方法对于中间人攻击是不安全的,例如Diffie-Hellman。通常,密钥交换方法是由外部机构规定的,例如蓝牙配对方法。根据本发明的方法于是基于预先给定的密钥交换方法或对预先给定的密钥交换方法进行扩充。

换句话说,根据本发明的方法可以如下进行。在初次联系时,执行密钥交换方法,以进行耦合。为此,分别使用公钥,并且得到共同密钥,用于之后的通信。现在,为了在两方对该密钥进行认证,即为了确保可信的车辆与可信的移动设备真正直接彼此执行密钥交换方法,由两个参与方对密钥交换方法的该执行的唯一的特征进行签名,并且由相应的另一参与方进行认证。迄今为止,该步骤例如通过在两个设备上确认显示的用户的校验和来进行。

为此,例如通过对该特征应用硬加密单向函数来实现数字指纹。这具有如下特性:由该函数的图像、即数字指纹,不能推断出原像或逆像(Urbild),并且在输入相同的情况下,图像总是保持相同。现在,必须由两个参与方对指纹进行签名。该签名基于非对称密钥来执行,对于其适用以下内容:设备本身生成自己的密钥并且本身进行验证,因为其是PKI的信任链的一部分,并且在生产时已经引入了为此所需的密钥和证书。移动设备事先经由与设备制造商的信任基础架构(PKI)的接口,获得了用于对设备进行认证的证书和用于针对设备对自己进行证明的其自己的密钥的证书。现在,相应的接收方可以通过对所发送的指纹的签名进行加密验证并且对一起发送的密钥的证书进行加密验证,来对另一参与方进行认证,由此相应地以可信的方式建立信任链。然后,参与方可以基于所计算的共同密钥以可信并且保密的方式彼此进行通信。

用于保护移动设备与设备的首次联系建立的方法,其中,设备设置有签名的设备公钥和对应的设备私钥以及验证机构的公钥,包括步骤:

-将签名的移动设备公钥和对应的移动设备私钥以及验证机构的公钥引入移动设备中;

-在移动设备中和在设备中利用共同密钥的结果在建立联系时执行密钥交换方法;

-在移动设备中经由共同密钥利用移动设备私钥生成第一签名;

-在设备中经由共同密钥利用设备私钥生成第二签名;

-将第一签名和签名的移动设备公钥传输到设备,并且将第二签名和签名的设备公钥传输到移动设备;

-在移动设备中通过利用签名的设备公钥和验证机构的公钥对第二签名进行加密验证来对设备进行认证;

-在设备中通过利用签名的移动设备公钥和验证机构的公钥对第一签名进行加密验证来对移动设备进行认证;以及

-在相互成功进行认证时,继续进行联系建立,或者当至少一个认证失败时,中止联系建立。

适用与前面所描述的相同的优点和修改。引入签名的移动设备公钥和对应的移动设备私钥还包括:在移动设备中进行这些密钥的实际生成,向验证机构或者后端发送移动设备公钥,在那里进行签名,随后将签名的移动设备公钥引入移动设备。

与前面描述的在移动设备中和在设备中基于对称密钥构建的方法不同,该方法基于非对称密钥。根据存在或者希望的公钥基础架构PKI,可以使用这一种方法或者另一种方法。

可以设置为,设备本身生成并且验证签名的设备公钥和对应的设备私钥,并且在制造设备时引入为此所需的密钥和证书。其前提是,在车辆中存在验证机构,所述方法特别是通过减少加密材料的传输可以使这得到简化并且更安全。替换地,在PKI的范围内,优选在制造设备时,将加密材料引入车辆。

还可以设置为,在生产设备时,将签名的设备公钥和对应的设备私钥以及验证机构的公钥或者对称密钥引入设备。这使安全性提高,因为设备的生产在受保护的环境内进行。

此外,可以设置为,在建立联系之前,将对称密钥或者签名的移动设备公钥和对应的移动设备私钥以及验证机构的公钥引入移动设备。这种类型的引入允许所述方法完全准备好,然后所述方法可以在不与服务器或者PKI机构连接的情况下进行。

可以通过在移动设备中安装程序来引入密钥。例如App形式的这种引入以简单并且安全的方式执行,并且也被设备的潜在使用者接受。

密钥交换方法可以基于Diffie-Hellman方法。例如,耦合或者配对过程可以在配对模式“Secure Simple Pairing-NumericalComparison(安全简单配对-数值比较)”下,通过椭圆曲线Diffie-Hellman密钥协商协议(Elliptic Curve Diffie Hellman Schlüsselvereinbarungsprotokoll)来进行。这种方法仅需要简单的硬件开销。

可以通过交换签名在密钥交换方法中进行确认。由此,可以用交换签名来代替在密钥交换方法中通常需要的对代码的确认。虽然在常见的配对方法中,必须确认并且比较代码、例如PIN或者长期密钥(LTK,Long Term Key),但是这些任务通过自动化地进行的方法来进行。这由于排除错误的操作而提高了安全性,并且提高了舒适度。

可以设置为,在相互进行认证之后,才激活所述设备中执行所述方法所需的其它系统。以这种方式防止能量供应、例如车辆的电池耗尽,这防止设备出现不安全状态。

根据本发明的用于保护移动设备与设备的首次联系建立的系统设置为,所述移动设备和所述设备被配置为执行例如前面描述的方法。适用与前面所描述的相同的优点和修改。

设备可以是车辆,和/或移动设备可以是智能电话。这是能够受益于所述系统的、经常遇到的例如针对汽车共享服务的组合。

可以设置为,所述移动设备和所述设备分别具有用于根据Bluetooth Low Energy标准共同进行通信的发送/接收单元。该标准不仅在移动设备中、而且在例如车辆的设备中广泛使用,并且能够简单的实现。

还可以设置为,所述设备具有发送/接收单元以及与其连接的计算机单元,被配置为用于执行前面描述的方法,并且在进行认证之后,才能通过所述计算机单元的控制命令激活所述设备的其它系统。所连接的计算机单元例如可以是车辆的通信控制设备。其可以有利地防止车辆电池针对性地耗尽。

本发明的其它优选构造从在从属权利要求中提到的其余特征中得到。

除非在个别情况下另有说明,否则在本申请中提到的本发明的不同的实施方式可以有利地彼此组合。

附图说明

下面,根据附图在实施例中对本发明进行说明。

图1示出了用于保护移动设备与设备的首次联系建立的系统的示意图;

图2示出了对移动设备与设备的首次联系建立的保护的示意图;以及

图3示出了对移动设备与设备的首次联系建立的保护的另一示意图。

具体实施方式

图1示出了用于保护移动设备12与设备、例如车辆14的首次联系建立的系统10的实施例。对于系统10,这里选择车辆制造商的示例。在车辆制造商的后端16中布置有验证机构18和数据库20。作为专门的单元示出了后端16、验证机构18和数据库20。在数据库20中可以设置为,车辆14与信息、例如尤其要使用的加密材料相关联。

可以将所有或者多个元素例如整合到服务器中。验证机构18可以完全或者部分地作为软件来实施。验证机构18属于公钥基础架构(PKI)。公钥基础架构包括车辆制造商的后端16以及制造商的车辆14,示例性地示出了其中的一个。

移动设备12可以是可移动计算机、例如笔记本计算机或者平板计算机或者智能电话、智能手表、数据眼镜或者其它可穿戴计算机。车辆14例如可以是轿车、货车、公共汽车或者摩托车或者轨道车辆、水上交通工具或者飞机。

后端16具有用于与车辆14进行通信的第一接口24和用于与移动设备12进行通信的第二接口22。后端16或验证机构18经由第一接口22与车辆14进行通信。这经由连接26、例如WLAN或者移动无线电网络或线缆或者以太网来实现。优选在制造车辆14期间在车辆制造商的受保护的环境中激活连接26,因为经由该连接26将要保持机密的加密材料、例如对称密钥或者私钥引入车辆14中。为此,车辆14具有对应的兼容接口28。

后端16或验证机构18经由第二接口24与移动设备12进行通信。这经由连接30、例如WLAN或者移动无线电网络或线缆或者以太网来实现。该连接30通常像移动无线电网络一样可以公开地使用。为此,移动设备12包含对应的兼容接口32。

在车辆14中在例如根据CAN标准的一个或更多个总线系统36上布置有多个控制设备34或者其它计算装置。车辆还包括发送/接收单元38以及相关的控制设备40。发送/接收单元38优选例如根据Bluetooth LE(Low Energy)或者WLAN标准以无线方式工作。控制设备40被配置为经由发送/接收单元38执行用于与外部设备、例如与移动设备12建立连接的所谓的配对方法。

移动设备12也包括对应的发送/接收单元42,经由其可以与车辆14的发送/接收单元38建立连接44。移动设备12的微处理器46被配置为经由发送/接收单元42执行用于与外部设备、例如与车辆14建立连接的配对方法。在此,可以使用从后端16下载的程序或者App。

现在,借助图2描述对移动设备12与设备14的首次联系建立的保护的第一实施例。设备14例如可以是图1中的车辆14或者控制设备40。

在初步设置的过程中,即在移动设备12和设备14之间首次建立联系之前,对两个参与方配备共同的、也就是说相同的对称密钥48。对称密钥48由信任机构、例如制造商的后端16输出。设备14在其生产期间已经获得了对称密钥48或者用于导出对称密钥48的数据,而移动设备12在执行软件或者注册例如汽车共享服务的服务时获得对称密钥48。

在移动设备12和设备14之间建立联系时,执行密钥交换方法49。示例性地示出了Diffie-Hellman方法。移动设备12包含私钥50a和公钥52a,而设备14包含私钥50b和公钥52b。现在,移动设备12和设备14交换其公钥52a和52b。

在密钥生成56中,移动设备12由其私钥50a和设备14的公钥52b生成共同密钥56。类似地,设备14由其私钥50b和移动设备12的公钥52a生成共同密钥56。由此,密钥交换方法49在这里结束。

现在,在移动设备12中,在签名生成58的过程中,利用对称密钥48经由共同密钥56生成第一签名60a。类似地,在设备14中,在签名生成58的过程中,利用对称密钥48经由共同密钥56生成第二签名60b。

随后,将第一签名60a传输到设备14,并且将第二签名60b传输到移动设备12。这经由用来执行密钥交换方法49的同一接口或者连接来进行。这例如可以是图1中的与接口或者发送/接收单元38和42的连接44。

在认证62的过程中,在移动设备12中通过利用对称密钥48对第二签名60b进行加密验证来对设备14进行认证。类似地,在认证62的过程中,在设备14中通过利用对称密钥48对第一签名60a进行加密验证来对移动设备12进行认证。

在成功的认证64中,也就是说,在相互通过认证时,继续进行联系建立。例如,在图1的示例中,然后才通过控制设备40的控制命令激活其它系统、例如设备14的总线36和/或其它控制设备34。

在失败的认证66中,也就是说,当至少一个认证62失败,即在设备14中或者在移动设备12中认证失败时,中止联系建立。

下面,描述可能的日常示例。车主或者汽车共享服务提供商想要通过移动终端设备或者移动设备为客户设置数字车辆密钥。B的移动设备12具有Bluetooth Low Energy(蓝牙低能量)功能或者还具有BT Classic或WLAN功能。经由后端系统16向B的移动设备12输送新设置的数字车辆密钥。附加地,向移动设备12分配对称或者非对称密钥材料。

如果B与其移动设备12进入车辆14的无线电有效范围内,则自动在配对模式“Secure Simple Pairing-Numerical Comparison”下,通过椭圆曲线Diffie Hellman密钥协商协议开始耦合过程。不仅移动设备12、而且车辆14由此创建长期密钥(LTK),然后等待对作为6位数字显示的关于约定的机密的指纹进行确认,以防止中间人攻击。在两方都避免了所需要的这种用户交互,并且通过软件自动化地进行确认。现在,经由已经能够使用的密钥材料,通过发送和随后的验证,在标准化的耦合方法之后的步骤中确保对协商的密钥材料的这种认证。由此,尽管不进行用户交互,仍然确保了相互的密钥认证,由此确保了对中间人攻击的阻止。

现在,借助图3描述对移动设备12与设备14的首次联系建立的保护的第二实施例。设备14例如可以是图1中的车辆14或者控制设备40。图3中的方法与图2中的方法类似。主要区别在于,根据图2的方法基于共同的对称密钥48,而根据图3的方法基于非对称密钥材料。

在初步设置的过程中,即在移动设备12和设备14之间首次建立联系之前,对两个参与方配备非对称密钥材料。

移动设备12例如从车辆制造商或者其它受信任的服务提供商的PKI连接,获得签名的设备公钥104a和对应的设备私钥102a以及验证机构的公钥100。

设备14例如从车辆制造商或者其它受信任的服务提供商的PKI连接,获得签名的设备公钥104b和对应的设备私钥102b以及验证机构的公钥100。

设备14在其生产期间已经获得了密钥材料,而移动设备12在执行软件或者注册例如汽车共享服务的服务时获得密钥材料。

在移动设备12和设备14之间建立联系时,执行可以对应于图2中的密钥交换方法的密钥交换方法149。示例性地示出了Diffie-Hellman方法。移动设备12包含私钥150a和公钥152a,而设备14包含私钥150b和公钥152b。现在,移动设备12和设备14交换其公钥152a和152b。

在密钥生成154中,移动设备12由其私钥150a和设备14的公钥152b生成共同密钥156。类似地,设备14由其私钥150b和移动设备12的公钥152a生成共同密钥156。由此,密钥交换方法149在这里结束。

现在,在移动设备12中,在签名生成158的过程中,利用移动设备私钥102a经由共同密钥156生成第一签名160a。类似地,在设备14中,在签名生成158的过程中,利用设备私钥102b经由共同密钥156生成第二签名160b。

随后,将第一签名160a和签名的移动设备公钥104a传输到设备14,并且将第二签名160b和签名的设备公钥104b传输到移动设备12。这经由用来执行密钥交换方法149的同一接口或者连接来进行。这例如可以是图1中的与接口或者发送/接收单元38和42的连接44。

在认证162的过程中,在移动设备12中通过利用签名的设备公钥104b并且利用验证机构的公钥100对第二签名160b进行加密验证来对设备14进行认证。类似地,在认证162的过程中,在设备14中通过利用签名的移动设备公钥104a并且利用验证机构的公钥100对第一签名160a进行加密验证来对移动设备12进行认证。

在成功的认证164中,也就是说,在相互通过认证时,继续进行联系建立。例如,在图1的示例中,然后才通过控制设备40的控制命令激活其它系统、例如设备14的总线36和/或其它控制设备34。

在失败的认证166中,也就是说,当至少一个认证162失败,即在设备14中或者在移动设备12中认证失败时,中止联系建立。

由此,所提出的方法使得在先前彼此没有联系的参与方之间,也能够经由配对方法建立加密安全连接,而不需要接近两个参与方中的一个。

附图标记列表

10 系统

12 移动设备

14 车辆

16 后端

18 验证机构

20 数据库

22 接口

24 接口

26 连接

28 接口

30 连接

32 接口

34 控制设备

36 总线系统

38 发送/接收单元

40 控制设备

42 发送/接收单元

44 连接

46 微处理器

48 对称密钥

49 密钥交换方法

50a 私钥

50b 私钥

52a 公钥

52b 公钥

54 密钥生成

56 共同密钥

58 签名生成

60a 第一签名

60b 第二签名

62 认证

64 成功的认证

66 失败的认证

100 验证机构的公钥

102a 移动设备私钥

104a 移动设备公钥

102b 设备私钥

104b 设备公钥

150a 私钥

150b 私钥

152a 公钥

152b 公钥

154 密钥生成

156 共同密钥

158 签名生成

160a 第一签名

160b 第二签名

162 认证

164 成功的认证

166 失败的认证

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1