`

`

`

`40
`
`ICC
`
`Cha ter 2 • Physical Characteristics of Smart Cards
`
`The computer on a smart card is a single ICC that includes the CPU, the mem(cid:173)
`ory system, and the VO lines. A single chip is used in order to make tapping into
`information flows inside the computer more difficult. If more than one chip
`were used to implement the smart card computer,
`the connections between the
`chips would be obvious points of attack. Signals passing across these connec(cid:173)
`tions would typically not be protected (e.g., by encrypting
`information) from
`from the card would likely be
`eavesdropping. Hence, extracting
`information
`greatly enhanced.
`Most smart card programming consists of writing programs on a host com(cid:173)
`puter that sends commands to and receives results from predefined or applica(cid:173)
`tion-specific smart cards. These applications read data from and write data to the
`smart card and perhaps make use of the modest computing powers of the proces(cid:173)
`sor on the smart card. Smart cards, in these applications,
`typically are secure
`stores for data pertaining to the individual bringing the card to the system, such
`as personal identification data.
`In situations where no off-the-shelf card contains all the functionality needed
`by the application, the programmer may be able to extend the capabilities of an
`off-the-shelf card by writing software that runs on the card itself. This software
`may implement special-purpose or higher level function on the card that is a
`combination of existing operating system functions, or it may provide additional
`protections for the data stored on the card.
`Finally, there may be situations where the operating system capabilities of an
`existing smart card need to be extended or where a wholly new and unique smart
`card needs to be manufactured. Examples of such situations
`include a closed
`system application where cost or a particularly high level of security is a critical
`factor or where a particular encryption algorithm is needed to connect the smart
`card to an existing host system. In these situations, smart card programmers
`write new operating system software for smart cards partially or completely in
`the assembly language of the processor on the smart card.
`Regardless of the type of software being written, the smart card programmer
`must be constantly aware of the two central concerns of smart card software: data
`security and data integrity. The invocation of operations on the smart card must
`be allowed only by entities whose identities can be authenticated by the smart
`card. Conversely, the smart card's identity must be authenticated by the off-card
`(host computer) application. In some instances, the privacy of information flow(cid:173)
`ing to and from the card must be guaranteed by encrypting the information.
`An interesting problem that must be handled with the computer in a smart
`card is the integrity of information in the ICC in the midst of transaction compu·
`tations. Power to the ICC is provided through the reader connections to a smart
`
`IPR2022-01239
`Apple EX1018 Page 53
`
`

`

`

`

`

`

`Card Construction
`
`43
`
`mise the smart card. It should be noted that security measures for smart card sys(cid:173)
`tems are in a constant state of evolution in response to the constant evolution of
`attack mechanisms.
`Historically, there are a variety of attacks against smart cards, which are facil(cid:173)
`itated by the external provision of power and programming (clock) control to the
`card. One such class of attack is termed "power analysis." This approach makes
`use of knowing sequences of commands that are to be executed by the smart
`card processor and, by monitoring in very fine-grained steps the power con(cid:173)
`sumed by the smart card processor, determining which commands are being exe(cid:173)
`cuted; including determining the values of parameters used to trigger switching
`among processing pathways in the command sequences. This approach is partic(cid:173)
`ularly adept at isolating cryptographic operations involving the use of keys; that
`is, encryption and decryption operations. In some instances, the breaking of
`cryptographic keys can be greatly enhanced (speeded up) by power analysis.
`The counter to this type of attack is to be cognizant of the attack mechanism
`while creating the on-card code which will effect the cryptographic operations.
`The cryptographic algorithms can be coded so that power analysis is greatly
`diminished as a viable attack. Of course, it should be remembered that to make
`use of such an attack means that the card must be in the hands of the attacker. This
`means that the cardholder should be able to detect the loss of the card and report
`it, allowing the information (e.g., keys) contained on the card to be invalidated.
`Another attack, which is somewhat similar, is termed "differential fault anal(cid:173)
`ysis." In this form of attack, a particular (usually cryptographic) operation is inj(cid:173)
`tiated and then an error is induced into the card operation causing an error
`response from the algorithm. If the error can be induced repeatedly, it is possible
`to glean information from the error responses that is useful in breaking the on(cid:173)
`card keys. As we'll discover when we look at a couple of specific (commercial)
`smart cards in Chapter 6, this type of attack can be diminished by reducing the
`information returned by an error condition within the computation.
`Attacks such as these are damaging to a system at large in the case where
`information from a single card can somehow be used to compromise a larger
`segment of the system in which it works. If the information gleaned from a sin(cid:173)
`gle card can only impact that single cardholder, then the integrity of the overall
`system can generally be maintained. Specifically, if the attacker must have phys(cid:173)
`ical possession of the card in order to pursue a particular attack mechanism, then
`the cardholder has an opportunity to notice the missing card and report it to the
`system's administrators. In this case, strictly personal information, such as a
`(cryptographic) key used to establish the identity of the cardholder, can be inval(cid:173)
`idated and reissued.
`Probably the greater risk to the individual cardholder are attacks aimed at
`intercepting information as it flows between the card and the terminal configura-
`
`IPR2022-01239
`Apple EX1018 Page 56
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`ICC Architecture --------
`
`~-..
`
`,•,.,..
`
`. '"'"-
`
`....
`
`51
`
`ure sections of NVM so that a program loaded into NVM cannot be overwritten
`(essentially turning the NVM into ROM) or so that the CPU won't take instruc(cid:173)
`tions and therefore execute code from this part of memory.
`These various types of memory used in smart card chips bring in a very inter(cid:173)
`esting wrinkle with respect to the chip design for smart card ICCs. The imple(cid:173)
`mentation technologies used for chip memories vary greatly in the size of
`individual memory cells as we saw illustrated in Figure 2.5. The smallest mem(cid:173)
`ory element is read-only memory. This type of memory, as the name implies,
`can be read by typical computer elements, but it requires very special equipment
`in order to write information into the memory. In fact, the writing of ROM can
`be incorporated very early into the chip fabrication process itself; this technique
`tends to enhance the security of the chip because it is difficult to examine the
`contents of the ROM without destroying the chip, even with very expensive
`probing equipment. So this type of memory is very useful for permanently
`encoding stored programs for the smart card, but it is useless for storage of
`dynamic information that needs to be changed during the normal use of the card.
`Significantly larger is the electrically erasable and programmable read-only
`memory (EEPROM). The contents of this type of memory in a smart card chip
`can actually be modified during normal use of the card. Hence, programs or data
`can be stored in EEPROM during normal operation of the card and then read
`back by applications that are using the card. The electrical characteristics of
`EEPROM memory are such that it can only be erased and then reprogrammed a
`finite (but reasonably large) number of times, generally around I 00,000 times.
`While somewhat limited, techniques have evolved which make this type of
`memory quite useful for typical smart card uses. EEPROM memory cells tend to
`be about a factor of four larger than ROM memory cells. EEPROM, like ROM,
`does have the nice characteristic of being nonvolatile memory; that is, the infor(cid:173)
`mation content of the memory is unchanged when the power to the memory is
`turned off. So information content is preserved across power-up and power(cid:173)
`down cycles on the smart card chip.
`Larger still is a memory type known as RAM. This is the type of memory
`used in typical computer systems such as a desktop PC. Information can be
`written and erased in this type of memory a very large number of times. In the
`smart card chip, however, a RAM memory cell is approximately four times
`larger than an EEPROM memory cell. RAM is also volatile memory; that is,
`the contents of the memory are lost when power is removed from the memory
`cell. So information in RAM is not preserved across a power-down and power(cid:173)
`up cycle on a smart card. RAM is, nevertheless, essential for certain operations
`in smart card applications; in particular, it requires much less time for RAM
`locations to be read or written by the chip's processor unit. This can be
`extremely important when the smart card is interacting with a PC application in
`
`IPR2022-01239
`Apple EX1018 Page 64
`
`

`

`52
`
`Cha. ter 2 • Phy:sical Characteristics of Smart Cards
`
`which the timing of responses from the card to the PC are important; this is
`often the case in the mobile telecommunications
`area (i.e., smart card-based
`cellular telephones).
`The net result is that smart card chips tend to make use of varying amounts of
`each memory type depending on the specific application for which the smart
`card is intended to be used. The most powerful chips used in smart cards today
`have RAM sizes in the I-kB to 2-kB range, ROM sizes in the 16-kB to 96-kB
`range, and EEPROM sizes in the 8-kB to 64-kB range.
`
`Cryptographic Assist
`
`The demand for stronger encryption in smart cards has outstripped the ability of
`software for these modest computers to generate results in a reasonable amount of
`time. Typically, I to 3 seconds is all that a transaction involving a smart card
`should take; however, a I 024-bit key RSA encryption can take IO or more seconds
`on a typical smart card processor. As a result, some smart card chips include
`coprocessors to accelerate specifically the computations done in strong encryption.
`A typical smart card processor is an 8-bit microprocessor. Such a processor is
`capable of manipulating only I byte of information at a time. This manifests
`itself in the support of 8-bit integer arithmetic as the primary computational
`facility of the computer. Handling larger integer arithmetic or floating-point
`arithmetic operations requires significant additional programming beyond the
`basic instruction set of the processor. This presents something of a problem
`when you need to support public key cryptography on a smart card chip.
`Public key cryptography is predicated on the use of integer arithmetic on a
`scale that severely taxes the capabilities of a typical smart card processor. Per(cid:173)
`forming encryption or decryption operations can be extremely time-consuming,
`taking several seconds or even minutes. Because these delays are not acceptable
`given the time it should take to conduct a typical transaction, enhancements to
`smart card processors are needed. This enhancement has been accomplished by
`adding to the chip a second processor that is capable of enhanced performance for
`selected integer arithmetic operations, such as fast integer multiply operations.
`This greatly speeds up the public key cryptography operations; however, it affects
`the overall size of the chip (slightly) and the cost of the chip (more significantly).
`
`Security Hardening
`
`One of the security threats to smart cards is the ability of an attacker to probe the
`ICC with high-powered magnification devices such as scanning electron micro(cid:173)
`scopes (SEM). This form of attack is essentially destructive of the smart card.
`That is, one must disassemble the card in order to extract the ICC from it. One
`
`IPR2022-01239
`Apple EX1018 Page 65
`
`

`

`

`

`4
`
`Smart Card
`Applications
`
`Smart
`cards provide a personal component of applications, whatever the
`complete purpose of the application might be. The smart card is carried by an
`individual and is periodically utilized in various equipment configurations
`to
`achieve the results or obtain the services provided by those configurations. The
`most common feature of smart cards in an application is to establish or authenti(cid:173)
`cate the identity of the cardholder and the cardholder's right (permission) to
`access and use the application in question. In other cases, besides authenticating
`identity, the smart card may carry additional information needed by the applica(cid:173)
`tion. For example, in financial debit and credit applications, the smart card may
`carry an account number (or numbers), which are to be accessed in backend
`servers involved in the application.
`
`A common aspect to virtually all smart card-enabled applications is that they
`involve establishing a communication channel between the smart card and some
`other computer processor acting as the general controller for the application.
`This translates into a situation of two application-level programs running on
`peer-level computers needing to communicate with each other. This is exactly
`the scenario of the International Standards Organization (ISO) Reference Model
`for communication protocols illustrated in Figure 4.1.
`
`Essentially, all of the layers described in the ISO Reference Model are found
`in the communication channel between an off-card application and the corre(cid:173)
`sponding application on the smart card. We'll look at a more detailed compari(cid:173)
`son in Chapter 7 where we'll recognize that the layering in the smart card
`environment is not quite what was envisioned in the ISO Reference Model, but
`the sum total of the layers is pretty well there.
`
`91
`
`IPR2022-01239
`Apple EX1018 Page 67
`
`

`

`

`

`

`

`

`

`Security
`
`95
`
`• validation by the vendor that the credit card account represented by the
`card is valid
`• validation by the vendor that the account maintains a sufficient credit
`balance to cover the cost of the item being purchased
`• debiting the credit account represented by the card by the amount of
`the item purchased
`• crediting the account of the vendor with the amount of the item
`purchased (less any fees due to the bank, etc. related to the credit
`card transaction)
`
`In the performance of this transaction, the cardholder would also like some
`assurances that much, if not all, of the information related to the transaction is
`held private. The credit card name, account number, and validation code should
`not be obtained by some unscrupulous character bent on making fraudulent pur(cid:173)
`chases with the purloined information.
`In the performance of a credit card transaction, there are actually many more
`components than previously mentioned. However, in just the steps noted, you
`can see that physical separation of the various parties to the transaction makes it
`difficult to guarantee that all these parties are satisfied about the integrity and
`privacy of the transaction.
`This section discusses the characteristics of security involved in upporting
`such a transaction. To facilitate this discussion, the objectives of a security envi(cid:173)
`ronment are first presented in somewhat abstract terms. After, some of the ele(cid:173)
`ments (we'll call them players) of a widely distributed transaction system are
`examined. Then, some of the mechanisms currently in wide use to provide the
`desired characteristics
`through the identified players are examined. Finally,
`some of the attacks used to thwart these security mechanisms are reviewed.
`
`Objectives and Characteristics of Security Systems
`
`Security within physical or electronic systems can be viewed as the provision of
`one or more general characteristics:
`
`• authentication
`• authorization
`• privacy
`• integrity
`• nonrepudiation
`
`IPR2022-01239
`Apple EX1018 Page 71
`
`

`

`

`

`

`

`98
`
`Chapter 4 • Smart Card Applications
`
`When a credit card purchase is made, the protocol of presenting the card t
`the vendor, performing the financial transaction, and returning a receipt of tho
`transaction to the cardholder is set up to minimize the conveyance of sensitiv:
`information such as the account name, number, or validation number to those
`who might be casually observing the transaction. Similarly, when using a tele(cid:173)
`phone calling card at a public telephone, conventional wisdom mandates that
`one be very cautious to hide the entry of the card number, lest it be seen by
`someone who will make note of it and use it to make cardholder telephone calls
`that the cardholder has not authorized.
`
`Integrity
`
`Integrit) is the concept that none of the information involved in a transaction
`is modified in any manner not known or approved by all the participants in the
`transaction, either while the transaction is in progress or after the fact. In the
`previous homework example, when the student turns in the homework, the total
`transaction may not actually be concluded until the teacher reviews the home(cid:173)
`work and records a grade. In this simple example, the integrity of the informa(cid:173)
`tion is maintained by the teacher keeping the homework in controlled possession
`until it is graded and the grade recorded. The student's integrity facility in this
`case is to get the homework back from the teacher and to be able to review it to
`make sure that it's in the same state as when it was submitted.
`For the homework example, the integrity of the transaction system is typically
`not of paramount importance to the student because teachers don't often mali(cid:173)
`ciously modify homework in their possession. The teacher might be more con(cid:173)
`cerned with the integrity of the information: first, in the sense of knowing that
`the homework hasn't been modified since it was turned in (usually not too likely)
`and second, in knowing that the homework was actually done by the student.
`This latter aspect is often not guaranteed by any stringent mechanism in the
`case of homework. In the case of examinations, which might be viewed as more
`valuable, more proactive mechanisms are sometimes used. For example, ome
`universities make use of an "honor code" under which a student might be
`required to attest to the fact that an examination was completed by the student
`and that the student neither gave nor received any assistance during the exami(cid:173)
`nation proper. Providing mechanisms to facilitate this concept in the highly di·
`persed environment of electronic transactions across a wide area computer
`network is a bit more challenging.
`
`Nonrepudiation
`
`Non repudiation is establishing the fact of participation in a particular tran ac·
`tion by all the parties to the transaction such that none of the parties can claim
`
`IPR2022-01239
`Apple EX1018 Page 74
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`~
`
`108
`
`--"'-----------Chapter
`
`4 • Smart Card Applications
`
`Capabilities List
`
`A relatively orthogonal way of loolcing at this same authorization model (i.e.,
`one represented by an ACL) is called a capabilities list. In most instances, the
`way this variant of the model is implemented, the capabilities list is passed
`along to the server essentially merged with the identity authentication. That is
`there is assumed to be an administration function that decides, external to the
`actual server, what capabilities (privileges) a specific identity is to have with
`respect to the object of interest.
`In both variants, the security procedures followed are essentially the same.
`First, authenticate the identity, and then go to an authorization list to detennine
`what privileges that identity has with respect to the object of interest. The most
`straightforward mechanism for doing this is to include the capabilities list in the
`digital certificate through which identity is tied to a key that can be used to
`authenticate that identity.
`
`I
`
`Privacy
`
`The final concept of security to be dealt with is privacy, which is keeping the
`details of a transaction secret from everyone not involved in the transaction. The
`cryptographic mechanisms previously discussed are adequate to provide transac(cid:173)
`tion privacy. In general, the major design factor (i.e., deciding which mechanism
`to actually use) is one of performance in the actual operational environment.
`As mentioned previously, public key cryptography is significantly more pro(cid:173)
`cessor intensive than is symmetric key cryptography. Consequently, most sys(cid:173)
`tems make use of symmetric key algorithms to actually encrypt the information
`flow between two disparate points involved in the same transaction. In point of
`fact, however, public key mechanisms are still quite useful in even this case.
`Specifically, public key mechanisms are useful in order to exchange the sym(cid:173)
`metric key needed by both ends of the communication channel. Such shared
`secrets are well-recognized risk areas in security ystems; the longer and more
`often that the same ymmetric key is used, the better the chance for an attacker
`to figure out what it is and use that knowledge to compromise the privacy of the
`transaction channel.
`If public keys are well known throughout the specific security system, then
`the mechanisms discussed earlier can be used in which one end of the transac(cid:173)
`tion channel can generate a random symmetric key and send it, under cloak of
`encryption by the other end's public key knowing that only the other end po·
`sesses the private key necessary to decrypt the me sage containing the secret
`symmetric key.
`
`IPR2022-01239
`Apple EX1018 Page 84
`
`

`

`

`

`110
`
`~------Chapter
`
`4 • Smart Card Applications
`
`preclude any eavesdropper from listening in on the proceedings of the transac.
`tion. These two computer systems can then participate in the application on
`behalf of the cardholder, assuming that the cardholder is truly the owner (holder)
`of the smart card. So, an additional authentication mechanism is needed to
`authenticate the identity of the cardholder to the smart card. After this is done
`'
`the card can participate in the application on behalf of the cardholder.
`The method used for authenticating the two computer systems to each other
`(i.e., the smart card ICC to the host computer) consists of each computer prov(cid:173)
`ing to the other that it knows a secret shared between the two machines. To
`enhance the long-term security of the two systems, it is desirable that this mech(cid:173)
`anism not involve actually moving the secret between the two systems. So, in
`the approach used, the shared secret is a key that can be used by a cryptographic
`algorithm to encrypt information. The approach can use either symmetric key
`cryptography or asymmetric key cryptography. In the authentication process, a
`
`key is used by one side of the operation (either the card or the host computer) to
`encrypt a random piece of information that has been specified by the other side
`of the operation. If both sides are using (know) the same key, then the "other''
`side will be able to decrypt and recover the random piece of information.
`When the card has authenticated the off-card computer's identity, the card is
`then said to be in an AUTH state relative to the key used in the authentication
`process. Various· commands can be tagged such that the on-card system must be
`in an AUTH state before the command can be executed. Since the off-card com(cid:173)
`puter sends commands to the on-card computer, this mechanism means that the
`off-card system has to be authenticated to the on-card system in order execute
`these commands. Since the various commands provide access to information or
`computational services on the card, this defines an authorization mechanism
`which limits access to that information of those services.
`There can be multiple key files stored on a card and there can be multiple
`keys in each of those files. This means that, in theory, a very large number of
`identities can be authenticated by the card and given access to various pieces of
`information or services.
`Another authentication mechanism uses a PIN stored in a file. If an off-card
`computer can provide a command containing the correct PIN, it can cause the
`on-card system to enter a state called CHV (cardholder verified). Commands
`can be predicated upon being in the CHV state just as for the AUTH state. So,
`by proper design of the information structures on the card, various information
`and various capabilities (in essence, various applications) can be made available
`to different off-card identities. In this case, the off-card identities are the "own·
`ers" of the application systems in which the on-card component work.
`ln the following sections, we'll examine the detaj)s of the specific command
`u ed to authenticate identitie . Plu , we'll ee a tandard information wrage
`
`l
`
`IPR2022-01239
`Apple EX1018 Page 86
`
`

`

`

`

`

`

`