数字钥匙授权的方法、系统、装置、存储介质及电子设备

技术领域

本申请涉及门锁授权管理技术领域，具体而言，涉及一种数字钥匙授权的方法、系统、装置、存储介质及电子设备。

背景技术

数字钥匙技术广泛应用于智能网联汽车、智能家居、保险箱和仓库等各种智能门锁的业务领域中。有了数字钥匙，用户便可以使用智能移动终端控制自己的门锁，还可以通过相关技术共享数字钥匙，允许其他人解锁自己的智能门锁，如数字钥匙复制、授权等。除解锁门锁之外，它还可以用来支持众多其他的应用场景，例如限制分享钥匙的功能和禁用钥匙等。

随着数字钥匙技术的发展，国内外相应地提出了大量的数字钥匙解决方案，并推出了相关的标准化技术。其中，部分解决方案数字钥匙存储在智能移动终端，要求智能移动终端具备安全元件(SE)或同等安全级别能力；部分解决方案的数字钥匙实际存储在云服务平台，由云服务平台实现对智能门锁的控制；国际车联网联盟提出的汽车数字钥匙标准化技术(CCC-TS-101)依赖安全元件(SE)，使用非对称密码技术在智能移动终端和汽车智能门锁之间提供相互认证。

在CCC-TS-101中，用户用数字钥匙操作汽车智能门锁前首先要完成用户配对功能，即用户智能移动终端与智能门锁绑定。用户配对完成后，智能移动终端利用数字钥匙私钥签名消息即可实现对门锁的启动、控制。用户智能移动终端还可以通过用自己的数字钥匙私钥对其他人的数字钥匙公钥签名，将其他人的智能移动终端设置为“共享终端”(如，好友终端、亲人终端)，授权其他人控制自己的智能门锁。当好友终端第一次与智能门锁交互时，智能门锁利用数字钥匙公钥验证签名消息，验证通过后将好友钥匙公钥存储在智能门锁中。好友终端启动、控制汽车时，智能门锁利用好友钥匙公钥认证好友身份，认证通过后执行相关控制消息。

上述方案中有的数字钥匙私钥存储在智能移动终端的安全元件(SE)中，对SE的安全能力要求很高，一旦智能移动终端侧的数字钥匙私钥泄露，被恶意攻击者伪造消息，不仅会对个人隐私和人身安全造成影响，甚至可能影响交通、社会等其他方面的安全性；还有一些方案中，有的由云服务平台控制完整的数字钥匙私钥，有的智能门锁直接连接云服务平台，对云服务平台的安全要求较高且存在一定的安全风险；此外，不同智能移动终端厂商SE内部安全机制存在差异，甚至很多智能移动终端不具备支持SE的能力，因此，CCC-TS-101技术规范的实施落地具有一定局限性。

因此，如何提供一种安全性较高且易于实施的数字钥匙授权的方法的技术方案成为亟需解决的技术问题。

发明内容

本申请的一些实施例的目的在于提供一种数字钥匙授权的方法、系统、装置、存储介质及电子设备，通过本申请的实施例的技术方案可以实现基于通用移动终端实现安全的数字钥匙管理，并支持用户可控的数字钥匙安全授权且易于实施。

第一方面，本申请的一些实施例提供了一种数字钥匙授权的方法，数字钥匙用于控制门锁终端，当主终端向共享终端授权所述数字钥匙的私钥时，所述方法包括：云服务平台接收所述主终端发送的第二授权参数；所述云服务平台接收所述共享终端发送的第一申请参数，其中，所述第一申请参数与所述共享终端生成的第一私钥分量相关，且所述第一申请参数与第一授权参数相关，所述第一授权参数是由所述主终端发送至所述共享终端的；所述云服务平台基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，所述第一私钥分量和所述第二私钥分量构成所述私钥。

本申请的一些实施例通过云服务平台对接收到的主终端发送的第二授权参数和共享终端发送的第一申请参数进行计算，得到第二私钥分量，以实现对数字钥匙的分割后授权共享终端可以使用私钥的第一私钥分量，通过分割存储和使用可以实现基于通用移动终端实现安全的数字钥匙管理，并支持用户可控的数字钥匙安全授权且易于实施。

在一些实施例，所述主终端存储有所述私钥的第一分量，所述云服务平台存储有所述私钥的第二分量；所述第一分量和所述第二分量与所述第一私钥分量和所述第二私钥分量不同，但所述私钥是唯一的。

本申请的一些实施例的数字钥匙的私钥是唯一的，可以降低钥匙生成和管理成本。

在一些实施例，所述主终端为在所述云服务平台已注册的设备，所述第二授权参数包括：第一随机数和授权信息，所述授权信息包括：共享终端ID和授权会话ID；所述第一申请参数包括：目标参数和被授权信息，所述被授权信息包括：主终端ID、所述共享终端ID和所述授权会话ID；所述第一授权参数包括：关联参数、所述主终端ID和所述授权会话ID；其中，在所述云服务平台基于所述第二授权参数和所述第一申请参数，生成第二私钥分量之前，所述方法还包括：所述云服务平台确认所述授权信息和所述被授权信息一致。

在一些实施例，所述云服务平台基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，包括：所述云服务平台对所述第二分量、目标参数和第一随机数进行计算，得到所述第二私钥分量。

本申请的一些实施例云服务平台通过对相关参量进行计算得到第二私钥分量，为后续控制门锁终端提供支持。

在一些实施例，所述方法还包括：所述云服务平台确认所述共享终端为合法授权设备。

本申请的一些实施例对共享终端进行合法性鉴别，提升钥匙管理的安全性。

在一些实施例，所述云服务平台确认所述共享终端为合法授权设备，包括：所述云服务平台获取与所述共享终端协同签名得到的待验证签名结果；其中，所述待验证签名结果含有第一部分签名和第二部分签名，所述第一部分签名是通过所述共享终端利用所述第一私钥分量对第一消息签名得到的，所述第二部分签名是由所述云服务平台利用所述第二私钥分量对所述第一消息签名得到的；所述云服务平台利用所述数字钥匙的公钥对所述待验证签名结果进行验证，确认所述验证的结果为通过时，所述共享终端为所述合法授权设备。

本申请的一些实施例通过云服务平台和共享终端协同签名得到待验证签名结果后，由云服务平台进行验证，确保共享终端合法，以此保证共享终端身份授权的准确性和安全性。

在一些实施例，所述待验证签名结果是由所述云服务平台或所述共享终端对所述第一部分签名和所述第二部分签名进行计算得到的。

在一些实施例，所述方法还包括：所述云服务平台接收所述主终端发送的撤销请求，其中，所述撤销请求中携带有共享终端ID；所述云服务平台删除所述共享终端ID对应的所述共享终端，以撤销所述主终端对所述共享终端的授权。

本申请的一些实施例可以实现对共享终端授权的撤销。

在一些实施例，所述主终端或所述共享终端与所述门锁终端的通信方式为短距离通信。

第二方面，本申请的一些实施例提供了一种数字钥匙授权的系统，数字钥匙用于控制门锁终端，当主终端向共享终端授权所述数字钥匙的私钥时，所述系统包括：所述主终端，用于向所述共享终端发送第一授权参数，并向云服务平台发送第二授权参数；所述共享终端，用于接收到所述第一授权参数后，生成第一私钥分量；通过所述第一私钥分量和所述第一授权参数，获取第一申请参数；向所述云服务平台发送所述第一申请参数；所述云服务平台，用于基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，所述第一私钥分量和所述第二私钥分量构成所述私钥。

第三方面，本申请的一些实施例提供了一种数字钥匙授权的装置，应用于云服务平台，数字钥匙用于控制门锁终端，当主终端向共享终端授权所述数字钥匙的私钥时，所述装置包括：第一接收模块，用于接收所述主终端发送的第二授权参数；第二接收模块，用于接收所述共享终端发送的第一申请参数，其中，所述第一申请参数与所述共享终端生成的第一私钥分量相关，且所述第一申请参数与第一授权参数相关，所述第一授权参数是由所述主终端发送至所述共享终端的；生成模块，用于基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，所述第一私钥分量和所述第二私钥分量构成所述私钥。

第四方面，本申请的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如第一方面任一实施例所述的方法。

第五方面，本申请的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如第一方面任一实施例所述的方法。

第六方面，本申请的一些实施例提供一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如第一方面任一实施例所述的方法。

附图说明

为了更清楚地说明本申请的一些实施例的技术方案，下面将对本申请的一些实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请的一些实施例提供的智能门锁管理的系统图；

图2为本申请的一些实施例提供的数字钥匙授权的方法流程图；

图3为本申请的一些实施例提供的智能门锁管理的方法流程图；

图4为本申请的一些实施例提供的数字钥匙授权以及智能门锁管理的方法流程图；

图5为本申请的一些实施例提供的数字钥匙授权的装置组成框图；

图6为本申请的一些实施例提供的一种电子设备示意图。

具体实施方式

下面将结合本申请的一些实施例中的附图，对本申请的一些实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

相关技术中，智能门锁可以涉及多种应用场景，其可以是智能汽车的车门锁、仓库或房屋的智能锁等。为了便于理解和阐述本申请的实现过程，下述以智能汽车的车门锁为例阐述现有技术中存在的问题和本申请为解决现有技术问题所提出的方案。

由于现有技术中对于智能门锁的数字钥匙在管理时是将完整的数字钥匙的私钥完全存储在主终端、共享终端或者备份存储在云服务平台，很容易导致攻击者获取完整的私钥，安全性较差。

鉴于此，本申请的一些实施例提供了一种数字钥匙授权的方法，该方法中控制门锁终端的数字钥匙的私钥和公钥是唯一的。当主终端向授权共享终端授权私钥时，共享终端可以接收到主终端的第一授权参数后生成第一私钥分量，云服务平台可以利用主终端发送的第二授权参数和共享终端发送的第一申请参数进行处理，得到第二私钥分量。显然，本申请通过对私钥进行分割使得云服务平台和共享终端分别存储有对应的两个私钥分量，即使某一端的私钥分量泄露，攻击者也无法恢复出完整的私钥，以此降低了对终端侧SE安全能力的依赖；同样，该私钥分割方法使得某一端无法控制完整的门锁终端的私钥，避免了恶意篡改和伪造控车指令的风险；并且，门锁终端的私钥和公钥是唯一的，以此可以降低钥匙存储和管理成本。

为了便于理解本申请中数字钥匙授权的实现过程，下面首先结合附图1示例性阐述本申请的一些实施例提供的与数字钥匙授权相关的智能门锁管理的应用场景进行示例性阐述。

如图1所示，本申请的一些实施例提供了一种智能门锁管理的系统，该智能门锁管理的系统包括：车主智能移动终端100(作为主终端的一个具体示例)、好友智能移动终端200(作为共享终端的一个具体示例)、汽车智能门锁ECU300(作为门锁终端的一个具体示例)、智能汽车云服务平台400(作为云服务平台的一个具体示例，其中，云服务平台也可以称为云服务平台端或云平台等)以及智能移动终端软件服务提供商500。

具体的，在一种实施方式中，车主智能移动终端100与智能汽车云服务平台400通过图1中的步骤(1)预先完成双向身份鉴别后，车主智能移动终端100在智能汽车云服务平台400实现车主注册。车主智能移动终端100完整的数字车钥匙(作为数字钥匙的一个具体示例)的私钥(简称私钥)分为两份分量(即第一分量和第二分量)，一份存储在车主智能移动终端100，一份存储在智能汽车云服务平台400。数字车钥匙的公钥(简称公钥)由车主智能移动终端100和智能汽车云服务平台400协同生成，并置入汽车智能门锁ECU300。车主智能移动终端100启动、控制汽车时，车主智能移动终端100和智能汽车云服务平台400通过(1)使用自己的数字车钥匙私钥分量对控制消息协同签名，通过短距离通信步骤(2)发送给汽车智能门锁ECU300，汽车智能门锁ECU300使用已置入的数字车钥匙公钥验证协同签名，验证通过后接收该消息并执行相应操作。在此过程中，汽车智能门锁无需联网。

在另一种实施方式中，当车主授权其他人使用自己的汽车时，可对自己的数字车钥匙的私钥进行二次分割，并通过软件提供商(3)(4)或NFC等短距离通信(5)将其发送给好友智能移动终端200。好友智能移动终端200使用二次分割的第一私钥分量，与智能汽车云服务平台400的第二私钥分量进行(6)协同签名后，通过短距离通信(7)发送给汽车智能门锁ECU300，汽车智能门锁ECU300使用车主已置入的数字车钥匙的公钥验证，验证通过后接收该消息并执行相应操作。在此之前，智能汽车云服务平台400还需要检验好友智能移动终端200是否已被车主智能移动终端100授权，以及被哪一个车主智能移动终端100授权；检验通过后，方可接收好友智能移动终端200的消息并生成协同签名，以此实现对汽车智能门锁ECU300的安全控制。

可以理解的是，通过图1所示的系统可以将数字车钥匙的私钥安全分割为两份，一份私钥分量存储在智能移动终端(即：车主智能移动终端100)的密码模块中，一份私钥分量存储在智能汽车云服务平台400。当数字车钥匙共享时，车主数字车钥匙的私钥分量需进行二次分割分享给好友，但好友与云平台构成的完整的数字车钥匙和车主与云平台构成的数字车钥匙仍然保持一致，也就是说控制门锁终端的私钥是唯一的，只是分割的方式不同。基于数字车钥匙的私钥分量，车主智能移动终端100或好友智能移动终端200可与智能汽车云服务平台400使用协同签名算法(如SM2协同签名算法)，实现对汽车的启动、控制。

应理解，上述虽然以汽车场景为例，在其他智能门锁的应用场景下，上述系统同样适用，本申请在此不具体限定应用场景。

基于此，本申请的一些实施例提供了一种数字钥匙授权的系统，该数字钥匙用于控制门锁终端，当主终端向共享终端授权数字钥匙的私钥时，系统包括：主终端，用于向共享终端发送第一授权参数，并向云服务平台发送第二授权参数；共享终端，用于接收到第一授权参数后，生成第一私钥分量；通过第一私钥分量和第一授权参数，获取第一申请参数；向云服务平台发送第一申请参数；云服务平台，用于基于第二授权参数和第一申请参数，生成第二私钥分量，第一私钥分量和第二私钥分量构成所述私钥。

下面示例性介绍该系统中各端的功能。

为了实现基于通用移动终端实现安全的数字钥匙管理，并支持用户可控的数字钥匙安全授权，下面结合附图2示例性阐述本申请的一些实施例提供的由云服务平台(例如，智能汽车云服务平台400)执行的数字钥匙授权的实现过程。

请参见附图2，图2为本申请的一些实施例提供的一种数字钥匙授权的方法流程图。在执行下述数字钥匙授权的过程之前，主终端和云服务平台需要先生成数字钥匙的私钥SK和公钥PK。该数字钥匙用于控制门锁终端。

在本申请的一些实施例中，主终端存储有私钥的第一分量，云服务平台存储有私钥的第二分量。

例如，在本申请的一些实施例中，以图1中汽车智能门锁ECU300控制为例，数字车钥匙的公私钥的生成过程具体包括：车主智能移动终端100通过随机数算法生成随机数，得到D1(作为第一分量的一个具体示例)，D1∈[1,n-1]。智能汽车云服务平台400生成随机数，得到D2(作为第二分量的一个具体示例)，D2∈[1,n-1]。智能汽车云服务平台400计算D2

需要说明的是，下述在对共享终端进行授权时所生成的第一私钥分量和云服务平台的第二私钥分量与上述D1和D2不同，但是，两者所构成的私钥是唯一的。而且，在执行S210之前，主终端为在云服务平台已注册的设备。

也就是说，以图1中的智能汽车的汽车门锁为例，车主智能移动终端100为在智能汽车云服务平台400上已注册的设备，以此才能授权给其他好友智能移动终端200数字钥匙。

下面结合附图2示例性阐述当主终端向共享终端授权数字钥匙的私钥时，该数字钥匙授权的方法可以包括：

S210，云服务平台接收所述主终端发送的第二授权参数。

例如，在本申请的一些实施例中，智能汽车云服务平台400接收车主智能移动终端100发送的第二授权参数。

在本申请的一些实施例中，第二授权参数包括：第一随机数和授权信息，授权信息包括：共享终端ID和授权会话ID。

例如，在本申请的一些实施例中，车主智能移动终端100持有第一分量D1，车主智能移动终端100生成第一随机数r1，然后计算关联参数δ＝D1·r1。车主智能移动终端100需要通过SSL安全通道把r1、好友ID(作为共享终端ID的一个具体示例)和会话ID(作为授权会话ID的一个具体示例)发送给智能汽车云服务平台400，使其存储好友智能移动终端200和车主智能移动终端100的绑定关系。其中，好友ID可表明车主授权了哪个好友智能移动终端200可以控制汽车智能门锁ECU300。会话ID可对授权的车主与被授权的好友进行绑定并且抗重放。

S220，云服务平台接收所述共享终端发送的第一申请参数，其中，所述第一申请参数与所述共享终端生成的第一私钥分量相关，且所述第一申请参数与第一授权参数相关，所述第一授权参数是由所述主终端发送至所述共享终端的。第一申请参数包括：目标参数和被授权信息，被授权信息包括：主终端ID、共享终端ID和授权会话ID；第一授权参数包括：关联参数、主终端ID和授权会话ID。

例如，在本申请的一些实施例中，车主智能移动终端100经过软件服务提供商或近场通信，通过SSL安全通道将目标参数δ、车主ID(作为主终端ID的一个具体示例)和会话ID发送给好友智能移动终端200。其中，车主ID是已经在智能汽车云服务平台400注册，其可以表明好友智能移动终端200被哪个车主授权；好友智能移动终端200收到车主智能移动终端100发送的上述授权参数后，利用随机数算法生成的随机数作为第一私钥分量D1’。之后好友智能移动终端200计算目标参数γ＝δ·D1’，最后好友智能移动终端200通过SSL安全通道将γ、车主ID、好友ID、会话ID发送给智能汽车云服务平台400。

在本申请的一些实施例中，在执行S230之前，数字钥匙授权的方法还可以包括：所述云服务平台确认所述授权信息和所述被授权信息一致。

例如，在本申请的一些实施例中，智能汽车云服务平台400对接收到的车主智能移动终端100发送的车主ID、好友ID、会话ID，与好友智能移动终端200发送的车主ID、好友ID、会话ID进行核验，在一致时核验通过。

需要说明的是，在另一些实施例中，S210和S220的执行顺序可以进行灵活调整。例如，S210和S220可以同时执行，或者，还可以先执行S220，再执行S210，本申请实施例在此不作具体限定。

S230，云服务平台基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，所述第一私钥分量和所述第二私钥分量构成所述私钥。

例如，在本申请的一些实施例中，智能汽车云服务平台400利用相关算法对第二授权参数和第一申请参数中的参量进行计算，得到第二私钥分量D2’。其中，私钥SK＝D1

在本申请的一些实施例中，S230可以包括：云服务平台对所述第二分量、目标参数和第一随机数进行计算，得到所述第二私钥分量。

例如，在本申请的一些实施例中，智能汽车云服务平台400通过如下方法计算第二私钥分量D2’：D2’＝(γ·D2)/r1＝D1·D2·D1’

为了确定共享终端为主终端授权的合法设备，在本申请的一些实施例中，数字钥匙授权的方法还可以包括：云服务平台确认所述共享终端为合法授权设备。

在本申请的一些实施例中，云服务平台确认所述共享终端为合法授权设备，包括：云服务平台获取与所述共享终端协同签名得到的待验证签名结果；其中，所述待验证签名结果含有第一部分签名和第二部分签名，所述第一部分签名是通过所述共享终端利用所述第一私钥分量对第一消息签名得到的，所述第二部分签名是由所述云服务平台利用所述第二私钥分量对所述第一消息签名得到的。云服务平台利用所述数字钥匙的公钥对所述待验证签名结果进行验证，确认所述验证的结果为通过时，所述共享终端为所述合法授权设备。

例如，在本申请的一些实施例中，智能汽车云服务平台400通过数字钥匙的公钥PK对智能汽车云服务平台400和好友智能移动终端200协同签名得到的待验证签名结果进行验证，以使得智能汽车云服务平台400确认好友智能移动终端200为车主智能移动终端100授权的合法设备，确保授权安全，后续好友智能移动终端200可以实现对汽车智能门锁ECU300的安全控制。

在本申请的一些实施例中，待验证签名结果是由所述云服务平台或所述共享终端对所述第一部分签名和所述第二部分签名进行计算得到的。

下面以智能汽车云服务平台400最终生成待验证签名结果为例进行示例性阐述对好友智能移动终端200的合法性鉴别的过程：

具体的，好友智能移动终端200生成D1’并计算γ后。使用D1’对γ、车主ID、好友ID和会话ID(作为第一消息的一个具体示例)进行签名得到部分协同签名(作为第一部分签名的一个具体示例)。好友智能移动终端200通过SSL安全通道将γ、车主ID、好友ID、会话ID和部分协同签名发送给智能汽车云服务平台400。智能汽车云服务平台400通过D2’对γ、车主ID、好友ID、会话ID进行签名后得到另一部分协同签名(作为第二部分签名的一个具体示例)，利用协同签名算法(如，SM2算法)对另一部分协同签名与部分协同签名进行计算得到协同签名(作为待验证签名结果的一个具体示例)。智能汽车云服务平台400利用PK对协同签名进行验证，若验证通过则好友智能移动终端200为合法授权设备。

需要说明的是，最终的协同签名也可以是由好友智能移动终端200按照与上述相同的协同签名算法进行协同签名生成后发送给智能汽车云服务平台400的。但是，最终验证协同签名的过程必须由智能汽车云服务平台400执行，以确定好友智能移动终端200是被合法的车主智能移动终端100允许授权的。

可以理解的是，除了上述在S230之后，通过协同签名对共享终端的合法性进行验证之外，还可以在S230之前采用身份认证的方式对共享终端进行合法性鉴别，本申请实施例并不局限于此。

在本申请的一些实施例中，数字钥匙授权的方法还可以包括：所述云服务平台接收所述主终端发送的撤销请求，其中，所述撤销请求中携带有共享终端ID；所述云服务平台删除所述共享终端ID对应的所述共享终端，以撤销所述主终端对所述共享终端的授权。

例如，在本申请的一些实施例中，车主智能移动终端100还可以撤销对好友智能移动终端200的授权。当用户在车主智能移动终端100撤销好友智能移动终端200的数字钥匙时，车主智能移动终端100向智能汽车云服务平台400发送要撤销的好友ID，智能汽车云服务平台400从数据库中删除好友ID，即实现好友智能移动终端200的数字钥匙的撤销。当已被撤销的好友智能移动终端200向智能汽车云服务平台400发送包含好友ID的请求时，智能汽车云服务平台400查询本地无对应的好友ID后将拒绝其请求。

为了保证门锁控制的安全性，在本申请的一些实施例中，主终端或共享终端与门锁终端的通信方式为短距离通信。其中，短距离通信可以包括：NFC、BLE、UWB、Wi-Fi等近距离的通信技术。

需要说明的是，上述实施例中主终端或共享终端对门锁终端的数字钥匙的私钥进行分割的方式可以根据实际情况选择，其只要保证私钥是唯一的即可，本申请实施例在此不具体限定分割方法。对应的门锁终端只需要存储一把数字钥匙的公钥即可，以此在一定程度上降低了存储成本。另外，上文的协同签名算法可以采用SM2算法，也可以采用其他的协同签名算法，本申请实施例并不局限于此。

在完成主终端对共享终端的数字钥匙授权之后，下面结合附图3示例性阐述本申请的一些实施例提供的智能门锁管理的具体过程。

请参见附图3，图3为本申请的一些实施例提供的一种智能门锁管理的方法流程图。在本申请的一些实施例中，图3的智能门锁管理的方法可以由车主智能移动终端100或好友智能移动终端200执行。

下面示例性阐述上述过程。

在本申请的一些实施例中，由车主智能移动终端100或好友智能移动终端200执行的智能门锁管理的方法可以包括：S310，利用第一私钥分量对门锁控制消息签名，得到第一签名结果；S320，向云服务平台发送第一签名结果，以便于云服务平台通过第二私钥分量对门锁控制消息签名得到第二签名结果，并基于第二签名结果和第一签名结果生成协同签名结果；并向车主智能移动终端100或好友智能移动终端200发送协同签名结果。协同签名结果用于被门锁终端利用数字钥匙的公钥进行验证通过后，执行与门锁控制消息对应的操作。

例如，在本申请的一些实施例中，在对智能门锁进行控制时，车主智能移动终端100或好友智能移动终端200需要利用自身存储的第一私钥分量对门锁控制消息签名，得到第一签名结果，并发送给智能汽车云服务平台400。智能汽车云服务平台400通过自身的第二私钥分量对门锁控制消息进行签名后与第一签名结果生成协同签名结果。最后由汽车智能门锁ECU300对协同签名结果进行验证，验证通过后汽车智能门锁ECU300可以执行对应的操作。可以理解的是，当车主智能移动终端100对汽车智能门锁ECU300控制时，S310和S320中的私钥分量分别为上文的D1和D2。当好友智能移动终端200对汽车智能门锁ECU300控制时，S310和S320中的私钥分量分别为上文的D1’和D2’。

在本申请的另一些实施例中，协同签名结果可以是由车主智能移动终端100或好友智能移动终端200最终生成的，其生成方式与云服务平台的原理相同。但是，由于门锁终端处于不联网的状态(也就是门锁终端与云服务平台不通信)，无论协同签名结果是由哪端生成，最终均是由车主智能移动终端100或好友智能移动终端200发送给汽车智能门锁ECU300的。

并且，如果主终端或共享终端因处于地下车库或其他环境等原因导致的网络差，可提前在网络状况良好时使用数字钥匙提前进行协同签名，靠近门锁终端时仅需将协同签名结果发送给门锁终端即可。

下面结合附图4示例性阐述本申请的一些实施例提供的数字钥匙授权以及智能门锁管理的具体过程。

请参见附图4，图4为本申请的一些实施例提供的一种数字钥匙授权以及智能门锁管理的方法流程图。

下面以主终端为车主智能移动终端100(即图4中的车主端)、共享终端为好友智能移动终端200(即图4中的好友端)、门锁终端为汽车智能门锁为例，示例性阐述数字钥匙授权以及智能门锁管理的具体实现过程。

S401，车主端生成第一随机数，并通过计算第一随机数和第一分量得到关联参数。

其中，第一随机数为上文中的r1，第一分量为D1，关联参数为δ。

S402，车主端将关联参数、车主ID和会话ID发送给好友端，以便于好友端存储与车主端的绑定关系。

S403，车主端将第一随机数、车主ID、好友ID和会话ID发送给云服务平台端，以便于存储好友端与车主端的绑定关系。

需要说明的是，S402和S403可以是同时执行的，也可以是分开执行的，本申请不限定执行次序。

S404，好友端生成第一私钥分量，并计算目标参数。

其中，第一私钥分量为上文中的D1’，目标参数为上文中的γ。

S405，好友端使用第一私钥分量对目标参数、车主ID、好友ID和会话ID签名得到部分协同签名。

S406，好友端向云服务平台端发送部分协同签名、目标参数、车主ID、好友ID和会话ID。

S407，云服务平台端对车主ID、好友ID和会话ID进行核验，核验通过后，通过第一随机数、目标参数和第二分量生成第二私钥分量。

其中，第二私钥分量为上文中的D2’，第二分量为上文中的D2。

S408，云服务平台端使用第二私钥分量对目标参数、车主ID、好友ID和会话ID签名后，结合部分协同签名生成完整的协同签名。

S409，云服务平台端利用公钥对协同签名进行验证，确认验证通过。

S410，好友端利用第一私钥分量对门锁控制消息签名，得到第一签名结果。

S411，好友端向云服务平台端发送第一签名结果和门锁控制消息。

S412，云服务平台端利用第二私钥分量对门锁控制消息签名，得到第二签名结果。

S413，云服务平台端基于第一签名结果和第二签名结果生成协同签名结果。

S414，云服务平台端向好友端发送协同签名结果。

S415，好友端向汽车智能门锁发送协同签名结果。

S416，汽车智能门锁利用公钥对协同签名结果验证，验证通过后执行与门锁控制消息对应的操作。

可以理解的是，S401～S416的具体实现过程可以参照上文提供的方法实施例，为避免重复，此处适当省略详细描述。并且S401～S416的执行顺序可以按需调整，但是计算方法不变，在对好友端身份验证时保证最终的协同签名有云服务平台端验证即可，在对门锁控制消息对应的协同签名结果进行发送时，保证协同签名结果是由好友端或车主端采用短距离通信的方式发送至门锁终端，由门锁终端验证即可。本申请实施例并不局限于此。

通过上述本申请的一些实施例可知，本申请与现有技术中门锁终端的数字钥匙私钥完全存储在智能移动终端的技术方案相比，本申请私钥分割后两个私钥分量分别存储在智能终端和云服务平台端，降低了智能终端私钥泄露风险，即使智能终端侧的部分私钥分量泄露，攻击者也无法恢复出完整的数字车钥匙私钥。相对来说，降低了对智能终端侧数字钥匙的存储、管理安全要求，有利于技术的实现和落地。另外，云服务平台端仅持有数字钥匙私钥分量，而非完整的数字钥匙私钥，且门锁终端不连接云服务平台端，可以防止他人恶意篡改和伪造控制消息。数字钥匙共享时，门锁终端的插槽中仅需存储和管理一把数字钥匙公钥，即主终端和共享终端对应的数字钥匙公钥相同。云服务平台端通过检验主终端、共享终端和会话ID，能够抗消息重放且实现授权方用户和被授权方共享人的关联关系。云服务平台端通过验证协同签名，可以鉴别共享终端是否被合法的用户的主终端授权，安全性较高。

请参考图5，图5示出了本申请的一些实施例提供的数字钥匙授权的装置的组成框图。应理解，该数字钥匙授权的装置与上述方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该数字钥匙授权的装置的具体功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。

图5的数字钥匙授权的装置包括至少一个能以软件或固件的形式存储于存储器中或固化在数字钥匙授权的装置中的软件功能模块，该数字钥匙授权的装置应用于云服务平台，其中，数字钥匙用于控制门锁终端，当主终端向共享终端授权所述数字钥匙的私钥时，该装置包括：第一接收模块510，用于接收所述主终端发送的第二授权参数；第二接收模块520，用于接收所述共享终端发送的第一申请参数，其中，所述第一申请参数与所述共享终端生成的第一私钥分量相关，且所述第一申请参数与第一授权参数相关，所述第一授权参数是由所述主终端发送至所述共享终端的；生成模块530，用于基于所述第二授权参数和所述第一申请参数，生成第二私钥分量，所述第一私钥分量和所述第二私钥分量构成所述私钥。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法中的对应过程，在此不再过多赘述。

本申请的一些实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

本申请的一些实施例还提供了一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

如图6所示，本申请的一些实施例提供一种电子设备600，该电子设备600包括：存储器610、处理器620以及存储在存储器610上并可在处理器620上运行的计算机程序，其中，处理器620通过总线630从存储器610读取程序并执行所述程序时可实现如上述任意实施例的方法。

处理器620可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器620可以是微处理器。

存储器610可以用于存储由处理器620执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器620可以用于执行存储器610中的指令以实现上述所示的方法。存储器610包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。