114
`
`________
`
`C_hap_ter 4 • Smart Card Applications
`
`Security Commands
`
`Associated with each component of the file system is a list of access propertie s.
`Through these access properties, a state can be defined such that the smart card
`system must be put into that state, through
`the successful execution of a series
`that component of the file system can be
`of commands by the reader, before
`accessed. At the most basic level, the operations
`to be performed on the file
`system are to select a specific file and then write information to that file or read
`information from that file. As shown in the following sections, the access prop.
`erties may be as simple as requiring
`the reader to provide a predefined PIN or
`as complex as the reader proving
`that it possesses some shared secret (e.g., a
`key) with the card. These mechanisms will be reviewed
`in more detail in the
`following sections.
`
`The VerifyCommand
`
`CLA
`
`C016
`
`INS
`
`2016
`
`Pl
`
`P2
`
`00 16
`
`00 16
`
`Le
`
`0316
`
`Data
`
`53166116 5316
`
`The Verify
`command is a command sent by a reader-side application to the
`security system on the card to allow it to check for a match to password type
`information stored on the card. This command
`is used to allow the reader-side
`application
`to convince
`the card that it (the reader-side application) knows a
`password maintained by the card to restrict access to information on the card.
`The password type information may be attached to a specific file on the card
`or to part or all of the file hierarchy on the card. Successful execution of this
`command
`indicates that the reader-side application did know the correct pass·
`word and it puts the card into a state such that a subsequent access to a file
`guarded by this pas word information will succeed.
`If the Verify
`command fail
`(i.e., the pa sword required by the card is not
`correctly provided by the reader-side application),
`then an error status indicator
`is returned by the card to the reader-side application.
`
`The Internal
`
`AuthenticateCommand
`
`CLA
`
`C016
`
`INS
`
`8816
`
`Pl
`
`00 16
`
`P2
`
`0016
`
`Le
`
`0316
`
`Data
`
`0216 0116 0316
`
`is a command ent by a
`Authenticate
`The Internal
`command
`reader-side application
`to the security sy tern on the card to allow the card to
`prove that it possesses a secret key that is shared with the reader- ide applica-
`
`IPR2022-01239
`Apple EX1018 Page 90
`
`

`

`

`

`

`

`

`

`118
`
`DF Characteristics
`
`The DF also is a container or a directory file in the same vein as the MF. The DF
`forms a subdirectory within the file hierarchy rooted in the MF. A DF also can
`be identified by a file identifier. A DF must be given a unique file identifier
`within the DF (or MF) that contains
`it. This allows for the creation of a unique
`path designation
`for a file (i.e., a path is simply the concatenation of the file
`identifiers of the file in question, and of all the DFs between the file in question
`and its containing DF or MF).
`A DF also can be referenced by a name that may be from 1 to 16 byes
`for the DF name are found in the ISO/IEC
`long. The naming conventions
`7816-5 specification.
`
`EF Characteristics
`
`The EF is the leaf node of the file hierarchy. It is the file that actually contains
`data. There are two variants of EFs: an internal EF, which is to be used by appli(cid:173)
`cations on the card, and a working EF, which is used as a storage mechanism for
`information used by an off-card application.
`Within a specific DF, an EF may be identified by a short (5-bit) identifier.
`There are four variants of EFs as illustrated in Figure 4.12:
`
`• a transparent file
`• a linear, fixed-length record file
`• a linear, variable-length record file
`• a cyclic, fixed-length record file
`
`A transparent file can be viewed as a string of bytes. When a command is
`used to read or write information from a transparent file, it is necessary to pro·
`vide a byte offset (from the start of the file) to the specific byte (within the trans(cid:173)
`parent file) where reading or writing should begin. A command to read or write
`information from/to a transparent file will also contain a counter or length of the
`byte string to be read or written to the file.
`Fixed- or variable-length record files are, as the name suggests, files that com·
`(within a file) are identified by 8
`prise subdivisions called records. Records
`sequence number. In a fixed-length record file, all the records contain the same
`number of bytes. In a variable-length record file, each record in the file can co~
`tain a different number of bytes. As mjght be suspected, a variable-length reco_
`file generally has a significantly higher overhead in read/write access time and 10
`the amount of administrative (data storage) overhead required by the file 5Ystem-
`
`IPR2022-01239
`Apple EX1018 Page 94
`
`

`

`

`

`120
`
`___._________
`
`Chapter 4 • Smart Card Applications
`
`The Select
`
`File Command
`
`CLA
`
`INS
`
`Pl
`
`C016
`
`A416
`
`0016
`
`P2
`
`0016
`
`Le
`
`0216
`
`Data
`
`3F16 0016
`
`command is used to establish what may be thought of as
`File
`The Select
`a logical pointer to a specific file in the smart card's file system. After a file is
`selected by this command, any subsequent commands, such as those to read or
`write information, will operate on the file pointed to by this logical pointer.
`Access to the smart card's file system
`is not multithreaded (from the card's
`viewpoint), but it is possible to have multiple such logical pointers in play at any
`point in time. This is done by using the Manage Channel
`command to estab(cid:173)
`lish multiple logical channels between the reader-side application and the card.
`Commands to access different files can then be multiplexed (by the reader-side
`application) allowing different files on the card to be in various states of access
`by the reader-side application at the same time.
`The primary piece of information
`the command must convey (from the
`reader-side application to the smart card's APDU processor) is the identification
`of the file to which this logical pointer must point. This identification can be
`provided in three ways (with the specific addressing mechanism being indicated
`in the data field of the Select File command APDU):
`
`• by file identifier (2-byte value)
`• by DF name (string of bytes identifying the DF)
`• by path (concatenation of file identifiers)
`
`The Read Binary Command
`
`CLA
`
`INS
`
`C016
`
`B016
`
`Pl
`
`0016
`
`P2
`
`0016
`
`Le
`
`1016
`
`Data
`
`empty
`
`command is used by a reader-side application to retrieve
`The Read Binary
`some segment of an EF on the card. The EF being accessed must be a transpar(cid:173)
`ent file; that is, it cannot be a record-oriented
`file. If a Read Binary
`command
`is attempted on a record-oriented EF, the command will abort with an error indi(cid:173)
`cator being returned by the card to the reader-side application.
`Two parameters are passed from the reader-side application to the card for
`this command: an offset pointer from the start of the file to initial byte to be read,
`and the number of bytes to be read and returned to the reader-side application.
`
`IPR2022-01239
`Apple EX1018 Page 96
`
`

`

`

`

`122
`
`~~--=-:;......
`
`__
`
`C_hapter 4 • Smart Card Applications
`
`The Erase Binary Command
`
`CLA
`
`INS
`
`Pl
`
`C016
`
`0E16
`
`0116
`
`P2
`
`0116
`
`Le
`
`0116
`
`Data
`
`0616
`
`The Erase Binary
`is used by a reader-side application to erase
`command
`(set the value to Q) a string of bits within an EF on a card. The file being
`file; that is, it cannot be a record-oriented file. If
`accessed must be a transparent
`an Erase
`Binary
`command
`is attempted on a record-oriented EF, the com(cid:173)
`mand will abort with an error indicator being returned by the card to the reader(cid:173)
`side application.
`Two parameters are specified as part of the command: an offset from the start
`of the EF to the segment of bytes within the file to be erased and the number of
`bytes within that segment.
`
`The Read Record Command
`
`CLA
`
`INS
`
`Pl
`
`C016
`
`B216
`
`0616
`
`P2
`
`0416
`
`Le
`
`1416
`
`Data
`
`empty
`
`The Read Re cord
`is a command sent by a reader-side applica(cid:173)
`command
`tion to read and return the contents of one or more records in an EF on a card.
`This command must be executed against a record-oriented EF. If it is applied to
`a transparent EF, the command will abort and an error indicator will be sent
`from the card back to the reader-side application.
`the command, the one desig(cid:173)
`Depending on the parameters passed through
`nated record is read and returned, or all the records from the beginning of the
`file to the designated
`record are read and returned, or all the records from the
`designated record to the end of the file are read and returned.
`
`The Nri te Record Command
`
`CLA
`
`INS
`
`Pl
`
`P2
`
`Le
`
`Data
`
`C016
`
`D216
`
`0616
`
`0416
`
`1416
`
`5316 61 16 6C 16 6C 16 79 16 20 164716
`7216 6516 6516 6E16 0016 0016 0016
`0016 0016 0016 0016 0016 0016
`
`'
`
`Record
`The Write
`is a command sent by a reader-side applica(cid:173)
`command
`tion to write a record into an EF on the card. Thi command must be executed
`against a record-oriented EF. If it i applied to a tran parent EF, the cornmand
`will abort and an error indicator will be ent from the card back to the reader·
`
`IPR2022-01239
`Apple EX1018 Page 98
`
`

`

`

`

`124
`
`_ ___.;;.__ ______
`
`C_h __ apter 4 • Smart Card Applications
`
`will abort and an error indicator will be sent from the card back to the reader.
`side application.
`this command is used to write a
`command,
`As with the Update
`Binary
`specific record into an EF. The net result of the operation
`is that the specific
`record in the EF is erased and the new record specified in the command is writ(cid:173)
`ten into the EF.
`
`Administrative Commands
`
`specified by 1SO/IEC 7816-4 is quite
`command protocol
`The master-slave
`restrictive
`in its ability to accommodate
`the wide variety of commands that
`you might want to access on a smart card. In an attempt to compensate for
`some of the syntactic shortcomings, 1SO/IEC 7 816-4 also defines a number of
`administrative
`commands
`that allow a wider latitude of command structures
`and responses.
`
`The Get Response Command
`
`CLA
`
`INS
`
`Pl
`
`C016
`
`C016
`
`0016
`
`P2
`
`0016
`
`Le
`
`1416
`
`Data
`
`empty
`
`is another command that allows the use of
`command
`The Get Response
`the T=0 link-level protocol for conveying the full range of APDUs. Specifically,
`the Case 4 type of APDU body cannot be supported with the T=O protocol. That
`is, you can't send a body of data to the card and then receive a body of data back
`as a direct response to that command. For this type of command, using the T=O
`protocol,
`the initial command results in a response
`that indicates more data is
`command
`is then used to retrieve
`waiting (in the card). The Get Response
`that waiting data.
`It should be noted that no other command can be interleaved between the
`original command and the Get Response
`command.
`
`The Manage Channel Command
`
`CLA
`
`C016
`
`INS
`
`7016
`
`Pl
`
`0016
`
`P2
`
`0116
`
`Le
`
`0016
`
`Data
`
`empty
`
`is used by the reader-side application 10
`The Manage Channe 1 command
`channels between it and the card. When
`open and close logical communication
`the card initially establishes an application-level
`protocol with the reader· i~e
`application (i.e., following the ATR sequence) a basic communication channel 1
`
`IPR2022-01239
`Apple EX1018 Page 100
`
`

`

`

`

`126
`
`atively general in its specification. So, the fact that the definition of just what
`constitutes a data object varies widely from card to card does not necessarily
`mean that the semantics of the command varies from card to card. In fact, the
`attractive feature of this command is the fact that you do not need to know the
`identity of a specific file into which the "data" is to be stored. This tends to
`make the command similar across a variety of different smart cards. An applica(cid:173)
`tion, should it need to store only a modest bit of information, can do so with this
`command and be moderately assured that the command will work on a variety
`of different smart cards.
`
`SUMMARY
`This chapter has hopefully provided you with a fairly extensive introduction into
`the structure of the smart card-side of a smart card-aware application. The most
`interesting facets of this environment are the security mechanisms that are
`defined through a set of international standards and which find themselves
`present on most smart cards in use today. Further, these same international stan(cid:173)
`dards establish a paradigm for smart card applications in the form of an on-card
`file system replete with an authentication and authorization mechanism that is
`firmly rooted in the use of cryptographic services to achieve the desired charac(cid:173)
`teristics of security. A series of commands for manipulating this on-card file
`system forms the backbone of many smart card applications in use today.
`
`IPR2022-01239
`Apple EX1018 Page 102
`
`

`

`6
`
`Commercial Smart Card
`Commands
`
`As
`we've seen in previous chapters, there are two distinct styles of smart
`cards found in widespread deployment today:
`
`• fixed command set cards built around the ISO/IEC 7816-4 command set
`• post-issuance programmable smart cards
`
`With the first style, the card is designed with a command set that is applicable
`to a particular application area. As you remember from Chapter 4, the Interna(cid:173)
`tional Standards Organization (ISO) command set is aimed at provision of an
`on-card file system for storing and retrieving data, and with a security model
`through which the on-card and off-card elements of applications can authenti(cid:173)
`cate themselves to each other. This security model also allows the cardholder to
`authenticate himself or herself to the card in order to validate that the card is
`operating on behalf of the correct person. With the second style of card, a com(cid:173)
`mand set can be custom designed for an application to be loaded onto the smart
`card. By adding more and more such applications, a single smart card can be
`used in a wide variety of application areas. To understand these two card styles
`in more detail, we're going to review the specifics of two cards, one of each
`style. These are cards currently offered by Schlumberger and are in widespread
`commercial use today: the Cryptoflex 32K eGate® card and the Cyberflex
`Access 32K eGate® card.
`You'll notice that both cards have the term eGate in their names. This is the
`name that Schlumberger has given to a technology added into the integrated cir(cid:173)
`cuit chip (ICC) of both of these cards that enables the chip to communicate
`using Universal Serial Bus (USB) protocols in addition to the usual smart card
`
`183
`
`IPR2022-01239
`Apple EX1018 Page 103
`
`

`

`

`

`Cryptoflex 32K eGate
`
`185
`
`complete set of commands aimed at secure manipulation of on-card files and for
`selected transaction operations with information stored in these files. These
`additional commands are particularly adept at supporting on-card purse opera(cid:173)
`tions via the card's file system. As we'll see in a more detailed example applica(cid:173)
`tion in Chapter 9, the command set is quite adequate for interesting variatio~s on
`the security infrastructure theme.
`The discussion of the Cryptoflex commands found in the remainder of this
`chapter does not constitute a complete technical specification for the Cryptoflex
`card or its command set. We're examining many (most) of the commands in
`some detail in an effort to give you a sense of what the commands are attempt(cid:173)
`ing to accomplish. However, you may find it necessary to consult the technical
`specification of the card provided by Schlumberger, the card vendor, in order to
`answer all of your detailed questions aimed at actually programming with the
`Cryptoflex card.
`
`Commands
`
`The Cryptoflex card provides four classes of commands:
`
`• Administrative commands are used to prepare the card for
`distribution to the individual cardholders. These commands are used
`only during the manufacturing process and are typically disabled
`prior to card issuance.
`• Security commands are used to authenticate identities of the various
`entities that will be participating in smart card operations and
`transactions.
`• Operational commands are used to manipulate information stored on
`the card.
`• Auxiliary commands are used primarily for housekeeping operations
`needed during the course of a smart card application.
`
`Administrative Commands
`
`The Administrative commands provided by the Cryptoflex card are used in
`two distinct ways in the preparation and personalization of the card: for soft(cid:173)
`mask additions to the card and for construction of a file hierarchy to be used by
`the applications supported by the card. All of these commands are controlled by
`access conditions that must be fulfilled prior to the individual commands being
`used. Through these access conditions, the commands can be made unusable
`outside of the manufacturing operation. In certain instances,
`the CREATE
`FILE, CREATE RECORD, and DELETE FILE commands are controlled by
`
`IPR2022-01239
`Apple EX1018 Page 105
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`194
`
`Cha ter 6 • Commercial Smart Card Commands
`
`selves to each other. The external key file, which has a file ID of "0011," has the
`structure indicated in Table 6.8.
`
`Table 6.8 External Key File Structure
`
`Bytes
`
`Description
`
`RFU
`
`2
`
`3
`
`Key length of key O (X)
`
`Algorithm ID for key 0
`
`4-3+X
`
`KeyO
`
`5+X
`
`6+X
`
`7+X
`
`Key O Attempt Preset Value
`
`Key O Remaining Attempt Counter
`
`Key length of key I
`
`Length
`
`1 byte
`
`1 byte
`
`I byte
`
`X bytes
`
`1 byte
`
`1 byte
`
`I byte
`
`Both the external key file and the internal key file have chained segments,
`each defining a single key; so, the file itself can hold many keys. The set of
`chained keys is terminated by setting the key length of the final key to zero.
`Thus, through these key files, many different off-card identities can authenticate
`themselves to the card and many on-card identities can authenticate themselves
`to the off-card application for any specific dedicated file structure. By defining
`different key files within different dedicated file
`tructures, we can enable the
`use of a large number of identities to restrict acces to information or operation
`on the card; the card can truly work for a large number of master .
`
`Before a Cryptoflex card is released from the manufactu1ing process, a ma -
`ter file with ID "3F00" is created on the card. Under this dedicated file, an ele(cid:173)
`mentary file for external keys with ID "001 l" is created with two keys in it. Key
`0 is termed the Application Tran port Key (ATK) and Key I is termed the Appli(cid:173)
`cation Activation Key. Key 0 is used to limit access to command to create an
`application file structure and Key l is used to limit access to command that
`enable transactions using thi file structure.
`
`For use with public key cryptography, two RSA key file structure can be
`defined on the card a well: one for the private key (of an RSA key pair) and the
`
`IPR2022-01239
`Apple EX1018 Page 114
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`206
`
`
`
`__._ __ C..c..h_aP.ter 6 • Commercial Smart Card Commands
`
`The statu word response from the RSA SIGNATURE command specifies the
`number of bytes to be retrieved by the GET RESPONSE command.
`
`CLA
`
`INS
`
`Pl
`
`P2
`
`Le
`
`Data
`
`Key#
`
`Data length
`
`Byte string to be signed
`
`After the signing operation is completed in the card, but before the status is
`returned, the inverse (verification) operation is performed using the complemen(cid:173)
`tary (to the private signing key) public key stored in the card. Only if the reciprocal
`operation is consistent with the original byte string does the command response
`occur; otherwise, an error indication is returned. This confirmation operation
`defeats what is termed the Bellcore attack, through which an attacker attempts to
`gain knowledge about an RSA key by intercepting repeated results in which the
`encryption (signing) operation is interrupted through some external means.
`If the byte string to be signed is
`RSA SIGNATURE INTERMEDIATE.
`longer than 128 bytes and/or if a signing key of 2048 bits is to be used, then the
`signing operation requires two (or more) successive commands. The first part of
`the byte string is signed with the RSA SIGNATURE
`INTERMEDIATE com(cid:173)
`mand. The partial results are stored on the card. The last part of the byte string is
`then encrypted using the RSA SIGNATURE LAST command, after which the
`results are fetched from the card using a GET RESPONSE command.
`
`CLA
`
`INS
`
`Pl
`
`P2
`
`Le
`
`Data
`
`Key#
`
`Data Length
`
`Partial byte string
`
`After one or more calls to the RSA SIGNA-
`RSA SIGNATURE LAST.
`INTERMEDIATE command have been made, the last part of the byte
`TURE
`string is encrypted with the RSA SIGNATURE
`LAST. Then, if the signature
`operation has completed correctly, the resulting ciphertext is retrieved from the
`card with the GET RESPONSE command.
`
`CLA
`
`INS
`
`Pl
`
`P2
`
`Le
`
`Data
`
`Key#
`
`Data Length
`
`Final part of byte string
`
`ignature i a way to protect in a
`The digital
`RSA KEY GENERATION.
`secure fa hion the identity represented by the private key of an RSA key pair
`out ide of the card. The private key that actually authenticates the identity is
`
`IPR2022-01239
`Apple EX1018 Page 126
`
`

`

`