A key schedule method and system based on a secure instruction set

Abstract

The application relates to the field of hardware security and key management, and specifically discloses a key scheduling method and system based on a security instruction set, which comprises the following steps: S1, receiving a key operation request, and calling an identity-scene-permission ternary verification instruction to verify the legality of the request; S2, if the verification is passed, based on a preset general security instruction subset, dynamically calling corresponding key generation, distribution or update instructions according to current business requirements to complete corresponding operations of the key; S3, in the key operation process, synchronously executing a timing randomization instruction and a power consumption balancing instruction to protect the key operation process; and S4, after the key is used up, triggering a hardware-level destruction instruction to clear all copies of the key in the memory, the cache and the non-volatile storage medium. The application realizes the whole life cycle management and control of the key through instruction level optimization, takes into account the cross-architecture adaptability and security, and is suitable for high-security requirement scenes.

Description

Technical Field

[0001] This invention relates to the field of hardware security and key management, specifically a key scheduling method based on a secure instruction set. Background Technology

[0002] In recent years, with the continuous upgrading of data security demands in fields such as financial payments, cloud computing, the Internet of Things, and government and military industries, key scheduling technology based on secure instruction sets has become a core solution for key lifecycle management due to its hardware-level protection advantages. Currently, the mainstream technical approaches mainly include four categories: general-purpose CPU secure extension instructions, dedicated secure chip instructions, static pre-configuration, and dynamic on-demand scheduling. All of these rely on "software-hardware collaboration" as their core to achieve key generation, storage, and retrieval.

[0003] However, in actual deployment and application, existing technologies have revealed many shortcomings that urgently need to be addressed: First, the fragmentation of instruction sets is prominent. Security instruction architectures from different vendors are incompatible, and there is a lack of unified standards for dedicated security chip instructions. This makes it difficult to port scheduling schemes developed based on a particular architecture across platforms, significantly increasing the development cost and time required for multi-device adaptation. Second, the permission verification mechanism has vulnerabilities. Most solutions only verify the caller's identity or the instruction execution result from a single dimension, failing to link the security level of the business scenario, the preset permissions of the key, and the caller's identity for verification. This easily leads to security risks such as unauthorized calls and replay attacks. Third, the ability to resist side-channel attacks is weak. Timing and power issues generated during key operations can cause problems. The physical characteristics such as power consumption and electromagnetic radiation are not effectively concealed. Attackers can reverse-engineer key information through timing analysis, power consumption analysis, and other means, resulting in data leakage. Fourth, the key lifecycle management is incomplete. Existing solutions focus on key generation and distribution, while the destruction process relies heavily on software logic. Only key copies in memory are cleared, which cannot completely eliminate key residues in hardware caches and non-volatile storage, posing a long-term risk of leakage. Fifth, it is difficult to balance security and scheduling efficiency. The execution of security instructions requires multiple context switches between ordinary execution environments and trusted execution environments. Dynamic key scheduling has high latency, and the consumption of hardware resources by multiple verification instructions makes it difficult to meet the real-time requirements of high-concurrency scenarios such as cloud computing.

[0004] In summary, existing key scheduling technologies based on secure instruction sets have significant shortcomings in cross-architecture compatibility, rigorous permission verification, anti-attack capabilities, full lifecycle management, and the balance between security and efficiency. There is an urgent need for a key scheduling method and system based on secure instruction sets that can balance cross-architecture adaptability, hardware-level full lifecycle management, and resistance to side-channel attacks, while effectively balancing security performance and scheduling efficiency, and adapting to high security requirements in multiple scenarios. Summary of the Invention

[0005] To address the aforementioned problems in the prior art, this invention provides a key scheduling method and system based on a secure instruction set, effectively solving the problems of poor compatibility and low security in traditional methods, and significantly improving key management efficiency.

[0006] To achieve the above objectives, this invention proposes a key scheduling method based on a secure instruction set, comprising: S1. Receive key operation request and call the identity-scenario-permission ternary verification instruction to verify the legality of the request; S2. If the verification is successful, based on the preset subset of general security instructions, the corresponding key generation, distribution or update instructions are dynamically invoked according to the current business needs to complete the corresponding key operation. S3. During the key operation process, timing randomization instructions and power balancing instructions are executed synchronously to protect the key operation process. S4. After the key is no longer needed, a hardware-level destruction instruction is triggered to clear all copies of the key in memory, cache, and non-volatile storage media.

[0007] Preferably, in S1, the verification process of the identity-scenario-permission ternary verification instruction includes: S11. Extract the caller's identity information, current business scenario identifier, and key permission level requested from the key operation request; S12. Verify the legitimacy of the caller's identity information through the identity verification sub-instruction, and confirm the security level corresponding to the business scenario identifier through the scenario identification sub-instruction; S13. Determine whether the key permission level matches the security level of the business scenario. If the identity is legitimate and the level matches, the request is deemed legitimate; otherwise, the key operation is rejected.

[0008] Preferably, in S1, the key is dynamically bound to the current business scenario identifier via the BindKeyScene command. The binding relationship is automatically released when the key is no longer in use. The binding formula is as follows: ; In the formula, The key to be bound. For business scenario identification, To bind the valid duration, For the preset hash function, This is an XOR operation.

[0009] Preferably, in S2, the subset of general security instructions includes key generation sub-instructions, key distribution sub-instructions, key update sub-instructions, key status monitoring sub-instructions, and key destruction sub-instructions. The conversion formula between proprietary security instructions and the subset of general security instructions is as follows: ; In the formula, These are the converted general security instructions. These are original proprietary security instructions. For hardware architecture type, This is a cross-architecture transformation function.

[0010] Preferably, in S3, the implementation process of the timing randomization instruction includes: A pseudo-random clock cycle offset is generated using a linear feedback shift register. Adjust the execution clock cycle of the key operation instructions to the base cycle. The calculation formula is: ; ; In the formula, This is the adjusted actual execution period. As the base period, This is the pseudo-random clock cycle offset. For the minimum offset, This is the maximum offset.

[0011] Preferably, in S3, the power balancing instruction is implemented by dynamically adjusting the operating voltage of the hardware processing unit, with the voltage adjustment range being... The calculation formula is: ; In the formula, The reference operating voltage, To adjust the coefficient, for Random numbers within the interval.

[0012] Preferably, in S4, the hardware-level destruction instruction is the HardwareDestroyKey instruction. When this instruction is executed, it sequentially clears the plaintext copy of the key in memory, the key fragments in the cache, and the key backup in non-volatile storage. After clearing is completed, a destruction confirmation signal is generated.

[0013] A key scheduling system based on a secure instruction set includes: The instruction verification module is used to execute identity-scenario-permission ternary verification instructions and scenario binding instructions to verify the legality of key operation requests; A cross-architecture adaptation module is used to store a subset of general security instructions and to convert between proprietary security instructions and the subset of general security instructions. The full lifecycle management module is used to execute key generation, distribution, update, status monitoring, and hardware-level destruction instructions; The anti-side-channel module is used to execute timing randomization instructions and power balancing instructions to protect the key operation process from side-channel attacks.

[0014] Preferably, the full lifecycle management module also includes a key status monitoring unit, which is used to collect the key's storage location, usage count, and call records in real time via the MonitorKeyState command. The monitoring formula is as follows: ; In the formula, This is the current storage location of the key. The cumulative number of times the key is used. A set of key call records.

[0015] Preferably, the cross-architecture adaptation module is compatible with proprietary security instructions of Intel SGX, ARM TrustZone and TPM 2.0 architectures. During the conversion process, the core operation logic of the proprietary instructions is preserved, and only the instruction format and parameters are adapted and adjusted.

[0016] Therefore, this invention proposes a key scheduling method and system based on a secure instruction set, the advantages of which are as follows: (1) Construct a three-element verification mechanism of identity-scenario-permission, and combine it with hardware-level key destruction instructions to realize the full life cycle security management of keys, eliminate the risk of unauthorized calls and key leakage, and improve the overall security of the system.

[0017] (2) Design a subset of general security instructions and a cross-architecture adaptation layer to be compatible with hardware architectures from multiple vendors and reduce cross-platform adaptation costs; enhance the ability to resist side-channel attacks through timing randomization and power consumption balancing instructions, while balancing security and scheduling efficiency.

[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0019] Figure 1 This is an overall structural diagram of a key scheduling method and system based on a secure instruction set according to the present invention; Figure 2 This is a flowchart of the steps of a key scheduling method based on a secure instruction set according to the present invention; Figure 3 This is a block diagram of a ternary verification logic for a key scheduling system based on a security instruction set, according to the present invention. Detailed Implementation

[0020] To make the technical solutions, advantages, and objectives of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below. The described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the protection scope of this application.

[0021] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0022] like Figures 1-3 As shown, the present invention provides a key scheduling method based on a secure instruction set, comprising: S1. Receive key operation request and call the identity-scenario-permission ternary verification instruction to verify the legality of the request; In S1, the verification process of the identity-scenario-permission ternary verification command includes: S11. Extract the caller's identity information, current business scenario identifier, and key permission level requested from the key operation request; S12. Verify the legitimacy of the caller's identity information through the identity verification sub-instruction, and confirm the security level corresponding to the business scenario identifier through the scenario identification sub-instruction; S13. Determine whether the key permission level matches the security level of the business scenario. If the identity is legitimate and the level matches, the request is deemed legitimate; otherwise, the key operation is rejected.

[0023] In S1, the key is dynamically bound to the current business scenario identifier via the BindKeyScene command. The binding relationship is automatically released when the key is no longer in use. The binding formula is as follows: ; In the formula, The key to be bound. For business scenario identification, To bind the valid duration, For the preset hash function, This is an XOR operation.

[0024] S2. If the verification is successful, based on the preset subset of general security instructions, the corresponding key generation, distribution or update instructions are dynamically invoked according to the current business needs to complete the corresponding key operation. The general security instruction subset includes key generation sub-instructions, key distribution sub-instructions, key update sub-instructions, key status monitoring sub-instructions, and key destruction sub-instructions. The conversion formula between proprietary security instructions and the general security instruction subset is as follows: ; In the formula, These are the converted general security instructions. These are original proprietary security instructions. For hardware architecture type, This is a cross-architecture transformation function.

[0025] S3. During the key operation process, timing randomization instructions and power balancing instructions are executed synchronously to protect the key operation process. The implementation process of timing randomization instructions includes: A pseudo-random clock cycle offset is generated using a linear feedback shift register. Adjust the execution clock cycle of the key operation instructions to the base cycle. The calculation formula is: ; ; In the formula, This is the adjusted actual execution period. As the base period, This is the pseudo-random clock cycle offset. For the minimum offset, This is the maximum offset.

[0026] Power balancing instructions are implemented by dynamically adjusting the operating voltage of the hardware processing unit, with the voltage adjustment range being... The calculation formula is: ; In the formula, The reference operating voltage, To adjust the coefficient, for Random numbers within the interval.

[0027] S4. After the key is no longer needed, a hardware-level destruction instruction is triggered to clear all copies of the key in memory, cache, and non-volatile storage media.

[0028] The hardware-level destruction instruction is the HardwareDestroyKey instruction. When this instruction is executed, it sequentially clears the plaintext copy of the key in memory, the key fragments in the cache, and the key backup in non-volatile storage. After clearing is completed, a destruction confirmation signal is generated.

[0029] This invention also proposes a key scheduling system based on a secure instruction set, comprising: The instruction verification module is used to execute identity-scenario-permission ternary verification instructions and scenario binding instructions to verify the legality of key operation requests; A cross-architecture adaptation module is used to store a subset of general security instructions and to convert between proprietary security instructions and the subset of general security instructions. The full lifecycle management module is used to execute key generation, distribution, update, status monitoring, and hardware-level destruction instructions; The anti-side-channel module is used to execute timing randomization instructions and power balancing instructions to protect the key operation process from side-channel attacks.

[0030] The full lifecycle management module also includes a key status monitoring unit, which uses the MonitorKeyState command to collect the key's storage location, usage count, and call records in real time. The monitoring formula is as follows: ; In the formula, This is the current storage location of the key. The cumulative number of times the key is used. A set of key call records.

[0031] The cross-architecture adaptation module is compatible with proprietary security instructions of Intel SGX, ARM TrustZone and TPM 2.0 architectures. During the conversion process, the core operation logic of the proprietary instructions is preserved, and only the instruction format and parameters are adapted and adjusted.

[0032] This invention uses a scenario of encrypted financial data transmission in a cloud computing environment as the verification object. This scenario involves server hardware from multiple vendors (including Intel SGX, ARM TrustZone architecture servers, and TPM 2.0 security modules), and needs to meet the requirements of high-frequency key generation, secure cross-device distribution, real-time updates, and high resistance to attacks. It is suitable for verifying the effectiveness of the method and system of this invention. The specific implementation process is as follows: Environment Deployment: Deploy the key scheduling system of this invention in a hybrid architecture server cluster. The cross-architecture adaptation module preloads a subset of general security instructions to complete the adaptation and conversion between proprietary security instructions of Intel SGX, ARM TrustZone and TPM 2.0 and general instructions, ensuring the consistency of instruction calls for devices with different architectures. The instruction verification module records the identity information of legitimate callers, the security level mapping table for financial scenarios and key permission classification rules.

[0033] Key operation request initiation: The financial business system initiates a key generation request, which carries the caller's identity identifier, the financial data encryption transmission scenario identifier, and the first-level key permission application.

[0034] Three-factor authentication and scenario binding: The instruction verification module calls the identity-scenario-permission three-factor authentication instruction to extract the identity, scenario, and permission information from the request. It verifies the caller's legitimacy through the identity verification sub-instruction and confirms the corresponding level 2 security level of the financial scenario through the scenario identification sub-instruction. It determines that the level 1 key permission matches the level 2 scenario security level and judges the request as legitimate. At the same time, it executes the BindKeyScene instruction to dynamically bind the key to be generated with the scenario identifier and 24-hour validity period according to the formula. The binding relationship is automatically released when the key is no longer in use.

[0035] Key generation and distribution: The cross-architecture adaptation module calls the corresponding general key generation sub-instruction according to the current server hardware architecture to generate an asymmetric key that conforms to financial encryption standards; based on business needs, it dynamically calls the key distribution sub-instruction to distribute the key to authorized devices in the cluster through an encrypted channel. During the distribution process, cross-architecture conversion functions are used to ensure that devices with different architectures can correctly parse the key data.

[0036] Protection during computation: While the key is used for financial data encryption computation, the anti-side-channel module synchronously executes timing randomization instructions and power balancing instructions. The timing randomization instruction generates a pseudo-random offset of 5-15 clock cycles through a linear feedback shift register, adjusting the execution cycle of the computation instruction to a random value of the base cycle plus the offset according to a formula. The power balancing instruction dynamically adjusts the operating voltage of the hardware computation unit according to a formula (the adjustment coefficient is set to 0.1, and the random number is within...). (Range value selection), balance the power consumption fluctuations during the calculation process, and hide physical characteristics.

[0037] Key status monitoring: The key status monitoring unit of the full lifecycle management module collects key storage location (memory / cache), cumulative number of uses and time of each call, device identifier and other records in real time according to the formula through the MonitorKeyState command, forming a key status log.

[0038] Hardware-level destruction: When the key is no longer in use (the 24-hour binding validity period expires), the system automatically triggers the HardwareDestroyKey hardware-level destruction command, which sequentially clears the plaintext copy of the key in memory, the key fragments in the cache, and the key backup in non-volatile storage. After the clearing is completed, a destruction confirmation signal is generated and written to the log, thus completing the full lifecycle management of the key.

[0039] Performance verification: By monitoring the success rate of key invocation across architecture devices, key generation / distribution latency, side-channel attack protection effectiveness (timing / power consumption characteristic dispersion), and key residue detection results, the system's performance indicators in terms of cross-architecture adaptability, security, and scheduling efficiency are verified.

[0040] Therefore, this invention provides a key scheduling method based on a secure instruction set. It constructs a multi-dimensional security barrier through identity-scenario-permission ternary verification instructions, combined with the BindKeyScene dynamic binding mechanism, eliminating the risk of unauthorized calls and replay attacks at the source. Relying on a subset of general security instructions and cross-architecture conversion functions, it achieves compatibility with multiple architectures such as Intel SGX and ARM TrustZone, significantly reducing adaptation costs. Through the coordinated execution of timing randomization and power balancing instructions, it effectively conceals the physical characteristics of key operations, improving resistance to side-channel attacks. With the HardwareDestroyKey hardware-level destruction instruction, it completely eliminates key remnants across all storage media, and combined with real-time key status monitoring, it achieves closed-loop management throughout the entire key lifecycle. This method requires no hardware reconstruction, optimizes scheduling efficiency while ensuring high security, and can be widely adapted to the high-security requirements of various scenarios such as financial payments, cloud computing, and the Internet of Things.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A key scheduling method based on a secure instruction set, characterized in that, include: S1. Receive key operation request and call the identity-scenario-permission ternary verification instruction to verify the legality of the request; S2. If the verification is successful, based on the preset subset of general security instructions, the corresponding key generation, distribution or update instructions are dynamically invoked according to the current business needs to complete the corresponding key operation. S3. During the key operation process, timing randomization instructions and power balancing instructions are executed synchronously to protect the key operation process. S4. After the key is no longer in use, a hardware-level destruction instruction is triggered to clear all copies of the key in memory, cache, and non-volatile storage media.

2. The key scheduling method based on a secure instruction set according to claim 1, characterized in that, In S1, the verification process of the identity-scenario-permission ternary verification command includes: S11. Extract the caller's identity information, current business scenario identifier, and key permission level requested from the key operation request; S12. Verify the legitimacy of the caller's identity information through the identity verification sub-instruction, and confirm the security level corresponding to the business scenario identifier through the scenario identification sub-instruction; S13. Determine whether the key permission level matches the security level of the business scenario. If the identity is legitimate and the level matches, the request is deemed legitimate; otherwise, the key operation is rejected.

3. The key scheduling method based on a secure instruction set according to claim 2, characterized in that, In S1, the key is dynamically bound to the current business scenario identifier via the BindKeyScene command. The binding relationship is automatically released when the key is no longer in use. The binding formula is as follows: ； In the formula, The key to be bound. For business scenario identification, To bind the valid duration, For the preset hash function, This is an XOR operation.

4. The key scheduling method based on a secure instruction set according to claim 1, characterized in that, In S2, the general security instruction subset includes key generation sub-instructions, key distribution sub-instructions, key update sub-instructions, key status monitoring sub-instructions, and key destruction sub-instructions. The conversion formula between proprietary security instructions and the general security instruction subset is as follows: ； In the formula, These are the converted general security instructions. These are original proprietary security instructions. For hardware architecture type, This is a cross-architecture transformation function.

5. A key scheduling method based on a secure instruction set according to claim 1, characterized in that, In S3, the implementation process of timing randomization instructions includes: A pseudo-random clock cycle offset is generated using a linear feedback shift register. Adjust the execution clock cycle of the key operation instructions to the base cycle. The calculation formula is: ； ； In the formula, This is the adjusted actual execution period. As the base period, This is the pseudo-random clock cycle offset. For the minimum offset, This is the maximum offset.

6. The key scheduling method based on a secure instruction set according to claim 1, characterized in that, In S3, power balancing instructions are implemented by dynamically adjusting the operating voltage of the hardware processing unit, with the voltage adjustment range... The calculation formula is: ； In the formula, The reference operating voltage, To adjust the coefficient, for Random numbers within the interval.

7. The key scheduling method based on a secure instruction set according to claim 1, characterized in that, In S4, the hardware-level destruction instruction is the HardwareDestroyKey instruction. When this instruction is executed, it sequentially clears the plaintext copy of the key in memory, the key fragments in the cache, and the key backup in non-volatile storage. After clearing is completed, a destruction confirmation signal is generated.

8. A key scheduling system based on a secure instruction set, characterized in that, include: The instruction verification module is used to execute identity-scenario-permission ternary verification instructions and scenario binding instructions to verify the legality of key operation requests; A cross-architecture adaptation module is used to store a subset of general security instructions and to convert between proprietary security instructions and the subset of general security instructions. The full lifecycle management module is used to execute key generation, distribution, update, status monitoring, and hardware-level destruction instructions; The anti-side-channel module is used to execute timing randomization instructions and power balancing instructions to protect the key operation process from side-channel attacks.

9. A key scheduling system based on a secure instruction set according to claim 8, characterized in that, The full lifecycle management module also includes a key status monitoring unit, which uses the MonitorKeyState command to collect the key's storage location, usage count, and call records in real time. The monitoring formula is as follows: ； In the formula, This is the current storage location of the key. The cumulative number of times the key is used. A set of key call records.

10. A key scheduling system based on a secure instruction set according to claim 8, characterized in that, The cross-architecture adaptation module is compatible with proprietary security instructions of Intel SGX, ARM TrustZone and TPM 2.0 architectures. During the conversion process, the core operation logic of the proprietary instructions is preserved, and only the instruction format and parameters are adapted and adjusted.

Images