EP4720964A1 - Secure allocation of volatile memory for smart card application design in embedded systems - Google Patents

Secure allocation of volatile memory for smart card application design in embedded systems

Info

Publication number
EP4720964A1
EP4720964A1 EP23938663.4A EP23938663A EP4720964A1 EP 4720964 A1 EP4720964 A1 EP 4720964A1 EP 23938663 A EP23938663 A EP 23938663A EP 4720964 A1 EP4720964 A1 EP 4720964A1
Authority
EP
European Patent Office
Prior art keywords
smart card
volatile memory
allocation
transient
card applet
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP23938663.4A
Other languages
German (de)
French (fr)
Inventor
Yuexi Chen
Kiat TAN
Baoxiang KANG
Prasanna Hegde
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
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 Visa International Service Association filed Critical Visa International Service Association
Publication of EP4720964A1 publication Critical patent/EP4720964A1/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

In some embodiments, a computer-implemented method includes receiving a smart card applet for program execution on a smart card; determining whether a memory allocation type keyword provided via the smart card applet is of a transient memory allocation type; and when the memory allocation type keyword is of the transient memory allocation type, allocating volatile memory from the smart card for temporary storage of an object entity. In some embodiments of the computer-implemented method, the transient allocation type keyword is utilized to indicate whether the memory allocation type keyword is the transient memory allocation type.

Description

SECURE ALLOCATION OF VOLATILE MEMORY FOR SMART CARD APPLICATION
DESIGN IN EMBEDDED SYSTEMS BACKGROUND
[0001] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventor(s), to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
[0002] Smart cards are utilized by many consumers to perform various financial transactions. The memory available on smart cards to execute and store smart card applications is restricted due to the limited amount space available for memory on the smart cards. As a result, smart card application engineers often encounter design issues in designing the smart card applications using an object-oriented design. For example, memory constraints related to the storage of objects on the memory of smart cards often hinder the design of the smart applications. Therefore, a need exists to develop techniques for the design of smart applications that account for the memory constraints on smart cards.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] FIG. 1 illustrates a block diagram of a smart card in accordance with some embodiments. [0004] FIG. 2 illustrates a block diagram of an object entity volatile memory allocation system included in non-volatile memory that is utilized to allocate volatile memory in the smart card of FIG. 1 in accordance with some embodiments.
[0005] FIG. 3 is a flow diagram illustrating an object reference volatile memory allocation method in accordance with some embodiments. [0006] FIG 4 is a flow diagram illustrating an object volatile memory allocation method in accordance with some embodiments.
DETAILED DESCRIPTION
[0007] FIG. 1 illustrates a block diagram of a smart card 100 in accordance with some embodiments. In some embodiments, smart card 100 includes an embedded microcontroller 105 that includes a microprocessor 110, random access memory (RAM) 120, read-only memory (ROM) 130, non-volatile memory 140, a cryptographic module 150, a card reader interface 160, and volatile memory 180. In some embodiments, smart card 100 is configured to utilize an object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180 to object entities utilized in the execution of smart card applets on smart card 100. In some embodiments, an object entity may be, for example, an object and/or an object reference generated using an object-oriented programming language, such as, Java or other high-level object-oriented programming language. In some embodiments, an object reference refers to a variable that holds a reference to an instance of an object, where an object is an instance of a class. In some embodiments, in order to allocate volatile memory of volatile memory 180 for an object entity, the object entity volatile memory allocation system 170 (executed by microcontroller 110) is configured to utilize a volatile memory allocation type keyword defined in a smart card applet installed on the smart card 100 to allocate the volatile memory for the object entity (e.g., the object and/or the object reference). In some embodiments, use of the object entity volatile memory allocation system 170 allows smart card applets installed on smart card 100, such as, Java applets, that traditionally do not have access to volatile memory for storing object entities, to access volatile memory for storage and execution during runtime, as described further herein with reference to FIG 1 - FIG. 4. [0008] Tn some embodiments, with further reference to FTG. 1 , microprocessor 110 is any suitable central processing unit for executing commands and controlling smart card 100. In some embodiments, RAM 120 serves as storage for calculated results and as stack memory. In some embodiments, ROM 130 stores the operating system, fixed data, standard routines, and look up tables. In some embodiments, RAM 120 may serve as volatile memory 180 or vice versa.
[0009] In some embodiments, cryptographic module 150 is an optional hardware module used for performing a variety of cryptographic algorithms. Card reader interface 160 includes the software and hardware necessary for communication with the outside world. A wide variety of interfaces are possible. By way of example, card reader interface 160 may provide a contact interface, a close-coupled interface, a remote-coupled interface, or a variety of other interfaces. With a contact interface, signals from the microcontroller are routed to a number of metal contacts on the outside of the card which come in physical contact with similar contacts of a card reader device.
[0010] In some embodiments, non-volatile memory 140 includes object entity volatile memory allocation system 170. In some embodiments, the object entity volatile memory allocation system 170 is executable code configured to allocate volatile memory of volatile memory 180 to object entities utilized in the execution of smart card applets on smart card 100. In some embodiments, the non-volatile memory may be, for example, EPROM or EEPROM that serves to store information that must not be lost when the smart card 100 is disconnected from a power source but that must also be alterable to accommodate data specific to the individual smart card or any changes possible over the lifetime of the smart card. In some embodiments, additional information stored on non-volatile memory 140 may include, for example, a card identification number, a person al identification number, authorization levels, cash balances, credit limits, etc., or other information related to financial transactions associated with the smart card 100.
[0011] FIG. 2 illustrates a block diagram of object entity volatile memory allocation system 170 in accordance with some embodiments. In some embodiments, as stated previously, object entity volatile memory allocation system 170 is executable code configured to allocate volatile memory of volatile memory 180 for object entities utilized in the execution of a smart card applet 250 on smart card 100. In some embodiments, as stated previously, an object entity may be, for example, an object and/or an object reference generated using an object-oriented programming language, such as, Java or other high-level object-oriented programming language utilized to generate a smart card applet or application for smart card 100. In some embodiments, smart card applet 250 is an object-oriented programming smart card applet that, in addition to being configured to execute on smart card 100, is configured to define transient memory allocation object entity code (e.g., transient memory allocation object code and/or transient memory allocation object reference code) that is utilized by the object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180. In some embodiments, the object entity volatile memory allocation system 170 utilizes an object reference volatile memory allocation method 300 (described further herein with reference to FIG. 3) and/or an object volatile memory allocation method 400 (described further herein with reference to FIG. 4) to allocate volatile memory of volatile memory 180 for the object entities.
[0012] VOLATILE MEMORY ALLOCATION FOR OBJECT REFERENCES DURING INSTALLATION OF THE SMART CARD APPLET 250 ON SMART CARD 100
[0013] In some embodiments, the object entity volatile memory allocation system 170 includes a smart card applet assessment and allocation unit 241 of smart card applet installation unit 220 and a smart card applet assessment and allocation unit 242 of smart card virtual machine (SCVM) 230. In some embodiments, the smart card applet installation unit 220 is executable code that, in addition to being configured to perform tasks associated with installing the smart card applet 250 onto the smart card 100, is configured to utilize the smart card applet assessment and allocation unit 241 to perform a transient memory allocation object reference code assessment of smart card applet 250 in order to allocate the volatile memory of volatile memory 180 for an object reference defined in the smart card applet 250. In some embodiments, the transient memory allocation object reference code assessment is an assessment of the smart card applet 250 performed by the smart card applet assessment and allocation unit 241 for transient memory allocation object reference code, where the transient memory allocation object reference code is executable code in smart card applet 250 indicative of allocating volatile memory of volatile memory 180 for the object reference defined in the smart card applet 250. In some embodiments, transient memory allocation object reference code is defined in the smart card applet 250 and includes a volatile memory allocation object reference type keyword. In some embodiments, the volatile memory allocation object reference type keyword is a keyword in the smart card applet 250 indicative of allocating volatile memory of volatile memory 180 for storage of the object reference in volatile memory 180. In some embodiments, the volatile memory allocation object reference type keyword may be a transient memory allocation object reference type keyword, such as, for example, the keyword “transient” located prior to the object reference (e g., public transient MyClass objectRef in the volatile memory allocation object reference example illustrated using Java code below). In some embodiments, a volatile memory allocation object reference example that utilizes a transient memory allocation object reference type keyword to allocate volatile memory from volatile memory 180 is exemplified utilizing object-oriented programming in the Java code below:
[0014] public class Example {
[0015] /*** Example of Utilizing Transient Memory Allocation Object Reference Type
Keyword to Allocate Volatile Memory 180 for an Object Reference */
[0016] public transient MyClass obj ectRef;
[0017] public void setObjectRef(MyClass oRef){
[0018] /*** Example of Writing into objectRef on Volatile Memory of Volatile Memory
180 Resolves Programming Constraints */
[0019] objectRef = oRef;
[0020] }
[0021] }
[0022] In some embodiments, in the volatile memory allocation object reference example above, the executable code in smart card applet 250 defines an object reference (e.g., objectRef) as being allocated to volatile memory of volatile memory 180. As a result, during installation of the smart card applet 250 by smart card applet installation unit 220, the smart card applet assessment and allocation unit 241 allocates volatile memory of volatile memory 180 for the object reference as defined utilizing the volatile memory allocation object reference type keyword. Similar to the allocation of volatile memory of volatile memory 180 for an object reference using smart card applet assessment and allocation unit 241 being described herein, the allocation of volatile memory of volatile memory 180 for an object (or object instance) utilizing smart card applet assessment and allocation unit 242 during runtime is also described herein. [0023] VOLATILE MEMORY ALLOCATION FOR AN OBJECT DURING SMART CARD
RUNTIME
[0024] In some embodiments, in order to allocate volatile memory of volatile memory 180 for an object during runtime of the smart card 100, object entity volatile memory allocation system 170 utilizes the smart card applet assessment and allocation unit 242 of SCVM 230. In some embodiments, the SCVM 230 is executable code that, in addition to being configured to perform traditional smart card virtual machine tasks (e.g., interpreting and executing bytecode instructions, managing memory and resources, and providing the necessary runtime environment for smart card applets), is configured to utilize the smart card applet assessment and allocation unit 242 to perform a transient memory allocation object code assessment of smart card applet 250 and allocate volatile memory of volatile memory 180 for an object defined in the smart card applet 250 based on the transient memory allocation object code assessment. In some embodiments, the transient memory allocation object code assessment is an assessment of the smart card applet 250 for transient memory allocation object code, where the transient memory allocation object code is executable code in smart card applet 250 indicative of allocating volatile memory of volatile memory 180 for the object defined in a smart card applet 250. In some embodiments, transient memory allocation object code is defined in the smart card applet 250 and includes a volatile memory allocation object type keyword. In some embodiments, the volatile memory allocation object type keyword is a keyword in the smart card applet 250 indicative of allocating volatile memory of volatile memory 180 for storage of an object in volatile memory 180. In some embodiments, the volatile memory allocation object type keyword may be a transient memory allocation object type keyword, such as, for example, the keyword “TRANSIENT” utilized in a set allocation type method (e.g., System. setAllocationType(System. TRANSIENT), where setAllocationType is a method configured to set the allocation type defined in the set allocation type method (e.g., a
“TRANSIENT” type). In some embodiments, an example of the utilizing the transient memory allocation object type keyword to allocate volatile memory from volatile memory 180 is exemplified in the code below:
[0025] public class Example {
[0026] /*** Example of Allocation of Volatile Memory 180 for Object Reference*/
[0027] public transient MyClass objectRef;
[0028] /*** Example of Allocation of Volatile Memory 180 for Object
[0029] * MyClass() - is Allocated in Volatile Memory 180 (e.g., RAM)*/
[0030] public void createlnstance(){
[0031] // System Determines Whether Enough Volatile Memory of Volatile
Memory 180 Is Available
[0032] // Cursor Type for Memory Allocation
[0033] System. setAllocationType( ys.Qm. TRANSIENT),'
[0034] objectRef = new MyClass();
[0035] ystQm.setAllocationType( ys.Qm.DEFA ULT),'
[0036] }
[0037] }
[0038] In some embodiments, in the volatile memory allocation object example above, the executable code in smart card applet 250 defines an object (e.g., MyClass) as being allocated to volatile memory of volatile memory 180. In some embodiments, the smart card applet 250 utilizes a set allocation type (e.g., setAllocationType) with the transient memory allocation object type keyword “TRANSIENT” to indicate to the smart card applet assessment and allocation unit 242 during runtime to allocate volatile memory of volatile memory 180 to the object defined utilizing “new” in the object-oriented programming language (e.g., objectRef=new MyClass();). In some embodiments, setAllocationType is a method or predefined code, such as, for example, a cursor, configured to allocate the object utilizing the transient memory allocation object type keyword (e.g., TRANSIENT). In some embodiments, during runtime of the smart card applet 250 by smart card applet installation unit 220, the smart card applet assessment and allocation unit 241 allocates volatile memory of volatile memory 180 for the object as defined utilizing the transient memory allocation object type keyword. In some embodiments, the DEFAULT keyword is utilized by the set allocation type (e.g., System. setAllocationType(System.DEF AULT)) in the smart card applet 250 to stop the allocation of volatile memory 180 for additional objects not defined utilizing the transient memory allocation object type keyword (System. setAllocationType(System. TRANSIENT)) and utilize a default memory allocation mode defined in the smart card applet 250 and/or smart card 100 (e.g., a non-volatile memory allocation mode). In some embodiments, the allocation of the volatile memory 180 for an object reference and the object is described further herein with reference to FIG. 3 and FIG. 4, respectively.
[0039] FIG. 3 is a flow diagram illustrating an object reference volatile memory allocation method 300 in accordance with some embodiments. In some embodiments, the object reference volatile memory allocation method 300 is utilized by the smart card applet assessment unit and allocation unit 241 of object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180 for an object reference defined in the smart card applet 250 utilizing a transient memory allocation object reference type keyword. In some embodiments, the method, process steps, or stages illustrated in the figures may be implemented as an independent routine or process, or as part of a larger routine or process. Note that each process step or stage depicted may be implemented as an apparatus that includes a processor executing a set of instructions, a method, or a system, among other embodiments. In some embodiments, the object reference volatile memory allocation method 300 is described with reference to the figures described herein.
[0040] In some embodiments, at operation 310, smart card applet assessment and allocation unit 241 of smart card applet installation unit 220 receives smart card applet 250 from, for example, an external entity, such as, for example, a card issuer or card management system, and commences the process of installing the smart card applet 250 onto non-volatile memory 140. In some embodiments, as stated previously, smart card applet 250 is an object-oriented programming smart card applet that, in addition to being configured to execute on smart card 100, is configured to define transient memory allocation object entity code utilized by the object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180. In some embodiments, after receiving the smart card applet 250, operation 310 proceeds to operation 320.
[0041] In some embodiments, at operation 320, during the installation process of the smart card applet 250, smart card applet assessment and allocation unit 241 assesses the smart card applet 250 to determine whether an object reference in smart card applet 250 has been designated for allocation of volatile memory in volatile memory 180 (e g., by performing the transient memory allocation object reference code assessment of smart card applet 250). In some embodiments, smart card applet assessment and allocation unit 241 performs the transient memory allocation object reference code assessment by performing an assessment of the smart card applet 250 for transient memory allocation object reference code indicative of allocating volatile memory of volatile memory 180 for the object reference defined in the smart card applet 250. In some embodiments, as stated previously, the transient memory allocation object reference code includes a volatile memory object reference allocation type keyword that may be a transient memory allocation object reference type keyword, such as, for example, the keyword “transient” associated with the object reference. In some embodiments, for the example given with reference to FIG. 2, for a smart card 100 (e g., a Java Card utilizing Java object-oriented programming language), volatile memory of volatile memory 180 may be allocated using the transient memory allocation object reference type keyword transient in the following Java code, “public transient MyClass objectRef’, as described previously herein with reference to FIG. 2. In some embodiments, as part of the transient memory allocation object reference code assessment, the smart card applet assessment and allocation unit 241 examines the bytecode of the smart card applet 250 and inspects the class hierarchy, static fields, constant pool, and methods in the smart card applet 250. In some embodiments, during the transient memory allocation object reference code assessment, when the smart card applet assessment and allocation unit 241 identifies the object reference and determines (using the transient memory allocation object reference type keyword) that the object reference requires volatile memory allocation from volatile memory 180, operation 320 proceeds to operation 330.
[0042] In some embodiments, at operation 330, when an object reference is identified as a transient memory allocation object reference type, smart card applet assessment and allocation unit 241 allocates volatile memory of volatile memory 180 for the object reference. In some embodiments, the object reference volatile memory allocation involves reserving a specific portion of volatile memory 180 dedicated to the object reference (e.g., objectRef) and its associated data. Tn some embodiments, by allocating memory during the installation process, the smart card applet assessment and allocation unit 241 ensures that the object reference has a predetermined volatile memory space available for efficient access and management during the execution of the smart card applet 250 on the smart card 100. In some embodiments, the embodiments described herein improve upon existing memory allocation systems and techniques by optimizing the utilization of volatile memory 180 during the installation of the smart card applet 250 and facilitating the proper functioning of the smart card applet 250 with regards to the identified object references. For example, in some embodiments, utilizing the embodiments described herein improves upon other memory allocation systems by allowing for the updating of a dynamic variable without stressing memory, allowing fast memory access when retrieving data, and saving stack space without having to pass an object reference in an argument of a method during a call of the method, whilst, for example, keeping the application design in proper object oriented design methodologies.
[0043] FIG. 4 is a flow diagram illustrating an object volatile memory allocation method 400 in accordance with some embodiments. In some embodiments, the object volatile memory allocation method 400 is utilized by the smart card applet assessment unit and allocation unit 242 of object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180 for an object defined in the smart card applet 250 utilizing a transient memory allocation object type keyword. In some embodiments, the method, process steps, or stages illustrated in the figures may be implemented as an independent routine or process, or as part of a larger routine or process. Note that each process step or stage depicted may be implemented as an apparatus that includes a processor executing a set of instructions, a method, or a system, among other embodiments. Tn some embodiments, the object volatile memory allocation method
400 is described with reference to the figures described herein.
[0044] In some embodiments, at operation 410, smart card applet assessment and allocation unit 241 of smart card applet installation unit 220 receives smart card applet 250 and installs the smart card applet 250 onto non-volatile memory 140. In some embodiments, as stated previously, smart card applet 250 is an object-oriented programming applet that, in addition to being configured to execute on smart card 100, is configured to define transient memory allocation object entity code utilized by the object entity volatile memory allocation system 170 to allocate volatile memory of volatile memory 180. In some embodiments, after receiving and installing the smart card applet 250, operation 410 proceeds to operation 420.
[0045] In some embodiments, at operation 420, SCVM 230 interprets and executes the code in the smart card applet 250 during runtime in a smart card runtime environment of the smart card 100. In some embodiments, the smart card runtime environment, may be, for example, a Java card runtime environment where the methods in the smart card applet 250 may be invoked in response to various events or commands. In some embodiments, the execution of the smart card applet 250 typically follows a specific lifecycle, which includes the selection and initialization of the smart card applet 250, the processing of commands, and the termination or deselection of the smart card applet 250. In some embodiments, the smart card runtime environment manages the execution of the smart card applet 250, performs some of the embodiments described herein, which includes, for example, executing some of the methods described herein (e g , object volatile memory allocation method 400), and provides security and integrity features described further herein. In some embodiments, during execution of the smart card applet 250, operation 420 proceeds to operation 430. [0046] Tn some embodiments, at operation 430, during the execution of the smart card applet 250 at runtime, smart card applet assessment and allocation unit 242 performs the transient memory allocation object code assessment of smart card applet 250. In some embodiments, smart card applet assessment and allocation unit 242 performs the transient memory allocation object code assessment by performing an assessment of the smart card applet 250 for a transient memory allocation object type keyword indicative of allocating volatile memory of volatile memory 180 for the object defined in the smart card applet 250. In some embodiments, as stated previously, the volatile memory object allocation type keyword may be a transient memory allocation object type keyword, such as, for example, the keyword “TRANSIENT” utilized in a set allocation type method (e.g., System. setAllocationType(System. TRANSIENT), where setAllocationType is a cursor or cursor-like method configured to set the allocation type the type defined in the method (e.g., a “TRANSIENT” type). In some embodiments, a cursor-like method is a method that utilizes a transient memory allocation object type keyword and has both a start point of volatile memory allocation for an object (e.g., a start object volatile memory allocation point) and a stop point of volatile memory allocation for an object (e.g., a stop object volatile memory allocation point). For example, System. setAllocationType(System. TRANSIENT) may be a start point that indicates that the object or objects defined before the stop point but after the
System. setAllocationType(System. TRANSIENT) should be allocated volatile memory in volatile memory 180. In some embodiments, System. setAllocationType(System.DEF AULT) may be a stop point that indicates that the allocation volatile memory of volatile memory 180 indicated by System. setAllocationType(System. TRANSIENT) should cease after Sy stem . set All ocationTy pe(Sy stem .DEF AULT) . [0047] Tn some embodiments, during the transient memory allocation object code assessment, the smart card applet assessment and allocation unit 242 examines the bytecode instructions, class relationships, static fields, constant pool entries, and method invocations to identify objects intended for volatile memory allocation in volatile memory 180. In some embodiments, during the transient memory allocation object reference assessment, when the smart card applet assessment and allocation unit 242 identifies an object and determines, using the transient memory allocation object type keyword, that the object requires volatile memory allocation from volatile memory 180, operation 430 proceeds to operation 440.
[0048] In some embodiments, at operation 440, when the transient memory allocation object code assessment indicates that the object should be allocated to volatile memory of volatile memory 180, the smart card applet assessment and allocation unit 242 allocates and reserves the volatile memory within the volatile memory 180. In some embodiments, the allocation of volatile memory of volatile memory 180 for the object involves reserving a specific portion of volatile memory 180 dedicated to the object and its associated data. In some embodiments, the smart card applet assessment and allocation unit 242 of SCVM 230 may be configured to dynamically allocate volatile memory from an object heap in volatile memory 180 to create and manage the objects allocated volatile memory. In some embodiments, volatile memory from volatile memory 180 is allocated for object instantiation, method invocations, and other runtime operations. In some embodiments, by allocating memory during runtime utilizing the embodiments described herein, the smart card applet assessment and allocation unit 241 ensures that the object and its associated data have a predetermined volatile memory space available for efficient access and management during runtime and the execution of the smart card applet 250 on the smart card 100. Further, the volatile memory allocation for objects utilizing the embodiments described herein ensures that the objects can be efficiently accessed and modified during runtime and the execution of the smart card applet 250. In some embodiments, by selectively allocating objects to volatile memory, the smart card applet assessment and allocation unit 242 optimizes memory utilization and enhances the performance of the smart card 100, allowing for effective management and execution of smart card applets in resource-constrained environments.
[0049] In some embodiments, smart card 100 may include a security and integrity unit. In some embodiments, the security and integrity unit may be executable code configured to perform encryption and checksum operations for the embodiments described herein. In some embodiments, cryptographic module 150 may be configured to perform the operations of the security and integrity unit. In some embodiments, for example, with reference to the example in FIG. 2, when, at runtime, volatile memory of volatile memory 180 is allocated for the object and an object is created (e.g., using “objectRef = new MyClass()”), security and integrity unit may perform encryption operations and checksum operations on the newly created object (e.g., MyClass()).
[0050] In some embodiments, for checksum operations, when the object is created or modified, a checksum algorithm is applied to the object's data. In some embodiments, the security and integrity unit generates a checksum value based on the content of the object and utilizes the checksum to verify the integrity of the object. In some embodiments, for encryption operations, when the object is encrypted by the security and integrity unit, the object’s data is processed using an encryption algorithm along with an encryption key. In some embodiments, the encryption algorithm ascertains the data associated with the object and transforms the data associated with the object into ciphertext, which is an encrypted representation of the object data. Tn some embodiments, the encryption key may be utilized by the security and integrity unit to control the encryption process and for decryption of the object.
[0051] In some embodiments, in order to read data associated with the objects and object references written to the volatile memory allocated by the object entity volatile memory allocation system 170, the SCVM 230 determines the type of memory the data is stored in (e.g., volatile memory or non-volatile memory), and if the memory type is a transient memory type (e.g., volatile memory), the SCVM 230 then verifies the checksum. In some embodiments, when the checksum is verified, the smart card applet 250 utilizes the read data for the prescribed actions in the smart card applet 250. In some embodiments, when the data associated with objects and object references stored in volatile memory 180 have been encrypted by the security and integrity unit, the data is decrypted before processing the data.
[0052] In some embodiments, in order to release the volatile memory that has been allocated by the object entity volatile memory allocation system 170, when the object or object reference usage is finished, the object or object refence is set to null, then the allocated volatile memory is released from volatile memory 180 into a free pool of volatile memory (e.g., volatile memory that may be allocated for new objects or object references).
[0053] In some embodiments, the object entity volatile memory allocation system may be configured to update or write an object entity to volatile memory for an object reference or object during runtime of the smart card applet.
[0054] Tn some embodiments, a computer-implemented method includes receiving a smart card applet for program execution on a smart card; determining whether a memory allocation type keyword provided via the smart card applet is of a transient memory allocation type; and when the memory allocation type keyword is of the transient memory allocation type, allocating volatile memory from the smart card for temporary storage of an object entity.
[0055] In some embodiments, the computer-implemented method further includes using a transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
[0056] In some embodiments of the computer-implemented method, the object entity is either an object or an object reference.
[0057] In some embodiments of the computer-implemented method, a start cursor and an end cursor are utilized during allocation of the volatile memory for the object.
[0058] In some embodiments of the computer-implemented method, the start cursor is utilized in a smart card runtime environment during the allocation of the volatile memory.
[0059] In some embodiments of the computer-implemented method, the volatile memory allocated for the object is utilized for a new object instance of the object.
[0060] In some embodiments of the computer-implemented method, the end cursor is utilized to stop allocation of volatile memory for the object.
[0061] In some embodiments of the computer-implemented method, transient is the transient allocation type keyword.
[0062] In some embodiments, a computer-implemented method includes receiving a smart card applet at a smart card that defines a memory allocation type keyword for allocation of memory for an object reference; determining whether the memory allocation type keyword provided via the smart card applet is a transient memory allocation type; and when the memory allocation type keyword is the transient memory allocation type, allocating volatile memory from the smart card for temporary storage of the object reference. [0063] Tn some embodiments, a computer-implemented method includes using a transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
[0064] In some embodiments of the computer-implemented method further includes, writing data into the volatile memory allocated for the object reference.
[0065] In some embodiments of the computer-implemented method, the volatile memory is allocated during an installation of the smart card applet.
[0066] In some embodiments of the computer-implemented method, the volatile memory allocated during the installation of the smart card applet is random-access memory.
[0067] In some embodiments of the computer-implemented method, when there is a context switch from the smart card applet after the object reference has been stored in the volatile memory, the object reference stored in the volatile memory remains in the volatile memory in order to retrieve the object reference after context switching back to the smart card applet.
[0068] In some embodiments of the computer-implemented method, the memory allocation type keyword provided via the smart card applet is a transient memory allocation type whose type is determined during installation of the smart card applet onto the smart card.
[0069] In some embodiments of the computer-implemented method, when the memory allocation type keyword is not the transient memory allocation type, allocating non-volatile memory from the smart card for storage of the object reference.
[0070] Tn some embodiments, an object entity volatile memory allocation system includes an object reference smart card applet assessment and allocation unit; and an object smart card applet assessment and allocation unit, wherein the object entity volatile memory allocation system utilizes the object reference smart card applet assessment and allocation unit to allocate volatile memory for an object reference during installation of a smart card applet and the object entity volatile memory allocation system utilizes the object smart card applet assessment and allocation unit to allocate the volatile memory for an object during runtime of the smart card applet.
[0071] In some embodiments of the object entity volatile memory allocation system, a transient allocation object reference type keyword is utilized to allocate volatile memory for the object reference during an installation of a smart card applet.
[0072] In some embodiments of the object entity volatile memory allocation system, a transient allocation object type keyword is utilized to allocate the volatile memory for an object during execution of the smart card applet at a runtime of the smart card applet.
[0073] In some embodiments of the object entity volatile memory allocation system, in order to determine whether a keyword in the smart card applet is a transient allocation object reference type keyword or a transient allocation object type keyword, the object entity volatile memory allocation system performs a transient memory allocation object reference code assessment of the smart card applet and a transient memory allocation object code assessment of the smart card applet.

Claims

WHAT IS CLAIMED IS:
1. A computer-implemented method, comprising: receiving a smart card applet for program execution on a smart card; determining whether a memory allocation type keyword provided via the smart card applet is of a transient memory allocation type; and when the memory allocation type keyword is of the transient memory allocation type, allocating volatile memory from the smart card for temporary storage of an object entity.
2. The computer-implemented method of claim 1, further comprising: using a transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
3. The computer-implemented method of claim 2, wherein: the object entity is either an object or an object reference.
4. The computer-implemented method of claim 3, wherein: a start cursor and an end cursor are utilized during allocation of the volatile memory for the object.
5. The computer-implemented method of claim 4, wherein: the start cursor is utilized in a smart card runtime environment during the allocation of the volatile memory.
6. The computer-implemented method of claim 5, wherein: the volatile memory allocated for the object is utilized for a new object instance of the object.
7. The computer-implemented method of claim 6, wherein: the end cursor is utilized to stop allocation of volatile memory for the object.
8. The computer-implemented method of claim 7, wherein: transient is the transient allocation type keyword.
9. A computer-implemented method, comprising: receiving a smart card applet at a smart card that defines a memory allocation type keyword for allocation of memory for an object reference; determining whether the memory allocation type keyword provided via the smart card applet is a transient memory allocation type; and when the memory allocation type keyword is the transient memory allocation type, allocating volatile memory from the smart card for temporary storage of the object reference.
10. The computer-implemented method of claim 9, further comprising: using a transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
11. The computer-implemented method of claim 10, further comprising: writing data into the volatile memory allocated for the object reference.
12. The computer-implemented method of claim 11, wherein: the volatile memory is allocated during an installation of the smart card applet.
13. The computer-implemented method of claim 12, wherein: the volatile memory allocated during the installation of the smart card applet is randomaccess memory.
14. The computer-implemented method of claim 13, wherein: when there is a context switch from the smart card applet after the object reference has been stored in the volatile memory, the object reference stored in the volatile memory remains in the volatile memory in order to retrieve the object reference after context switching back to the smart card applet.
15. The computer-implemented method of claim 14, wherein: the memory allocation type keyword provided via the smart card applet is a transient memory allocation type whose type is determined during installation of the smart card applet onto the smart card.
16. The computer-implemented method of claim 15, wherein: when the memory allocation type keyword is not the transient memory allocation type, allocating non-volatile memory from the smart card for storage of the object reference.
17. An object entity volatile memory allocation system, comprising: an object reference smart card applet assessment and allocation unit; and an object smart card applet assessment and allocation unit, wherein the object entity volatile memory allocation system utilizes the object reference smart card applet assessment and allocation unit to allocate volatile memory for an object reference during installation of a smart card applet and the object entity volatile memory allocation system utilizes the object smart card applet assessment and allocation unit to allocate the volatile memory for an object during runtime of the smart card applet.
18. The object entity volatile memory allocation system of claim 17, wherein: a transient allocation object reference type keyword is utilized to allocate volatile memory for the object reference during an installation of a smart card applet.
19. The object entity volatile memory allocation system of claim 18, wherein: a transient allocation object type keyword is utilized to allocate the volatile memory for an object during execution of the smart card applet at a runtime of the smart card applet.
20. The object entity volatile memory allocation system of claim 19, wherein: in order to determine whether a keyword in the smart card applet is a transient allocation object reference type keyword or a transient allocation object type keyword, the object entity volatile memory allocation system performs a transient memory allocation object reference code assessment of the smart card applet and a transient memory allocation object code assessment of the smart card applet.
EP23938663.4A 2023-05-25 2023-05-25 Secure allocation of volatile memory for smart card application design in embedded systems Pending EP4720964A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2023/023540 WO2024242679A1 (en) 2023-05-25 2023-05-25 Secure allocation of volatile memory for smart card application design in embedded systems

Publications (1)

Publication Number Publication Date
EP4720964A1 true EP4720964A1 (en) 2026-04-08

Family

ID=93590272

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23938663.4A Pending EP4720964A1 (en) 2023-05-25 2023-05-25 Secure allocation of volatile memory for smart card application design in embedded systems

Country Status (3)

Country Link
EP (1) EP4720964A1 (en)
CN (1) CN120937030A (en)
WO (1) WO2024242679A1 (en)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1980002610A1 (en) * 1979-05-23 1980-11-27 Telxon Corp Portable data entry device including dynamic partitioning of data memory
US6772954B2 (en) * 2001-10-09 2004-08-10 Activcard Ireland Limited Method of encoding information within directory files on an integrated circuit smart card
WO2017105441A1 (en) * 2015-12-16 2017-06-22 Hewlett Packard Enterprise Development Lp Allocate memory based on memory type request
IN201941036171A (en) * 2019-09-09 2019-09-27

Also Published As

Publication number Publication date
WO2024242679A1 (en) 2024-11-28
CN120937030A (en) 2025-11-11

Similar Documents

Publication Publication Date Title
JP3766052B2 (en) Microcontroller using high-level programming language
US6052690A (en) Coherent data structure with multiple interaction contexts for a smart card
Faraj et al. Investigation of Java Smart Card Technology for Multi-Task Applications
US6883163B1 (en) Populating resource-constrained devices with content verified using API definitions
US7506175B2 (en) File language verification
AU712005B2 (en) System and method for runtime optimization of private variable function calls in a secure interpreter
JP5457496B2 (en) Memory management of portable data storage media
US7467376B2 (en) Semantic analysis based compression of interpreted code by replacing object instruction groups with special instruction specifying a register representing the object
CN102073544A (en) Page operation-based electrically erasable programmable read-only memory (EEPROM) cache method
US7702872B2 (en) Java smart card chip having memory area reserved for global variables
CN102428472B (en) Secure execution of native code
EP4720964A1 (en) Secure allocation of volatile memory for smart card application design in embedded systems
JP3515417B2 (en) Methods and apparatus for creating objects in non-persistent memory and methods for maintaining accessibility to objects
Oestreicher Transactions in java card
KR102263692B1 (en) Ethereum smart contract virtual machine bytecode security improve method
Marlet et al. Security properties and Java Card specificities to be studied in the SecSafe project
CN111966443B (en) Smart card and working method thereof
US8458790B2 (en) Defending smart cards against attacks by redundant processing
CN110888674A (en) Method and device for executing security calculation in Python virtual machine
Jean et al. Using some database principles to improve cooperation in multi-application smart cards
CN113378177A (en) Safe and open Native multi-application system architecture and Native application program execution method
KR101140522B1 (en) System and Method for Managing Object
US20120131634A1 (en) Method of executing an application embedded in a portable electronic device
Srinivas Java New Technology for Smart Cards
Fontaine et al. On-device control flow verification for java programs

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20260102

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR