适用于智能家居环境的分布式跨设备访问控制方法及装置

1.本技术涉及访问控制技术领域，特别涉及一种适用于智能家居环境的分布式跨设备访问控制方法及装置。


背景技术：

2.跨设备信号传输使得用户可以通过操作本地设备上的应用来控制远程设备，提高了智能家居的便利性和智能化水平，但与此同时，跨设备信号传输也存在许多安全问题，一方面，需要验证设备身份和传输内容的合法性，另一方面，需要保证传输过程的可靠性。
3.访问控制是用于保证访问主体对客体进行合法访问的一种技术，一个访问控制方案的实现需要访问控制架构与访问控制策略的参与，分别提供结构上和逻辑上的支持。
4.访问控制架构可分为两类：集中式架构(centralized approach)和分布式架构(distributed approach)。集中式架构由一个中心服务器做身份认证与授权工作，如图1所示。在智能家居环境下，中心服务器需要掌握大量的用户隐私信息，客体设备只作为消息接收方，存在极大的单点故障(single point of failure-spof)威胁，故目前考虑更多的是分布式架构。分布式架构的结构如图2所示，不需要第三方服务的参与，访问控制的逻辑被直接嵌入到客体设备中，由客体终端进行认证与授权。分布式架构解决了集中式架构存在的问题，同时实现了主体设备与客体设备的双向通信，有利于对跨设备通信安全进行监管与保护。
5.主流的访问控制策略有以下四种：自主访问控制(discretionary access control-dac)，强制访问控制(mandatory access control-mac)，基于角色的访问控制(role-based access control-rbac)，基于属性的访问控制(attribute-based access control-abac)。由于智能家居设备和场景的复杂多样，而dac和mac的访问控制策略不够灵活，目前得到应用的是rbac和abac两种策略。然而，rbac和abac依赖于大量预先制定好的规则(policy)、身份(role)和属性(attribute)信息，在分布式访问控制架构下，对iot中计算能力和存储资源有限的弱设备并不友好。近年来，基于能力的访问控制(capability-based access control)开始被逐渐完善与应用，这种策略使用了凭证(token)的概念，一个token能够描述一个实体的身份和权限信息，这些信息又被称为capability。当主体访问客体时，主体发送带有token的请求，访问控制不再需要进行身份、属性或规则的认证，仅通过验证token的合法性即可实现对主体访问权限的验证。
6.在基于capability的分布式访问控制方案中，由于访问控制覆盖不全面、验证机制存在漏洞或验证信息容易被伪造等因素，其中存在诸多安全问题，主要可分为以下两类：
7.来自恶意设备的攻击。该类攻击归因于两个设备建立连接前身份验证的不足，即对token的合法性没有进行及时的判断。
8.来自可信设备上恶意应用的攻击。该类攻击归因于两个设备建立连接后权限验证的不足，即对token的合法性没有进行有效的判断。
9.针对基于capability的分布式访问控制方案存在的安全问题，token的定义方式、
管理模式与验证机制十分关键，而目前很少有工作能够给出一套符合需求的完整访问控制方案。


技术实现要素：

10.本技术提供一种适用于智能家居环境的分布式跨设备访问控制方法及装置，以解决相关技术中由于访问控制覆盖不全面、验证机制存在漏洞或验证信息容易被伪造等原因带来的安全问题。
11.本技术第一方面实施例提供一种适用于智能家居环境的分布式跨设备访问控制方法，应用于智能家居环境，包括以下步骤：
12.步骤s1：控制主体与客体从云端获取规定进程所具备的权限信息的访问控制规则，并基于所述访问控制规则对请求的发送和响应进行限制，其中，所述主体与所述客体在本地分别持有一个用于标识数据包的正整数counter；
13.步骤s2：控制所述主体与所述客体建立连接，其中，当所述主体与所述客体首次进行通信时，所述主体先发送连接请求，所述客体验证所述主体的身份及主体权限的合法性，若合法，则建立连接的同时，所述客体基于所述访问控制规则生成第一预设时长内有效的访问验证凭证和第二预设时长内有效的更新凭证，以一同返回至所述主体，其中，所述第二预设时长大于所述第一预设时长；
14.步骤s3：在所述主体接收并存储所述访问验证凭证和所述更新凭证后，向所述客体发送携带有所述访问验证凭证的请求，同时在所述请求包内加入所述正整数counter；
15.步骤s4：在所述客体验证所述主体发送的访问验证凭证的合法性与有效性后，若合法且有效，则执行所述请求的请求内容，并向所述主体返回请求结果；若不合法，则拒绝所述请求，报错并结束通信；以及，若合法但超过所述第一预设时长，则向所述主体返回凭证过期错误，且继续执行下述步骤；
16.步骤s5：在所述主体收到所述凭证过期错误后，向所述客体发送与过期的所述访问验证凭证匹配的所述更新凭证，同时发送所述正整数counter；
17.步骤s6：在所述客体验证所述更新凭证的合法性与有效性后，同时检验所述正整数counter的一致性，若不合法，则拒绝请求，报错并结束通信；若合法，则所述客体重新基于所述访问控制规则生成新的访问验证凭证和与之对应的更新凭证，返回给所述主体；
18.步骤s7：在所述主体接收并覆盖存储新的访问验证凭证和与之对应的更新凭证后，重新执行所述步骤s3。
19.根据本技术的实施例，还包括：对所述云端的访问控制规则进行更新时，同时更新所述主体与所述客体的访问控制规则。
20.根据本技术的实施例，所述正整counter是一个随机整数，存储在所述主体和所述客体，初始值为0，每一次通信结束，所述主体和所述客体均把自己的counter值加一，以同步更新counter数值。
21.根据本技术的实施例，在所述步骤s2之前，还包括：通过所述客体对所述主体的身份合法性以及请求权限合法性进行验证，验证通过后建立所述主体与所述客体间的连接。
22.根据本技术的实施例，所述步骤s3进一步包括：所述主体将所述访问验证凭证和与之对应的更新凭证存储在本地，且所述访问验证凭证的数据包经过所述主体端的代理，
使用hmac算法加密，并加入所述正整数counter后发送，所述正整数counter的值由0开始基于数据包自增。
23.根据本技术的实施例，在所述客体对所述正整数counter验证时，数据包内的counter值与本地存储的counter值保持一致。
24.根据本技术的实施例，还包括：通过主体端透明代理进行所述主体所有通信的数据包的发送或接收以及数据包的验证；通过客体端透明代理进行所述客体所有通信的数据包的发送或接收以及数据包的验证。
25.本技术第二方面实施例提供一种适用于智能家居环境的分布式跨设备访问控制装置，应用于智能家居环境，包括：
26.准备模块，用于控制主体与客体从云端获取规定进程所具备的权限信息的访问控制规则，并基于所述访问控制规则对请求的发送和响应进行限制，其中，所述主体与所述客体在本地分别持有一个用于标识数据包的正整数counter；
27.连接建立模块，用于控制所述主体与所述客体建立连接，其中，当所述主体与所述客体首次进行通信时，所述主体先发送连接请求，所述客体验证所述主体的身份及主体权限的合法性，若合法，则建立连接的同时，所述客体基于所述访问控制规则生成第一预设时长内有效的访问验证凭证和第二预设时长内有效的更新凭证，以一同返回至所述主体，其中，所述第二预设时长大于所述第一预设时长；
28.第一请求模块，用于在所述主体接收并存储所述访问验证凭证和所述更新凭证后，向所述客体发送携带有所述访问验证凭证的请求，同时在所述请求包内加入所述正整数counter；
29.第一验证模块，用于在所述客体验证所述主体发送的访问验证凭证的合法性与有效性后，若合法且有效，则执行所述请求的请求内容，并向所述主体返回请求结果；若不合法，则拒绝所述请求，报错并结束通信；以及，若合法但超过所述第一预设时长，则向所述主体返回凭证过期错误，且继续执行下述步骤；
30.第二请求模块，用于在所述主体收到所述凭证过期错误后，向所述客体发送与过期的所述访问验证凭证匹配的所述更新凭证，同时发送所述正整数counter；
31.第二验证模块，用于在所述客体验证所述更新凭证的合法性与有效性后，同时检验所述正整数counter的一致性，若不合法，则拒绝请求，报错并结束通信；若合法，则所述客体重新基于所述访问控制规则生成新的访问验证凭证和与之对应的更新凭证，返回给所述主体；
32.更新模块，用于在所述主体接收并覆盖存储新的访问验证凭证和与之对应的更新凭证后，重新执行所述第一请求模块的功能。
33.本技术第三方面实施例提供一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序。所述处理器执行所述程序，能够实现如上述实施例所述的适用于智能家居环境的分布式跨设备访问控制方法。
34.本技术第四方面实施例提供一种计算机可读存储介质。所述计算机可读存储介质能够存储计算机指令，所述计算机指令用于使所述计算机执行如上述实施例所述的适用于智能家居环境的分布式跨设备访问控制方法。
35.本技术实施例的适用于智能家居环境的分布式跨设备访问控制方法及装置，具有
以下有益效果：
36.本技术的分布式访问控制方案，基于访问认证凭证对每一个数据包进行认证，摆脱了访问控制对第三方服务或规则数据集的依赖，增大了对每一个通信数据包的监控力度，同时又降低了iot设备进行访问控制的资源开销。访问验证凭证与更新凭证并行的方式能够避免访问验证凭证一经发出就永久有效而带来的安全隐患，也避免了用户频繁的授权认证。利用代理对数据包进行加密与转发，解决了跨设备通信时通信双方在认证之前就建立连接而带来的安全问题，同时隐藏了设备进程的实际端口与内部细节，避免了利用暴露的端口造成的攻击。
37.本技术附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
38.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
39.图1为集中式访问控制架构的示意图；
40.图2为分布式访问控制架构的示意图；
41.图3为根据本技术实施例提供的一种适用于智能家居环境的分布式跨设备访问控制方法的流程图；
42.图4为根据本技术实施例提供的初始访问与访问验证的实施机制示意图；
43.图5为根据本技术实施例提供的超时访问与访问验证的实施机制示意图；
44.图6为根据本技术实施例提供的丢包/重传访问与访问验证的实施机制示意图；
45.图7为根据本技术实施例的适用于智能家居环境的分布式跨设备访问控制装置的示例图；
46.图8为根据本技术实施例的电子设备示意图。
具体实施方式
47.下面详细描述本技术的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本技术，而不能理解为对本技术的限制。
48.可申请的框架包括主体和主体两个实体，其中主体为请求的发送端，请求访问权限并发送相应的凭证；客体为请求的接收端，即资源的提供者或指令的执行者，负责凭证的验证。在本技术的后续描述中，access token(at)表示进程对应的访问验证凭证；refresh token(rt)表示进程对应的更新凭证；proxy表示部署在主客体端的代理。
49.散列消息认证码(hash-based message authentication code，hmac)，是一种通过特别计算方式之后产生的消息认证码(mac)，使用密码散列函数，同时结合一个加密密钥。它可以用来保证资料的完整性，同时可以用来作某个消息的身份验证。hmac的运算公式为：hmac(k,m)＝h((k'
⊕
opad||h((k'
⊕
ipad)||text))，其中，h为密码散列函数(如sha家族)，k为密钥(secret key)，text是要认证的消息，k'是从原始密钥k导出的另一个秘密密钥(如果k短于散列函数的输入块大小，则向右填充(padding)零；如果比该块大小更长，则
对k进行散列)，||代表串接，
⊕
代表异或(xor)，opad是外部填充(0x5c5c5c
…
5c5c，一段十六进制常量)，ipad是内部填充(0x363636
…
3636，一段十六进制常量)。
50.图3为根据本技术实施例提供的一种适用于智能家居环境的分布式跨设备访问控制方法的流程图。
51.如图3所示，该适用于智能家居环境的分布式跨设备访问控制方法，应用于智能家居环境，包括以下步骤：
52.步骤s1：控制主体与客体从云端获取规定进程所具备的权限信息的访问控制规则，并基于访问控制规则对请求的发送和响应进行限制，其中，主体与客体在本地分别持有一个用于标识数据包的正整数counter。
53.在本技术的一个实施例中，对云端的访问控制规则进行更新时，同时更新主体与客体的访问控制规则。
54.具体地，主体与客体从云端获取访问控制规则，访问控制规则由运营商根据产品功能定义、用户根据个人需求利用ui界面授权，访问控制规则规定了进程所具备的权限信息，对请求的发送和响应进行限制。访问控制规则之间不存在冲突。访问控制规则一经生成就会被上传到云端，设备在初次访问时从云端下载规则到本地。云端的规则一旦发生更新，本地的规则就立刻也会被更新。
55.主客体双方在本地分别持有一个正整数counter，用于标识数据包，实现防重放攻击。
56.步骤s2：控制主体与客体建立连接，其中，当主体与客体首次进行通信时，主体先发送连接请求，客体验证主体的身份及主体权限的合法性，若合法，则建立连接的同时，客体基于访问控制规则生成第一预设时长内有效的访问验证凭证access token和第二预设时长内有效的更新凭证refresh token，以一同返回至主体，其中，第二预设时长大于第一预设时长，更新凭证refresh token用来更新访问验证凭证access token。
57.在本技术的一个实施例中，在步骤s2之前，还包括：通过客体对主体的身份合法性以及请求权限合法性进行验证，验证通过后建立主体与客体间的连接。
58.具体地，客体对主体的验证包括身份的合法性以及请求权限的合法性，验证由客体端的代理完成，发生在主客体实际进程建立连接之前，验证通过后连接才被建立起来。access token和refresh token由客体签发，均包含有效期信息以及通信双方身份信息，此外，refresh token还包含其对应的access token信息。
59.步骤s3：在主体接收并存储访问验证凭证access token和更新凭证refresh token后，向客体发送携带有访问验证凭证access token的请求，同时在请求包内加入正整数counter。
60.在本技术的实施例中，counter是一个随机整数，存储在主体和客体两方，初始值为0，每一次通信结束，主体和客体就都要把自己的counter加一，以此来保证同步更新counter数值。
61.进一步地，主体把访问验证凭证access token和更新凭证refresh token都存储在本地，但只发送访问验证凭证access token。数据包经过主体端的代理，使用hmac算法加密，并加入counter后发送，counter此时由0开始基于数据包自增。
62.步骤s4：在客体验证主体发送的访问验证凭证access token的合法性与有效性
后，若合法且有效，则执行请求的请求内容，并向主体返回请求结果；若不合法，则拒绝请求，报错并结束通信；以及，若合法但超过第一预设时长，则向主体返回凭证过期错误，且继续执行下述步骤。
63.在本技术的实施例中，客体的验证由客体端代理执行，包括对access token的验证和对counter的验证，客体对access token的验证包括对其签名的验证和有效期的验证，以保证合法有效，如果签名验证不通过则结束通信，如果签名验证通过但有效期验证不通过则报错但不结束通信。客体对counter的验证需要保证包内的counter值与本地存储的counter值一致。
64.步骤s5：在主体收到凭证过期错误后，向客体发送与过期的访问验证凭证access token匹配的更新凭证refresh token，同时发送正整数counter。
65.可以理解的是，更新凭证refresh token用于更新过期的访问验证凭证access token，由于更新凭证refresh token有效期远远长于访问验证凭证access token，故通常情况下更新凭证refresh token不会过期。
66.具体地，主体发送过期访问验证凭证access token对应的更新凭证refresh token，数据包经过主体端的代理，使用hmac算法加密，并加入counter后发送，counter此时继续基于数据包自增。
67.步骤s6：在客体验证更新凭证refresh token的合法性与有效性后，同时检验正整数counter的一致性，若不合法，则拒绝请求，报错并结束通信；若合法，则客体重新基于访问控制规则生成新的访问验证凭证access token和与之对应的更新凭证refresh token，返回给主体。
68.进一步地，客体的验证由客体端代理执行，包括对refresh token的验证和对counter的验证，客体对refresh token的验证包括对其签名的验证和有效期的验证，以保证合法有效，如果其中之一验证不通过则结束通信。客体对counter的验证需要保证包内的counter值与本地存储的counter值一致。
69.步骤s7：在主体接收并覆盖存储新的访问验证凭证和与之对应的更新凭证后，重新执行步骤s3。
70.进一步地，原有的访问验证凭证access token和更新凭证refresh token在主体端被覆盖存储，原有的访问验证凭证access token和更新凭证refresh token失效。
71.在本技术的一个实施例中，通过主体端的透明代理进行主体所有通信的数据包的发送或接收以及数据包的验证；通过客体端的透明代理进行客体所有通信的数据包的发送或接收以及数据包的验证。
72.具体而言，主体通过主体端透明代理处理主体的数据包具体包括以下步骤：
73.s101：在主体设备端部署一个透明代理，主体进程与代理建立连接，主体进程端口对外不可见，代理端口对外被虚拟为进程端口，所有通信的数据包都经由代理才能被发送或接收。
74.s102：当主客体首次进行通信时，主体代理向客体发送与客体进行连接的请求，代理使用主体私钥将数据包签名后转发给客体，以标识主体身份。若客体生成access token与refresh token，则首先被代理接收，代理通过客体的公钥验证token的发布者是否为客体，若发布者是客体，则将两个token解密后存储在本地；若发布者不是客体，则重复本步
骤。
75.s103：主体进程发送对客体的请求，代理接收到请求，在请求包内添加access token和counter，同时利用与客体动态商议的密钥将数据包进行hmac加密，然后把加工后的数据包发送给客体。若代理收到客体返回的重议counter请求，则代理把原有counter除以100，向上取整后再乘100作为新的counter，然后重复本步骤。
76.s104：若代理接收到客体返回access token过期的错误，在代理把过期access token对应的refresh token与counter一起，再次利用hmac加密后发送给客体。若代理收到新的access token与refresh token，则代理通过hmac密钥验证两个token的发布者是否为客体，若发布者是客体，则将两个token解密后存储在本地，进入s103；若发布者不是客体，则重复本步骤。若代理收到客体返回的重议counter请求，则代理把原有counter除以100，向上取整后再乘100作为新的counter，重复本步骤。
77.s105：若代理接收到客体返回的请求结果或请求资源，则代理利用hmac密钥解密后，把原文信息发送给主体进程。
78.具体而言，客体通过客体端透明代理处理客体的数据包具体包括以下步骤：
79.s201：在客体端部署一个透明代理，代理与客体进程连接，客体进程端口对外不可见，代理端口对外被虚拟为进程端口，所有通信的数据包都经由代理才能被发送或接收。
80.s202：代理收到来自主体的连接请求，代理利用主体公钥验证主体身份，基于访问控制规则验证主体权限，若身份与权限均合法，则代理生成access token与refresh token，私钥签名后发送给主体，进入s203；若其中之一不合法，则代理返回错误，结束通信。
81.s203：代理接收到主体含有access token和counter的请求，利用hmac密钥解密验证数据包的合法性，若解密失败，则说明数据包不合法，代理返回错误，结束通信；若解密成功，则验证access token是否过期，counter是否一致。若access token过期，执行s204；若counter不一致，执行s205；若二者都合法有效，则代理将解密后的数据包，除去access token和counter后发送给客体进程，由客体进程执行请求，代理向主体返回请求结果。
82.s204：代理向主体发送access token错误的信息，收到主体发来的refresh token和counter，代理利用本地信息对refresh token进行身份与权限的验证，同时验证counter是否一致。若refresh token不合法，则代理返回错误，结束通信；若counter不一致，则执行s205；若二者都合法有效，则代理生成新的access token与refresh token，利用hmac加密后发送给主体，进入s203。
83.s205：代理向主体发送重议counter的请求，请求利用hmac加密，主客体同步一个新的counter，新的counter值为原有counter除以100，向上取整后再乘100。
84.本发明的分布式访问控制方案，可有效加强智能家居跨设备通信的安全性，防止恶意设备的连接和恶意应用的请求，且本发明考虑了部分物联网设备计算能力弱、存储空间小等特点，适用于真实的智能家居环境。
85.下面结合附图和具体实施例阐述本技术的访问控制方案的具体流程。首先，将描述两个首次进行通信的实体如何建立连接，然后将给出各类情形的验证机制和执行结果，并详细解释本技术对于访问控制对安全性的保障。
86.初始访问：
87.初始访问机制在主体进程与客体进程进行首次通信时实施，其中，首次通信指的
是主客体直接不存在可信连接记录时进行的通信。该机制用于生成access token和refresh token，并初始化counter值。
88.当主体进程发送一个请求时，主体代理将首先收到该请求，根据主体请求的目标客体，对客体的代理发出请求并获得连接信息，建立“主体进程
→
主体代理
→
客体代理
→
客体进程”的连接，然后执行通信转发，表1的算法1展示了这一过程。
89.表1
[0090][0091]
主体代理对主体用户是透明的，即用户不知道该代理的存在，透明代理不需要用户进行手动配置。图4展示了初始访问机制的实施细节，数据包的处理与转发均由代理完成，实线表示数据包的传递，虚线表示代理对主客体存储空间的读写。由于该过程并不需要主客体进程的主动参与，故本方案并不对主客体进程进行修改。
[0092]
建立连接后，主体将首先发送存储在本地的访问控制规则给主体代理，主体对于数据包的处理机制如表2的算法2所示，主体代理获取访问控制规则，为存有规则的数据包添加上counter，然后利用客体的公钥加密、主体的私钥签名，把签名后的数据包发送给客体。此处主体代理对数据包的修改能有效保证数据在传输过程中的安全性，防止数据被篡改或窃取。
[0093]
表2
[0094][0095]
客体首先需要从云端把访问控制规则下载到本地，以便于后续的验证。主体发送的数据包将首先由客体代理接管。客体接收到主体含有访问控制规则的数据包后，首先利用私钥对数据包进行解密，然后利用主体的公钥对签名进行验证，以确认主体的身份可信、消息可靠，否则直接拒绝请求。验证通过后，客体再对本地的访问控制规则与数据包中的规
则进行对照，确保主客体拥有一致的规则，若规则不一致，则返回应用需更新的提示，双方重新从云端下载最新版的规则；若规则一致，则客体根据规则生成access token和refresh token，同时与主体商议出一个随机数作为后续进行hmac加密的密钥，access token和refresh token和密钥同样经过算法2的机制，由客体代理为数据包添加counter，进行加密签名后发送给主体。access token和refresh token始终与主体进程的端口号绑定，主体代理将二者写入主体的存储空间，客体端只存储refresh token。
[0096]
访问验证：
[0097]
访问验证机制在主体端获得access token和refresh token对后，利用access token进行访问时实施。该机制用于验证access token和counter的合法性，并在异常情况时调用超时访问机制或丢包/重传机制。
[0098]
如图4所示，主体发送请求后，主体代理监听到消息，复制请求数据包内容，向主体存储空间获取与请求进程对应的access token，把access token和counter一起添加到数据包中，再对包进行hmac加密后发出。表3的算法3呈现了主体代理对请求的处理与转发机制。
[0099]
表3
[0100][0101]
客体代理接收到含有access token的数据包后，将执行验证工作。客体此时只需要验证access token和counter的合法性，不再需要执行身份认证与授权工作，若二者均合法，则请求会被发送给客体进程，客体进程执行请求的操作。此处access token的合法性指：
[0102]
1、access token由客体签发且未被篡改(由签名验证)。
[0103]
2、access token包含主体请求的权限(由权限信息验证)。
[0104]
3、access token未过期(由签发时间和有效期验证)。
[0105]
若access token未过期但不合法，则表示用户已更改规则收回权限，此时客体返回请求失败的信息，请求直接被拒绝；若access token过期，则客体返回一个表示token失效的错误码，此时需要进行token的更新，即调用超时访问机制。若counter不合法，则调用丢包/重放访问机制。
[0106]
表4的算法4呈现了客体代理的验证机制，包括对存有访问控制规则数据包的验证和对存有access token数据包的验证。客体代理是一个反向代理，反向代理对于主体用户同样是透明的，反向代理负责接收主体发送过来的数据包，进行解密和验证，验证通过后再将解密后的包转发给真正的客体进程，如图4所示，客体进程接收到的包将不再包含counter或签名，而是直接可执行的请求。
[0107]
表4
[0108][0109]
超时访问：
[0110]
超时访问机制在访问验证机制发现access token过期时实施。该机制用于请求主体的refresh token，验证refresh token的合法性并生成新的access token和refresh token。
[0111]
如图5所示，客体返回access token失效的错误，此时主体将refresh token连带过期的access token一起发给客体，由客体代理验证refresh token的合法性。同样，实线表示数据包的传递，虚线表示proxy对主客体存储空间的读写，并不需要主客体进程的主动参与。其中，refresh token的合法性指：
[0112]
1、refresh token由客体签发且未被篡改(由签名验证)。
[0113]
2、refresh token未被禁用(由客体存储空间验证)。
[0114]
3、refresh token与access token匹配(由access token信息验证)。
[0115]
4、refresh token未过期(由签发时间和有效期验证)。
[0116]
若refresh token合法则下发新的access token和refresh token，其中，新的access token荷载内容除了签发时间与有效期外，其余信息与原来不变。在荷载内容中，除了签发时间与有效期外，其他信息均相同的access token同一时刻只能存在一个，与之对应的refresh token也只能存在一个，若有多个，则签发时间最晚的为有效的access token和refresh token。当需要禁用一个access token时，只需要将客体的refresh token删除或加入黑名单。在超时访问机制下，主客体交互的所有信息都需要经过hmac加密，加密机制与算法3相似。
[0117]
丢包/重放访问：
[0118]
丢包/重放访问机制在访问验证机制发现接收包内的counter与本地的counter不一致时实施。该机制用于调用重设counter的函数，使主客体counter保持一致。
[0119]
本技术的方法利用一个整数counter来识别携带token的数据包，以避免重放攻击。counter的初始值为0，考虑到tcp协议和udp协议的传输差异，此处对两种协议采用不同的counter同步机制：对于基于tcp协议的连接，counter在通信双方进行三次握手后完成初始化，counter值在同一个tcp连接中一直保持不变，直到四次挥手结束，tcp连接断开后，通信双方才同步把counter数值加一；对于基于udp协议的连接，每一个数据包携带的counter值都不同，发送方每发送一个包就把自己的counter加一，而接收方每接收一个包就把自己的counter加一。
[0120]
丢包/重放访问机制由两个proxy商议出新的counter值，即图6中方框内的字段。若接收方的counter小于包内counter，则表示发送方发出的包多于接收方收到的包，该情形多发生于udp连接，表示传输过程中发生了丢包；若接受方的counter大于包内的counter，则表示发送方发送了重复的包，意味着可能出现了重放攻击，此时将认为通信出现问题。若counter不一致，则客体会返回要求重新商议counter的信息，主客体将重设counter，若发生丢包，则还需要进行重传。
[0121]
由于counter的数值以数据包为粒度，故通信双方的counter差值通常应小于10，我们把误差范围扩大到100，设置重设counter的公式为：
[0122][0123]
根据本技术实施例提出的适用于智能家居环境的分布式跨设备访问控制方法，基于访问认证凭证每一个数据包进行认证，摆脱了访问控制对第三方服务或规则数据集的依赖，增大了对每一个通信数据包的监控力度，同时又降低了iot设备进行访问控制的资源开销。访问验证凭证与更新凭证并行的方式能够避免访问验证凭证一经发出就永久有效而带来的安全隐患，也避免了用户频繁的授权认证。利用代理对数据包进行加密与转发，解决了跨设备通信时通信双方在认证之前就建立连接而带来的安全问题，同时隐藏了设备进程的实际端口与内部细节，避免了利用暴露的端口造成的攻击。
[0124]
其次参照附图描述根据本技术实施例提出的适用于智能家居环境的分布式跨设备访问控制装置。
[0125]
图7为根据本技术实施例的适用于智能家居环境的分布式跨设备访问控制装置的示例图。
[0126]
如图7所示，该适用于智能家居环境的分布式跨设备访问控制装置10应用于智能家居环境，该装置10包括：准备模块100、连接建立模块200、第一请求模块300、第一验证模块400、第二请求模块500、第二验证模块600和更新模块700。
[0127]
其中，准备模块100，用于控制主体与客体从云端获取规定进程所具备的权限信息的访问控制规则，并基于访问控制规则对请求的发送和响应进行限制，其中，主体与客体在本地分别持有一个用于标识数据包的正整数counter。
[0128]
连接建立模块200，用于控制主体与客体建立连接，其中，当主体与客体首次进行通信时，主体先发送连接请求，客体验证主体的身份及主体权限的合法性，若合法，则建立
architecture，简称为eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0144]
可选地，在具体实现上，如果存储器801、处理器802及通信接口803，集成在一块芯片上实现，则存储器801、处理器802及通信接口803可以通过内部接口完成相互间的通信。
[0145]
处理器802可能是一个中央处理器(central processing unit，简称为cpu)，或者是特定集成电路(application specific integrated circuit，简称为asic)，或者是被配置成实施本技术实施例的一个或多个集成电路。
[0146]
本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的适用于智能家居环境的分布式跨设备访问控制方法。
[0147]
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
[0148]
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本技术的描述中，“n个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
[0149]
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
[0150]
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或n个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。
[0151]
应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件
或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。
[0152]
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
[0153]
此外，在本技术各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
[0154]
上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本技术的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本技术的限制，本领域的普通技术人员在本技术的范围内可以对上述实施例进行变化、修改、替换和变型。