A Comparison of Java Cards: State-of-Affairs 2006∗
`Wojciech Mostowski1
`Jing Pan2
`Srikanth Akkiraju3
`
`Erik de Vink2
`
`Erik Poll1
`
`Jerry den Hartog3
`
`Abstract
`This document presents the results of a comparative study of some popular Java
`Cards on the market. Eight different cards from four manufacturers have been con-
`sidered. The analysis has been done at two levels – (i) a documentation-based com-
`parison, also taking other publicly available resources into account, (ii) an actual
`hands-on testing with software developed specifically for this purpose by the Pin-
`pasJC research team. The investigations focus on basic functionality, secure chan-
`nels, the transaction mechanism, support symmetric and asymmetric cryptography,
`Global Platform and Open Platform compliance, and garbage and memory manage-
`ment.
`
`1 Introduction
`
`Java Card plays an increasingly predominant role in smart card projects, e.g. for identity
`cards and travel documents. Many vendors respond to this market expansion with dedi-
`cated products. However, by design, these products are not exactly equivalent. On top of
`the traditional dissimilarities such as component size, many behavioural differences can be
`detected both at the functional and performance level. As such, this can have impact on
`the portability of a solution and undermine the advantage of using Java Card.
`This document presents a comparative analysis of eight commercial Java Cards available
`to us to date (Autumn/Winter 2006), namely C 211A, C 211B, B 211, B 22, B 221, A 211,
`A 221(two slightly different instances differing in the communication speed), and D 22. The
`evaluation took place with respect to the following criteria:
`∗This work is supported by the research program Sentinels (http://www.sentinels.nl). Sentinels is
`financed by the Technology Foundation STW, the Netherlands Organisation for Scientific Research NWO,
`and the Dutch Ministry of Economic Affairs.
`1Computing Science Department, Radboud University, Nijmegen, The Netherlands
`2Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Nether-
`lands
`3Department of Electrical Engineering, Mathematics and Computer Science, Twente University, En-
`schede, The Netherlands
`
`1
`
`IPR2022-00412
`Apple EX1045 Page 1
`
`

`

`Compliance to standards: Compatibility to Java Card and Global Platform
`
`Implemented features: Communication interfaces, APDU protocols, memory manage-
`ment, atomicity, RMI support and on-card byte-code verification availability
`
`Performance: Execution time of cryptographic algorithms
`
`Limits: Transaction commit capacity and APDU buffer capacity
`
`The investigations discussed below, give an indication of the present state of affairs regard-
`ing Java Card. For example, the choice of cards under consideration has been limited by
`their availability. It is also noted that some results reported in this document have been
`based on publicly available information only. Additionally, when it came to actual card
`testing, two major bottlenecks were hindering our progress for some time. First of all,
`getting hold of a type of Java Card in small quantities is non-trivial. Secondly, some cards
`are personalized with proprietary authentication keys (or, more precisely, keys that are
`derived following proprietary schemes). Finding out this information took a considerable
`amount of time (see also Section 3.1).
`The rest of this document is organized as follows. Section 2 discusses the card features
`stated in the cards’ documentations [16, 15, 2, 1, 6], regarding the four evaluation criteria
`above. Section 3 presents several tests (and their results) we performed with the cards
`to explore various features: basic card features, secure channel functionality, transaction
`mechanism, cryptography support and speed, RMI, garbage collection, etc. For each of
`the tests the methodology is briefly described. Finally, Section 4 concludes the report.
`
`2 Card Features Based on Documentation
`
`The Java Cards that have been considered in the research reported here are the following:
`• From Manufacturer C the C 211A and C 211B cards. These cards are the only
`cards that we were able to buy directly from the manufacturer in small quantities.
`They are also the only cards that have full technical documentation that is publicly
`available regarding the particular Global Platform implementation. On the other
`hand Manufacturer C continuously sells cards known to have bugs, see comments in
`Section 3.8.
`• From Manufacturer B the following cards: an older B 211, B 22, and B 221. The
`B 221 card is the most advanced (supporting both Java Card 2.2.1, Global Platform
`2.1.1 and contactless interface) card from Manufacturer B currently available.
`• From Manufacturer A the A 211 card and A 221 card. For the A 221 card we
`have two different instances available, the main difference being the communication
`speed of the contact interface. Whenever any substantial difference has been noticed
`between the two A 221 cards we noted them down. Also, A 221 is the only other card
`in our test set that supports the latest Java Card and Global Platform technologies.
`
`2
`
`IPR2022-00412
`Apple EX1045 Page 2
`
`

`

`Java Card
`C 211A
`C 211B
`B 211
`B 22
`B 221
`A 211
`A 221
`D 22
`
`Company
`Manufacturer C
`Manufacturer C
`Manufacturer B
`Manufacturer B
`Manufacturer B
`Manufacturer A
`Manufacturer A
`Manufacturer D
`
`JC API Open/Global Platform
`2.1.1
`2.0.1
`2.1.1
`2.0.1
`2.1.1
`2.0.1
`2.2
`2.0.1
`2.2.1
`2.1.1
`2.1.1
`2.0.1
`2.2.1
`2.1.1
`2.2
`2.1.1
`
`Table 1: Compliance to software standards
`
`Java Card EEPROM(KB) RAM(Bytes) ROM(KB)
`32 (30)
`4096
`96
`C 211A
`64 (—)
`—
`—
`C 211B
`32 (29)
`—
`—
`B 211
`64
`—
`—
`B 22
`16/32/64
`—
`—
`B 221
`32 (30)
`2300
`96
`A 211
`72 (70)
`4608
`160
`A 221
`64
`—
`—
`D 22
`
`Table 2: Memory characteristics
`
`• From Manufacturer D the D 22 card.
`
`2.1 Compliance to Standards
`
`Table 1 compares the cards under consideration from the point of view of specific versions
`of the Java Card API and Open/Global Platform standard that they support.
`Table 2 provides the hardware features of the cards. The values between parentheses
`are the amounts of free memory available for applications once the system is loaded. The
`documentation from the vendor of B 211 card does not show any information about the
`capacity of RAM or ROM. The total amount of ROM size of the A 221 card is not presented
`in any documentations either,1 though the vendor of this card’s microcontroller does say
`that the card has 160KB of ROM.
`
`2.2 Implemented Features
`
`Table 3 compares the cards under consideration with respect to the data transport layer,
`whereas Table 4 provides an overview of the availability of additional features such as
`
`1There is actually no formal documentation available for this card as other cards from Manufacturer A.
`
`3
`
`IPR2022-00412
`Apple EX1045 Page 3
`
`

`

`Java Card APDU Protocols
`T=0
`C 211A
`T=0, T=1
`C 211B
`T=0, T=1
`B 211
`T=0, T=1
`B 22
`T=0, T=1, T=CL
`B 221
`T=0, T=1
`A 211
`T=0, T=1, T=CL
`A 221
`
`Communication Interface
`Contact
`Contact
`Contact
`Contact
`Contact, Contactless
`Contact
`USB 2.0 (Low Speed)
`Contact, Contactless
`T=0, T=1, T=CL Contact, Contactless, USB
`
`D 22
`
`Table 3: Communication features
`
`Logical
`On-card
`RMI
`Java Card Garbage
`Collection Supported Byte-code Verification Channel
`—
`No
`Yes
`No
`—
`No
`Yes
`No
`Yes
`No
`—
`No
`Yes
`Yes
`—
`Yes
`Yes
`Yes
`—
`Yes
`Full
`No
`—
`No
`Full
`Yes
`—
`Yes
`—
`Yes
`—
`—
`
`C 211A
`C 211B
`B 211
`B 22
`B 221
`A 211
`A 221
`D 22
`
`Table 4: Java Card and Open Platform features
`
`garbage collection, RMI, on-card byte-code verification and logical channels. Availability
`of many of these cannot be decided given the information in the vendors’ documentations.
`For example, Manufacturer B claims that their cards support run-time garbage collection.
`However, it remains implicit whether they concern full or partial garbage collection. Both
`cards from Manufacturer A supposedly provide full garbage collection (see Section 3.11
`on garbage collection). Note that logical channel functionality is added only to Global
`Platform specification 2.1.1 as an optional feature.
`
`2.3 Performance
`
`As far as we are aware, there is no publication available that actually considers a perfor-
`mance comparison for Java Cards. An exception is [4] which, at present, treats rather
`outdated cards. Manufacturer A has certain documents for each of their cards (excluding
`A 221), where a list of performance figures can be found, though qe are not in a position
`to confirm these figures. Recently, a project to measure smart card performance has been
`initiated in France,2 but at the moment the project is in its very early stage.
`
`2http://cedric.cnam.fr/mesure/
`
`4
`
`IPR2022-00412
`Apple EX1045 Page 4
`
`

`

`Java Card Transaction Buffer Size APDU Buffer Size
`(bytes)
`(bytes)
`—
`255
`—
`—
`—
`—
`—
`—
`—
`—
`512
`261
`—
`—
`—
`—
`
`C 211A
`C 211B
`B 211
`B 22
`B 221
`A 211
`A 221
`D 22
`
`Table 5: Buffer capacity limits
`
`2.4 Limits
`
`The limits we consider are the size of the APDU buffer and the transaction commit buffer.
`The APDU buffer is used to hold incoming and outgoing communication data. The trans-
`action buffer is used to save data involved in transactions, viz. all persistent byte and short
`stores, as well as persistent parameters to Util.arrayCopy. Only a few vendors have the
`buffer size figures in their documentations. However, some of these figures can be retrieved
`directly from the card through the Java Card API, see Section 3. The figures obtained
`from the documentation (only a few) are listed in Table 5.
`Some of the limits are not documented at all (we mention the maximum number of
`Java Card objects managed, maximum size of applets or load files, maximum number of
`load files or applets that can be installed on a card, maximum number of secure channel
`keys in the Issuer Security Domain).
`The data we have presented so far are based solely on available documentation (if any).
`In the next section we describe a number of tests we performed to verify the documented
`data and to obtain details not included in the documentation.
`
`3 Card Testing
`
`For the purpose of testing a number of applications and applets have been written. We
`have tested some basic features (Section 3.2), Global Platform functionality, in particular
`secure channels (Section 3.3), the transaction mechanism (Section 3.4). Furthermore, we
`have established the range of cryptographic support on the cards. We also performed speed
`and compatibility tests (Section 3.5) and put an effort to test the basic RMI functionality
`of RMI enabled cards (Section 3.7), to test the GP API support (Section 3.8) and garbage
`collection (Section 3.11).
`
`5
`
`IPR2022-00412
`Apple EX1045 Page 5
`
`

`

`3.1 Preparations
`
`First, a suitable host-side library had to be found to communicate with the cards. Our
`choice was to use the IBM BlueZ (RMI) Off-Card API (available as part of the IBM JCOP
`tool-set for Eclipse) and build our testing software on top of this library.3 In the process
`of developing the software we discovered some (minor) bugs in the IBM libraries – we
`developed some small workarounds for these problems.
`Some of the programs we have
`written are the following:
`• PATT (PinPas Applet Testing Tool) – a command line tool to manage applets on the
`card. The main feature of the tool is that it talks to a wide range of different Java
`Cards through the Global Platform interface taking into account all small ‘quirks’
`that the cards may require (see below).
`• PinPas card customiser – a very simple application that loads a couple of custom key
`sets into ISD to be used in the Secure Channel test. This application also performs
`the detailed GP key registry test, see Section 3.3.1.
`• Secure Channel tester (Section 3.3) – an application that runs a set of GP commands
`on the card to reveal details of (Visa) Global Platform [7, 17] behaviour of the card.
`The results are presented to the user in concise, human readable form.
`• A simple applet (Section 3.2) and host side application to retrieve basic card infor-
`mation from the card through the Java Card API. The host application presents the
`results in human readable form.
`• A test applet for transactions and non-atomic methods (Section 3.4).
`• An applet and host side application to test the cryptographic features of the card
`(Section 3.5): supported algorithms, compatibility test (with respect to the desktop
`Java Crypto API), and performance. Again results are presented in a human readable
`form.
`• Global/Open Platform API test applet and host application (Section 3.8).
`• Garbage collection test applet and host application (Section 3.11).
`
`The IBM Off-Card API provides a uniform framework to manage all GP compliant
`cards, but has been developed by IBM and tested mainly with their own cards. Trying to
`make the library talk to cards from various vendors revealed some interesting card features:
`• Two Manufacturer B cards (B 211 and B 221) have specific initial static keys derived
`on a ‘per card’ basis from the standard GP keys (4041...4F). Finding out how these
`derivation routines work took a while. For the B 211 card the routine (defined in
`
`3Another possibility is to use an open-source Global Platform implementation – http://sourceforge.
`net/projects/globalplatform/, however, we prefer to work with Java programs and libraries.
`
`6
`
`IPR2022-00412
`Apple EX1045 Page 6
`
`

`

`VISA Card Personalisation Guideline we believe) can be found on the Java Card
`forums, although it is in principle secret/proprietary. For the B 221 card the routine
`is similar, but differs in small details, after a long search we found it is documented
`in a rather obvious place [5]. However, again, VISA itself seems to be hiding this
`information. During the process of figuring out these derivation schemes some cards
`got locked.
`• The B 211 cards are somewhat more sensitive than all the other cards to the way
`the applets are loaded onto the card. The required loading mode is ‘component by
`component’ one.
`• Both B 22 and D 22 cards implement Java Card API version 2.2 (not version 2.2.1).
`The Java Card SUN Development Kit version 2.2 has to be used (2.2.1 library files
`are not downwards compatible with 2.2 cards, although the APIs themselves are
`almost identical, if not actually the same) to prepare applets for these cards.
`• First applet selection after card reset takes more time (noticeably long) on B 22
`compared to the other cards.
`• C 211A and C 211B cards do not accept standard .cap files produced by the SUN
`Java Card Development Kit. This is due to a ‘picky’ on-card byte-code verifier. The
`.cap files have to be transformed before loading with proprietary software (provided
`by Trusted Logic, it can be downloaded for free from their web site).4
`• Rather than B 211 cards, e.g. C 211A does not accept ‘component by component’
`loading. Instead, ‘all in one’ mode is required. Also, certain CAP components have
`to be included in the load command, a procedure that other cards do not require.
`• With our reader (Omnikey CardMan 5121), for the C 211A (C 211B) card loading of
`large .cap files failed because of a card timeout. Our guess is that this is due to
`lengthy on-card byte code verification. Thus, it seems that the size of the loadable
`applets is limited, for this set-up, by the speed of the verifier.
`
`The applet loading differentiators have been systematically analyzed and is summarized
`in Table 6. We make the following comments:
`• ‘Load Params’, ‘Install Params’ – these two columns indicate whether the card re-
`quires any specific parameters to load and install commands. Notably, the C 211A
`and C 211B cards have to be informed about the load file size ahead of time, and
`also require a persistent memory usage limit to be specified during applet installa-
`tion (this is marked by ‘CF’). None of the other cards showed such behaviour. For
`these three situations can be distinguished: (a) the card does not require any applet
`installation parameters (–), (b) the card requires at least an empty parameter string
`of type 1 (c9 00) marked T1, or (c) of type 2 (c9 01 00) marked T2.
`
`4http://www.trusted-logic.com/down.php
`
`7
`
`IPR2022-00412
`Apple EX1045 Page 7
`
`

`

`• ‘Load mode’ – some cards require the load components of the CAP file to start at
`the APDU boundary (component by component loading – CbC), other cards require
`the load APDUs to be of equal lengths, in which case the components are put one
`after another and the whole load block is divided at the APDU block size boundary
`(all in one mode – AiO). For most of the cards the loading mode does not matter
`(–).
`• ‘Block Size’ the maximum load block size, usually limited by the APDU buffer size.
`Here we tested plain communication where no MACing or encoding takes place,
`thus the additional data that maybe required in the APDU (e.g. the MAC) is not
`considered.
`• ‘Verifier’ – some cards are equipped with a byte-code verifier. In that case the CAP
`file needs first to be transformed with a suitable tool (for Manufacturer C cards a
`CAP file transformer from Trusted Logic, marked ‘TL’).
`• ‘Debug’ – the same cards that are equipped with a verifier also require the debug
`component to be loaded onto the card. ‘Yes’ means the debug component is required,
`‘No’ means the debug component cannot be included (not the case for any of the
`cards), ‘–’ means that the debug component is optional.
`
`The results in Table 6 suggest that all the cards are more or less the same with respect to
`applet loading. The Manufacturer C cards are one exception to this rule – this is caused
`by the on-card verifier. The other exception is the B 211 card, although here we are not
`completely sure of the result. During the early stages of card testing the results we were get-
`ting suggested that the card requires ‘component by component’ loading mode. However,
`during later systematic tests of applet loading this requirement could not be confirmed,
`explaining the asterisk ‘*’ in the table. The fact that some Manufacturer B cards require
`specifically derived static keys to authenticate before applet loading is not considered to be
`an applet loading differentiator. It is, however, an important card personalization feature.
`We should add that depending on the API versions installed on the card (JC or GP),
`properly versioned JAR and EXP files are needed to build applets for a given card and also
`a matching Java Card development kit has to be used. To the best of our knowledge the
`JAR and EXP files are interchangeable between cards that share the same API version,
`which in particular means that the standard files provided by Sun or Global Platform
`Consortium can be used. We also did manage to use the standard Java Card development
`kits to prepare applets for all of the cards. All in all, apart from the CAP file transformer
`for the Manufacturer C cards, no proprietary software was needed to prepare applets for
`any of the cards.
`Finally, we tested the maximal number of load files that can be loaded and instantiated
`on the card. The test consisted of cloning one applet 64 times and subsequently loading
`and instantiating it on the card. The problem with some cards turned out to be that the
`number of the actual load files/applets on the card is different from what the card reports
`with the ‘get status’ command. The following are the end results for all the cards:
`
`8
`
`IPR2022-00412
`Apple EX1045 Page 8
`
`

`

`A 221 We managed to put total of 30 load files and 29 applets on this card, but GP reports
`only 21 load files and all of the applets present on the card.
`
`A 211 We managed to load all 64 test applets onto the card and to instantiate them all.
`The card, however, reports only 21 load files and 15 applets with the ‘get status’
`command.
`
`B 221 We managed to put 17 load files and 13 applets onto this card, and the card’s report
`reflects the reality.
`
`B 22 We managed to put 51 load files and 37 applets onto this card, and the card’s report
`reflects the reality.
`
`B 211 We managed to put 28 load files and 19 applets onto this card, and the card’s report
`reflects the reality.
`
`C 211A We managed to put 14 load files and 7 applets onto this card, and the card’s report
`reflects the reality.
`
`C 211B We managed to put 28 load files and 17 applets onto this card, however, the card
`in the end the card reported only 8 load files and 3(!) applets.
`
`D 22 We managed to load and instantiate all 64 test applets on to the card. Moreover, the
`card reported all of the load files and applets in the ‘get status’ response.
`
`A note about C 211A and C 211B cards is due: the number of load files and applets depend
`on the memory settings of an applet – the lower the limit is set for one applet the more
`applets can be loaded. Thus turned out to be very difficult to figure out the actual limits
`of those cards.
`For the two cards that loaded all the test applets (A 211 and D 22) we rerun the test
`with 128 cloned applets. The A 211 card managed to store the total of 115 load files, the
`D 22 managed to load all the test files again resulting in 132 load files total on the card.
`From this we conclude that these two cards are simply limited by the available memory
`when it comes to applet loading.
`Table 7 summarizes the results. Of course, because of the nature of the test those
`values should be treated as approximate, they rather indicate the range of the capacity of
`the card rather than the exact limit.
`
`3.2 The BasicInfo Applet
`
`The BasicInfo applet is a very simple applet that reports basic features of a Java Card
`accessible through the Java Card API. For the 2.1.1 cards this is limited to (a) the API
`version, (b) the maximum transaction commit capacity, (c) the kind of APDU protocol
`(T0/T1), and (d) the size of the APDU buffer. For the 2.2.* cards the applet reports
`the following features: (a) the API version, (b) the transaction commit capacity, (c) the
`
`9
`
`IPR2022-00412
`Apple EX1045 Page 9
`
`

`

`Java Card Load param Install param Load mode Block size Verifier Debug
`–
`–
`–
`255
`–
`–
`A 211
`–
`T1
`–
`255
`–
`–
`A 221
`CF
`CF
`AiO
`255
`TL
`Yes
`C 211A
`CF
`CF
`AiO
`255
`TL
`Yes
`C 211B
`–
`T2
`CbC*
`255
`–
`–
`B 211
`–
`T2
`–
`255
`–
`–
`B 22
`–
`T1
`–
`255
`–
`–
`B 221
`–
`T2
`–
`255
`–
`–
`D 22
`
`Table 6: Applet loading differentiators
`
`Java Card Load Files Applets Reports
`−
`115
`108
`A 211
`−
`30
`29
`A 221
`14
`7
`+
`C 211A
`−
`28
`17
`C 211B
`28
`19
`+
`B 211
`51
`37
`+
`B 22
`17
`13
`+
`B 221
`>132
`>130
`+
`D 22
`
`Table 7: Applet loading differentiators
`
`available memory (persistent and transient), (d) the kind of APDU protocol (T0/T1/TCL),
`(e) the APDU size, and (f) the support for object deletion. Additionally, based on the
`card’s ATR,5 the maximum supported baud rate of the card is reported – the note ‘default’
`means that the card does not report any particular speed, which usually means the default
`(initial) speed of 9600 bits/sec is used for the whole communication session. The results of
`running the BasicInfo applet on the cards are collected in Appendix A and an overview
`of results is given in Table 8. The ‘Memory Persistent’ column indicates the number of
`bytes of free persistent memory reported by the Java Card API call – because of the limits
`of the short data type, the Java Card API does not report memory sizes above 32K, even
`though some cards offer more. The ‘Memory Transient’ column lists the amount of free
`transient (RAM) memory in two modes – memory that is cleared on card reset (first value),
`and memory that is cleared on applet deselection (second value).6
`We have encountered the following:
`• B 221: This card reports different sizes of RAM memory for two memory clearing
`modes: clearing on reset and clearing on deselection. As noted later in the report
`
`5The information on how to decode the supported baud rate out of the ATR is available at http:
`//www.cs.uct.ac.za/Research/DNA/SOCS/psec2.html.
`6Note, that the test was not run on cards that were totally empty. In particular, the test applet itself
`was present on the card, which already takes up some resources. Thus the actual memory size, especially
`RAM, of an empty card may differ slightly. See also Section 3.11.
`
`10
`
`IPR2022-00412
`Apple EX1045 Page 10
`
`

`

`(Section 3.11), there is something strange about transient memory reporting on this
`card.
`• D 22 and C 211B: These cards indicate unusual APDU buffer sizes (274 bytes and
`272 bytes respectively).
`
`For the Java Card 2.2.* API a call to APDU.getProtocol should in principle give the type
`of the protocol/mode (Wireless Type A, Wireless Type B, or USB). All the 2.2.* cards
`however, return the default value. According to the Java Card API documentation that
`means the wireless protocol is simply ISO 14443-4 (T=CL).
`Finally, during multiple applet loading and deletion we obtained some strange results
`with respect to the card memory management and garbage collection. Apparently one of
`our C 211A cards does not clear the memory properly on applet deletion – after a sequence
`of applet loads and deletions the card refused to load applets, giving an error indicating
`lack of memory on the card. This way we managed to effectively lock one of our C 211A
`card. All other cards (including a different instance of the same C 211A card), despite the
`same loading and deleting operations, still functioned properly.
`
`3.3 Secure Channel and (Visa) Global Platform Tests
`
`The purpose of the Global Platform test is to reveal the details of the Global Platform
`implementation on the card and compliance of the card to Visa Global Platform Guide-
`lines [17]. It is noted that only are limited number of features is tested (as described below).
`So, our test is not a comprehensive (Visa) Global Platform test suite and its results should
`therefore be treated with certain reserve.
`In the current version, the secure channel test application performs the following tasks:
`
`1. Based on a response to ‘initialize update’ command, a basic secure channel protocol
`is established (01 or 02).
`
`2. Furthermore, for a given main version, all secure channel options defined in the
`Global Platform Specification [7] are tried out, including implicit modes. A successful
`exchange of ‘initialize update’ and ‘external authenticate’ (which requires a MAC)
`commands indicates that a corresponding explicit option is supported by the card.
`For the implicit modes a simple MACed communication with implicitly derived keys
`is initiated, but it seems that none of the cards supports implicit secure channels.
`
`3. Once the main version and the secure channel option are established, the secure
`channel is subsequently tested:
`• A secure channel is initiated in all possible security levels (PLAIN, MAC,
`ENC+MAC, RMAC, MAC+RMAC, ENC+MAC+RMAC). For each of the se-
`curity levels a basic communication with the Security Domain is performed (a
`communication that requires non-trivial command and response APDU).
`
`11
`
`IPR2022-00412
`Apple EX1045 Page 11
`
`

`

`Table8:OverviewresultsoftheBasicInfotest
`
`2.2
`2.2
`2.2
`2.1
`2.1
`2.1
`2.2
`2.1
`APIAPDUprot.APDUsizeCommitbuf.Mem.pers.Mem.trans.Objectdel.
`
`Yes
`Yes
`Yes
`
`—
`
`—
`
`—
`
`Yes
`
`—
`
`946/946
`614/906
`1936/1936
`
`—
`
`—
`
`—
`
`32767
`32767
`32767
`
`—
`
`—
`
`—
`
`1983/1983
`
`—
`
`32767
`
`—
`
`511
`504
`896
`505
`512
`510
`512
`500
`
`274
`261
`261
`261
`272
`261
`261
`261
`
`T0/T=CL
`T1/T=CL
`
`T1
`T1
`T0
`T0
`
`T1/T=CL
`
`T0
`
`161290/9622
`161290/9622
`
`161290
`53763
`156250
`78125
`
`161290/9622
`
`9622
`
`D22
`B221
`B22
`B211
`C211B
`C211A
`A221
`A211
`
`Baudrate
`
`JavaCard
`
`12
`
`IPR2022-00412
`Apple EX1045 Page 12
`
`

`

`• Additionally, a check if ‘Begin/End R-MAC Session’ commands are supported
`is performed. None of the cards seem to support ‘Begin/End R-MAC Session’
`or RMACing in general.
`• Finally, based on the Visa Global Platform specification, a challenge that the
`card should give according to the predictable challenge rules is ‘guessed’ and
`compared to the challenge returned by the card. This indicates if the card
`implements predictable challenges.
`
`4. A communication over multiple logical channels is initiated. If it succeeds a test is
`performed to check whether a security channel can be active on multiple channels.
`Lack of such a possibility indicates adherence to Visa Global Platform specifications.
`Additionally, the maximum number of logical channels the card supports (again,
`based on a trial and error test) is reported.
`
`5. An additional key set is loaded onto the card and a key deletion is attempted. This
`indicates the support for key deletion in the Global Platform implementation.
`
`6. Finally, an attempt to instantiate an additional Security Domain from a standard
`load file (A0000000035350) indicated by VGP specification [17] is performed. Note,
`that the card may have a different load file than the one required by the VGP
`specification to instantiate additional Security Domains. We tested VGP compliance
`here only for the standard load file.
`
`The complete test results are gathered in Appendix B. We give an overview of results in
`Table 9 and list some comments, where applicable:
`• C 211A: Regarding key management on this card, the following has been observed. It
`seems that the card can hold multiple key sets, but only one can be active at a time –
`loading a new key set makes it the default one and none of the previous key sets can
`be used for authentication, although the card’s behaviour suggests the other key sets
`still exist on the card. Further tests (see the next section) of different instances of
`the card suggest that this is caused by some sort of fault that we induced on the card
`during testing. Unfortunately, we are not able to reconstruct the fault that occurred.
`• D 22: For this card, although the default load file for the security domain is present
`on the card, we were not able to instantiate any additional security domains – the
`error that we get is ‘conditions of use not satisfied’, which none of the other cards
`reported in the same scenario. So far, we did not find any information that would
`give us any clue as to what the reason for this behaviour could be.
`
`One thing we find quite unexpected is that none of the cards support Visa predictable
`challenges. We tried two challenge calculation schemes described in two different versions
`of the VGP specification and none of the challenges were calculated accordingly by the
`cards. For the A 221 card however the challenges are predictable – they can be repeated
`each time the associated sequence counter is reset. See the next section for details.
`
`13
`
`IPR2022-00412
`Apple EX1045 Page 13
`
`

`

`No
`Yes
`Yes
`Yes
`No
`No
`Yes
`No
`
`Table9:OverviewresultsoftheGlobalPlatformtest
`
`3
`
`3
`
`3
`
`No
`No
`No
`
`3
`
`No
`
`No
`No
`No
`No
`No
`No
`No
`No
`
`Yes
`No
`Yes
`Yes
`No
`No
`No
`No
`
`05
`15
`05
`05
`05
`05
`15
`05
`
`01
`02
`01
`01
`01
`01
`02
`01
`
`2.0.1
`2.1.1
`2.0.1
`2.0.1
`2.0.1
`2.0.1
`2.1.1
`2.0.1
`
`D22
`B221
`B22
`B211
`C211B
`C211A
`A221
`A211
`
`JavaCardGPVer.SCPSCPOptionKeyDeletionVGPChall.Log.ChannelsAdditionalSD
`
`14
`
`IPR2022-00412
`Apple EX1045 Page 14
`
`

`

`3.3.1 GP Key Registry Test
`
`A separate application has been developed to perform some tests on the GP key registry.
`The test has four purposes:
`• To see if it possible to replace only parts of key sets (say only 1 key, or only 2 keys,
`etc.) and to see what happens to the sequence counter associated with key set after
`such an operation. The sequence counter is only implemented in the Secure Channel
`protocol version 2, thus, the last part only applies to corresponding cards (A 221 and
`B 221). A key is always modified/replaced with the same key.
`• If the sequence counter gets reset after key replacement, it is then easy to check if
`the card implements predictable challenges: (A) we ask the card for a challenge, then
`(B) reset the counter by reloading the keys, and ask the card for a challenge again.
`If the two challenges match that means that the challenge is calculated based solely
`on the sequence counter and some other fixed data (e.g. current AID). Note again,
`that testing predictable challenges only makes sense for cards implementing SCP02.
`• An attempt to delete only one key out of the key set is attempted. Again, if this
`turns out to be possible, we check (a) what happens to the sequence counter, (b)
`whether such ‘crippled’ key set is usable – an authentication is attempted.
`
`Below we summarize the results for the different cards:
`
`A 221 This card exhibits very specific behaviour:
`• It is possible to modify the whole key set in one go (key identifiers #1, #2, #3)
`without any problem.
`• The sequence counter gets reset after any key replacement/modification in the
`given key set.
`• It is possible to modify only key #2 (the MAC key) and the card still functions
`normally.
`• It is possible to modify key #1 (AUTH+ENC) but only once. A second attempt
`results in an error. It is however possible to reload the whole key set again. If we
`try to modify key #1 and some other key (meaning a pair of keys that includes
`key #1) an error is always reported – a pair of keys that includes key #1 cannot
`be modified.
`• It is possible to modify key #3 (DEK/KEK), but the whole key set is not usable
`after such modification – authentication cannot be performed, because the card
`cryptogram cannot be verified (note that the keys are always replaced with the
`same keys). Repl