98
`
`CHAPTER 8 WORKING WITH APDUS
`
`◄
`
`code in an exception object it catches. In either case, the JCRE returns
`1S07816. SW_UNKNOWN _(0x6F00) without specifying a precise diagnosis. If the
`error is more severe, the JCRE may decide to mute the card, block the
`applet for execution, or perform any necessary operations to ensure the
`security and integrity of the applet and the card.
`
`8.4 Protocol-Specific APDU Processing
`
`In the Java Card platform, applet developers program at the application layer-han(cid:173)
`dling APDUs using the APDU class. The APDU class provides a simplified and com(cid:173)
`mon interface to applets regardless of the underlying transport protocol (T=O or
`T=l) used. However, some legacy smart card systems were designed employing a
`specific transport protocol. To be compatible with such systems, applets must use
`protocol-specific attributes so they can communicate with a lar~e base of installed
`card acceptance devices. Therefore, the APDU class also defines methods that an
`applet can use to discover the underlying protocol, to schedule space for receiving
`and sending data, and to request additional processing time.
`This section explains why these methods are defined and how to use them.
`However, all the methods defined in the APDU class can be used in a protocol-inde(cid:173)
`pendent way. In other words, knowledge of the transport protocol details is not
`necessary for using the methods.
`Most applet developers can skim through this section or use it as a reference
`when a special case in programming an applet arises.
`
`8.4.1 Method getProtoco 1
`
`public static byte getProtocol()
`
`The method getProtocol returns the ISO 7816 transport protocol type supported on
`the Java Card platform. The result can be either APDU. PROTOCOL_ T0 for the T=O pro(cid:173)
`tocol or APDU. PROTOCOL_ Tl for the T=l protocol.
`
`8.4.2 Method getlnBl ockS i ze
`
`public static
`
`short getinBlockSize()
`
`The method getinBl ockSi ze returns the configured incoming block size. The T:::I
`protocol is a block-oriented protocol. An APDU command is transmitted in one
`block or in a few blocks if the chaining mechanism is supported. The chaining
`mechanism allows a long APDU command to be transmitted in consecutive blocks.
`
`IPR2022-00413
`Apple EX1049 Page 102
`
`

`

`PROTOCOL-SPECIFIC APDU PROCESSING
`
`99
`
`Each block consists of three fields: prologue field, information field, and epilogue
`field. The prologue field and the epilogue field describe the block, and the informa(cid:173)
`tion field carries the APD U.
`In the T=l protocol, the block size returned by this method corresponds to the
`IFSC (information field size on card) parameter. The IFSC specifies the maximum
`length of the information field in a block that can be accepted by the card. The
`IFSC value varies from card to card. The default value of IFSC is 32 bytes. This is
`why the minimum APDU buffer size is set to 37 bytes (5-byte header plus the
`default IFSC value of 32 bytes). Typically, the APDU buffer is somewhat larger,
`which allows an applet to reserve a few bytes of data in the APDU buffer and still
`receive subsequent command data bytes without the risk of overflow.
`The T=0 protocol is a byte-oriented protocol. It has no such maximum length
`requirement and needs to receive only 1 byte at a time. Thus, the getinBl ock~i ze
`method returns 1 for the T=0 protocol.
`An applet can use the getinBl ockSi ze method in a protocol-independent way
`to indicate the maximum number of bytes that can be received in the APDU buffer
`in a single underlying 1/0 operation. The recei veBytes and setlncomi ngAndRe.(cid:173)
`cei ve methods consist of one or more such 1/0 operations.
`In addition, an applet can check In Bl ockSi ze to ensure that there is enough
`space remaining in the APDU buffer when the receiveBytes method is invoked.
`For example, to optimize the space usage, an applet may conserve the beginning n
`bytes in the APDU buffer for storing intermediate data without using a separate
`buffer. To do so, the applet needs to find out whether the remaining bytes in the
`APDU buffer are enough to hold at least one block of the data that can be sent by
`the host.
`
`8.4.3 Method getOutBlockSize
`
`public
`
`static
`
`short
`
`getOutBlockSize()
`
`The getOutBl ockSi ze method is analogous to the getinBl ockSi ze method. It
`returns the configured outgoing block size. In the T=l protocol, this size corre(cid:173)
`sponds to IFSD (information field size for interface device}--the maximum length
`of the information fielq in a Dlock that can be accepted by the host. The initial value
`defined in ISO 7816-3 is 32 bytes. In the T=O protocol, this method returns 258,
`accounting for 2 status bytes. Thus the maximum data bytes that can be sent from
`the applet to the host is 256.
`The IFSD specifies the attribute at the host side. Unlike InBlockSize, an applet
`normally does not check OutBlockSize. For the T=l protocol, if the JCRE cannot
`send all the data in one block-the
`total number of response data reaches the limit
`
`IPR2022-00413
`Apple EX1049 Page 103
`
`

`

`100
`
`CHAPTER 8 WORKING WITH APDUS
`
`◄
`
`JCRE can divide the data into blocks and send the blocks by using
`of IFSD-the
`the chaining mechanism. However, if the underlying T=l protocol does not suppon
`chaining, when the JCRE cannot respond to the host with a large piece of data, it
`throws an APDUExcepti on. The following code sample demonstrates how an applet
`can work around this limitation when block chaining is not allowed.
`
`logs for
`
`in a byte array
`each log record is stored
`log record size
`is less
`than 256 bytes
`
`II a wallet applet stores
`transaction
`II the last
`three
`transactions
`II
`II for simplicity,
`II and the total
`II
`II to respond to a READ_TRANSACTION_LOG
`APDU command, the
`II wallet applet sends each transaction
`log record to the host
`II
`II check the protocol
`if (apdu.getProtocol() == APDU.PROTOCOL_T0)
`{
`II no problem, the transaction
`logs can be all sent once
`II ...
`} else {
`II get out block size
`short out_block_size = apdu.getOutBlockSize();
`
`log record size is smaller than
`
`II check if the total
`II the out block size
`if (TOTAL_LOG_RECORD_SIZE
`<= out_block_size) {
`II no problem, send all
`log records
`apdu.setOutgoinglength(TOTAL_LOG_RECORD_SIZE);
`apdu.sendByteslong(log_record_l,
`(short)0,
`(short)log_record_l.length);
`apdu.sendBytesLong(log_record_2,
`(short)0,
`(short)log_record_2.length);
`apdu.sendByteslong(log_record_3,
`(short)0,
`(short)log_record_3.length);
`
`return;
`} else {
`II send one record, but inform the host that there are
`II more records
`apdu.setOutgoingLength((short)log_record_l.length);
`apdu.sendByteslong(log_record_l,
`(short)0,
`(short)log_record_l.length);
`
`IPR2022-00413
`Apple EX1049 Page 104
`
`

`

`PROTOCOL-SPECIFIC APDU PROCESSING 101
`
`the host there are two more log records
`tell
`//
`the host can issue another APDU command
`//
`to retrieve
`the remaining records
`//
`ISOException.throwit(SW_2_MORE_RECORDS);
`
`}
`
`}
`
`8.4.4 Method setOutgoi ngNoCha i ni ng
`
`public short setOutgoingNoChaining()
`
`throws APDUException
`
`This method is used to set the data transfer direction to outbound without using
`block chaining and to obtain the expected length of data (the Le field) in the
`response APDU. Applets should use this method in place of the setOutgoi ng
`method to be compatible with the EMV specification.
`The setOutgoi ngNoChai ni ng method can be used in the same way as the set(cid:173)
`Outgoing method. Once it is invoked, any remaining incoming data are discarded.
`The applet must invoke the setOutgoi nglength method to inform the host of the
`actual number of bytes it will send.
`
`8.4.S Method getNAD
`
`public byte getNAD()
`
`In the T=l protocol, this method returns the node address byte (NAO). The NAD
`field is the first byte in the prologue field of a T=l block. The NAD field specifies
`both the source node address (SAD) and the destination node address (DAD). A
`smart card system may use NAD to maintain multiple logical connections between
`the host and the card.
`In the T=O protocol, the getNAD method returns 0.
`
`8.4.6 Method waitExtension
`
`public byte waitExtension()
`
`When the host does not receive any response for an ISO 7816-3-specified maximum
`time, it considers the card to be unresponsive and times out. An applet calls the
`waitExtension method to request additional processing time from the host so that it
`
`IPR2022-00413
`Apple EX1049 Page 105
`
`

`

`102 CHAPTER 8 WORKING WITH AP DUS
`
`does not time out while the applet is performing a long operation (a significant nu .
`rn
`her of EEPROM writes or complex cryptographic operations).
`An applet can call the wai tExtensi on method at any time during processing an
`APDU command. It does not need to call this method if the card has a hardware
`timer that automatically sends wai tExtensi on to the host.
`
`8.5 Summary
`
`This chapter shows how to process APDUs in applets. The discussion centers on
`using the methods in the APDU class to examine the APDU header, read command
`data, and send response data.
`Following is a summary of steps that an applet should follow to handle each
`case of APDU commands. In all cases, the applet can throw an ISOException with
`the appropriate reason code to flag errors.
`
`Case 1-No command data, no response data
`
`1. The applet's process method is called. The applet examines the first 4 bytes of
`the APDU buffer and determines that this is a case 1 command. The field P3
`(the fifth byte in the APDU buffer) is 0.
`
`2. The applet performs the request specified by the APDU header.
`
`3. The applet returns from the process method.
`
`Case 2-No command data, send response data
`
`1. The applet's process method is called. The applet examines the first4 bytes of
`the APDU buffer and determines that this is a case 2 command. The field P3 is
`interpreted as the Le field.
`
`2. The applet performs the request specified by the APDU header.
`
`3. The applet sends response data. The response can be short or long and is han(cid:173)
`dled differently, based on the data size.
`
`Short response (the response data fit in the APDU buffer):
`
`1. The applet calls the setOutgoi ngAndSend method and specifies the actual
`response data length.
`2. The applet returns from the process method.
`
`IPR2022-00413
`Apple EX1049 Page 106
`
`

`

`SUMMARY
`
`103
`
`Long response (the response data do not fit in the APDU buffer):
`
`I. The applet calls the setOutgoi ng method and obtains the Le field.
`2. The applet calls the setOutgoi nglength method to inform the host of the
`actual length of the response data.
`3. The applet calls the methods sendBytes or sendBytesLong (repeatedly if
`necessary) to send groups of response bytes.
`4. The applet returns from the process method.
`
`Case 3-Receive command data, no response data
`
`1. The applet's process method is called. The applet examines the first 4 bytes of
`the APDU buffer and determines that this is a case 3 command. The field P3 is
`interpreted as the Le field.
`
`2. The applet calls the setlncomi ngAndRecei ve method and repeats the call to
`the recei veBytes method if necessary to receive bytes. Each group of com(cid:173)
`mand data bytes is processed or copied to an internal buffer as it is received.
`
`3. The applet returns from the process method.
`
`Case 4-Receive command data, send response data
`
`Case 4 is a combination of cases 3 and 2. First, the applet receives the command
`data as described for case 3. Next, the applet sends the response data as described
`for case 2. At the end, the applet returns from the process method.
`
`)
`
`IPR2022-00413
`Apple EX1049 Page 107
`
`

`

`CHAPTER 9
`Applet Firewall
`and Object Sharing
`
`The Java Card platform is a multiapplication environment. Multiple applets from
`different vendors can coexist in a single card, and additional applets can be down(cid:173)
`loaded after card manufacture. An applet often stores highly sensitive information,
`such as electronic money, fingerprints, private cryptographic keys, and so on. Shar(cid:173)
`ing such sensitive data among applets must be carefully limited.
`In the Java Card platform, applet isolation is achieved through the applet fire(cid:173)
`wall mechanism. The applet firewall confines an applet to its own designated area.
`An applet is prevented from accessing the contents or behaviors of objects owned
`by other applets.
`To support cooperative applications on a single card-for instance, providing
`wallet, authentication, loyalty, and phone card functions-Java Card technology
`provides well-defined and secure object sharing mechanisms.
`The applet firewall and the sharing mechanisms affect the way you write
`applets. This chapter explains the behavior of objects, exceptions, and applets in
`the presence of the firewall and discusses how applets can safely share data by
`using the Java Card APls. JCRE implementation details that are not exposed to
`applets are intentionally ignored.
`
`9.1 Applet Firewall
`
`With applet isolation, the applet firewall provides protection against the most fre(cid:173)
`quently anticipated security concern: developer mistakes and design oversights that
`might allow sensitive data to be leaked to another applet. It also provides protection
`against hacking. An applet might be able to obtain an object reference from a pub(cid:173)
`licly accessible location, but if the object is owned by another applet in a different
`
`105
`
`)
`
`IPR2022-00413
`Apple EX1049 Page 108
`
`

`

`I 06
`
`CHAPTER 9 APPLET FIREWALL AND OBJECT SHARING
`
`package, the firewall prevents access to the object. Thus, a malfunctionin
`even a "hostile" applet, cannot affect the operations of other applets hg applet, or
`or t e JCRE
`
`9.1.1 Contexts
`
`The applet firewall partitions the Java Card object system into separat
`.
`e protected
`object spaces called contexts. The firewall is the boundary between one c
`ontext and
`.
`.
`.
`another. When an applet mstance 1s created, the JCRE assigns it a context Th·
`• 1s con-
`.
`text is essentially a group context. All applet mstances of a single Java package share
`the same gr~up context. There is no fire~all between two applet instances in a group
`context. ObJect access between applets m the same group context is allowed. How(cid:173)
`ever, accessing an object in a different group context is denied by the firewall.
`In addition, the JCRE maintains its own JCRE context. The JCRE context is a
`dedicated system context that has special privileges: access from the JCRE con(cid:173)
`text to any applet's context is allowed, but the converse, access from an applet's
`context to the JCRE context, is prohibited by the firewall. The Java Card object
`system partitions are illustrated in Figure 9 .1.
`
`sySlem space (---J-C_R_E_c_o_nt-ex_t ___
`
`)
`
`applet space
`
`group context
`
`applet
`context
`
`group context
`
`package B
`
`package A
`
`applet firewall
`
`Figure 9.1 The object system partitions on the Java Card platform
`
`IPR2022-00413
`Apple EX1049 Page 109
`
`

`

`APPLET FIREWALL
`
`107
`
`9.1.2 Object Ownership
`
`At any time, there is only one active context within the virtual machine: either the
`JCRE context or an applet's group context. When a new object is created, it is
`assigned an owning context-the
`currently active context. The object can be
`accessed from within that context, that is, by all applet instances in its owning
`context. Also, we say that the object is owned by the active applet in the current
`context when the object is instantiated. If the JCRE context is the currently active
`context, the object is owned by the JCRE.
`Primitive type static arrays in applets can be initialized when they are
`declared. Such static arrays are created and initialized by the converter. Because
`they are statically created before any applet instance is instantiated on the card,
`the ownership of these arrays can be assigned to any applet instance in their defin(cid:173)
`ing package. Any applet within this package can access these arrays. In other
`words, the owning context of these arrays is the group context of the package.
`
`9.1.3 Object Access
`
`When an object is accessed, the Java language access controls are enforced. For
`example, a private instance method cannot be invoked from outside the object. In
`addition, the object's owning context is compared to the currently active context. If
`the contexts do not match, the access is denied, and the comparison results in a
`Secu ri tyExcepti on. For instance, in the examples that follow, assume that object b
`owned is by context A. The following operations accessing object b from context A'
`cause the Java Card virtual machine to throw a Securi tyExcepti on:
`
`• Get and set fields:
`get object b's field
`short a= b.field_a;II
`b.field_a = S;II set object b's
`field
`
`• Invoke a public instance method:
`b.virtual_method_a();
`
`• Invoke an interface method:
`II if bis
`b.interface_method_a();
`
`an interface
`
`type
`
`• Throw it as an exception:
`throw b;
`
`IPR2022-00413
`Apple EX1049 Page 110
`
`

`

`108
`
`CHAPTER 9 APPLET FIREWAIL AND OBJECT SHARING
`
`◄
`
`• Cast it to a given type:
`
`(givenType)b;
`
`• Determine whether it is of a given type:
`if (b instanceof givenType)
`
`• Access an array element:
`
`short a= b[0];//
`b[0] = S;
`
`if object bis
`
`an array type
`
`• Obtain the array length
`
`int a= b.length;//
`
`if bis
`
`an array type
`
`9.1.4 Transient Array and Context
`
`Like a persistent object, a transient array of CLEAR_ON_RESET type can be accessed
`
`only when the currently active context is the array's owning context.
`Trarisient arrays of CLEAR_ON_DESELECT
`type are applet-specific resources.
`They can be created only when the currently active context is the context of the
`currently selected applet. Because applets from the same package share a group
`context, a transient array of CLEAR_ON_DESELECT
`type can also be accessed by all
`applets in its owning context. However, such access is granted only if one of these
`applets is the currently selected applet.
`
`9.1.5 Static Fields and Methods
`
`owned by contexts; classes themselves are
`Only instances of classes-objects-are
`not. No runtime context check is performed when a static field is accessed or when a
`static method is invoked. In other words, static fields and methods are accessible
`from any context. For example, any applet can invoke the static method throwit in
`the class ISOExcepti on:
`
`If (apdu_buffer[ISO7816.OFFSET_CLA] != EXPECTED_VALUE)
`ISOException.throwit(ISO7816.SW_CLA_NOT_SUPPORTED);
`
`Of course, the Java access rules still apply to static fields and methods. For exam~le,
`static fields and methods with the private modifier are visible only to their definutg
`classes.
`
`IPR2022-00413
`Apple EX1049 Page 111
`
`

`

`OBJECT SHARING ACROSS CONTEXTS 109
`
`When a static method is invoked, it executes in the caller's context. This sug(cid:173)
`gests that objects created inside a static method are assigned with the caller's con(cid:173)
`text (the currently active context).
`Static fields are accessible from any context. However, objects (including
`arrays) referenced in static fields are like regular objects. Such objects are owned by
`the applet (or the JCRE) that created them, and standard firewall access rules apply.
`
`9.2 Object Sharing across Contexts
`
`The applet firewall confines an applet's actions to its designated context. The applet
`cannot reach beyond its context to access objects owned by the JCRE or by another
`applet in a different context. But in situations where applets need to execute cooper(cid:173)
`atively, Java Card technology provides well-defined and secure sharing mechanisms
`that are accomplished by the following means:
`
`• JCRE privileges
`
`• JCRE entry point objects
`
`• Global arrays
`
`• Shareable interfaces
`
`The sharing mechanisms essentially enable one context to access objects belonging
`to another context under specific conditions.
`
`9.2.1 Context Switch
`
`Recall that there is only one active context at any time within the execution of the
`Java Card virtual machine. All object accesses are checked by the virtual machine to
`detennine whether the access is allowed. Normally, such access is denied if the
`owning context of the object being accessed is not the same as the currently active
`context. When a sharing mechanism is applied, the Java Card virtual machine
`enables access by performing a context switch.
`Members in an object consist of instance methods and fields. Accessing
`instance fields of an object in a different context does not cause a context switch.
`Only the JCRE can access instance fields of an object in a different context. Con(cid:173)
`text switches occur only during invocation of and return from instance methods of
`an object owned by a different context, as well as during exception exits from
`those methods.
`
`'
`
`IPR2022-00413
`Apple EX1049 Page 112
`
`

`

`110 CHAPTER 9 APPLET FIREWALL AND OBJECT SHARING
`
`During a context-switching method invocation, the current context is saved
`'
`and the new context becomes the currently active context. The invoked method is
`now executing in the new context and has the access rights of the current context.
`When the method exits from a normal return or an exception, the original context
`(the caller's context) is restored as the currently active context. For example, if an
`applet invokes a method of a JCRE entry point object, a context switch occurs
`from the applet's context to the JCRE context. Any objects created by the invoked
`method are associated with the JCRE context.
`Because method invocations can be nested, context switches can also be
`nested in the Java Card virtual machine. When the virtual machine begins running
`after a card reset, the JCRE context is always the currently active context.
`The following sections explore each sharing mechanism and discuss when
`and how context switch occurs in each access scenario.
`
`9.2.2 JCRE Privileges
`
`In the Java Card platform, the JCRE acts as the card executive. Because it is the
`"system" context, the JCRE context has special privileges. It can invoke a method
`on any object or access an instance field of any object on the card. Such system priv(cid:173)
`ileges enable the JCRE to control system resources and manage applets. For exam(cid:173)
`ple, when the JCRE receives an APDU command, it invokes the currently selected
`applet's select, deselect, or process method.
`When the JCRE invokes an applet's method, the JCRE context is switched to
`the applet's context. The applet now takes control and loses the JCRE privileges.
`Any objects created after the context switch are owned by the applet and associ(cid:173)
`ated with the current applet's context. On return from the applet's method, the
`JCRE context is restored.
`
`9.2.3 JCRE Entry Point Objects
`
`The JCRE can access any applet contexts, but applets are not allowed to access the
`JCRE context. A secure computer system must have a way for nonprivileged users
`(those restricted to a subset of resources) to request system services that are per(cid:173)
`formed by privileged system routines. In the Java Card platform, this requirement
`is
`accomplished by using JCRE entry point objects.
`JCRE entry point objects are normal objects owned by the JCRE context, bul
`they have been flagged as containing entry point methods. Normally, the fireW~
`1
`would completely protect such objects from access by any applets. The entry PoiJl
`designation allows the public methods of such objects to be invoked from any con·
`
`IPR2022-00413
`Apple EX1049 Page 113
`
`

`

`OBJECT SHAR1NG ACROSS CONTEXTS
`
`111
`
`text. When that occurs, a context switch to the JCRE context is performed. Thus,
`these methods are the gateways through which applets request privileged JCRE ser(cid:173)
`vices. Notice that only the public methods of JCRE entry point objects are accessi(cid:173)
`ble through the firewall. The fields of these objects are still protected by the firewall.
`The APDU object is perhaps the most frequently used JCRE entry point
`object. Chapter 8 explains how applets instruct the JCRE to read or send APDU
`data by invoking methods on the APDU object.
`There are two categories of JCRE entry point objects:
`
`• Temporary JCRE entry point objects-Like
`all JCRE entry point objects,
`methods of temporary JCRE entry point objects can be invoked from any con(cid:173)
`text. However, references to these objects cannot be stored in class variables,
`instance variables, or array fields (including transient arrays) of an applet. The
`JCRE detects and restricts attempts to store references to these objects as part
`of the firewall functions of preventing unauthorized reuse. The APDU object
`and all JCRE-owned exception objects are examples of temporary JCRE entry
`point objects.
`
`• Permanent JCRE entry point objects-Like
`all JCRE entry point objects,
`methods of permanent JCRE entry point objects can be invoked from any con(cid:173)
`text. Additionally, references to these objects can be stored and freely reused.
`The JCRE-owned AID instances are examples of permanent JCRE entry point
`objects. The JCRE creates an AID instance to encapsulate an applet's AID
`when the applet instance is created.
`
`Only the JCRE itself can designate entry point objects and whether they are
`temporary or permanent. JCRE implementors are responsible for implementing
`the JCRE, including the mechanism by which JCRE entry point objects are desig(cid:173)
`nated and how they become temporary or permanent.
`
`9.2.4 Global Arrays
`
`JCRE entry point objects allow applets to access particular JCRE services by invok(cid:173)
`ing their respective entry point methods. The data encapsulated in the JCRE entry
`point objects are not directly accessible by applets. But in the Java Card platform,
`the global nature of some data requires that they be accessible from any applet and
`the JCRE context.
`To access global data in a flexible way, the firewall allows the JCRE to desig(cid:173)
`nate primitive arrays as global. Global arrays essentially provide a shared memory
`
`IPR2022-00413
`Apple EX1049 Page 114
`
`

`

`112
`
`CHAPTER 9 APPLET FIREWALL AND OBJECT SHARING
`
`buffer whose data can be accessed by any applets and by the JCRE. Because there
`is only one context executing at any time, access synchronization is not an issue.
`Global arrays are a special type of JCRE entry point object. The applet fire(cid:173)
`wall enables public fields (array components and array length) of such arrays to
`be accessed from any context. Public methods of global arrays are treated the
`same way as methods of other JCRE entry point objects. The only method in the
`array class is the equals method, which is inherited from the root class Object.
`As does invoking any method of a JCRE entry point object, invoking the equals
`method of a global array causes the current context to be switched to the JCRE
`context.
`Only primitive arrays can be designated as global, and only the JCRE itself
`can designate global arrays. All global arrays must be temporary JCRE entry point
`objects. Therefore, references to these arrays cannot be stored in class variables,
`instance variables, or array components (including transient arrays).
`The only global arrays required in the Java Card APis are the APDU buffer
`and the byte array parameter in an applet's install method. Typically, a JCRE
`implementation passes the APDU buffer as the byte array parameter to the
`i nsta 11 method. Because global arrays can be viewed and accessed by anyone,
`the JCRE clears the APDU buffer whenever an applet is selected or before the
`JCRE accepts a new APDU command, to prevent an applet's sensitive data from
`being potentially "leaked" to another applet via the global APDU buffer.
`
`9.2.5 Object Shareable Interface Mechanism
`
`To reiterate the sharing mechanisms between the JCRE and applets:
`
`• The JCRE can access any object due to its privileged nature.
`
`• An applet gains access to system services via JCRE entry point objects.
`
`• The JCRE and applets share primitive data by using designated global arrays.
`
`Java Card technology also enables object sharing between applets through the share·
`able inte1f ace mechanism.
`
`9.2.5.J Shareable Interface
`
`A shareable interface is simply an interface that extends, either directly or indirectly,
`the tagging interface j avacard. framework.Shareable.
`
`public
`
`interface
`
`Shareable{}
`
`----
`
`IPR2022-00413
`Apple EX1049 Page 115
`
`

`

`OBJECT SHARING ACROSS CONTEXTS
`
`113
`
`This interface is similar in concept to the Remote interface used by the RM] facility.
`Neither interface defines any methods or fields. Their sole purpose is to be extended
`by other interfaces and to tag those interfaces as having special properties.
`A shareable interlace defines a set of methods that are available to other
`applets. A class can implement any number of shareable interfaces and can extend
`other classes that implement shareable interfaces.
`
`9.2.5.2 Shareable Interface Object
`
`An object of a class that implements a shareable interface is called a shareable inter(cid:173)
`face object (SIO). To the owning context, an SIO is a normal object whose fields
`and methods can be accessed. To any other context, the SIO is an instance of the
`shareable interface type, and only the methods defined in the shareable interface are
`accessible. All fields and other methods of the S1O are protected by the firewall.
`
`9.2.5.3 Thoughts behind the Shareable Interface Mechanism
`
`Applets store data in objects. Data sharing between applets means that an applet
`makes an object it owns available to other applets, thus sharing the data encapsu(cid:173)
`lated in the object.
`In the object-oriented world, an object's behavior (aside from direct variable
`access) is expressed through its methods. Message passing, or method invocation,
`supports interactions and communications between objects. The shareable inter(cid:173)
`face mechanism enables applets sending messages to bypass the surveillance of
`the firewall. An owning applet creates a shareable interface object and implements
`methods defined in the shareable interface. These methods represent the public
`interface of the owning applet, through which another applet can send messages
`and consequently access services provided by this applet.
`The sharing scenario illustrated in Figure 9 .2 can be described as a client/
`server relationship. Applet A (providing SIOs) is a server, and applets B and C
`(using the SIOs of applet A) are clients. An applet may be a server to some applets
`•
`and yet a client of other applets.
`In the Java programming language, an interface defines a reference type that
`contains a collection of method signatures and constants. A client applet views an
`SIO as having a shareable interface type. The class type of the S1O that imple(cid:173)
`ments the shareable interface is not exposed. In other words, only methods
`defined in the shareable interface are presented to the client applet; instance fields
`and other methods are not disclosed. In this way, a server applet can provide con(cid:173)
`trolled access to data it wants to share.
`
`IPR2022-00413
`Apple EX1049 Page 116
`
`

`

`114
`
`CHAPTER 9 APPLET FIREWALL AND OBJECT SHARING
`
`\~----t--t---e
`
`applet A
`
`0
`0
`
`Figure 9.2
`
`Shareable interface object mechanism
`
`When interacting with a different client applet, a server applet could wear a
`different hat. This would require the server applet to customize its services with
`respect to the client applet without having the door wide open. A server applet can
`do so by defining multiple interfaces, each interface declaring methods that are
`suitable for a group of client applets. If methods in interfaces are distinct, a server
`applet may choose to create classes, each of which implements an interface. ~ul
`often services overlap; a server applet can define a class that implements multiple
`interfaces. Therefore, an SIO of that class can play multiple roles.
`
`9.2.5.4 An Example of Object Sharing between Applets
`f
`. d an example o
`This section uses a wallet applet and an air-miles applet to pro: 1 e ThernoneY
`object sharing between applets. The wallet applet stores electronic cash.
`can be spent to purchase goods.
`ailet applet,
`th
`er :as travele~(cid:173)
`The air-miles applet provides travel incentives. Similar to
`the air-miles applet also stores values-the miles the card holde ppJet, one air
`th wallet a
`.
`Under a comarketing deal, for every dollar spent using
`e
`_
`.
`.
`1con
`il
`. differen . y
`m e 1s credited to the air-miles applet.
`1 t are in
`V we
`teps of h0'
`Suppose that the wallet applet and the air-miles app e
`are the s
`.
`texts (they are defined in separate packages). Following