CN115022873A - 设备通信方法、装置及存储介质 - Google Patents

Abstract

本申请实施例提供一种设备通信方法、装置及存储介质，涉及通信技术领域，该方法应用于基于业务进行绑定认证的任意场景，该方法可以复用第一设备与第二设备之前的应用绑定时的绑定相关信息，实现对后续其他应用的认证，不需要执行第一应用与第二应用之间的绑定关系，减少第一应用与第二应用之间的交互次数，因此可以提升第一应用与第二应用建立通信连接的效率，节约第一设备与第二设备的功耗。且，用户不需要执行绑定应用相关的操作，可以提升用户体验。

Description

设备通信方法、装置及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种设备通信方法、装置及存储介质。

背景技术

随着终端技术的发展，终端设备之间的通信越来越多样化。在一些对安全要求较高的通信场景中，两个终端设备通信前，需要双方进行绑定并认证，绑定并认证通过后可以建立通信连接，以实现数据安全传输等。

在可能的方式中，两个终端设备基于各自的应用程序(application，APP)进行绑定和认证。例如，第一终端设备中加载APP1，第二终端设备中加载APP2，第一终端设备通过APP1向第二终端设备的APP2发起通信连接，则第二终端设备中可以弹出个人识别码(personal identification number，PIN码)或二维码，用户需要在第一终端设备的界面中输入该PIN码或扫描该二维码，建立APP1和APP2之间的绑定，之后APP1和APP2之间执行认证步骤，认证通过则APP1与APP2建立通信连接，实现业务处理。

类似的，如果第一终端设备中的APP3向第二终端设备的APP4发起通信连接，第二终端设备再次弹出PIN码或二维码，用户仍然需要在第一终端设备的界面中输入PIN码或扫描二维码，建立APP3和APP4之间的绑定，之后APP3和APP4之间执行认证步骤，认证通过则APP3与APP4建立通信连接。

上述实现中，每当第一终端设备中有APP向第二终端设备中的APP发起通信连接时，用户均需要输入PIN码或扫描二维码实现APP的绑定，操作繁琐，影响用户体验。

发明内容

本申请实施例提供一种设备通信方法、装置及存储介质，涉及通信技术领域，有助于在维持安全性的基础上减少设备间基于APP通信时的用户操作。

第一方面，本申请实施例提供一种设备通信方法，应用于通信系统，通信系统包括第一设备和第二设备，方法包括：

第一设备接收到用于指示通过第一应用向第二设备的第二应用发起通信的触发；第一设备在确定第一应用为支持目标功能的应用时，获取第一设备中已存储的绑定相关信息，绑定相关信息包括第一设备相关的公钥信息、第二设备相关的公钥信息以及目标密钥信息；第一设备基于第一应用向第二应用发送通信请求，通信请求包括目标密钥信息；在第二设备确定第二应用为支持目标功能的应用时，第二设备根据目标密钥信息在第二设备已存储的绑定相关信息中获取第一设备相关的公钥信息；在第一应用基于第二设备相关的公钥信息，以及第二应用基于第一设备相关的公钥信息互相认证通过时，第一应用与第二应用建立通信连接。

这样，可以复用第一设备与第二设备之前的应用绑定时的绑定相关信息，实现对后续其他应用的认证，不需要执行第一应用与第二应用之间的绑定关系，减少第一应用与第二应用之间的交互次数，因此可以提升第一应用与第二应用建立通信连接的效率，节约第一设备与第二设备的功耗。且，用户不需要执行绑定应用相关的操作，可以提升用户体验。

在一种可能的实现方式中，在第一应用为支持目标功能的应用时，第一应用的密钥标签为第一设备相关的公钥信息；在第二应用为支持目标功能的应用时，第二应用的密钥标签为第二设备相关的公钥信息。这样，后续可以基于第一应用的密钥标签实现对绑定相关信息的模糊查询，有利于得到适用的绑定相关信息。

在一种可能的实现方式中，第一设备在确定第一应用为支持目标功能的应用时，获取第一设备中已存储的绑定相关信息，包括：第一设备在确定第一应用为支持目标功能的应用时，第一设备基于第一应用的密钥标签，在存储在第一设备的本地密钥信息列表中得到绑定相关信息。这样，可以基于第一应用的密钥标签实现对绑定相关信息的模糊查询，有利于得到适用的绑定相关信息。

在一种可能的实现方式中，存储在第一设备的本地密钥信息列表中包括多条绑定信息，任一条绑定信息为第一设备基于加载在第一设备中的应用执行绑定时存储的；第一设备基于第一应用的密钥标签，在存储在第一设备的本地密钥信息列表中得到绑定相关信息，包括：第一设备基于密钥标签，在存储在第一设备的本地密钥信息列表中得到多条绑定信息；第一设备在多条绑定信息中取出任一条绑定信息的密钥，得到任一条绑定信息的密钥的业务类型和任一条绑定信息的密钥的设备认证标识；若任一条绑定信息中存在第二设备的设备认证标识，则得到绑定相关信息。这样，可以通过遍历本地密钥信息列表的方式，较大可能得到适用的绑定相关信息。

在一种可能的实现方式中，目标密钥信息包括下述的一项或多项：密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证标识、密钥应用的应用程序包APK包名、或密钥附加信息。这样，后续第二设备可以基于目标密钥信息实现对绑定相关信息的模糊查询，有利于找到适用的绑定相关信息，提升认证成功的可能性。

在一种可能的实现方式中，方法还包括：第一设备执行对第三应用的注册流程；其中，若第三应用支持目标功能，将第三应用的密钥标签设置为第三应用的公钥；若第三应用不支持目标功能，将第三应用的密钥标签设置为第三应用的业务类型；第二设备执行对第四应用的注册流程；其中，若第四应用支持目标功能，将第四应用的密钥标签设置为第四应用的公钥；若第四应用不支持目标功能，将第四应用的密钥标签设置为第四应用的业务类型。这样，后续第三应用和第四应用可以支持后续的同签名认证。

在一种可能的实现方式中，方法还包括：第一设备接收到用于指示通过第三应用向第四应用发起通信的触发；第一设备基于第三应用向第四应用发送绑定请求；第一设备基于第三应用和第二设备的第四应用实现绑定，以及第一设备和第二设备分别存储绑定中产生的绑定信息。这样，后续第一设备和第二设备可以复用绑定信息，减少用户绑定相关操作，节约流程，提升效率，提升用户体验。

在一种可能的实现方式中，方法还包括：第一设备的第三应用基于第一认证功能函数authDevice(opParams,keyLength)向第二设备的第四应用发起设备认证。该第一认证功能函数可以用于认证已执行过绑定流程的应用。

在一种可能的实现方式中，还包括：第一设备的第一应用基于第二认证功能函数authDevice(opParams,ownerPkgName,peerAuthId,keyLength)向第二设备的第二应用发起设备认证。该第二认证功能函数可以用于认证未执行过绑定流程的应用。

第二方面，本申请实施例提供一种设备通信方法，应用于通信系统，通信系统包括第一设备和第二设备，第一设备中加载有第一应用和第三应用，第二设备中加载有第二应用和第四应用，方法包括：

第一设备显示第一界面；第一界面包括第三应用中的待传输数据，以及第四应用的标识；在第一界面中接收到用于将第三应用中的待传输数据向第四应用发送的触发的情况下，第二设备显示验证码或可扫描码；第一设备显示用于输入验证码或用于扫描可扫描码的第二界面；在第一设备在第二界面中接收到验证码输入或可扫描码的扫描操作时，第二设备在第二应用中显示传输的第三应用中的待传输数据；第一设备显示第三界面；第三界面包括第一应用中的待传输数据，以及第二应用的标识；在第三界面中接收到用于将第一应用的待传输数据向第四应用发送的触发时，第二设备在第二应用中显示传输的第一应用中的待传输数据。

其中，第一界面可以对应于图3中的c的界面，或者图4中的b的界面；第二界面可以对应于图3中的d的界面，或者图4中的e的界面；第三界面可以对应于图5中的c的界面，或者图6中的b的界面。

在一种可能的实现方式中，在第一界面中接收到用于将第三应用中的待传输数据向第四应用发送的触发，包括：在第一界面中接收到用于将第三应用中的待传输数据移动向第四应用所对应的区域的触发，或者，在第一界面中接收到点击第四应用的标识的触发。

在一种可能的实现方式中，在第三界面中接收到用于将第一应用的待传输数据向第四应用发送的触发时，第二设备在第二应用中显示传输的第一应用中的待传输数据，包括：在第三界面中接收到用于将第一应用的待传输数据向第四应用发送的触发的情况下，第一设备在确定第一应用为支持目标功能的应用时，获取第一设备中已存储的绑定相关信息，绑定相关信息包括第一设备相关的公钥信息、第二设备相关的公钥信息以及目标密钥信息；第一设备基于第一应用向第二应用发送通信请求，通信请求包括目标密钥信息；在第二设备确定第二应用为支持目标功能的应用时，第二设备根据目标密钥信息在第二设备已存储的绑定相关信息中获取第一设备相关的公钥信息；在第一应用基于第二设备相关的公钥信息，以及第二应用基于第一设备相关的公钥信息互相认证通过时，第一应用与第二应用建立通信连接；第一设备通过第一应用向第二应用发送待传输数据；第二设备在第二应用中显示传输的第一应用中的待传输数据。

在一种可能的实现方式中，在第一应用为支持目标功能的应用时，第一应用的密钥标签为第一设备相关的公钥信息；在第二应用为支持目标功能的应用时，第二应用的密钥标签为第二设备相关的公钥信息。

在一种可能的实现方式中，第一设备在确定第一应用为支持目标功能的应用时，获取第一设备中已存储的绑定相关信息，包括：第一设备在确定第一应用为支持目标功能的应用时，第一设备基于第一应用的密钥标签，在存储在第一设备的本地密钥信息列表中得到绑定相关信息。

在一种可能的实现方式中，存储在第一设备的本地密钥信息列表中包括多条绑定信息，任一条绑定信息为第一设备基于加载在第一设备中的应用执行绑定时存储的；第一设备基于第一应用的密钥标签，在存储在第一设备的本地密钥信息列表中得到绑定相关信息，包括：第一设备基于密钥标签，在存储在第一设备的本地密钥信息列表中得到多条绑定信息；第一设备在多条绑定信息中取出任一条绑定信息的密钥，得到任一条绑定信息的密钥的业务类型和任一条绑定信息的密钥的设备认证标识；若任一条绑定信息中存在第二设备的设备认证标识，则得到绑定相关信息。

在一种可能的实现方式中，目标密钥信息包括下述的一项或多项：密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证标识、密钥应用的应用程序包APK包名、或密钥附加信息。

在一种可能的实现方式中，方法还包括：第一设备执行对第三应用的注册流程；其中，若第三应用支持目标功能，将第三应用的密钥标签设置为第三应用的公钥；若第三应用不支持目标功能，将第三应用的密钥标签设置为第三应用的业务类型；第二设备执行对第四应用的注册流程；其中，若第四应用支持目标功能，将第四应用的密钥标签设置为第四应用的公钥；若第四应用不支持目标功能，将第四应用的密钥标签设置为第四应用的业务类型。

需要说明的是，第一方面和第二方面中以通信系统为例进行示例说明，也可以将第一设备单侧执行的方法从第一方面和第二方面分别拆出，组成单侧技术方案，以及，可以将第二设备单侧执行的方法从第一方面和第二方面分别拆出，组成单侧技术方案，在此不再赘述。

第三方面，本申请实施例提供一种设备通信装置，设备通信装置包括处理单元，处理单元用于实现第一方面或第二方面中与第一设备处理相关的任意方法。设备通信装置还可以包括显示单元，用于显示第一方面或第二方面中的第一设备的用户界面。设备通信装置还可以包括通信单元，用于第一设备实现向第一方面或第二方面中第二设备发送数据的任意方法。

第四方面，本申请实施例提供一种设备通信装置，设备通信装置包括处理单元，处理单元用于实现第一方面或第二方面中与第二设备处理相关的任意方法。设备通信装置还可以包括显示单元，用于显示第一方面或第二方面中的第二设备的用户界面。设备通信装置还可以包括通信单元，用于第二设备实现向第一方面或第二方面中第一设备发送数据的任意方法。

第五方面，本申请实施例提供一种设备通信装置，括处理器和存储器，存储器用于存储代码指令，处理器用于运行代码指令，以执行第一方面或第二方面的任意一种可能的实现方式中描述的第一设备执行的方法。

第六方面，本申请实施例提供一种设备通信装置，括处理器和存储器，存储器用于存储代码指令，处理器用于运行代码指令，以执行第一方面或第二方面的任意一种可能的实现方式中描述的第二设备执行的方法。

第七方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行第一方面或第二方面的任意一种可能的实现方式中描述的第一设备执行的设备通信方法，或者，使得计算机执行第一方面或第二方面的任意一种可能的实现方式中描述的第二设备执行的设备通信方法。

第八方面，本申请实施例提供一种包括计算机程序的计算机程序产品，当计算机程序在计算机上运行时，使得计算机执行第一方面或第二方面的任意一种可能的实现方式中描述的第一设备执行的设备通信方法，或者，使得计算机执行第一方面或第二方面的任意一种可能的实现方式中描述的第二设备执行的设备通信方法。

第九方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以执行第一方面或第二方面的任意一种可能的实现方式中描述的第一设备执行的设备通信方法。其中，芯片中的通信接口可以为输入/输出接口、管脚或电路等。

在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。

第十方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以执行第一方面或第二方面的任意一种可能的实现方式中描述的第二设备执行的设备通信方法。其中，芯片中的通信接口可以为输入/输出接口、管脚或电路等。

在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。

应当理解的是，本申请的第二方面至第十方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

附图说明

图1为本申请实施例所提供的终端设备的结构示意图；

图2为本申请实施例所提供的终端设备的软件架构示意图；

图3为本申请实施例提供的一种设备通信方法的界面示意图；

图4为本申请实施例提供的另一种设备通信方法的界面示意图；

图5为本申请实施例提供的一种设备通信方法的界面示意图；

图6为本申请实施例提供的另一种设备通信方法的界面示意图；

图7为本申请实施例的一种设备通信方法的流程示意图；

图8为本申请实施例的第一设备与第二设备基于第三应用和第四应用实现绑定的流程示意图；

图9为本申请实施例的一种应用在设备的注册流程示意图；

图10为本申请实施例的一种设备间应用绑定的流程示意图；

图11为本申请实施例的一种认证本应用绑定的设备的流程示意图；

图12为本申请实施例的一种认证同签名的其他应用绑定的设备的流程示意图；

图13为本申请实施例的一种芯片结构示意图。

具体实施方式

为了便于清楚描述本申请实施例的技术方案，以下，对本申请实施例中所涉及的部分术语和技术进行简单介绍：

1)同签名认证：可以理解为在两个设备之间通过各自的某APP绑定后，该两个设备其他的APP可以基于该某APP绑定时产生的数据实现认证。同签名认证也可以称为：基于APP的同签名认证，基于业务的同签名认证，基于以已存储公钥的同签名认证等，本申请实施例不作具体限定。

可以理解的是，设备中可以设置APP是否支持同签名认证功能的权限。

一种可能的实现中，该设置可以是APP默认的设置，例如，某些APP可以默认支持同签名认证功能，则该APP与其他同样支持同签名认证功能的APP之间可以实现同签名认证。

另一种可能的实现中，该设置可以是用户在APP中提供的用于设置是否支持同签名认证的界面中选定的。例如，APP中可以提供用于设置支持同签名认证功能的按钮，以及用于设置不支持同签名认证功能的按钮，在用户触发用于设置支持同签名认证功能的按钮时，设置该APP为支持同签名认证功能；在用户触发用于设置不支持同签名认证功能的按钮时，设置该APP为不支持同签名认证功能。

2)密钥数据结构：密钥数据结构可以理解为用于存储密钥相关信息的数据结构。密钥相关信息可以称为密钥信息或功能参数等。

示例性的，表1示出了部分密钥信息。

表1

需要说明的是，表1中的业务可以理解为应用程序(或称为应用)。

3)同签名认证相关的功能：可以理解为用于实现同签名认证中相关的功能函数。示例性的，同签名认证相关的功能可以包括下述功能函数：

获取实例：DeviceAuthManager get Instance(Context context)

注册：int register Local Device(String authId,String serviceType,Boolean isPrivate)

注销：int unregisterLocalDevice(String authId,String serviceType)

基于PIN码协商会话密钥：int runSpeke(OperationParameteroperationParams,string pin,int keyLength)

绑定：int bindDevice(OperationParameter operationParams,string pin,intkeyLength)

解绑：int unbindDevice(OperationParameter oprationParams)

认证本应用绑定的设备：int authDevice(OperationParameteroperationParams,int keyLength)

认证其他同签名应用绑定的设备：int authDevice(OperationParameteroperationParams,string ownerPkgName,string peerAuthId,int keyLength)

同签名认证相关的功能还可以包括连接服务、断开服务以及各类查询接口等，不进行赘述。

4)其他术语

在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一芯片和第二芯片仅仅是为了区分不同的芯片，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a--c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

随着终端技术的发展，终端设备的种类越来越多样化。例如，终端设备可以包括：手机(mobile phone)、平板电脑、掌上电脑、笔记本电脑、移动互联网设备(mobileinternet device，MID)、可穿戴设备，虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、无线本地环路(wirelesslocal loop，WLL)站、个人数字助理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobilenetwork，PLMN)中的终端设备等。

其中，可穿戴设备也可以称为穿戴式智能设备，是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，例如：智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

终端设备还可以是物联网(internet of things，IoT)系统中的终端设备，IoT是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连，物物互连的智能化网络。

终端设备之间通信的场景也越来越多样化。例如，手机与手机之间可以通信实现互相传输文件或互相控制等，手机与智慧屏之间可以通信实现投屏等，手机与平板电脑之间可以通信实现互相传输文件或投屏等，手机与笔记本电脑之间可以通信实现互相传输文件或投屏等，等。

在两终端设备之间建立通信时，为了安全考虑，一些场景中需要在设备间通过APP绑定并认证通过后，才建立两终端设备的通信连接。其中，设备间的APP绑定时用户有感知，绑定后的认证用户可以无感知。例如，每当其中一个终端设备中有APP向另一个终端设备中的APP发起通信连接时，用户均需要输入PIN码或扫描二维码以实现APP间的绑定，操作繁琐，影响用户体验。

有鉴于此，本申请实施例提供的设备通信方法，可以在第一终端设备与第二终端设备基于各自的某APP执行过绑定流程后，在第一终端设备和第二终端设备分别存储对端的公钥，则后续第一终端设备与第二终端设备中其他APP需要建立通信连接时，第一终端设备与第二终端设备中其他APP可以复用该已存储的公钥，基于存储的公钥实现设备认证，这样，既能通过认证达到提升安全的效果，也不需要执行APP之间的绑定，使得用户可以减少用于实现APP间绑定的操作，提升用户体验。

需要说明的是，本申请实施例不同于基于设备层面实现的设备之间的绑定认证流程，本申请实施例可以理解为基于业务(或称为APP)层面实现的业务之间的绑定认证流程，本申请实施例可以应用于基于业务进行绑定认证的任意场景。

为了能够更好地理解本申请实施例，下面对本申请实施例的终端设备的结构进行介绍。示例性的，图1为本申请实施例提供的一种终端设备的结构示意图。

终端设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，收话器170B，麦克风170C，传感器模块180，按键190，指示器192，摄像头193，以及显示屏194等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。其中，陀螺仪传感器180B和加速度传感器180E的结合可以理解为姿态传感器。

可以理解的是，本申请实施例示意的结构并不构成对终端设备的具体限定。在本申请另一些实施例中，终端设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。处理器110中还可以设置存储器，用于存储指令和数据。本申请实施例中，处理器110也可以用于支持终端设备与其他设备APP之间的绑定和/或认证等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为终端设备充电，也可以用于终端设备与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。电源管理模块141用于连接充电管理模块140与处理器110。

终端设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。终端设备中的天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。

移动通信模块150可以提供应用在终端设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。

无线通信模块160可以提供应用在终端设备上的包括无线局域网(wirelesslocalarea networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)等无线通信的解决方案。

终端设备通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实施例中，终端设备可以包括1个或N个显示屏194，N为大于1的正整数。本申请实施例中，显示屏194用于显示终端设备基于环境图像的位姿的计算得到的导航路线。

终端设备可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

摄像头193用于捕获静态图像或视频。在一些实施例中，终端设备可以包括1个或N个摄像头193，N为大于1的正整数。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端设备的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。

终端设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构等，在此不再赘述。

本申请实施例以分层架构的Android系统为例，示例性说明终端设备的软件结构。图2为本申请实施例适用的终端设备的一种软件结构框图。分层架构将终端设备的软件系统分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可以将Android系统分为五层，分别为应用程序层(applications)、应用程序框架层(application framework)、安卓运行时(Android runtime)和系统库、硬件抽象层(hardware abstract layer，HAL)以及内核层(kernel)。

应用程序层可以包括一系列应用程序包，应用程序层通过调用应用程序框架层所提供的应用程序接口(application programming interface，API)运行应用程序。

如图2所示，应用程序包可以包括电话、邮箱、相机、智慧互连等应用程序。其中，智慧互连可以包括用于社交的应用程序或用于智能家居互连的应用程序等。应用程序层的应用程序包也可以称为上层业务。

应用程序框架层为应用程序层的应用程序提供API和编程框架。应用程序框架层包括一些预先定义的函数。如图2所示，应用程序框架层可以包括设备认证服务软件开发工具包(software development kit，SDK)，设备认证服务，签名密钥管理服务，窗口管理器，视图系统，电话管理器，资源管理器，通知管理器，等。

设备认证服务SDK可以是上层业务与设备认证服务之间的桥梁，上层业务与设备认证服务之间通过设备认证服务SDK互相交换数据。

设备认证服务可以用于实现本申请实施例的同签名认证。

签名密钥管理服务可以用于管理密钥相关的数据，例如生成密钥对、存储密钥信息等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。

安卓运行时包括核心库和虚拟机。安卓运行时负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层可以运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。系统库可以包括多个功能模块。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

硬件抽象层，可以包含多个库模块，库模块如可以为摄像头库模块、硬件配置模块等。Android系统可以为设备硬件加载相应的库模块，进而实现应用程序框架层访问设备硬件的目的。设备硬件可以包括如终端设备中的扬声器、显示屏以及摄像头等。

内核层是硬件和软件之间的层。内核层用于驱动硬件，使得硬件工作。内核层至少包含显示驱动，马达驱动，传感器驱动等，本申请实施例对此不做限制。

需要说明的是，一些场景中，硬件抽象层可以省略，或与其它层集成，本申请实施例对终端设备的软件架构不作具体限定。

下面结合手机与手机之间可以通信实现互相传输文件的场景为例，对本申请实施例的发明构思进一步说明。

示例性的，图3示出了一种第一手机与第二手机之间互相传输数据的场景示意图。

如图3的a所示，第一手机中可以显示APP1的界面，APP1的界面中可以包括一个或多个待传输数据，待传输数据可以是下述的一种或多种：文字、图片、文档、视频等。APP1的界面中还可以包括第一手机通过设备发现查找到的多个其他设备的标识，其他设备例如包括第二手机、第一PAD或耳机等。

用户希望将APP1中的一个或多个待传输数据传输给第二手机的APP2时，用户可以在APP1的界面中触发第二手机的标识，进入如图3的b所示的界面。

如图3的b所示，第一手机的界面可以显示第二手机中多个应用的标识，例如第一手机中可以显示第二手机中APP2的标识、APP4的标识以及APP6的标识等。可以理解的是，第一界面中所显示的第二手机中多个应用的标识可以是能够与APP1实现文件传输的应用，或者可以是用户预先设置的，或者可以是默认系统设置的，本申请实施例不作具体限定。

用户可以在第一手机的界面中触发APP2的标识，进入如图3的c所示的界面。在如图3的c所示的界面中，用户可以将APP1中的一个或多个待传输数据移动至APP2对应的区域。

如图3的c所示，用户可以将APP1中的待传输数据1移动至APP2对应的区域，该用户操作可以触发第一手机的APP1与第二手机的APP2之间的绑定流程。

如图3的d所示，第二手机可以基于用户可以将APP1中的待传输数据1移动至APP2对应的区域的操作，启动APP2以及显示验证码。其中，验证码可以是PIN码，也可以是第二手机生成的数字、字母、符号中任意一种或多种。

如图3的e所示，第一手机中可以进一步显示用于输入验证码的输入框以及软键盘等，用户可以在第一手机中输入第二手机中显示的验证码，则第一手机的APP1与第二手机的APP2之间实现绑定。

绑定后的APP1和APP2可以进一步自动认证，认证通过后，待传输数据1可以从第一手机的APP1传输到第二手机的APP2。如图3的f所示，第二手机的APP2的界面中可以显示接收到的待传输数据1的标识。

需要说明的是，本申请实施例中如图3的d所示的验证码也可以替换为二维码或条形码等任意可能的可扫描码，则如图3的e所示的用户输入验证码可以替换为用户利用第一手机扫描二维码等可扫描码。为便于表述，后续实施例一验证码为PIN码，可扫描码为二维码为例进行示例说明，该示例并不构成对验证码的具体限定。

在第一手机与第二手机经过上述的APP1与APP2之间的绑定认证之后，可能的实现中，如果第一手机的APP3需要向第二手机的APP4传输文件，则第一手机与第二手机需要执行与图3的a-f示例的过程，即每当第一手机中有应用向第二手机的应用传输数据时，均需要用户执行输入PIN码或者扫描二维码的操作，操作繁琐，影响体验。

可以理解的是，在图3的示例中，第一手机为先确定APP2之后，再选择向APP2传输的待传输数据。另一个示例中，第一手机与第二手机之间互相传输数据时，第一手机可以先选定待传输数据，再选择需要传输的APP2。

示例性的，图4示出了另一种第一手机与第二手机之间互相传输数据的场景示意图。

如图4的a所示，第一手机中可以显示APP1的界面，APP1的界面中可以包括已选定的待传输数据1，待传输数据1可以是下述的一种或多种：文字、图片、文档、视频等。APP1的界面中还可以包括第一手机通过设备发现查找到的多个其他设备的标识，其他设备例如包括第二手机、第一PAD或耳机等。

用户希望将APP1中的待传输数据1传输给第二手机的APP2时，用户可以在APP1的界面中触发第二手机的标识，进入如图4的b所示的界面。

如图4的b所示，第一手机的界面可以显示第二手机中多个应用的标识，例如第一手机中可以显示第二手机中APP2的标识、APP4的标识以及APP6的标识等。可以理解的是，第一界面中所显示的第二手机中多个应用的标识可以是能够与APP1实现文件传输的应用，或者可以是用户预先设置的，或者可以是默认系统设置的，本申请实施例不作具体限定。

用户可以在第一手机的界面中触发APP2的标识，进入如图4的c所示的界面。在如图4的c所示的界面中，可以弹出提示框，用于提示用户是否缺向APP2传输数据，用户可以选择触发确认按钮，该触发确认按钮的操作可以触发第一手机的APP1与第二手机的APP2之间的绑定流程。

如图4的d所示，第二手机的界面中可以弹出提示框，用于询问用户是否同意APP1传输数据，在用户触发确认按钮时，如图4的e所示，第二手机可以显示验证码。其中，验证码可以是PIN码，也可以是第二手机生成的数字、字母、符号中任意一种或多种。

如图4的f所示，第一手机中可以进一步显示用于输入验证码的输入框以及软键盘等，用户可以在第一手机中输入第二手机中显示的验证码，则第一手机的APP1与第二手机的APP2之间实现绑定。

绑定后的APP1和APP2可以进一步自动认证，认证通过后，待传输数据1可以从第一手机的APP1传输到第二手机的APP2。

在第一手机与第二手机经过上述的APP1与APP2之间的绑定认证之后，可能的实现中，如果第一手机的APP3需要向第二手机的APP4传输文件，则第一手机与第二手机需要执行与图4的a-f示例的过程，即每当第一手机中有应用向第二手机的应用传输数据时，均需要用户执行输入PIN码或者扫描二维码的操作，操作繁琐，影响体验。

基于此，本申请实施例中，可以复用第一手机与第二手机之前利用APP绑定时生成的数据，使得第一手机与第二手机再次通过APP实现数据传输时，不需要用户执行绑定相关的操作。

示例性的，以第一手机已通过如图3所示的方式实现过绑定为例，图5示出了本申请实施例提出的一种第一手机与第二手机之间互相传输文件的场景示意图。

如图5的a所示，第一手机中可以显示APP3的界面，APP3的界面中可以包括一个或多个待传输数据，待传输数据可以是下述的一种或多种图片、文档、视频等。APP3的界面中还可以包括第一手机通过设备发现查找到的多个其他设备的标识，其他设备例如包括第二手机、第一PAD或耳机等。

用户希望将APP3中的一个或多个待传输数据传输给第二手机的APP4时，用户可以在APP3的界面中触发第二手机的标识，进入如图5的b所示的界面。

如图5的b所示，第一手机的界面可以显示第二手机中多个应用的标识，例如第一手机中可以显示第二手机中APP4的标识、APP4的标识以及APP6的标识等。可以理解的是，第一界面中所显示的第二手机中多个应用的标识可以是能够与APP3实现文件传输的应用，或者可以是用户预先设置的，或者可以是默认系统设置的，本申请实施例不作具体限定。

用户可以在第一手机的界面中触发APP4的标识，进入如图5的c所示的界面。在如图5的c所示的界面中，用户可以将APP3中的一个或多个待传输数据移动至APP4对应的区域。

如图5的c所示，用户可以将APP3中的待传输数据1移动至APP4对应的区域，该用户操作可以触发第一手机的APP3与第二手机的APP4之间利用APP1与APP2绑定时的数据进行自动验证。

认证通过后，待传输数据1可以从第一手机的APP3传输到第二手机的APP4。如图5的d所示，第二手机的APP4的界面中可以显示接收到的待传输数据1的标识。

也就是说，本申请实施例中，在第一手机的应用与第二手机的应用再次传输数据时，用户可以省略输入PIN码或扫描二维码的步骤，减少用户操作，提升用户体验。

示例性的，以第一手机已通过如图4所示的方式实现过绑定为例，图6示出了本申请实施例提出的一种第一手机与第二手机之间互相传输文件的场景示意图。

如图6的a所示，第一手机中可以显示APP3的界面，APP3的界面中可以已选定的待传输数据1。APP3的界面中还可以包括第一手机通过设备发现查找到的多个其他设备的标识，其他设备例如包括第二手机、第一PAD或耳机等。

用户希望将APP3中的一个或多个待传输数据传输给第二手机的APP4时，用户可以在APP3的界面中触发第二手机的标识，进入如图6的b所示的界面。

如图6的b所示，第一手机的界面可以显示第二手机中多个应用的标识，例如第一手机中可以显示第二手机中APP4的标识、APP4的标识以及APP6的标识等。可以理解的是，第一界面中所显示的第二手机中多个应用的标识可以是能够与APP3实现文件传输的应用，或者可以是用户预先设置的，或者可以是默认系统设置的，本申请实施例不作具体限定。

用户可以在第一手机的界面中触发APP4的标识，该用户操作可以触发第一手机的APP3与第二手机的APP4之间利用APP1与APP2绑定时的数据进行自动验证。

认证通过后，待传输数据1可以从第一手机的APP3传输到第二手机的APP4。如图6的c所示，第二手机的APP4的界面中可以显示接收到的待传输数据1的标识。

也就是说，本申请实施例中，在第一手机的应用与第二手机的应用再次传输数据时，用户可以省略输入PIN码或扫描二维码，以及确认数据传输等步骤，减少用户操作，提升用户体验。

可以理解的是，上面是以手机与手机中传输数据为例说明本申请实施例的场景，本申请实施例所提供的界面仅作为一种示意，并不能构成对本申请实施例的限定。

需要说明的是，本申请实施例也可以应用于下述场景：手机与手机间传输备忘录等，手机与手机之间通信实现互相控制等，手机与智慧屏之间通信实现投屏等，手机与平板电脑之间通信实现互相传输文件或投屏等，手机与笔记本电脑之间通信实现互相传输文件或投屏等，等。各场景中可以有对应的界面图，本申请实施例不作具体限定。

下面以具体地实施例对本申请实施例如何实现上述复用两个终端设备之前利用APP绑定时生成的数据，实现后续APP的自动认证的内部实现进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图7为本申请实施例的一种设备通信方法的流程示意图。如图5所示，方法可以包括：

S701、第一设备接收到用于指示通过第一应用向第二设备的第二应用发起通信的触发。

一种可能的实现方式中，第一设备接收到用于指示通过第一应用向第二设备的第二应用发起通信的触发包括：第一设备检测到用户将第一应用的数据向第二应用发送的触发。

示例性的，第一设备可以接收到用户将第一应用的文件向第二设备的第二应用传输的触发，例如图5中c所示的界面所受到的触发，或者图6中b所示的界面所受到的触发。

或者，第一设备可以接收到用户将第一应用的音视频数据向第二设备的第二应用投屏的触发，等，本申请实施例对具体的触发过程和界面不作限定。

在第一设备接收到用于指示通过第一应用向第二设备的第二应用发起通信的触发后，为了通信安全，第一应用和第二应用需要互相认证通过之后，建立通信连接。S702-S705示例性的说明第一应用和第二应用互相认证的可能实现。

S702、第一设备在确定第一应用为支持目标功能的应用时，获取第一设备中已存储的绑定相关信息，绑定相关信息包括第一设备相关的公钥信息、第二设备相关的公钥信息以及目标密钥信息。

本申请实施例中，目标功能可以为同签名认证功能。第一应用可以默认支持同签名认证功能，或者用户可以设置第一应用为支持同签名认证功能。

一种可能的实现中，第一设备可以基于第一应用中用于指示是否支持同签名认证功能的接口的状态确定第一应用是否支持同签名认证功能。示例性的，在第一应用中可以包括用于读取isPrivate参数的接口，如果isPrivate＝true，则keyAttribute＝sha256(ownerPkgName||serviceType)，说明第一应用不支持同签名认证功能；如果isPrivate＝false，则keyAttribute＝sha256(ownerPkgName||ownerPubKey)，说明第一应用不支持同签名认证功能。

在第一应用支持目标功能的应用时，第一设备可以获取第一设备中已存储的绑定相关信息。该绑定相关信息可以是第一设备与第二设备基于不同于第一应用和第二应用的而其他应用进行绑定时存储的信息，例如，第一设备可能曾经基于第三应用与第二设备中的第四应用进行过绑定，在基于第三应用与第四应用绑定时，第一设备和第二设备中分别可以存储该绑定相关信息。

示例性的，绑定相关信息可以包括第一设备相关的公钥信息、第二设备相关的公钥信息以及目标密钥信息。

第一设备相关的公钥信息可以为：第一设备与第二设备曾经利用其它应用绑定时，该其他应用的公钥信息，例如，第一设备可能曾经基于第三应用与第二设备中的第四应用进行过绑定，则第一设备相关的公钥信息可以为第三应用的公钥信息。该第三应用的公钥信息也可以是第一设备中默认的公钥信息。

类似的，第二设备相关的公钥信息，可以为第四应用的公钥信息，也可以为第二设备中默认的公钥信息。

目标密钥信息可以包括表1中的密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证ID、密钥所述应用的APK包名、或密钥附加信息中的一项或多项。

一种可能的实现方式中，第一基于第一应用的相关信息获取已存储的绑定相关信息。例如，第一应用为支持同签名认证功能的应用时，第一应用的密钥标签为ownerPubKey，第一设备可以基于ownerPubKey查找该已存储的绑定相关信息。当然，第一应用的相关信息也可以为密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证ID、密钥所述应用的APK包名、或密钥附加信息中的一项或多项，第一设备可以基于模糊匹配的方式，利用第一应用的相关信息得到该已存储的绑定相关信息。

一种可能的实现中，第一设备中可能存在本地密钥信息列表，本地密钥信息列表中可以包括多条已存储的绑定信息，则第一设备可以遍历多条已存储的绑定信息，得到适用的绑定相关信息。

S703、第一设备基于第一应用向第二应用发送通信请求，通信请求包括目标密钥信息。

示例性的，通信请求可以为业务转发authenticate请求报文，通信请求包括目标密钥信息，使得第二设备可以基于通信请求中的目标密钥信息，基于模糊匹配等在第二设备已存储的绑定相关信息，并从该绑定相关信息中获取第一设备相关的公钥信息。

S704、在第二设备确定第二应用为支持目标功能的应用时，第二设备根据目标密钥信息在第二设备已存储的绑定相关信息中获取第一设备相关的公钥信息。

第二设备确定第二应用为支持目标功能的应用的方式，以及第二设备利用目标密钥信息得到已存储的绑定相关信息以及第一设备相关的公钥信息的方式，可以参照S702和S703中第一设备类似的方式，不再赘述。

S705、在第一应用基于第二设备相关的公钥信息，以及第二应用基于第一设备相关的公钥信息互相认证通过时，第一应用与第二应用建立通信连接。

本申请实施例中，因为第一应用得到第二设备相关的公钥信息，所以在第二应用采用私钥加密验证信息后，第一应用可以成功解密，类似的，第二应用得到第一设备相关的公钥信息，所以在第一应用采用私钥加密验证信息后，第二应用可以成功解密，从而实现第一应用于第二应用的通信连接。

本申请实施例的设备通信方法中，可以复用第一设备与第二设备之前的应用绑定时的绑定相关信息，实现对后续其他应用的认证，不需要执行第一应用与第二应用之间的绑定关系，减少第一应用与第二应用之间的交互次数，因此可以提升第一应用与第二应用建立通信连接的效率，节约第一设备与第二设备的功耗。且，用户不需要执行绑定应用相关的操作，可以提升用户体验。

以第一设备与第二设备是基于第三应用和第四应用实现绑定为例，图8示出了第一设备与第二设备基于第三应用和第四应用实现绑定的流程示意图。如图8所示，方法可以包括：

S801、第一设备执行对第三应用的注册流程；其中，若第三应用支持同签名认证功能，将第三应用的密钥标签设置为第三应用的公钥；若第三应用不支持同签名认证功能，将第三应用的密钥标签设置为第三应用的业务类型。

本申请实施例中第三应用的公钥可以是第一设备分配的，可能的实现中，第一设备可以为加载在第一设备中的应用统一分配一个公钥。

与通常的应用注册流程不同的是，本申请实施例中，对第三应用注册时，若第三应用支持同签名认证功能，将第三应用的密钥标签设置为第三应用的公钥；若第三应用不支持同签名认证功能，将第三应用的密钥标签设置为第三应用的业务类型。这样，如果第三应用支持同签名认证功能，因为第三应用的密钥标签在注册时设置为公钥，则后续可以得到包括第三应用的公钥信息的绑定相关信息。

需要说明的是，具体的注册流程将在后续实施例详细说明，在此不再赘述。

S802、第二设备执行对第四应用的注册流程；其中，若第四应用支持同签名认证功能，将第四应用的密钥标签设置为第四应用的公钥；若第四应用不支持同签名认证功能，将第四应用的密钥标签设置为第四应用的业务类型。

第二设备执行对第四应用的注册流程与第一设备执行对第三应用的注册流程类似，在此不再赘述。

需要说明的是，S801和S802的执行没有先后顺序，注册流程可以是各应用加载到对应的设备时发起的，也可以是基于一定的用户触发发起的，本申请实施例不作具体限定。

S803、第一设备接收到用于指示通过第三应用向第二设备的第四应用发起通信的触发。

本申请实施例中，S803可以参照S701的说明，不同的是，S803第一设备对应为第三应用，第二设备对应的为第四应用，S701第一设备对应为第一应用，第二设备对应的为第二应用，原理类似，不再赘述。

S804、第一设备基于第三应用向第四应用发送绑定请求。

本申请实施例中，绑定请求可以为bind请求报文，绑定请求中可以包括目标密钥信息，则后续绑定成功后，可以得到包括目标密钥信息、第一设备相关的公钥信息、以及第二设备相关的公钥信息的绑定相关信息。

S805、第一设备基于第三应用和第二设备的第四应用实现绑定，以及第一设备和第二设备分别存储绑定相关信息。

本申请实施例对第一设备基于第三应用和第二设备的第四应用实现绑定的具体过程不作限定，可以基于绑定协议的相关规定，在第三应用和第四应用绑定后，第一设备和第二设备可以分别存储绑定相关信息，用于后续第一设备与第二设备之间的同签名认证。

S806、基于第三应用和第四应用执行设备认证流程，在认证通过的情况下，建立第三应用与第四应用之间的通信连接。

本申请实施例对第一设备基于第三应用和第二设备的第四应用执行认证流程的具体过程不作限定，可以基于认证协议的相关规定，在第三应用和第四应用认证通过后，第三应用与第四应用之间可以建立通信连接。

本申请实施例中，在第一设备中进行应用注册时，可以将支持同签名认证的第三应用的密钥标签设置为第一设备相关的公钥信息，在第二设备中进行应用注册时，可以将支持同签名认证的第四应用的密钥标签设置为第二设备相关的公钥信息，这样，后续第三应用与第四应用绑定后，可以得到包括目标密钥信息、第一设备相关的公钥信息、以及第二设备相关的公钥信息的绑定相关信息，以支持后续第一设备与第二设备之间的同签名认证。

综合上述实施例，本申请实施例的设备通信方法中，在第一设备和第二设备之间未曾通过应用绑定的情况下，第一设备可以基于进行过注册的第三应用，与第二设备中进行过注册的第四应用实现绑定，绑定时，第一设备和第二设备均可以存储绑定相关信息，后续在第三应用和第四应用需要建立通信连接时，可以执行认证本应用绑定的设备的流程；后续在的第一设备的第一应用与第二设备的第二应用之间需要通信时，可以复用绑定相关信息，执行认证同签名的其他应用绑定的设备的流程。

下面详细对上述涉及的流程进行详细介绍，各流程具体包括：应用在设备的注册流程、设备间应用绑定的流程、认证本应用绑定的设备的流程、以及认证同签名的其他应用绑定的设备的流程。可以理解，各流程可以在不同的阶段分别实现，也可以作为整体的流程实现，本申请实施例不作限定。

各流程的实现中，可以涉及到第一设备中的上层业务、设备认证服务SDK、设备认证服务和签名密钥管理服务，以及第二设备中的上层业务、设备认证服务SDK、设备认证服务和签名密钥管理服务，各服务的具体说明可以参照图2对应的实施例中的描述，在此不再赘述。

图9示出了一种应用在设备的注册流程示意图。需要说明的是，第一设备和第二设备中应用注册的流程可以一致，图7的注册流程的执行主体可以是第一设备，也可以是第二设备。

如图9所示，注册流程包括：

S901、注册本地设备。

例如，上层业务可以采用注册功能函数register Local Device(authId,serviceType,isPrivate)向设备认证服务SDK发起注册。

其中，注册功能函数可以翻译为注册本地设备(设备认证ID，业务类型，私有)。

S902、获取应用包名。

例如，设备认证服务SDK可以获取应用包名ownerPkgName(即密钥所属应用的apk包名)。

S903、注册生成身份密钥对。

例如，设备认证服务SDK可以向设备认证服务注册生成身份密钥对，注册生成身份密钥对时，所涉及的参数可以包括(ownerPkgName，serviceType，authID，isPrivate)，这些参数可以翻译为(密钥所属应用的apk包名，业务类型，设备认证ID，私有)。

S904、整合密钥信息。

例如，设备认证服务整合密钥信息可以包括：

获取应用apk签名公钥ownerPubKey。

设置密钥类型＝密钥对，即keyType＝KEY_PAIR。

判断如果isPrivate＝true，则keyAttribute＝sha256(ownerPkgName||serviceType)，如果isPrivate＝false，则keyAttribute＝sha256(ownerPkgName||ownerPubKey)。

上述判断过程可以翻译为：如果私有＝真，则密钥标签＝sha256(密钥所属应用的apk包名||业务类型)，如果私有＝假，则密钥标签＝sha256(密钥所属应用的apk包名||密钥所属应用的apk签名公钥)。

设置密钥别名＝sha256(密钥标签||密钥类型||设备认证ID)，即alias＝Sha256(keyAttribute||keyType||authId)。

设置密钥附加信息＝{本地ID＝设备认证ID}，即extInfo＝{localId＝authId}。

S905、注册生成身份密钥对。

例如，设备认证服务向签名密钥管理服务注册生成身份密钥对。

S906、生成ed25519密钥对，存储密钥信息。

例如，签名密钥管理服务生成ed25519密钥对，并存储密钥信息。

S907、返回密钥生成和存储结果。

例如，签名密钥管理服务向设备认证服务返回密钥生成和存储结果，进一步的，设备认证服务可以向设备认证服务SDK返回注册结果，设备认证服务SDK可以向上层业务返回注册结果。

需要说明的是，本申请实施例中，在应用支持同签名认证功能时，可以设置密钥标签为ownerPubKey，使得后续应用可以基于ownerPubKey实现对绑定相关信息的模糊匹配。

后续的流程中涉及第一设备和第二设备，为区分第一设备和第二设备，后续第一设备中的上述内部服务称为第一上层业务、第一设备认证服务SDK、第一设备认证服务和第一签名密钥管理服务，第二设备中的上述内部服务称为第二上层业务、第二设备认证服务SDK、第二设备认证服务和第二签名密钥管理服务。

图10示出了一种设备间应用绑定的流程示意图。如图10所示，以第一设备通过第三应用与第二设备的第四应用实现绑定为例，绑定流程包括：

S1001.设备绑定。

例如，第一上传业务可以对应第三应用，第一上层业务可以采用绑定功能函数bindDevice(opParams,PIN,keyLength)向第一设备认证服务SDK发起设备绑定。

绑定功能函数可以翻译为设备绑定(操作参数，PIN，密钥长度)。

S1002.获取应用包名。

例如，第一设备认证服务SDK可以获取第三应用的包名ownerPkgName(即密钥所属应用的apk包名)。

S1003.绑定。

例如，第一设备认证服务SDK可以向第一设备认证服务指示绑定，绑定时，所涉及的参数可以包括(ownerPkgName，opParams，PIN，keyLength)，这些参数可以翻译为(第三应用的应用包名，操作参数，PIN码，密钥长度)。

进一步的，第一设备认证服务可以执行S1004.1获取第三应用apk签名公钥：ownerPkgName，以及执行S1004.2获取第一设备的authId，keyAttribute和alias(ownerPkgName，serviceType，KEY_PAIR)，这些参数可以翻译为认证ID，密钥标签和密钥别名(应用包名，业务类型，密钥对)。

S1005.通过业务转发绑定请求报文。

例如，第一设备认证服务可以基于第一签名密钥管理服务、第二设备的第二签名密钥管理服务向第二设备的第二设备认证服务发送绑定请求报文，绑定请求报文可以包括参数(ownerPkgName，serviceType，clientAuthId)，这些参数可以翻译为(应用包名，业务类型，客户设备认证ID)。

S1006.接受请求。

例如，第二设备认证服务SDK可以采用功能函数onReceiveRequest(reqId，operation＝BIND)表示接收请求，该函数可以翻译为接受请求(异步请求标识，操作＝绑定)。

S1007.获取PIN码，密钥长度。

例如，第二设备认证服务SDK可以获取PIN码，密钥长度keyLength。用于后续的第二设备显示PIN码。

进一步的第二设备认证服务可以执行S1008.1获取第三应用的apk签名公钥：ownerPubKey，以及确定业务类型＝第一设备发来的业务类型；以及执行S1008.2获取第二设备的authId，keyAttribute和alias(ownerPkgName，serviceType,KEY_PAIR)，这些参数可以翻译为：认证ID，密钥标签和密钥别名(应用包名，业务类型，密钥对)。

S1009.第二设备认证服务基于密码认证密钥协商(password-authenticated keyagreement，PAKE)协议向第一设备认证服务转发报文。

可以理解的是，PAKE协议也可以替换为标准传输协议(standard transferspecification，STS)等，本申请实施例不作具体限定。

S1010.会话密钥返回。

例如，第一设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第一上层业务发返回会话密钥，该功能函数可以翻译为：会话密钥返回(异步请求标识，会话密钥)。

类似的，第二设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第二上层业务发返回会话密钥。

S1011.打包第一设备认证凭据。

例如，第一设备认证服务可以打包第一设备认证凭据。

S1012.第一设备认证服务向第二设备认证服务发送第一设备认证凭据。

S1013.第二设备认证服务验证和存储第一设备认证凭据。

例如，确定密钥类型＝公共密钥，密钥标签与第二设备的密钥对保持一致。

确定密钥别名＝Sha256(密钥标签||密钥类型||客户设备认证ID)。

S1014.第二设备认证服务打包第二设备的认证凭据。

S1015.第二设备认证服务向第一设备认证服务发送第二设备认证凭据

S1016.第一设备认证服务验证和存储第二设备认证凭据。

例如，验证密钥类型＝公共密钥，密钥标签与本地密钥对保持一致。

验证密钥别名＝Sha256(密钥标签||密钥类型||服务器设备认证ID)

第一设备和第二设备呼应验证密钥成功后，可以实现第三应用与第四应用的绑定。

需要说明的是，本申请实施例中，在第三应用与第四应用进行绑定时，第一设备和第二设备可以分别存储绑定相关信息，用于后续第三应用于第四应用的认证，或用于后续第一应用与第二应用的认证。

图11示出了一种认证本应用绑定的设备的流程示意图。示例性的，以认证已绑定的第三应用和第四应用为例，认证流程包括：

S1101.设备认证。

例如，第一上传业务可以对应第三应用，第一上层业务可以采用认证功能函数authDevice(opParams,keyLength)向第一设备认证服务SDK发起设备认证。

认证功能函数可以翻译为：设备认证(操作参数，密钥长度)。

S1102.获取应用包名。

例如，第一设备认证服务SDK可以获取第三应用的包名callerPkgName，密钥所属应用的apk包名ownerPkgName＝callerPkgName。

S1103.认证。

例如，第一设备认证服务SDK可以向第一设备认证服务指示认证，认证时，所涉及的参数可以包括(callerPkgName，opParams，owenerPkgName，null，keyLength)，这些参数可以翻译为(访客apk包名，操作参数，密钥所属应用的apk包名，空值，密钥长度)。

进一步的，第一设备认证服务可以执行S1104.1因为访客apk包名＝密钥所属应用的apk包名，判断认证的为本应用绑定的设备。以及执行S1104.2获取第一设备的authId，keyAttribute和alias(ownerPkgName，serviceType)，这些参数可以翻译为认证ID，密钥标签和密钥别名(密钥所属应用的apk包名，业务类型)。

S1105.通过业务转发认证。

例如，第一设备认证服务可以基于第一签名密钥管理服务、第二设备的第二签名密钥管理服务向第二设备的第二设备认证服务发送authenticate请求报文，authenticate请求报文可以包括参数(ownerPkgName，serviceType，clientAuthId)，这些参数可以翻译为(密钥所属应用的apk包名，业务类型，客户设备认证ID)。

S1106.接受请求。

例如，第二设备认证服务SDK可以采用功能函数onReceiveRequest(reqId，operation＝AUTHENTICATE)表示接收请求，该函数可以翻译为接受请求(异步请求标识，操作＝认证)。

S1107.获取密钥长度。

例如，第二设备认证服务SDK可以获取密钥长度keyLength。用于后续的第二设备进行密钥验证。

进一步的第二设备认证服务可以执行S1108获取第三应用的apk签名公钥：ownerPubKey，以及确定业务类型＝第一设备发来的业务类型；获取第二设备的authId，keyAttribute和alias(ownerPkgName，serviceType)，这些参数可以翻译为：认证ID，密钥标签和密钥别名(应用包名，业务类型)。

S1109.第二设备认证服务基于STS协议向第一设备认证服务转发报文。

可以理解的是，STS协议也可以替换为PAKE协议等，本申请实施例不作具体限定。

S1110.会话密钥返回。

例如，第一设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第一上层业务发返回会话密钥，该功能函数可以翻译为：会话密钥返回(异步请求标识，会话密钥)。

类似的，第二设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第二上层业务发返回会话密钥。

本申请实施例中，第三应用和第四应用执行过绑定流程，因此可以适应较为简洁的认证本应用绑定的设备的流程。可以理解的是，可能的实现方式中，第三应用和第四应用也可以执行如图12所示的认证流程，本申请实施例不作限定。

图12示出了一种认证同签名的其他应用绑定的设备的流程示意图。示例性的，以认证未绑定的第一应用和第二应用为例，认证流程包括：

S1201.设备认证(操作参数，密钥所属应用的apk包名，对端设备认证ID，密钥长度)

例如，第一上传业务可以对应第一应用，第一上层业务可以采用认证其他同签名应用绑定的设备的功能函数authDevice(opParams,ownerPkgName,peerAuthId,keyLength)向第一设备认证服务SDK发起设备认证。

S1202.获取应用包名。

例如，第一设备认证服务SDK可以获取第一应用的包名callerPkgName。

S1203.认证。

例如，第一设备认证服务SDK可以向第一设备认证服务指示认证，认证时，所涉及的参数可以包括(callerPkgName，opParams，owenerPkgName，peerAuhId，keyLength)，这些参数可以翻译为(访客apk包名，操作参数，密钥所属应用的apk包名，对端设备认证ID，密钥长度)。

进一步的，设备认证服务可以执行S1204.1-S1204.4的步骤。

S1204.1获取第一应用apk签名公钥：ownerPubKey。

S1204.2如果密钥所属应用的apk包名不为空值，密钥标签＝sha256(密钥所属应用的apk包名||密钥所属应用的apk签名公钥)，通过(密钥标签,密钥对)查询本地密钥信息加入本地密钥信息列表；如果密钥所属应用的apk包名为空值则获取同签名的本地密钥信息列表(密钥所属应用的apk签名公钥，密钥对)。

其中，本地密钥信息列表可以理解为第一设备中已存储的一个或多个绑定相关信息。

S1204.2采用密钥信息的英文形式可以表述为：如果ownerPkgName不为null，keyAttribute＝sha256(ownerPkgName||ownerPubKey)，通过(keyAttribute,KEY_PAIR)查询本地密钥信息加入本地密钥信息列表；如果ownerPkgName为null则获取同签名的本地密钥信息列表(ownerPubKey，KEY_PAIR)。

S1204.3从本地密钥信息列表中取出一个密钥，得到密钥的业务类型和密钥对应的设备的认证ID。

S1204.4若第二设备认证ID不为空值，则查询是否存在对应公钥，若不存在则返回S1204.3。

这样可以遍历本地密钥信息列表中已存储的绑定相关信息，以得到可以用于第一应用和第二应用进行认证的绑定相关信息。

S1205.通过业务转发认证。

例如，第一设备认证服务可以基于第一签名密钥管理服务、第二设备的第二签名密钥管理服务向第二设备的第二设备认证服务发送authenticate请求报文，authenticate请求报文可以包括参数(ownerPkgName，serviceType，clientAuthId)，这些参数可以翻译为(密钥所属应用的apk包名，业务类型，客户设备认证ID)。

S1206.接受请求。

例如，第二设备认证服务SDK可以采用功能函数onReceiveRequest(reqId，operation＝AUTHENTICATE)表示接收请求，该函数可以翻译为接受请求(异步请求标识，操作＝认证)。

S1207.获取密钥长度。

例如，第二设备认证服务SDK可以获取密钥长度keyLength。用于后续的第二设备进行密钥验证。

进一步的第二设备认证服务可以执行S1208.获取密钥所属应用的apk包名的apk签名公钥：ownerPubKey，以及确定业务类型＝第一设备发来的业务类型；获取第二设备的authId，keyAttribute和alias(ownerPkgName，serviceType)，这些参数可以翻译为：认证ID，密钥标签和密钥别名(应用包名，业务类型)

S1209.第二设备认证服务基于STS协议向第一设备认证服务转发报文。

可以理解的是，STS协议也可以替换为PAKE协议等，本申请实施例不作具体限定。

第一设备认证服务可以根据报文进行认证，若认证失败返回S1204.3，继续寻找可用的绑定相关信息。

S1210.会话密钥返回。

例如，第一设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第一上层业务发返回会话密钥，该功能函数可以翻译为：会话密钥返回(异步请求标识，会话密钥)。

类似的，第二设备认证服务可以采用onSessionKeyReturned(reqId，sessionKey)向第二上层业务发返回会话密钥。

本申请实施例的设备通信方法中，可以复用第一设备与第二设备之前的应用绑定时的绑定相关信息，实现对后续其他应用的认证，不需要执行第一应用与第二应用之间的绑定关系，减少第一应用与第二应用之间的交互次数，因此可以提升第一应用与第二应用建立通信连接的效率，节约第一设备与第二设备的功耗。且，用户不需要执行绑定应用相关的操作，可以提升用户体验。

需要说明的是，上述图9-图12以部分密钥相关的参数进行说明，具体应用中还可以结合需求选择图中部分参数，或添加其他的参数，本申请实施例不作具体限定。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的方法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对设备通信方法的装置进行功能模块的划分，例如可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图13所示为本申请实施例提供的一种芯片的结构示意图。芯片130包括一个或两个以上(包括两个)处理器1301、通信线路1302、通信接口1303和存储器1304。

在一些实施方式中，存储器1304存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。

上述本申请实施例描述的方法可以应用于处理器1301中，或者由处理器1301实现。处理器1301可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述第一设备或第二设备执行方法的各步骤可以通过处理器1301中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1201可以是通用处理器(例如，微处理器或常规处理器)、数字信号处理器(digital signal processing，DSP)、专用集成电路(applicationspecific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gatearray，FPGA)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件，处理器1301可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。

结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electricallyerasable programmable read only memory，EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器1304，处理器1301读取存储器1304中的信息，结合其硬件完成上述方法的步骤。

处理器1301、存储器1304以及通信接口1303之间可以通过通信线路1302进行通信。

在上述实施例中，存储器存储的供处理器执行的指令可以以计算机程序产品的形式实现。其中，计算机程序产品可以是事先写入在存储器中，也可以是以软件形式下载并安装在存储器中。

本申请实施例还提供一种计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如，可用介质可以包括磁性介质(例如，软盘、硬盘或磁带)、光介质(例如，数字通用光盘(digital versatile disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本申请实施例还提供一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质，还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。

作为一种可能的设计，计算机可读介质可以包括紧凑型光盘只读储存器(compactdisc read-only memory，CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器；计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且，任何连接线也可以被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，DSL或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，DSL或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD)，激光盘，光盘，数字通用光盘(digital versatile disc，DVD)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。

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

Claims (21)

1.一种设备通信方法，其特征在于，应用于通信系统，所述通信系统包括第一设备和第二设备，所述方法包括：

所述第一设备接收到用于指示通过第一应用向所述第二设备的第二应用发起通信的触发；

所述第一设备在确定所述第一应用为支持目标功能的应用时，获取所述第一设备中已存储的绑定相关信息，绑定相关信息包括所述第一设备相关的公钥信息、所述第二设备相关的公钥信息以及目标密钥信息；

所述第一设备基于所述第一应用向所述第二应用发送通信请求，所述通信请求包括所述目标密钥信息；

在所述第二设备确定所述第二应用为支持所述目标功能的应用时，所述第二设备根据所述目标密钥信息在所述第二设备已存储的所述绑定相关信息中获取所述第一设备相关的公钥信息；

在所述第一应用基于所述第二设备相关的公钥信息，以及所述第二应用基于所述第一设备相关的公钥信息互相认证通过时，所述第一应用与所述第二应用建立通信连接。

2.根据权利要求1所述的方法，其特征在于，在所述第一应用为支持所述目标功能的应用时，所述第一应用的密钥标签为所述第一设备相关的公钥信息；

在所述第二应用为支持所述目标功能的应用时，所述第二应用的密钥标签为所述第二设备相关的公钥信息。

3.根据权利要求2所述的方法，其特征在于，所述第一设备在确定所述第一应用为支持目标功能的应用时，获取所述第一设备中已存储的绑定相关信息，包括：

所述第一设备在确定所述第一应用为支持目标功能的应用时，所述第一设备基于所述第一应用的密钥标签，在存储在所述第一设备的本地密钥信息列表中得到所述绑定相关信息。

4.根据权利要求3所述的方法，其特征在于，所述存储在所述第一设备的本地密钥信息列表中包括多条绑定信息，任一条绑定信息为所述第一设备基于加载在所述第一设备中的应用执行绑定时存储的；

所述第一设备基于所述第一应用的密钥标签，在存储在所述第一设备的本地密钥信息列表中得到所述绑定相关信息，包括：

所述第一设备基于所述密钥标签，在存储在所述第一设备的本地密钥信息列表中得到多条绑定信息；

所述第一设备在所述多条绑定信息中取出任一条绑定信息的密钥，得到所述任一条绑定信息的密钥的业务类型和所述任一条绑定信息的密钥的设备认证标识；

若所述任一条绑定信息中存在所述第二设备的设备认证标识，则得到所述绑定相关信息。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述目标密钥信息包括下述的一项或多项：密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证标识、密钥所述应用的应用程序包APK包名、或密钥附加信息。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

所述第一设备执行对第三应用的注册流程；其中，若所述第三应用支持所述目标功能，将所述第三应用的密钥标签设置为所述第三应用的公钥；若所述第三应用不支持所述目标功能，将所述第三应用的密钥标签设置为所述第三应用的业务类型；

所述第二设备执行对第四应用的注册流程；其中，若所述第四应用支持所述目标功能，将所述第四应用的密钥标签设置为所述第四应用的公钥；若所述第四应用不支持所述目标功能，将所述第四应用的密钥标签设置为所述第四应用的业务类型。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

所述第一设备接收到用于指示通过所述第三应用向所述第四应用发起通信的触发；

所述第一设备基于所述第三应用向所述第四应用发送绑定请求；

所述第一设备基于所述第三应用和所述第二设备的所述第四应用实现绑定，以及所述第一设备和所述第二设备分别存储所述绑定中产生的绑定信息。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

所述第一设备的第三应用基于第一认证功能函数authDevice(opParams,keyLength)向所述第二设备的所述第四应用发起设备认证。

9.根据权利要求1-8任一项所述的方法，其特征在于，还包括：

所述第一设备的第一应用基于第二认证功能函数authDevice(opParams,ownerPkgName,peerAuthId,keyLength)向所述第二设备的所述第二应用发起设备认证。

10.一种设备通信方法，其特征在于，应用于通信系统，所述通信系统包括第一设备和第二设备，所述第一设备中加载有第一应用和第三应用，所述第二设备中加载有第二应用和第四应用，所述方法包括：

所述第一设备显示第一界面；所述第一界面包括第三应用中的待传输数据，以及所述第四应用的标识；

在所述第一界面中接收到用于将所述第三应用中的待传输数据向所述第四应用发送的触发的情况下，所述第二设备显示验证码或可扫描码；

所述第一设备显示用于输入所述验证码或用于扫描所述可扫描码的第二界面；

在所述第一设备在所述第二界面中接收到所述验证码输入或所述可扫描码的扫描操作时，所述第二设备在所述第二应用中显示传输的所述第三应用中的待传输数据；

所述第一设备显示第三界面；所述第三界面包括第一应用中的待传输数据，以及所述第二应用的标识；

在所述第三界面中接收到用于将所述第一应用的待传输数据向所述第四应用发送的触发时，所述第二设备在所述第二应用中显示传输的所述第一应用中的待传输数据。

11.根据权利要求10所述的方法，其特征在于，所述在所述第一界面中接收到用于将所述第三应用中的待传输数据向所述第四应用发送的触发，包括：在所述第一界面中接收到用于将所述第三应用中的待传输数据移动向所述第四应用所对应的区域的触发，或者，在所述第一界面中接收到点击所述第四应用的标识的触发。

12.根据权利要求10或11所述的方法，其特征在于，在所述第三界面中接收到用于将所述第一应用的待传输数据向所述第四应用发送的触发时，所述第二设备在所述第二应用中显示传输的所述第一应用中的待传输数据，包括：

在所述第三界面中接收到用于将所述第一应用的待传输数据向所述第四应用发送的触发的情况下，所述第一设备在确定所述第一应用为支持目标功能的应用时，获取所述第一设备中已存储的绑定相关信息，绑定相关信息包括所述第一设备相关的公钥信息、所述第二设备相关的公钥信息以及目标密钥信息；

所述第一设备基于所述第一应用向所述第二应用发送通信请求，所述通信请求包括所述目标密钥信息；

在所述第二设备确定所述第二应用为支持所述目标功能的应用时，所述第二设备根据所述目标密钥信息在所述第二设备已存储的所述绑定相关信息中获取所述第一设备相关的公钥信息；

在所述第一应用基于所述第二设备相关的公钥信息，以及所述第二应用基于所述第一设备相关的公钥信息互相认证通过时，所述第一应用与所述第二应用建立通信连接；

所述第一设备通过所述第一应用向所述第二应用发送所述待传输数据；

所述第二设备在所述第二应用中显示传输的所述第一应用中的待传输数据。

13.根据权利要求10-12任一项所述的方法，其特征在于，在所述第一应用为支持所述目标功能的应用时，所述第一应用的密钥标签为所述第一设备相关的公钥信息；

在所述第二应用为支持所述目标功能的应用时，所述第二应用的密钥标签为所述第二设备相关的公钥信息。

14.根据权利要求13所述的方法，其特征在于，所述第一设备在确定所述第一应用为支持目标功能的应用时，获取所述第一设备中已存储的绑定相关信息，包括：

所述第一设备在确定所述第一应用为支持目标功能的应用时，所述第一设备基于所述第一应用的密钥标签，在存储在所述第一设备的本地密钥信息列表中得到所述绑定相关信息。

15.根据权利要求14所述的方法，其特征在于，所述存储在所述第一设备的本地密钥信息列表中包括多条绑定信息，任一条绑定信息为所述第一设备基于加载在所述第一设备中的应用执行绑定时存储的；

所述第一设备基于所述第一应用的密钥标签，在存储在所述第一设备的本地密钥信息列表中得到所述绑定相关信息，包括：

所述第一设备基于所述密钥标签，在存储在所述第一设备的本地密钥信息列表中得到多条绑定信息；

所述第一设备在所述多条绑定信息中取出任一条绑定信息的密钥，得到所述任一条绑定信息的密钥的业务类型和所述任一条绑定信息的密钥的设备认证标识；

若所述任一条绑定信息中存在所述第二设备的设备认证标识，则得到所述绑定相关信息。

16.根据权利要求10-15任一项所述的方法，其特征在于，所述目标密钥信息包括下述的一项或多项：密钥别名、密钥标签、密钥类型、业务类型、密钥对应的设备的认证标识、密钥所述应用的应用程序包APK包名、或密钥附加信息。

17.根据权利要求10-16任一项所述的方法，其特征在于，所述方法还包括：

所述第一设备执行对第三应用的注册流程；其中，若所述第三应用支持所述目标功能，将所述第三应用的密钥标签设置为所述第三应用的公钥；若所述第三应用不支持所述目标功能，将所述第三应用的密钥标签设置为所述第三应用的业务类型；

所述第二设备执行对第四应用的注册流程；其中，若所述第四应用支持所述目标功能，将所述第四应用的密钥标签设置为所述第四应用的公钥；若所述第四应用不支持所述目标功能，将所述第四应用的密钥标签设置为所述第四应用的业务类型。

18.一种设备通信装置，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，以执行如权利要求1-9任一项所述的第一设备执行的通信方法，或者，以执行如权利要求10-17任一项所述的第一设备执行的通信方法。

19.一种设备通信装置，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，如权利要求1-9任一项所述的第二设备执行的通信方法，或者，以执行如权利要求10-17任一项所述的第二设备执行的通信方法。

20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有指令，当所述指令被执行时，使得计算机执行如权利要求1-9任一项所述的第一设备执行的通信方法，或者，或者，使得计算机执行如权利要求10-17任一项所述的第一设备执行的通信方法。

21.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有指令，当所述指令被执行时，使得计算机执行如权利要求1-9任一项所述的第二设备执行的通信方法，或者，使得计算机执行如权利要求10-17任一项所述的第二设备执行的通信方法。

Images