CN108449178B - Method for generating root key in secure trusted execution environment - Google Patents
Method for generating root key in secure trusted execution environment Download PDFInfo
- Publication number
- CN108449178B CN108449178B CN201810250833.1A CN201810250833A CN108449178B CN 108449178 B CN108449178 B CN 108449178B CN 201810250833 A CN201810250833 A CN 201810250833A CN 108449178 B CN108449178 B CN 108449178B
- Authority
- CN
- China
- Prior art keywords
- salt
- root key
- userrootkey
- execution environment
- password
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 150000003839 salts Chemical class 0.000 claims abstract description 26
- 238000005516 engineering process Methods 0.000 claims abstract description 6
- 238000009795 derivation Methods 0.000 abstract description 5
- 230000009286 beneficial effect Effects 0.000 abstract description 2
- 238000013175 transesophageal echocardiography Methods 0.000 description 25
- 238000004422 calculation algorithm Methods 0.000 description 11
- 238000012795 verification Methods 0.000 description 4
- 238000005336 cracking Methods 0.000 description 3
- XKRFYHLGVUSROY-UHFFFAOYSA-N Argon Chemical compound [Ar] XKRFYHLGVUSROY-UHFFFAOYSA-N 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 229910052786 argon Inorganic materials 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
The invention discloses a method for generating a root key in a secure trusted execution environment, which comprises the following steps: s1, calculating Key1= PBKDF2(Password, Salt, it), where Password is a Password input by a user, a random number is generated inside the Salt trusted execution environment TEE, and it is an iteration number; s2, calculating a root Key UserRootKey = Argon2(Key1, HWUID, Salt, SecretFactor, it, M), wherein M is a memory occupation value, SecretFactor is a confidentiality factor which is built in a TEE operating system and protected by obfuscation technology, and HWUID is a hardware unique identification number; s3, compute Key3= Argon2(UserRootKey, Salt, it, M); s4, generating a data encryption key DEK and a CCM-mode random number Nonce by a random number generator, and calculating EDEK = AES-CCM (UserRootKey, DEK, Nonce). The invention has the beneficial effects that: by adding the user PIN as another input factor for root key derivation, the security and reliability of the root key is enhanced.
Description
Technical Field
The invention relates to the field of information security, in particular to a method for generating a root key in a secure trusted execution environment.
Background
Secure Element (Secure Element) SE, commonly provided in chip form. In order to prevent external malicious analysis attack and protect data security, an encryption/decryption logic circuit is arranged in a chip.
TEE is an acronym for trusted execution environment. The current trusted execution environment is mainly a trusted execution environment built based on a secure area of a processor in a smart terminal (such as a smart phone). The TEE is an independent execution area that provides many security attributes such as isolation, integrity of the TA, etc., while the TEE also ensures the security of the code and data loaded into the TEE. Conventional TEE technologies include ARM TrustZone, and the like. The GP organization (GlobalPlatform, international standards organization for global platform) promulgates the basic scope of protection, associated APIs and security attributes of TEE, a TEE that meets this standard is called GPTEE. And other TEEs, such as N3TEE, etc.
The security system mostly adopts a multi-level key system. In the system, the security of a lower-level key is protected by an upper-level key, and a root key is the source of the key system, so that the root key security is the basis and guarantee of the key system security, and once the root key is leaked, a great loss is brought to a user.
The security level of the TEE is between ree (rich Execution environment) and se (secure element). Since the security level of TEE is lower than SE, there is no SE, and there is no physically fully isolated secure area to hold the user's keys. Most of the existing TEE schemes are based on that a CPU chip obtains a Unique HUK (Hardware Unique Key), and then derives other function keys from the HUK. Chip manufacturers may provide a strict way of managing to protect the HUK. However, the HUK may be obtained by at least three parties: CPU manufacturers (e.g., distribution branch office), end-device OEMs, TEE providers. And in three parties, especially OEM manufacturers are more and have different technical capabilities, which greatly increases the risk of HUK leakage.
CCM is known as Counter mode with CBC-MAC, and CBC-MAC is known as Cipher Block Chain-Message Authentication Code mode, it being understood that CCM is a combination of Cipher Block Chain Message Authentication Code (CBC-MAC) and Counter mode (CTR).
TUI (trusted User interface) represents a trusted User interface;
HWUID (hardware unique ID) hardware unique identification number.
An effective solution to the problems in the related art has not been proposed yet.
Disclosure of Invention
In view of the above technical problems in the related art, the present invention provides a method for generating a root key in a secure trusted execution environment, which can enhance the security of the root key.
In order to achieve the technical purpose, the technical scheme of the invention is realized as follows:
a method of generating a root key in a secure trusted execution environment, comprising the steps of:
s1 calculates Key1= PBKDF2(Password, Salt, it), where Password is a Password input by a user, a random number is generated inside the Salt trusted execution environment TEE, and it is an iteration number;
s2, calculating a root Key UserRootKey = Argon2(Key1, HWUID, Salt, SecretFactor, it, M), wherein M is a memory occupation value, SecretFactor is a confidentiality factor which is built in a TEE operating system and protected by obfuscation technology, and HWUID is a hardware unique identification number;
s3 calculates Key3= Argon2(UserRootKey, Salt, it, M);
s4 calculates EDEK = AES-CCM (UserRootKey, DEK, Nonce) by generating a data encryption key DEK and a random number Nonce of CCM mode by a random number generator.
Preferably, the method further comprises: s5 saves Salt, EDEK, Nonce, Key3 to memory.
Preferably, the iteration time it is selected according to a hardware platform, and is based on the maximum time consumption accepted by a user.
Preferably, the memory occupation value M is selected according to a hardware condition.
The invention has the beneficial effects that: by adding the user PIN as another input factor for root key derivation, the security and reliability of the root key is enhanced.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
Fig. 1 is a schematic diagram of data flow of a method for generating a root key in a secure trusted execution environment according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of the present invention.
As shown in fig. 1, a method for generating a root key in a secure trusted execution environment according to an embodiment of the present invention includes the following steps:
s1 calculates Key1= PBKDF2(Password, Salt, it), where Password is a Password input by a user, a random number is generated inside the Salt trusted execution environment TEE, and it is an iteration number;
s2, calculating a root Key UserRootKey = Argon2(Key1, HWUID, Salt, SecretFactor, it, M), wherein M is a memory occupation value, SecretFactor is a confidentiality factor which is built in a TEE operating system and protected by obfuscation technology, and HWUID is a hardware unique identification number;
s3 calculates Key3= Argon2(UserRootKey, Salt, it, M);
s4 calculates EDEK = AES-CCM (UserRootKey, DEK, Nonce) by generating a data encryption key DEK and a random number Nonce of CCM mode by a random number generator.
Preferably, the method further comprises: s5 saves Salt, EDEK, Nonce, Key3 to memory.
Preferably, the iteration time it is selected according to a hardware platform, and is based on the maximum time consumption accepted by a user.
Preferably, the memory occupation value M is selected according to a hardware condition.
In order to facilitate understanding of the above-described technical aspects of the present invention, the above-described technical aspects of the present invention will be described in detail below in terms of specific usage.
In specific use, the method for generating the root key in the secure trusted execution environment according to the present invention specifically includes the following steps:
1) inputting a Password by a user on a TUI interface, wherein the TUI is a trusted interface of the TEE world;
2) TEE internally generates a random number Salt which participates in operation in the process of key derivation (pbkdf 2 and argon 22 algorithms) and is used for preventing attack of a pre-built rainbow table;
3) calculating Key1= PBKDF2(Password, Salt, it), wherein the iteration number it is selected according to a hardware platform, and the maximum time consumption which can be accepted by a user is taken as the standard;
4) calculating UserRootKey = Argon2(Key1, HWUID, Salt, SecretFactor, it, M), iteration times it is as above, and memory occupation value M is according to hardware condition, such as 64 MByte. The SecretFactor is a confidentiality factor which is built in TEEOS and protected by an obfuscation technology;
5) compute Key3= Argon2(UserRootKey, Salt, it, M), Key3 will be saved for verification of user input password. That is, the key3 should be checked for correctness when the key is used;
6) generating a data encryption key DEK and a random number Nonce of a CCM mode, the Nonce being used for distinguishing key streams of different stream ciphers;
7) calculating EDEK = AES-CCM (UserRootKey, DEK, Nonce) for decrypting a data encryption key DEK from EDEK after next startup;
8) save Salt, EDEK, Nonce, Key 3.
After the root key and the related data are generated according to the steps, when the equipment is used after being restarted, the verification of the user input password and the acquisition of the key are carried out according to the following steps:
a) reading salt from the storage area, calculating to obtain a key3 (shown in FIG. 1), and comparing the key3 with the key3 read from the storage area to determine the validity of the input password;
b) computing UserRootKey
c) Reading EDEK and Nonce
d) Calculate DEK = AES-CCM (EDEK, UserRootKey, Nonce)
f) The DEK is a key used for encrypting the service data, and the specific encrypted data and the encryption algorithm are different in practice.
The following is the mode of resisting the scheme in dealing with the potential threat:
1. risk of UserRootKey leakage intentionally or unintentionally by CPU vendors: CPU manufacturers can only obtain HUKs without users PASSWORD and SecretFactor, and to obtain UserRootKey, the CPU manufacturers must attack to obtain PASSWORD.
2. Risk of UserRootKey leakage due to OEM internal mismanagement: the OEM has the root private key of the ROT, can sign out own codes, and therefore can easily obtain the HUK. There is no PASSWORD and SecretFactor, so to get UserRootKey, we have to attack to get PASSWORD.
3. Risk of UserRootKey leakage due to internal mismanagement of TEE OS: TEE OS, as a software project provider for REE, also readily available HUK and mastered SecretFactor. But as in the above 2, but to obtain the UserRootKey, we have to attack to obtain PASSWORD.
4. Attack risk from REE OS: the scheme requires that the PASSWORD must be input through TUI before the safe starting stage, namely REE starting, and the PASSWORD and the derived UserRootKey thereof are ensured to be only present in the TEE. Thus, REEs cannot obtain these data.
5. Attacks against PASSSWORD
a) Monitoring, keyboard recording
i) PASSWORD does not output TEE and is resistant to snooping and keylogging attacks from REE and the web.
b) Brute force cracking
ii) brute force cracking is to use the quick capability of the computer, exhaust the password space and guess one by one. The scheme adopts a method of combining PBKDF2 and Argon2 to derive UserRootKey. One of the parameters of these 2 is the number of iterations, which can be adjusted to increase the computational complexity of the algorithm, and each round of guessing is very slow. If the user can accept login verification in 1 second, the password space has 10^6 passwords for a 6-bit PIN code, and if the lower case letters are added, the password space has (10+24) ^6 passwords. Then a complete search for a 6-bit PIN code would take 10^6 seconds, about 1000000/3600/24=11 days. Then for the case where lower case letters are added, about (10+24) ^6/3600/24=17879 days. It is more effective if the password length is increased. The scheme provides an adjustable security level for a terminal user, and the adjustment parameters comprise password length and calculation amount duration.
c) Attack on rainbow table
iii) the rainbow table attack can greatly improve the speed of brute force cracking by using a pre-calculation and storage method. In the scheme, both the PBKDF2 algorithm and the Argon2 algorithm have a salt parameter which is a random number, so that an attacker can be prevented from constructing a rainbow table.
Meanwhile, the GPU or the FPGA is accelerated, hardware acceleration is not a factor of increasing the main frequency of the general CPU by several times, any factor is possible as long as hardware resources are enough, and the Argon2 adopted by the scheme has the characteristics of anti-parallel computation and high memory consumption. Therefore, if 1G memory is used for each operation, 1T of RAM is required for 1000 parallel paths, and the attack cost is increased sharply.
In addition, since the Argon2 is an algorithm generated only in 2015, the reliability of the algorithm needs to be further checked, so that the key is derived by connecting the PBKDF2 and the Argon2 in series, and the advantages of a new algorithm and the reliability of an old algorithm can be used as a basis for ensuring.
6. Risk of attack against SecretFactor: and reversing the mirror image of the TEE to obtain the secret factor SecretFactor. The confidentiality of this factor depends on the following software protection techniques: 1) performing inverse debugging; 2) carrying out mirror image encryption; 3) logic obfuscation; 4) constant encryption scatter 5) caller verification 6) strip 7) code logical association binding. The difficulty of obtaining useful data by an attacker is greatly improved by utilizing the measures.
7 other attacks: obtaining equipment, and reading out UserRootKey from the equipment
When an attacker obtains a device, the common method:
a) if the mobile phone does not have a password or a fingerprint screen locking function, an attacker directly starts the mobile phone to read data, and the data is stored in a safe storage area in the TEE, and the TA cannot provide the data to the CA, so that the attacker cannot obtain confidential data.
b) If the mobile phone is provided with the screen unlocking lock, the assumption is that an attacker cannot unlock the screen. At this time, UserRootKey is in the RAM of TEE, and an attacker tries to read the method of the RAM. And normally, the dynamic debugging interface of the equipment is closed before the equipment leaves a factory, and the software layer also has forbidden detection. The ADB method can only go to REE if it can link, and the following problem is the same as mentioned in a).
c) Device shutdown
i) The attacker directly reads the NVM, can obtain the ciphertext data of the user, and can obtain the image data of the OS and the TA
ii) assuming that attackers obtain key derivation algorithms of different levels by reversing or referring to some public data, and file encryption algorithm
iii) the problem then moves to obtaining the root key if the attacker can get PASSWORD.
In summary, by means of the above technical solution of the present invention, the security and reliability of the root key are greatly enhanced by adding the user PIN as another input factor for root key derivation.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (4)
1. A method for generating a root key in a secure trusted execution environment, comprising the steps of:
s1 calculates Key1 ═ PBKDF2(Password, Salt, it), where Password is a Password input by a user, Salt is a random number generated inside the trusted execution environment TEE, and it is an iteration number;
s2, calculating a root Key UserRootKey which is Argon2(Key1, HWUID, Salt, SecretFactor, it and M), wherein M is a memory occupation value, SecretFactor is a confidentiality factor which is arranged in a TEE operating system and protected by an obfuscation technology, and HWUID is a hardware unique identification number;
s3 calculates Key3 ═ Argon2(UserRootKey, Salt, it, M);
s4 generates a data encryption key DEK and a random number Nonce in CCM mode by a random number generator, and calculates EDEK ═ AES-CCM (UserRootKey, DEK, Nonce).
2. A method for generating a root key in a secure trusted execution environment as claimed in claim 1, further comprising: s5 saves Salt, EDEK, Nonce, Key3 to memory.
3. The method for generating a root key in a secure trusted execution environment according to claim 1, wherein the number of iterations it is selected according to a hardware platform, based on a maximum time duration that can be accepted by a user.
4. The method of claim 1, wherein the memory footprint value M is selected according to hardware conditions.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810250833.1A CN108449178B (en) | 2018-03-26 | 2018-03-26 | Method for generating root key in secure trusted execution environment |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810250833.1A CN108449178B (en) | 2018-03-26 | 2018-03-26 | Method for generating root key in secure trusted execution environment |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108449178A CN108449178A (en) | 2018-08-24 |
CN108449178B true CN108449178B (en) | 2020-12-22 |
Family
ID=63196585
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810250833.1A Active CN108449178B (en) | 2018-03-26 | 2018-03-26 | Method for generating root key in secure trusted execution environment |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108449178B (en) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109981285B (en) * | 2019-03-11 | 2020-10-09 | 北京纬百科技有限公司 | Password protection method, password verification method and system |
CN109976948B (en) * | 2019-03-18 | 2021-04-30 | 北京思源理想控股集团有限公司 | Private information backup method and recovery method and system |
KR102263325B1 (en) | 2019-04-26 | 2021-06-15 | 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. | How to securely execute smart contract actions in a trusted execution environment |
US11240026B2 (en) | 2019-05-16 | 2022-02-01 | Blackberry Limited | Devices and methods of managing data |
CN110932853B (en) * | 2019-12-06 | 2022-12-06 | 深圳市纽创信安科技开发有限公司 | Key management device and key management method based on trusted module |
CN111008390A (en) * | 2019-12-13 | 2020-04-14 | 江苏芯盛智能科技有限公司 | Root key generation protection method and device, solid state disk and storage medium |
CN113098679A (en) * | 2020-01-09 | 2021-07-09 | 杭州海康威视数字技术股份有限公司 | Root key generation method and device and electronic equipment |
CN114745112A (en) * | 2022-04-15 | 2022-07-12 | 北京凝思软件股份有限公司 | Root key derivation method and device, electronic equipment and storage medium |
CN114867012A (en) * | 2022-05-30 | 2022-08-05 | 北京启星微电子有限公司 | Encryption earphone and voice communication method thereof |
CN115174125A (en) * | 2022-09-07 | 2022-10-11 | 北京笔新互联网科技有限公司 | Method and device for acquiring trusted true random number in trusted execution environment |
CN117134914B (en) * | 2023-10-26 | 2024-01-30 | 山东山大鸥玛软件股份有限公司 | One-time-pad random key stream encryption algorithm and system based on hardware characteristics |
CN118821104A (en) * | 2024-09-13 | 2024-10-22 | 深圳市洞见智慧科技有限公司 | Data authorization management method and related equipment applied to trusted data space |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102271037A (en) * | 2010-06-03 | 2011-12-07 | 微软公司 | Key protectors based on online keys |
CN102724215A (en) * | 2012-07-07 | 2012-10-10 | 成都国腾实业集团有限公司 | Method for storing user key safely and improving data security of cloud platform based on user login password |
CN104579644A (en) * | 2015-01-12 | 2015-04-29 | 浪潮软件集团有限公司 | Key generation and recovery method |
CN105027494A (en) * | 2013-03-14 | 2015-11-04 | 英特尔公司 | Trusted data processing in the public cloud |
CN107147495A (en) * | 2017-05-25 | 2017-09-08 | 广东工业大学 | Implementation of SM2 Encryption Algorithm on Binary Extended Domain |
DE102017121497A1 (en) * | 2017-09-15 | 2019-03-21 | genua GmbH | NETWORK TERMINATION FOR MANAGING A PASSWORD FROM A USER |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7934096B2 (en) * | 2007-07-27 | 2011-04-26 | Microsoft Corporation | Integrity protected smart card transaction |
-
2018
- 2018-03-26 CN CN201810250833.1A patent/CN108449178B/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102271037A (en) * | 2010-06-03 | 2011-12-07 | 微软公司 | Key protectors based on online keys |
CN102724215A (en) * | 2012-07-07 | 2012-10-10 | 成都国腾实业集团有限公司 | Method for storing user key safely and improving data security of cloud platform based on user login password |
CN105027494A (en) * | 2013-03-14 | 2015-11-04 | 英特尔公司 | Trusted data processing in the public cloud |
CN104579644A (en) * | 2015-01-12 | 2015-04-29 | 浪潮软件集团有限公司 | Key generation and recovery method |
CN107147495A (en) * | 2017-05-25 | 2017-09-08 | 广东工业大学 | Implementation of SM2 Encryption Algorithm on Binary Extended Domain |
DE102017121497A1 (en) * | 2017-09-15 | 2019-03-21 | genua GmbH | NETWORK TERMINATION FOR MANAGING A PASSWORD FROM A USER |
Non-Patent Citations (2)
Title |
---|
Argon2: New Generation of Memory-Hard Functions for Password Hashing and Other Applications;Alex Biryukov;《IEEE》;20160324;全文 * |
PBKDF2函数的一种快速实现;于飞;《信息安全与通信保密》;20131215(第12期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN108449178A (en) | 2018-08-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108449178B (en) | Method for generating root key in secure trusted execution environment | |
Bhatia et al. | Data security in mobile cloud computing paradigm: a survey, taxonomy and open research issues | |
RU2445689C2 (en) | Method to increase limitation of access to software | |
US20050283826A1 (en) | Systems and methods for performing secure communications between an authorized computing platform and a hardware component | |
US9270655B1 (en) | Configurable one-time authentication tokens with improved resilience to attacks | |
US20050235148A1 (en) | Access system utilizing multiple factor identification and authentication | |
WO2003065169A2 (en) | Access system utilizing multiple factor identification and authentication | |
US12177355B2 (en) | Methods and devices for secure application authentication using a one-way encrypted authentication token | |
CN109302442B (en) | Data storage proving method and related equipment | |
Johnston et al. | Recommendations for securing Internet of Things devices using commodity hardware | |
Das | A secure and robust password-based remote user authentication scheme using smart cards for the integrated epr information system | |
Shirvanian et al. | Building and studying a password store that perfectly hides passwords from itself | |
US20250148073A1 (en) | Systems and methods for managing state | |
Murtaza et al. | A portable hardware security module and cryptographic key generator | |
Guo et al. | PUFPass: A password management mechanism based on software/hardware codesign | |
Wee et al. | Excavating vulnerabilities lurking in multi-factor authentication protocols: A systematic security analysis | |
Mahnamfar et al. | ROSTAM: A passwordless web single sign-on solution mitigating server breaches and integrating credential manager and federated identity systems | |
Hugenroth et al. | Sloth: Key Stretching and Deniable Encryption using Secure Elements on Smartphones | |
CN116992494A (en) | Security protection method, equipment and medium for scenic spot data circulation | |
Kim et al. | Secure IoT Device Authentication Scheme using Key Hiding Technology | |
Pham et al. | Novel PUF-Based Authentication Protocol for IoT Devices with Secure Boot and Fuzzy Matching | |
WO2022223136A1 (en) | Method and communication system for supporting key recovery for a user | |
CN114637995A (en) | Method and system with multiple heterogeneous TEE implementations | |
Sudha et al. | A survey on different authentication schemes in cloud computing environment | |
CN114866228A (en) | Method, system, storage medium and terminal for realizing soft password module |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |