CN113378177A

CN113378177A - Safe and open Native multi-application system architecture and Native application program execution method

Info

Publication number: CN113378177A
Application number: CN202110671775.1A
Authority: CN
Inventors: 涂翠; 杜昭睿
Original assignee: Wuhan Jahport Technology Co ltd
Current assignee: Wuhan Jahport Technology Co ltd
Priority date: 2021-06-17
Filing date: 2021-06-17
Publication date: 2021-09-10

Abstract

The invention provides a safe and open Native multi-application system architecture and a Native application program execution method, wherein the architecture can be compatible with an existing Java Card operating system, an existing JavaApplet can be executed in the architecture, binary Native applications are supported in a safe and open manner, and good isolation is provided between the operating system and the applications and between the applications. The system architecture comprises hardware, a hardware abstraction layer HAL, a Kernel layer, a unified operating environment, Native application management and a Native Applet. The framework and the method have the advantages of independent and controllable technology, low cost, convenient API interface, high performance, high safety, capability of supporting Native application post-download and the like.

Description

Safe and open Native multi-application system architecture and Native application program execution method

Technical Field

The invention relates to the technical field of information security, in particular to a safe and open Native multi-application system architecture and a Native application program execution method.

Background

Java Card is the smallest subset of the Java platform, and is an open standard set by Sun for the smart Card development platform. Smart cards are cards embedded in computer chips, and are widely used in the fields of communications, transportation, finance, securities, insurance and the like, and nowadays, more and more smart cards and other forms of Security Elements (SE) are equipped with a Chip Operating System (COS) on a Java card. The four most important characteristics of the Java Card COS are compatibility, multiple applications, dynamics and security, i.e., different Java applets can run on all Java Card OSs, multiple applications coexist on the same Java Card, new applications can be installed on the SE after the SE is issued, and the application isolation characteristics are good.

Although the Java Card technology defines a secure, portable, multi-application smart Card platform, it still suffers from the following disadvantages: 1) java Card is not a self-controlled technology in China, and cannot fundamentally guarantee the economic safety, social safety and national safety of China; 2) license cost of Java Card is a non-negligible product cost; 3) although a standard interface of the JCDK is defined in the Java Card specification, interfaces required by some applications are not standardized, and cannot provide convenient API support for upper-layer applications, for example, some cryptographic algorithms and novel cryptographic algorithms are widely used in various domestic industrial applications, but the JCDK has no corresponding standard interface; 4) compared with the Native code, the execution performance of the Java Applet is high in efficiency by interpreting the execution bytecode on the Java Card virtual machine, and the slow execution performance of the Java Applet is generally suffered from the following problems.

Disclosure of Invention

The invention provides a safe and open Native multi-application system architecture and a Native application program execution method, which are used for solving or at least partially solving the technical problem of insufficient safety and openness in the prior art.

In order to solve the above technical problem, a first aspect of the present invention provides a secure open Native multi-application system architecture, including:

the hardware layer is a microprocessor chip, and the hardware abstraction layer is an interface layer positioned between an operating system Kernel and a hardware circuit and used for abstracting hardware; the Kernel layer is the core of an operating system, unifies the operating environment and is used for providing the operating environment of Native application programs, the Native application management is used for managing a plurality of Native application programs, the operation of the Native application programs supports the application isolation of hardware protection and supports two modes including a system mode and a user mode, wherein codes operated in the system mode have complete access rights to a memory and a peripheral device, and the access rights of the codes operated in the user mode to the memory and the peripheral device are set according to the situation.

In one embodiment, application program compilation linking supports three modes, the first mode is that a logic address can be fixed for an application code and an application program, a range of codes and data is specified through a compilation option, the logic address is remapped to a physical address through an MMU, the second mode is that a code area and a data area of the application are given in advance, a user specifies the range of the codes and the data through the compilation option, the third mode is that when the multi-application platform is loaded, the code area and the data area of the application are determined dynamically, and the application program code generates address-independent codes when the application program code is compiled and linked.

Based on the same inventive concept, a second aspect of the present invention provides a Native application executing method based on the system architecture of the first aspect, including:

when the microprocessor chip is reset and powered on, entering a system mode by default;

setting configuration in a system mode, carrying out system initialization, and waiting for receiving an external command;

when an external command is received, judging whether the received external command is processed by a Native application program, if so, setting the system resource access authority of the application program, otherwise, processing the external command by an operating system COS on the card until the processing is finished;

when the received external command is processed by a Native application program, after the system resource access authority of the application program is set, switching from a system mode to a user mode, and setting the configuration in the user mode;

and executing the boot code of the Native application program, and jumping to the code of the Native application program to process an external command.

In one embodiment, when the Native application program code is skipped to process an external command, the Native application program accesses hardware resources in a system calling mode in the running process to realize functions of cryptographic operation, communication transmission, memory access and transaction operation.

In one embodiment, the system call includes checking whether the memory region pointed to by the input/output parameter is a region that can be legally accessed by the application, whether the application has read permission for the region pointed to by the input parameter, and whether the memory region pointed to by the output parameter has write permission.

In one embodiment, the method further comprises returning to the system mode after the Native application in the user mode has processed the corresponding external command.

One or more technical solutions in the embodiments of the present application have at least one or more of the following technical effects:

the invention provides a safe and open Native multi-application system architecture, which can be compatible with the existing Java Card operating system, the existing Java Applet can be executed in the architecture, meanwhile, binary Native application is supported in a safe and open form, and the operating system and the application as well as the application and the application have good isolation. The system architecture comprises hardware, a hardware abstraction layer HAL, a Kernel layer, a unified operating environment, Native application management and a Native Applet. The framework and the method have the advantages of independent and controllable technology, low cost, convenient API interface, high performance, high safety, capability of supporting Native application post-download and the like.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 is a schematic diagram of a secure open Native multi-application system architecture in the present invention.

FIG. 2 is a flow chart of application execution in an embodiment of the present invention.

Fig. 3 is a flowchart of downloading, installing, and deleting an application in an embodiment of the invention.

FIG. 4 is a diagram of application development and system calls in a specific embodiment of the invention.

Detailed Description

In order to solve the problem of the platform safety and openness in the prior art, the invention provides a safe and open Native multi-application system architecture and a method, wherein the architecture can be compatible with the existing Java Card operating system, the existing Java Applet can be executed in the architecture, and the binary Native application is supported in a safe and open manner. The operating system and the application have good isolation.

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Example one

Referring to fig. 1, an embodiment of the present invention provides a secure and open Native multi-application system architecture, including:

Specifically, the hardware abstraction layer hides the hardware interface details of a specific platform, provides a virtual hardware platform for an operating system, enables the virtual hardware platform to have hardware independence, and can be transplanted on various platforms. Kernel layer: is the core of an operating system. The software expansion based on hardware provides the most basic functions of the operating system and is the basis of the operation of the operating system. Unified operating environment: an execution mode between a compiler and an interpreter. An application written in the C, Java language may run on the environment. Native application management: and managing functional components of a plurality of Native applications. Native Applet (Native application layer): and the application program is written by using C language.

Example two

Based on the same inventive concept, the invention also provides a Native application program execution method based on the system architecture of the first embodiment, which comprises the following steps:

s1: when the microprocessor chip is reset and powered on, entering a system mode by default;

s2: setting configuration in a system mode, carrying out system initialization, and waiting for receiving an external command;

s3: when an external command is received, judging whether the received external command is processed by a Native application program, if so, setting the system resource access authority of the application program, otherwise, processing the external command by an operating system COS on the card until the processing is finished;

s4: when the received external command is processed by a Native application program, after the system resource access authority of the application program is set, switching from a system mode to a user mode, and setting the configuration in the user mode;

s5: and executing the boot code of the Native application program, and jumping to the code of the Native application program to process an external command.

Specifically, Native application programs of the application run and application isolation of hardware protection is supported. Most microprocessor chips currently support at least two modes in hardware (and possibly more): privileged mode and non-privileged mode (microprocessors of different architectures name similar modes differently). Code running in privileged mode (system mode) has full access to memory and peripherals; the access authority of the non-privileged mode (user mode) is flexibly set in the privileged mode, and the non-privileged mode can only have a small number of authorities and can almost have all access authorities of the memory and the peripheral equipment.

In the specific implementation process, the operating system runs in a privileged mode, the applications loaded on the operating system run in a non-privileged mode, and the respective authority of each application is different. The processor throws an exception as soon as an application in a certain system mode requires access to a memory or register in its non-authorized range. When some user program has an error, the operating system will not crash, and other user programs will not be affected by the error.

The configuration under the system mode comprises system stack setting and user mode configuration.

In the step S3, if the received external command is processed by the Native application, the system resource access authority of the application is set, and then the step S4 is executed, otherwise, the external command is processed by the COS on the card until the processing is completed, and the execution is finished.

Please refer to fig. 2, which is a flowchart illustrating an application execution method according to an embodiment.

Specifically, when a received command is to be processed by some application programs, the target CPU directly runs the binary code, and the permission set during the running of the application is the access permission of the system resource of the application itself. The Memory access authority of the user mode, including the address ranges of the accessible ROM, NVM and RAM, and the read/write execution authority, is usually set by hardware modules such as MMU (Memory Management Unit), MPU (Memory Protection Unit), PMP (Physical Memory Protection) and the like. The access right of the peripheral device is generally configured by corresponding special function registers, and the peripheral device includes a password coprocessor module, a random number generator, a Timer, each communication module, and the like. In order to not affect the function of the operating system due to the error of the application program, the permission of the application to directly access the peripheral equipment in the user mode can be closed. And after the operating system finishes the setting of the access authority of the application, switching the processor mode from the system mode to the user mode.

Fig. 3 is a flowchart of downloading, installing, and deleting an application in an embodiment of the present invention.

The development of the Native application program comprises the following steps:

(1) the development of the application program is completely independent of the development of the multi-application platform. In order to realize a safe and open application environment, the multi-application platform provides a corresponding system resource access API (application program interface) based on Native, and realizes functions of cryptographic operation, communication transmission, memory access, transaction operation and the like.

(2) The implementation of the NA _ API (Native application API) includes two aspects, one is that a system library NA _ Lib _ S is implemented in a system call mode in a multi-application platform operating system, and the logical function of the NA _ API is really executed; and secondly, the application program developer uses the user library NA _ Lib _ U, and the user library is used for switching the non-privileged mode to the privileged mode and calling a corresponding API in the NA _ Lib _ S. And the NA _ Lib _ S and the NA _ Lib _ U together form a Native multi-application platform library file NA _ Lib.

(3) And checking the parameter validity. In the call of the NA _ API, the application program needs to pass input/output parameters, which usually indicate the address of the input information and the address of the output information in the form of pointers. After entering the system call, it is necessary to check whether the memory area pointed by the input/output parameter is an area that can be legally accessed by the application program, whether the application has a read right to the area pointed by the input parameter, and whether the memory area pointed by the output parameter has a write right.

The validity check of the input/output buffer area (namely the memory area pointed by the input/output parameters) can be realized by hardware or software, and if the hardware checks out an illegal memory area, an exception is triggered; if the software checks out the illegal memory region, it can be returned to the application program by means of an error return code. Therefore, when the application calls the NA _ API, the called return code is checked first to judge whether the calling is successful, and the subsequent steps are continued only when the calling is successful, otherwise, error processing is performed in time.

(4) And compiling and linking the application program. If the application accesses the memory directly in the absolute address mode, the method is divided into the following steps according to whether the MMU has the function of remapping the application program logical address to the physical address:

1) with MMU address remapping. The application code and application data may be in a fixed logical address space, with the scope of the code and data being specified by a compilation option. When the code executes, the logical addresses of the user space will be remapped to the physical addresses by the MMU.

2) The MMU address remapping function is not provided, and when the system is loaded on a multi-application platform, the code area and the data area of the application are given in advance. The memory space address used by the application program is also downloaded into the memory space range of the multi-application platform. The user specifies the scope of the code and data through the compile option.

3) The method has no MMU address remapping function, and the code area and the data area of the application are dynamically determined when the method is loaded on a multi-application platform. The application program codes generate address-independent codes during compiling and linking, and a small amount of relocation may be required when the address-independent codes are downloaded to a multi-application platform, which requires that the multi-application platform has certain relocation and linking functions.

Relocation refers to the process of converting the logical address space of a program into the actual physical address space in memory.

FIG. 4 is an application development and system call diagram in an embodiment of the invention.

The downloading, installing and deleting of the Native application comprises the following steps:

(1) and generating an application download Package file. The application development project generates a binary executable file, some extra information is added to the binary file to form a Package file downloaded to the multi-application platform, and the information can include the version number of the Package, the version number of NA _ Lib, the code and data address range and other information.

(2) And downloading the application Package. The application provider establishes a secure session channel with the system-on-chip, and stores the application code download to the operating NVM region or the RAM region (if the RAM region has executable rights). And registering the downloaded application Package in the multi-application operating system, wherein the application Package comprises information such as a Package ID, a storage address, the number of application instances and the like. During the Package downloading process, the code may need to be relocated, and part of the binary code of part of the application program may need to be modified.

(3) And installing an application example. The application Package code cannot be directly executed after being downloaded, installation of an application instance is required, an NVM space, an RAM space and even a ROM readable space are allocated to the application instance, the access authority of a peripheral is specified, and the application instance is registered in the multi-application operating system and comprises instance ID, the allocated memory space, the authority and other information.

(4) More application instances are installed. An application Package may correspond to multiple application instances (e.g., running multiple wallet applications on an operating system), each having a respective memory space, storing respective data and file systems, and registering application instances in the multi-application operating system. If a variable or an object shared by a plurality of application instances exists, the shared resource is also allocated in the downloading phase or the installation phase of the application Package.

(5) The application instance is deleted. And the operating system searches the information in the application instance registry, recovers the file system space used by the application instance, and deletes the corresponding registry entry in the application instance registry.

(6) The application Package is deleted. And the operating system searches the information in the application Package registry, recovers the storage space occupied by the application Package, and deletes the corresponding registry key in the Package registry. If some application Package has a corresponding application instance, the Package cannot be deleted.

The Native application program execution method provided by the invention is described below by a specific example.

The example takes a secure multi-application operating system implemented on a secure microcontroller CVF1088 as an example, and illustrates an execution flow of an open Native application. The CVF1088 is an enhanced 80C51 architecture security microcontroller, has security enhancement functions such as a unified MMU (unified memory management unit), and is provided with an advanced encryption coprocessor ACE (advanced encryption coprocessor), a SM4 coprocessor and a DES coprocessor. The CVF1088 has a system mode (privileged mode) that accesses the physical address space and a user mode (non-privileged mode) that accesses the logical address space remapped by the MMU in cooperation with the MMU. The memory space available for CVF1088 is:

ROM 294KB 0x800000-0x8497FF

EEPROM 87KB 0xC00000-0xC15DFF

CPU RAM 9KB

an example of further partitioning CPURAM is:

a system mode DATA RAM area (256B0x7F0000 ~ 0x7F00FF),

a system mode IDATA RAM area (512B0x7F 0100-0 x7F02FF),

a system mode STACK (STACK) region (512B0x7F 0100-0 x7F02FF),

system mode XDATA RAM area (8.25KB, 0-0 x0020FF),

user mode DATA RAM area (128B0x7F0000 ~ 0x7F007F),

a user mode IDATA random access memory area (192B0x7F0100 ~ 0x7F01BF),

user mode Stack (STACK) region (64B0x7F01C0 ~ 0x7F01FF)

User mode XDATA RAM area (0x0 ~ 0x00103F)

The above addresses are all physical addresses.

Note that several field modifiers, namely DATA, IDATA, XDATA, and code, are defined in KEILC51, and these modifiers determine the variable access method.

Wherein, DATA: with the internal RAM directly accessed by the mov,

IDATA: internal RAM with indirect access by mov @ and,

XDATA: external RAM accessed with movx.

The execution flow of Native application:

(1) and after the chip is powered on and started, the chip enters a system mode by default, and an accessible DATA, IDATA and stack area are set for a chip operating system running in the system mode. In the system mode, the special function register SFR is set to indicate whether or not all other peripheral devices can be accessed.

(2) When a Native application is selected to be executed, the MMU is first set up to:

1) the scope and the authority (reading, writing and executable) for the Native application to access the storage are limited;

2) the permission of Native application to access the peripheral is limited;

3) physical addresses accessible to Native applications are mapped to logical addresses, facilitating the compilation of application programs into code that is independent of memory physical addresses.

The MMU settings are as follows:

storage area logic starting address logic ending address physical starting address read-write execution authority

(3) Invoking a special instruction ECALL0x800000 to switch to user mode and starting at logical address 0x800000 to execute code in user mode;

(4) according to the MMU setting, logical address 0x800000 in user mode corresponds to physical address 0x8497C0, here the boot code in user mode, for setting the STACK area in user mode

This code sets the user mode STACK register and STACK upper and lower boundary registers, and the ECALL0C00000H instruction calls the function with logical address 0xC00000, which is the real entry address of Native application code.

The LCALL01F8H instruction calls Systemcall at 0x8001F8, which functions to return to system mode. I.e. return to system mode after execution of the user mode code is complete.

CSEGAT0001F8H

SYSTEM_CALL_BACK2SYSMODE:

ERET

(5) The code of the Native application consists of two parts, wherein one part is provided for the NA _ API of the Native application in a library form; for security, the access to the hardware resource in user mode is performed by a system call, and the NA _ API performs the system call. The other part is code written by the application developer.

The API source code provided in the form of a library is

In the section of example code, Native application code boot section code calls App _ Entry to enter code written by an application developer, and when the application developer needs to call a system function SM3, Native api _ SM3 is called.

An example of application code is as follows:

in the example code, NAAPI _ setincomindedreceive () receives data from the outside, NAAPI _ setoutingandsend () sends a result to the outside, NAAPI _ SetSW () sets a state code, NAAPI _ SM3(Func _ SM3Simple) performs a hash operation of the one-time cryptographic hash algorithm SM3, and the example code starts with a byte of which the APDU offset of the input data is 5 until the SM3 hash value is finally calculated, and puts the 32-byte hash value until the APDU offset is 5, and finally outputs the operation result to the outside. Where sm3 is used as a structure for I/O parameter passing, apdu can be considered as an I/O buffer.

The specific embodiments described herein are merely illustrative of the spirit of the invention. Various modifications or additions may be made to the described embodiments or alternatives may be employed by those skilled in the art without departing from the spirit or ambit of the invention as defined in the appended claims.

Claims

1. A secure open Native multi-application system architecture, comprising:

2. A Native multi-application system architecture according to claim 1, wherein the application program compile link supports three ways, the first being to fix logical addresses for application code and application program, to specify ranges of code and data by compile options, to remap logical addresses to physical addresses by MMU, the second being to specify in advance code and data regions for application, to specify ranges of code and data by user through compile options, and the third being to dynamically determine code and data regions for application when loaded on multi-application platform, the application code generating address independent code when compiled link.

3. A Native application execution method based on the system architecture of claim 1, comprising:

4. The Native application program execution method of claim 3, wherein when jumping to the Native application program code to process the external command, the Native application program accesses the hardware resource in a system call mode during the running process to realize the functions of cryptographic operation, communication transmission, memory access and transaction operation.

5. A Native application program execution method according to claim 4, wherein the system call includes checking whether the memory region pointed to by the input/output parameter is a region that can be legally accessed by the application program, whether the application has read permission for the region pointed to by the input parameter, and whether the memory region pointed to by the output parameter has write permission.

6. The Native application execution method of claim 3, further comprising returning to system mode after the Native application in user mode has processed the corresponding external command.