Multi-level dynamic smart home privacy authentication method based on verifiable voucher

Abstract

The invention relates to the field of privacy protection, in particular to a multi-level dynamic smart home privacy authentication method based on verifiable certificates. The method comprises the following steps: S1, receiving an access request of a user; the access request comprises a user decentralized identifier (DID) and a verifiable voucher VC, and the verifiable voucher VC is bound with the user DID and applies for signing and issuing from an identity provider for the user; step S2, executing a DID identity authentication step; step S21, extracting a signer DID, a signature and a to-be-verified message from the verifiable voucher VC, and verifying whether the signature is correct or not; and step S22, if the signature verification is correct, analyzing a DID document according to the user DID and obtaining a public key and a verification path of the DID document, carrying out Hash processing on the user DID and calculating whether the Hash is the same as Merkle root Hash stored on the block chain in advance according to the obtained verification path, and if the Hash is the same as the Merkle root Hash stored on the block chain in advance, the user identity authentication is successful. According to the invention, the problem of privacy leakage caused by malicious behaviors of internal personnel of a service provider in an existing smart home scene can be solved.

Description

Technical Field

[0001] This invention relates to the field of privacy protection, and specifically to a multi-level dynamic smart home privacy authentication method based on verifiable credentials. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) and wireless communication technologies, smart home systems have demonstrated significant advantages in enhancing the intelligence and convenience of living environments. However, the interconnectivity between devices and the widespread adoption of remote control functions have also led to increasingly serious privacy breaches. The malicious theft and sale of user identity information and device behavior data by insiders of smart home service providers can easily result in the creation of behavioral profiles, privacy leaks, and even issues with user identifiability. Therefore, protecting user privacy is an urgent area requiring research.

[0003] Currently, the mainstream methods fall into three categories: data obfuscation, decentralized storage, and anonymous credentials. Data obfuscation reduces the identifiability of the original data by adding random noise or generating synthetic data at the collection point; some solutions also employ local differential privacy or oversampling-Gaussian noise mixing strategies. However, service providers may still be able to link user identity information and behavioral data through their possession. Decentralized storage leverages blockchain, distributed ledgers, or content-addressed networks to distribute and store user data, and uses aggregate signatures, differential privacy, and other methods to improve tamper resistance and data sovereignty. However, decentralized storage still faces the risk of potential privacy breaches due to smart home service providers excessively accumulating user identity information. Anonymous credentials are digital documents that allow users to prove they possess specific attributes or qualifications to service providers without revealing their real identity and without being trackable. Nevertheless, the method of combining anonymous credentials with multi-factor authentication lacks dynamic authentication strength scheduling and fine-grained log encryption mechanisms for highly sensitive device scenarios, making it difficult to simultaneously achieve security, privacy, and operational efficiency.

[0004] Therefore, there is an urgent need to design a new smart home authentication method with privacy protection to solve the above problems. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to overcome the defects of the prior art and provide a multi-level dynamic smart home privacy authentication method based on verifiable credentials, which can solve the privacy leakage problem caused by malicious behavior of service provider insiders in existing smart home scenarios.

[0006] To address the aforementioned technical problems, the technical solution of this invention is: a multi-level dynamic smart home privacy authentication method based on verifiable credentials, comprising: Step S1, receive the user's access request; among them, the access request includes the user's decentralized identifier (DID) and the verifiable credential VC. The user's decentralized identifier (DID) is registered by the user through the DID generation tool provided by the identity provider, and the verifiable credential VC is bound to the user's DID and is applied and issued by the user to the identity provider. Step S2, perform the DID identity authentication step: Step S21, extract the issuer DID, signature and the message to be verified from the verifiable credential VC, and verify whether the signature is correct; Step S22, if the signature verification is correct, parse the DID document according to the user's DID and obtain its public key and verification path, perform a hash operation on the user's DID, and calculate whether it is the same as the Merkle root hash stored on the blockchain in advance according to the obtained verification path. If it is the same, the user identity authentication is successful.

[0007] Furthermore, registering the user's DID based on the DID generation tool provided by the identity provider includes: The DID generation tool calls the secure cryptographic library Bouncy Castle to construct an Ed25519 elliptic curve environment and generates a key pair in a trusted execution environment.

[0008] Furthermore, the DID generation tool calls the secure cryptographic library Bouncy Castle to construct an Ed25519 elliptic curve environment and generates a key pair in a trusted execution environment, specifically including: Step A, the DID generation tool calls the true random number generator to generate a 32-byte seed, and obtains the private key that satisfies 0 < d < q through SHA512 hashing and clamp operation and obtains the public key through the point multiplication operation on the elliptic curve , and the public key calculation formula is as follows:

[0009] where G is the fixed base point on the curve and q represents the order of the elliptic curve; Step B, the DID generation tool uses the SHA256 hashing function to perform a hashing operation on the public key to obtain a 32-bit hash digest; Step C, use Base58 to perform an overall encoding on the hash digest to obtain the DID string, and the DID string is expressed as:

[0010] Step D involves constructing a DID document containing a public key for verification, an optional server endpoint, and version information; the user then publishes the DID document, signed with their private key, to the immutable InterPlanetary File System, thus completing the user's DID registration.

[0011] Furthermore, the specific steps for an identity provider to issue a verifiable credential (VC) bound to a user's DID include: After verifying the user's DID and authentication information submitted by the user, the identity provider issues a verifiable credential VC containing the DID identifier, user claim attributes, issuer information, and validity period, and then signs it with its private key before giving it to the user.

[0012] Furthermore, after verifying the user's DID and authentication information submitted by the user, the identity provider issues a verifiable credential (VC) containing the DID identifier, user claim attributes, issuer information, and validity period, and then signs it with its private key before delivering it to the user; specifically including: Step a: After verifying the user's DID and authentication information submitted by the user, the identity provider generates the VC body content; wherein, the VC body content includes the issuer DID, holder DID, attribute assertion, issuance time, and expiration time; Step b: The identity provider standardizes the VC body content according to W3C specifications to obtain the data M to be signed; Step c, the identity provider generates a one-time random number using the Ed25519 algorithm. and Perform calculations to generate temporary curve points Then calculate the challenge hash. And through the issuer's private key Calculate response value Temporary curve point and response value Together they form a combined signature Combined signature As part of a verifiable document, it is used to verify the authenticity and validity of the verifiable document VC; the specific formula is:

[0014] In the formula, q represents the order of the elliptic curve. This represents the issuer's public key.

[0015] Furthermore, step S21 specifically includes: Recalculate the challenge hash , ; judge Whether or not If they are equal, the signature verification is correct; where .

[0016] Furthermore, the steps for storing the Merkle root hash on the blockchain are as follows: The identity provider hashes the DID identifiers of registered users and constructs a Merkle tree. The leaf nodes of the Merkle tree are the hash values ​​of each DID identifier; every two leaf nodes form the parent node of the Merkle tree; all parent nodes constitute the root node of the Merkle tree. Write the path from each user to the root node of the Merkle tree into the user's DID document, and finally save the root hash of the Merkle tree and the DID document index on the blockchain.

[0017] To further enhance security, the access request in step S1 also includes the security level of the smart home device. Step S2 also includes adding a face recognition step if the security level exceeds the threshold.

[0018] Furthermore, the facial recognition steps specifically include: Facial feature points are obtained from the detected face using the 68-point Landmark predictor from the Dlib library; the obtained facial feature points are then fed into the ResNet-50 face recognition model from the Dlib library, outputting 128... 3D facial feature vector; The Euclidean distance is used to compare the output 128-dimensional vector with the stored known face vectors.

[0019] Furthermore, the method also includes: Step S3: Access logs generated by users accessing smart home devices are encrypted and stored using an IBE algorithm based on bilinear pairing.

[0020] By adopting the above technical solution, this invention achieves minimal disclosure of identity by introducing decentralized identity, and completes credible identity verification without exposing any identifiable information. This cuts off the way service provider personnel can abuse centralized identity databases, fundamentally severs the direct link between real identity and behavioral data, and significantly reduces the risk of service providers or hackers reconstructing user profiles. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating the architecture of the multi-level dynamic smart home privacy authentication system based on verifiable credentials of the present invention. Figure 2 This is a flowchart illustrating the dynamic invocation of two-factor authentication based on the device security level in the multi-level dynamic smart home privacy authentication method based on verifiable credentials of the present invention. Figure 3It is the DID authentication flow chart in the multi-level dynamic smart home privacy authentication method based on verifiable credentials of the present invention; Figure 4 It is the schematic diagram of the Merkle tree of the present invention; Figure 5 It is the effect diagram of face input of the present invention; Figure 6 It is the effect diagram of face recognition of the present invention; Figure 7 It is the comparison chart of the time overhead of IBE encryption and ABE encryption of the present invention. Detailed implementation manners

[0022] In order to make the content of the present invention easier to be clearly understood, the present invention will be further described in detail below according to specific embodiments and in conjunction with the accompanying drawings.

[0023] As Figures 1 to 7 shown, a multi-level dynamic smart home privacy authentication method based on verifiable credentials includes: In the first step, the user first uses the DID generation tool provided by the identity provider (government department) to register DID for the user and the device, and applies to the identity provider for issuing a verifiable credential VC binding the DID.

[0024] Among them, the device registering DID is only used for unique identification. When the user initiates an access later, the request carries "user DID, target device DID, device security level" at the same time. Based on this, the platform knows "which device to operate", and after completing the verification of user DID + VC, it enters the subsequent policy judgment and access process. The steps for registering DID are that the user and the smart home device run the DID generation tool provided by the identity provider (government department) locally. This tool calls the secure cryptographic library BouncyCastle to construct an Ed25519 elliptic curve environment and generates a key pair in the trusted execution environment. Specifically, it includes: (1) The DID generation tool calls the true random number generator to generate a 32-byte seed, and through SHA512 hashing and clamp operation, obtains a private key satisfying 0 < d < q , and obtains the public key through the point multiplication operation on the elliptic curve ​​​​​​​​​​​​(2) The DID generation tool uses the SHA256 hash function to hash the public key. A hash operation is performed to obtain a 32-bit hash digest, which ensures that subsequent identifiers are both short and irreversible; (3) Encode the hash digest using Base58 to obtain the DID string, which is represented as:

[0027] Step D involves constructing a DID document containing a public key for verification, an optional server endpoint, and version information. This DID document serves as a public identity verification tool corresponding to a decentralized identity; external entities can verify the signature using it but cannot ascertain the holder's true identity. The user then publishes the signed DID document to the immutable InterPlanetary File System, thus completing identity registration.

[0028] The specific steps involved in an identity provider issuing a verifiable credential (VC) bound to a user's DID include: After verifying the user's DID and authentication information submitted by the user, the identity provider issues a verifiable credential (VC) containing the DID identifier, user claim attributes, issuer information, and validity period, and then signs it with its private key before delivering it to the user. The specific steps are as follows: (1) After verifying the user DID and authentication information submitted by the user, the identity provider generates the VC body content; wherein, the VC body content includes the issuer DID, the holder DID, attribute assertion (such as "for real-name authenticated user" or "for homeowner"), the issuance time, and the expiration time; (2) The identity provider standardizes the VC body content according to the W3C specification to obtain the data M to be signed; (3) The identity provider generates a one-time random number using the Ed25519 algorithm. and Perform calculations to generate temporary curve points Then calculate the challenge hash. And through the issuer's private key Calculate response value Temporary curve point and response value Together they form a combined signature Combined signature As part of a verifiable document, it is used to verify the authenticity and validity of the verifiable document VC; the specific formula is:

[0029] In the formula, q represents the order of the elliptic curve. This represents the issuer's public key.

[0030] The second step involves the identity provider hashing the registered users' DID identifiers and constructing a Merkle tree. The leaf nodes of the Merkle tree are the hash values ​​of each DID identifier; every two leaf nodes form the parent node of the Merkle tree; all parent nodes constitute the root node of the Merkle tree; specifically as follows... Figure 4 As shown, the path from each user to the root node of the Merkle tree is written into the user's DID document, and finally the root hash of the Merkle tree and the DID document index are stored on the blockchain.

[0031] The third step is for the user to initiate an access request to the smart home platform from their user terminal. The user terminal will... Send to the smart home platform; in, A decentralized identity identifier representing a user; This represents a decentralized identity identifier for the target device; Indicates the security level of the target device The request includes the following parameters. This is used to indicate the security sensitivity level of a device. Based on this level, the platform will automatically decide whether to enable additional authentication methods through policies defined by smart contracts.

[0032] After receiving a device access request, the smart home platform first performs the DID identity authentication step. After successful authentication, it calls the strategy smart contract to verify whether two-factor authentication is required. If so, it adds facial recognition.

[0033] The DID identity authentication steps specifically include: Extract the issuer's DID and signature from the verifiable credential VC. Unverified message Verify that the signature is correct; specifically: Recalculate the challenge hash , ; judge Whether or not If they are equal, the signature verification is correct; where .

[0034] If the signature verification is correct, the smart home platform parses the DID document based on the user's DID and obtains its public key and verification path. It then hashes the user's DID and calculates whether the obtained verification path is the same as the Merkle root hash stored in the blockchain beforehand (by calculating the hash value of each node on the path using a cryptographic hash algorithm until the root node is reached, and comparing the calculated value with the stored root hash value to see if it is the same). If they are the same, it proves that the user's verifiable credential VC is valid. Subsequently, the platform sends a verification success message back to the user's terminal to complete the user authentication.

[0035] Signature verification is essentially a mathematical equation verification. A signature is the result of encrypting a specific message using the issuer's private key, and the public key, corresponding to the private key, can decrypt that encrypted result. If the equation is true, it means that the result obtained by decrypting the signature with the public key matches the original message, indicating that the issuer indeed possesses the private key and the message has not been tampered with. If the equation is false, the signature is invalid, possibly due to forgery or data modification.

[0036] The steps involved in calling the strategy smart contract to verify whether two-factor authentication is required include: The platform will determine the security level of the device. The request is submitted to the smart contract, which then returns a response based on the device's security level, indicating whether facial recognition verification is required. The smart contract uses a pre-defined security level mapping relationship. Make the following decision:

[0037] Where 0 indicates that only single-factor authentication is required, and the signature verification process of the user's DID is completed; 1 indicates that two-factor authentication is required, and the user needs to perform facial recognition verification.

[0038] By dynamically invoking two-factor authentication, enhanced security for highly sensitive devices is ensured while avoiding unnecessary computational burden on low-sensitivity devices, effectively improving the user experience while guaranteeing privacy and security.

[0039] The facial recognition process includes face registration, feature extraction, and face matching. The specific steps are as follows: (1) such as Figure 5 As shown, the user registers their face locally using the system's built-in face recognition module. First, the forward face detector is initialized and the video stream from the local camera is activated. The system continuously captures image frames from the built-in camera and uses the forward face detector to extract candidate face bounding boxes. Let... Here is an RGB image acquired at time t, where W=640, H=480; a forward face detector based on Dlib HOG+SVM is used. right The calculation yields a set of rectangles, as shown in the formula below:

[0040] in, For a moment A collection of rectangles; This represents the number of faces detected in the current video frame. For the set of A rectangle, with the coordinates of its top-left vertex being... Width and height are .

[0041] To ensure the quality of subsequent templates, each captured frame... Apply single-face constraints and range constraints; only frames that simultaneously meet these conditions can proceed with subsequent operations. For The number of faces in the data ,like If the current frame contains only one face, proceed to the next step; otherwise, discard the frame immediately and display a red "MULTI-FACE" message on the user interface.

[0042] For single-face rectangles Apply spread factor The extended boundary is obtained and expressed by the following formula:

[0043] Only when the four expanded boundaries simultaneously satisfy... , , , When inRange is active, set the flag inRange=1; otherwise, set inRange=0. If inRange=0, the system marks the frame as "OUT OF RANGE" and displays a red box indicating this. Only when inRange=0... When both are established, the system will follow the expanded coordinates. Directly from the original frame Cut out the facial interest area The image was then compressed using a JPEG template and saved locally.

[0044] (2) Regions of interest for the entered and saved faces Feature extraction is performed.

[0045] First, load the JPEG template as an RGB array, represented by the following formula:

[0046] Face detection operator right The system calculates and confirms whether a face exists within the ROI. If the detection fails, the template is discarded; otherwise, a unique bounding box is obtained. Then, keypoint alignment is performed. Performing 68-point shape prediction yields the coordinates of 68 key points. It can be expressed by the following formula:

[0047] Solving the affine matrix from key points Subsequently Geometric normalization is performed to obtain the calibration image. The calculation is as follows:

[0048] The result Feed into ResNet-50 embedded network The output is a 128-dimensional unit vector. and Then, the mean of all valid vectors for the same user is calculated dimension by dimension to obtain a stable template, as shown in the following formula:

[0049] Finally, the username and feature template will be used. The record is saved to a local feature file and is called . This is for subsequent use. The above process can complete the feature generation of a single template within 0.05 seconds on the local terminal, providing a highly robust and discriminative numerical representation for face comparison during runtime.

[0050] (3) After the user completes face registration and saves the extracted features locally, subsequent face recognition matching can be performed. The face recognition module uses the "feature vector-Euclidean distance" strategy to complete identity determination, and the method includes the following: For users requiring verification, the user locally invokes the face recognition module, aligns the detected user face with 68 points, and inputs it into the ResNet-50 embedding network to obtain a unit vector of length 128. For each aggregation template in the database The Euclidean distance is calculated using the following formula:

[0051] Then take the minimum distance. , threshold The default value is 0.4. If the match is successful, the corresponding template is matched and the name is returned, indicating successful verification; otherwise, it is marked as "unknown," and verification fails, denying the user access to smart home devices. The entire matching process relies on only one forward feature extraction and one Euclidean distance comparison, requiring no additional classifier, thus being computationally lightweight while maintaining high discrimination accuracy.

[0052] The fifth step involves encrypting the access logs generated after a user accesses the device using Identity-Based Encryption (IBE). The algorithm consists of three steps: initialization, encryption, and decryption. The system first initializes and generates the common parameters required for pairing, as shown in Table 1.

[0053] System randomly selects As a generator, select The system master key msk is then used to calculate the public parameters. The system public key is shown in the following formula:

[0054] Regarding the user's identity Map it to a group The elements on and by the system master key Calculate this corresponding private key The details are as follows:

[0056] To perform the encryption operation, first select a random number. Then calculate the ciphertext component , compute shared secret Finally, the ciphertext component is calculated. Obtain the ciphertext The calculation is as follows:

[0058] The key to decryption lies in reconstructing the shared secret, which requires the corresponding user identity. Only then can decryption be successfully completed; the system reads the private key corresponding to the identity from the security module. And analyze the components in the ciphertext. The plaintext can be recovered by performing pairwise calculations on them. The specific calculations are as follows:

[0059] Identity-based encryption ensures that only those with the corresponding identity can access the system. Only authorized users can decrypt the access logs, fundamentally eliminating the risk of unauthorized access to the logs by service provider personnel.

[0060] Experiments were conducted to compare the time overhead of attribute-based encryption (ABE) with other methods, for example... Figure 7 As shown, identity-based encryption is simpler and lighter than attribute-based encryption. Its time overhead in the four stages of initialization, key generation, encryption and decryption is significantly better than that of attribute-based encryption. Attribute-based encryption must maintain an attribute set and policy tree. The ciphertext size increases linearly with the number of attributes. Offline devices have difficulty dynamically obtaining new attribute keys. Its deployment and computing costs are significantly higher than those of identity-based encryption. Therefore, identity-based encryption has more advantages in log encryption scenarios with high frequency, small data packets, sensitive edge resources and only occasional decryption.

[0061] This invention assigns decentralized identities to users and their devices, preventing smart home service providers from obtaining personal identities while providing verifiable and reliable identity credentials. This achieves decentralized and minimal disclosure of identity management, effectively preventing the association between user identity and behavioral data. For different security sensitivity levels of devices, a two-factor authentication mechanism is designed, dynamically invoked according to the level. In high-sensitivity device access scenarios, DID authentication and local facial recognition are combined to prevent credential abuse or impersonation, achieving a delicate balance between security and efficiency. Furthermore, this scheme employs an identity-based encryption mechanism to encrypt and store access logs, enabling fine-grained access control and preventing the reverse association between behavioral data and identity. This invention, while ensuring security, also considers efficiency, providing a feasible new method for smart home privacy protection.

[0062] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A multi-level dynamic smart home privacy authentication method based on verifiable credentials, characterized in that, include: Step S1: Receive the user's access request; wherein, the access request includes the user's DID and the verifiable credential VC, the user's DID is registered by the user through the DID generation tool provided by the identity provider, and the verifiable credential VC is bound to the user's DID and is issued by the user to the identity provider upon application; Step S2, perform DID authentication: Step S21: Extract the issuer's DID and signature from the verifiable credential VC. Unverified message Verify that the signature is correct; Step S22: If the signature verification is correct, parse the DID document based on the user's DID and obtain its public key and verification path. Hash the user's DID and calculate whether it is the same as the Merkle root hash stored in the blockchain in advance based on the obtained verification path. If they are the same, the user's identity authentication is successful.

2. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 1, characterized in that, Registering a user's DID based on the DID generation tool provided by the identity provider includes: The DID generation tool calls the secure cryptographic library Bouncy Castle to construct an Ed25519 elliptic curve environment and generate key pairs within a trusted execution environment.

3. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 2, characterized in that, The DID generation tool calls the secure cryptographic library Bouncy Castle to construct an Ed25519 elliptic curve environment, generating key pairs within a trusted execution environment, specifically including: Step A, the DID generation tool calls a true random number generator to generate a 32-byte seed, which is then subjected to SHA512 hashing and a clamp operation to obtain a private key that satisfies 0 < d < q , and the public key is obtained through point multiplication on the elliptic curve , and the public key calculation formula is as follows: Where G is a fixed base point on the curve, and q represents the order of the elliptic curve; Step B: The DID generation tool uses the SHA256 hash function to hash the public key. Perform a hash operation to obtain a 32-bit hash digest; Step C: Encode the hash digest using Base58 to obtain the DID string, which is represented as: Step D involves constructing a DID document containing a public key for verification, an optional server endpoint, and version information; the user then publishes the DID document, signed with their private key, to the immutable InterPlanetary File System, thus completing the user's DID registration.

4. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 1, characterized in that, The specific steps an identity provider takes to issue a verifiable credential (VC) bound to a user's DID include: After verifying the user's DID and authentication information submitted by the user, the identity provider issues a verifiable credential VC containing the DID identifier, user claim attributes, issuer information, and validity period, and then signs it with its private key before giving it to the user.

5. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 4, characterized in that, After verifying the user's DID and authentication information submitted by the user, the identity provider issues a verifiable credential (VC) containing the DID identifier, user claim attributes, issuer information, and validity period, and signs it with its private key before delivering it to the user; specifically including: Step a: After verifying the user's DID and authentication information submitted by the user, the identity provider generates the VC body content; wherein, the VC body content includes the issuer DID, holder DID, attribute assertion, issuance time, and expiration time; Step b: The identity provider standardizes the VC body content according to W3C specifications to obtain the data M to be signed; Step c, the identity provider generates a one-time random number using the Ed25519 algorithm. and Perform calculations to generate temporary curve points Then calculate the challenge hash. And through the issuer's private key Calculate response value Temporary curve point and response value Together they form a combined signature Combined signature As part of a verifiable document, it is used to verify the authenticity and validity of the verifiable document VC; the specific formula is: In the formula, q represents the order of the elliptic curve. This represents the issuer's public key.

6. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 5, characterized in that, Step S21 specifically includes: Recalculate the challenge hash , ; judge Whether or not If they are equal, the signature verification is correct; where .

7. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 1, characterized in that, The steps for storing the Merkle root hash on the blockchain are as follows: The identity provider hashes the DID identifiers of registered users and constructs a Merkle tree. The leaf nodes of the Merkle tree are the hash values ​​of each DID identifier; every two leaf nodes form the parent node of the Merkle tree; all parent nodes constitute the root node of the Merkle tree. Write the path from each user to the root node of the Merkle tree into the user's DID document, and finally save the root hash of the Merkle tree and the DID document index on the blockchain.

8. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 1, characterized in that, The access request in step S1 also includes the security level of the smart home device. Step S2 also includes adding a face recognition step if the security level exceeds the threshold.

9. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 8, characterized in that, The specific steps of facial recognition include: Facial feature points are obtained from the detected face using the 68-point Landmark predictor in the Dlib library; the obtained facial feature points are then fed into the ResNet-50 face recognition model in the Dlib library to output a 128-dimensional face feature vector. The Euclidean distance is used to compare the output 128-dimensional vector with the stored known face vectors.

10. The multi-level dynamic smart home privacy authentication method based on verifiable credentials according to claim 1, characterized in that, The method also includes: Step S3: Access logs generated by users accessing smart home devices are encrypted and stored using an IBE algorithm based on bilinear pairing.

Images