`

`

`

`The Actors
`
`319
`
`own right. Making all three types of systems work together is a particularly
`daunting task. To accomplish it well, a coherent management approach and an
`integrated management system are desirable, if not mandatory.
`
`THE ACTORS
`Within large-scale, smart card-based application systems, there are a number of
`distinct roles played out in the development, deployment, and ongoing operations
`of the complete system infrastructure. Some of these roles are consistent with
`those found in typical IT systems. Some are perhaps a bit unique to the smart card
`arena. In the course of this book, we've mentioned most of these principals from
`time to time; now, in the following sections, we'IJ examine some of them in a more
`coherent fashion. In a couple of areas, we'll provide the names of some organiza(cid:173)
`tions that are well known in these particular arenas. Theirs aren't the only groups
`in these areas, but serve as examples of the types of groups you'll seek out if you
`become involved in considering the deployment of a smart card-based system.
`
`The Card Issuer
`
`The central entity in any commercial smart card application venture is the card
`issuer. This is the control point for the application system-the owner of it, if
`you will. More
`to the point,
`the card issuer is usually the ultimate risk
`taker/holder in the system. If there is a breakdown in the overall integrity (secu(cid:173)
`rity) of the system, it is the card issuer's nickel at stake.
`Historically, smart card systems started with the card issuer. The card issuer
`would develop the concept for the application or application system and would
`approach the smart card manufacturer, and others, to develop on-card and off(cid:173)
`card components of the system. In many instances, particularly with financial sys(cid:173)
`tems, the card issuer would be responsible for the long-term operation of the sys(cid:173)
`tem. With current systems, we are at a bit of a transition point insofar as system
`development goes. Today, significant parts of an application infrastructure either
`exist or are off-the-shelf components, ready to be integrated into a final system.
`With the current style of system deployment, smart cards themselves are
`often off-the-shelf items. The card's integrated circuit chip (ICC) architecture is
`developed as a moderately general-purpose computing platform and the installa(cid:173)
`tion of the final application software on it typically involves either soft-mask or
`application installation at prepersonalization
`time (a concept we'll look at in
`more detail a little later on in this chapter).
`The card is typically given to the cardholder by a card issuer. In the case of
`financial cards, the issuer is generally a bank or other financial institution. The
`card issuer generally is responsible for providing the system in which the card can
`
`IPR2022-01239
`Apple EX1018 Page 170
`
`

`

`320
`
`Cha ter 10 • Smart Card System Management
`
`be used to perform its security-related functions. One aspect of this system is typi(cid:173)
`cally the linking of salient infonnation about the cardholder to the functional char(cid:173)
`acteristics of the card. In this area, the issuer functions as a certification authority
`or as a "trust broker." It is through the actions of the issuer that various parties of a
`subsequent transaction can achieve some level of trust in the transaction even
`though they do not know each other prior to the initiation of the transaction.
`In the financial environment, very well-defined protocols have been put in
`place by associations of financial organizations and buttressed by binding
`national and international laws and agreements. In the emerging world of com(cid:173)
`puter networks, the existence of equivalent certification authorities is only now
`being legitimized by evolving system deployment.
`A significant impediment to the deployment of smart card-based systems in the
`IT world has been the lack of card issuer experience in the area. The degree of lia(cid:173)
`bility assumed by the card issuer in this situation can be difficult to assess. In a cor(cid:173)
`porate environment, it is a natural assumption that the corporate entity assume the
`role of card issuer, and, in fact, this is the most common model for successful sys(cid:173)
`tems. Given that a common role for smart cards in any system, but particularly in IT
`systems, is to establish an authenticated identity, the corporate HR function is per(cid:173)
`haps the most logical card issuer of choice. As a matter of fact, the identity that can
`be established through a corporate HR office is probably the "best" identity that can
`be established short of a government ID based on a comprehensive security check.
`
`The ICC Manufacturer
`
`As we saw in Chapter 2, the ICC contained in a smart card is a complete com(cid:173)
`puter assembly contained within a single chip. The various elements of the ICC
`(i.e., the central processing unit, the various types of memory, and the other
`components) are quite comparable to those components as housed for general(cid:173)
`purpose computer systems. The ICC manufacturers for smart cards are general
`silicon vendors who also design and manufacture components for more general(cid:173)
`purpose computer systems. Some of the well-known ICC manufacturers are:
`
`• Infineon (www.infineon.com)
`• ST Microelectronics (www.stm.com)
`• Atmel (www.atmel.com)
`• Philips Semiconductors (www.philips.com)
`• Fujitsu (www.fujitsu.com)
`• Hitachi (www.hitachi.com)
`
`The relationship among card issuers, ICC manufacturers, and smart card
`manufacturers is complex. Each has evolved a degree of control in developing
`and deploying smart card systems; in many instances, these entities are comple(cid:173)
`mentary while in some areas they appear competitive.
`
`IPR2022-01239
`Apple EX1018 Page 171
`
`

`

`fhCActors
`
`321
`
`The product delivered by the ICC manufacturer is typically a smart card chip
`delivered in one of two forms: either as a wafer with many ICCs on it or as a
`module comprised of a single ICC and its associated contact faceplate. Smart
`card manufacturers can typically work with either variant.
`
`The Smart Card Manufacturer
`
`The smart card manufacturer, as the name implies, is the entity that builds the
`smart card. The manufacturer typically develops the base operating system soft(cid:173)
`ware for the card and perhaps the application-level software as well. The card
`manufacturer creates the card body from raw PVC and installs the ICC into it.
`The manufacturer will typically be responsible for card printing and system per(cid:173)
`sonalization (or the ICC), although these functions are sometimes assumed by
`the issuer or perhaps even a service bureau function. We' 11 look at the manufac(cid:173)
`turing process for a smart card a little later in this chapter.
`Some of the prevalent smart card manufacturers are:
`
`• Gemplus (www.gemplus.com)
`• SchlumbergerSema ( www.schlumbergersema.com)
`• Giesicke & Devrient (www.gdm.de)
`• Oberthur (www.oberthur.com)
`
`These companies provide a significant fraction of the smart cards produced in
`the world today.
`
`The Application Developer
`
`The application developer in today's system environment is part developer and
`part integrator. Many components of the overall application are built as standard
`modules, ready to be specialized for inclusion into a specific application system.
`In today's marketplace, application developers are generally recruited by the
`card issuers or they are in the (speculative) business of building systems and
`recruiting card issuers to deploy them. What does not exist today is a significant
`population of application developers who can develop a product to sell into
`deployed systems. Thus, smart card systems are not yet like PC systems where
`applications can be independently marketed. It is, in fact, one small goal of this
`book to help facilitate such developers.
`
`The POS Manufacturer
`
`In the world of financial applications, a very significant role is played by the
`developer of the point-of-sale terminal. While smart cards provide a significant
`security environment for the component of the system that resides with the card-
`
`IPR2022-01239
`Apple EX1018 Page 172
`
`

`

`322
`
`~~---C_b
`
`
`
`__ a,._t_e_r_l_O_• Smart Card System Management
`
`holder, a standard personal computer that might be found in the office or store of
`a vendor does not provide an equivalent security level. This is the realm of the
`POS terminal. These terminals can contain most or all of the off-card applica(cid:173)
`tion necessary to interact with the cardholder's smart card.
`The POS often contains a smart card in its own right. This security authenti(cid:173)
`cation module (SAM) will be contained within a POS and it serves (at least) two
`purposes: to authenticate the identity of the POS and to contain a purse on
`behalf of the POS owner/vendor to record transactions and their values.
`POS manufacturers have a variety of associations, but one of the more active
`at the moment is the STIP group, which we discussed in Chapter 7.
`
`The Cardholder
`
`A smart card can represent the cardholder in an electronic environment. Further,
`the card can be programmed to require some type of identity authentication
`from the cardholder before it will provide such electronic representation for the
`cardholder. That is, the smart card can use a variety of mechanisms in a transac(cid:173)
`tion with the cardholder through which the cardholder convinces the card that it
`should act on the cardholder's behalf. Some of the mechanisms used by the card
`to authenticate the identity of the bearer include requiring
`
`• the bearer to enter a personal identification number (PIN)
`• the bearer to enter some known personal information stored on the card
`• some biometrical characteristic of the bearer, such as a fingerprint or a
`facial image, to be measured by a sensor or collection of sensors and then
`matched against a benchmark of this characteristic stored on the card
`• the bearer to properly perform a series of operations leading to a
`specific state known to the card
`
`The identity authentication transaction that occurs between the card and the
`cardholder is a rather complete, specific example of the transaction that one
`wants to occur generally through the enabling actions of the carq. That is, both
`sides of the transaction (i.e., the card and the cardholder) must be concerned with
`
`• authenticating the identity of the other (party to the transaction)
`• being authorized with the appropriate privileges once identity is
`authenticated
`• being assured of the integrity of the transaction
`• being assured of the privacy of the transaction
`• being able to confirm that the transaction took place in a proper fashion
`
`IPR2022-01239
`Apple EX1018 Page 173
`
`

`

`'fhc Infrastructure
`
`323
`
`THE INFRASTRUCTURE
`We've examined the main actors in a large-scale smart card system. Now let's look
`at the infrastructure of the system itself. The infrastructure for smart card-based
`systems is, today, probably best represented by the Internet. That is, the infrastruc(cid:173)
`ture is comprised of many platforms and their network connections through which
`specific elements of smart card-based systems can be interconnected.
`Essentially none of the platforms and none of the communication channels
`used in a widespread smart card application can be assumed to be secure in and
`of themselves. Consequently, the smart card (as a security platform itself) must
`be vigilant as to what other entities it is tallcing to. The designers and developers
`of systems have to guard against nonsecure elements of the infrastructure from
`being able to authenticate an identity to which the smart card will free to talk.
`
`The Card
`
`Smart cards use a computer platform on which information can be stored such
`that access to it can be strictly controlled by the cardholder, the card issuer, or
`the provider of any specific applications on the card. Further, software can be
`executed on the card under strict control of either the cardholder, the card issuer,
`or the provider of specific applications on the card. Given these characteristics,
`the smart card provides a variety of useful security characteristics, including
`
`• storage of passwords for access to computer systems, networks,
`information stores, and so forth
`• storage of keys, public and private, for authenticating identity
`• storage of keys, public and private, for encrypting information to
`ensure its privacy
`• storage of information to be conveyed to various access points for a
`system (e.g., a financial system) without the cardholder being able to
`access or change that information in any way
`• performance of encryption algorithms for authenticating identity
`• performance of encryption algorithms for ensuring the privacy of
`information
`
`The InterFace Device
`
`The access point of any smart card with any electronic system is typically
`referred to in the ISO specifications as an lnterFace Device (!FD); most of the
`time, the terms terminal, smart card reader or smart card intetface device are
`used. Terminals can vary significantly in complexity and capability and, hence,
`in the level of security that they support. At the most capable level, a terminal is
`a secure computing platform on a par with the smart card itself, although typi-
`
`IPR2022-01239
`Apple EX1018 Page 174
`
`

`

`

`

`

`

`

`

`►
`
`The card System
`
`.L
`
`327
`
`THE CARD SYSTEM
`We've had an overview of the actors and the infrastructure for a large scale
`smart card system; now let's look at some aspects of the convergent systems that
`were introduced in Figure 10.1. From its design inception to its widespread
`deployment, a smart card typically goes through a rather consistent life cycle.
`This life cycle may vary a bit from card manufacturer to card manufacturer and
`from application system to application system, but for the most part, it goes
`through a consistent series of phases.
`
`Life Cycle
`
`A smart card typically involves two distinct development phases:
`
`• development of the smart card operating system and application
`software
`• manufacturing of the smart cards
`
`In Figure 10.1, these two phases are illustrated in the two top rows of tasks
`shown. Consider first the development of software for the card. Throughout the
`course of this book we've examined a variety of approaches for providing soft(cid:173)
`ware, both systems and applications on a smart card. We'll do a succinct review
`in the following section. Then, we will consider the manufacturing, deployment,
`and operation of a smart card system.
`
`Smart Card Operating System Software Development
`
`Applications that make use of smart cards typically comprise software that runs
`on an off-card computer (a PC or PC-class computer), on the smart card itself,
`and perhaps even on other computers widely distributed within a local area or
`wide area network. Software to run on the card itself (i.e., within the ICC embed(cid:173)
`ded in the card), comes in a spectrum of flavors as illustrated in Figure 10.2.
`Hard-mask software is developed in advance of the manufacture of the ICC,
`which is embedded in a smart card plastic body. The hard-mask software is pro(cid:173)
`vided to the chip manufacturer and it is created as a bit pattern in the read-only
`memory (ROM) of the ICC. Hard-mask software comprises the base operating
`system of the smart card. Historically, all of the application and operating system
`software of the card was built into ROM. As an evolutionary measure, however,
`some of the base operating system and application software came to be stored in
`electrically erasable and programmable read-only memory (EEPROM).
`
`IPR2022-01239
`Apple EX1018 Page 178
`
`

`

`

`

`

`

`I I
`
`~.\/
`Y
`
`330
`
`-~--------
`
`Cha ter 10 • Smart Card System Management
`
`mands) to the Cyberflex Access card is through Java Card applets, which are
`loaded onto the card either as part of the prepersonalization phase of manufac(cid:173)
`turing or after the card has been issued to the cardholder.
`All of these various mechanisms for adding software to a card have their own
`sets of benefits and liabilities. Each requires a specialized software development
`environment as well. Included in most of these environments are various types
`of specialized equipment or software support infrastructures.
`
`Chip Simulators
`
`For (hard-mask) software loaded onto the chip during the manufacturing pro-
`cess, the process for writing and then checking the software (debugging) can be
`very long and involved. In particular, supporting a debugging environment in
`which checkpoints can be set with code and a dynamjc debugger used to isolate
`errors is difficult to provide on an isolated ICC meant for a smart card. In order
`to mitigate this difficult situation somewhat, most chip manufacturers provide
`software simulators for their chips. This allows the software developer to create
`a full complement of software for a chip and check it out via the simulator prior
`to actually fabricating a set of chips with the software included.
`While a chip simulator improves the software development process, it still
`leaves many aspects of the software unchecked. For example, it is very difficult
`to check the timing of various operations through a simulator. As seen in Chap(cid:173)
`ter 3, many aspects of the communication between the off-card and the on-card
`application are critically depending on the timing of various transactions
`between the reader and the card. These aspects of the software's execution can
`usually not be tested with the simulators provided for most chips. Instead, devel(cid:173)
`opment tools called chip emulators are available that allow the actual ICC hard(cid:173)
`ware to be used, but augmented by external memory and other debugging aids.
`
`Chip Emulators
`
`To improve the testing environment, but without requiring the actual fabrication
`of chips with embedded application software, most chip manufacturers provide
`hardware emulators for their chips. With an emulator, a variant of memory is
`provided that can be accessed both by a computer being used for the software
`development environment and by the processor of a chip of the form to be
`deployed on the smart card. This emulator allows the software developer to
`write code and load it into this sharable memory. The code, thus loaded, can
`then be executed by the processor in the emulator. In this way, the code is being
`
`IPR2022-01239
`Apple EX1018 Page 181
`
`

`

`

`

`

`

`

`

`334
`
`Cha ter 10 • Smart Card System Management
`
`also usually entails writing a PIN on the card that the cardholder can then
`use to confirm his or her identity to the card. The personalization
`procedure usually involves physical manipulation of the card as well (i.e.,
`pictures, names, and address information often are printed on the card). In
`addition, some information, such as account numbers, may be embossed
`on the card to allow physical transference of that information onto other
`media (e.g., printing a paper receipt of a credit card transaction).
`Card personalization is typically the last step in preparing the card before it
`is issued to the cardholder and put into the cardholder's possession. This
`final personalization step may involve physical preparation of the card's
`body and/or preparation of information stored in the ICC of the card. This
`final personalization step has at least two distinct purposes, both of which
`help define the physical requirements on the personalization operation itself.
`First, the card will likely contain information through which the card can
`authenticate its identity to the (one or more) application system(s) in
`which it may operate and keys through which the cardholder can authenti(cid:173)
`cate his or her identity to the card. This information must be prepared and
`loaded into the card in a secure fashion, which generally means in a secure
`environment as well as through secure procedures. Second, the card must
`be placed directly into the possession of the cardholder and then activated
`for use by the cardholder.
`7. Printing of the card. The printing of graphics and text on a smart card is an
`extremely important feature. The appearance of the card generally reflects
`both aesthetically and financially on the issuer of the card. Branding
`information, such as corporate symbols and logos, builds name recognition
`for the issuer and has significant advertising value. When a card is used as a
`personal identification card, a person's picture, along with name and address
`information, often is printed on the card. For many cards supporting financial
`transactions, issuers often are concerned with the threat of counterfeiting of
`their cards and will sometimes make use of anti-counterfeiting mechanisms
`such as holograms printed on the face of the card as a safeguard, much as is
`found in thwarting the counterfeiting of currency (Figure 10.5).
`Depending on the information to be placed on a card, a variety of printing
`processes can be utilized. For cards that will have exactly the same graph(cid:173)
`ics on every card (e.g., telephone cards, transit tokens, and the like), the
`printing step is often done prior to the insertion of the ICC in the card. In
`this case, the cards are formed from large plastic sheets. The printing is
`done on the sheet, prior to cutting the individual cards from the sheet. Fol(cid:173)
`lowing the printing operation, the individual cards are stamped from the
`sheet and their edges are smoothed to conform to ISO specifications,
`which are examined in a bit more detail in Chapter 3.
`8. Card aclivalion-initialization of the program and program information
`on !he chip in the card. Distinct from prepersonalization activities, these
`
`IPR2022-01239
`Apple EX1018 Page 185
`
`

`

`

`

`

`

`

`

`

`

`Characteristics to be Managed
`
`339
`
`Table 10.1 State Transition
`
`for a Card (Continued)
`
`Old State
`
`New State Transition Criteria
`
`In Use
`
`Successful entry of Unblock PIN
`
`Retired
`
`No more Unblock PIN entries possible
`
`Retired
`
`Passage of expiration date
`
`Blocked
`
`Blocked
`
`InU e
`
`Keys
`
`it is possible to
`Through the use of public key cryptography mechanisms,
`address the concepts of authentication and integrity in a highly dispersed secu(cid:173)
`rity infrastructure. In fact, many of the same techniques can be used to address
`authorization and privacy as well, and those points are discussed in Chapter 4.
`
`In smart card-based systems, keys are used to establish identities. As we've
`seen in a number of cases, we typically need to establish the identities of com(cid:173)
`puters talking to computers, people talking to computers, and people talking
`(communicating with) other people. The establishing of keys through which we
`can authenticate identities is one of the most critical, security-related tasks in
`preparing and issuing smart cards.
`
`Both private key and public key cryptography can be used to establish iden(cid:173)
`tity. In the security commands of the two smart cards we examined in Chapter 6,
`we noted that we can use either cryptographic system with the same set of com(cid:173)
`mands. The real difference between the systems comes from their respective dif(cid:173)
`ficulties in preparing and distributing the keys.
`
`If we have a large number of smart cards in a system and a large number of
`terminals that provide the computer
`interfaces into which smart cards are
`inserted, we can either have a large number of unique keys establishing the vari(cid:173)
`ous identities or we can have a few keys to essentially identify the boundary of
`the system (i.e., we can identify participants in the system). If we use a lot of
`unique keys, then we have a difficult key distribution problem in creating all
`those keys in the first place, associating them with various identities, and then
`distributing them to the platforms encompassed by those identities.
`
`If we make use of a small number of keys and use them to establish participa(cid:173)
`tion in the system, then we increase the risk to the entire system if a key is com(cid:173)
`promised in any way. Given the philosophy we're to use for key management, we
`then have the problem of generating the keys, confirming that they're "good" keys,
`and distributing them to the relevant platforms. That said, let's now define the life(cid:173)
`cycle states of the keys to be used in our sy·stem; this is done in Figure 10.10.
`
`IPR2022-01239
`Apple EX1018 Page 190
`
`

`

`

`

`

`

`

`

`

`

`344
`
`~---~----------
`
`Cha ter 10 • Smart Card System Management
`
`The transition criteria for transaction state changes are listed in Table 10.4.
`
`Table 10.4 Tran action State Transactions
`
`Old State New State
`
`Transition Criteria
`
`Initiated
`
`Submitted
`
`Submitted
`
`Rejected
`
`Rejected
`
`Submitted
`
`Submitted Accepted
`
`Rejected
`
`Abandoned
`
`Accepted
`
`Committed
`
`Transaction has been
`fonnatted and sent to
`transaction processing center
`
`Rejection message received
`back from transaction
`processing center
`
`Corrective action taken on
`rejected transaction and it is
`resent to transaction
`proces ing center
`
`Acceptance message received
`back from transaction
`processing center
`
`Data contained in transaction
`declared to be invalid and log
`entry is made
`
`All data used to build
`transaction is updated to
`reflect transaction
`
`It is worth noting that many transactions that smart cards are involved with
`occur in terminals or back-end processing systems. In the e instances, the termi(cid:173)
`nal or back-end systems can archive the transaction proce
`ing and make it
`available to the card management system, or actually be part of the card man(cid:173)
`agement system. In some instances, however, the card itself can log the transac(cid:173)
`tions that it takes part in. In the e cases, it is intere ting to consider how to feed
`these tran action logs (stored on many smart card ) back into a card manage(cid:173)
`ment system.
`
`IPR2022-01239
`Apple EX1018 Page 195
`
`

`

`

`

`346
`
`_,_._ ____ _._ __ C __ h_a __ t_er_l_O_• Smart Card System Management
`
`Card Printing
`Services
`
`Photograph
`&
`Biometric Data
`Capture
`
`-
`-
`~ .. -
`
`Certificate
`Authority
`
`Directory
`Services
`
`Personal Data
`Capture
`
`Application
`Personalization
`
`Key
`Management
`
`Application
`Management
`
`Card Management System
`Card Issuing System
`Figure 10.13 Components of a card management system.
`
`relatively small numbers of individuals, but its applicability for handling very
`large numbers of individuals is still being explored.
`Large-scale trust models are currently rooted in the concept of a CA or
`even hierarchies of CAs (i.e., organizational entities known as CAs perform
`the service of validating identity information, associating that information
`with a specific entity [person or organization], and associating all this with a
`public key). This attestation is provided in the form of a document (a certifi(cid:173)
`cate) that is digitally signed by the CA. The intent is that the CA forms a
`trusted third party to all two-way transactions. If two different parties can
`each trust the CA, then they can trust the information received from the CA
`(certificates) and, hence, can trust each other if each has received a certificate
`from the CA.
`
`Registration Authorities
`
`Issuing a signed digital certificate requires a two-stage operation. As we've
`seen, the purpose of the certificate is to tie together physical identity (of a per(cid:173)
`son) with a private key, which can be used to authenticate their identity or to
`project their identity over a distant network. The act of ensuring that the physi(cid:173)
`cal information actually corresponds to the identity in question becomes a task
`for a registration authority (RA). Once the RA approves the is uance of a certif(cid:173)
`icate, it can then be signed by a certifying authority.
`
`IPR2022-01239
`Apple EX1018 Page 197
`
`

`

`

`

`348
`
`;:.___ _____ ~ .......
`
`---~
`Cha ter 10 • Smart Card System Management
`
`escrowing of keys such that, with proper authorization, keys can be retrieved in
`order to acce s secret (encrypted) information.
`The key management system must be involved with the initial preparation of
`cards as well as their ongoing use.
`
`Directory Services
`
`In a network infrastructure supporting the use of smart cards within a PKI, a
`general directory service is a useful backup mechanism to the card itself. That
`is, information from digital certificates and, in fact, the certificates themselves,
`can be stored on a directory server accessible by applications in a wide area net(cid:173)
`work. Such directory servers are typically built along the lines of X.500 servers.
`These servers can be accessed from various applications through the lightweight
`directory access protocol or LDAP mechanism. Such directory services are
`often referred to as LDAP services.
`Real-Time Confirmation. As indicated previously, signed digital certifi(cid:173)
`cates are an effective way to build a chain of trust from a central authentication
`authority to widely distributed access points. The signature on the certificate is
`easily authenticated and subsequently provides an excellent mechanism through
`which a trusted environment can be extended from a trusted third party to other
`participants in transactions around the network.
`A digital certificate typically contains a time interval during which it is
`valid. If a certificate is presented during the period when it is indicated to be
`valid, then a receiving entity should be able to trust the authentication infor(cid:173)
`mation presented in the certificate. The certificate allows use of the authenti(cid:173)
`cation (and other) information from the certificate in off-line as well as online
`transactions. An off-line transaction is one in which there is no real-time
`communication link extending beyond the systems directly involved in the
`transaction. This is an arena of significant opportunity for smart card-based
`transactions.
`In some cases, however, a real-time check on the authenticity of a certifi(cid:173)
`cate is required. In this case, a database of invalidated certificates can be
`maintained.
`Certificate Revocation Lists. A certificate revocation list (CRL) is such a
`list of invalidated certificates. To be used in confirming the authenticity of
`certificates during a transaction, the list mu t be continuously available
`online and its address must be known and authenticated in its own right. The
`contents of such a CRL are essentially a digital certificate. It is is ued by the
`
`IPR2022-01239
`Apple EX1018 Page 199
`
`

`

`nts of a Card Management System
`Eteme
`
`349
`
`card management system in response to some action that serves to invalidate
`the certificate.
`
`During the course of a transaction, when a certificate is obtained from a
`card, if a general network connection is available, it is a straightforward oper(cid:173)
`ation to access a CRL to confirm that the certificate is still valid. Should the
`certificate be found to have been revoked, it is useful if a command can be
`issued to the card to lock it and prevent it from being used for further services.
`If possible, cards should be physically confiscated at this point; but if not,
`locking the card will at least prevent its being used again. Further, it is possi(cid:173)
`ble to report the locking operation to the card management system to indicate
`that a card has been deactivated and to prevent the card from being presented
`for reactivation.
`
`Application Management
`
`The application management component is concerned with the applications
`found on cards or the applications
`that cards participate
`in. This is where
`transaction archiving and/or monitoring would come into play. The element of
`the management system would need to keep track of all the applications in the
`system, who can use them, who has used them, what has been done with them,
`and the current state of their being. Obviously there is a lot of latitude for such
`a component.
`
`Locked Cards. A typical approach through which smart card systems are
`programmed to react in the event of a detected attack on the smart card itself is
`by locking down the card and not allowing it to communicate with the outside
`world in other than a highly restricted way. For example, if a PIN code is used to
`authenticate the identity of the cardholder to the card, and if a PIN is incorrectly
`entered several times, a card is often programmed to go mute as a response to
`this perceived attack. When this happens, the only thing the card will respond to
`is a command sequence
`from the off-card