Autonomous and controllable JAVA card communication method and system and storage medium

Abstract

The invention provides an autonomous and controllable JAVA card communication method and system and a storage medium, and relates to the technical field of information security, and the method comprises the steps: carrying out the mode division and authority limitation of an NVM, and obtaining a super user mode and a user mode; the method comprises the following steps: developing a control OS (Operating System) at a first user side in a super user mode, which comprises a preset API (Application Program Interface) constraint; downloading the management and control OS and switching to the user mode at the second user side; in the user mode, based on a preset API interface constraint, a function application of the JAVA card is developed, and a COS is generated; and downloading the COS to the card to complete the function realization of the JAVA card. According to the method and the device, the technical problem that a client faces a security risk when delivering a core technology to a card provider due to the fact that the card provider has an unlimited access capability in the debugging and development process because a development mode in the prior art does not perform hierarchical control on the authority is solved.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to an autonomous and controllable JAVA card communication method, system and storage medium. Background Art

[0002] When an industry customer develops a customized product, the customer needs to provide the card dealer with a customized algorithm library or interface, and the card dealer will then develop according to the technical documents provided by the card dealer. The card dealer is a platform developer and has administrator privileges during development and debugging. It can access any data in the chip, such as reading the algorithm library data provided by the customer, and then decompiling the code in the algorithm library by disassembling it, so as to obtain the customer's customized algorithm and interface implementation principle. In addition, before the JAVA card leaves the factory, the customer needs to provide the card dealer with relevant sensitive data and key information, and the card dealer will store it in the JAVA card. These are all risks for customers. At present, the card dealer mainly adopts the static link lib library to provide it to the card dealer. The card dealer loads the algorithm lib library into the development platform to participate in the compilation and complete the java card function development. In the existing technology, once the lib library is obtained, the internal functions can be accessed or even decompiled. Once the customer's core business algorithm is leaked, it will cause irreparable damage. Summary of the invention

[0003] This application provides an autonomous and controllable JAVA card communication method, system and storage medium, aiming to solve the technical problem that the development model of the existing technology does not have hierarchical control over permissions, allowing card dealers to have unrestricted access during debugging and development, resulting in customers facing security risks when delivering core technologies to card dealers.

[0004] The first aspect disclosed in the present application provides an autonomous and controllable JAVA card communication method, the method comprising: dividing NVM into modes and restricting permissions to obtain super user mode and user mode; at a first user end, developing a control OS in the super user mode, which includes preset API interface constraints; at a second user end, downloading the control OS and switching to the user mode; at the user mode, developing JAVA card function applications based on the preset API interface constraints to generate COS; downloading the COS to the card to complete the JAVA card function implementation.

[0005] The second aspect disclosed in the present application provides an autonomous and controllable JAVA card communication system, which is used for the above-mentioned autonomous and controllable JAVA card communication method, and the system includes: a mode division module, which is used to divide the NVM into modes and limit permissions to obtain super user mode and user mode; a first development module, which is used to develop a control OS in the super user mode at a first user end, including preset API interface constraints; a mode switching module, which is used to download the control OS and switch to the user mode at a second user end; a second development module, which is used to develop JAVA card function applications and generate COS based on the preset API interface constraints in the user mode; a download module, which is used to download the COS to the card to complete the JAVA card function implementation.

[0006] According to a third aspect disclosed in the present application, a storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, any step of the first aspect disclosed in the present application is implemented.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0008] By dividing the NVM area into modes, the scope of authority of the superuser mode and user mode is clarified. The superuser mode focuses on the management of the underlying functions and sensitive data of the chip, while the user mode only allows access to some open APIs. This division of authority ensures that even during development or use, it is impossible to unauthorize access to core data or functions; developing a control OS in the superuser mode ensures that developers have independent control over the sensitive data protection mechanism. The control OS provides preset API interface constraints so that card vendors can only call authorized APIs, avoiding the possibility of direct access to the underlying hardware or sensitive data, and preventing malicious or misoperation from threatening the security of the system; card vendors download the management OS on the second user end, and the management OS can be used to control the development of the core data or functions. Control OS and switch to user mode to ensure that the subsequent development work of the card dealer is limited to the controlled user mode. In user mode, the card dealer develops JAVA card function applications based on some open APIs provided by the controlled OS. The restrictions of user mode ensure that the card dealer cannot access core data or underlying hardware, but can still develop applications under API constraints. This design effectively balances the needs of security and functional expansion; the functional applications developed by the card dealer are downloaded to the card to complete the final function implementation. The whole process ensures that COS development and deployment are carried out in a controlled environment, and user sensitive data and system security are not damaged. This controlled deployment method makes the final delivered JAVA card both secure and customized.

[0009] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A flowchart of an autonomous and controllable JAVA card communication method provided in an embodiment of the present application.

[0011] Figure 2 A schematic diagram of the structure of an autonomous and controllable JAVA card communication system provided in an embodiment of the present application.

[0012] Description of reference numerals: mode division module 10 , first development module 20 , mode switching module 30 , second development module 40 , download module 50 . DETAILED DESCRIPTION

[0013] The embodiments of the present application provide an autonomous and controllable JAVA card communication method, system and storage medium, which solves the technical problem that the development model of the prior art does not have hierarchical control over permissions, allowing card dealers to have unrestricted access capabilities during debugging and development, causing customers to face security risks when delivering core technologies to card dealers.

[0014] After introducing the basic principles of the present application, various non-limiting implementation methods of the present application will be specifically introduced below in conjunction with the accompanying drawings of the specification. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0015] Embodiment 1, as Figure 1 As shown, the embodiment of the present application provides an autonomous and controllable JAVA card communication method, the method comprising:

[0016] The NVM is divided into modes and permission restricted to obtain the super user mode and user mode.

[0017] The chip's NVM (non-volatile memory) is divided into two main access modes, namely supervisor mode and user mode. This division is for security and data protection. Supervisor mode has full control over the system, including access to the underlying API of the chip, while user mode is limited to accessing specific, public APIs. Specifically, different permission levels are set to protect sensitive data and system functions from unauthorized access. Supervisor mode has higher permissions and can perform system settings, debugging, and privileged operations, while user mode is limited to basic, open application operations.

[0018] At the first user end, a management and control OS is developed in the super user mode, which includes preset API interface constraints.

[0019] The first user end is specifically the industry client. Industry customers develop the operating system (OS) in super user mode, which means that industry customers can use super user privileges to integrate deeper security and management functions. The operating system is mainly responsible for managing and monitoring the behavior of JAVA cards to ensure security and data protection. The API interfaces implemented in the operating system include high-privilege APIs and low-privilege APIs. The high-privilege API provides support for underlying and sensitive operations, while the low-privilege API provides services for ordinary applications. The preset API interface constraints support various applications to correctly and securely access appropriate system resources and functions, and prevent sensitive operations from being called by unauthorized users.

[0020] On the second user terminal, the control OS is downloaded and switched to the user mode.

[0021] The second user end is the card merchant end. The card merchant needs to develop JAVA cards according to the technical documents provided by industry customers. The card merchant downloads the developed control OS to the target JAVA card. This process is usually carried out during the card manufacturing or personalization stage to ensure that each card is correctly configured for subsequent operations. After the download is completed, the system switches from super user mode to user mode. This transition is critical because it limits subsequent operations to user mode permissions. This is done to ensure that only non-privileged operations can be performed during card debugging.

[0022] In the user mode, based on the preset API interface constraints, the functional application of the JAVA card is developed to generate COS.

[0023] Card vendors work in user mode and develop JAVA card applications based on preset API interface constraints. These applications may include payment, identity authentication and other functions. The developed applications are integrated into the JAVA card operating system, called COS, or card operating system. This step ensures that the debugging of all applications meets security requirements.

[0024] The COS is downloaded to the card to complete the JAVA card function implementation.

[0025] Downloading COS to the card is done at the final stage of card personalization. The successful download and startup of COS indicates that the JAVA card is fully configured, has all the functions and applications required, and can be delivered to the end user. The entire process, from the development of the operating system to the final realization of the card function, involves a high degree of security control and sophisticated authority management, which supports the JAVA card to meet both functional requirements and security standards.

[0026] Furthermore, NVM is divided into modes and restricted in permissions to obtain super user mode and user mode, including:

[0027] Generate super user rights for the super user mode, wherein the super user rights include rights to access the chip and control the underlying API of the chip; generate user rights for the user mode, wherein the user rights only include rights to access some open APIs.

[0028] Configure permissions for the superuser mode, which allow access to all functions of the chip, including full control of the underlying hardware and underlying APIs. The generated superuser permissions mean that operations such as firmware updates, security configurations, and system-level debugging can be performed. The permissions in superuser mode are not limited to advanced operating system functions, but also include the ability to directly access the underlying hardware of the chip, such as directly managing memory, adjusting processor speed, and configuring hardware interfaces.

[0029] User mode permissions are restricted to protect the system from unauthorized access or operation hazards. The generated user permissions are mainly for the safe operation of functions and do not include access to the core or sensitive parts of the system. Specifically, permissions in user mode only include access to APIs that are exposed for routine operations. These APIs involve user data processing, application logic execution, etc., but do not involve sensitive operations of the underlying system. The purpose of this is to ensure that even when the user mode is maliciously exploited, attackers cannot reach the core of the system.

[0030] This distinction in permissions is intended to achieve a hierarchical security structure for the operating system, ensuring that the core of the system remains secure even when faced with security threats. The division of permissions between superuser mode and user mode helps to fundamentally control access levels and permissions and prevent potential security risks.

[0031] Furthermore, it also includes:

[0032] Based on the super user authority and the user authority, the NVM area is divided into areas to obtain a super user area and a user area; wherein the super user area is controlled by the super user mode, and the user area is controlled by the user mode.

[0033] The NVM area is divided into two independent logical areas, namely the superuser area and the user area. The division is based on superuser permissions and user permissions, so that the storage area corresponds to the access rights of the corresponding mode. Among them, the superuser area is allocated to the superuser mode with high permissions, which is used to store sensitive data, underlying control functions and key components of the operating system, such as core algorithms, hardware access codes, etc. This area is completely controlled by the superuser mode and other modes have no access; the user area is allocated to the user mode with low permissions, which is used to store ordinary application data and open function modules, such as application logic, partial API implementation, etc. This area is accessed and controlled by the user mode, which restricts the user mode to operate only these non-sensitive data and functions to avoid the leakage of core data. When different modes access, the system automatically identifies and restricts the access area according to the permissions.

[0034] Furthermore, the control OS is stored in the super user area and can only be accessed in the super user mode.

[0035] The control OS is the core component of the system. It is stored in the super user area and can only be loaded and run in super user mode. Even if malicious code attempts to access the super user area in user mode, this design ensures the high security of the control OS. Even if the card is controlled by an unauthorized user, it cannot threaten the core functions.

[0036] Furthermore, the method of developing and controlling the OS in the super user mode, including presetting API interface constraints, includes:

[0037] The MPU mechanism of the chip is utilized to classify access rights of the API interface to generate a high-authority API and a low-authority API, wherein the high-authority API includes the underlying API and the low-authority API includes the partially open API; based on the high-authority API and the low-authority API, the preset API interface constraints are generated.

[0038] MPU (Memory Protection Unit) is a hardware function used to perform fine-grained control over storage areas and access rights. Through MPU, the access rights of API interfaces are strictly divided to ensure that users with different permission levels can only access the corresponding APIs. Specifically, according to the functions and sensitivity of the APIs, they are divided into high-privilege APIs and low-privilege APIs. Among them, high-privilege APIs include underlying hardware operations and core functions, such as direct operation of chip registers, encryption algorithm implementation, sensitive data access, etc. These APIs can only be called by super user mode; low-privilege APIs include some open functional interfaces, such as ordinary data reading and writing, user function calls, etc. These APIs allow user mode calls. Through the hardware isolation mechanism of MPU, user mode is prevented from accessing high-privilege APIs.

[0039] Generate preset API interface constraints based on high-privilege APIs and low-privilege APIs. API interface constraints are designed to clarify the permission level of each API and prevent unauthorized access. For example, in user mode, callers can only access pre-opened APIs and cannot access underlying or sensitive APIs.

[0040] Furthermore, the developing and controlling OS in the super user mode further includes:

[0041] Acquire sensitive data, core business algorithms, and underlying chip functions; encrypt the sensitive data and store them in the super user area, and generate sensitive data protection in combination with the access control permission verification mechanism, wherein the access control permission verification mechanism includes setting an access whitelist and / or a dynamic verification token; encrypt the core business algorithm and store it in the super user area, and generate core business algorithm protection in combination with the isolation mechanism of the trusted execution environment; set underlying function access rules for the underlying chip functions through the access control list mechanism.

[0042] Sensitive data includes but is not limited to identity authentication data, payment information, etc., input data from the user side, used for core operations such as security authentication and identity verification; core business algorithms include user-defined algorithms, such as encryption algorithms, verification algorithms or other proprietary business logic. These algorithms belong to the customer's core intellectual property and require high security protection; chip underlying functions are low-level operation functions that directly interact with chip hardware, such as register reading and writing, hardware encryption module calls, etc. These underlying functions directly control the chip hardware and are highly sensitive resources.

[0043] Sensitive data is encrypted using an encryption algorithm, such as symmetric encryption (such as AES-256) or asymmetric encryption (such as RSA or ECC). The encryption key itself needs to be securely stored and can be stored in a secure storage area of ​​the chip, such as a supervisor area. All sensitive data is encrypted and stored in the supervisor area of ​​the chip, which can only be accessed by the supervisor mode and cannot be read in the user mode.

[0044] Combined with the access control permission verification mechanism, including setting up an access whitelist and / or a dynamic verification token, where setting up an access whitelist means defining a group of trusted users or applications in the system, namely, an access whitelist, and only users or programs in the whitelist can access sensitive data; or, each time sensitive data is accessed, a dynamic token is generated, which requires verification before access, and the dynamic token can be based on a timestamp or other dynamic generation methods. By generating sensitive data protection through this step, sensitive data can be effectively protected, allowing the system to maintain autonomous and controllable capabilities while ensuring security.

[0045] Similar to sensitive data, the core business algorithm is encrypted using an encryption algorithm and stored in the super user area. Combined with the trusted execution environment, it ensures that the core business algorithm runs in an isolated environment and the running process is fully protected. Specifically, the trusted execution environment is a security isolation mechanism within the chip, which is used to execute sensitive code and data, and restrict the core business algorithm to run only in the trusted execution environment to prevent it from being exposed in a normal environment. During operation, the memory data is isolated and cannot be read by debugging tools or malware. When the core business algorithm needs to be called, the encrypted algorithm code is decrypted and loaded into the trusted execution environment. After execution, the memory data is immediately cleared to prevent residual information leakage.

[0046] The access control list mechanism is a set of rules that define access rights to the underlying functions of the chip, including which users, processes or modes can call the underlying functions. Specifically, a set of access rights rules are attached to each underlying function, including the caller's authentication (such as whether it is super user mode), calling conditions (such as time window, operation context), data access scope (such as memory address, function parameter range), and immutable access rights for certain functions are pre-defined during the system design phase. For example, only super user mode can call the chip initialization function, and user mode can only call some open APIs. The access control list mechanism effectively restricts access to the underlying functions of the chip, ensuring that unauthorized access cannot reach sensitive operations, thereby improving the security of the underlying functions of the chip.

[0047] Furthermore, the isolation mechanism combined with the trusted execution environment generates core business algorithm protection, including:

[0048] Through the scheduling mechanism of the control OS, the core business algorithm is restricted to run only in the super user area, and the memory content is protected by the isolation mechanism of the trusted execution environment during the operation; before and after the execution of the core business algorithm, the control OS verifies the integrity of the input and output data.

[0049] By setting scheduling rules through the control OS, the core business algorithm is restricted to be executed only in the super user area. The super user area is an isolated area with the highest permissions in the chip. Its storage and operating environment are strictly protected by hardware and software. This also means that the core business algorithm can only run when the super user mode is activated. If you try to call the algorithm in user mode, the control OS will refuse the operation.

[0050] When the core business algorithm is running, the trusted execution environment in the chip is used for isolation and protection. The trusted execution environment is a hardware-supported security area that can protect the memory data of the algorithm from being read or modified externally during runtime. The specific protection process is as follows: the code and data of the core business algorithm are loaded into the trusted execution environment memory area. During the execution of the algorithm, all intermediate data and operation results are protected by the hardware isolation of the trusted execution environment. After the execution is completed, TEE automatically cleans up its memory to ensure that the data will not be leaked.

[0051] Before the core business algorithm is executed, the purpose of integrity verification is to prevent malicious tampering or injection of erroneous data, and to ensure that the input data for algorithm execution is credible. Methods include data verification, permission check, whitelist matching, dynamic token verification, etc. After the core business algorithm is executed, the purpose of integrity verification is to ensure that the running results of the core business algorithm have not been maliciously tampered with or damaged. Methods include result verification, access permission verification, encryption protection, logging, etc. This dynamic verification mechanism and encryption protection further improve the security of the calling process.

[0052] Furthermore, in the user mode, based on the preset API interface constraints, the method for developing the functional application of the JAVA card includes:

[0053] In the user mode, based on the preset API interface constraints, the partially open API of the low-authority API is called; when the partially open API is verified, the functional application of the JAVA card is developed based on the partially open API.

[0054] User mode is a mode with restricted permissions. Card dealers can only access some open APIs and cannot directly access the chip's underlying hardware and high-privilege APIs. The preset API interface constraint rules defined in advance by the control OS limit the user mode to calling low-privilege APIs. In user mode, card dealers call low-privilege APIs through the interfaces provided by the control OS. Low-privilege APIs are open interfaces for function development. They allow operations but are restricted by predefined rules. In addition, the called low-privilege APIs can only perform ordinary functions, such as data reading and writing, logical operations, etc., and cannot touch core security data or underlying functions.

[0055] When calling, strict verification is carried out, including permission check and API rule matching. After verification, card merchants can develop functions based on the low-privilege API called, such as payment function development, identity authentication function development, data management function development, etc. Specifically, use standard JAVA card development tools and frameworks to call low-privilege APIs to implement specific functional logic, and the developed functional modules are eventually encapsulated as part of COS. Among them, during the development process, low-privilege API calls are always protected by the control OS to prevent malicious calls or illegal operations.

[0056] Through the above steps, in user mode, card vendors can implement the functional applications of JAVA cards safely and flexibly based on some open APIs, while ensuring the security and stability of the core system.

[0057] In summary, the autonomous and controllable JAVA card communication method provided by the embodiment of the present application has the following technical effects:

[0058] By dividing the NVM area into modes, the scope of authority of the superuser mode and user mode is clarified. The superuser mode focuses on the management of the underlying functions and sensitive data of the chip, while the user mode only allows access to some open APIs. This division of authority ensures that even during development or use, it is impossible to unauthorize access to core data or functions; developing a control OS in the superuser mode ensures that developers have independent control over the sensitive data protection mechanism. The control OS provides preset API interface constraints so that card vendors can only call authorized APIs, avoiding the possibility of direct access to the underlying hardware or sensitive data, and preventing malicious or misoperation from threatening the security of the system; card vendors download the management OS on the second user end, and the management OS can be used to control the development of the core data or functions. Control OS and switch to user mode to ensure that the subsequent development work of the card dealer is limited to the controlled user mode. In user mode, the card dealer develops JAVA card function applications based on some open APIs provided by the controlled OS. The restrictions of user mode ensure that the card dealer cannot access core data or underlying hardware, but can still develop applications under API constraints. This design effectively balances the needs of security and functional expansion; the functional applications developed by the card dealer are downloaded to the card to complete the final function implementation. The whole process ensures that COS development and deployment are carried out in a controlled environment, and user sensitive data and system security are not damaged. This controlled deployment method makes the final delivered JAVA card both secure and customized.

[0059] Embodiment 2 is based on the same inventive concept as the autonomous and controllable JAVA card communication method in the above embodiment. Figure 2 As shown, the embodiment of the present application provides an autonomous and controllable JAVA card communication system, the system comprising:

[0060] The mode division module 10 is used to divide the NVM into modes and restrict permissions to obtain the super user mode and the user mode; the first development module 20 is used to develop the control OS in the super user mode at the first user end, which includes the preset API interface constraints; the mode switching module 30 is used to download the control OS and switch to the user mode at the second user end; the second development module 40 is used to develop the functional application of the JAVA card based on the preset API interface constraints in the user mode and generate the COS; the download module 50 is used to download the COS to the card to complete the JAVA card function implementation.

[0061] Furthermore, the mode division module 10 includes the following operation steps:

[0062] Generate super user rights for the super user mode, wherein the super user rights include rights to access the chip and control the underlying API of the chip; generate user rights for the user mode, wherein the user rights only include rights to access some open APIs.

[0063] Furthermore, the mode division module 10 further includes the following operation steps:

[0064] Based on the super user authority and the user authority, the NVM area is divided into areas to obtain a super user area and a user area; wherein the super user area is controlled by the super user mode, and the user area is controlled by the user mode.

[0065] Furthermore, the control OS is stored in the super user area and can only be accessed in the super user mode.

[0066] Furthermore, the first development module 20 includes the following operation steps:

[0067] The MPU mechanism of the chip is utilized to classify access rights of the API interface to generate a high-authority API and a low-authority API, wherein the high-authority API includes the underlying API and the low-authority API includes the partially open API; based on the high-authority API and the low-authority API, the preset API interface constraints are generated.

[0068] Furthermore, the first development module 20 further includes the following operation steps:

[0069] Acquire sensitive data, core business algorithms, and underlying chip functions; encrypt the sensitive data and store them in the super user area, and generate sensitive data protection in combination with the access control permission verification mechanism, wherein the access control permission verification mechanism includes setting an access whitelist and / or a dynamic verification token; encrypt the core business algorithm and store it in the super user area, and generate core business algorithm protection in combination with the isolation mechanism of the trusted execution environment; set underlying function access rules for the underlying chip functions through the access control list mechanism.

[0070] Furthermore, the first development module 20 further includes the following operation steps:

[0071] Through the scheduling mechanism of the control OS, the core business algorithm is restricted to run only in the super user area, and the memory content is protected by the isolation mechanism of the trusted execution environment during the operation; before and after the execution of the core business algorithm, the control OS verifies the integrity of the input and output data.

[0072] Furthermore, the second development module 40 further includes the following operation steps:

[0073] In the user mode, based on the preset API interface constraints, the partially open API of the low-authority API is called; when the partially open API is verified, the functional application of the JAVA card is developed based on the partially open API.

[0074] Through the above detailed description of an autonomous and controllable JAVA card communication method, those skilled in the art can clearly understand an autonomous and controllable JAVA card communication system in this embodiment. Since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0075] Embodiment 3 provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, any step of embodiment 1 is implemented.

[0076] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An autonomous and controllable JAVA card communication method, characterized in that: The method comprises: Divide NVM into different modes and restrict permissions to obtain super user mode and user mode; On the first user side, developing and controlling the OS in the super user mode, including presetting API interface constraints; On the second user terminal, download the control OS and switch to the user mode; In the user mode, based on the preset API interface constraints, a functional application of the JAVA card is developed to generate a COS; The COS is downloaded to the card to complete the JAVA card function implementation.

2. The autonomous and controllable JAVA card communication method as claimed in claim 1, characterized in that: Divide NVM into different modes and restrict permissions to obtain super user mode and user mode, including: Generating super user rights for the super user mode, wherein the super user rights include rights to access the chip and control the underlying API of the chip; Generate user rights for the user mode, wherein the user rights only include rights to access part of the open APIs.

3. An autonomous and controllable JAVA card communication method as claimed in claim 2, characterized in that: Also includes: Based on the super user authority and the user authority, the NVM area is divided into regions to obtain a super user area and a user area; The super user area is controlled by the super user mode, and the user area is controlled by the user mode.

4. The autonomous and controllable JAVA card communication method as claimed in claim 3, characterized in that: The control OS is stored in the super user area and can only be accessed in the super user mode.

5. The autonomous and controllable JAVA card communication method as claimed in claim 2, characterized in that: The method of developing and controlling the OS in the super user mode, including presetting API interface constraints, includes: Using the MPU mechanism of the chip, the API interface is graded for access rights, and a high-authority API and a low-authority API are generated, wherein the high-authority API includes the underlying API, and the low-authority API includes the partially open API; The preset API interface constraint is generated according to the high-authority API and the low-authority API.

6. An autonomous and controllable JAVA card communication method as claimed in claim 5, characterized in that: The developing and controlling OS in the super user mode further includes: Obtain sensitive data, core business algorithms, and underlying chip functions; Encrypting the sensitive data and storing it in the super user area, and generating sensitive data protection in combination with an access control authority verification mechanism, wherein the access control authority verification mechanism includes setting an access whitelist and / or a dynamic verification token; Encrypt the core business algorithm and store it in the super user area, and generate core business algorithm protection in combination with the isolation mechanism of the trusted execution environment; The underlying function access rules are set for the underlying functions of the chip through the access control list mechanism.

7. An autonomous and controllable JAVA card communication method as claimed in claim 6, characterized in that: The isolation mechanism combined with the trusted execution environment generates core business algorithm protection, including: By controlling the scheduling mechanism of the OS, the core business algorithm is restricted to run only in the super user area, and the memory content is protected by the isolation mechanism of the trusted execution environment during the operation; Before and after the execution of the core business algorithm, the control OS verifies the integrity of the input and output data.

8. The autonomous and controllable JAVA card communication method as claimed in claim 5, characterized in that: In the user mode, based on the preset API interface constraints, developing a functional application of the JAVA card, the method includes: In the user mode, based on the preset API interface constraint, calling the partially open API of the low-privilege API; After the partial open API is verified, the functional application development of the JAVA card is performed based on the partial open API.

9. An autonomous and controllable JAVA card communication system, characterized in that: A system for implementing an autonomous and controllable JAVA card communication method according to any one of claims 1 to 8, the system comprising: The mode division module is used to divide the NVM mode and restrict the permissions to obtain the super user mode and user mode; A first development module, used for developing a control OS in the super user mode at a first user end, including preset API interface constraints; A mode switching module, used for downloading the control OS and switching to the user mode at the second user end; The second development module is used to develop the functional application of the JAVA card and generate the COS based on the preset API interface constraint in the user mode; The download module is used to download the COS to the card to complete the JAVA card function implementation.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of an autonomous and controllable JAVA card communication method described in any one of claims 1 to 8 are implemented.

Images