Security control method and device and storage medium

Abstract

The invention discloses a security control method and device and a storage medium, and relates to the technical field of information security, and is applied to an Internet of Things device, the Internet of Things device comprises a security smart card, and the method comprises the following steps: receiving a target access request; obtaining an operating system type of the Internet of Things equipment; if the operating system type of the Internet of Things equipment is a first operating system, performing biological identity recognition on a target user sending the target access request through the secure smart card; and if the operating system type of the Internet of Things equipment is a second operating system, performing secondary authorization on the target access request based on the secure smart card, thereby improving the security of the Internet of Things equipment.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a security control method, device and storage medium. Background Art

[0002] In the wave of digitalization, IoT technology is widely used in smart homes, industrial production, medical treatment and other fields. However, as the scope of application expands, the security challenges faced by IoT are becoming increasingly severe.

[0003] Currently, the security of IoT devices is not high.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a security control method, device and storage medium, aiming to solve the technical problem that the security of current IoT devices is not high.

[0006] To achieve the above object, the present application proposes a security control method, which is applied to an Internet of Things device, wherein the Internet of Things device includes a security smart card, and the method includes the following steps: receiving a target access request; Obtaining the operating system type of the IoT device; If the operating system type of the IoT device is the first operating system, performing biometric identification of the target user who issues the target access request through the secure smart card; If the operating system type of the Internet of Things device is the second operating system, a secondary authorization is performed on the target access request based on the secure smart card.

[0007] In one embodiment, the step of receiving a target access request includes: Performing security verification on the IoT device; If the IoT device passes the security verification, the step of receiving a target access request is executed.

[0008] In one embodiment, the step of performing security verification on the IoT device includes: Initialize the IoT device and generate a public key, a private key, and a symmetric key through the secure smart card; The private key and the symmetric key are stored in a secure storage area through the secure smart card.

[0009] Compiling the firmware of the IoT device; Calculating a hash value of the firmware; Signing the hash value of the firmware using the secure smart card based on a pre-generated private key to generate a signature value; Storing the signature value and the hash value of the firmware in a firmware storage area; When the IoT device is started, the firmware is loaded, and the signature value is extracted from the firmware storage area; Obtaining a device identifier of the IoT device; Verifying, by the secure smart card, whether the device identifier matches a list of authorized devices pre-stored in the secure smart card; If the match is successful, verifying the signature value based on the public key through the secure smart card; If the verification is passed, the IoT device passes the security verification; If the verification fails, the IoT device fails the security verification, the IoT device is prevented from starting, and the relevant security events are recorded in the security audit log of the secure smart card.

[0010] In one embodiment, the first operating system is a security-enhanced Linux system, and the step of performing biometric identification of the target user who issues the target access request through the secure smart card includes: Receiving a request from the target user to access a highly sensitive object; activating a biometric identification module through the secure smart card; Collecting the biometric information of the target user through the biometric identification module; comparing the biometric information with a pre-stored biometric template via the secure smart card; If the comparison is successful, the target user is allowed to access the highly sensitive object according to the preset access control rules through the security-enhanced Linux system; If the comparison fails, the access request of the target user is rejected through the security-enhanced Linux system, and the relevant security events are recorded in the security audit log of the secure smart card.

[0011] In one embodiment, the step of receiving a request from the target user to access a highly sensitive object includes: Receiving a biometric registration request of the target user through the biometric identification module to obtain the biometric template; The biometric template is stored in a secure storage area of ​​the secure smart card.

[0012] In one embodiment, the second operating system is a real-time operating system, and the step of performing secondary authorization on the target access request based on the secure smart card includes: Performing a preliminary review of the target access request according to a preset memory access control rule through a memory protection unit of the real-time operating system; If the preliminary review is passed, the target access request is subject to a secondary review by the secure smart card according to a preset memory access authorization policy; If the secondary review is passed, the target access request is accepted through the real-time operating system; If the secondary audit fails, the target access request is rejected by the real-time operating system, and the relevant security event is recorded in the security audit log of the secure smart card.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a security control device, which is arranged in an Internet of Things device, wherein the Internet of Things device includes a security smart card, and the device includes: A request receiving module, used to receive a target access request; obtain the operating system type of the IoT device; The request control module performs biometric identification of the target user who issues the target access request through the security smart card if the operating system type of the IoT device is the first operating system; and performs secondary authorization of the target access request based on the security smart card if the operating system type of the IoT device is the second operating system.

[0014] In addition, to achieve the above-mentioned purpose, the present application also proposes a security control device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the security control method described above.

[0015] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the security control method described above are implemented.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application uses a secure smart card as the core hub, and uses the secure smart card to perform security control on the target access request, which can be flexibly configured according to different IoT application scenarios. Whether it is industrial control and smart medical fields with extremely high security requirements, or smart homes and small sensor networks that are cost-sensitive and relatively simple in function, they can accurately adapt to the needs and improve security by adjusting the smart card storage strategy and selecting different biometric modules.

[0017] In addition, the architecture design based on the secure smart card makes it easier to upgrade various security technologies. For example, when the encryption algorithm needs to be updated to deal with new security threats, only the relevant modules need to be updated in the secure smart card, without the need for large-scale transformation of the entire IoT device hardware; for another example, with the development of biometric technology, new and more accurate identification methods are introduced, which can be quickly integrated into smart cards and seamlessly connected with existing systems through software updates, providing strong support for the continued development of IoT device security protection.

[0018] This application implements different security control measures based on different operating system types, and integrates biometric authentication technology into IoT devices. When the operating system type of the IoT device is the first operating system, a biometric identification module, such as a fingerprint recognition or iris recognition sensor, is built into a security smart card to achieve user identity authentication, thereby enhancing the security of the IoT device. Moreover, when the operating system type of the IoT device is the second operating system, a secondary authorization is performed on the target access request based on the security smart card, thereby building a double-layer defense line, significantly enhancing the integrity and confidentiality of memory data, and enhancing the security of the IoT device. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 A flowchart of the first embodiment of the security control method of the present application is provided; Figure 2 This is a flowchart of the startup verification in the safety control method of this application; Figure 3 This is a schematic diagram of the structure of the IoT device for this application; Figure 4 A schematic diagram of the process of biometric identification for the security control method of this application; Figure 5 This is a schematic diagram of the module structure of the safety control device according to an embodiment of the present application; Figure 6 Schematic diagram of the device structure of the hardware operating environment involved in the security control method in the embodiment of the present application.

[0022] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0023] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0024] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of the embodiment of the present application is: receiving a target access request; obtaining the operating system type of the Internet of Things device; if the operating system type of the Internet of Things device is the first operating system, performing biometric identification of the target user who issued the target access request through the security smart card; if the operating system type of the Internet of Things device is the second operating system, performing secondary authorization on the target access request based on the security smart card.

[0026] In this embodiment, for ease of description, the following description is made with the Internet of Things device as the execution subject.

[0027] Because currently, the security of IoT devices is not high.

[0028] The present application provides a solution, which implements different security control measures based on different operating system types, integrates biometric authentication technology into IoT devices, and when the operating system type of the IoT device is the first operating system, a biometric identification module, such as a fingerprint recognition or iris recognition sensor, is built into a security smart card to achieve user identity authentication, thereby enhancing the security of the IoT device, and when the operating system type of the IoT device is the second operating system, a secondary authorization is performed on the target access request based on the security smart card, thereby building a double-layer defense line, significantly enhancing the integrity and confidentiality of memory data, and enhancing the security of the IoT device.

[0029] The security of current IoT devices is mainly achieved through the following technologies: SecureBoot: SecureBoot is a security mechanism that acts on the initial stage of device startup. It verifies the loaded system software and firmware through digital signature verification and key management system, and only allows the code with reliable source and correct integrity to start. This mechanism effectively prevents malware from being implanted into the system during the startup phase, providing guarantee for the safe operation of the device.

[0030] SELinux: SELinux (Security Enhanced Linux System) is a security module embedded in the Linux kernel. It controls access to resources such as files, processes, and network ports through sophisticated policy rules, and implements restrictions based on subject permissions. Even if a malicious program enters the system, it will not be able to obtain key resources at will due to strict access control, thereby reducing security risks caused by abuse of permissions.

[0031] MPU: MPU (Memory Protection Unit) divides the memory into multiple independent areas according to task requirements, and allocates independent memory space to each application or task module, while setting strict read, write and execute permissions. This method prevents cross-boundary access and illegal read and write of memory between tasks, ensures the integrity and security of memory data, and avoids system crashes or data leaks caused by memory problems.

[0032] SE: SE (Secure Element) is a hardware security module that integrates encryption, decryption, digital signature and key management functions. During network data transmission, it protects data security and prevents information theft through encryption algorithms. In the key generation and storage process, it uses hardware-level protection mechanisms to prevent illegal access to keys from outside, providing reliable protection for the data security of IoT devices.

[0033] The current security issues of IoT devices include the following three points: Disadvantage 1: Cost. If you choose to purchase equipment equipped with the above-mentioned independent safety technology components, or adapt and modify existing equipment one by one and introduce complex independent modules, it will cost a huge amount of money.

[0034] Disadvantage 2: Different security technologies originate from different R&D backgrounds and technical systems. Integrating them requires not only proficiency in various technical principles, but also close collaboration among multiple professionals to complete complex integration and debugging work, which is extremely difficult.

[0035] Disadvantage 3: SecureBoot mechanism usually relies on efuse (one-time programmable fuse) hardware to ensure the integrity and credibility of the firmware. However, efuse hardware has disadvantages such as high cost and poor flexibility. Once burned, it cannot be modified. It is not suitable for IoT application scenarios that require frequent firmware updates or are cost-sensitive.

[0036] It should be noted that the executor of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a security control device, an Internet of Things device, etc. that can realize the above functions. The following takes the Internet of Things device as an example to illustrate this embodiment and the following embodiments.

[0037] Based on this, the present application embodiment provides a security control method, referring to Figure 1 , Figure 1 A flowchart of the first embodiment of the security control method of the present application is provided.

[0038] In this embodiment, it is applied to an Internet of Things device, and the Internet of Things device includes a secure smart card.

[0039] It should be noted that secure smart cards can be inserted into IoT devices.

[0040] It should be noted that the secure smart card may have a built-in biometric identification module, such as a fingerprint recognition or iris recognition sensor, to perform biometric identification of the target user through the secure smart card.

[0041] The safety control method includes steps S1-S2 and steps S411-S412: Step S1, receiving a target access request; Step S2, obtaining the operating system type of the IoT device.

[0042] It should be noted that there are various types of operating systems for IoT devices, and different operating systems have different security features and adopt different security measures. Therefore, corresponding security measures need to be taken based on the operating system type of the IoT device.

[0043] Step S411: if the operating system type of the IoT device is the first operating system, biometric identification of the target user who issues the target access request is performed through the secure smart card; Optionally, the first operating system may be an operating system that requires high-precision authentication of the user identity.

[0044] Step S412: If the operating system type of the IoT device is the second operating system, a second authorization is performed on the target access request based on the secure smart card.

[0045] Optionally, the second operating system may be an operating system that is difficult to prevent complex illegal memory access behaviors.

[0046] Optionally, if the operating system type of the IoT device is a second operating system, access requests to sensitive memory can be reviewed through the second operating system when the IoT device is running.

[0047] Optionally, if the operating system type of the IoT device is the second operating system, access requests to sensitive memory can be reviewed through the secure smart card when the IoT device is running.

[0048] Optionally, if the operating system type of the IoT device is a second operating system, access requests to sensitive memory can be audited through the second operating system and the secure smart card when the IoT device is running.

[0049] Different security control measures are implemented based on different operating system types, and biometric authentication technology is integrated into IoT devices. When the operating system type of the IoT device is the first operating system, a biometric identification module, such as a fingerprint recognition or iris recognition sensor, is built into the security smart card to achieve user identity authentication, thereby enhancing the security of the IoT device. Moreover, when the operating system type of the IoT device is the second operating system, access requests to sensitive memory are reviewed by the second operating system and / or the security smart card, thereby building a solid double-layer defense line, upgrading from simply preventing out-of-bounds memory access to comprehensively preventing various complex illegal memory operations, including malicious programs exploiting memory vulnerabilities to execute code, steal data, etc., significantly enhancing the integrity and confidentiality of memory data, thereby enhancing the security of IoT devices.

[0050] In addition, traditional technologies usually rely on efuse hardware to ensure the integrity and credibility of the firmware when the IoT device starts. Once the efuse is burned, it cannot be changed, which makes firmware updates extremely inconvenient and costly, especially for those application scenarios that require frequent firmware iterations. The limitations are becoming more and more obvious. However, the embodiment of the present application abandons the reliance on efuse hardware and uses a secure smart card as a core component to build a SecureBoot mechanism. With its encryption function and storage characteristics, the secure smart card can not only generate and securely store public and private key pairs during the device initialization phase, but also dynamically perform verification operations based on the firmware hash value and signature sent by the device in the subsequent startup process, greatly improving the flexibility and maintainability of the startup process, while significantly reducing hardware costs.

[0051] At present, the security issues of IoT devices also include the following: Although SELinux provides access control policies for the operating system, it is still insufficient to protect highly sensitive objects. Simply relying on conventional user authentication methods is difficult to meet higher security requirements. At the same time, in low-cost RTOS (real-time operating system) systems, the memory protection mechanism is relatively weak, and there is a lack of effective means to prevent illegal access to sensitive memory areas.

[0052] Based on the above security issues, an embodiment of the present application is proposed.

[0053] Based on any of the above embodiments, in the second embodiment of the present application, the same or similar contents as any of the above embodiments can be referred to the above introduction, and will not be repeated later. On this basis, step S3, before receiving the target access request, the security control method also includes step S1: Step S1, performing security verification on the IoT device; If the IoT device passes the security verification, execute step 3: receiving a target access request.

[0054] The step S1, performing security verification on the IoT device, includes steps S11 to S112: Step S11, initializing the IoT device, and generating a public key, a private key, and a symmetric key through the secure smart card; Step S12: storing the private key and the symmetric key in a secure storage area via the secure smart card.

[0055] It should be noted that the security smart card has a built-in encryption module. During the initialization phase of the IoT device, a pair of public and private keys (denoted as and ), private key It is permanently stored in the secure storage area of ​​the smart card, which uses hardware encryption technology to prevent illegal external access.

[0056] Public Key It can then be securely exported to the device’s trusted storage area (such as a specific secure partition in the read-only memory of an IoT device) when needed.

[0057] At the same time, the secure smart card also generates a device-specific symmetric key , used for subsequent secure communication between the IoT device and the secure smart card, this symmetric key is also stored in the secure area of ​​the secure smart card, and key negotiation is performed with the IoT device when the IoT device is started for the first time to ensure that both parties share the same key.

[0058] Step S13, compiling the firmware of the IoT device; Step S14, calculating the hash value of the firmware; Among them, after the IoT device firmware is compiled, the hash value of the firmware is calculated by the hash function built into the compilation tool chain of the IoT device (denoted as ).

[0059] Optionally, the hash function may use a secure hash algorithm such as SHA-256 / SM3 to ensure the uniqueness and collision resistance of the hash value.

[0060] Step S15, signing the hash value of the firmware based on the pre-generated private key by the secure smart card to generate a signature value; Next, IoT devices will Sent to a secure smart card, which uses a pre-generated private key right Sign and generate signature value and returns it to the IoT device.

[0061] Step S16, storing the signature value and the hash value of the firmware in a firmware storage area; Among them, there is a firmware storage area in the IoT device, and the IoT device will and Stored together in the firmware storage area of ​​the IoT device, associated with the firmware itself.

[0062] Step S17, when the IoT device is started, the firmware is loaded, and the signature value is extracted from the firmware storage area; You can refer to Figure 2 , Figure 2 This is a flowchart of the startup verification in the safety control method of this application.

[0063] When the device is powered on, the bootloader first loads the firmware and extracts the signature value. and the firmware hash .

[0064] Among them, you can refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of the IoT device for this application. Figure 3 In the present invention, the IoT device includes a secure smart card, a main chip and a biometric module, wherein the main chip includes a bootloader and a main operating system. The bootloader and the secure smart card interact to achieve secure startup of the IoT device.

[0065] Step S18, obtaining a device identifier of the IoT device; Among them, the device identifier of the IoT device can be set to .

[0066] The bootloader then sends a boot verification request to the secure smart card, which contains the hash value of the firmware. and device identifier .

[0067] Step S19, verifying, by the secure smart card, whether the device identifier matches a list of authorized devices pre-stored in the secure smart card; After receiving the request, the secure smart card first verifies the device identifier Whether it matches the authorized device list pre-stored in the card to ensure the legitimacy of the device.

[0068] Among them, verifying the device identifier every time the IoT device is started is equivalent to setting up a dynamic device identity authentication function. Only devices that are pre-registered and authorized in the security smart card can be unlocked and started, eliminating the possibility of illegal devices accessing the IoT network, reducing security risks such as data leakage and network attacks caused by illegal access, and ensuring the boundary security of the entire IoT system.

[0069] Step S110: If the match is successful, verify the signature value based on the public key through the secure smart card; If a match is successful, the secure smart card uses the public key Signature value Verify that the signature value is generated using the corresponding private key and is consistent with the hash value of the firmware. match.

[0070] Step S111: If the verification is passed, the IoT device passes the security verification; If the signature value verification passes, it means that the firmware is complete and has not been tampered with. The secure smart card returns a verification pass signal to the Bootloader, allowing the IoT device to continue booting.

[0071] Step S112: If the verification fails, the IoT device fails the security verification, the IoT device is prevented from starting, and the relevant security events are recorded in the security audit log of the secure smart card.

[0072] If the signature value verification fails, the secure smart card sends an alarm signal to the Bootloader to prevent the IoT device from starting, and can choose to record related security events in the security audit log of the secure smart card for subsequent analysis.

[0073] The embodiment of the present application abandons the traditional efuse hardware dependence and adopts a secure smart card to build a SecureBoot mechanism. When the IoT device is started, a dynamic verification process based on the public-private key pair and the firmware hash value ensures that the loaded firmware has not been tampered with.

[0074] By abandoning the traditional efuse hardware dependency, the embodiment of the present application uses a secure smart card to build a SecureBoot mechanism. When the IoT device is started, a dynamic verification process based on the public-private key pair and the firmware hash value ensures that the loaded firmware has not been tampered with. Whether facing malware attempting to implant code during the startup phase or firmware damage caused by unexpected factors, it can be accurately identified and effectively prevent the device from being attacked from the startup source.

[0075] Compared with the traditional static SecureBoot verification method, the embodiment of the present application introduces dynamic IoT device identity authentication and security audit functions. Every time an IoT device is started, the secure smart card not only verifies the integrity of the firmware, but also verifies the device identifier to ensure that only legally authorized devices can be started, effectively preventing access to illegal devices. In addition, once the verification fails, the secure smart card can immediately record the relevant security events in the audit log, providing a strong basis for subsequent troubleshooting and security analysis, which is the active defense and post-event tracing capabilities lacking in traditional technologies.

[0076] In addition, the instant recording of security events in the audit log in the embodiment of the present application provides clear clues for accident tracing for operation and maintenance personnel. Once an abnormal device startup occurs, the root cause of the problem can be quickly located through the audit log, whether it is firmware tampering, device identity theft or other reasons. At the same time, long-term analysis of audit data can also discover potential security trends and provide early warning of possible large-scale security incidents.

[0077] Based on any of the above embodiments, in Embodiment 3 of the present application, the same or similar contents as any of the above embodiments can be referred to the above description, and will not be repeated in the following. On this basis, the first operating system is a security-enhanced Linux system, and the biometric identification of the target user who issues the target access request through the security smart card includes steps S4113~S4118: Step S4113, receiving a request from the target user to access a highly sensitive object; It should be noted that, for the security-enhanced Linux system, the embodiment of the present application formulates a corresponding security policy for the security-enhanced Linux system.

[0078] Among them, new rules related to biometric authentication are added to the SELinux policy file for highly sensitive protection objects in IoT devices, such as sensitive data files, key system processes, etc. These rules stipulate that access to the corresponding highly sensitive objects is allowed only when the user passes the biometric authentication of a secure smart card and the verification result matches the pre-stored biometric template.

[0079] For example, for a medical IoT device, the file storing patient privacy data is defined as a highly sensitive object. The SELinux policy stipulates that only medical staff who have passed the biometric authentication of a secure smart card can access the file in read-only mode to prevent data leakage.

[0080] Reference Figure 4 , Figure 4 A schematic diagram of the process of biometric identification for the security control method of this application, in Figure 4 In the security environment, when a user tries to access a highly sensitive object, SELinux first detects and receives the access request and sends a biometric authentication request to the secure smart card. The request contains relevant information about the access request (such as the access object identifier, access type, etc.).

[0081] Step S4114, activating a biometric identification module through the secure smart card; Step S4115, collecting the biometric information of the target user through the biometric identification module; Step S4116, comparing the biometric information with a pre-stored biometric template via the secure smart card; Among them, the security smart card activates the biometric identification module, collects the user's current biometric information, and compares it with the pre-stored biometric template.

[0082] Step S4117: if the comparison is successful, the target user is allowed to access the highly sensitive object according to a preset access control rule through the security-enhanced Linux system; If the comparison is successful, the security smart card returns a signal of authentication success to SELinux, and SELinux allows the user to access the highly sensitive object according to normal access control rules.

[0083] Step S4118: If the comparison fails, the access request of the target user is rejected through the security-enhanced Linux system, and the relevant security events are recorded in the security audit log of the secure smart card.

[0084] If the comparison fails, the security smart card returns an authentication failure signal to SELinux, and SELinux denies the user's access request and records the relevant security events in the smart card's audit log for subsequent tracking and analysis.

[0085] In the past, SELinux mainly relied on conventional user authentication methods, such as username-password combinations, to control access to system resources. However, this approach is prone to security risks such as password cracking and impersonation when facing highly sensitive objects. This application embodiment integrates biometric authentication technology into the SELinux policy system, and implements user identity authentication by building a high-precision biometric identification module, such as fingerprint recognition or iris recognition sensor, into a secure smart card. Only when the user passes the biometric identification of the smart card and the biometric features match the template pre-stored in the card, is access to highly sensitive objects allowed, which improves the security and accuracy of authentication.

[0086] In addition, traditional SELinux policies are relatively fixed during device operation and are difficult to flexibly adjust according to real-time security needs. The embodiment of the present application gives SELinux policies the ability to dynamically adapt, and with the help of the storage and computing functions of the security smart card, the diversified and customized access policy rules are stored in the security smart card in advance. During the operation of the IoT device, according to different access scenarios and user behaviors, the security smart card can provide SELinux with adaptive policies in real time to ensure effective response to complex and changing security threats. This is a dynamic protection advantage that traditional SELinux cannot achieve.

[0087] Among them, relying on the ability of secure smart cards to store and distribute policies, SELinux policies can be dynamically adapted according to the real-time operating status of the device and user behavior. In multi-user, multi-task IoT scenarios, different users have different requirements for system resources. The policies provided by smart cards in real time can not only protect highly sensitive resources from illegal access, but also flexibly allocate ordinary resources, improve the overall operating efficiency of the system, and avoid the impact of overly strict or loose access control on device performance.

[0088] Based on any of the above embodiments, in the fourth embodiment of the present application, the same or similar contents as any of the above embodiments can refer to the above introduction, and will not be repeated later. On this basis, step S4113, before receiving the request of the target user to access the highly sensitive object, the security control method also includes steps S4111~S4112: Step S4111, receiving a biometric registration request of the target user through the biometric identification module, and obtaining the biometric template; Step S4112: storing the biometric template in a secure storage area of ​​the secure smart card.

[0089] Among them, the secure smart card has a built-in biometric identification module, such as a fingerprint recognition sensor or a high-precision iris recognition module (selected according to the application scenario and cost requirements). These modules have advanced biometric collection and preprocessing functions, and can quickly and accurately collect users' biometric information.

[0090] Before the device is operated, the user needs to register the biometrics on the biometric identification module of the secure smart card and store the biometric template (such as fingerprint template or iris template) in the secure storage area of ​​the secure smart card. This area is similar to the key storage area and uses multi-layer encryption protection to ensure the security of the biometric template.

[0091] Integrate biometric authentication technology into the SELinux policy system, and use the built-in biometric module of the secure smart card to verify the user's identity. Compared with the traditional username-password method, biometric features such as fingerprints and irises are unique and non-replicable, which reduces the risk of identity fraud and ensures that only legally authorized users can access highly sensitive data, such as patient privacy information in the medical Internet of Things and transaction data in the financial Internet of Things, thereby improving the confidentiality of highly sensitive data.

[0092] Based on any of the above embodiments, in Embodiment 5 of the present application, the same or similar contents as any of the above embodiments can refer to the above introduction and will not be repeated later. On this basis, the second operating system is a real-time operating system, and the secondary authorization of the target access request based on the secure smart card includes steps S4121~S4124: Step S4121, when receiving an access request to the sensitive area memory, a preliminary review is performed by the memory protection unit of the real-time operating system according to a preset memory access control rule; In the low-cost real-time operating system RTOS system, a special driver is developed to achieve a close connection between the secure smart card and the real-time operating system RTOS. This driver provides a series of APIs (application programming interfaces) for RTOS to send memory access requests to the secure smart card and receive authorization results from the secure smart card. Figure 3 , Figure 3 This is a schematic diagram of the structure of the IoT device for this application. Figure 3 In the present invention, the real-time operating system is the main operating system, and the real-time operating system can receive the authorization result of the security smart card through the driver.

[0093] The driver defines the function SendMemoryAccessRequest(address, size,access_type), where address indicates the memory address requested for access, size indicates the size of the memory area requested for access, and access_type indicates the access type (such as read, write, execute, etc.). At the same time, the function ReceiveAuthorizationResult() is defined to receive the authorization result returned by the smart card.

[0094] It should be noted that when an application initiates an access request to sensitive memory in the RTOS system, the RTOS MPU will first conduct a preliminary review according to the conventional memory access control rules. If the preliminary review is passed, it means that the access request initially meets the memory protection requirements at the RTOS level.

[0095] Step S4122, if the preliminary review is passed, a secondary review is performed through the secure smart card according to a preset memory access authorization policy; Next, the RTOS sends a memory access request to the secure smart card through the driver. After the secure smart card receives the request, it performs a secondary review based on the memory access authorization policy pre-stored in the card.

[0096] Among them, the memory access authorization policy can be customized according to the functions and security requirements of the device. For example, for some key system variable storage areas, only specific system processes can access them at specific running stages.

[0097] Step S4123: if the secondary review is passed, the access request to the sensitive area memory is allowed through the real-time operating system; Step S4124: If the secondary audit fails, the access request to the sensitive area memory is rejected by the real-time operating system, and the relevant security event is recorded in the security audit log of the secure smart card.

[0098] After the smart card audit is completed, the driver returns the authorization result to the RTOS. If the authorization result is passed, the RTOS allows the application to perform the final memory access; otherwise, the RTOS denies the application's access request and can choose to record related security events in the smart card audit log for subsequent analysis.

[0099] In low-cost RTOS systems, traditional memory protection mechanisms rely only on the MPU for a single level of access control, which is somewhat weak for preventing complex illegal memory access behaviors. The embodiment of the present application introduces a secondary authorization mechanism for the secure smart card to access the MPU. When an application initiates an access request to the memory in a sensitive area, the MPU first performs a preliminary compliance review. After passing, the RTOS uses a specially developed driver to send a detailed memory access request to the secure smart card. The smart card conducts a secondary in-depth review of the request based on the pre-customized memory access authorization policy, comprehensively considering multi-dimensional factors such as the time, process, and memory area of ​​the access. Only after the secondary review is passed, the final memory access is allowed, thereby enhancing the reliability of memory protection.

[0100] In addition, unlike the isolated memory protection mode of traditional technology, the embodiment of this application emphasizes the close driver collaboration between the secure smart card and the RTOS. Through a specially designed driver, the smart card and the RTOS are interconnected, and a series of API functions such as sending memory access requests and receiving authorization results are defined, realizing efficient and secure interaction between the two. This driver collaboration mode ensures that the secondary authorization mechanism can run smoothly, making the secure smart card and the MPU form an organic whole.

[0101] In addition, the secondary authorization mechanism for MPU access by the secure smart card introduced in the low-cost RTOS system improves the security of memory data. The initial compliance audit of the MPU is combined with the secondary in-depth audit of the smart card, and multi-dimensional factors are comprehensively considered, from simply preventing memory cross-border access to comprehensively preventing all kinds of complex illegal memory operations, including malicious programs using memory vulnerabilities to execute code and steal data, which significantly enhances the integrity and confidentiality of memory data.

[0102] In addition, the driver realizes close collaboration between the secure smart card and RTOS, and promotes interaction with simple API functions. This collaborative mode makes the secondary authorization mechanism run smoothly, reduces security vulnerabilities caused by poor communication, incompatible interfaces, etc., and reduces the difficulty for developers to integrate secure smart cards with RTOS.

[0103] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the safety control method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0104] This application also provides a safety control device, please refer to Figure 5 , which is arranged in an Internet of Things device, wherein the Internet of Things device includes a secure smart card, and the security control device includes: The request receiving module 10 is used to receive a target access request; obtain the operating system type of the IoT device; The request control module 20 is used to perform biometric identification of the target user who issues the target access request through the secure smart card if the operating system type of the IoT device is the first operating system; and to perform secondary authorization of the target access request based on the secure smart card if the operating system type of the IoT device is the second operating system.

[0105] The security control device provided by the present application adopts the security control method in the above embodiment, which can solve the technical problem that the security of the Internet of Things devices is not high. Compared with the prior art, the beneficial effects of the security control device provided by the present application are the same as the beneficial effects of the security control method provided by the above embodiment, and the other technical features in the security control device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0106] The present application provides a security control device, which includes: at least one processor; and a memory that is communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the security control method in the above-mentioned embodiment one.

[0107] Reference below Figure 6 , which shows a schematic diagram of the structure of a safety control device suitable for implementing the embodiment of the present application. The safety control device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (tablet computers), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The safety control device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0108] like Figure 6As shown, the security control device may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1002 or the program loaded from the storage device 1003 to the random access memory 1004. In the random access memory 1004, various programs and data required for the operation of the xxx device are also stored. The processing device 1001, the read-only memory 1002 and the random access memory 1004 are connected to each other through a bus 1005. The input / output interface 1006 is also connected to the bus. Generally, the following systems can be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the security control device to communicate with other devices wirelessly or wired to exchange data. Although the drawings show a safety control device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0109] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0110] The security control device provided by the present application adopts the security control method in the above embodiment, which can solve the technical problem that the security of the Internet of Things device is not high. Compared with the prior art, the beneficial effects of the security control device provided by the present application are the same as the beneficial effects of the security control method provided by the above embodiment, and the other technical features in the security control device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0111] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0112] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0113] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the security control method in the above-mentioned embodiment.

[0114] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0115] The computer-readable storage medium may be included in the safety control device; or may exist independently without being assembled into the safety control device.

[0116] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the security control device, the security control device: receives a target access request; obtains the operating system type of the Internet of Things device; if the operating system type of the Internet of Things device is the first operating system, performs biometric identification of the target user who issues the target access request through the security smart card; if the operating system type of the Internet of Things device is the second operating system, performs secondary authorization on the target access request based on the security smart card.

[0117] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0118] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0119] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0120] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned security control method, and can solve the technical problem that the security of IoT devices is not high. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the security control method provided in the above-mentioned embodiment, and will not be elaborated here.

[0121] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A safety control method, characterized in that: Applied to an Internet of Things device, the Internet of Things device includes a secure smart card, and the method includes the following steps: receiving a target access request; Obtaining the operating system type of the IoT device; If the operating system type of the IoT device is the first operating system, performing biometric identification of the target user who issues the target access request through the secure smart card; If the operating system type of the Internet of Things device is the second operating system, a secondary authorization is performed on the target access request based on the secure smart card.

2. The method according to claim 1, characterized in that The step of receiving a target access request includes: Performing security verification on the IoT device; If the IoT device passes the security verification, the step of receiving a target access request is executed.

3. The method according to claim 2, characterized in that The step of performing security verification on the IoT device comprises: Initialize the IoT device and generate a public key, a private key, and a symmetric key through the secure smart card; Storing the private key and the symmetric key in a secure storage area via the secure smart card; Compiling the firmware of the IoT device; Calculating a hash value of the firmware; Signing the hash value of the firmware using the secure smart card based on a pre-generated private key to generate a signature value; Storing the signature value and the hash value of the firmware in a firmware storage area; When the IoT device is started, the firmware is loaded, and the signature value is extracted from the firmware storage area; Obtaining a device identifier of the IoT device; Verifying, by the secure smart card, whether the device identifier matches a list of authorized devices pre-stored in the secure smart card; If the match is successful, verifying the signature value based on the public key through the secure smart card; If the verification is passed, the IoT device passes the security verification; If the verification fails, the IoT device fails the security verification, the IoT device is prevented from starting, and the relevant security events are recorded in the security audit log of the secure smart card.

4. The method according to claim 1, characterized in that The first operating system is a security-enhanced Linux system, and the step of performing biometric identification of a target user who issues the target access request through the security smart card comprises: Receiving a request from the target user to access a highly sensitive object; activating a biometric identification module through the secure smart card; Collecting the biometric information of the target user through the biometric identification module; comparing the biometric information with a pre-stored biometric template via the secure smart card; If the comparison is successful, the target user is allowed to access the highly sensitive object according to the preset access control rules through the security-enhanced Linux system; If the comparison fails, the access request of the target user is rejected through the security-enhanced Linux system, and the relevant security events are recorded in the security audit log of the secure smart card.

5. The method according to claim 4, characterized in that The step of receiving a request from the target user to access a highly sensitive object includes: Receiving a biometric registration request of the target user through the biometric identification module to obtain the biometric template; The biometric template is stored in a secure storage area of ​​the secure smart card.

6. The method according to claim 1, characterized in that The second operating system is a real-time operating system, and the step of performing secondary authorization on the target access request based on the secure smart card includes: Performing a preliminary review of the target access request according to a preset memory access control rule through a memory protection unit of the real-time operating system; If the preliminary review is passed, the target access request is subject to a secondary review by the secure smart card according to a preset memory access authorization policy; If the secondary review is passed, the target access request is accepted through the real-time operating system; If the secondary audit fails, the target access request is rejected by the real-time operating system, and the relevant security event is recorded in the security audit log of the secure smart card.

7. A safety control device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the safety control method according to any one of claims 1 to 6.

8. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the safety control method according to any one of claims 1 to 6 are implemented.

Images