Java card gp architecture implementation method and electronic device

Abstract

The embodiment of the application discloses a JAVA card GP architecture implementation method and electronic equipment. The method comprises the following steps: creating a main security domain class and an auxiliary security domain class in JAVA code; setting the main security domain class and the auxiliary security domain class to obtain a first setting result; setting domain objects of the main security domain and the auxiliary security domain in the JAVA code to obtain a second setting result; and implementing the first setting result and the second setting result in C code of a native method. Compared with the prior art, the JAVA card GP architecture implementation method and the electronic equipment provided by the embodiment of the application can perform various settings in JAVA, and implement the setting conditions in C code of a native method. That is, the embodiment of the application can not only reduce bugs by using the object mechanism of the java language, but also run the GP function in the native environment, improve the running performance of the program, and facilitate program debugging.

Description

Technical Field

[0001] This invention relates to the field of JAVA smart card COS design technology, specifically to a JAVA card GP architecture implementation method and electronic device. Background Technology

[0002] Java Card is an open standard developed by Sun Microsystems for smart card development platforms. Smart cards created using the Java Card platform contain Java applets. After the card is issued, applets can be added to the card or existing application applets on the card can be modified. They store data in an integrated microprocessor chip. The applet is then downloaded into the microprocessor's memory and executed by the Java Virtual Machine.

[0003] The Global Platform (GP) specification provides clear definitions for Java cards in areas such as application downloading, deletion, personalization, and card lifecycle management. However, the specification only outlines what the GP needs to do, without explaining how it should be implemented, such as how security domains are implemented and their security capabilities. Therefore, different card vendors have developed different GP architecture implementations tailored to the characteristics of their own Java card COS.

[0004] Currently, there are two main GP architectures:

[0005] The first type is the Java architecture, which includes command dispatch, security management, and card content management. These are all implemented using the Java language. During the pre-masking phase of Java COS, all these GP implementations are converted into bytecode. During the runtime phase of Java COS, these GP functionalities are implemented by running the Java bytecode.

[0006] The second approach is a pure native architecture, where all the functionalities of the aforementioned GP are implemented in C. During compilation, these GP functionalities are compiled into Java COS. At runtime, Java COS executes these functionalities by running the binary code.

[0007] Both of the above architectures have their own drawbacks:

[0008] The disadvantages of the first architecture are: slow Java bytecode execution speed, low efficiency, inconvenient tracing and debugging, and inconvenient patching when bugs occur;

[0009] The disadvantage of the second architecture is that the C language itself lacks an object mechanism, which makes it prone to memory buffer overflows and memory space vulnerabilities, etc. Summary of the Invention

[0010] In view of the technical defects mentioned in the background art, the purpose of this invention is to provide a GP architecture implementation method and electronic device for a JAVA card.

[0011] To achieve the above objectives, in a first aspect, embodiments of the present invention provide a method for implementing the GP architecture of a Java card, comprising:

[0012] In the Java code, create a primary security domain class and a secondary security domain class; both the primary security domain class and the secondary security domain class inherit from the applet class of javacard;

[0013] The primary security domain class and the secondary security domain class are configured to obtain the first configuration result;

[0014] In Java code, setting the domain objects of the primary security domain and the secondary security domain yields the second setting result;

[0015] Implement the first and second setting results in the C code of the native method.

[0016] As a specific implementation of this application, the main security domain class and the auxiliary security domain class are set as follows:

[0017] The select() and deselect() methods in the main security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods.

[0018] The select() and deselect() methods in the auxiliary security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods.

[0019] Furthermore, as a preferred implementation of this application, the setting of the main security domain class and the auxiliary security domain class further includes:

[0020] Add exception handling to the process of the main security domain class and the auxiliary security domain class.

[0021] As a specific implementation of this application, the domain objects of the primary security domain and the secondary security domain are set as follows:

[0022] Define class objects, including an application list entry class, a secure channel sequence counter class, a secure domain key list class, and a secure domain storedata class;

[0023] Define multiple domain objects for primary security domains and multiple domain objects for secondary security domains; the number of domain objects for primary security domains is not less than the number of domain objects for secondary security domains, and the order of the domain objects for primary security domains is the same as the order of the domain objects for secondary security domains;

[0024] In the Java code compilation configuration file, add object offset definitions for class objects and secondary security domains.

[0025] The domain objects of the main security domain include an application list entry object, a security channel sequence counter object, a security domain key list object, a security channel default key version, a security domain RAM data object, a security domain NVM data object, a security domain storedata data object, and a security domain CGM variable.

[0026] The domain objects of the auxiliary security domain include an application list entry object, a security channel sequence counter object, a security domain key list object, a security channel default key version, a security domain RAM data object, a security domain NVM data object, a security domain storedata data object, a security domain CGM variable, and auxiliary security domain parameter variables.

[0027] In a second aspect, embodiments of the present invention also provide an electronic device, including a processor, an input device, an output device, and a memory, wherein the processor, the input device, the output device, and the memory are interconnected, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the method described in the first aspect above.

[0028] Compared with the prior art, the GP architecture implementation method and electronic device of JAVA card provided by the embodiments of the present invention perform various settings in JAVA and implement the settings in the C code of the native method; that is, the embodiments of the present invention can reduce bugs by utilizing the object mechanism of the Java language and run GP functions in the native environment, thereby improving the running performance of the program and facilitating program debugging. Attached Figure Description

[0029] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0030] Figure 1 This is a flowchart of the GP architecture implementation method for a JAVA card provided in an embodiment of the present invention;

[0031] Figure 2 This is a diagram of the interface for creating the main security domain class;

[0032] Figure 3 This is a screenshot of the interface for setting the main security domain class;

[0033] Figure 4a and 4b It is a graphical representation of the interface for defining class objects;

[0034] Figure 5 This is a diagram of the interface for creating auxiliary security domain classes;

[0035] Figure 6 This is a screenshot of the interface for configuring auxiliary security domain classes;

[0036] Figure 7 This is a structural diagram of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0039] The technical terms used in this embodiment are explained as follows:

[0040] GP: Global Platform

[0041] Security Domain: A security domain is an applet with management functions defined in GP. There are two types: the primary security domain (Issuer Security Domain), which represents the card issuer and can fully manage all card content, including the ability to load, install, and delete applications belonging to the card issuer or other application providers; and the supplementary security domain, which is usually the application provider security domain. It assists the primary security domain in management and can only manage a portion of the card content, providing security services (including key processing, data encryption, data decryption, digital signature generation and verification, etc.) for all or part of the applications on the card.

[0042] The two existing GP architectures mentioned in the background section have obvious drawbacks, but each also has its advantages. This invention aims to provide a third technical architecture that retains the advantages of the two existing GP architectures while minimizing their disadvantages as much as possible.

[0043] Please refer to Figure 1 The GP architecture implementation method for JAVA cards provided in this embodiment of the invention includes:

[0044] S1. In the Java code, create the primary security domain class and the secondary security domain class.

[0045] S2, configure the main security domain class and the auxiliary security domain class to obtain the first configuration result.

[0046] S3, in the Java code, sets the domain objects of the primary security domain and the secondary security domain to obtain the second setting result.

[0047] S4, Implement the first setting result and the second setting result in the C code of the native method.

[0048] The implementation method of the above GP architecture is described in detail below with a specific example. The specific steps are as follows:

[0049] (1) In the Java code, create the main security domain class, which inherits from the Javacard applet class. The specific interface diagram for this step is shown below. Figure 2 As shown.

[0050] (2) For methods such as select() and deselect() in the main security domain class, only native calls are retained. An exception handling mechanism is implemented for the process() method. The processing content and exception handling content of process(), as well as the specific implementations of select(), deselect(), etc., are all in the C code of the native methods. The specific interface diagram for this step is shown below. Figure 3 As shown. Exception caught in Figure 3 The embodiment of

[0051]

[0052] (3) Define the application list entry class, the secure channel sequence counter class, the secure domain key list class, and the secure domain storedata data class, etc. The specific interface diagram for this step is shown below. Figure 4a and 4b As shown.

[0053] (4) In the domain object definition of the main security domain, define the application list entry object, security channel sequence counter object, security domain key list object, security channel default key version, security domain RAM data object, security domain NVM data object, security domain storedata data object, security domain CGM variable, etc. The specific interface diagram for this step is shown below. Figure 2 As shown.

[0054] (5) In the Java code, create a secondary security domain class that inherits from the Javacard applet class. The specific interface for this step is shown below. Figure 5 As shown.

[0055] (6) For methods such as select() and deselect() in the auxiliary security domain class, only native calls are retained. An exception handling mechanism is implemented for the process() method. The processing content and exception handling content of process(), as well as the specific implementations of select() and deselect(), are all in the C code of the native methods. The specific interface diagram for this step is shown below. Figure 6 As shown.

[0056] (7) In the domain object definition of the auxiliary security domain, define the application list entry object, the security channel sequence counter object, the security domain key list object, the security channel default key version, the security domain RAM data object, the security domain NVM data object, the security domain storedata data object, the security domain CGM variable, and the auxiliary security domain parameter variables, etc. The order of each object and variable defined in this step must be exactly the same as in step 4, and the additional parameter variables of the auxiliary security domain should be placed at the end of the definition.

[0057] (8) Add the domain object offset definition for the auxiliary security domain in step 7 and the object offset of the class object defined in step 3 to the compilation configuration file of the Java code. For example, if a variable A is defined in the configuration items, the compilation tool will automatically generate an offset value (which is a constant) and assign the offset value to variable A.

[0058] (9) Implement the settings of the aforementioned steps (1) to (8) in the C code of the native method.

[0059] As can be seen from the above description, the GP architecture implementation method of the JAVA card provided by the embodiments of the present invention allows for various settings to be made in JAVA, and the settings are implemented in the C code of the native method; that is, the embodiments of the present invention can reduce bugs by utilizing the object mechanism of the Java language, and can run the GP function in the native environment, thereby improving the running performance of the program and facilitating program debugging.

[0060] Furthermore, the implementation method of the aforementioned GP architecture is explained as follows:

[0061] (1) Two security domain classes are implemented, one main security domain class and one auxiliary security domain class; if necessary, the domain objects of the two security domains are the same, and the auxiliary security domain can add additional domain objects. Therefore, in the native implementation, the same auxiliary security domain object offset can be used to access the domain objects of the auxiliary security domain class and the main security domain class.

[0062] (2) Most of the methods in the security domain are implemented in the native code, and only the calling relationship is retained in Java.

[0063] (3) Exception handling is used for the process method of the security domain, which allows for flexible handling of exceptions in the native implementation.

[0064] (4) Define some classes for the domain objects of the security domain, but there are no method implementations in the class definitions. The specific access implementations are all in the native code.

[0065] Based on the same inventive concept, embodiments of the present invention provide an electronic device. As shown in the figure, the electronic device may include: one or more processors 101, one or more input devices 102, one or more output devices 103, and a memory 104. The processors 101, input devices 102, output devices 103, and memory 104 are interconnected via a bus 105. The memory 104 is used to store a computer program, the computer program including program instructions, and the processor 101 is configured to invoke the program instructions to execute the following steps:

[0066] In the Java code, create a primary security domain class and a secondary security domain class; both the primary security domain class and the secondary security domain class inherit from the applet class of javacard;

[0067] The primary security domain class and the secondary security domain class are configured to obtain the first configuration result;

[0068] In Java code, setting the domain objects of the primary security domain and the secondary security domain yields the second setting result;

[0069] Implement the first and second setting results in the C code of the native method.

[0070] In one specific implementation, the processor 101 is configured to invoke the program instructions to execute the following steps:

[0071] The select() and deselect() methods in the main security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods.

[0072] The select() and deselect() methods in the auxiliary security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods.

[0073] Furthermore, the processor 101 is also configured to invoke the program instructions to perform the following steps:

[0074] Add exception handling to the process of the main security domain class and the auxiliary security domain class.

[0075] In one specific implementation, the processor 101 is configured to invoke the program instructions to execute the following steps:

[0076] Define class objects, including an application list entry class, a secure channel sequence counter class, a secure domain key list class, and a secure domain storedata class;

[0077] Define multiple domain objects for primary security domains and multiple domain objects for secondary security domains; the number of domain objects for primary security domains is not less than the number of domain objects for secondary security domains, and the order of the domain objects for primary security domains is the same as the order of the domain objects for secondary security domains;

[0078] In the Java code compilation configuration file, add object offset definitions for class objects and secondary security domains.

[0079] The domain objects of the main security domain include an application list entry object, a security channel sequence counter object, a security domain key list object, a security channel default key version, a security domain RAM data object, a security domain NVM data object, a security domain storedata data object, and a security domain CGM variable.

[0080] The domain objects of the auxiliary security domain include an application list entry object, a security channel sequence counter object, a security domain key list object, a security channel default key version, a security domain RAM data object, a security domain NVM data object, a security domain storedata data object, a security domain CGM variable, and auxiliary security domain parameter variables.

[0081] It should be understood that, in this embodiment of the invention, the processor 101 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0082] Input device 102 may include a keyboard, etc., and output device 103 may include a display (LCD, etc.), a speaker, etc.

[0083] The memory 104 may include read-only memory and random access memory, and provides instructions and data to the processor 101. A portion of the memory 104 may also include non-volatile random access memory. For example, the memory 104 may also store device type information.

[0084] In specific implementations, the processor 101, input device 102, and output device 103 described in the embodiments of the present invention can execute the implementation methods described in the embodiments of the GP architecture implementation method of the JAVA card provided in the embodiments of the present invention, which will not be repeated here.

[0085] It should be noted that for a more detailed description of the workflow of the electronic device, please refer to the aforementioned method embodiment section, which will not be repeated here.

[0086] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for implementing a GP architecture for a Java card, characterized in that, include: In the Java code, create the primary security domain class and the secondary security domain class; The primary security domain class and the secondary security domain class are configured to obtain the first configuration result; In Java code, setting the domain objects of the primary security domain and the secondary security domain yields the second setting result; Implement the first and second setting results in the C code of the native method; The primary security domain class and the secondary security domain class are configured as follows: The select() and deselect() methods in the main security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods. The select() and deselect() methods in the auxiliary security domain class retain only the native call relationship; the specific implementation of the select() and deselect() methods is in the C code of the native methods. Configure the domain objects for the primary and secondary security domains as follows: Define class objects, including an application list entry class, a secure channel sequence counter class, a secure domain key list class, and a secure domain storedata class; Define multiple domain objects for primary security domains and multiple domain objects for secondary security domains; the number of domain objects for primary security domains is not less than the number of domain objects for secondary security domains, and the order of the domain objects for primary security domains is the same as the order of the domain objects for secondary security domains; In the Java code compilation configuration file, add object offset definitions for class objects and secondary security domains.

2. The GP architecture implementation method as described in claim 1, characterized in that, Both the primary security domain class and the secondary security domain class inherit from the applet class of javacard.

3. The GP architecture implementation method as described in claim 1, characterized in that, Setting the primary security domain class and the secondary security domain class also includes: Add exception handling to the process of the main security domain class and the auxiliary security domain class.

4. The GP architecture implementation method as described in claim 1, characterized in that, The domain objects of the main security domain include the application list entry object, the security channel sequence counter object, the security domain key list object, the security channel default key version, the security domain RAM data object, the security domain NVM data object, the security domain storedata data object, and the security domain CGM variable; The domain objects of the auxiliary security domain include an application list entry object, a security channel sequence counter object, a security domain key list object, a security channel default key version, a security domain RAM data object, a security domain NVM data object, a security domain storedata data object, a security domain CGM variable, and auxiliary security domain parameter variables.

5. An electronic device, characterized in that, The electronic device includes a processor, an input device, an output device, and a memory, which are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to invoke the program instructions to execute the method as described in any one of claims 1-4.

Images