CN117014844A - 通信方法、电子设备和存储介质 - Google Patents

Abstract

本申请提供了通信方法、电子设备和存储介质。通信方法包括在第一电子设备处响应于确定与第一电子设备通信连接的第二电子设备在可信通信环境中并且具有账号能力，向第二电子设备传输第一电子设备的用于认证的公钥私钥对中的公钥。通信方法还包括存储用于非对称密钥认证的账号标识。本申请的实施例能够提升物联网设备的安全认证级别。

Description

通信方法、电子设备和存储介质

技术领域

本申请的实施例主要涉及物联网技术领域。更具体地，本申请的实施例涉及通信方法、电子设备、计算机可读存储介质以及计算机程序产品。

背景技术

随着智能家居设备的发展，越来越多的物联网(IoT)设备支持绑定到诸如智能手机、平板电脑等移动设备上。用户可以移动设备上安装的应用程序(App)来访问IoT设备，实现远程或本地控制。因此，移动设备和IoT设备需要在远程或者本地环境下进行安全认证。这给物联网技术带来了挑战。

发明内容

本申请的实施例提供了安全认证的方案。

根据本申请的第一方面，提供了一种通信方法。方法包括在第一电子设备处响应于确定与第一电子设备通信连接的第二电子设备在可信通信环境中并且具有账号能力，向第二电子设备传输第一电子设备的用于认证的公钥私钥对中的公钥。方法还包括存储用于非对称密钥认证的账号标识。

在第一方面的一些实施例中，确定与第一电子设备连接的第二电子设备在可信通信环境中可以包括：确定第一电子设备和第二电子设备已经建立本地通信连接。在一些实施例中，本地通信连接可以包括近端通信连接技术，具体地，本地通信连接可以包括以下至少一项：局域网连接、蓝牙连接、或者Zig-bee连接。局域网连接可以包括诸如Wi-Fi的无线接入网连接，或者是以太网连接。在第一方面的一些实施例中，确定与第一电子设备连接的第二电子设备在可信通信环境中还可以包括：在第一电子设备和第二电子设备之间的本地通信连接建立基于对称密钥认证的会话通道。

在第一方面的一些实施例中，确定与第一电子设备连接的第二电子设备在可信通信环境中还可以包括：基于第一电子设备或第二电子设备的识别码(PIN)与第二电子设备建立端到端加密通信。在一些实施例中，建立所述端到端加密通信可以包括：基于PIN和密码认证密钥协商(PAKE)协议，与第二电子设备协商会话密钥。

在第一方面的一些实施例中，确定第二电子设备具有账号能力可以包括以下至少一项：确定第二电子设备经由指定的端口连接到第一电子设备；或者确定从第二电子设备接收到账号能力标记。

在第一方面的一些实施例中，账号标识可以包括以下至少一项：在第二电子设备上登录的账号标识；或者与登录的账号标识相关联的账号标识。

在第一方面的一些实施例中，方法还可以包括：在第一电子设备处从第二电子设备接收证书机构(CA)针对第一电子设备的设备标识、第一电子设备的用于认证的公钥私钥对中的公钥以及账号标识的签名。

在第一方面的一些实施例中，第一电子设备可以包括IoT设备，并且第二电子设备可以包括移动设备。

根据本申请的第二方面，提供了一种通信方法。方法包括：在第一电子设备处确定第二电子设备是否处于不可信通信环境中。方法还包括：如果第二电子设备被确定为处于不可信通信环境中，允许从第二电子设备、经由基于对称密钥认证的会话通道传输的第一消息的操作，并且禁止从所述第二电子设备、经由所述基于对称密钥认证的会话通道传输的第二消息的操作，其中所述第二消息的安全级别高于所述第一消息。

在第二方面的一些实施例中，方法还可以包括：响应于第二消息的操作被禁止，生成建立基于非对称密钥认证的会话通道的提示，以及在非对称密钥认证的会话通道已建立之后，允许从第二电子设备、经由基于非对称密钥认证的会话通道传输的第二消息的操作。

在第二方面的一些实施例中，确定第二电子设备在不可信通信环境中可以包括：确定第一电子设备和第二电子设备之间的通信连接是远程通信连接。在一些实施例中，远程通信连接包括因特网连接，例如，第二电子设备经由因特网上的IoT平台来访问第一电子设备。

在第二方面的一些实施例中，方法还可以包括：如果第二电子设备被确定为处于可信通信环境中，则允许从第二电子设备、经由基于对称密钥认证的会话通道传输的第二消息的操作。

在第二方面的一些实施例中，确定所述第二电子设备在可信通信环境中包括：确定第一电子设备和第二电子设备之间的通信连接是本地通信连接，本地通信连接可以包括以下至少一项：局域网连接、蓝牙连接、或者Zig-bee连接。在一些实施例中，局域网连接可以包括诸如Wi-Fi的无线接入网连接，或者是以太网连接。

根据本申请的第三方面，还提供了一种电子设备，包括：至少一个计算单元；至少一个存储器，所述至少一个存储器被耦合到所述至少一个计算单元并且存储用于由所述至少一个计算单元执行的指令，所述指令当由所述至少一个计算单元执行时，使得所述电子设备执行根据本申请的第一方面或第二方法所述的方法。

根据本申请的第四方面，还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现根据本申请的第一方面或第二方面所述的方法。

根据本申请的第五方面，还提供了一种计算机程序产品，包括计算机可执行指令，其中所述计算机可执行指令被处理器执行时实现根据本申请的第一方面或第二方面所述的方法。

附图说明

结合附图并参考以下详细说明，本申请各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标注表示相同或相似的元素，其中：

图1示出了本申请的多个实施例能够在其中实现的示例环境的示意图；

图2示出了根据本申请的一些实施例的智能物联网系统的示意图；

图3a示出了根据本申请的一些实施例的交换对称认证凭据的过程的示意交互图；

图3b示出了根据本申请的一些实施例的交换对称认证凭据的另一过程的示意交互图；

图3c示出了根据本申请的一些实施例的基于对称认证凭据建立会话通道的过程的示意交互图；

图4示出了根据本申请的一些实施例的基于非对称认证凭据的认证过程的示意图；

图5示出了根据本申请的一些实施例的基于非对称认证凭据建立会话通道的过程的示意交互图；

图6示出了根据本申请的一些实施例的提升设备认证安全级别的过程的示意交互图；

图7示出了根据本申请的一些实施例的提升设备认证安全级别的另一过程的示意交互图；

图8示出了根据本申请的一些实施例的能够相互认证的物联网设备的示意框图；

图9示出了根据本申请的一些实施例的物联网设备之间建立会话通道的过程的示意交互图；

图10示出了根据本申请的一些实施例的物联网设备的访问控制系统的示意图；

图11示出了根据本申请的一些实施例的通信方法的示意流程图；

图12示出了根据本申请的一些实施例的另一通信方法的示意流程图；

图13出了可以用来实施本申请内容的实施例的示例设备的示意性框图。

具体实施方式

下面将参照附图更详细地描述本申请的实施例。虽然附图中显示了本申请的某些实施例，然而应当理解的是，本申请可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本申请。应当理解的是，本申请的附图及实施例仅用于示例性作用，并非用于限制本申请的保护范围。

在本申请的实施例的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

在智能家居应用中，用户可以使用移动设备来访问或控制物联网(IoT)设备。IoT设备与移动设备之间的连接一般采用Wi-Fi、蓝牙、Zig-bee等无线连接技术。支持Wi-Fi协议的IoT设备可以通过IP协议直接连接互联网从而接入IoT智能家居平台(下文简称为“IoT平台”)，而只支持蓝牙或Zig-bee等协议的设备则不能直接访问互联网，一般通过蓝牙、Zig-bee网关转换成IP协议后再访问IoT智能家居平台。由此，移动设备可以在本地或远程地访问和控制IoT设备。

在使用移动设备控制IoT设备之前，一般要对IoT设备进行绑定，建立IoT设备与用户账号的对应关系，以便在控制IoT设备时对控制者的身份做验证。通常，在控制设备和被控IoT设备互通之前，需要经过协商认证，在建立安全会话通道之后才能继续应用层操作。传统的方案使用对称认证凭据(本文中有时也称为“对称密钥”)进行身份认证和建立会话通道。一般在控制设备和被控IoT设备的绑定期间交换对称认证凭据。对称认证凭据通常在设备绑定期间由控制设备、IoT设备或智能家居中枢设备、IoT平台其中一方生成，并在绑定时的本地安全会话中同步到其他网元。

然而，在使用对称认证凭据进行认证时存在如下问题：控制设备和被控IoT设备都拥有相同的凭据，一旦被泄露，攻击者利用凭据控制IoT设备，将无法追溯凭据是哪里被泄露的，也无法单独限制攻击者不能再控制IoT设备，只能使整个对称认证凭据失效。因此，对称密钥方案的安全性较低。另一方面，在通过用户账号和IoT设备之间的绑定关系实现远程控制的场景下，对称身份凭据需要上传到IoT平台，这进一步加剧了对称认证凭据泄露的风险。

有鉴于此，本申请的实施例提供了一种通信方法。根据该方法，第一电子设备(例如，IoT设备)确定与第一电子设备通信连接的第二电子设备(例如，移动设备)是否在可信通信环境中并且具有账号能力。如果确定第二电子设备在可信环境且具有账号能力，则第一电子设备向第二电子设备传输第一电子设备的用于认证的公钥私钥对中的公钥。IoT设备还存储用于非对称密钥认证的账号标识。基于这样的方式，在满足可信通信环境的情况下，将第一电子设备和第二电子设备之间的身份认证机制提升为更为安全的非对称密钥的认证，并且这种非对称密钥认证适用于基于用户账号的远程控制。

本申请的实施例还提供了一种通信方法。根据该方法，第一电子设备(例如，IoT设备)确定第二电子设备(例如，移动设备)是否处于不可信通信环境中。如果第二电子设备处于不可信通信环境中，则第一电子设备允许从第二电子设备、经由基于对称密钥认证的会话通道传输的第一消息的操作，并且禁止从第二电子设备、经由基于对称密钥认证的会话通道传输的第二消息的操作，其中所述第二消息的安全级别高于所述第一消息。基于这样的方式，在不满足可信通信环境的情况下，第一电子设备可以实现安全级别的分级操作，提升了系统的整体安全性。

示例环境

图1示出了本申请的多个实施例能够在其中实现的示例环境的示意图。如图1所示，该系统包括多个电子设备，例如示例性示出的电子设备200、电子设备101、电子设备102、电子设备103、电子设备104等。系统内的各个电子设备可按照一定的通信协议和组网策略组建网络(即组网)，使得系统内的各个电子设备之间可以互相通信。例如，该系统中的各个电子设备之间可以通过无线通信方式连接。例如至少可以通过以下至少一种连接方式建立连接：蓝牙、低功率蓝牙、近场通信、无线保真(Wi-Fi)、Zig-Bee、以太网连接等

本申请实施例对电子设备(例如电子设备200、电子设备101、电子设备102、电子设备103或电子设备104)的类型不做具体限定，在一些实施例中，本申请实施例中的电子设备可以是手机、可穿戴设备(例如智能手环、智能手表、耳机等)、平板电脑、膝上型计算机(laptop)、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(Augmented reality，AR)\虚拟现实(virtual reality，VR)设备等设备，还可以是电视、大屏、音箱、电视机、冰箱、空调、车载设备、打印机、投影仪等设备。电子设备的示例性实施例包括但不限于搭载Harmony或者其它操作系统的电子设备。

在一些实施例中，电子设备200、电子设备101、电子设备102、电子设备103和电子设备104可以通过有线或无线连接的方式连接至局域网(LAN)。电子设备200、电子设备101、电子设备102、电子设备103和电子设备104通过局域网进行互相通信。其中电子设备200、电子设备101、电子设备102、电子设备103和电子设备104还可以通过局域网中的第三方设备进行互相通信，第三方设备例如是路由器、网关、智能设备控制器等。电子设备200、电子设备101、电子设备102、电子设备103和电子设备104还可以经由第三方设备连接到因特网，例如，连接到智能家居云平台或其他电子设备。在一些实施例中，电子设备200、电子设备101、电子设备102、电子设备103和电子设备104还可以具有直接连接到因特网的能力。例如，电子设备200可以是手机，其通过移动运营商网络连接到因特网。

在一些实施例中，电子设备200、电子设备101、电子设备102、电子设备103和电子设备104中的至少一部分可以在地理位置相同或相近的区域(例如，可以通过本地通信连接彼此通信，如Wi-Fi、蓝牙、ZigBee、局域网)，从而构建智能家居环境。而一部分电子设备(例如，电子设备200)可以不在智能家居环境中，并且能够经由因特网来远程访问智能家居环境中的电子设备或IoT平台。

在一些实施例中，电子设备200、电子设备101、电子设备102、电子设备103和电子设备104中的一些电子设备可以安装应用程序，并且在应用程序上登录账号标识。电子设备200、电子设备101、电子设备102、电子设备103和电子设备104中的一些电子设备可以不具有账号能力。上述账号可以为云服务器提供商为用户提供的账号，如华为账号，还可以为用于登录应用程序的账户，如各类通讯软件的账户、支付软件的账户等。

可以理解的，本申请实施例示出的结构并不构成对系统架构的具体限定。在本申请另一些实施例中，系统架构可以包括比图示更多或更少的设备。

示例智能物联网系统

图2示出了根据本申请的一些实施例的智能物联网系统的示意图。如图所示，智能物联网系统包括经由网络彼此连接的移动设备200、智能家居210、IoT平台230、证书机构(CA)服务240。

移动设备200可以是具有能够安装应用并登录用户账号的设备，例如智能手机、平板电脑、笔记本电脑等。移动设备200可以通过移动运用商网络连接到因特网，或者可以本地连接到第三方设备(例如，路由器)来连接到因特网，由此可以访问因特网上的其他设备(例如，CA服务240、IoT平台230以及智能家居210中的任何设备)。在一些实施例中，移动设备200可以通过运行应用程序来访问或控制智能家居210中的与用户账号绑定的设备。

智能家居210部署有组网的智能设备。智能设备可以包括一个或多个中枢设备204和一个或多个IoT设备206和208。中枢设备204集成了智能家居业务中枢服务，一般可以是常驻家庭中的、且长电设备，例如智能音箱、智能电视、智能路由器、机顶盒等。在一些实施例中，中枢设备204可以具有认证凭据分配能力。例如，在智能家居的前装阶段，中枢设备204可以为家居环境中的IoT设备206和208生成对称认证凭据，并且中枢设备204还可以在智能家居的前装阶段将生成的IoT设备206和208的对称认证凭据分配给移动设备200。由此，移动设备200与IoT设备206和208可以通过对称认证凭据进行认证并建立会话通道。应理解，中枢设备204也可以作为普通的IoT设备206和208来操作，也可以被称为IoT设备。

IoT设备206和208可以包括智能家居设备，例如智能门铃、智能门锁、电冰箱、洗衣机等带智能控制的IoT设备。IoT设备206和208可以被中枢设备204控制、彼此控制、被处于智能家居210中的移动设备(未示出)本地控制、或者可以通过连接到IoT而被移动设备200远程控制。

IoT平台230也被称为IoT智能家居云平台，可以部署在因特网中。IoT平台230用于实现智能家居210中的设备的远程控制等功能。在一些实施例中，IoT平台230可以存储用户账号信号、移动设备200和智能家居210中的设备(包括中枢设备204、IoT设备206和208等)的认证凭据。在一些实施例中，认证凭据可以包括用于对称密钥认证的对称密钥和用于非对称密钥认证的公钥私钥对中的公钥。由此，移动设备200与智能家居210中设备204、206、208之间可以通过对称认证凭据进行认证，或者可以通过非对称认证凭据进行认证。当移动设备200、中枢设备204、IoT设备206和208登录到IoT平台230时将相关联的认证凭据同步到本地。在一些实施例中，IoT平台230还可以为智能家居210中的设备204、206、208生成作为设备唯一标识的设备标识。

CA服务240可以用于为移动设备签发账号证书。CA服务使用公钥私钥对中的私钥对相关信息进行签名，所生成的签名可以通过在网络上公开的CA根证书来验证被签名的相关信息的真实性。在一些实施例中，移动设备200可以将自身的认证凭据(例如，公钥私钥对中的公钥)、账号标识、名称、设备型号等信息传输给CA服务，由CA服务240这些信息进行签名而生成账号证书。账号证书可以被存储在移动设备200，用于基于非对称密钥的身份认证和建立安全会话通道。

在一些实施例中，CA服务240可以对中枢设备204、IoT设备206、IoT设备208中的任一个的认证凭据(例如，用于身份认证的公钥私钥对中的公钥)、设备标识、相关联的账号标识等信息进行签名。签名可以被返回和存储设备中，用于主控设备204、IoT设备206、IoT设备208之间的身份认证和建立安全会话通道。

以上仅示出了根据本申请实施例的示例性智能IoT系统。本领域技术人员应理解，该系统中还可以包括更多或更少移动设备，中枢设备和IoT设备，并且设备之间的连接不限于如图2所示的，例如，移动设备200还可以通过本地通信，而不是远程通信与中枢设备和IoT设备中的任一个进行连接。

对称密钥认证

为了实现全套的智能家居解决方案，IoT解决方案商可以与地产公司，在地产项目交付给最终住户之前的装修阶段，就将智能设备安装并调试完成，待最终用户待入住可以直接实现IoT设备的控制以及IoT设备的自动化本地联动。

在前装配置时，一般房屋内具有IP网络、Wi-Fi的，但是一般没有访问互联网的能力，因为一般访问互联网需要用户办理宽带业务，考虑到用户会选择的宽带运营商(电信、移动、联通、网通等)以及不同的宽带套餐，地产商的房屋精装一般不会直接给住户办好宽带业务。

由于没有互联网，前装工程师在调测IoT设备、设置自动化联动规则时，只能在本地家居中枢设备(例如，常驻在家庭中且长电设备，例如智能音箱、智能电视、智能路由器、机顶盒等设备)上调测。但是设备注册以及规则数据不会上传到IoT云平台，因为一般IoT云平台要求验证账号和密码(例如，华为账号或者智能家居提供商的账号)，且不能确定最终用户使用什么账号登录，所以一般交房前的前装配置都是无账号的。

前装相较于后装来说，可以在装修时对家庭中的设备安装部署进行规划、预埋线等，故前装多使用有线(网线或PLC)。后装IoT设备一般是在装修后再安装，此时已经不便对房屋内的布线进行改造，因此后装IoT设备大多是无线连接(例如，Wi-Fi、Zig-bee、Z-Wave、蓝牙等)。

当房屋的最终住户收房入住后，可以直接使用前装配置的IoT设备，但是由于前装设备配置并未绑定账号，所以无法被远程控制，或者跟用户自己购买的IoT设备联动。在用户给家里办了宽带，家里的网络可以访问互联网后，要实现前装设备的远程控制以及跟其他后装设备联动，用户需要将前装设备绑定到自己的账号上。IoT解决方案商为了避免用户一个一个的去绑定前装设备，一般会提供一键交房/注册功能，一次性将所有前装IoT设备注册到IoT云平台，绑定到用户的指定账号上，最终可以通过登录了该用户账号的移动设备(安装有对应的应用程序)来实现本地和/或远程控制。用户可以编辑IoT设备的联动规则，还可以把这些IoT设备共享给其他家庭成员账号控制。

前装无互联网无账号下的情况时，由于无法连接证书机构(CA)服务器，也无法将装维人员的账号配置到IoT设备中，故不能采用基于账号和认证公私钥对的非对称密钥认证方案。这种情况下，可以采用对称密钥方案，由一个常驻本地的中枢设备存储和维护本地绑定的设备信息(包括IoT设备标识和对称密钥形式的认证凭据)。用户可以使用移动设备来获取智能家居中的前装IoT设备的对称认证凭据，如图3a所示。

图3a示出了根据本申请的一些实施例的交换对称认证凭据的过程的示意交互图。移动该设备200可以本地连接到IoT设备206，通过与IoT设备206交互进行前装设备配网301。然后，IoT设备206可以向中枢设备204发送302设备本地注册请求。中枢设备204可以生成303对称密钥，并且将对称密钥下发给IoT设备206。由此，IoT设备206获取到对称密钥来作为用于认证的身份凭据。中枢设备204还可以在移动设备200上线时将用于IoT设备206的对称密钥下发304给移动设备200。在一些实施例中，移动设备200可以将IoT设备208的对称密钥长期保存在本地，或者可以在连接到中枢设备204上线时从中枢设备204获取最新的对称密钥。在一些实施例中，对称密钥可以由IoT设备206自身生成，并且传输给中枢设备204。基于这种方式，移动设备200可以与智能家居环境中的前装IoT设备交互对称身份凭据。在一些实施例中，IoT设备206的身份凭据(即，用于认证的对称密钥)可以是厂商预先生成的并存储在IoT设备中。

一些实施例中，移动设备200可以将接收到的IoT设备的身份凭据以及在设备上登录的账号标识传输到IoT平台。此后，每当移动设备200使用账号标识登录IoT平台，可以下载与其绑定的IoT设备的身份凭据用于认证。

用户还可以购买新的IoT设备。为了使新的IoT设备加入智能家居系统，用户可以使用移动设备对IoT设备进行绑定，建立IoT设备和账号标识之间的对应关系，以便在用户使用移动设备控制IoT设备时进行认证。在绑定时，移动设备和IoT设备交互身份凭据，如图3b所示。

图3b示出了根据本申请的一些实施例的交换对称认证凭据的另一过程的示意交互图。移动设备200可以通过手工输入或扫描二维码的方式来获得IoT设备206的身份识别码(PIN)。通常，可以认为能够获取IoT设备的PIN的设备在可信通信环境中，例如，与IoT设备都在本地。在一些实施例中，也可以由移动设备200来提供PIN，在IoT设备上输入PIN。本公开对此不做限制。

然后，在动作312处，基于PIN，移动设备200向IoT设备206发送绑定请求。IoT设备206接收绑定请求，并且在动作313处，验证移动设备200具有PIN并生成313随机数salt。然后，在动作314处，IoT设备206向移动设备发送该随机数salt。

在动作315处，移动设备200可以基于PIN和随机数salt生成移动设备200侧的公钥私钥对。在一些实施例中，可以基于口令认证密钥协商(PAKE)协议来生成上述公钥私钥对。然后，移动设备200向IoT设备206传输316所生成的公钥私钥对中的公钥。在动作317处，IoT设备206基于PIN和随机数salt生成用于IoT设备的公钥私钥对，并且根据对方的公钥来本地的私钥生成共享会话密钥。应理解，IoT设备侧的公钥私钥不同于移动设备侧的公钥私钥对。接下来，在动作318处，IoT设备206向移动设备200传输IoT设备侧的公钥。在动作319处，移动设备200根据接收到的IoT设备侧的公钥和本地私钥生成共享会话密钥。至此，由于移动设备200和IoT设备具有共享秘密(PIN)，所以可以生成相同的共享会话密钥。最后，在动作320处，移动设备200和IoT设备206使用所生成的共享会话密钥加密传输，交换IoT设备的对称认证凭据。

根据本申请的实施例，移动设备200可以使用IoT设备的对称认证凭据来建立与IoT设备的加密会话通道。图3c示出了根据本申请的一些实施例的基于对称认证凭据建立会话通道的过程的示意交互图。

在图3c所示的交互过程中，移动设备200和IoT设备206可以处于位置彼此接近的本地环境中，二者可以通过本地通信连接进行通信，例如，通过有线或无线局域网、Wi-Fi、蓝牙、ZigBee等。

在动作321，IoT设备206已经具有了自身的对称认证凭据。在一些实施例中，对称认证凭据可以是IoT设备206自身生成的，设备制造商生成的并预先配置的，还可以是IoT设备注册到中枢设备时由中枢设备生成并分配的，或者可以是IoT设备通过因特网(例如，经由智能家居的路由器)连接到IoT云平台时由云平台生成并分配的。在动作322处，移动设备200获取IoT设备206的对称认证凭据。例如，移动设备通过图3a和图b描述的过程获取IoT设备206的对称身份凭据。因此，IoT设备206和移动设备200具有共享的对称认证凭据。

在动作323处，移动设备200通过发送组播来发现周边的IoT设备。在动作324处，移IoT设备206以单播方式向移动设备200返回设备信息(例如，IoT设备206的设备标识)。

在动作325处，移动设备200根据返回的设备信息，确定IoT设备206是自身的身边并生成随机数RN1。在动作326处，移动设备200向IoT设备206传输会话协商请求，会话协商请求携带RN1。在动作327处，IoT设备206生成另一个随机数RN2，并且基于共享的对称认证凭据、随机数RN1、随机数RN2生成会话密钥。在动作328处，IoT设备206向移动设备200传输会话协商响应，会话协商响应协议随机数RN2。在动作329处，移动设备200基于共享的对称认证凭据、随机数RN1、随机数RN2生成会话密钥。

由于移动设备200和IoT设备206具有相同的对称认证凭据、随机数RN1和随机数RN2，所以它们可以生成相同的会话密钥。由此，IoT设备206和移动设备200实现了彼此的身份认证。

在动作330，移动设备200使用会话密钥加密并下发控制指令。IoT设备206可以使用相同的会话密钥来解密控制指令。

尽管图3c示出了移动设备200通过本地连接与IoT设备206进行认证并下发控制指令，移动设备200还可以通过远程连接与IoT设备206进行认证和控制。在这种情况下，移动设备200和IoT设备206可以通过IoT云平台来传输消息。在一些实施例中，为了实现基于账号标识的认证(用户可能使用不同的移动设备来访问IoT设备)，IoT设备的对称认证凭据存储在IoT云平台中。这给移动设备和IoT设备之间的远程通信带来了安全风险。例如，如果IoT设备的对称身份凭据被泄露，将无法追踪攻击者的来源。为此，本申请的实施例还提供了安全级别更高的非对称密钥认证。

非对称密钥认证

非对称秘钥认证是指，通信双方分别使用非对称秘钥做认证凭据，在认证时交换公钥，并且使用对方的公钥校验对方的私钥签名以确保双方的身份是正确的。在本文中，用于认证的非对称密钥(公钥和私钥)也被称为长效公钥和长效私钥。与此对应地，设备还可以生成临时公钥私钥对，临时公钥私钥对可以用于生成对会话通道的数据进行加密的会话密钥，从而实现端到端加密通信。以下将结合图4和图5描述根据本申请的实施例的非对称密钥认证和建立端到端加密通信的过程。

图4示出了根据本申请的一些实施例的基于非对称认证凭据的认证过程的示意图。图4以移动设备200作为控制设备、IoT设备206作为被控设备来说明基于非对称密钥的认证过程。应理解，控制设备还可以是能够连接到互联网的其他电子设备，例如智能家居中的中枢设备或其他IoT设备等。

如图4所示，移动设备200包括账号证书402和证书私钥404。在一些实施例中，移动设备200可以在连接到互联网时，例如用户在移动设备200的智能家居应用上登录账号标识时，向互联网中的认证机构(CA)服务240申请证书，请求CA服务对相关信息进行签名。

在一些实施例中，移动设备200可以生成用于非对称密钥认证的公钥私钥对。该公钥和私钥也称为长效公钥和长效私钥。长效私钥被存储在移动设备200处，作为证书私钥404。移动设备200向CA服务240发送公钥，请求CA服务240使用CA私钥进行该公钥签名。在一些实施例中，移动设备200还可以向CA服务240发送账号标识、设备型号、安全级别、安全能力、运行环境等信息，请求CA服务240对这些信息进行签名。CA服务240对来自移动设备200的相关信息进行签名，生成账号证书402，发送回并存储在移动设备200处。在认证阶段，账号证书402可以被发送给IoT设备206，由IoT设备206验证其有效性。

证书私钥404是移动设备200的长效私钥，被移动设备200用于生成签名，例如，移动设备200可以使用证书私钥对会话信息(例如，移动设备200与IoT设备的认证过程产生的随机数，例如，本次会话中产生的临时公钥)进行签名。

移动设备200还包括与其绑定的IoT设备的列表，IoT设备的列表包括关于IoT设备的条目。如图所示，每个条目可以包括IoT设备的设备标识406和设备公钥408。在一些实施例中，移动设备200可以直接从IoT设备206获取设备标识406和设备公钥408，或者经由IoT云平台230来获取设备标识406和设备公钥408。

IoT设备206存储有账号标识412。账号标识412表示该IoT设备206的拥有者。IoT设备206可以根据账号标识412来验证移动设备200是否被允许访问和控制IoT设备206。在一些实施例中，IoT设备206还可以包括其拥有者设备设置的分享账号标识(未示出)。分享账号标识的其他移动设备也可以访问和/或控制IoT设备206。分享账号标识的移动设备可以被设置有相关联的访问权限。

IoT设备206还存储有CA根证书414。CA根证书414可以是从CA服务240获取的，或者通过其他方式获取。CA根证书414包括CA服务的公钥，IoT设备206可以使用CA服务240的公钥来验证账号证书的有效性。

IoT设备206还包括设备自身的设备标识416，以及用于非对称密钥认证的设备公钥418和设备私钥419。类似地，设备私钥419用于产生IoT设备206的签名(例如，会话信息的签名)，而设备公钥418可以被发送到移动设备200，由移动设备200用来验证签名。

尽管图4示出了移动设备200和IoT设备206分别包括用于非对称密钥认证的身份凭据(公钥、私钥、账号证书等)，但是应理解，移动设备200和IoT设备206还可以包括用于对称密钥认证的身份凭据(例如，对称密钥)。由此，移动设备200和IoT设备206之间可以按照多种模式进行身份认证，提供不同的安全级别。

根据本申请的实施例，移动设备200可以基于来自IoT设备206的签名和设备标识416验证IoT设备206是否为指定设备，并且IoT设备206可以基于来自移动设备200的账号证书402和签名来验证移动设备200上的账号。在通过彼此认证的情况下，移动设备200和IoT设备206可以协商会话密钥并建立端到端加密通信。以下参考图5描述该过程。

图5示出了根据本申请的一些实施例的基于非对称认证凭据建立会话通道的过程的示意交互图。在图5所示的实施例中，移动设备200和IoT设备206经由IoT云平台230进行认证和协商会话密钥。应理解，移动设备200和IoT设备206也可以在没有IoT云平台230的情况下实现基于非对称认证凭据的认证。

如图5所示，在动作501处，IoT设备206登录到IoT云平台230。例如，IoT设备206可以经由智能家居中的中枢设备(例如，智能路由器)登录到互联网中的IoT云平台230。在一些实施例中，IoT设备206可以将设备标识和设备的认证凭据(例如长效私钥)上传到IoT云平台230。

在动作502，移动设备200使用账号标识登录到IoT云平台230。在动作503，移动该设备200从IoT云平台230获取与该账号标识相关联的设备列表，设备列表可以包括设备标识406和设备公钥408。在一些实施例中，账号标识和相关联的设备列表可以在启用非对称密钥认证机制时上传到IoT云平台230，如下文参考图6所描述。基于这种方式，在用户使用多个移动设备的情况下，通过账号标识来访问和控制IoT设备206。

在动作504，移动设备200生成移动设备侧的临时公钥私钥对。在动作505，移动设备200经由IoT云平台230向IoT设备206传输所生成的临时公钥私钥对中的临时公钥。

在动作506，IoT设备206生成IoT设备侧的临时公钥私钥对，并且使用临时私钥和接收到的移动设备200的临时公钥生成会话密钥，例如，通过椭圆曲线算法(如ECDH算法)。在动作506，IoT设备206还可以使用长效私钥(即，非对称认证凭据中的私钥)对会话信息进行签名，生成签名会话信息。在一些实施例中，会话信息可以是IoT设备206和移动设备206彼此已知的随机数据(IoT设备和移动设备生成的临时公钥)。

然后，在动作507，IoT设备206向移动设备200传输IoT设备206的临时公钥和使用会话密钥的签名会话信息。在动作508，移动设备200使用接收到的临时公钥和自身生成的临时私钥生成会话密钥，例如，通过椭圆曲线算法(如ECDH算法)。在动作508，移动设备200还使用会话密钥解码签名会话信息，并使用IoT设备206的设备公钥408(长效公钥)来验证签名，由此对IoT设备206进行认证。在认证通过之后。由此使用账号证书私钥404对会话信息进行签名，生成签名会话信息。

在动作509，移动设备200经由IoT云平台230传输账号证书402和签名会话信息。在一些实施例中，移动设备200使用所生成的会话密钥对账号证书和签名会话信息进行加密，将加密后的账号证书和签名会话信息传输到IoT设备206。

在动作510，IoT设备206使用会话密钥解码账号证书和签名会话信息，并且使用CA根证书414来验证账号证书的有效性。在账号证书的有效性被验证通过之后，IoT设备206使用账号证书中的移动设备200的长效公钥来验证签名会话信息，并且验证账号证书中的账号标识是否与本地的账号标识412匹配。如上所述，本地的账号标识可以是IoT设备206的拥有者的账号标识或者分享账号标识，因此可以用多个账号来访问和控制IoT设备206。由此，IoT设备206对移动设备200进行认证。

在移动设备200和IoT设备206彼此的认证通过之后，移动设备200和IoT设备206之间建立会话通道。在动作511，移动设备200和IoT设备206使用上述会议密钥在该会话通道上加密传输消息，例如，移动设备200下发控制指令，或者IoT设备206上报状态数据等。

应理解，图5所示交互图中的动作仅是示例性的，根据本申请实施例的交互可以包括更多或更少的交互动作，并且动作的顺序可以与图5所示不同。

以上描述了使用基于账号标识的非对称密钥认证。相比于对称密钥认证，其优点在于安全性更高。例如，一旦用户发现了某个设备丢失或者数据泄露后，可以指示CA服务240吊销指定控制设备的账号证书。另外，账号证书中可以对控制设备的其他信息进行签名，例如控制设备的安全级别、安全能力、运行环境等。IoT设备可以根据证书中声明的能力等级，接受对应级别的控制，例如对于高敏感操作，必须拥有特定安全硬件的控制设备才能控制。

非对称密钥认证还可以实现端到端加密。作为身份凭据，非对称密钥中的私钥只有控制设备和被控设备自身才拥有，所以中间透传消息的网元(例如，远程控制时转发控制指令的IoT云平台)无法假冒任何一方。并且，根据椭圆曲线算法(例如，ECDH算法)生成会话密钥，中间的网元也无法破解会话密钥，从而可以实现更为安全的端到端加密。

另外，根据本申请的一些实施例，采用账号证书的公私钥对作为控制设备的身份凭据，被控制设备可以使用CA服务的根证书来认证账号证书是否CA签发、是否已经被吊销，再判断证书中签名的账号标识是否是绑定自己账号的用户标识。基于这种实现方式，同一个账号的不同控制设备的公私钥对是不一样的，不需要将同账号不同控制设备的身份凭据同步到云平台，身份凭据通过CA服务器签发即可，存储在控制设备本地即可。因此，可以减少身份凭据泄露的风险。

安全认证级别提升

根据本申请的实施例，一些IoT设备可以支持对称密钥认证方案和非对称密钥认证方案中的一个或二者。然而，一些IoT设备对安全级别较高，在使用对称密钥认证方案的情况下必须限制控制设备对IoT设备的访问。

例如，对于具有蓝牙和Wi-Fi连接能力的智能门锁设备来说，蓝牙传输由于其带宽和传输速率限制，不适宜传输大报文以及密钥协商复杂的协议，因此一般蓝牙通道采用较为简单的对称密钥协商认证方案。但当用户后续开启了Wi-Fi模块将设备注册到云，想要在移动设备上通过IoT云平台对智能门锁做远程敏感操作时，例如设置开门密码、远程控制开门等，对称密钥协商认证方案无法实现端到端加密。因此，出于安全考虑，用户只能限制智能门锁仅使用蓝牙本地连接进行控制。

另一方面，对于软硬件能力都充足可以支持非对称密钥认证方案的设备来说，为了支持某些特殊场景(例如双协议、前装)使用了对称密钥认证方案。这导致对于后续有敏感类操作的需求时，无法使用更高安全等级的非对称密钥认证协商方案。

有鉴于此，本申请的实施例还提供了从对称密钥认证到非对称密钥认证的安全认证级别提升的方案。在一些实施例中，可以根据IoT设备的软硬件资源(例如CPU、内存、FLASH等)来确定其是否具有支持非对称密钥认证的能力。应理解，在提升安全认证级别之前，IoT设备和控制设备之间已经分配了对称密钥，可以实现基于对称密钥的认证。

图6示出了根据本申请的一些实施例的提升设备认证安全级别的过程的示意交互图。在图6所示的实施例中，以移动设备200和IoT设备206为例描述了提升控制设备和被控设备之间的安全认证级别的过程。应理解，提升安全认证级别的过程还可以适用于其他设备。

根据本申请的实施例，提升安全认证级别的过程可以在可信通信环境下实施，并且在不可信通信环境下，不发起该过程。在动作601，IoT设备206登录到IoT平台230，并且可以接收IoT平台230下发的控制命令。IoT设备206可以确定与IoT平台230之间的连接为非本地连接，例如，IoT设备206确定IoT平台230具有外部网络地址。在这种情况下，IoT设备206可以确定当前属于不可信通信环境，不发起提升安全认证级别的过程。

在动作603，中枢设备204登录到IoT平台230，并且从IoT平台230获取所有相关联的IoT设备的设备凭据，例如，用于认证的对称密钥。在动作604，中枢设备204使用对称密钥建立与IoT设备206的会话通道，并且向IoT设备206下发控制指令和接收上报的状态消息。在动作605，IoT设备206确定与中枢设备204之间的连接为本地连接，但是中枢设备不具有账号登录能力，IoT设备206可以不发起提升安全认证级别的过程。在一些实施例中，IoT设备206可以根据确定连接所使用的端口来确定中枢设备204不具有账号能力。备选地，IoT设备206还可以根据中枢设备204没有携带账号能力标记来确定中枢设备204没有账号能力。由于中枢设备204没有账户能力，也就是说无法通过账号标识实施非对称密钥认证，因此，IoT设备206可以不发起提升安全认证级别的过程。

在动作606，移动设备200使用账号标识登录到IoT平台230，并且从IoT平台230获取所有相关联的IoT设备的设备凭据，例如，用于认证的对称密钥。在动作607，移动设备200使用对称密钥建立与IoT设备206的会话通道，并且向IoT设备206下发控制指令和接收上报的状态消息。在动作608，IoT设备206确定移动设备200是否处于可信通信环境中，并且确定移动设备200是否具有账号能力。

在一些实施例中，IoT设备206通过确定与移动设备200之间的连接为本地通信连接，例如，局域网连接、蓝牙连接或者Zig-Bee连接等，确定移动设备200处于可信通信环境中。在一些实施例中，IoT设备206还可以进一步确定已经在本地通信连接上建立了基于对称密钥的会话通道，由此，IoT设备206确定移动设备200处于可信通信环境中。

在一些实施例中，IoT设备206可以通过确定移动设备200经由指定的端口连接到IoT设备206来确定移动设备200具有账号能力。例如，IoT设备206可以被预配置为使用第一端口来与具有账号能力的设备建立连接，并且使用与第一端口不同的第二端口来与没有账号能力的设备建立连接。备选地，如果移动设备200发送给IoT设备206的消息中携带了账号能力标记或者已登录的账号标识，则IoT设备206可以确定移动设备200具有账号能力。

响应于在动作608处确定移动设备200在可信通信环境中并且具有账号能力，IoT设备206可以发起提升安全认证级别的过程。在动作609，IoT设备206可以生成用于认证的公钥私钥对。该公钥私钥对也被称为长效公钥和长效私钥。

接下来，在动作610，IoT设备206向移动设备200上报支持非对称密钥认证，请求启用非对称密钥认证，向移动设备200传输所生成的公钥私钥对中的公钥。IoT设备206还将移动设备200的账号标识存储在本地(例如，图4所示的账号标识412)。账号标识可以在动作607所示的交互期间由移动设备200发送给IoT设备306。备选地，移动设备200可以在接收到IoT设备206的上报610之后，将账号标识下发给IoT设备206。在一些实施例中，下发的账号标识可以是在移动设备200上登录的账号标识。账号标识还可以是与登录的账号标识相关联的账号标识。例如，在登录的账号标识是IoT设备206的拥有者的情况下，移动设备200可以向IoT设备206提供分享账号标识。分享账号标识也可以被存储在IoT设备206中，使得这些账号标识可以被IoT设备206认证，从而能够访问和控制IoT设备206。

接下来，根据动作611至616，IoT设备206被CA服务240所认证。具体地，IoT设备206可以获取CA服务240对该设备的签名，以便后续在两个或更多IoT设备之间实现非对称密钥认证和安全通信。

具体地，在动作611，移动设备200向CA服务240传输认证IoT设备的请求，该请求包括IoT设备206的长效公钥、设备标识、以及移动设备200的账号标识。这里，移动设备200的账号标识也被存储在IoT设备206处，表示IoT设备206的拥有者。IoT设备206的设备标识可以由IoT平台230提供、或者由设备制造商提供并同步到IoT平台230，因而不能被伪造。

在动作612，CA服务240对接收到的IoT设备206的长效公钥、设备标识以及移动设备200的账号标识进行签名，并且在动作613，将签名发送给移动设备200。

然后，在动作614，移动设备200可以将接收到的针对IoT设备206的签名传输到IoT云平台230进行备份，并且在动作615，将针对IoT设备206的签名传输给IoT设备206。最后，在动作616，IoT设备206存储接收到的签名，完成非对称密钥绑定授权。

以上参考图6描述了在移动设备200处于本地通信连接的情况下的提升安全认证级别的过程。在一些实施例中，还可以在移动设备200处于远程通信连接的情况下实现提升安全认证级别的过程。在这种情况下，通过建立移动设备200和IoT设备206之间的端到端加密通信，确定移动设备200处于可信通信环境。参考图7描述该过程。

图7示出了根据本申请的一些实施例的提升设备认证安全级别的另一过程的示意交互图。如图7所示，移动设备200经由IoT平台230实现与IoT设备206的远程通信。

在动作701，IoT设备206登录到IoT平台230。例如，IoT设备206经由中枢设备登录到IoT平台230，由此在互联网上发送和接收消息。应理解，作为前提，在动作701之前，IoT设备206已经与该中枢设备建立应用层连接和安全会话

在动作702，移动设备200使用账号标识登录到IoT平台230，并且在动作703从IoT平台230获取所有相关联的IoT设备的设备凭据，例如，用于认证的对称密钥。

在动作704，移动设备200接收用户输入的IoT设备206的PIN。在一些实施例中，动作704可以响应于移动设备200要对IoT设备206的敏感功能进行操作而触发。这是因为移动设备200处于远程环境，被IoT设备206认为是不可信通信环境，因此限制移动设备200的操作。当发生敏感操作时，可以提供移动设备200的用户输入IoT设备206的PIN。

对于不支持动态显示PIN的IoT设备，一般是在设备出厂时预置了一个固定的PIN。对于支持动态显示PIN的IoT设备(例如有屏幕、有喇叭)，则可以在操作的时候，指示设备动态实时生成一个PIN。然后，用户可以通过其他方式获取到IoT设备的PIN(例如，提前记录下了IoT设备的PIN，或者联系设备周边的朋友前往查看告知)。由此用户在移动设备200处输入PIN。

接下来，通过IoT平台230的转发，移动设备200可以基于PIN与IoT设备206协商会话秘钥。在一些实施例中，可以使用PAKE协议进行协商。

具体地，在动作705，移动设备200基于PIN和本地产生的随机数生成PAKE协议的公钥私钥对(也被称为临时公钥和临时私钥)，并且在动作706将公钥发送给IoT设备206。在动作707，IoT设备206基于PIN和在其本地产生的另一随机数生成PAKE协议的公钥私钥对(也被称为临时公钥和临时私钥)。在动作707，IoT设备206还使用自己的PAKE私钥和接收到的移动设备200的PAKE公钥生成会话密钥，使用会话密钥对会话信息进行签名，得到签名会话信息，其中会话信息可以是随机化内容。在动作707，IoT设备206还可以使用会话密钥对签名会话信息进行加密。然后，在动作708，IoT设备206将自己的PAKE公钥和加密的签名会话信息发送给移动设备200。

在动作709，移动设备200使用自己的PAKE私钥和接收到的IoT设备206的PAKE公钥来生成会话密钥，使用会话密钥解密签名会话信息并验证签名。在动作709，移动设备200还可以使用会话密钥对会话信息进行签名，得到签名会话信息，并使用会话密钥对签名会话信息进行加密，得到加密的签名会话信息。在动作710，移动设备200经由IoT平台320向IoT设备传输加密的签名会话信息。

在动作711，IoT设备206使用会话密钥解密签名会话信息，并验证签名。在验证通过之后，IoT设备206和移动设备200完成了彼此的身份认证。这时，进一步地，IoT设备206还可以生成用于认证的非对称公钥私钥对，也称为长效公钥和长效私钥。在动作712，IoT设备206向移动设备200传输所生成的长效公钥。在一些实施例中，长效公钥可以用会话密钥来加密。另外，IoT设备206也可以将移动设备200的账号标识存储在本地，作为后续认证的依据。

在动作713，移动设备200可以代理设备206向CA服务240请求为IoT设备206进行签名。在一些实施例中，移动设备200向CA服务240传输IoT设备206的设备标识、长效公钥和账号标识，请求CA服务对这些信息进行签名。在从CA服务240接收到签名之后，移动设备200将该签名发送给IoT设备206。在一些实施例中，移动设备使用会话密钥对签名进行加密并传输给IoT设备206。

因此，移动设备200和IoT设备206使用PIN进行认证，并协商会话密钥，由此实现了经由IoT平台230的端到端加密通信(动作701至动作710)。在这种情况下，IoT设备可以确定移动设备处于可信通信环境中，由此发起提升安全认证级别的过程(动作711至动作714)。相比于图5所示的过程，该交互过程中使用会话秘钥进行了额外的加密，确保中间网元例如IoT平台230无法解密以及篡改报文。

根据图6和图7所示的过程，IoT设备206可以获取CA服务240对该设备的签名。在一些实施例中，在多个IoT设备被绑定到相同的账号标识的情况下，可以利用该签名实现IoT设备之间的非对称密钥认证。

图8示出了根据本申请的一些实施例的能够相互认证的物联网设备的示意框图。如图所示，设备810和设备820通信连接，例如，在同一智能家居环境中的本地连接。设备810和设备820可以彼此认证并且可以相互发送控制指令或上报状态信息。例如，设备810可以是智能音箱，设备820可以是智能门锁。在一些应用中，设备810要向设备820发送控制指令。

设备810包括设备标识812、账号标识814、设备长效公钥815、设备长效私钥816、设备签名818。应理解，账号标识814、长效公钥815、长效私钥815、设备签名818可以通过图5或图6所示的提升安全级别的过程而得到。设备签名是由CA服务240提供的针对设备标识、公钥、账号标识的签名。类似地，设备820包括设备标识822、账号标识824、设备长效公钥825、设备长效私钥826、设备签名828。这里，设备810的设备签名818和设备820的设备签名812是彼此认证的有效身份凭据。

需要注意的是，设备810和设备820认证的条件是，设备810和设备820被绑定到相同的账号标识，并且通过安全认证级别提升机制支持非对称秘钥认证方案，并且获取到了CA服务240对设备的认证签名。这时，设备810和设备820可以进行认证，建立安全的会话通道。以下参考图9描述该过程。

图9示出了根据本申请的一些实施例的物联网设备之间建立会话通道的过程的示意交互图。以IoT设备810作为控制设备、IoT设备820作为被控制设备进行说明。

如图所示，IoT设备810发起会话协商，要跟周边的IoT设备820进行交互。为此，在动作901，IoT设备810生成第一临时公私钥对。在动作902，IoT设备902向IoT设备820发送会话请求，携带设备810的设备标识812、长效公钥815、设备签名818、第一临时公钥。

在动作903，设备820使用预置的CA根证书校验设备810的签名818。设备签名818的内容是：设备标识812+设备长效公钥815+设备账号标识814(例如，拥有者的标识)，而此时设备820已经均获取了这些字段，故可以验证签名818是否合法。

设备820验证设备810的签名818合法后，在动作904，设备820响应设备810的会话协商请求，生成第二临时公私钥对。在动作905，设备820返回响应报文，携带设备820的设备标识822、长效公钥825、设备签名828、第二临时公钥。

在动作906，设备810使用预置的CA根证书校验设备签名828。设备签名828的内容可以是：设备标识822+设备长效公钥825+设备账号标识826(例如，拥有者的标识)，而此时设备810已经均获取了这些字段，故可以验证签名是否合法。

在动作907，设备810验证设备820的签名828合法后，基于第一临时公钥和第二临时私钥生成会话密钥，并使用长效私钥816签名会话信息，例如签名(第一临时公钥+第二临时公钥)，得到第一会话签名。在动作908，设备810使用会话秘钥加密第一会话签名，发送给设备820。

在动作909，设备820基于第一临时公钥和第二临时公钥生成会话密钥，并使用会话秘钥解密得到第一会话签名，使用设备810的长效公钥815验证第一会话签名。在动作910，在第一会话签名验证通过后，设备820使用自己的长效私钥826签名会话信息，例如，签名(第一临时公钥+第二临时公钥)，得到第二会话签名。

在动作911，设备820使用会话秘钥加密会话第二会话签名，发送给设备810。

在动作912，设备810使用会话秘钥解密得到第二会话签名，使用设备820的长效公钥826验证第二会话签名。

在验证通过后，设备810和设备820在动作913继续使用本次协商的会话秘钥加密业务会话通道。

根据图9所示的过程，在没有主控设备干预的情况下，同账号下的两个IoT设备之间可以直接进行业务交互。具体地，IoT设备之间不需要建立安全绑定，而是通过CA服务给相同账号下的设备进行签名，IoT设备分别验证签名来确保是同账号下绑定的设备来确保对方是否有权限与自己通信。

根据以上描述的实施例，除了对称密钥认证，IoT设备还可以支持非对称密钥认证。非对称密钥认证的安全级别高于对称密钥认证。基于此，本申请的实施例还提供了访问控制系统和方法，用于在不同通信环境下提供对应的访问控制，从而提高整体安全性。

图10示出了根据本申请的一些实施例的物联网设备的访问控制系统的示意图。如图所示，移动设备200可以经由IoT设备206的本地接口1005来访问IoT设备206。移动设备200还可以经由IoT平台230和IoT设备206的远程接口1010来访问IoT设备206。

对于同时支持对称密钥、非对称密钥两种安全认证方式的IoT设备，可以对IoT设备上的可操作功能设定不同的操作权限。在一些实施例中，对于非敏感操作列表1015中的操作(例如，获取设备状态、打开风扇灯)，同时可允许本地接口1005控制和远程接口1010控制。对于敏感操作列表1020中的操作(例如设置管理员密码、远程开门)，则允许本地接口1005可以控制，但是经由远程接口1010的访问，则要求通过端到端加密通道才可以远程控制。也就是说，对于敏感操作，移动设备200处于对IoT设备来说的可信通信环境下。

在一些实施例中，本地接口1005的通信可以基于对称密钥协商加密会话通道，也可以基于非对称密钥协商加密会话通道。远程接口1010的通信需要是基于非对称密钥协商加密会话通道。

在还没有完成基于非对称密钥认证的安全级别提升时，可以限制移动设备200通过远程接口11的敏感操作。在一些实施例中，可以在移动设备200上设置错误引导。例如，移动设备200上可以看到敏感操作，当远程控制时，提示用户“必须现在本地连接设备认证后才允许远程敏感操作”，由此，引导用户完成安全认证级别提升的过程。在一些实施例中，移动设备200可以隐藏敏感操作入口。例如，为了避免用户不理解上述引导，也可以直接在远程连接设备时，直接隐藏敏感操作入口，直到用户完成安全认证级别提升过程后再显示。

在以上参考图3至图10描述的实施例中，使用移动设备200作为控制设备，但是应理解，控制设备还可以是其他类型的设备，例如，智能家居环境中的中枢设备204，例如，固定在家庭特定位置处的中枢设备。

示例过程

图11示出了根据本申请的一些实施例的通信方法1100的示意流程图。通信方法1100可以第一电子设备处被实施，第一电子设备可以是例如图1所示的设备101、102、103、104，图2所示的中枢设备204、IoT设备206、208。应理解，方法1100还可以在其他设备处实施，本申请对此不做限制。

在框1100，第一电子设备确定第二电子设备是否在可信通信环境中并且具有账号能力。第二电子设备与第一电子设备通信连接，并且可以是例如图1所示的移动设备100或图2所示的移动设备200、或者其他设备。

在一些实施例中，确定第二电子设备在可信通信环境中包括：确定第一电子设备和第二电子设备已经建立本地通信连接。本地通信连接可以包括局域网连接、蓝牙连接、或者Zig-bee连接中的至少一项。在一些实施例中，，确定第二电子设备在可信通信环境中还可以包括：在第一电子设备和第二电子设备之间的本地通信连接建立基于对称密钥认证的会话通道。

在一些实施例中，确定与第一电子设备连接的第二电子设备在可信通信环境中可以包括：基于第一电子设备的识别码(PIN)与第二电子设备建立端到端加密通信。在一些实施例中，建立端到端加密通信可以包括：基于PIN和PAKE协议，与第二电子设备协商会话密钥。

在一些实施例中，确定第二电子设备具有账号能力可以包括以下至少一项：确定第二电子设备经由指定的端口连接到所述第一电子设备；或者确定从第二电子设备接收到账号能力标记。

响应于第二电子设备在可信通信环境中并且具有账号能力，在框1110，第一电子设备向第二电子设备传输第一电子设备的用于认证的公钥私钥对中的公钥。

在框1015，第一电子设备存储用于非对称密钥认证的账号标识。在一些实施例中，账号标识包括以下至少一项：在第二电子设备上登录的账号标识，或者与登录的账号标识相关联的账号标识。

在一些实施例中，方法1100还可以包括：从第二电子设备接收证书机构(CA)针对第一电子设备的设备标识、第一电子设备的用于认证的公钥以及账号标识的签名。

在一些实施例中，第一电子设备可以是物联网(IoT)设备，第二电子设备可以是移动设备。

图12示出了根据本申请的一些实施例的另一通信方法1200的示意流程图。通信方法1200可以第一电子设备处被实施，第一电子设备可以是例如图1所示的设备101、102、103、104，图2所示的中枢设备204、IoT设备206、208。应理解，方法1100还可以在其他设备处实施，本申请对此不做限制。

在框1205，第一电子设备确定第二电子设备是否处于不可信通信环境中。在一些实施例，确定第二电子设备在不可信通信环境中可以包括：确定第一电子设备和第二电子设备之间的通信连接是远程通信连接，其中远程通信连接包括因特网连接。

如果第二电子设备被确定为处于不可信通信环境中，在框1210，第一电子设备允许从第二电子设备、经由基于对称密钥认证的会话通道传输的第一消息的操作，并且禁止从第二电子设备、经由基于对称密钥认证的会话通道传输的第二消息的操作，其中，第二消息的安全级别高于第一消息。在一些实施例中，第一消息的操作是非敏感操作，第二消息的操作是敏感操作。

在一些实施例中，方法100还可以包括：响应于第二消息的操作被禁止，生成建立基于非对称密钥认证的会话通道的提示。提示可以例如引导用户完成安全认证级别提升的过程，由此可以建立基于非对称密钥认证的会话通道。然后，在非对称密钥认证的会话通道已建立之后，第一电子设备允许从第二电子设备、经由基于非对称密钥认证的会话通道传输的第二消息的操作。

在一些实施例中，如果第二电子设备被确定为处于可信通信环境中，则第一电子设备允许从第二电子设备、经由基于对称密钥认证的会话通道传输的第二消息的操作。在一些实施例中，确定第二电子设备在可信通信环境中可以包括：确定第一电子设备和第二电子设备之间的通信连接是本地通信连接。本地通信连接可以包括以下至少一项：本地IP局域网连接(例如，Wi-Fi连接，有线以太网连接)、蓝牙连接、或者Zig-bee连接。

根据参考图1至图11描述的本申请的实施例，设备可以同时配置对称密钥认证和安全能力更强的非对称密钥认证。对称密钥认证为基础认证方式，从设备绑定开始就支持，而非对称密钥认证方式能够用于敏感业务操作。非对称密钥认证可以在设备绑定时不支持，后续通过本地后台同步或者远程PIN码认证同步来提升设备操作安全性。

根据本申请的一些实施例，设备还可以对于操作权限做白名单管控。对于非敏感操作，无论远程、本地都可以通过对称密钥认证方式控制，而对于敏感操作，本地连接可以通过对称密钥认证方式来控制，而远程连接需要通过非对称密钥认证方式来控制。根据本申请的一些实施例中，设备在配置了非对称密钥认证方式后，可以关闭对称密钥方式认证，防止设备认证安全级别被对称密钥拉低。

本申请的一些实施例适用于广泛的应用场景，例如，能够解决前装设备无法支持非对称密钥控制的限制。因此，对于敏感设备(如支持远程开门的门锁，远程监控的摄像头)，则可以前装时用对称密钥认证，在交房后实施安全级别提升过程，启用非对称密钥认证。

本申请的一些实施例还可以解决双协议设备(支持对称密钥认证和非对称密钥认证协议)被窄带通道拉低安全性的问题。利用本申请的实施例，通过在窄带协议(例如蓝牙)配对时，可以先采用对称密钥认证，宽带接通后再改变为非对称密钥认证。

本申请的一些实施例解决了已绑定的旧设备升级后无法提升安全性的问题。对于旧设备升级，升级时沿用旧版本的对称密钥认证，升级后使用非对称密钥认证，提高设备安全性。

另外，根据本申请的一些实施例，安全认证级别提升过程可以在用户使用移动设备本地连接智能设备后，在后台自动升级为非对称密钥认证，因此是用户无感的。另一方面，还可以通过远程操作，利用PIN码方式，实现远程紧急升级操作。

示例设备

图13出了可以用来实施本申请内容的实施例的示例设备1300的示意性。例如，根据本申请实施例的设备100、101、102、103、104、204、206、208等可以由设备1300来实施。如图所示，设备1200包括中央处理单元(CPU)1301，其可以根据存储在只读存储器(ROM)1302中的计算机程序指令或者从存储单元1308加载到随机访问存储器(RAM)1303中的计算机程序指令，来执行各种适当的动作和处理。在RAM 1303中，还可存储设备1300操作所需的各种程序和数据。CPU 1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

设备1300中的多个部件连接至I/O接口1305，包括：输入单元1306，例如键盘、鼠标等；输出单元1307，例如各种类型的显示器、扬声器等；存储单元1308，例如磁盘、光盘等；以及通信单元1309，例如网卡、调制解调器、无线通信收发机等。通信单元1309允许设备1300通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个过程和处理，例如图3a至3c、图5至图7、图9、图10、图11、图12所示的过程，可由处理单元1301执行。例如，在一些实施例中，上述过程可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序被加载到RAM 1303并由CPU 1301执行时，可以执行上文描述的任何过程的一个或多个动作。

本申请可以是方法、装置、系统、芯片和/或计算机程序产品。芯片可以包括处理单元和通信接口，处理单元可以处理从通信接口接收到的程序指令。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本申请的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。

这里参照根据本申请实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本申请的各实施方式，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施方式。在不偏离所说明的各实施方式的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施方式的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施方式。

Claims (18)

1.一种通信方法，包括：在第一电子设备处，

响应于确定与所述第一电子设备通信连接的第二电子设备在可信通信环境中并且具有账号能力，向所述第二电子设备传输所述第一电子设备的用于认证的公钥私钥对中的公钥；以及

存储用于非对称密钥认证的账号标识。

2.根据权利要求1所述的方法，其中，确定与第一电子设备连接的第二电子设备在可信通信环境中包括：

确定所述第一电子设备和所述第二电子设备已经建立本地通信连接。

3.根据权利要求2所述的方法，其中，所述本地通信连接包括以下至少一项：局域网连接、蓝牙连接、或者Zig-bee连接。

4.根据权利要求2所述的方法，其中，确定与第一电子设备连接的第二电子设备在可信通信环境中包括：

在所述第一电子设备和所述第二电子设备之间的所述本地通信连接建立基于对称密钥认证的会话通道。

5.根据权利要求1所述的方法，其中，确定与第一电子设备连接的第二电子设备在可信通信环境中包括：

基于所述第一电子设备或所述第二电子设备的识别码(PIN)与所述第二电子设备建立端到端加密通信。

6.根据权利要求5所述的方法，其中，建立所述端到端加密通信包括：

基于所述PIN和PAKE协议，与所述第二电子设备协商会话密钥。

7.根据权利要求1所述的方法，其中，确定所述第二电子设备具有账号能力包括以下至少一项：

确定所述第二电子设备经由指定的端口连接到所述第一电子设备；或者

确定从所述第二电子设备接收到账号能力标记。

8.根据权利要求1所述的方法，其中，所述账号标识包括以下至少一项：

在所述第二电子设备上登录的账号标识；或者

与登录的账号标识相关联的账号标识。

9.根据权利要求1所述的方法，还包括：在所述第一电子设备处，

从所述第二电子设备接收证书机构(CA)针对所述第一电子设备的设备标识、所述第一电子设备的所述公钥以及所述账号标识的签名。

10.根据权利要求1所述的方法，其中，所述第一电子设备包括物联网(IoT)设备，并且所述第二电子设备包括移动设备。

11.一种通信方法，包括：在第一电子设备处，

确定第二电子设备是否处于不可信通信环境中；

如果所述第二电子设备被确定为处于不可信通信环境中，

允许从所述第二电子设备、经由基于对称密钥认证的会话通道传输的第一消息的操作，并且禁止从所述第二电子设备、经由所述基于对称密钥认证的会话通道传输的第二消息的操作，其中所述第二消息的安全级别高于所述第一消息。

12.根据权利要求11所述的方法，还包括：

响应于所述第二消息的操作被禁止，生成建立基于非对称密钥认证的会话通道的提示；以及

在所述非对称密钥认证的会话通道已建立之后，允许从所述第二电子设备、经由基于所述非对称密钥认证的会话通道传输的第二消息的操作。

13.根据权利要求11所述的通信方法，其中，确定所述第二电子设备在不可信通信环境中包括：

确定所述第一电子设备和所述第二电子设备之间的通信连接是远程通信连接，所述远程通信连接包括因特网连接。

14.根据权利要求11所述的方法，还包括：

如果所述第二电子设备被确定为处于可信通信环境中，允许从所述第二电子设备、经由所述基于对称密钥认证的会话通道传输的第二消息的操作。

15.根据权利要求14所述的方法，其中，确定所述第二电子设备在可信通信环境中包括：

确定所述第一电子设备和所述第二电子设备之间的通信连接是本地通信连接，所述本地通信连接包括以下至少一项：局域网连接、蓝牙连接、或者Zig-bee连接。

16.一种电子设备，包括：

至少一个计算单元；

至少一个存储器，所述至少一个存储器被耦合到所述至少一个计算单元并且存储用于由所述至少一个计算单元执行的指令，所述指令当由所述至少一个计算单元执行时，使得所述电子设备执行根据权利要求1-10中任一项或者根据权利要求11-15中任一项所述的方法。

17.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现根据权利要求1-10中任一项所述的方法或者根据权利要求11-15中任一项所述的方法。

18.一种计算机程序产品，包括计算机可执行指令，其中所述计算机可执行指令被处理器执行时实现根据权利要求1-10中任一项所述的方法或者根据权利要求11-15中任一项所述的方法。