A method for ensuring secure access and operation of devices in smart home

Abstract

The present invention belongs to the technical fields of privacy protection, access control, and identity authentication, and proposes a method for ensuring secure access and operation of devices in smart homes. The method includes four steps: establishing a model, specifying constraints, role assignment and permission assignment, and access control. The model introduces device functional roles and privacy roles from the perspective of devices, and uses the mapping relationship between functional roles and context attributes to ensure that user permission assignment meets environmental requirements; by dividing devices into different geographical domains, location parameters and device privacy roles are used to restrict user access to ensure personal device privacy. The model standardizes the permission assignment and use of user roles from both functional and privacy aspects, which can not only meet the privacy requirements of user devices, but also avoid creating a large number of device roles and environmental roles. When a user requests access, permission will be granted only when both the user has relevant operation permissions and can access the corresponding privacy devices are satisfied.

Description

Technical Field

[0001] The present invention belongs to the technical field of privacy protection, access control and identity authentication, and specifically relates to a method for ensuring secure access and operation of devices for smart homes. Background Art

[0002] With the rapid development of information technology and its integration with home networks, smart homes have become one of the fastest-growing fields in the Internet of Things and a current research hotspot. Smart home is an application of Internet of Things technology. Through the intersection of multiple fields and disciplines, it transforms traditional homes into an intelligent system, effectively improving the comfort, convenience, energy conservation, environmental protection and security of home life, and thus improving the quality of people's home life.

[0003] When people enjoy the convenience brought by smart homes, certain security problems also arise: children may accidentally or intentionally access a smart oven, which may cause a fire; a worker who comes to repair the dishwasher temporarily may try to control the camera during his working hours; a temporary guest may try to open the door lock at midnight. The above problems stem from the lack of reasonable authorization for visitors. Therefore, there is an urgent need for a security mechanism to prevent illegal access by malicious users and unauthorized access by legitimate users. The home Internet of Things is significantly different from other Internet of Things application fields, such as the industrial Internet of Things, in three main aspects. First, in the home Internet of Things, many users use the same device, such as a smart door lock. When multiple users share a device, traditional access control technologies can no longer meet the requirements; second, there are usually complex social relationships among household members, which introduces a new threat model, such as a child trying to control the smart light in a sibling's room; another main feature of Internet of Things devices is that most devices do not have a screen and keyboard, which is inconvenient for operation and almost impossible to send passwords or verification codes to the system. All these make access control, authorization and authentication for the Internet of Things more challenging; in addition, according to the online user survey of smart homes, even members in the same home environment hope to ensure personal privacy security, that is, the home access control model needs to consider the privacy needs of different users who hope to exclusively enjoy all the permissions of certain smart devices. These characteristics indicate that in the case of limited users and resources, the smart home Internet of Things needs a dynamic fine-grained access control model that can ensure the privacy security of personal devices.

[0004] Many scholars have conducted research on the current access control specifications in the home Internet of Things: The Attribute-Based Access Control (ABAC) model grants access rights based on the attributes associated with users and resources. However, designing and implementing an ABAC model for the Internet of Things is not simple. Its implementation usually requires a large amount of computation, which is unbearable for resource-constrained smart devices in the home Internet of Things environment. In addition, determining a suitable set of attributes is crucial. The increase in the number of attributes may lead to conflicts between access policies, which are difficult to detect and resolve. The Role-Based Access Control (RBAC) model associates permissions with roles, making users members of the corresponding roles to obtain the permissions of the roles. However, the role-based access control model usually requires defining a large number of roles to achieve fine-grained access control, resulting in the problem of role explosion, increasing the difficulty of model establishment and maintenance. Moreover, the role-based access control model usually cannot capture the changes in the environmental state, lacking the perception of environmental context in complex environments and having insufficient flexibility. In addition, some blockchain technology-based solutions are not applicable to the home Internet of Things environment due to their inherent technical characteristics such as encryption costs and processing times. The above models do not conform to the access control model standards of smart homes and cannot meet the characteristics of being dynamic, fine-grained, and ensuring the privacy of personal devices. Summary of the Invention

[0005] Aiming at the problems of cumbersome permission allocation, difficulty in capturing environmental state changes, and insufficient protection of personal device privacy in traditional access control technologies for the home Internet of Things, the present invention provides a method for ensuring secure access and operation of devices in smart homes. This method not only simplifies user permission allocation but also ensures the privacy nature of devices.

[0006] To achieve the above object, the present invention is implemented through the following technical solutions:

[0007] The present invention is a method for ensuring secure access and operation of devices in smart homes, and the method includes the following steps:

[0008] Step 1) Establish a model. The present invention is based on the basic RBAC model, and the model includes basic elements such as user (User), role (Role), and device (Device). Aiming at problems such as cumbersome permission allocation and insufficient protection of personal device privacy, role analysis is re - carried out and extended. The intelligent devices (Device) and operations (Operation) in the model are combined and labeled as permissions (Permission), and similar permissions are integrated into device roles (DeviceRole); environmental roles (ER) are created as the context states for roles to exercise permissions; device privacy roles (Device Privacy Role) are created to classify intelligent devices from the perspective of privacy protection; location (Location) parameters are created to restrict role access to privacy devices.

[0009] Step 2) Specify constraints. When assigning permissions to role R, constraints need to be created to regulate permission allocation. Two aspects of constraints are created in this model. The PRC (Permission - role constraint) constraint specifies that role R is prohibited from being assigned specific permissions; the PDRC (Private Devicerole - Role constraint) constraint stipulates that role R cannot be assigned specific device privacy roles.

[0010] Step 3) Role assignment and permission assignment. Before assigning roles, users need to register as legal users of the system, and the administrator assigns appropriate roles to users according to user relationships. Permissions are assigned to user roles from two aspects. In terms of privacy protection, combined with the location parameter L, the device privacy role DPR is assigned to user role R, and in terms of function use, combined with the environmental role, the device role is assigned to the user role.

[0011] Step 4) Access control. After the model is deployed and running, when a legitimate user sends an access request, the model will analyze and verify according to the parameters in the request, combined with the permission assignment results of the current user's held roles during permission assignment. If the verification passes, the operation command is sent to the specific device to implement the operation; if the verification fails, access is denied.

[0012] Among them, the specific content of the said Step 1) is as follows:

[0013] Step 11) First, create roles (r x ∈R = {r 1, r2..r x ..}), devices (d j ∈D = {d 1, d2..d j ..}), operations (op k = OP = {op1,op2..op k ..}), locations (lt ∈L = {l1, l2.. l t ..}).

[0014] Step 12) Create device privacy roles (dpr y ∈DPR = {dpr1, dpr2.. dpr y ..}) according to the membership relationship and device privacy requirements, classify the devices, and establish a many-to-one assignment relationship from device D to device privacy role DPR Establish an association relationship between device D and operation OP to construct permissions (p q = (op, d), p q ∈P = {p1, p q2 .. p q ..}). Create device roles (dr m ∈DP = {dr1, dr2.. dr m ..}), and establish a many-to-many assignment from device roles to permissions to integrate some permissions onto device roles.

[0015] Step 13) The administrator sets different environmental conditions e according to different environmental attributes, and then creates an environmental condition set (EC = {e1, e2.. e n ..}); Select a subset of conditions from the environmental condition set and label it as an environmental role as the context state for a role to exercise permissions.

[0016] The specific steps of step 2) are as follows:

[0017] Step 21) Create a PRC constraint, expressed as Establish a many-to-many relationship from a subset of permissions to a subset of roles. Each prc = (P i , R j ) specifies the following invariant for each p m ∈P i and r n ∈R j that cannot be violated during the permission assignment process.

[0018]

[0019] Cannot be violated during the permission assignment process.

[0020] Step 22) Create a PDRC constraint, establish a many-to-many assignment between a subset of device privacy roles and a subset of roles, expressed as Each pdrc = (DPR i , R j ) for each dpr m ∈DPR iand r n ∈R j Specify the following invariant:

[0021]

[0022] It cannot be violated during the permission assignment process.

[0023] The specific steps of step 3) are as follows:

[0024] Step 31) The permission assignment includes two aspects. In terms of function usage, the user roles are authorized and assigned in units of device roles DR. First, an association relationship between the user role R and the environment role ER is established to construct the role pair Then, the device role DR is assigned to the role pair RP to establish a many-to-many assignment relationship from the device role to the role pair RP

[0025] Step 32) In terms of privacy protection, the user roles are authorized and assigned in units of device privacy roles DPR. First, an association relationship between the user role R and the location L is established to construct the role pair Then, the device privacy role DPR is assigned to the role pair RL to establish a many-to-many assignment relationship from the device role DPR to the role pair RL

[0026] The specific steps of step 4) are as follows:

[0027] When the user makes an access request, the device parameters and operation parameters are submitted. The system verifies from two aspects: First, the system detects the current environmental state and determines whether the user has the operation permission for the expected device under the current environment role; if so, continue the verification, otherwise reject the access.

[0028] Step 42) Secondly, the system extracts the user's access location parameter L and determines whether the user can access the expected device at this location. If both verifications are successful, access is allowed; if any condition verification fails, access is rejected.

[0029] The beneficial effects of the present invention are as follows: The present invention is based on the basic RBAC model, and in view of the problems such as cumbersome permission assignment and insufficient personal device privacy protection, the role analysis is re-conducted and extended. While simplifying the permission assignment, it also supports the protection of personal device privacy. Specifically:

[0030] (1) The present invention extends the device role, integrates similar device permissions, and performs permission assignment in units of device roles, simplifying the user's permission assignment.

[0031] (2) The present invention extends the environmental role, enabling the model to capture the environmental context changes and device characteristics during the access control process, enhancing the flexibility of the model.

[0032] (3) The present invention extends the device privacy role and location parameters, classifies intelligent devices using the device privacy role to determine the privacy nature of the devices, and restricts user access to intelligent devices using the location parameters, ensuring device privacy. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 is a flowchart of the present invention.

[0034] Figure 2 is a component diagram of the present invention.

[0035] Figure 3 is the specific access control process of the user. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0036] The following will disclose the embodiments of the present invention with reference to the drawings. For the sake of clarity, many practical details will be described together in the following description. However, it should be understood that these practical details are not used to limit the present invention. That is to say, in some embodiments of the present invention, these practical details are not necessary.

[0037] Aiming at the disadvantages of limited computing resources, large differences in heterogeneous devices, and insufficient privacy protection in smart homes, the present invention conducts extended role analysis and re - models access control. An environmental role and geographical location are introduced into the model, enabling the user role to meet the corresponding environmental status when accessing a device. Access that does not conform to the predetermined environmental role in the model is rejected, enhancing the security and flexibility of the model and standardizing the use of user permissions at the same time. The device function role and device privacy role are introduced into the model. The device function role inherits some partial permissions of the device, which can greatly reduce the complexity of permission allocation. At the same time, each device function role is an integration of similar permissions, facilitating the reasonable allocation of user permissions and subsequent management. The device privacy role classifies intelligent devices in combination with user living habits and personal device privacy requirements, and restricts user access to intelligent devices with the help of location parameters, thus ensuring personal device privacy. When a user applies to access an intelligent device, the user needs to provide the current environmental conditions and location area. Only when both the device permissions of the user and the privacy device are verified can the user be allowed to execute relevant permissions on the device.

[0038] Specifically, as Figure 1 shown, the present invention provides a method for ensuring secure access and operation of devices in smart homes, including the following steps:

[0039] Step 1: Establish a model. The model includes user U (User), role R (Role), device D (Device), location L (Lication), operation OP (Operation), permission P (Permission), device role DR (Device Role), device privacy role DPR (Device Privacy Role), environment condition set EC (Environment Condition), environment role ER (Environment Role), role pair RP (Role-Environment Pairs), and role pair RL (Role-Location Pairs). User U represents the subject authorized to interact with intelligent devices. Role R represents the social relationships among subjects. Device D represents intelligent devices with restricted access. Location L parameter identifies different location areas in the Internet of Things environment. Operation OP represents the operations that can be performed on a device. Permission P is the approval for performing an operation on a device, that is, a mapping between an operation OP and its owner device D. Device role DR is a way to classify the permissions P of different devices D. Device privacy role DPR is a way to classify device D according to the privacy requirements of role R for it. Environment condition set EC is a set composed of environmental attributes used for system resource access control in the environment. Environment role ER represents the environmental context and is a way to classify environmental conditions. Role pair RP is a valid combination composed of role R and environment role ER, specified by the administrator. Role pair RL is a valid combination composed of role R and location area L, specified by the administrator. When the model is used, there must always be a user as the administrator to assign permissions for these relationships, and these relationships specified by the administrator are valid relationships.

[0040] The specific steps for establishing the model are as follows:

[0041] Step 1-1: First, create role R, device D, operation OP, and location L. Among them, role R satisfies: r x ∈R = {r 1, r2..r x ..}, r x represents the elements in R. Device D satisfies d j ∈D = {d 1, d2..d j ..}, d j represents the elements in device D. Operation OP satisfies op k = OP = {op1,op2..op k ..}, where op k represents the elements in operation OP. Location satisfies l t ∈L = {l1,l2..l t..}, l t Represents the element at position L;

[0042] Step 1-2: According to the membership relationship and device privacy requirements, create the device privacy role DPR (dpr y ∈ DPR = {dpr1, dpr2.. dpr y ..}), and classify device D, establishing a many-to-one assignment relationship from device D to the device privacy role DPR Establish an association relationship between device D and operation OP to construct the permission P (p q = (op, d), p q ∈ P = {p1, p q2 .. p q ..}), create the device role DR (dr m ∈ DR = {dr1, dr2.. dr m ..}), establish a many-to-many assignment from the device role DR to the permission P To integrate similar permissions onto the device role DR;

[0043] Step 1-3: The administrator sets different environmental conditions e according to different environmental attributes, and then creates the environmental condition set EC = {e1, e2.. e n ..}, selects a conditional subset from the environmental condition set, and identifies it as the environmental role As the context state for the role to exercise permissions.

[0044] Step 2, Specify constraints. When assigning permissions to role R, constraints need to be created to regulate the permission assignment. The model creates two constraints. The PRC (Permission-role constraint) constraint specifies that role R is prohibited from being assigned a specific permission; the PDRC (Private Device role-Role constraint) constraint stipulates that role R cannot be assigned a specific device privacy role DPR. Specifically, creating constraints includes the following steps:

[0045] Step 2-1: Create the PRC constraint, expressed as Establish a many-to-many relationship from the permission subset to the role subset, where each prc = (P i , R j ) for each p m ∈ P i and r n ∈ R j Specify the following invariant:

[0046]

[0047] rp p rp is an element in the role pair RP, and dr q dr is an element in the device role DR. RPDRA is a many-to-many assignment relationship set from the device role to the role pair RP, and p m is an element in the permission P. PDRA is a many-to-many assignment relationship set from the device role to the permission, and r n is an element in the role R and cannot be violated during the permission assignment process;

[0048] Step 2-2: Create the PDRC constraint and establish a many-to-many assignment between the device privacy role subset and the role subset, denoted as Each pdrc = (DPR i , R j ) for each dpr m ∈ DPR i and r n ∈ R j Specify the following invariant:

[0049]

[0050] dpr q is an element in the device privacy role DPR, and rl p is an element in the role pair RL. RLDPRA is a many-to-many assignment relationship set from the device role DPR to the role pair RL, and r n is an element in the role R and cannot be violated during the permission assignment process.

[0051] Step 3: Role assignment and permission assignment. Before assigning roles, the user needs to register as a legitimate user of the system. The administrator assigns appropriate roles to the user based on the user relationship and assigns permissions to the user role from two aspects. In terms of privacy protection, the device privacy role is assigned to the user role in combination with the location parameter, and in terms of function usage, the device role is assigned to the user role in combination with the environmental role. Specifically:

[0052] Step 3-1: In terms of function usage, authorize and assign the user role in units of the device role DR. First, establish the association relationship between the user role R and the environmental role ER, and construct the role pair Then assign the device role DR to the role pair RP and establish a many-to-many assignment relationship from the device role to the role pair RP

[0053] Step 3-2: In terms of privacy protection, authorize and assign the user role in units of the device privacy role DPR. First, establish the association relationship between the user role R and the location L, and construct the role pair Then the device privacy role DPR is assigned to the role pair RL, establishing a many-to-many assignment relationship from the device role DPR to the role pair RL

[0054] Step 4: Access control. After the model is deployed and running, when a legitimate user sends an access request, the model will analyze and verify according to the parameters in the request in combination with the permission assignment results for the roles held by the current user during permission assignment. If the verification passes, the operation command will be sent to the specific device to implement the operation; if the verification fails, access will be denied.

[0055] The access control specifically includes the following steps:

[0056] Step 4-1: When the user makes an access request, device parameters and operation parameters will be submitted, and the system will verify from two aspects: First, the system will detect the current environmental status and determine whether the user has the operation permission for the desired device under the current environmental role; if so, continue the verification, otherwise deny access;

[0057] Step 4-2: Secondly, the system will extract the user's access location parameter L and determine whether the user can access the desired device at this location. If both verifications are successful, access will be allowed; if any condition verification is not met, access will be denied.

[0058] In specific implementation, Figure 2 It is a schematic diagram of all the components and component relationships included in this access control model. In the field of smart home, the access control model must ensure to prevent illegal access by malicious users and unauthorized access by legitimate users. However, the social relationships between users will bring new threat models. For example, a child tries to control the smart lights in the sibling's room, causing trouble to the other. Therefore, users need to ensure the privacy security of personal devices to restrict access by other users to personal devices. Usually, personal privacy devices are related to personal living habits. Therefore, this model extends roles on the basis of the original RBAC model, creates device privacy roles, and uses the access location to restrict users' access to personal privacy devices. At the same time, in order to simplify the permission assignment operation, device roles are created to integrate the permissions of similar devices. Finally, environmental roles are created to specify the specific context environment required when users perform access control. On this basis, every user must pass two aspects of verification when performing access device permissions. Only when the user has the relevant device permissions under the current environmental conditions and can access the device at the current location, will the access request be allowed.

[0059] Figure 3This is the access process of the present invention. When user u makes an access, the device parameters d and operation parameters op will be submitted. The system will check whether the current user has been assigned a predetermined role. If so, assume it is r. Then the system checks whether there is a role pair rp in the set of RP role pairs associated with role r, which is composed of role r and the environmental role er triggered by the current active environmental conditions. If it exists, the system will continue to check whether the device role dr associated with role pair rp contains the permission p formed by device d and operation op. If all verifications pass, the device permission verification part passes; otherwise, access is directly rejected. Then the system checks whether there is a role pair rl in the set of RL role pairs associated with role r, which is composed of role r and the current user access location l. If it exists, the system will continue to check whether the device privacy role dpr associated with role pair rr contains device d. If all verifications pass, the device privacy verification part passes; otherwise, access is directly rejected. Only when both parts pass the verification is the user access request allowed.

[0060] Suppose in a smart home scenario, Ben is assigned the role of ChildA. The smart devices include TV1 and TV2, where TV1 is placed in Proom (Parents Room) and TV2 is placed in Droom (Drawing Room). Permissions P1 and P2 are defined on TV1 and TV2 respectively, and these two permissions represent the operation of turning on TV1 and TV2 respectively. Permissions P1 and P2 are both integrated into the device role ED (Entertainment Device), and it is stipulated that only in the environmental role ET (EntertainmentTime), role ChildA can access the permissions on device role ED, where ET is assumed to be defined as Saturday and before 10:00 pm. Assume that user role ChildA and environmental role ET form role pair rp1. At the same time, TV1 and TV2 are respectively assigned the device privacy roles PPr (Parents-room Private Role) and Dpu (Drawing-room PublicRole), and it is stipulated that role ChildA can access the devices on device role Dpu anywhere and cannot access the devices on PPr anywhere. Assume that user role ChildA and location Droom (Drawing room) form role pair rl2.

[0061] Suppose Ben is in the living room Droom and tries to turn on TV2 at 8:00 pm on Saturday. Then the system needs to verify whether the user's access is a legal operation. Ben is assigned the role of ChildA. It is necessary to verify whether there is a role pair rp in the set of RP role pairs associated with the ChildA role, which is composed of ChildA and the environmental role er triggered by the current active environmental conditions. The current environment can activate the environmental role ET, which conforms to the predefined role pair rp1, and the verification passes. Then it is verified whether there is an assignment relationship between this role pair and the device role possessed by TV2. TV2 has the ED device role, and there is a predefined relationship between ED and rp1, so the verification passes. Then it is verified whether there is a role pair rl in the RL role pairs related to the ChildA role, which is composed of ChildA and Droom. Since it is stipulated in advance that ChildA can access TV2 anywhere, it conforms to the predefined role pair rl2, and the verification passes. Finally, it is verified whether there is an assignment relationship between the rl2 role pair and the device privacy role possessed by TV2. TV2 has the device privacy role Dpu, and there is a predefined relationship between rl2 and Dpu, and the verification passes. In summary, after all verifications pass, the system determines that the access behavior is legal, and Ben can turn on TV2.

[0062] Suppose Ben is in the living room Droom and tries to turn on TV1 at 8:00 pm on Saturday. The previous verification process is similar, and all verifications pass until finally it is verified whether there is an assignment relationship between the rl2 role pair and the device privacy role DPR possessed by TV1. TV2 has the device privacy role PPr, and there is no predefined relationship between rl2 and Dpu, so the verification fails. Therefore, the system determines that the access behavior is illegal, and Ben cannot turn on TV1.

[0063] The model of the present invention introduces device functional roles and privacy roles from the device perspective, and uses the mapping relationship between functional roles and context attributes to ensure that user permission allocation meets environmental requirements; by dividing devices into different geographical domains, location parameters and device privacy roles are used to restrict user access to ensure personal device privacy. The model standardizes the permission allocation and use of user roles from both functional and privacy aspects, which can not only meet the needs of ensuring user device privacy, but also avoid creating a large number of device roles and environmental roles, reducing the complexity of permission allocation. When a user requests access, permission is granted only when both the user has the relevant operation permissions and can access the corresponding privacy device.

Claims

1. A method for ensuring secure access and operation of devices in a smart home, characterized in that: The method includes the following steps: Step 1, Establish a model: The model includes user U, role R, device D, location L, operation OP, permission P, device role DR, device privacy role DPR, environmental condition set EC, environmental role ER, role pair RP, and role pair RL. Establishing the model specifically includes the following steps: Step 1-1: First, create roles R, devices D, operations OP, and locations L; Step 1-2: Create a device privacy role DPR according to the membership relationship and device privacy requirements, classify device D, and establish a many-to-one assignment relationship from device D to the device privacy role DPR Establish an association relationship between device D and operation OP to construct permission P, create device role DR, and establish a many-to-many assignment from device role DR to permission P To integrate similar permissions onto device role DR; Creating constraints specifically includes the following steps: Step 2-1: Create a PRC constraint, denoted as Establish a many-to-many relationship from a subset of permissions to a subset of roles, where each prc = (P i , R j ) for each p m ∈ P i and r n ∈ R j Specify the following invariant: rp p is an element in the role pair RP, dr q is an element in the device role DR, RPDRA is a set of many-to-many assignment relationships from the device role to the role pair RP, p m is an element in the permission P, PDRA is a set of many-to-many relationships from the device role to the permission, r n is an element in the role R and cannot be violated during the permission assignment process; Step 2-2: Create PDRC constraints to establish a many-to-many assignment between the device privacy role subset and the role subset, denoted as each pdrc = (DPR i , R j ) for each dpr m ∈ DPR i and r n ∈ R j specify the following invariant: dpr q is an element in the device privacy role DPR, rl p refers to the element in RL. RLDPRA is a set of many-to-many assignment relationships from the device role DPR to the role pair RL, r n is an element in the role R and cannot be violated during the permission assignment process; Step 1-3: The administrator sets different environmental conditions e according to different environmental attributes, and then creates an environmental condition set EC = {e1, e2..e n ..}, selects a condition subset from the environmental condition set, and identifies it as an environmental role as the context state for the role to exercise permissions; Step 2, Specify constraints: When assigning permissions to role R, constraints need to be created to regulate the permission assignment. The model creates two constraints. The PRC constraint specifies that role R is prohibited from being assigned specific permissions; the PDRC constraint stipulates that role R cannot be assigned a specific device privacy role DPR; Step 3, Role assignment and permission assignment: Before assigning roles, users need to register as legitimate users of the system. The administrator assigns appropriate roles to users based on the user relationship and assigns permissions to the user roles from two aspects. In terms of privacy protection, the device privacy role is assigned to the user role in combination with the location parameter. In terms of function usage, the device role is assigned to the user role in combination with the environmental role; Step 4, Access control: After the model is deployed and running, a legitimate user sends an access request. The model will analyze and verify according to the parameters in the request in combination with the permission assignment result of the current user's held role during permission assignment. If the verification passes, the operation command will be sent to the specific device to implement the operation; if the verification fails, access will be refused.

2. The method for ensuring secure access and operation of devices in a smart home according to claim 1, characterized in that: The permission assignment in step 3 includes two aspects, specifically: Step 3-1: In terms of function usage, authorize and allocate user roles in units of device roles DR. First, establish the association relationship between user roles R and environmental roles ER to construct role pairs Then allocate device role DR to role pair RP to establish a many-to-many allocation relationship from device role to role pair RP Step 3-2: In terms of privacy protection, authorize and allocate user roles in units of device privacy roles DPR. First, establish the association relationship between user roles R and locations L to construct role pairs Then, allocate the device privacy role DPR to the role pair RL to establish a many-to-many allocation relationship from the device role DPR to the role pair RL 3. A method for ensuring secure access and operation of devices in a smart home according to claim 1, characterized in that: The access control in step 4 specifically includes the following steps: Step 4-1: When the user makes an access request, device parameters and operation parameters will be submitted. The system verifies from two aspects: First, the system will detect the current environmental state and determine whether the user has the operation permission for the desired device under the current environmental role; if so, continue the verification, otherwise refuse access; Step 4-2: Secondly, the system will extract the user's access location parameter L and determine whether the user can access the desired device at this location. If both verifications are successful, access will be allowed; if any condition verification is not met, access will be refused.

4. A method for ensuring secure access and operation of devices in a smart home according to any one of claims 1-3, characterized in that: In the model of step 1, user U represents the subject authorized to interact with intelligent devices, role R represents the social relationship between subjects, device D represents the intelligent device with restricted access, location L parameter identifies different location areas in the Internet of Things environment, operation OP represents the operations that can be performed on the device, permission P is the approval for performing an operation on a device, that is, a mapping between an operation OP and its owner device D. Device role DR is a way to classify the permissions P of different devices D; device privacy role DPR is a way to classify devices D according to the privacy requirements of role R for device D. Environmental condition set EC is a set composed of environmental attributes used for system resource access control in the environment. Environmental role ER represents the environmental context and is a way to classify environmental conditions; role pair RP is an effective combination composed of role R and environmental role ER, specified by the administrator. Role pair RL is an effective combination composed of role R and location area L, specified by the administrator.

Images