Code protection method, system, architecture and storage medium based on a security chip

By building a security chip in the object-side device to store and manage mixed code and access control data, the security and management problems of code protection in the prior art are solved, and a more efficient and safer code protection effect is achieved.

CN118965303BActive Publication Date: 2025-06-10刘增气 +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411121793.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-08-15
Publication Date
2025-06-10
Estimated Expiration
2044-08-15

AI Technical Summary

Technical Problem

The existing code protection technology has problems such as insufficient encryption strength, large resource usage, limited key distribution, difficult authorization application, and lack of code life cycle management.

Method used

The code protection method based on security chip is adopted, and the code encryption and access control is realized by incorporating a security chip in the object-side device to store mixed code, access control module, trust domain data, permission domain data and ACL.

Benefits of technology

It improves the security strength of code protection, expands the application scope of protected codes, simplifies authorized applications, can effectively cover the access control process used by codes, and realizes effective management of the code life cycle.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118965303B_ABST
    Figure CN118965303B_ABST
Patent Text Reader

Abstract

A code protection method, system, architecture, and storage medium based on a security chip proposed by an embodiment of the present disclosure. The method includes: receiving a request from an application program of an object device to call a protected code service in the security chip; wherein, the request carries the object device DEV ID, role information, access type, application program ID, and the identity certificate of the object device application program; sequentially reading the ACL and the trust domain, and respectively verifying the binding result of the object device DEV ID and the security chip SEID and the identity of the application program; reading the permission result set to verify the application program role information and obtain the permission information corresponding to the application program role; performing a permission determination according to the access type to determine the requested service content; calling the corresponding code resources according to the permission determination result and performing the corresponding operations; and returning the code execution result to the object device application program. The method of the present disclosure improves the security intensity of code protection and expands the application scope of the protected code.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of information security technology, and in particular, to a code protection method, system, architecture, and computer storage medium based on a security chip. Background Art

[0002] Existing code protection mostly adopts technologies such as code mixing and code encryption. Some code mixing and encryption technologies are complex, and these technologies still have the following problems: First, the encryption strength is insufficient and it is easy to be reversed; second, it occupies more system resources and affects the normal use of business applications; third, the distribution of encryption keys is restricted and it is not suitable for large-scale promotion; fourth, the authorization application of code protection is difficult and it cannot effectively cover the access control process of code use; fifth, the supervision of code application is lacking and it is impossible to effectively manage the life cycle of code. Summary of the Invention

[0003] The purpose of the embodiments of the present disclosure is to provide a code protection method, system, architecture, and computer storage medium based on a security chip, so as to solve the foregoing problems existing in the prior art.

[0004] In order to achieve the above purpose, the technical solutions adopted by the embodiments of the present disclosure are as follows:

[0005] On the one hand, the embodiments of the present disclosure provide a code protection method based on a security chip. The method includes:

[0006] Applied to an end device, the end device is built-in with a security chip, and the security chip stores mixed code, an access control module, trust domain data, permission domain data, and an ACL. The mixed code includes protected code, encrypted code, and redundant code. The method includes:

[0007] Receiving a request from an end device application program to call the protected code service in the security chip, where the request carries the end device DEV ID, role information, access type, application program ID, and the end device application program identity certificate;

[0008] Sequentially reading the ACL and the trust domain, and respectively verifying the binding result of the end device DEV ID and the security chip SE ID and the application program identity; where the ACL stores the binding result signature of the end device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chain data for verification;

[0009] Reading the permission result set to verify the application program role information and obtaining the permission information corresponding to the application program role; where the permission domain data includes permission rules, the permission rules refer to the corresponding relationship between user roles and corresponding permissions, and the permission result set refers to all user roles in the permission rules;

[0010] Determine permissions based on the access type to determine the service content;

[0011] According to the permission determination result, call the corresponding code resources and perform operations within the corresponding permission range;

[0012] Return the code execution result to the application program of the device-side device.

[0013] Optionally, before the application program of the device-side device sends a service request, initialize the security chip. The specific process includes:

[0014] Initialize the internal structure of the security chip to form a data area and a code area;

[0015] Write the pre-acquired initial data, namely PKI certificates and certificate chains, trust domain data, permission rule data, ACL initial data, and mixed code data, into the data area and the code area respectively to initialize the security chip. Among them, the mixed code data includes protected code, encrypted code, and redundant code. The protected code is the code to be protected. The ACL stores the binding result signature of the device-side device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chains for verification.

[0016] Optionally, the binding process between the device-side device DEV ID and the security chip SE ID includes:

[0017] Receive the security chip registration and binding service request;

[0018] Determine whether the security chip is bound to the device-side device. If it is already bound, return the binding information; if it is not bound, return the security chip SE ID;

[0019] If the security chip SE ID is returned, extract the device-side device Dev ID, send the SE ID and Dev ID to the security supervision system, and request to activate the registration and binding service;

[0020] Receive the binding result signature data of the security chip and the device-side device generated after activating the registration of the security chip returned by the security supervision system;

[0021] Store the binding result signature in the ACL and return the binding success information.

[0022] Optionally, after returning the code execution result to the application program of the device-side device, the method further includes:

[0023] Obtain the protected code access behavior - related events, the protected code running environment perception - related security events, and the protected code application result security handling - related events respectively, and send them to the security supervision system;

[0024] The security supervision system conducts statistical analysis on the protected code access behavior - related events, the protected code running environment perception - related security events, and the protected code application result security handling - related events, obtains the threat level of the security chip of the physical device, and performs corresponding handling according to the threat level.

[0025] Optionally, the security supervision system conducts statistical analysis on the protected code access behavior - related events, the protected code running environment perception - related security events, and the protected code application result security handling - related events, obtains the threat level of the security chip of the physical device, and performs corresponding handling, including:

[0026] The security supervision system performs risk - weighted calculation on each type of event within a preset time according to the pre - configured corresponding event category scores, the classification factors of various types of events, and the scores corresponding to each classification factor, to obtain the risk threat level score of the security chip within the corresponding preset time;

[0027] Determine the risk level according to the risk threat level score;

[0028] Take corresponding early - warning responses to security threats of different levels, that is, perform corresponding processing on security threats of different levels according to the predetermined strategy.

[0029] Optionally, the pre - configured corresponding event category scores, the classification factors of various types of events, and the risk threat scores corresponding to each classification factor include:

[0030] The category score of the protected code running environment perception - related security events is the first score. The classification factors of the protected code running environment perception - related security events include abnormal data identification, abnormal data flow, abnormal user login, abnormal application program, abnormal network intrusion, abnormal network process, abnormal network process, abnormal system vulnerability, and abnormal system resources. Each classification factor is set with a corresponding risk threat score;

[0031] The category score of the protected code access behavior - related events is the second score. The classification factors of the protected code access behavior - related events include insufficient access rights, abnormally frequent access, authentication failure, role information mismatch, invalid trust domain, and abnormal code access. Each classification factor is set with a corresponding risk threat score;

[0032] The score of the event category for the secure disposal of the protected code application result is the third score. The classification factors for the event category of the secure disposal of the protected code application result include unencrypted data and unsigned data. Each classification factor is set with a corresponding risk threat score.

[0033] Determining the risk level based on the risk threat level score includes:

[0034] If the risk threat level score of the security chip is less than or equal to the first threshold, the threat level is level one; if the risk threat level score of the security chip is greater than the first threshold and less than the second threshold, the threat level is level two; if the risk threat level score of the security chip is greater than or equal to the second threshold and less than or equal to the third threshold, the threat level is level three; if the risk threat score of the security chip is greater than the third threshold, the threat level is level four.

[0035] Taking corresponding warning responses to security threats of different levels includes:

[0036] For level one threats, reminder disposal is carried out; for level two, level three, and level four threats, alarm disposal is carried out. For level three and level four threats, on the basis of alarm disposal, corresponding emergency disposal is carried out simultaneously.

[0037] Optionally, after taking corresponding warning responses to security threats of different levels, that is, after processing security threats of different levels according to a predetermined strategy, the method further includes:

[0038] Obtaining various events, threat levels, and processed data of each physical device uploaded by each security supervision system, and performing summary analysis;

[0039] According to the threat levels of each physical device, perform analysis on threat types, threat devices, threat postures, and penalty disposals.

[0040] Optionally, the permission rules include the corresponding relationship between user roles and corresponding permissions, specifically as follows:

[0041] Set user roles, and the user roles include: visitors, policy administrators, and super administrators;

[0042] Set permission categories, and the permission categories include: code call permission, ACL rule update, permission update, other configuration parameter update, internal code version management, and trust domain management six categories;

[0043] Set the corresponding relationship between user roles and permission categories. The visitor has code call permission; the policy administrator has ACL rule update, permission update, and other configuration parameter update permissions; the super administrator has internal code version management and trust domain management permissions.

[0044] Another aspect of the embodiments of the present disclosure provides a code protection system based on a security chip for an end device. The end device is built-in with a security chip, and the security chip stores mixed code, trust domain data, permission domain data, and ACL. The mixed code includes protected code, encrypted code, and redundant code. The system includes:

[0045] A receiving module, configured to receive a request from an end device application to call a protected code service in the security chip. Among them, the request carries the end device DEV ID, role information, access type, application ID, and the identity certificate of the end device application;

[0046] A first verification module, configured to read the ACL and the trust domain, and respectively verify the binding result of the end device DEV ID and the security chip SE ID and the application identity. Among them, the ACL stores the signature of the binding result of the end device DEV ID and the security chip SEID, and the trust domain stores various PKI certificates and certificate chain data for verification;

[0047] A second verification module, configured to read the permission result set to verify the application role information and obtain the permission information corresponding to the application role. Among them, the permission domain data includes permission rules, where the permission rules refer to the corresponding relationship between user roles and corresponding permissions, and the permission result set refers to all user roles in the permission rules;

[0048] A permission determination module, configured to perform permission determination according to the access type to determine the service content;

[0049] A calling module, configured to call the corresponding code resources according to the permission determination result and perform operations within the corresponding permission range;

[0050] A sending module, configured to return the code execution result to the end device application.

[0051] Another aspect of the embodiments of the present disclosure provides a code protection architecture based on a security chip. The architecture includes: a plurality of end devices, a global center set up on a cloud platform, and at least one management layer. The global center is respectively connected to each management layer, and each management layer is connected to a plurality of the end devices;

[0052] The global center includes: a root key center, a permission management center, and a security event management center;

[0053] The root key center generates and stores a root key, and the root key signs various PKI certificates and certificate chains, which are used to derive the PKI asymmetric cryptosystem of the management layer and provide the root key signature service for the PKI asymmetric cryptosystem;

[0054] The Permission Management Center formulates a set of globally unified permission rule management strategies and distributes different subsets of permission management strategies to the corresponding management levels according to the differences of various management levels. Among them, a subset of permission rule management strategies corresponds to a management level permission management system;

[0055] The Security Incident Management Center is used to aggregate the security supervision data transmitted by each management level, conduct a global-level comprehensive analysis based on the access behavior data of the application program codes of each physical device, the security data of the code running environment, and the code application result data, and predict the risk threat level, and conduct statistical analysis on the distribution and use of all physical device security chips;

[0056] The management levels include: PKI asymmetric cryptosystem, permission management system, and security supervision system;

[0057] The PKI asymmetric cryptosystem is used to provide the application program identity certificates of the corresponding physical devices respectively, provide permission management system certificates and permission signature services, and is also used to distribute various PKI certificates and certificate chains obtained from the root key center to the corresponding physical devices;

[0058] The permission management system is used to receive the permission management strategies issued by the permission management center, provide a trusted authorization result to each physical device application program, and send the results of the permission rules to the corresponding physical devices;

[0059] The security supervision system is used to obtain the behavior, environment, and code application result data of the protected code accessed by each physical device respectively, determine the security threat level of the physical device security chip according to the pre-set security incident threat level division method, and conduct corresponding early warnings, realize the supervision of each security chip, and report the data uploaded by each physical device and the threat level data to the security incident management center;

[0060] The physical device includes a security chip, an access control interface API, and a security event probe;

[0061] The security chip is integrated with a mixed code area, an access control module, a trust domain data area, a permission domain data area, and an ACL. The mixed code area includes protected code, encrypted code, and redundant code, and the protected code is the code to be protected; among them, the access control module can be used to call other areas and the ACL to authenticate the identity and verify the permissions of the application programs and interfaces accessing the protected code in the security chip; the trust domain data area includes various PKI certificates and certificate chains for verification, the permission domain data area includes permission rules, and the permission rules refer to the corresponding relationship between user roles and corresponding permissions. The ACL stores the binding result signature of the physical device DEV ID and the security chip SE ID;

[0062] The security event probe is divided into an environmental security perception probe and an access probe, which respectively collect the operating environment data, code access behavior, and code application result data of the protected code of the security chip, and output the collected data to the management layer.

[0063] On the other hand, an embodiment of the present disclosure provides a computer storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the security chip code protection method as described above are implemented.

[0064] The beneficial effects of the embodiments of the present disclosure are:

[0065] The security chip code protection method of the embodiments of the present disclosure improves the security intensity of code protection, expands the application scope of the protected code, makes the authorized application of code protection easier, and can effectively cover the access control process of code use. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 FIG. is a schematic structural diagram of a code protection architecture based on a security chip provided by an embodiment of the present disclosure;

[0067] Figure 2 FIG. is a schematic structural diagram of a security chip according to an embodiment of the present disclosure;

[0068] Figure 3 FIG. is a schematic diagram of the code protection implementation logic of the security chip according to an embodiment of the present disclosure;

[0069] Figure 4 FIG. is a schematic diagram of the analysis and early warning of the security supervision system in the security chip code protection according to an embodiment of the present disclosure;

[0070] Figure 5 FIG. is a schematic diagram of the corresponding relationship between user roles and permission categories in the security chip access permission according to an embodiment of the present disclosure;

[0071] Figure 6 FIG. is a schematic diagram of the summary analysis of the security event management center in the security chip code protection according to an embodiment of the present disclosure;

[0072] Figure 7 FIG. is a schematic flowchart of a code protection method based on a security chip provided by an embodiment of the present disclosure;

[0073] Figure 8 FIG. is a schematic diagram of the code access process of the security chip according to an embodiment of the present disclosure;

[0074] Figure 9 FIG. is a schematic diagram of the initialization process of the security chip according to an embodiment of the present disclosure;

[0075] Figure 10Schematic diagram of the binding process between the security chip and the corresponding terminal device in an embodiment of the present disclosure;

[0076] Figure 11 Schematic diagram of the analysis process of the security supervision system in the code protection architecture of the security chip in an embodiment of the present disclosure;

[0077] Figure 12 Schematic diagram of the structure of a code protection system based on a security chip provided in an embodiment of the present disclosure. Detailed implementation manners

[0078] In order to make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the embodiments of the present disclosure will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific implementation manners described herein are only used to explain the embodiments of the present disclosure, and are not used to limit the embodiments of the present disclosure.

[0079] As Figure 1As shown in the figure, an embodiment of the present disclosure proposes a code protection architecture based on a security chip. The architecture includes: a plurality of physical devices, a global center set up on a cloud platform, and at least one management layer. The global center is connected to each management layer respectively, and each management layer is connected to a plurality of physical devices; the global center includes: a root key center, a permission management center, and a security event management center; the root key center generates and stores a root key, and the root key signs various PKI certificates and certificate chains, which are used to derive the PKI asymmetric cryptosystem of the management layer and provide the root key signature service for the PKI asymmetric cryptosystem; the permission management center formulates a set of globally unified permission rule management policies, and distributes different subsets of permission management policies to the corresponding management layers according to the differences of various management layers. Among them, a subset of permission rule management policies corresponds to a management layer permission management system; the security event management center is used to aggregate the security supervision data transmitted by each management layer, and conduct a global-level comprehensive analysis according to the access behavior data of the application program code of each physical device, the security data of the code running environment, and the code application result data, as well as the predicted risk threat level, and conduct a statistical analysis on the distributed use of the security chips of all physical devices; the management layer includes: a PKI asymmetric cryptosystem, a permission management system, and a security supervision system; the PKI asymmetric cryptosystem is used to provide the application program identity certificates of the corresponding physical devices respectively, provide the permission management system certificates and permission signature services, and is also used to distribute various PKI certificates and certificate chains obtained from the root key center to the corresponding physical devices; the permission management system is used to receive the permission management policies issued by the permission management center to provide a trusted authorization result for each physical device application program, and issue the result of the permission rules to the corresponding physical device; the security supervision system is used to obtain the behavior, environment, and code application result data of the protected code accessed by each physical device respectively, and determine the security threat level of the security chip of the physical device and conduct corresponding early warnings according to the pre-set security event threat level division method, so as to realize the supervision of the process of each security chip, and report the data and threat level data uploaded by each physical device to the security event management center; the physical device includes a security chip, an access control interface API, and a security event probe; the security chip integrates a mixed code area, an access control module, a trust domain data area, a permission domain data area, and an ACL. The mixed code area includes protected code, encrypted code, and redundant code, and the protected code is the code to be protected; among them, the access control module can be used to call other areas and the ACL to perform identity authentication and permission verification on the application programs and interfaces accessing the protected code in the security chip. The trust domain data area includes various PKI certificates and certificate chains for verification. The permission domain data area includes permission rules, and the permission rules refer to the corresponding relationship between user roles and corresponding permissions. The ACL stores the binding result signature of the physical device DEV ID and the security chip SEID.The security event probe is divided into an environmental security perception probe and an access probe, which respectively collect the operating environment data of the protected code of the security chip, the code access behavior, and the code application result data, and output the collected data to the management layer.

[0080] The security chip of the embodiment of the present disclosure can be used in various security terminals for Internet of Things informatization, and is applicable to various scenarios, such as vehicle networking data compliance, urban Internet of Things security terminals, and power Internet of Things edge security scenarios, etc. The code protection architecture of the embodiment of the present disclosure is based on the existing security chip and cryptography technology, taking the cryptographic chip as a prerequisite condition, mainly using the relatively high-strength hardware security protection ability of the security chip and the cryptographic encryption and decryption ability to build a miniature trusted computing base, and building a trusted execution environment for the code based on the security chip components.

[0081] As Figure 2 shown, the security chip module refers to the security protection hardware using cryptography technology. In addition to the cryptographic circuit and protection against side-channel attacks inside the chip, it also includes other circuits to implement services such as protected code protection and access control. The security chip cooperates with other systems to build a trust system, access control policies, verification services, protected code, etc.

[0082] As Figure 3 shown, the security chip code protection method in the embodiment of the present disclosure can be implemented using the above architecture. Among them, the management layer is connected to the device-side device, and the management layer is also connected to the global center. The global center performs global management, formulates permission management policies according to actual situations, generates root keys, signs corresponding root certificates, summarizes security events, and conducts overall analysis, etc., to form hierarchical management, strengthen the confidentiality of the security chip, be applicable to security chips with protected codes of different functions, effectively expand the application scope of the security chip, and be applicable to various device-side device scenarios. The device-side device includes an embedded security chip, a security interface bus, an access control API, an application program, an environmental security perception probe, and other security event probes, etc. The application program of the device-side device is connected to the access control API through the security interface bus.

[0083] The secure chip includes a mixed-code area, an access control module, a trusted domain data area, a permission domain data area, and an ACL. Among them, the mixed-code area includes protected code, encrypted code, and redundant code, and the protected code is the code to be protected; the access control module, which is an application on the secure chip, can call the mixed-code area, the trusted domain data area, the permission domain data area, and the ACL. The trusted domain data area includes various root certificates and certificate chains for verification, and the permission domain data area includes permission rules, which refer to the correspondence between user roles and corresponding permissions. When the data in the secure chip is initialized offline, it obtains data from the PKI asymmetric cryptosystem and the permission management system respectively. The PKI asymmetric cryptosystem and the permission management system need to obtain relevant data from the global center to complete initialization before use, so as to provide initialization data for the secure chip, which will not be elaborated here. The secure chip can also be called a secure code chip. The secure chip obtains relevant data of the PKI asymmetric cryptosystem and the permission management system through the secure code chip initialization system to initialize the secure chip. The secure code chip initialization system obtains various root certificates, certificate chains, and trusted domain signature data from the PKI asymmetric cryptosystem respectively, and obtains permission rule data, ACL initial data, etc. from the permission management system. Obtain the mixed code from relevant providers.

[0084] The access control interface API is respectively connected to the security interface bus of the device-side device and the access control module of the secure chip. The application APP of the device-side device accesses the secure chip through the security interface bus and the access control API to realize the communication between the application of the device-side device and the secure chip.

[0085] The security event probe is an application set in the device-side device to implement a collection service for supervising the access behavior of the code. The collected data includes access behavior data of the code, code running environment data, etc. After the data is collected, it is sent to the central end, that is, the security event supervision system.

[0086] The design intention of the key in the PKI asymmetric cryptosystem is to be used to construct a trusted domain, which is used to express the identity of the secure chip, the user, or the business APP. It verifies the identity through cryptographic algorithms and technologies to prevent forgery, and it is the secondary management node of the root key.

[0087] The permission management system is mainly to grant permissions to users or application APPs. The permissions include three levels: access permission, update parameter, and COS upgrade, to realize the control of the code in the secure chip.

[0088] A security supervision system is used to supervise the running process of protected code in a security chip based on the data accessed by the protected code obtained, conduct threat level assessment and corresponding early warnings; and report the data accessed by the protected code and the supervision data of code information to the security event management center. Supervise the running process of the code in the security chip to prevent security risks and problems. The implementation method is to statistically analyze the access events and environmental information of user or application APP code, and then issue early warnings according to the definition of the level of security events. For example Figure 4 As shown, the environmental security perception probe in the security event probe is used to collect the running environment data of the protected code of the security chip. The environmental data includes: data identifier monitoring, user login, network intrusion monitoring, system resource monitoring, data flow monitoring, application fingerprint monitoring, network traffic monitoring, and system vulnerability monitoring. The access probe collects code access events, that is, code access behaviors and code application result data. The result data includes encryption and decryption results, etc.

[0089] The security event probe transmits the collected various data to the security supervision system at the management layer through the security interface bus. The security supervision system statistically analyzes the code running environment data, code access behavior data, and code application result data, conducts event threat analysis and grading, and conducts corresponding emergency responses.

[0090] Root key center: Generates and stores the root key. The root key signs various PKI certificates and certificate chains, is used to derive the PKI asymmetric cryptosystem at the management layer, and provides the root key signature service to the PKI asymmetric cryptosystem. The root key is the trust core of the entire system solution, establishes a trust chain with the PKI asymmetric cryptosystem, so as to support the PKI asymmetric cryptosystem to issue identities for all device objects at the physical layer. In actual application, PKI certificates and certificate chains are generated in advance according to the device objects at the physical layer.

[0091] Permission management center: Formulates a globally unified set of permission rule management strategies, and distributes different subsets of permission management strategies to the corresponding management layers according to the differences of various management layers. Among them, a subset of permission rule management strategies corresponds to a management layer permission management system. The access authorization of the code chip can be set hierarchically, and the permission management is assigned to the users and the units of the application APP, and multiple permissions are set and distributed according to the identity of the user or application program. Here, a permission management system can correspond to one user, and the user can be an enterprise, institution, company, etc. Each user can have multiple application programs, each application program is a user role, and different user roles have corresponding permissions.

[0092] Security Incident Management Center: The Security Management Center aggregates the data of all security incident monitoring systems, conducts a comprehensive global analysis based on the data of the access and usage of the application programs of the device-side devices, the security data of the operating environment, etc., and the threat levels of the predicted risks, and conducts a statistical analysis of the distribution and usage of the security chips of all device-side devices to predict the possibility of risks.

[0093] As Figure 6 shown, the Security Incident Management Center aggregates the event and disposal data, and conducts aggregated analysis, threat type analysis, threatened device analysis, threat situation analysis, penalty and disposal analysis, etc. according to the threat levels statistically analyzed by the Security Incident Monitoring Center.

[0094] As Figure 7 shown, on the other hand, an embodiment of the present disclosure proposes a code protection method based on a security chip, which is applied to a device-side device. The device-side device is built-in with a security chip, and the security chip stores mixed code, an access control module, trust domain data, permission domain data, and an ACL. The mixed code includes protected code, encrypted code, and redundant code. The method includes:

[0095] Step S100: Receive a request from the application program of the device-side device to call the protected code service or update / manage the corresponding permissions in the security chip. Among them, the request carries the device-side device DEV ID, role information, access type, application program ID, and the identity certificate of the application program of the device-side device.

[0096] The security chip code protection method of the embodiment of the present disclosure is implemented based on the above security chip code protection architecture. The device-side device can be a vehicle-side device, etc., which is not limited here. The device-side device is built-in with a security chip, and the application program of the device-side device communicates with the security chip through a security interface bus. The security chip is also a security code chip. The redundant code is invalid code that increases the code volume to improve the difficulty of decompilation and make the protected code not easily decompiled. In the embodiment of the present disclosure, the application program ID and the application program identity certificate are usually used together. As Figure 8 shown, the relevant business application program of the device-side device, that is, a certain APP, sends a request for the protected code service to the security chip through the security interface bus, and occasionally there are other permission update requests, etc.

[0097] Step S200: Sequentially, read the ACL and the trust domain, and respectively verify the binding result of the device-side device DEV ID and the SEID of the security chip and the identity of the application program. Among them, the ACL stores the signature of the binding result of the device-side device DEV ID and the SE ID of the security chip, and the trust domain stores various PKI certificates and certificate chains for verification.

[0098] Specifically, the access control module in the security chip reads the relevant content pre-stored in the ACL and the trust domain by invoking the ACL and the trust domain to implement corresponding verification. That is to say, when downloading relevant application programs, an identity certificate is carried. When the application program requests protected code services or other permission services in the security chip, the PKI certificate and certificate chain pre-stored in the trust domain are used to verify whether the application program is trustworthy. If the identity of the application program is trustworthy, the next step is carried out, which will not be elaborated here. In the embodiments of the present disclosure, the DEV ID of the device at the physical end is a device identifier, which is a code used to uniquely identify a hardware device. The main purpose is to identify and distinguish different devices; the application program ID is also used to determine the application program.

[0099] Step S300: Read the permission result set to verify the application program role information and obtain the permission information corresponding to the application program role. Among them, the permission domain data includes permission rules, and the permission rules refer to the corresponding relationship between user roles and corresponding permissions. The permission result set refers to all user roles in the permission rules.

[0100] After the binding result of the DEV ID of the device at the physical end and the SEID of the security chip and the identity of the application program are respectively verified by reading the ACL and the trust domain in step S200, step S300 is performed. The access control module invokes the permission domain data and reads the permission results of the permission rules therein, that is, the user roles; verifying the application program role information is to match the user role information carried by the application program with the role list in the permission rules. If a match can be made, the corresponding permissions are obtained.

[0101] As Figure 5 shown, as a specific example of the permission rules, the permission rules include the corresponding relationship between user roles and corresponding permissions, as follows:

[0102] Set user roles, and the user roles include: visitors, policy administrators, and super administrators;

[0103] Set permission categories, and the permission categories include: code call permission, ACL rule update, permission update, other configuration parameter update, internal code version management, and trust domain management;

[0104] Set the corresponding relationship between user roles and permission categories. The visitor has the code call permission; the policy administrator has the ACL rule update, permission update, and other configuration parameter update permissions; the super administrator has the internal code version management and trust domain management permissions.

[0105] Specifically, internal code version management refers to the update of protected code, and the update of permissions refers to the update of specific permission contents in the permission rules. The update permissions for other configuration parameters can be redundant code updates, API updates, and other configuration parameters. The permission rules can be set according to the actual situation.

[0106] In the embodiment of the present disclosure, after the security chip is initialized, during the application process, the data in the code area and data area inside the security chip can be updated, and only the corresponding user roles can perform the corresponding updates. The embodiment of the present disclosure sets different permissions according to different user roles, which can better protect the security chip.

[0107] Step S400: Perform permission determination according to the access type to determine the requested service content.

[0108] It should be noted that the access type includes the role and specific permission category to determine the specific access content. For example, Figure 5 As shown, for example, if the access type is visitor / R0 and code call permission / 01, it means accessing the code, which is also a frequently accessed request; another example is that if the access type is policy administrator / R1 and ACL rule update / 11, then the request is to update the ACL. In this way, the specific requested service content is determined.

[0109] Step S500: According to the permission determination result, call the corresponding code resource and perform operations within the corresponding permission range.

[0110] That is to say, if it is a request for a protected code service, then call the corresponding code from the code file and perform the corresponding operations. If it is an operation of other permission categories, the corresponding permission operations are also performed.

[0111] Step S600: Return the code execution result to the application program of the device at the physical end.

[0112] Specifically, the code execution result is transmitted to the application program through the access control module and the security interface bus.

[0113] For example, Figure 9 As shown, before the application program of the device at the physical end sends a service request, it is necessary to initialize the trust of the security chip. The specific method includes:

[0114] Step S10: Initialize the internal structure of the security chip to form a data area and a code area.

[0115] In the embodiment of the present disclosure, a chip writing tool and a chip initialization system are used to initialize the internal structure of the security chip to form an initialized data area and a code area; the data area is used to store trust domain data, permission domain data, and ACL, etc., and the code area is used to store encrypted mixed code.

[0116] Step S20: write the pre-acquired initial data, namely, the PKI certificate and certificate chain, the trust domain data, the permission rule data, the ACL initial data and the mixed code data, into the data area and the code area respectively to initialize the security chip, wherein the mixed code data includes the protected code and the redundant code, the protected code is the guarded code, the ACL stores the binding result signature of the physical device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chains for verification.

[0117] The chip writing tool, that is, the security chip initialization system obtains various root certificates and certificate chain data summarized by the root key center. The various PKI certificates and certificate chain data of the root key center are first sent to the PKI asymmetric cryptographic system, and then transmitted to the security chip initialization system via the PKI asymmetric cryptographic system; obtains signature data such as trust domain summarized from the PKI asymmetric cryptographic system; obtains permission rule data, ACL initial data, etc. summarized from the permission system; obtains mixed code data from relevant providers, and the mixed code data is the encrypted protected code data. The chip writing tool pours the aforementioned data obtained into the security chip to initialize the security chip. Specifically, the root certificate, trust domain signature data, permission rule data, and ACL initial data are written into the data area, and the code data is written into the code area.

[0118] like Figure 10 As shown in FIG. 1 , as a specific example of the security chip registration and binding process, the binding process of the security chip carrier device DEV ID and the security chip SE ID includes:

[0119] Step S210: receiving a security chip registration and binding service request.

[0120] The security interface bus of the embodiment of the present disclosure sends a security code chip registration and binding service request to the security chip, and the access control module of the security chip receives the request.

[0121] Step S220: determine whether the security chip is bound to the physical device. If so, return the binding information; if not, return the unique identifier SE ID of the security chip.

[0122] The access control module of the security chip of the disclosed embodiment sends a request to the ACL inside the security chip, and determines whether the chip is registered and bound by reading and retrieving whether there is a binding signature between the security chip and the physical end device. The unique identifier SE ID (Secure Element ID) inside the security chip is usually used to ensure the uniqueness and security of each chip. This identifier is solidified inside the chip when it is manufactured and cannot be changed. It provides hardware-level identity proof of the chip itself. If it has been bound, the binding information is returned to the security chip, and the process ends. If it has not been bound, the unique identifier SE ID of the security chip is returned to the access control module of the security chip.

[0123] Step S230: If the security chip SE ID is returned, extract the unique identifier Dev ID of the physical terminal device, send the SE ID and Dev ID to the security supervision system, and request to activate the registration binding service.

[0124] Specifically, the access control module of the security chip extracts the unique identifier Dev ID of the object terminal device. The access control module of the security chip sends the SE ID and Dev ID to the security supervision system to request activation registration binding. The security supervision system performs activation registration based on the security chip SE ID and the object terminal device Dev ID, and generates the signature data of the binding result between the security chip and the object terminal device. The signature data of the binding result between the security chip and the object terminal device is sent to the security chip through the security interface bus.

[0125] Step S240: receiving the signature data of the binding result between the security chip and the physical terminal device generated after the registered security chip is activated and returned by the security supervision system.

[0126] The security supervision system of the disclosed embodiment will also have an identity certificate, which also comes from the PKI asymmetric cryptographic system. The security chip ID and the physical device ID are combined and signed through this identity certificate, and then the result is returned to the security chip and stored in the ACL storage area. The access control module of the security chip receives the signature data of the binding result between the security chip and the physical device.

[0127] Step S250: Store the binding result signature into the ACL and return binding success information.

[0128] The access control module of the security chip of the disclosed embodiment stores the binding result signature into the ACL, and the ACL returns the binding success information to the access control module. The access control module of the security chip returns the registration binding success to the security interface bus, and ends the binding process. The security chip receives the security chip registration activation request sent by the security interface bus, activates the registration through the above steps S220 to S250, binds the corresponding relationship between the security chip and its physical end device, and returns the registration binding result to the security interface bus.

[0129] As Figure 4 shown, as a specific example after returning the code execution result to the application program, after returning the code execution result to the application program of the device-side device, the method further includes:

[0130] Step S700: respectively obtain the protected code access behavior type events, the protected code running environment perception type security events, and the protected code application result security handling type events, and send them to the security supervision system.

[0131] In the embodiment of the present disclosure, the device-side device is provided with various security event collection probes, namely an environment security perception probe and an access probe, which respectively collect the relevant data of the execution operation of the device-side device application program on the protected code. The environment security perception probe collects the running environment data of the protected code of the security chip, and the access probe collects the code access behavior and the code application result data. The security event collection probe transmits the collected various events to the security supervision system through the security interface bus. The security supervision system analyzes and divides the security threat levels according to various security events and makes corresponding processing.

[0132] Step S800: The security supervision system performs statistical analysis on the protected code access behavior type events, the protected code running environment perception type security events, and the protected code application result security handling type events, obtains the threat level of the device-side device security chip, and performs corresponding handling according to the threat level.

[0133] The security supervision system of the embodiment of the present disclosure obtains the data related to the code access events uploaded by multiple device-side devices, and analyzes the security threat level of the protected code access for each device-side device.

[0134] Before analyzing the security threat level of the protected code access for each device-side device, as Figure 11As shown in the figure, the security event preprocessing module configures type scores, classification factors, and sets corresponding risk threat scores for each splitting factor for the protected code access behavior class events, the protected code running environment perception class security events, and the protected code application result security handling class events, and stores them in the threat analysis and grading module. For example, the protected code running environment perception class security events include: data identity monitoring, user login, network intrusion monitoring, system resource monitoring, data flow monitoring, application fingerprint monitoring, network traffic monitoring, and system vulnerability monitoring data. If the factor data in each type of event is normal, the score is not considered or is 0. If one or several factor data is abnormal, the score of this type of event is calculated based on the abnormal factors, and the scores of each type of event are summarized to obtain the risk threat level score within a preset time. The threat analysis and grading module of the security supervision system forms the threat grading data of the device-side code for various events to be summarized and weighted uploaded by each device-side device.

[0135] According to the different functional attributes of the protected code, the security event preprocessing module configures corresponding classification factors for various security events to weight the security risks, that is, sets corresponding type scores for various events, sets corresponding classification factors for each event, and sets corresponding risk threat scores for each classification factor. The category score of the protected code running environment perception class security events is the first score, and the first score is 3 points. The classification factors and the scores of each factor of the protected code running environment perception class security events are: data identity anomaly, score: 0.5; data flow anomaly, score: 2; user login anomaly, score: 0.5; application program anomaly, score: 2; network intrusion anomaly, score: 2; network process anomaly, score: 1; network process anomaly, score: 0.5; system vulnerability anomaly, score: 0.5; and system resource anomaly, score: 0.5.

[0136] The category score of the protected code access behavior class events is the second score, and the second score is 4 points; the classification factors and scores of the protected code access behavior class events are: insufficient access rights, score: 0.5; abnormal frequent access, score: 1; authentication failure, score: 0.5; role information mismatch, score: 0.5; trust domain invalid, score: 0.5; and code access anomaly, score: 2.

[0137] The category score of the protected code application result security handling class events is the third score, and the third score is 2 points. The classification factors and scores of the protected code application result security handling class events are: data not encrypted, score: 0.5; and data not signed, score: 0.5.

[0138] Users can define this risk weighting table according to the attributes of the protected code and the abnormal threats.

[0139] As Figure 11 shown, as a specific example of security supervision, the security supervision system statistically analyzes the events of the protected code access behavior type, the security events of the protected code running environment perception type, and the security disposal events of the protected code application results, obtains the threat level of the security chip of the physical device, and performs corresponding disposal according to the threat level, including:

[0140] Step S810: The security supervision system performs risk weighted calculation on the events of the protected code access behavior type, the security events of the protected code running environment perception type, and the security disposal events of the protected code application results within a preset time according to the pre-configured scores of each event category, the classification factors of various events, and the scores corresponding to the classification factors, and obtains the risk threat level score of the security chip within the corresponding preset time.

[0141] Analyze the risk weighting of security events to form the security threat score of the security code chip for each physical device within a certain period of time. The calculation method is: risk threat score = category score + category item score. For example, if the probe collects a failed authentication, which belongs to the event type of code access behavior, the risk threat score is the sum of the failed authentication and its event type score, which is 4.5 points; if the probe collects abnormal data flow, abnormal user login, and abnormal frequent access, then the risk threat score is the sum of the scores of abnormal data flow, abnormal user login, and abnormal frequent access and their respective event category scores, which is 10.5.

[0142] Step S820: Determine the risk level according to the risk threat level score.

[0143] Specifically, when the risk threat score of the security chip is less than or equal to the first threshold, the threat level is level one; when the risk threat score of the security chip is greater than the first threshold and less than the second threshold, the threat level is level two; when the risk threat score of the security chip is greater than or equal to the second threshold and less than or equal to the third threshold, the threat level is level three; when the risk threat score of the security chip is greater than the third threshold, the threat level is level four.

[0144] According to the risk threat score, form the threat security level: risk threat score <= 4, threat level is level one; risk threat score > 4 and < 5, threat level is level two; risk threat score >= 5 and <= 7, threat level is level three; risk threat score > 7, threat level is level four. Users can also define the security level by themselves.

[0145] Step S830: Take corresponding early warning responses to security threats of different levels, that is, perform corresponding processing on security threats of different levels according to the predetermined strategy.

[0146] Specifically, the early warning response module of the safety supervision system reminds and disposes of first-level threats, alarms and disposes of second-level, third-level, and fourth-level threats. For third-level and fourth-level threats, corresponding emergency responses are carried out simultaneously on the basis of alarm disposal. The emergency response can be follow-up by a dedicated person, etc.

[0147] The corresponding early warning responses to security threats of different levels, that is, after corresponding processing of security threats of different levels according to a predetermined strategy, the method further includes:

[0148] Step S900: Obtain various events, threat levels, and processing data of the corresponding physical devices uploaded by each safety supervision system, and perform summary analysis.

[0149] In the embodiments of the present disclosure, each safety supervision system uploads the obtained physical device data, security threat levels, and disposal data to the security event management center, and the security event management center performs further analysis.

[0150] Step S900A: Perform analysis on threat types, threat devices, threat situations, and penalty disposals according to the threat levels of each physical device.

[0151] As Figure 6 shown, after each safety supervision system processes the corresponding physical device data, the processed data and the original data are further summarized and reported to the security event management center. The security event management center receives the processed result data of each safety supervision system, and performs summary analysis, threat type analysis, threat device analysis, threat situation analysis, and penalty disposal according to the four threat levels for better management. The embodiments of the present disclosure are applicable to various security chips, so that the security chips are applied to various terminal devices, and different permission management is formulated according to the code protection architecture of the security chips to authorize corresponding application programs to access the security chips, and further protection of the security chips is achieved through the trust system. Through the security chip access events feedback by the physical devices, analysis and summary are carried out to achieve post-event supervision and improve the operation management of the security chips.

[0152] Analyze threat types, threat devices, threat postures, and punishment and handling measures according to the actual situation. For example, threat types may include: Data leakage: Unauthorized data access or transmission may lead to the leakage of sensitive information such as personal identity information, health records, or corporate secrets. Device hijacking: Attackers control IoT devices such as smart cameras and door locks for monitoring or illegal operations. Denial of Service (DoS) and Distributed Denial of Service (DDoS): Overloading requests to paralyze devices or networks. Man-in-the-Middle (MITM) attack: Intercepting communications during data transmission, tampering with or eavesdropping on information. Software vulnerability: Unpatched software vulnerabilities may be exploited, leading to system intrusion. Physical security threat: Physical damage or theft of devices results in data loss or loss of device functionality. Threat devices may include: Smart home devices (such as smart bulbs, smart locks); Industrial control systems (such as SCADA systems); Wearable devices (such as smart watches, fitness trackers); Medical devices (such as remote patient monitoring systems); Vehicles (such as autonomous vehicles), etc.

[0153] Threat posture analysis may include: Frequency: Some threats may be more common than others, such as software vulnerabilities and data leakage. Scope of impact: Threats may affect a single device or the entire network. Potential damage: Ranging from minor data leakage to large-scale infrastructure paralysis. Response time: The detection and response speed of threats, the faster the better.

[0154] Punishment and handling analysis may include: Emergency response: Immediately disconnect the infected device from the network to prevent the spread of threats. Software updates and patches: Regularly update device software to fix known security vulnerabilities. Encryption and authentication: Ensure data transmission and storage are encrypted, and use multi-factor authentication to enhance security. Physical security: Protect devices from physical damage or theft. Monitoring and auditing: Continuously monitor network traffic and device activities to identify abnormal behaviors.

[0155] As Figure 12 As shown, on the other hand, an embodiment of the present disclosure proposes a security chip code protection system applied to a security chip. The security chip stores mixed codes, an access control module, trust domain data, permission domain data, and an ACL. The mixed codes include protected codes, encrypted codes, and redundant codes. The system includes:

[0156] A receiving module 100, configured to receive a request from an application program of an object-side device to call a protected code service in the security chip; wherein, the request carries the object-side device DEV ID, role information, access type, application program ID, and the identity certificate of the object-side device application program.

[0157] The first verification module 200 is used to read the ACL and the trust domain, and respectively verify the binding result of the device end device DEV ID and the security chip SEID, and the application identity; wherein, the ACL stores the signature of the binding result of the device end device DEV ID and the security chip SEID, and the trust domain stores various PKI certificates and certificate chain data for verification;

[0158] The second verification module 300 is used to read the permission result set to verify the application role information and obtain the permission information corresponding to the application role; wherein, the permission domain data includes permission rules, and the permission rules refer to the corresponding relationship between user roles and corresponding permissions, and the permission result set refers to all user roles in the permission rules;

[0159] The permission determination module 400 is used to perform permission determination according to the access type to determine the service content;

[0160] The call module 500 is used to call the corresponding code resources according to the permission determination result and perform operations within the corresponding permission range;

[0161] The sending module 600 is used to return the code execution result to the device end device application.

[0162] In the security chip code protection system of the embodiments of the present disclosure, each module implements the access control process of the protected code in the security chip, improves the code protection ability, and makes the security chip have a stronger anti-attack effect.

[0163] Another aspect of the embodiments of the present disclosure proposes a computer storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above-mentioned security chip code protection method are implemented.

[0164] By adopting the above technical solutions disclosed in the embodiments of the present disclosure, the following beneficial effects are obtained:

[0165] First, a stronger anti-attack effect; second, a more comprehensive code protection ability; third, a more effective authorized access control; fourth, a more effective code security promotion method.

[0166] The above are only the preferred embodiments of the embodiments of the present disclosure. It should be noted that for those of ordinary skill in the art, without departing from the principle of the embodiments of the present disclosure, several improvements and refinements can be made, and these improvements and refinements should also fall within the protection scope of the embodiments of the present disclosure.

Claims

1. A code protection method based on a security chip, applied to a physical end device, wherein the physical end device has a built-in security chip, characterized in that: The security chip stores a mixed code, an access control module, trust domain data, permission domain data and ACL, the mixed code includes a protected code, an encrypted code and a redundant code, and the method includes: Receive a request from an application on a physical device to call a protected code service in a security chip; wherein the request carries the physical device DEV ID, role information, access type, application ID, and identity certificate of the physical device application; Sequentially, read the ACL and the trust domain, and verify the binding result of the object device DEV ID and the security chip SE ID and the application identity respectively; wherein the ACL stores the binding result signature of the object device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chain data for verification; Read the permission result set to verify the application role information and obtain the permission information corresponding to the application role; wherein the permission domain data includes permission rules, the permission rules refer to the correspondence between user roles and corresponding permissions, and the permission result set refers to all user roles in the permission rules; Determine the permissions based on the access type to determine the requested service content; According to the permission determination result, the corresponding code resources are called to perform operations within the corresponding permission range; Return the code execution result to the object-end device application; After returning the code execution result to the object-end device application, the method further includes: Respectively obtain protected code access behavior events, protected code running environment perception security events, and protected code application result security disposal events, and send them to the security supervision system; The security supervision system performs statistical analysis on the protected code access behavior events, the protected code running environment perception events, and the protected code application result security disposal events to obtain the threat level of the security chip of the object-end device, and performs corresponding disposal according to the threat level; include: The security supervision system performs risk weighted calculation for each type of event within a preset time according to the pre-configured corresponding event category score, the pre-configured classification factors of each type of event and the scores corresponding to each classification factor, to obtain the security chip risk threat level score within the corresponding preset time; Determine the risk level based on the risk threat level score; Take corresponding early warning responses to different levels of security threats, that is, handle different levels of security threats accordingly according to predetermined strategies.

2. The method according to claim 1, characterized in that Before the application of the physical device sends a service request, the security chip is initialized. The specific process includes: Initializing the internal structure of the security chip to form a data area and a code area; The pre-acquired initial data, namely, the PKI certificate and certificate chain, the trust domain data, the permission rule data, the ACL initial data and the mixed code data, are written into the data area and the code area respectively to initialize the security chip, wherein the mixed code data includes protected code, encrypted code and redundant code, the ACL stores the binding result signature of the physical device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chain data for verification.

3. The method according to claim 1, characterized in that The binding process of the physical end device DEV ID and the security chip SEID includes: Receive security chip registration and binding service request; Determine whether the security chip is bound to the physical device. If so, return the binding information; if not, return the security chip SE ID. If the security chip SE ID is returned, the DEV ID of the physical device is extracted, and the SE ID and DEV ID are sent to the security supervision system to request activation of the registration binding service; Receive the signature data of the binding result between the security chip and the physical terminal device generated after the activation and registration of the security chip returned by the security supervision system; The binding result signature is stored in the ACL, and the binding success information is returned.

4. The method according to claim 3, characterized in that The pre-configured corresponding event category scores, the pre-configured classification factors of each type of event, and the risk threat scores corresponding to each classification factor include: The category score of the protected code running environment perception security event is the first score, and the classification factors of the protected code running environment perception security event include data identification anomaly, data flow anomaly, user login anomaly, application anomaly, network intrusion anomaly, network process anomaly, network process anomaly, system vulnerability anomaly and system resource anomaly, and each classification factor is set with a corresponding risk threat score; The protected code access behavior event category score is a second score, and the protected code access behavior event classification factors include: insufficient access rights, abnormal frequent access, identity authentication failure, role information mismatch, invalid trust domain, and code access abnormality, and each classification factor is set with a corresponding risk threat score; The category score of the protected code application result security disposal event is a third score, and the classification factors of the protected code application result security disposal event include data is not encrypted and data is signed, and each classification factor is set with a corresponding risk threat score; Determining the risk level according to the risk threat level score includes: If the risk threat level score of the security chip is less than or equal to the first threshold, the threat level is level one; if the risk threat level score of the security chip is greater than the first threshold and less than the second threshold, the threat level is level two; if the risk threat level score of the security chip is greater than or equal to the second threshold and less than or equal to the third threshold, the threat level is level three; if the risk threat level score of the security chip is greater than the third threshold, the threat level is level four; The corresponding early warning responses to security threats of different levels include: Reminders are provided for level one threats, warnings are provided for level two, level three and level four threats, and corresponding emergency measures are taken for level three and level four threats based on warnings.

5. The method according to any one of claims 1 to 4, characterized in that: The permission rules include the corresponding relationship between user roles and corresponding permissions, as follows: Setting user roles, including visitor, policy administrator, and super administrator; Set permission categories, including six categories: code call permission, ACL rule update, permission update, other configuration parameter update, internal code version management, and trust domain management; The correspondence between user roles and permission categories is set. The visitor has code call permission; the policy administrator has ACL rule update, permission update and other configuration parameter update permissions; the super administrator has internal code version management and trust domain management permissions.

6. A security chip-based code protection system, applied to a physical end device, wherein the physical end device has a built-in security chip, characterized in that: The security chip stores mixed codes, access control modules, trust domain data, authority domain data and ACL, the mixed codes include protected codes, encrypted codes and redundant codes, and the system includes: A receiving module, used to receive a request from an application of a physical device to call a protected code service in a security chip; wherein the request carries a DEV ID of the physical device, role information, access type, application ID, and identity certificate of the physical device application; The first verification module is used to read the ACL and the trust domain to verify the binding result of the object device DEV ID and the security chip SE ID and the application identity; wherein the ACL stores the binding result signature of the object device DEV ID and the security chip SE ID, and the trust domain stores various PKI certificates and certificate chain data for verification; The second verification module is used to read the permission result set, verify the application role information respectively, and obtain the permission information corresponding to the application role; wherein the permission domain data includes permission rules, the permission rules refer to the corresponding relationship between user roles and corresponding permissions, and the permission result set refers to all user roles in the permission rules; The permission determination module is used to determine the permission according to the access type to determine the service content; The calling module is used to call the corresponding code resources and perform operations within the corresponding permission range according to the permission determination result; A sending module, used for returning the code execution result to the object-end device application; After returning the code execution result to the object-end device application, the system further includes: Respectively obtain protected code access behavior events, protected code running environment perception security events, and protected code application result security disposal events, and send them to the security supervision system; The security supervision system performs statistical analysis on the protected code access behavior events, the protected code running environment perception events, and the protected code application result security disposal events to obtain the threat level of the security chip of the object-end device, and performs corresponding disposal according to the threat level; include: The security supervision system performs risk weighted calculation for each type of event within a preset time according to the pre-configured corresponding event category score, the pre-configured classification factors of each type of event and the scores corresponding to each classification factor, to obtain the security chip risk threat level score within the corresponding preset time; Determine the risk level based on the risk threat level score; Take corresponding early warning responses to different levels of security threats, that is, handle different levels of security threats accordingly according to predetermined strategies.

7. A code protection architecture based on a security chip, characterized in that: The architecture includes: multiple A physical end device, a global center and at least one management layer arranged on a cloud platform, wherein the global center is respectively connected to each of the management layers, and each of the management layers is connected to a plurality of the physical end devices; The global center includes: a root key center, a rights management center and a security incident management center; Root key center, generates and stores root keys, signs various PKI certificates and certificate chains with root keys, is used to derive the PKI asymmetric cryptographic system at the management level, and provides root key signing services to the PKI asymmetric cryptographic system; The authority management center formulates a globally unified authority rule management strategy set, and distributes different authority management strategy subsets to the corresponding management layers according to the differences of various management layers. One authority rule management strategy subset corresponds to one management layer authority management system. The security incident management center is used to aggregate the security supervision data transmitted by each management level, conduct a comprehensive global analysis based on the application code access behavior data of each device, the code running environment security data, the code application result data, and the predicted risk threat level, and conduct a statistical analysis of the distribution and use of security chips of all device devices; The management layer includes: PKI asymmetric cryptographic system, authority management system and security supervision system; The PKI asymmetric cryptographic system is used to provide application identity certificates for corresponding physical end devices, provide rights management system certificates and rights signature services, and distribute various PKI certificates and certificate chains obtained from the root key center to corresponding physical end devices; The authority management system is used to receive the authority management policy issued by the authority management center to provide reliable authorization results to each object-end device application, and issue the results of the authority rules to the corresponding object-end device; The security supervision system is used to obtain the protected code access behavior, environment and code application result data uploaded by each object terminal device, and determine the security threat level of the security chip of the object terminal device according to the pre-set security event threat level classification method and make corresponding warnings, so as to supervise each security chip and report the data uploaded by each object terminal device and the threat level data to the security event management center; The physical end device includes a security chip, an access control interface API, and a security event probe; A security chip is integrated with a mixed code area, an access control module, a trust domain data area, a permission domain data area and an ACL, wherein the mixed code area includes protected code, encrypted code and redundant code, and the protected code is the protected code; wherein the access control module can be used to call other areas and ACL to perform identity authentication and permission verification on application programs and interfaces that access the protected code in the security chip; the trust domain data area includes various PKI certificates and certificate chains for verification, the permission domain data area includes permission rules, and the permission rules refer to the corresponding relationship between user roles and corresponding permissions, and the ACL stores the binding result signature of the object terminal device DEV ID and the security chip SE ID; The security event probe is divided into an environmental security perception probe and an access probe, which respectively collects the operating environment data, code access behavior and code application result data of the protected code of the security chip, and outputs the collected data to the management layer.

8. A computer storage medium, characterized in that: The computer storage medium stores a A computer program, which, when executed by a processor, implements the steps of the code protection method based on a security chip as described in any one of claims 1 to 5.

Citation Information

Patent Citations

  • Encryption protection method and device of chip, equipment and storage medium

    CN116756781A

  • Identity verification method and device of encryption service, electronic equipment and storage medium

    CN117668807A