WO2022133774A1 - Native与JavaCard动态切换的方法及设备 - Google Patents

Native与JavaCard动态切换的方法及设备 Download PDF

Info

Publication number
WO2022133774A1
WO2022133774A1 PCT/CN2020/138518 CN2020138518W WO2022133774A1 WO 2022133774 A1 WO2022133774 A1 WO 2022133774A1 CN 2020138518 W CN2020138518 W CN 2020138518W WO 2022133774 A1 WO2022133774 A1 WO 2022133774A1
Authority
WO
WIPO (PCT)
Prior art keywords
javacard
cos
native
control instruction
security chip
Prior art date
Application number
PCT/CN2020/138518
Other languages
English (en)
French (fr)
Inventor
金辉
李路昌
Original Assignee
深圳杰睿联科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳杰睿联科技有限公司 filed Critical 深圳杰睿联科技有限公司
Priority to CN202080027000.4A priority Critical patent/CN113692576A/zh
Priority to PCT/CN2020/138518 priority patent/WO2022133774A1/zh
Publication of WO2022133774A1 publication Critical patent/WO2022133774A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption

Definitions

  • the invention relates to the technical field of smart cards, in particular to a method and device for dynamically switching between Native and Java Card.
  • the operating system (Chip On System, COS) of the smart card security chip mainly includes Native COS and JavaCard COS.
  • Native COS uses C language for development and implementation, which has high execution efficiency, low card issuance space consumption and low cost
  • JavaCard COS has the advantages of flexibility, scalability, and standard-compliant interconnectivity.
  • JavaCard COS supports the preset of Java Applet or dynamic download and installation after leaving the factory, which maintains the independence and friendliness of the upper-level Applet application developers.
  • JavaCard in the telecommunications field supports remote download of Applet for installation and update, and you can also download the corresponding Applet application when downloading the profile number (Profile).
  • Such Applet including traffic swipe card, wallet, payment, electronic driver's license, etc.
  • Native COS and JavaCard COS have their own advantages and their own application scenarios. At present, two kinds of COS exist independently in the industry to meet the needs of different customers. For the smart card production line, different hardware production processes are required for Native COS and JavaCard COS, which will undoubtedly increase the operational burden of the production line and reduce the production efficiency of the production line.
  • the present invention mainly provides a method and device for dynamic switching between Native and JavaCard, which are used to solve the problem of low production efficiency of smart card production lines caused by the independent coexistence of existing two sets of COS architectures.
  • an embodiment provides a method for dynamically switching between Native and JavaCard, including:
  • the compiled firmware version is written into the security chip, and the firmware version is developed based on a compatible system architecture including Native COS and JavaCard COS, and the compatible system architecture is compatible with Native and JavaCard in a decoupled manner;
  • the personalized status indicates that the root security domain has not performed a personalized operation
  • an embodiment provides an electronic device, comprising:
  • the processor is configured to implement the method for dynamically switching between Native and JavaCard described in the first aspect above by executing the program stored in the memory.
  • an embodiment provides a computer-readable storage medium, including a program, where the program can be executed by a processor to implement the method for dynamically switching between Native and JavaCard described in the first aspect.
  • the method and device for dynamically switching between Native and JavaCard include writing the compiled firmware version into the security chip, and the firmware version is developed based on a compatible system architecture including Native COS and JavaCard COS, and the compatible system architecture is decoupled.
  • the method is compatible with Native and JavaCard; obtain the personalized status of the root security domain in the firmware version; if the personalized status indicates that the root security domain has not been personalized, send a control command to the security chip, so that the security chip can realize the firmware version according to the control command. Dynamic switching between Native COS and JavaCard COS.
  • the dynamic switching between Native COS and JavaCard COS in the firmware version is realized through control instructions, so that only one set of hardware production process needs to be maintained, which greatly enhances the reusability of production line production hardware, thereby improving the production efficiency of smart card production lines. .
  • Embodiment 1 is a schematic flowchart of Embodiment 1 of a method for dynamically switching between Native and JavaCard according to an embodiment of the present invention
  • Embodiment 2 is a schematic flowchart of Embodiment 2 of a method for dynamically switching between Native and JavaCard according to an embodiment of the present invention
  • Embodiment 3 is a schematic flowchart of Embodiment 3 of a method for dynamically switching between Native and JavaCard according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a compatible system architecture according to an embodiment of the present invention.
  • connection and “connection” mentioned in this application, unless otherwise specified, include both direct and indirect connections (connections).
  • JavaCard Technology Provides a secure environment for applications running on smart cards (security chips) and other devices with very limited memory and processing power. Multiple applications can be deployed on a single card, and new applications can be added to the end user even after the card is released. Applications written in the Java programming language can run securely on cards from different vendors. is the leading open interoperable platform for smart cards and security tokens. Various JavaCard specifications provide the basis for cross-platform and cross-vendor applet interoperability.
  • Java It is an object-oriented programming language. It not only absorbs various advantages of C++ language, but also abandons the incomprehensible concepts of multiple inheritance and pointers in C++. Therefore, Java language has two characteristics of powerful functions and ease of use. As a representative of static object-oriented programming language, Java language perfectly implements object-oriented theory, allowing programmers to perform complex programming in an elegant way of thinking. Java has the characteristics of simplicity, object orientation, distribution, robustness, security, platform independence and portability, multithreading, and dynamism. Java can write desktop applications, Web site applications, distributed systems and embedded system applications.
  • Applet Application, applet, here refers to the applet that can run on the JavaCard platform. It is written in the Java language and has the characteristics of crossing different JavaCard platforms and hardware chips.
  • SPU Secure Process Unit, a dedicated security processing unit integrated in the baseband chip.
  • eSE embedded Secure Element, embedded security chip.
  • COS Chip On System
  • the operating system developed directly on the security chip usually refers to the general or industrial operating system developed based on the underlying chip capabilities and interfaces in the embedded security chip industry, such as the telecommunications industry, the financial industry, Transportation and other industries.
  • Native Generally refers to the technical design and implementation of C language that has nothing to do with Java, JavaCard, and Java Applet.
  • USIM Universal Subscriber Identity Module
  • Global Subscriber Identity Module also known as Upgrade SIM
  • UMTS Universal Mobile Telecommunication System
  • the USIM card has also upgraded the algorithm in terms of security, and added the card-to-network authentication function. This two-way authentication can effectively prevent hackers from attacking the card.
  • This technology can be used as another high-speed data service carrier of the Global System for Mobile Communications (GSM) network, and it will become the technical support for a good transition from the second generation to the third generation of mobile communication SIM cards. It was proposed as a research direction in 1991.
  • GSM Global System for Mobile Communications
  • UMTS also provides brand-new interactive multimedia services.
  • UMTS uses frequency bands allocated by the International Telecommunication Union (ITU) for terrestrial and satellite wireless communications. It can be accessed through mobile or fixed, public or private networks, and is compatible with GSM and Internet Protocol (IP).
  • ITU International Telecommunication Union
  • IP Internet Protocol
  • eUICC embedded UICC card, an embedded universal integrated circuit card designated by the Global System for Mobile Communications Alliance (GSMA), dedicated to the telecommunications field, and an eSIM card that supports secure remote profile download, multi-profile management and other functions .
  • GSMA Global System for Mobile Communications Alliance
  • Profile A collection of number resources in telecommunications and corresponding data, file systems, and applications.
  • RAM Random Access Memory
  • random access memory also called main memory
  • main memory is an internal memory that directly exchanges data with the CPU. It can be read and written at any time (except when flushing), is fast, and is often used as a temporary data storage medium for the operating system or other running programs. When RAM is working, information can be written (stored) or read (fetched) from any specified address at any time. The biggest difference between it and read-only memory (Read-Only Memory, ROM) is the volatility of data, that is, the stored data will be lost once the power is turned off.
  • RAM is used in computers and digital systems to temporarily store programs, data, and intermediate results. This mainly refers to the running memory provided in the security chip.
  • NVM Non-volatile memory, non-volatile memory, with non-volatile, byte-by-byte access, high storage density, low energy consumption and other characteristics, its read and write performance is close to dynamic random access memory (Dynamic Random Access Memory, DRAM) , but the read and write speed is asymmetric and the life is limited. This mainly refers to the storage provided by the security chip that can perform data persistence.
  • DRAM Dynamic Random Access Memory
  • JCVM JavaCard Virtual Machine, Java Card Virtual Machine, the main function is to implement bytecode parsing and processing execution.
  • JCRE JavaCard Runtime Environment, Java Card runtime environment, responsible for related context environment processing, state saving and switching, and providing runtime support other than JCVM.
  • GP GlobalPlatform, an international standards organization, has corresponding standards and specifications for telecommunications, Java cards, and finance.
  • OPEN The open environment defined by GP supports security domain management, Java Applet installation management, rights management, etc.
  • HAL Hardware Abstract Layer, hardware abstraction layer, abstracts and unifies different interfaces of hardware.
  • System framework here is mainly the system layer, providing various system services.
  • IO Input/Output, input and output, here mainly refers to the output and output processing module of the hardware layer.
  • SD Secure Domain, the security domain.
  • ISD-R root security domain application, responsible for profile download process management, information query management, card management, etc. in the eUICC card.
  • ISD-P Profile security domain, responsible for the information management of each individual Profile in the eUICC card, including Profile core data, file system, applications, etc.
  • ECASD Security authentication and authorization security domain, responsible for the management of certificates and keys in the eUICC card, as well as the corresponding functions such as signature, signature verification, encryption and decryption, and certificate verification.
  • APDU application protocol data unit
  • application protocol data unit is the application-level communication command format definition in the SIM card.
  • API Application Programming Interface, application programming interface.
  • NVMM NVM Manager, NVM manager, responsible for implementing transaction processing on the basis of NVM.
  • Dispatcher Distribution management, responsible for system-level processing and distribution of instructions.
  • Install here specifically refers to the installation on top of GP functions related to JavaCard, such as installing Java Applet, etc.
  • JC API JavaCard API, the application programming interface needed to develop Java Applet.
  • JC Function Restrict JavaCard function restrictions.
  • AES A symmetric encryption algorithm used to encrypt APDU command data for communication between PC production line tools and COS.
  • RSA An asymmetric encryption algorithm used to encrypt AES keys.
  • the operating systems of smart card security chips mainly include Native COS and JavaCard COS.
  • Native COS uses C language for development and implementation, which has high execution efficiency, low card issuance space consumption and low cost.
  • the architecture of Native COS can be shown in Table 1 below.
  • the bottom layer can be developed based on SE chip (SE Chip), using the chip itself to provide hardware-based IO, RAM, NVM, Crypto and other operation interfaces to complete basic bottom-level related operations, after packaging, it becomes the internal hardware driver or hardware of the OS Interface layer: Based on the hardware interface layer (Hardware Driver & Interface), the operating system for the corresponding application scenario is developed. Different application scenarios may have different requirements for the system services that the operating system needs to provide.
  • the top layer is equivalent to the application layer, which can be SIM, USIM, or custom applications to realize the business logic of specific application scenarios.
  • the Native Card OS layer is dispatched to the specific application for processing, and the application is responsible for the processing of the entire process, but the specific execution of a certain part of the logic will call the capabilities and services provided by the corresponding Native Card OS and hardware interface.
  • Native COS is all developed and implemented in C language, and may use some assembly language depending on the chip. It does not support post-update applications and does not support Java Applet. Therefore, applications written under the above architecture are migrated to different chip platforms. It is difficult, does not have unity, and cannot achieve interconnection.
  • the operating system of the smart card security chip also includes JavaCard COS, ordinary USIM cards in the general telecommunications field, and industrial application smart cards in the fields of finance and transportation all use JavaCard COS, such as NXP's eSE chip, Qualcomm's baseband chip SPU, etc.
  • JavaCard COS has the advantages of flexibility, extensibility, and standard-compliant interconnectivity.
  • the architecture of JavaCard COS can be shown in Table 2 below.
  • the top layer is equivalent to the application layer, which can be SIM , USIM, financial wallet application, bus card application, or customized personalized application implemented by JC API, etc., are used to realize the business logic of specific application scenarios, in eUICC, it will be ISD-R, ISD-P, ECASD It can also be a Java Applet downloaded later.
  • Java Applet can be implemented by using the corresponding packaged JC API, regardless of the underlying layer and hardware interface; the Applet here can have very high portability, and can be installed and run on different JavaCards with only one compilation.
  • most of the implementation of the bottom layer and the middle layer are developed in C language, and the application layer can be developed in Java language based on the JavaCard API, and Java Applet applications can be downloaded after support.
  • FIG. 1 is a schematic flowchart of Embodiment 1 of a method for dynamically switching between Native and Java Card according to an embodiment of the present invention. As shown in FIG. 1 , the method in this embodiment may include:
  • the firmware version is developed based on the compatible system architecture including Native COS and JavaCard COS.
  • the compatible system architecture is compatible with Native and JavaCard in a decoupled manner.
  • the execution body of the embodiment of the present invention is an electronic device.
  • all the functions supported by Native COS and JavaCard COS are packaged and compiled, and the compiled firmware version is written into the security chip.
  • the corresponding COS dynamic switching cannot be performed on the security chip.
  • the method for dynamically switching between Native and JavaCard includes writing a compiled firmware version into a security chip, the firmware version is developed based on a compatible system architecture including Native COS and JavaCard COS, and the compatible system architecture is decoupled. Compatible with Native and JavaCard; obtain the personalized status of the root security domain in the firmware version; if the personalized status indicates that the root security domain has not been personalized, send a control command to the security chip, so that the security chip can implement the Native in the firmware version according to the control command. Dynamic switching between COS and JavaCard COS.
  • the compatible system architecture is compatible with both Native COS and JavaCard COS in a decoupled manner, the same content in Native COS and JavaCard COS does not need to be developed repeatedly, making the compatible system architecture highly scalable, easy to maintain and upgrade and iterate. This improves the COS development efficiency and version iteration speed, and reduces the R&D cost and cycle. Moreover, the dynamic switching between Native COS and JavaCard COS in the firmware version is realized through control commands, which greatly enhances the reusability of production hardware in the production line. Thereby, the production efficiency of the production line of the smart card is improved.
  • the root security domain of the firmware version can be preset with JavaCard restriction parameters during compilation.
  • the JavaCard restriction parameter takes the value of the first preset value, it is used to indicate that the firmware version adopts JavaCard COS.
  • the JavaCard restriction parameter is the second preset value, it is used to indicate that the firmware version adopts Native COS.
  • the control instruction may adopt the application protocol data unit format, including a first control instruction and a second control instruction, the first control instruction is used to set the JavaCard restriction parameter to the first preset value, and the second control instruction is used to restrict the JavaCard The parameter is set to the second preset value.
  • the firmware version adopts JavaCard COS.
  • the control command sent by the electronic device may include the second control command.
  • the security chip can be controlled according to the second control command.
  • the control command sent by the electronic device may include the first control command, then, the security chip may set the JavaCard limit parameter to the first preset value according to the first control command, thereby realizing the switching by the Native COS in the firmware version to JavaCard COS.
  • Data is the above-mentioned JavaCard restriction parameter.
  • XX XX in Data is set to "0x00 0x00"
  • Set value that is, "0x00 0x00” can correspond to the second preset value, which is used to indicate that the firmware version adopts Native COS; when "XX XX” in Data is set to "0xFF 0xFF", it means that the JavaCard function is enabled, It can correspond to the above-mentioned "the first control instruction is used to set the JavaCard restriction parameter to the first preset value", that is, "0xFF 0xFF” can correspond to the first preset value, and is used to indicate that the firmware version adopts JavaCard COS at this time.
  • control instruction may further include a third control instruction, and the third control instruction is used to obtain the value of the JavaCard restriction parameter, so as to obtain the COS adopted by the firmware version according to the value of the JavaCard restriction parameter .
  • the above-mentioned third control instruction is exemplified in a specific implementation manner, as shown in Table 4 below.
  • the security chip receives the above-mentioned third control command, it is assumed that the "XX XX" part in the DATA returned to the electronic device is "0x00 0x00", then the value of the JavaCard restriction parameter is the second preset at this time. value, that is, the firmware version adopts Native COS at this time; assuming that the "XX XX” part in the DATA returned to the electronic device is "0xFF 0xFF", then the value of the JavaCard restriction parameter is the first preset value, that is, At this time, the firmware version adopts JavaCard COS. Specifically, as shown in Table 5 below.
  • FIG. 2 is a schematic flowchart of the second embodiment of a method for dynamically switching between Native and Java Card provided by the embodiment of the present invention. As shown in FIG. 2 , the method of this embodiment may include:
  • the firmware version is developed based on the compatible system architecture, including Native COS and JavaCard COS, and the compatible system architecture is compatible with Native and JavaCard in a decoupled manner.
  • a random symmetric encrypted session key can be generated by a key agreement algorithm, where the key agreement algorithm can include an elliptic curve key agreement algorithm (Elliptic Curve Diffie–Hellman key Exchange, ECDH) and an RSA algorithm.
  • the key agreement algorithm can include an elliptic curve key agreement algorithm (Elliptic Curve Diffie–Hellman key Exchange, ECDH) and an RSA algorithm.
  • S205 Send the session key ciphertext to the security chip, so that the security chip obtains the session key from the session key ciphertext according to the asymmetrically encrypted public key preset in the firmware version and corresponding to the asymmetrically encrypted private key key plaintext.
  • the method for dynamically switching between Native and JavaCard provided by the embodiments of the present invention enhances the security of establishing a data channel between an electronic device and a security chip through the above encryption and decryption mechanism, and can effectively avoid problems such as information cloning and replay attacks.
  • encryption and decryption can be performed by using a U-shield physical component, and the U-shield physical component is used to generate a random symmetric encrypted session key and asymmetric encrypted key pair,
  • the U-shield physical component has the security feature of self-destruction of the dismantling key to prevent malicious exposure and dismantling to obtain the key stored in the U-shield management component, so as to use the method of stealing or imitating the ciphertext data to break the COS dynamic switching function.
  • the session key may also include an Advanced Encryption Standard AES key
  • the private key for asymmetric encryption includes an RSA private key
  • the public key for asymmetric encryption includes an RSA public key.
  • FIG. 3 is a schematic flowchart of Embodiment 3 of a method for dynamically switching between Native and Java Card provided by the embodiment of the present invention.
  • the Methods can include:
  • the above-mentioned ciphertext of the execution result may be generated by the security chip encrypting the execution result using the session key, and the execution result is the execution result of dynamically switching the Native COS and the JavaCard COS in the firmware version by the security chip according to the control instruction.
  • the execution result may be to switch the Native COS in the firmware version to the JavaCard COS, or the execution result may also be to switch the JavaCard COS in the firmware version to the Native COS.
  • the user prompt information when the execution result is to switch the Native COS in the firmware version to the JavaCard COS, can be the information indicating that the Native COS in the firmware version has been switched to the JavaCard COS; or, when the execution result is to switch the firmware version When the JavaCard COS in the firmware version has been switched to the Native COS, the user prompt information can be the information indicating that the JavaCard COS in the firmware version has been switched to the Native COS.
  • the method for dynamically switching between Native and JavaCard receives the execution result ciphertext sent by the security chip; decrypts the execution result ciphertext by using the session key, and obtains the execution result plaintext; generates the execution result plaintext according to the obtained execution result plaintext User prompt information, which can show the execution result of the COS status in the firmware version to the user.
  • FIG. 4 is a schematic structural diagram of a compatible system architecture provided by an embodiment of the present invention.
  • the compatible system architecture in the embodiment of the present invention may include a hardware abstraction layer, a system layer and application layer.
  • the hardware abstraction layer can be used to adapt and encapsulate the interface provided by the security chip, and provide the system layer with a unified interface for using the security chip;
  • the system layer can be used to provide system services to the application layer, including dispatch modules, Native modules and JavaCard module;
  • the application layer can be used to provide industry applications, including Native applications and JavaCard applications.
  • the distribution module may be used to distribute the data belonging to the Native application to the Native module for processing, and distribute the data belonging to the JavaCard application to the JavaCard module for processing.
  • the eUICC COS is implemented through the compatible system architecture shown in Table 6 below, as shown in Table 6 below.
  • the hardware abstraction layer (HAL) is constructed at the bottom layer.
  • the HAL is decoupled into different modules after general abstraction: non-volatile memory NVM, Crypto (a cryptographic library), output and output processing module IO, random access Memory RAM and log LOG.
  • the HAL can provide the system layer with a unified interface using the security chip, which is transparent to the layers above the HAL, so that the upper-layer OS and applications are unaware of the hardware interfaces of different chips.
  • the specific implementation of all the unified interfaces of the HAL uses the interfaces provided by SLE97. Adaptation and packaging.
  • the middle layer builds the system layer (Framework), which can provide system services, abstract the system services and functions common to telecommunication and eUICC cards, so as to realize code reuse, and provide the calling interface of the application layer upward.
  • the system layer of Native COS includes: Auth, code number manager ProfileMgr, PPI, PPE, RFM, over-the-air download module OTA, application protocol data unit APDU, CAT, channel management module Channel, distribution module Dispatcher, file system module FileSystem and NVM manager NVMM;
  • the system layer of JavaCard COS includes: random access memory RAM, open environment GP OPEN, GP Amd defined by International Standards Organization, application programming interface GP API defined by International Standards Organization, and application programming interface USIM API of USIM card , Java Card Application Programming Interface JC API, UICC Card Application Programming Interface UICC API, Java Card Virtual Machine JCVM and Java Card Runtime Environment JCRE.
  • the top layer builds the application layer (Application) to realize the applications required by telecommunication and eUICC.
  • the application layer of Native COS includes: root security domain application ISD-R, UICC card, Profile security domain ISD-P, security authentication and authorization security domain ECASD, USIM card and solid state drive (Solid State Disk, SSD); JavaCard COS
  • the application layer includes: Java Applet.
  • the entry and exit at the bottom are in the IO of HAL, and then the communication protocol of the transport layer is parsed and distributed to the distribution module Dispatcher implemented by Native COS. If it is judged that Java Applet needs to be supported, the distribution module Dispatcher will belong to the JavaCard application.
  • the data is dispatched to GP OPEN and the corresponding JCVM, JCRE, etc. for processing, otherwise the data is dispatched to the module corresponding to the Native COS system layer for processing.
  • the dynamic switch through the dynamic switch, the privately defined APDU command format is used, and the encryption and decryption and signature verification of the corresponding APDU content are added. Only after the signature verification and decryption are successful, the dynamic switch Java Applet feature support can be operated from the outside.
  • GP OPEN The support of GP OPEN is also determined according to whether it supports JavaCard as decoupling and optional configuration. JCVM, JCRE and corresponding API packages and RAM application support are fully decoupled. If Java Applet is not supported, you can Perform flexible switching; if Java Applet is supported, then participate in the operation of the entire business process.
  • JavaCard COS When implementing eUICC COS through the compatible system architecture shown in Table 6 above, the functions that JavaCard COS can implement mainly include: downloading JavaCard Package, installing JavaCard Applet, and obtaining JavaCard related information through GP related commands.
  • the above JavaCard functions can all be provided by standard commands of the GP. Specifically, the commands in the GP that support the above functions are shown in Table 7 below.
  • the specific implementation method can be:
  • JavaCard restriction parameters are stored in ISD-R, which are preset at compile time, and can be modified before personalizing the ISD-R, and modification is prohibited after Personalize;
  • the specific disabling process can be as follows:
  • the hardware abstraction layer (HAL) is constructed at the bottom layer.
  • the HAL is decoupled into different modules after general abstraction: NVM, Crypto, IO, RAM and LOG.
  • the HAL can provide the system layer with a unified interface using the security chip, which is transparent to the layers above the HAL, so that the upper-layer OS and applications are unaware of the hardware interfaces of different chips.
  • the interface is adapted and encapsulated, including C and assembly calls.
  • the middle layer builds the system layer (Framework), which can provide system services, abstract system services and functions common to different industries such as telecommunications, so as to realize code reuse, and provide the calling interface of the application layer upward.
  • the system layers of Native COS include: financial system services, security services, other services, industry services, APDU, Channel, Dispatcher, FileSystem and NVMM;
  • the system layers of JavaCard COS include: GP OPEN, GP Amd, GP API, financial API , JC API, Telecom API, JCVM and JCRE.
  • the top layer builds the application layer (Application) to realize the applications required by telecommunications and other industries; among them, the application layer of Native COS includes: finance, telecommunications, transportation and others; the application layer of JavaCard COS includes: Java Applet.
  • the entry and exit at the bottom are in the IO of HAL, and then the communication protocol of the transport layer is parsed and distributed to the distribution module Dispatcher implemented by Native COS. If it is judged that Java Applet needs to be supported, the distribution module Dispatcher will belong to the JavaCard application.
  • the data is dispatched to GP OPEN and the corresponding JCVM, JCRE, etc. for processing, otherwise the data is dispatched to the module corresponding to the Native COS system layer for processing; in the specific implementation, the privately defined APDU instruction format is adopted through the dynamic switch, and the corresponding APDU is added.
  • Java Applet For content encryption, decryption and signature verification, only after the signature verification and decryption are successful, the feature support of Java Applet can be dynamically switched from outside. Moreover, when JavaCard and Java Applet support is required, it can be judged by macro definition and configuration switch. Corresponding to the code logic, if the version support feature is determined at compile time, the corresponding part of the code can not be compiled in to reduce the space occupied by the final version and reduce redundancy.
  • GP OPEN The support of GP OPEN is also determined according to whether it supports JavaCard as decoupling and optional configuration. JCVM, JCRE and corresponding API packages and RAM application support are fully decoupled. If Java Applet is not supported, you can Perform flexible switching; if Java Applet is supported, then participate in the operation of the entire business process.
  • Different implementations can be provided for application scenarios in different industries at the system layer and application layer. For example, due to the different requirements of GP in the telecommunications and financial industries, different implementations are required, that is, different APIs need to be provided for Java Applet calls , corresponding to the system layer, application layer, Java API part, Java Applet part requires the implementation of their respective industries.
  • an embodiment of the present invention also provides an electronic device, the electronic device may include: a memory for storing programs; a processor for executing The program stored in the memory implements the method for dynamically switching between Native and Java Card provided by the embodiment of the present invention.
  • the embodiments of the present invention further provide a computer-readable storage medium, where the computer-readable storage medium includes a program, and the program can be executed by a processor to realize The method for dynamically switching between Native and Java Card provided by the embodiment of the present invention is realized.
  • any tangible, non-transitory computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CD-ROMs, DVDs, Blu Ray disks, etc.), flash memory, and/or the like .
  • These computer program instructions may be loaded on a general purpose computer, special purpose computer or other programmable data processing apparatus to form a machine such that the instructions executed on the computer or other programmable data processing apparatus may generate means for implementing the specified functions.
  • Computer program instructions may also be stored in a computer-readable memory that instructs a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable memory form a piece of Articles of manufacture, including implementing means for implementing specified functions.
  • Computer program instructions may also be loaded on a computer or other programmable data processing device to perform a series of operational steps on the computer or other programmable device to produce a computer-implemented process such that a process executed on the computer or other programmable device Instructions may provide steps for implementing specified functions.
  • the term “comprising” and any other variations thereof are non-exclusive inclusion, such that a process, method, article or device including a list of elements includes not only those elements, but also not expressly listed or included in the process , method, system, article or other elements of the device.
  • the term “coupled” and any other variations thereof refer to physical connections, electrical connections, magnetic connections, optical connections, communication connections, functional connections, and/or any other connection.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

一种Native与JavaCard动态切换的方法及设备，包括将编译好的固件版本写入安全芯片，固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS；获取固件版本中根安全域的个性化状态；若个性化状态指示根安全域未进行个性化操作，则向安全芯片发送控制指令，以使安全芯片根据控制指令实现固件版本中Native COS与JavaCard COS的动态切换。通过控制指令实现了固件版本中Native COS与JavaCard COS的动态切换，这样只需维护一套硬件生产流程即可，大大增强了产线生产硬件的复用性，从而提高了智能卡的产线生产效率。

Description

Native与JavaCard动态切换的方法及设备 技术领域
本发明涉及智能卡技术领域，具体涉及一种Native与JavaCard动态切换的方法及设备。
背景技术
目前智能卡安全芯片的操作系统(Chip On System，COS)主要包括Native COS和JavaCard COS。其中，Native COS使用C语言进行开发和实现，执行效率高，发卡空间消耗小且成本低；JavaCard COS具备灵活、可扩展、符合标准规范的互联互通性等优点。JavaCard COS支持Java Applet的预置或者出厂后动态下载安装，保持了上层Applet应用开发者的独立和友好性，可以不太关心JavaCard底层实现，只需要关注Applet应用自身的业务逻辑即可。例如电信领域的JavaCard支持远程下载Applet进行安装和更新，也可以在下载码号(Profile)的时候顺带下载对应Applet应用；金融领域的JavaCard支持后安装支付检查、钱包应用等，可以支持各种各样的Applet，包括交通刷卡、钱包、支付、电子驾照等。
Native COS和JavaCard COS各具优势，有着各自的应用场景。目前业内两种COS独立并存，以满足不同客户的使用需求。对于智能卡产线来说，针对Native COS和JavaCard COS需要采用不同的硬件生产流程，这无疑会加重产线的操作负担，降低产线的生产效率。
发明内容
本发明主要提供一种Native与JavaCard动态切换的方法及设备，用于解决现有两套COS架构独立并存而导致的智能卡产线生产效率低的问题。
根据第一方面，一种实施例中提供一种Native与JavaCard动态切换的方法，包括：
将编译好的固件版本写入安全芯片，所述固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，所述兼容型系统架构以解 耦的方式兼容Native和JavaCard；
获取所述固件版本中根安全域的个性化状态；
若所述个性化状态指示所述根安全域未进行个性化操作，则向所述安全芯片发送控制指令，以使所述安全芯片根据所述控制指令实现所述固件版本中Native COS与JavaCard COS的动态切换。
根据第二方面，一种实施例中提供一种电子设备，包括：
存储器，用于存储程序；
处理器，用于通过执行所述存储器存储的程序以实现上述第一方面所述的Native与JavaCard动态切换的方法。
根据第三方面，一种实施例中提供一种计算机可读存储介质，包括程序，所述程序能够被处理器执行以实现上述第一方面所述的Native与JavaCard动态切换的方法。
依据上述实施例的Native与JavaCard动态切换的方法及设备，包括将编译好的固件版本写入安全芯片，固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，兼容型系统架构以解耦的方式兼容Native和JavaCard；获取固件版本中根安全域的个性化状态；若个性化状态指示根安全域未进行个性化操作，则向安全芯片发送控制指令，以使安全芯片根据控制指令实现固件版本中Native COS与JavaCard COS的动态切换。通过控制指令实现了固件版本中Native COS与JavaCard COS的动态切换，这样只需维护一套硬件生产流程即可，大大增强了产线生产硬件的复用性，从而提高了智能卡的产线生产效率。
附图说明
图1为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例一的流程示意图；
图2为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例二的流程示意图；
图3为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例三的流程示意图；
图4为本发明实施例提供的一种兼容型系统架构的结构示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明作进一步详细说明。其中不同实施方式中类似元件采用了相关联的类似的元件标号。在以下的实施方式中，很多细节描述是为了使得本申请能被更好的理解。然而，本领域技术人员可以毫不费力的认识到，其中部分特征在不同情况下是可以省略的，或者可以由其他元件、材料、方法所替代。在某些情况下，本申请相关的一些操作并没有在说明书中显示或者描述，这是为了避免本申请的核心部分被过多的描述所淹没，而对于本领域技术人员而言，详细描述这些相关操作并不是必要的，他们根据说明书中的描述以及本领域的一般技术知识即可完整了解相关操作。
另外，说明书中所描述的特点、操作或者特征可以以任意适当的方式结合形成各种实施方式。同时，方法描述中的各步骤或者动作也可以按照本领域技术人员所能显而易见的方式进行顺序调换或调整。因此，说明书和附图中的各种顺序只是为了清楚描述某一个实施例，并不意味着是必须的顺序，除非另有说明其中某个顺序是必须遵循的。
本文中为部件所编序号本身，例如“第一”、“第二”等，仅用于区分所描述的对象，不具有任何顺序或技术含义。而本申请所说“连接”、“联接”，如无特别说明，均包括直接和间接连接(联接)。
首先，对于本发明中所涉及到的一些术语进行简单说明：
JavaCard技术：为那些在智能卡(安全芯片)以及其他内存和处理能力非常有限的设备上运行的应用程序提供了一个安全的环境。一张卡上可以部署多个应用程序，甚至在卡发售给最终用户后还可以向其添加新应用程序。使用Java编程语言编写的应用程序可以在不同供应商的卡上安全运行。是适用于智能卡和安全令牌的领先的开放互操作平台。各种JavaCard规范为跨平台和跨供应商的小程序互操作性提供了基础。
Java：是一门面向对象编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。Java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程。Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点。Java可以编写桌面应用程序、Web网站应用程序、分布式系统和嵌入式系统应用程序等。
Applet：应用，小程序，这里都是专指在JavaCard平台上可以运行 的小程序，使用Java语言编写，具备跨不同JavaCard平台、跨硬件芯片等特性。
SPU：Secure Process Unit，在基带芯片中集成的专用安全处理单元。
eSE：embedded Secure Element，嵌入式安全芯片。
COS：Chip On System，指在安全芯片上直接进行开发的操作系统，通常指嵌入式安全芯片行业上基于底层芯片能力和接口开发的通用或者行业性的操作系统，例如面向电信行业、金融行业、交通行业等其他行业。
Native：一般指用C语言实现和Java、JavaCard、Java Applet无关的技术设计和实现。
USIM：Universal Subscriber Identity Module，全球用户身份模块，也叫做升级SIM，是在通用无线通信系统(Universal Mobile Telecommunication System，UMTS)3G网络的一个构件。除能够支持多应用之外，USIM卡还在安全性方面对算法进行了升级，并增加了卡对网络的认证功能，这种双向认证可以有效防止黑客对卡片的攻击。该技术可以作为全球移动通信系统(Global System for Mobile Communications，GSM)网络的另一种高速数据业务载体，它将成为第二代到第三代移动通信SIM卡良好过渡的技术依托，该技术早在1991年就被提出来作为研究方向，UMTS除支持现有的一些固定和移动业务外，还提供全新的交互式多媒体业务。UMTS使用国际电信联盟(International Telecommunication Union，ITU)分配的、用于陆地和卫星无线通信的频带。它可通过移动或固定、公用或专用网络接入，与GSM和网际互连协议(Internet Protocol，IP)兼容。
eUICC：embedded UICC卡片，全球移动通信系统协会(Global System for Mobile Communications Alliance，GSMA)指定的嵌入式通用集成电路卡，专用于电信领域，可支持安全远程Profile下载、多Profile管理等功能的eSIM卡片。
Profile：电信中的码号资源及对应数据和文件系统、应用等的集合。
RAM：Random Access Memory，随机存取存储器，也叫主存，是与CPU直接交换数据的内部存储器。它可以随时读写(刷新时除外)，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储介质。RAM工作时可以随时从任何一个指定的地址写入(存入)或读 出(取出)信息。它与只读存储器(Read-Only Memory，ROM)的最大区别是数据的易失性，即一旦断电所存储的数据将随之丢失。RAM在计算机和数字系统中用来暂时存储程序、数据和中间结果。这里主要指安全芯片中提供的运行内存。
NVM：Non-volatile memory，非易失存储器，具有非易失、按字节存取、存储密度高、低能耗等特性，其读写性能接近动态随机存取存储器(Dynamic Random Access Memory，DRAM)，但读写速度不对称，寿命有限。这里主要指安全芯片提供的可以进行数据持久化的存储。
JCVM：JavaCard Virual Machine，Java卡虚拟机，主要功能实现字节码的解析和处理执行。
JCRE：JavaCard Runtime Environment，Java卡运行环境，负责相关上下文环境处理、状态保存和切换、提供除JCVM以外需要的运行支持。
GP：GlobalPlatform，国际标准组织，针对电信、Java卡、金融等都有对应的标准和规范。
OPEN：GP定义的开放环境，支持安全域管理、Java Applet安装管理、权限管理等。
HAL：Hardware Abstract Layer，硬件抽象层，将硬件的不同接口进行抽象和统一。
Framework：系统框架，这里主要是系统层，提供各种系统服务。
IO：Input/Output，输入输出，这里主要指硬件层的输出输出处理模块。
SD：Secure Domain，即安全域。
ISD-R：根安全域应用，在eUICC卡中负责Profile的下载流程管理、信息查询管理、卡片管理等。
ISD-P：Profile安全域，在eUICC卡中负责每一个单独的Profile的信息管理，包括Profile的核心数据、文件系统、应用等。
ECASD：安全认证和授权安全域，负责eUICC卡中对证书、密钥的管理以及对应签名、验签、加解密、证书校验等功能。
APDU：application protocol data unit，应用协议数据单元，是SIM卡中应用级别的通信指令格式定义。
API：Application Programming Interface，应用编程接口。
NVMM：NVM Manager，NVM管理器，负责在NVM基础上实现 事务处理。
Dispatcher：分发管理，负责指令的系统级别处理和分发。
Install：安装，这里特指支持JavaCard相关的在GP功能之上的安装，比如安装Java Applet等。
JC API：JavaCard API，即开发Java Applet需要用到的应用编程接口。
JC Function Restrict：JavaCard功能限制。
AES：一种对称加密算法，用于加密PC产线工具与COS通讯的APDU指令数据。
RSA：一种非对称加密算法，用以加密AES密钥。
目前智能卡安全芯片的操作系统主要包括Native COS和JavaCard COS。其中，Native COS使用C语言进行开发和实现，执行效率高，发卡空间消耗小且成本低。举例说明，Native COS的架构可以如下面的表1所示。
表1
Native Application：USIM
Native Card OS
Hardware Driver&Interface
SE Chip
其中，底层可以基于SE芯片(SE Chip)进行开发，利用芯片本身提供基于硬件的IO、RAM、NVM、Crypto等操作接口可以完成基本的底层相关操作，进行封装后成为OS内部的硬件驱动或者硬件接口层；基于硬件接口层(Hardware Driver&Interface)上进行开发对应应用场景的操作系统，不同的应用场景可能对于操作系统需要提供的系统服务要求不同，例如电信USIM需要具有SIM卡文件系统处理能力、基本的加解密和鉴权算法能力等；最上层等同于应用层，可以是SIM、USIM，或者自定义应用等实现特定应用场景的业务逻辑。具体实现时，Native Card OS层派发到具体应用进行处理，应用来负责整个流程的处理，但是具体执行某部分的逻辑会调用对应Native Card OS和硬件接口提供的能力和服务。
但是，Native COS全部使用C语言进行开发和实现，可能会根据芯片不同使用到部分汇编语言，不支持后更新应用，不支持Java Applet， 因此，在上述架构下编写的应用迁移到不同芯片平台的难度较高、不具备统一性、无法实现互联互通。
同时，智能卡安全芯片的操作系统还包括JavaCard COS，一般电信领域的普通USIM卡，金融、交通等领域的行业应用智能卡片均采用JavaCard COS，例如恩智浦的eSE芯片、高通基带芯片的SPU等。JavaCard COS具备灵活、可扩展、符合标准规范的互联互通性等优点。举例说明，JavaCard COS的架构可以如下面的表2所示。
表2
Figure PCTCN2020138518-appb-000001
上述底层(SE Chip)与硬件接口层(Hardware Driver&Interface)的实现方式与具体功能可以参考上述Native COS架构中的底层(SE Chip)与硬件接口层(Hardware Driver&Interface)的相关说明；JavaCard COS OS层需要通过JCVM和JCRE进行字节码的解析、处理、执行，还有对应Java Applet需要的生命周期管理、上下文环境保持和切换、访问控制隔离等；同时为了保证不同Java Applet的通用性和安全性处理，所以实现和搭建GP部分和对应的OPEN环境系统服务，处理Java Applet的安装、密钥管理、访问授权管理、选择和通道管理指令的处理和指令派发；最上层等同于应用层，可以是SIM、USIM、金融钱包应用、公交卡应用，或者是自定义的采用JC API实现的个性化应用等，用于实现特定应用场景的业务逻辑，在eUICC中会是ISD-R、ISD-P、ECASD等对应应用，还可以是后下载的Java Applet。其中，Java Applet可以使用对应封装好的JC API来实现，不关心底层和硬件接口；这里的Applet可以具备非常高的可移植性，只需要一次编译就可以在不同的JavaCard上面安装运行。并且，底层和中间层的实现大部分使用C语言进行开发，应用层则可以使用Java语言，基于JavaCard API进行开发，而且支持后下载Java Applet应用。
由于Native COS和JavaCard COS各具优势，有着各自的应用场景，目前业内两种COS独立并存，以满足不同客户的使用需求。对于智能卡 产线来说，针对Native COS和JavaCard COS需要采用不同的硬件生产流程，这无疑会加重产线的操作负担，降低产线的生产效率。为了解决现有两套COS架构独立并存而导致的智能卡产线生产效率低的问题，本发明实施例提供了一种Native与JavaCard动态切换的方法及设备，以下分别进行详细说明。
图1为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例一的流程示意图，如图1所示，本实施例的方法可以包括：
S101，将编译好的固件版本写入安全芯片，固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，兼容型系统架构以解耦的方式兼容Native和JavaCard。
本发明实施例的执行主体为电子设备。具体实现时，将Native COS和JavaCard COS支持的所有功能全部打包编译，并将编译后的固件版本写入安全芯片。
S102，获取固件版本中根安全域的个性化状态。
S103，若个性化状态指示根安全域未进行个性化操作，则向安全芯片发送控制指令，以使安全芯片根据控制指令实现固件版本中Native COS与JavaCard COS的动态切换。
可选的，若个性化状态指示根安全域已经进行个性化操作，则无法对安全芯片进行相应的COS动态切换。
本发明实施例提供的Native与JavaCard动态切换的方法，包括将编译好的固件版本写入安全芯片，固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，兼容型系统架构以解耦的方式兼容Native和JavaCard；获取固件版本中根安全域的个性化状态；若个性化状态指示根安全域未进行个性化操作，则向安全芯片发送控制指令，以使安全芯片根据控制指令实现固件版本中Native COS与JavaCard COS的动态切换。由于兼容型系统架构以解耦的方式同时兼容Native COS和JavaCard COS，那么Native COS和JavaCard COS中相同的内容无需重复开发，使得该兼容型系统架构的扩展性强，易于不断维护和升级迭代，从而提高了COS开发效率和版本迭代速度，降低了研发成本和周期；并且，通过控制指令实现了固件版本中Native COS与JavaCard COS的动态切换，这样大大增强了产线生产硬件的复用性，从而提高了智能卡的产线生产效率。
作为一种可以实现的方式，上述固件版本的根安全域在编译时可以预置有JavaCard限制参数，当JavaCard限制参数取值为第一预设值时，用于指示固件版本采用JavaCard COS，当JavaCard限制参数取值为第二预设值时，用于指示固件版本采用Native COS。并且，控制指令可以采用应用协议数据单元格式，包括第一控制指令和第二控制指令，第一控制指令用于将JavaCard限制参数设置为第一预设值，第二控制指令用于将JavaCard限制参数设置为第二预设值。
具体实现时，当JavaCard限制参数取值为第一预设值时，则固件版本采用JavaCard COS，此时，电子设备发送的控制指令可以包括第二控制指令，那么，安全芯片可以根据第二控制指令，将JavaCard限制参数设置为第二预设值，从而实现了由固件版本中的JavaCard COS切换至Native COS；当JavaCard限制参数取值为第二预设值时，则固件版本采用Native COS，此时，电子设备发送的控制指令可以包括第一控制指令，那么，安全芯片可以根据第一控制指令，将JavaCard限制参数设置为第一预设值，从而实现了由固件版本中的Native COS切换至JavaCard COS。
下面以一个具体的实现方式对上述JavaCard限制参数的设置进行举例说明，如下面的表3所示。
表3
Figure PCTCN2020138518-appb-000002
Figure PCTCN2020138518-appb-000003
其中，Data为上述JavaCard限制参数，将Data中的“XX XX”设置为“0x00 0x00”时，表征禁用JavaCard功能，可以对应于上述“第二控制指令用于将JavaCard限制参数设置为第二预设值”，即“0x00 0x00”可以对应于第二预设值，此时用于指示固件版本采用Native COS；将Data中的“XX XX”设置为“0xFF 0xFF”时，表征启用JavaCard功能，可以对应于上述“第一控制指令用于将JavaCard限制参数设置为第一预设值”，即“0xFF 0xFF”可以对应于第一预设值，此时用于指示固件版本采用JavaCard COS。
作为一种可以实现的方式，上述控制指令还可以包括第三控制指令，第三控制指令用于获取JavaCard限制参数的取值，以便根据JavaCard限制参数的取值，获取到固件版本所采用的COS。下面以一个具体的实现方式对上述第三控制指令进行举例说明，如下面的表4所示。
表4
Figure PCTCN2020138518-appb-000004
Figure PCTCN2020138518-appb-000005
其中，Data中的“XX XX”设置为“0xFF44”时，可以表征获取JavaCard限制参数的取值；Data中的“XX XX”设置为“0x00”时，可以表征获取JavaCard限制参数的取值的长度。
可选的，当安全芯片接收到上述第三控制指令后，假设向电子设备返回的DATA中的“XX XX”部分为“0x00 0x00”，则此时JavaCard限制参数的取值为第二预设值，即，此时固件版本采用Native COS；假设向电子设备返回的DATA中的“XX XX”部分为“0xFF 0xFF”，则此时JavaCard限制参数的取值为第一预设值，即，此时固件版本采用JavaCard COS。具体的，如下面的表5所示。
表5
Figure PCTCN2020138518-appb-000006
在上述实施例一的基础上，图2为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例二的流程示意图，如图2所示，本实施例的方法可以包括：
S201，将编译好的固件版本写入安全芯片。
其中，固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，兼容型系统架构以解耦的方式兼容Native和JavaCard。
S202，获取固件版本中根安全域的个性化状态。
S203，若个性化状态指示根安全域未进行个性化操作，则生成随机的对称加密的会话密钥。
具体实现时，可以采用密钥协商算法生成随机的对称加密的会话密钥，这里密钥协商算法可以包括椭圆曲线密钥协商算法(Elliptic Curve Diffie–Hellman key Exchange，ECDH)和RSA算法。
S204，使用非对称加密的私钥对会话密钥进行加密。
S205，将会话密钥密文发送至安全芯片，以使安全芯片根据固件版本中预置的与非对称加密的私钥相对应的非对称加密的公钥，从会话密钥密文中获取会话密钥明文。
S206，使用会话密钥对控制指令进行加密。
S207，向安全芯片发送控制指令密文，以使安全芯片根据获取到的会话密钥明文对控制指令密文进行解密以获取控制指令明文，并根据控制指令明文实现固件版本中Native COS与JavaCard COS的动态切换。
本发明实施例提供的Native与JavaCard动态切换的方法，通过上述加解密机制加强了电子设备和安全芯片之间建立数据通道的安全性，可以有效避免信息被克隆、重放攻击等问题。
作为一种可以实现的方式，在上述实施例二中，可以使用U盾物理组件进行加密与解密，U盾物理组件用于生成随机的对称加密的会话密钥和非对称加密的密钥对，U盾物理组件具备拆解密钥自毁的安全特性，以防恶意暴露拆破获取存储在U盾理组件内部的密钥，从而使用窃取或仿照密文数据的方式攻破COS动态切换的功能。
作为一种可以实现的方式，在上述实施例二中，会话密钥也可以包括高级加密标准AES密钥，非对称加密的私钥包括RSA私钥，非对称加密的公钥包括RSA公钥。
在上述实施例二的基础上，图3为本发明实施例提供的一种Native与JavaCard动态切换的方法的实施例三的流程示意图，如图3所示，在执行S207之后，本实施例的方法可以包括：
S301，接收安全芯片发送的执行结果密文。
其中，上述执行结果密文可以是安全芯片使用会话密钥对执行结果进行加密生成的，执行结果是安全芯片根据控制指令对固件版本中Native COS与JavaCard COS进行动态切换的执行结果。例如，执行结果可以是将固件版本中的Native COS切换至JavaCard COS，或者，执行结果也可以是将固件版本中的JavaCard COS切换至Native COS。
S302，使用会话密钥对执行结果密文进行解密，获取执行结果明文。
S303，根据获取到的执行结果明文生成用户提示信息。
具体实现时，当执行结果是将固件版本中的Native COS切换至JavaCard COS时，用户提示信息可以为指示固件版本中的Native COS已经切换至JavaCard COS的信息；或者，当执行结果是将固件版本中的JavaCard COS已经切换至Native COS时，用户提示信息可以为指示固件版本中的JavaCard COS已经切换至Native COS的信息。
本发明实施例提供的Native与JavaCard动态切换的方法，通过接收安全芯片发送的执行结果密文；使用会话密钥对执行结果密文进行解密，获取执行结果明文；根据获取到的执行结果明文生成用户提示信息，可以向用户展示固件版本中COS状态的执行结果。
作为一种可以实现的方式，图4为本发明实施例提供的一种兼容型系统架构的结构示意图，如图4所示，本发明实施例中的兼容型系统架构可以包括硬件抽象层、系统层和应用层。
其中，硬件抽象层可以用于对安全芯片提供的接口进行适配和封装，向系统层提供使用安全芯片的统一接口；系统层可以用于向应用层提供系统服务，包括派发模块、Native模块和JavaCard模块；应用层可以用于提供行业应用，包括Native应用和JavaCard应用。其中，派发模块可以用于将属于Native应用的数据派发给Native模块进行处理，将属于JavaCard应用的数据派发给JavaCard模块进行处理。
下面以两个具体的安全芯片为例，对本发明实施例中的兼容型系统架构以及Native与JavaCard动态切换的方法进行解释说明：
首先，以英飞凌SLE97安全芯片为例，通过下面表6所示的兼容型系统架构实现eUICC COS，如下面的表6所示。
表6
Figure PCTCN2020138518-appb-000007
Figure PCTCN2020138518-appb-000008
(1)最底层构建硬件抽象层(HAL)，HAL经过通用的抽象后解耦成不同的模块：非易失存储器NVM、Crypto(一种密码类库)、输出输出处理模块IO、随机存取存储器RAM以及日志LOG。HAL可以向系统层提供使用安全芯片的统一接口，对HAL以上的层次都是透明的，达到上层OS和应用对于不同芯片硬件接口的无感知，HAL所有统一接口的具体实现使用SLE97提供的接口进行适配和封装。
(2)中间层构建系统层(Framework)，可以提供系统服务，将电信、eUICC卡通用的系统服务和功能进行抽象，以实现代码复用，并且向上提供应用层的调用接口。其中，Native COS的系统层包括：Auth、码号管理器ProfileMgr、PPI、PPE、RFM、空中下载模块OTA、应用协议数据单元APDU、CAT、通道管理模块Channel、派发模块Dispatcher、文件系统模块FileSystem以及NVM管理器NVMM；JavaCard COS的系统层包括：随机存取存储器RAM、国际标准组织定义的开放环境GP OPEN、GP Amd、国际标准组织定义的应用编程接口GP API、USIM卡的应用编程接口USIM API、Java卡的应用编程接口JC API、UICC卡的应用编程接口UICC API、Java卡虚拟机JCVM以及Java卡运行环境JCRE。
(3)最上层构建应用层(Application)，实现电信和eUICC需要的 应用。其中，Native COS的应用层包括：根安全域应用ISD-R、UICC卡、Profile安全域ISD-P、安全认证和授权安全域ECASD、USIM卡以及固态驱动器(Solid State Disk，SSD)；JavaCard COS的应用层包括：Java Applet。
(4)最底层的入口和出口在HAL的IO中，然后解析传输层通讯协议后给到Native COS实现的派发模块Dispatcher进行分发，若判断需要支持Java Applet，则派发模块Dispatcher将属于JavaCard应用的数据派发给GP OPEN和相应的JCVM、JCRE等进行处理，否则将数据派发给Native COS系统层对应的模块进行处理。具体实现时，通过动态开关，采用私有定义的APDU指令格式，且增加对应APDU内容的加解密和签名验证，只有通过签名验证和解密成功后，才可以从外部操作动态开关Java Applet的特性支持。
(5)由于不论是否支持Java Applet都可能会使用到NVM管理器NVMM、FileSystem文件系统模块、应用协议数据单元APDU和通道管理模块Channel，因此以上模块均可以复用。并且进行灵活区分后，如果在需要支持Java Applet的场景下，再进行对应关联调用和额外处理即可。
(6)GP OPEN的支持也根据是否支持JavaCard是解耦和可选配置而确定，JCVM、JCRE和对应的各种API封装、RAM应用支持都是充分解耦的，如果不支持Java Applet，可以进行灵活切换；如果支持Java Applet，再参与整个业务流程的运行。
(7)支持后下载Java Applet和在Profile下载时一起加载和安装Applet，并且支持安装安全域SD。
通过上述表6所示的兼容型系统架构实现eUICC COS时，JavaCard COS可以实现的功能主要包括：下载JavaCard Package、安装JavaCard Applet、通过GP相关命令获取到JavaCard相关信息。上述JavaCard功能可以均由GP的标准命令提供。具体的，GP中支持上述功能的命令如下面的表7所示。
表7
Figure PCTCN2020138518-appb-000009
Figure PCTCN2020138518-appb-000010
如果需要禁用JavaCard功能，只实现Native COS，那么可以增加对卡内容管理相关功能的限制来达到启用/禁用JavaCard功能的目的。具体实施方法可以为：
(1)ISD-R中存储JavaCard限制参数，在编译时预置，在对ISD-R进行个性化操作(Personalize)之前可以进行修改，Personalize之后禁止修改；
(2)ISD-R中的Store Data命令新增对私有TAG(JC Function Restrict)的支持，用来设置和查询JC Function Restrict；
(3)使用Store Data命令修改时，检查ISD-R是否Personalize，如果已经Personalize，则返回相应错误；
(4)卡内容管理相关实现增加对JC Function Restrict的判断，如果为禁用状态，则命令不允许执行。
其中，具体的禁用过程可以为：
1)选择ISD-R；
2)查看当前支持情况，Store Data(Get JC Function Restrict)；
3)发送Store Data(Disable JC Function)。
具体的启用过程可以为：
1)选择ISD-R；
2)查看当前支持情况，Store Data(Get JC Function Restrict)；
3)发送Store Data(Enable JC Function)。
对于产线动态切换JavaCard COS和Native COS的私有指令设计以及产线动态切换JavaCard COS和Native COS的安全设计等，可以参考前述实施例的相关说明。
其次，以华大98M25安全芯片为例，通过下面表8所示的兼容型系统架构实现通用JavaCard COS。
表8
Figure PCTCN2020138518-appb-000011
(1)最底层构建硬件抽象层(HAL)，HAL经过通用的抽象后解耦成不同的模块：NVM、Crypto、IO、RAM以及LOG。HAL可以向系统层提供使用安全芯片的统一接口，对HAL以上的层次都是透明的，达到上层OS和应用对于不同芯片硬件接口的无感知，HAL所有统一接口的具体实现使用华大98M25提供的接口进行适配和封装，包括C和汇编的调用。
(2)中间层构建系统层(Framework)，可以提供系统服务，将电信等不同行业通用的系统服务和功能进行抽象，以实现代码复用，并且向上提供应用层的调用接口。其中，Native COS的系统层包括：金融系统服务、安全服务、其他服务、行业服务、APDU、Channel、Dispatcher、FileSystem以及NVMM；JavaCard COS的系统层包括：GP OPEN、GP Amd、GP API、金融API、JC API、电信API、JCVM以及JCRE。
(3)最上层构建应用层(Application)，实现电信和其他行业需要 的应用；其中，Native COS的应用层包括：金融、电信、交通以及其他；JavaCard COS的应用层包括：Java Applet。
(4)最底层的入口和出口在HAL的IO中，然后解析传输层通讯协议后给到Native COS实现的派发模块Dispatcher进行分发，若判断需要支持Java Applet，则派发模块Dispatcher将属于JavaCard应用的数据派发给GP OPEN和相应的JCVM、JCRE等进行处理，否则将数据派发给Native COS系统层对应的模块进行处理；具体实现时，通过动态开关，采用私有定义的APDU指令格式，且增加对应APDU内容的加解密和签名验证，只有通过签名验证和解密成功后，才可以从外部操作动态开关Java Applet的特性支持，并且，需要用到JavaCard、Java Applet支持时，可以通过宏定义、配置开关判断对应代码逻辑，如果采取编译时决定版本支持特性，可以不将对应部分代码编译进去减少最终版本的空间占用大小，减少冗余。
(5)由于不论是否支持Java Applet都可能会使用到NVM管理器NVMM、FileSystem文件系统模块、应用协议数据单元APDU和通道管理模块Channel，因此以上模块均可以复用。并且进行灵活区分后，如果在需要支持Java Applet的场景下，再进行对应关联调用和额外处理即可。
(6)GP OPEN的支持也根据是否支持JavaCard是解耦和可选配置而确定，JCVM、JCRE和对应的各种API封装、RAM应用支持都是充分解耦的，如果不支持Java Applet，可以进行灵活切换；如果支持Java Applet，再参与整个业务流程的运行。
(7)支持后下载Java Applet和在Profile下载时一起加载和安装Applet，并且支持安装安全域SD。
(8)在系统层和应用层可以针对不同行业的应用场景提供不同的实现，例如由于GP在电信和金融行业的要求不同，因此需要进行不同的实现，即需要提供不同的API给Java Applet调用，相应的在系统层、应用层、Java API部分、Java Applet部分都需要各自行业的实现。
对于禁用JavaCard功能的主要设计、动态切换JavaCard COS和Native COS的私有指令设计、产线动态切换JavaCard COS和Native COS的安全设计等，可以参考前述实施例的相关说明。
另外，相应于上述实施例所提供的Native与JavaCard动态切换的方 法，本发明实施例还提供了一种电子设备，该电子设备可以包括：存储器，用于存储程序；处理器，用于通过执行所述存储器存储的程序以实现本发明实施例的提供的Native与JavaCard动态切换的方法。
另外，相应于上述实施例所提供的Native与JavaCard动态切换的方法，本发明实施例还提供了计算机可读存储介质，该计算机可读存储介质包括程序，所述程序能够被处理器执行以实现实现本发明实施例的提供的Native与JavaCard动态切换的方法。
本文参照了各种示范实施例进行说明。然而，本领域的技术人员将认识到，在不脱离本文范围的情况下，可以对示范性实施例做出改变和修正。例如，各种操作步骤以及用于执行操作步骤的组件，可以根据特定的应用或考虑与系统的操作相关联的任何数量的成本函数以不同的方式实现(例如一个或多个步骤可以被删除、修改或结合到其他步骤中)。
另外，如本领域技术人员所理解的，本文的原理可以反映在计算机可读存储介质上的计算机程序产品中，该可读存储介质预装有计算机可读程序代码。任何有形的、非暂时性的计算机可读存储介质皆可被使用，包括磁存储设备(硬盘、软盘等)、光学存储设备(CD-ROM、DVD、Blu Ray盘等)、闪存和/或诸如此类。这些计算机程序指令可被加载到通用计算机、专用计算机或其他可编程数据处理设备上以形成机器，使得这些在计算机上或其他可编程数据处理装置上执行的指令可以生成实现指定的功能的装置。这些计算机程序指令也可以存储在计算机可读存储器中，该计算机可读存储器可以指示计算机或其他可编程数据处理设备以特定的方式运行，这样存储在计算机可读存储器中的指令就可以形成一件制造品，包括实现指定功能的实现装置。计算机程序指令也可以加载到计算机或其他可编程数据处理设备上，从而在计算机或其他可编程设备上执行一系列操作步骤以产生一个计算机实现的进程，使得在计算机或其他可编程设备上执行的指令可以提供用于实现指定功能的步骤。
虽然在各种实施例中已经示出了本文的原理，但是许多特别适用于特定环境和操作要求的结构、布置、比例、元件、材料和部件的修改可以在不脱离本披露的原则和范围内使用。以上修改和其他改变或修正将被包含在本文的范围之内。
前述具体说明已参照各种实施例进行了描述。然而，本领域技术人员将认识到，可以在不脱离本披露的范围的情况下进行各种修正和改变。 因此，对于本披露的考虑将是说明性的而非限制性的意义上的，并且所有这些修改都将被包含在其范围内。同样，有关于各种实施例的优点、其他优点和问题的解决方案已如上所述。然而，益处、优点、问题的解决方案以及任何能产生这些的要素，或使其变得更明确的解决方案都不应被解释为关键的、必需的或必要的。本文中所用的术语“包括”和其任何其他变体，皆属于非排他性包含，这样包括要素列表的过程、方法、文章或设备不仅包括这些要素，还包括未明确列出的或不属于该过程、方法、系统、文章或设备的其他要素。此外，本文中所使用的术语“耦合”和其任何其他变体都是指物理连接、电连接、磁连接、光连接、通信连接、功能连接和/或任何其他连接。
具有本领域技术的人将认识到，在不脱离本发明的基本原理的情况下，可以对上述实施例的细节进行许多改变。因此，本发明的范围应根据以下权利要求确定。

Claims (10)

  1. 一种Native与JavaCard动态切换的方法，其特征在于，包括：
    将编译好的固件版本写入安全芯片，所述固件版本基于兼容型系统架构开发包括Native COS和JavaCard COS，所述兼容型系统架构以解耦的方式兼容Native和JavaCard；
    获取所述固件版本中根安全域的个性化状态；
    若所述个性化状态指示所述根安全域未进行个性化操作，则向所述安全芯片发送控制指令，以使所述安全芯片根据所述控制指令实现所述固件版本中Native COS与JavaCard COS的动态切换。
  2. 如权利要求1所述的方法，其特征在于，所述固件版本的根安全域在编译时预置有JavaCard限制参数，当所述JavaCard限制参数取值为第一预设值时，用于指示所述固件版本采用JavaCard COS，当所述JavaCard限制参数取值为第二预设值时，用于指示所述固件版本采用Native COS；
    所述控制指令采用应用协议数据单元格式，包括第一控制指令和第二控制指令，所述第一控制指令用于将所述JavaCard限制参数设置为所述第一预设值，所述第二控制指令用于将所述JavaCard限制参数设置为所述第二预设值。
  3. 如权利要求2所述的方法，其特征在于，所述控制指令还包括第三控制指令，所述第三控制指令用于获取所述JavaCard限制参数的取值。
  4. 如权利要求1所述的方法，其特征在于，所述向所述安全芯片发送控制指令之前，所述方法还包括：
    生成随机的对称加密的会话密钥；
    使用非对称加密的私钥对所述会话密钥进行加密；
    将所述会话密钥密文发送至所述安全芯片，以使所述安全芯片根据所述固件版本中预置的与所述非对称加密的私钥相对应的非对称加密的公钥，从所述会话密钥密文中获取会话密钥明文；
    使用所述会话密钥对所述控制指令进行加密；
    所述向所述安全芯片发送控制指令包括：向所述安全芯片发送控制指令密文，以使所述安全芯片根据获取到的会话密钥明文对所述控制指令密文进行解密以获取控制指令明文。
  5. 如权利要求4所述的方法，其特征在于，所述方法还包括：
    接收所述安全芯片发送的执行结果密文，所述执行结果密文是所述安全芯片使用会话密钥对执行结果进行加密生成的，所述执行结果是所述安全芯片根据所述控制指令对所述固件版本中Native COS与JavaCard COS进行动态切换的执行结果；
    使用所述会话密钥对所述执行结果密文进行解密，获取执行结果明文；
    根据获取到的执行结果明文生成用户提示信息。
  6. 如权利要求4所述的方法，其特征在于，使用U盾物理组件进行加密与解密，所述U盾物理组件用于生成随机的对称加密的会话密钥和非对称加密的密钥对，所述U盾物理组件具备拆解密钥自毁的安全特性。
  7. 如权利要求4所述的方法，其特征在于，所述会话密钥包括高级加密标准AES密钥，所述非对称加密的私钥包括RSA私钥，所述非对称加密的公钥包括RSA公钥。
  8. 如权利要求1-7任一项所述方法，其特征在于，所述兼容型系统架构包括硬件抽象层、系统层和应用层；
    所述硬件抽象层用于对安全芯片提供的接口进行适配和封装，向所述系统层提供使用安全芯片的统一接口；
    所述系统层用于向所述应用层提供系统服务，包括派发模块、Native模块和JavaCard模块；
    所述应用层用于提供行业应用，包括Native应用和JavaCard应用；
    所述派发模块用于将属于Native应用的数据派发给所述Native模块进行处理，将属于JavaCard应用的数据派发给所述JavaCard模块进行处理。
  9. 一种电子设备，其特征在于，包括：
    存储器，用于存储程序；
    处理器，用于通过执行所述存储器存储的程序以实现如权利要求1-8中任一项所述的Native与JavaCard动态切换的方法。
  10. 一种计算机可读存储介质，其特征在于，包括程序，所述程序能够被处理器执行以实现如权利要求1-8中任一项所述的Native与JavaCard动态切换的方法。
PCT/CN2020/138518 2020-12-23 2020-12-23 Native与JavaCard动态切换的方法及设备 WO2022133774A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080027000.4A CN113692576A (zh) 2020-12-23 2020-12-23 Native与JavaCard动态切换的方法及设备
PCT/CN2020/138518 WO2022133774A1 (zh) 2020-12-23 2020-12-23 Native与JavaCard动态切换的方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/138518 WO2022133774A1 (zh) 2020-12-23 2020-12-23 Native与JavaCard动态切换的方法及设备

Publications (1)

Publication Number Publication Date
WO2022133774A1 true WO2022133774A1 (zh) 2022-06-30

Family

ID=78576405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/138518 WO2022133774A1 (zh) 2020-12-23 2020-12-23 Native与JavaCard动态切换的方法及设备

Country Status (2)

Country Link
CN (1) CN113692576A (zh)
WO (1) WO2022133774A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101739755A (zh) * 2009-12-04 2010-06-16 北京握奇数据系统有限公司 一种实现智能卡多业务应用的方法及装置
CN102054173A (zh) * 2010-12-24 2011-05-11 北京握奇数据系统有限公司 在智能卡上集成多电信应用的方法及其智能卡
CN106712964A (zh) * 2016-12-27 2017-05-24 广州智慧城市发展研究院 一种基于Java卡的应用验证方法及验证系统
CN107688473A (zh) * 2016-08-03 2018-02-13 北京数码视讯科技股份有限公司 一种智能卡内自定义安全域的实现方法及智能卡
CN108664327A (zh) * 2018-03-29 2018-10-16 北京中电华大电子设计有限责任公司 一种Java+Native应用的系统架构

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106227503A (zh) * 2016-07-29 2016-12-14 苏州国芯科技有限公司 安全芯片cos固件更新方法、服务端、终端及系统
DE102018115758A1 (de) * 2018-06-29 2020-01-02 Infineon Technologies Ag Sicherheit von Java-Card-Schlüsselobjekten

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101739755A (zh) * 2009-12-04 2010-06-16 北京握奇数据系统有限公司 一种实现智能卡多业务应用的方法及装置
CN102054173A (zh) * 2010-12-24 2011-05-11 北京握奇数据系统有限公司 在智能卡上集成多电信应用的方法及其智能卡
CN107688473A (zh) * 2016-08-03 2018-02-13 北京数码视讯科技股份有限公司 一种智能卡内自定义安全域的实现方法及智能卡
CN106712964A (zh) * 2016-12-27 2017-05-24 广州智慧城市发展研究院 一种基于Java卡的应用验证方法及验证系统
CN108664327A (zh) * 2018-03-29 2018-10-16 北京中电华大电子设计有限责任公司 一种Java+Native应用的系统架构

Also Published As

Publication number Publication date
CN113692576A (zh) 2021-11-23

Similar Documents

Publication Publication Date Title
US10853270B2 (en) Cryptographic pointer address encoding
WO2021217980A1 (zh) java代码的加壳方法与系统
EP2549380B1 (en) Information processing device, virtual machine generation method, and application software distribution system
TWI706660B (zh) 基於共享安全應用的密鑰傳遞方法及系統、儲存媒體、設備
CN105391840A (zh) 自动创建目标应用程序
US7962746B2 (en) Computer system and program creating device
US20180129794A1 (en) Method for Protecting Dex File from Decompilation in Android System
CN104318182A (zh) 一种基于处理器安全扩展的智能终端隔离系统及方法
US20180067777A1 (en) Application protection method, server, and terminal
CN102073520A (zh) 一种c++应用程序版本动态管理系统和方法
US11455430B2 (en) Secure element and related device
TWI724473B (zh) 移動終端中共享安全應用的方法及移動終端
JP2007526573A (ja) リトリーブ可能なトークン（例えば、スマートカード）内の独立した実行環境におけるアプリケーション間のセキュリティで保護されたリソース共有
US20210306304A1 (en) Method and apparatus for distributing confidential execution software
US20210109870A1 (en) Isolating memory within trusted execution environments
CN114402295A (zh) 安全运行时系统和方法
WO2022165771A1 (zh) 虚拟电子卡管理方法、系统及安全芯片、终端和存储介质
WO2016206393A1 (zh) 管理应用的方法和装置、实现读写操作的方法和装置
WO2022133774A1 (zh) Native与JavaCard动态切换的方法及设备
CN110888674B (zh) 在Python虚拟机中执行安全计算的方法及装置
WO2023016151A1 (zh) Linux系统安全应用的软件框架及创建方法
CN115544538A (zh) 一种数据传输方法、装置、设备及可读存储介质
CN110430046B (zh) 一种面向云环境的可信平台模块两阶段密钥复制方法
CN108319872B (zh) 一种封闭容器生成方法、装置及设备
CN107679858B (zh) 移动终端及移动支付方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20966354

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20966354

Country of ref document: EP

Kind code of ref document: A1