(12) United States Patent
`Lee et al.
`
`USOO6367011B1
`(10) Patent No.:
`US 6,367,011 B1
`(45) Date of Patent:
`Apr. 2, 2002
`
`(54) PERSONALIZATION OF SMART CARDS
`(75) Inventors: Alson Lee, Inverness, IL (US); Mary
`L. Gorden, San Rafael, CA (US)
`
`(73) Assignee: Visa International Service
`Association, Foster City, CA (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days
`
`(*) Notice:
`
`a --
`
`7/1996
`12/1984
`8/1988
`4/1990
`8/1995
`10/1997
`3/1999
`
`O723251
`EP
`2575566
`FR
`2638002
`FR
`2638002
`FR
`952810
`WO
`9739424
`WO
`99.10848
`WO
`* cited by examiner
`Primary Examiner-Thomas R. PeSSO
`(74) Attorney, Agent, or Firm-Beyer Weaver & Thomas,
`
`LLP
`
`ABSTRACT
`(57)
`(21) Appl. No.: 09/172,722
`Smart card personalization includes a personalization prepa
`(22) Filed:
`Oct. 13, 1998
`ration process prior to the personalization Session at the
`personalization bureau. The personalization preparation pro
`Related U.S. Application Data
`ceSS derives the derived card keys for a single or for multiple
`(60) Provisional application No. 60/061,918, filed on Oct. 14,
`applications. The preparation process also generates issuer
`1997.
`and card public key pairs and certificates. Master keys are
`(51) Int. Cl. .................................................. G04L 9/00
`used in conjunction with the personalization preparation
`(52) U.S. Cl. ....................... 713,172. 712/165. 712/168;
`process rather than utilizing the master keys during the
`380/255
`remainder of the personalization process at the personaliza
`(58) Field of Search
`713/172, 164
`tion bureau. Because the personalization preparation process
`713/165, 168, 200, 201; 380/255, 33, 283
`does not require highly Specialized, expensive machinery, it
`is Straightforward for an issuer to derive the card keys at the
`References Cited
`issuer's location. Once the personalization preparation pro
`ceSS is complete, the derived card keys are Stored in an
`U.S. PATENT DOCUMENTS
`4,549,075 A 10/1985 Saada et al. .................. sos output file merged with other card personalization data. The
`531505 A * 5/1994 Bjerrum et al. ............... 380/25
`output file contains records of Secret and non-secret card
`5,473,690 A 12/1995 Grimonprez et al.
`data, each record corresponding to personalization informa
`5,534,857 A 7/1996 Laing et al.
`tion for a Single card to be personalized. The output file is
`5,557,679 A
`9/1996 Julin et al.
`Sent to the personalization bureau which process the file
`5,889,941 A 3/1999 Tushie et al.
`using Standard processing modules to personalize each Smart
`6,021,203 A
`2/2000 Douceur et al. .............. 380/49
`card. The preparation proceSS and the personalization pro
`FOREIGN PATENT DOCUMENTS
`ceSS may be performed at the same location or at different
`locations.
`
`(56)
`
`DE
`DE
`
`3927270
`3927270
`
`8/1989
`2/1991
`
`28 Claims, 5 Drawing Sheets
`
`
`
`
`
`54
`
`PREPARAION
`PROCESSING
`DEVICE
`
`
`
`HARDWARE
`SECURY
`MODUE
`
`OUTPU
`FILE
`
`170
`
`CARD
`SUPPLIER
`
`172
`
`PERSONAZATION
`DEVICE
`
`150
`N.
`
`\
`\
`
`180
`Y
`
`HARDWARE
`SECURITY
`MODULE
`
`152
`
`EE
`
`Personalized Cards
`
`SSUERLOCATION
`
`PERSONALZAION LOCATION
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 15
`
`

`

`U.S. Patent
`
`Apr. 2, 2002
`
`Sheet 1 of 5
`
`US 6,367,011 B1
`
`ZZ ).
`
`09 ].
`
`
`
`HH
`
`
`
`EITT GJOW A LIHT|0ES
`
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 15
`
`

`

`U.S. Patent
`
`Apr. 2, 2002
`
`Sheet 2 of 5
`
`US 6,367,011 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Begin
`Preparation
`Process
`
`Supply Card
`Personalization
`Data
`
`300
`
`Retrieve List of
`Applications to Process
`
`
`
`301
`
`302
`
`or Current Applicatio
`in Current Record
`
`304
`-Ns ls
`
`-( their Derivation Data
`in Record
`
`
`
`NO
`
`YES
`
`Retrieve Derivation
`Data
`
`306
`
`Derive Keys
`(FIGS. 3 or 4)
`
`Place Derived
`Keys & Derivation
`Data into Record
`
`308
`
`31 O
`
`312
`
`there another
`Application
`
`
`
`
`
`Write Current
`Record to Output
`File
`
`
`
`Retrieve Derivation
`Data
`
`318
`
`Derive Keys
`(FIGS. 3 or 4)
`
`Merge Derived Keys &
`Derivation Data with input
`Data in Record
`
`32O
`
`--O End
`
`FIG. 2
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 15
`
`

`

`U.S. Patent
`
`Apr. 2, 2002
`
`Sheet 3 of 5
`
`US 6,367,011 B1
`
`Begin Step 308 or 318
`
`Begin Step 308 or 318
`
`ldentify Master Key
`
`ldentify Derivation Data
`
`402
`
`404
`
`Generate issuer Key
`Pair
`
`500
`
`Generate SSuer
`Certificate
`
`501
`
`
`
`
`
`
`
`
`
`
`
`Encrypt Derivation Data With
`Master Key to Produce Card
`Derived Key
`
`406
`
`Generate Card Key
`Pair
`
`5O2
`
`
`
`
`
`
`
`Generate Card
`Certificate
`
`
`
`504
`
`Assemble Car
`Key issuer Certificate,
`and Card Certificiate
`
`
`
`506
`
`O End
`
`FIG. 4
`
`End
`
`FIG. 3
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 15
`
`

`

`U.S. Patent
`
`Apr. 2, 2002
`
`Sheet 4 of 5
`
`US 6,367,011 B1
`
`
`
`
`
`
`
`Card 1 Record
`
`Card 2 Record
`
`Card 3 Record
`
`602
`
`604
`
`606
`
`608
`
`
`
`F.G. 5A
`-- 160
`
`610 612
`2
`MC Data
`1 Length
`
`614
`
`
`
`616 618
`
`620
`
`622
`
`Data for MC 1
`
`Data for MC 2
`
`-- 602
`
`Card 1 input Record
`
`FIG. 5B
`
`630 632, 634
`
`636
`
`64
`O
`
`642 644
`
`646
`
`650
`
`Appl. Data KEK Application 1
`ld. Length id.
`1
`
`
`
`Appl.
`KEK Applic
`ation 2
`Data
`ld. Length
`Data
`ld.
`2
`
`Data for MIC 2 (Chip Data)
`
`F.G. 5C
`
`670
`
`672
`
`674
`
`680
`
`682
`
`
`
`684
`
`to or VALUE to or VALUE
`
`O. O. O.
`
`-- 636
`
`Application 1 Data
`
`FIG. 5D
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 15
`
`

`

`U.S. Patent
`
`Apr. 2, 2002
`
`Sheet 5 of 5
`
`US 6,367,011 B1
`
`900
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NetWork
`Connection
`
`
`
`912
`
`-90
`
`interface
`
`Primary
`Storage
`
`Primary
`Storage
`
`
`
`Processor(s)
`
`FIG. 6
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 15
`
`

`

`US 6,367,011 B1
`
`1
`PERSONALIZATION OF SMART CARDS
`
`This application claims priority of U.S. provisional appli
`cation No. 60/061,918, filed Oct. 14, 1997, which is incor
`porated herein by reference.
`FIELD OF THE INVENTION
`The present invention relates generally to Smart cards.
`More Specifically, the present invention relates to a System
`and method for personalization of Smart cards having mul
`tiple applications.
`
`2
`other while the terminal only needs to hold a small number
`of master keys to communicate with a large number of cards
`in a System.
`There can be a potential problem with security when
`using this conventional method of personalization and
`derived keys. Since all card keys are typically derived at the
`time of personalization, all of the master keys are required
`at the personalization device within the personalization
`bureau. A Security issue can arise when the master keys are
`placed within a third party's control, Such as at the perSon
`alization bureau. Every additional party who has access to
`the master keys is a potential breach of Security.
`Another common problem with conventional personal
`ization is that the personalization proceSS can take a Sub
`Stantial amount of time. In addition to the cost of contracting
`with third parties to perform the personalization process, the
`time needed to perform the personalization process adds an
`additional amount to the total cost of personalization. This
`results in higher priced cards and Systems.
`In fact, a major challenge in the implementation of
`encryption technology (and especially public key
`technology) in chip cards is in how to achieve significant
`throughput in the personalization process. It is interesting to
`note that because personalization is seen as a bottleneck in
`the overall process, Special and costly personalization
`machines are used that are able to personalize multiple cards
`at once. With banks having a requirement to issue millions
`of cards per year, it is imperative that the proceSS be fully
`optimized. For example, as mentioned briefly above, certain
`chip card applications require not only a card Secret key (for
`example, the Secret key of a card public key pair), but also
`public key certificates and derived keys that are placed onto
`the card. Creating Such card keys and public key certificates
`at the point of personalization could Severely degrade
`throughput. For example, a Stored value application may
`require that a Smart card be loaded with a card Secret key, a
`card certificate, an issuer certificate, at least three DES keys
`and other card data. Creating card key pairs at the point of
`personalization would inhibit throughput.
`Furthermore, it is conceivable that one Smart card may
`contain multiple applications. Each application is likely to
`require its own Set of keys, data and algorithms. Personal
`ization throughput would be dramatically affected should
`each Smart card have to be run through a separate perSon
`alization proceSS for each application that it contains.
`Requiring each card to be personalized multiple times is not
`cost effective.
`It would therefore be desirable to provide a system and
`method for personalizing a Smart card Such that the issuer's
`master keys and other Secret information can remain Secure.
`It would also be desirable to provide a system and method
`for personalizing a card Such that the time required for the
`personalization process at the personalization bureau is
`decreased. It would be further desirable to efficiently per
`Sonalize Smart cards that may have multiple applications
`Stored thereon. The present invention addresses Such needs.
`SUMMARY OF THE INVENTION
`To achieve the foregoing, and in accordance with the
`purpose of the present invention, a preparation proceSS is
`disclosed that Speeds up the personalization process for
`Smart cards. The proceSS may be used to personalize Single
`or multiple application Smart cards. Derived card keys,
`public key pairs (if any) and public key certificates (if any)
`are generated in advance. The preparation process creates an
`output file by merging the generated Secret data with card
`
`BACKGROUND OF THE INVENTION
`Before a Smart card is issued to a cardholder, the card goes
`through an initialization and a personalization process. Dur
`ing the initialization process, a manufacturer or other card
`Supplier embeds an integrated circuit chip into the plastic
`card body. The chip is loaded with at least one application
`program, Such as a credit or a Stored value application. In
`addition, a file structure may be initialized with default
`values, and initial cryptographic keys may be Stored for
`transport Security. After a card is initialized, it is then
`typically personalized. During personalization, the Smart
`card is generally loaded with data that uniquely identifies the
`card, and with data that allows the card to be used in a
`payment System, for example. Personalization data may
`include file information, application information, a maxi
`mum value for an application or of the card and a personal
`identification number (PIN) or other cardholder information.
`Also included may be the currency in which the card or
`application is valid, the expiration date of the card or
`application, and a variety of cryptographic keys and algo
`rithm information for the card or applications on the card.
`For certain applications, cryptographic information to be
`loaded during personalization can include not only a Secret
`card key and derived keys, but also public key certificates.
`Card life cycle is described in Financial transaction cards
`Security architecture of financial transaction Systems using
`integrated circuit cards, Part 1. Card life cycle, Interna
`tional Organization for Standardization, ISO 10202-1, 1991,
`which is incorporated by reference.
`Conventionally, the Smart card is personalized at a per
`Sonalization bureau, often a third party contracted by a Smart
`card issuer to personalize their Smart cards. The personal
`ization bureau may be in a separate physical location from
`the location of the Smart card issuer or from the location of
`the entity that performs Smart card initialization. During
`personalization, a personalization device located at the per
`Sonalization bureau is coupled to a Security module. The
`personalization device generally provides data which, when
`installed on a card, gives the card the ability to run appli
`cation programs.
`During personalization, cryptographic keys (Such as
`derived card keys) are stored in a memory of the initialized
`card. These keys are used for a variety of cryptographic
`purposes. Derived card keys are derived from master keys
`Stored in the Security module (of the personalization bureau)
`using derivation data unique to each card. The derivation
`data is encrypted with a Suitable algorithm using a master
`key to produce a derived card key for a particular card. The
`use of the master key to produce derived card keys obviates
`the need to have a unique key for every card in the System
`Stored in terminals where applications are used. Instead, the
`master key can be used with derivation data from the card to
`independently regenerate the derived card key. This allows
`a terminal and a card to Securely communicate with each
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 15
`
`

`

`US 6,367,011 B1
`
`3
`data from other issuer cardholder Systems. Advantageously,
`chip card data is interspersed with other personalization data
`in a flexible format in the output file. The file is input to the
`personalization process. Advantageously, the entity per
`forming personalization may then use the output file to
`personalize all applications on a Smart card in one process.
`An embodiment of the present invention speeds up the
`personalization process performed at the personalization
`bureau by deriving any needed derived card keys prior to the
`time of personalization at the bureau. Additionally, the
`present invention provides greater overall Security by allow
`ing the issuer to maintain the master keys (or other Secret
`information) at the issuer's location without the need to give
`the master keys to a personalization bureau or other third
`party. The present invention is applicable to a wide variety
`of Secret information that an issuer may not wish to divulge
`to outside parties. By using the Secret information at the
`issuer location to help produce the output file, the Secret
`information need not be divulged to a third party Such as a
`personalizer.
`This embodiment of the present invention provides a
`modified personalization process, which includes a prepa
`ration proceSS accomplished after initialization, but prior to
`the Standard personalization Session (typically, but not
`necessarily, occurring at a personalization bureau). The
`preparation proceSS will generally be carried out at the issuer
`location, but may be carried out at any location trusted by the
`issuer. Furthermore, it is contemplated that the preparation
`proceSS and the personalization Session may be performed at
`the same location. Among other tasks, the preparation pro
`ceSS is used to derive the derived card keys for one or more
`applications to be installed on a card. In this manner, an
`issuer's master keys are used during the preparation proceSS
`rather than during the remainder of the Standard personal
`ization Session at a personalization bureau. Since the prepa
`ration proceSS does not require highly specialized, expensive
`machinery (Such as the personalization device) it is rela
`tively simple for an issuer to derive the card keys at the
`issuer's location. Once the preparation proceSS is complete,
`the derived card keys may be Stored in a file, which can later
`be sent to the personalization bureau for the remainder of the
`personalization process.
`According to a further embodiment of the present
`invention, applications in addition to those applications that
`need derived card keys can also be included in the file to be
`Sent to the personalization bureau. An example of an appli
`cation that may not need derived card keys is a loyalty
`application. Loyalty applications are used to keep track of
`purchases by a cardholder for the purpose of rewarding the
`cardholder for being a particularly loyal customer. Embodi
`ments of the invention allow data related to multiple appli
`cations to be combined in a single file, which can then be
`Sent to the personalization bureau or other entity responsible
`for personalizing the card. Advantageously, use of a Single
`file to personalize a Smart card having multiple applications
`is efficient and obviates the need for the card to be person
`alized once for each application.
`One embodiment of the present invention for personaliz
`ing a Smart card includes performing a first portion of a
`personalization process at a first location (e.g., at a card
`issuer), including an output of the first portion of the
`personalization proceSS in an output file, and Sending the
`output file to a Second location. The Second portion of the
`personalization proceSS may then be performed at the Second
`location (e.g., at a personalization bureau).
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a System for personalization
`of a Smart card according to one embodiment of the present
`invention.
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`FIG. 2 is a flowchart of one method for performing a
`preparation process to produce an output file at a preparation
`processing device.
`FIG. 3 is a flowchart describing one method for deriving
`keys using Symmetric cryptography.
`FIG. 4 is a flowchart describing another method for
`deriving keys using asymmetric cryptography.
`FIGS. 5A-5D illustrate one possible embodiment of a
`format for an output file.
`FIG. 6 is a block diagram of a typical computer System
`Suitable for implementing an embodiment of the present
`invention.
`
`DETAILED DESCRIPTION
`AS mentioned above, the life cycle of a Smart card begins
`with the manufacture of the chip, and its mounting into a
`card body by a card manufacturer or card Supplier. Once
`initialized, a batch of cards is shipped to a personalizing
`entity who performs personalization of the cards. Data is
`received from the card issuer for use in personalizing each
`card. Personalization of each card depends upon the appli
`cation for which the card is intended, but may include:
`addition of Secret keys, addition of application Specific data
`and parameters, embossing, addition of graphic images,
`addition of magnetic Stripe data, etc. The present invention
`is directed toward the interaction between the issuer and
`personalization entity, and addresses a need to Streamline the
`personalization process for high Volumes of cards, and
`especially when multiple applications are in use. By way of
`background, Smart cards are first discussed in general.
`
`Smart Cards
`The present invention is applicable to Smart cards. Also
`termed chip cards, integrated circuit cards, memory cards or
`processor cards, a Smart card is typically a credit card-sized
`plastic card that includes one or more Semiconductor inte
`grated circuits. A Smart card can interface with a point-of
`Sale terminal, an ATM, or with a card reader integrated with
`a computer, telephone, Vending machine, or a variety of
`other devices. The Smart card may be programmed with
`various types of functionality Such as a Stored-value
`application, a credit or debit application, a loyalty
`application, cardholder information, etc. Although a plastic
`card is currently the medium of choice for Smart cards, it is
`contemplated that a Smart card may also be implemented in
`a Smaller form factor, for example, it may attach to a key
`chain or be as Small as a chip module. A Smart card may also
`be implemented as part of a personal digital assistant,
`telephone, or take a different form. The below description
`provides an example of the possible elements of a Smart
`card, although the present invention is applicable to a wide
`range of types of Smart cards.
`A Smart card may include a microprocessor, random
`access memory (RAM), read-only memory (ROM), non
`volatile memory, an encryption module (or arithmetic unit),
`and a card reader (or terminal) interface. Other features may
`be present such as optical storage, flash EEPROM, FRAM,
`a clock, a random number generator, interrupt control,
`control logic, a charge pump, power connections, and inter
`face contacts that allow the card to communicate with the
`outside world. Of course, a Smart card may be implemented
`in many ways, and need not necessarily include a micro
`processor or other features.
`The microprocessor is any Suitable central processing unit
`for executing commands and controlling the device. RAM
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 15
`
`

`

`US 6,367,011 B1
`
`S
`Serves as temporary Storage for calculated results and as
`Stack memory. ROM Stores the operating System, fixed data,
`Standard routines, look up tables and other permanent infor
`mation. Non-volatile memory (such as EPROM or
`EEPROM) serves to store information that must not be lost
`when the card is disconnected from a power Source, but that
`must also be alterable to accommodate data Specific to
`individual cards or changes possible over the card lifetime.
`This information includes a card identification number, a
`personal identification number, authorization levels, cash
`balances, credit limits, and other information that may need
`to change over time. An encryption module is an optional
`hardware module used for performing a variety of encryp
`tion algorithms. Of course, encryption may also be per
`formed in Software. Applied Cryptography, Bruce Schneier,
`John Wiley & Sons, Inc., 1996 discusses suitable encryption
`algorithms and is hereby incorporated by reference.
`The card reader interface includes the Software and hard
`ware necessary for communication with the outside world.
`A wide variety of interfaces are possible. By way of
`example, the interface may provide a contact interface, a
`close-coupled interface, a remote-coupled interface, or a
`variety of other interfaces. With a contact interface, Signals
`from the integrated circuit are routed to a number of metal
`contacts on the outside of the card which come in physical
`contact with Similar contacts of a card reader device. A Smart
`card may include a traditional magnetic Stripe to provide
`compatibility with traditional card reader devices and
`applications, and may also provide a copy of the magnetic
`Stripe information within the integrated circuit itself for
`compatibility.
`Various mechanical and electrical characteristics of a
`Smart card and aspects of its interaction with a card reader
`device are described in Smart Card Handbook, W. Rankland
`W. Effing, John Wiley & Sons, Ltd., 1997, and are defined
`by the following Specifications, all of which are incorporated
`herein by reference: Visa Integrated Circuit Card
`Specification, EMV Integrated Circuit Card Specification for
`Payment Systems, EMV Integrated Circuit Card Terminal
`Specification for Payment Systems, EMV Integrated Circuit
`Card Application Specification for Payment Systems, Visa
`International Service Association 1996; and International
`Standard. Identification Cards Integrated Circuit(s) Cards
`with Contacts, Parts 1-6, International Standards Organiza
`tion 1987-1995.
`
`Smart Card Personalization
`FIG. 1 shows a block diagram of a system 100 for
`personalization of a Smart card according to an embodiment
`of the present invention. At the issuer location, hardware
`security module (HSM) 130 is coupled to a preparation
`processing device 154, which receives an input file 159. At
`the personalization location, a personalization device 150 is
`coupled to a hardware security module (HSM) 152. Output
`file 160 is transferred from the issuer location via transport
`mechanism 158 to be input to device 150. Card supplier 170
`is one of many well known card Suppliers that provides
`initialized Smart cards 172 to personalization device 150.
`Once personalized by device 150 using file 160, personal
`ized cards 180 are available for use by cardholders. It is
`possible for the issuer location and the personalization
`location to be the same location.
`Hardware security module (HSM) 130 is used to facilitate
`cryptographic processing. HSM 130 typically Stores Secret
`keys and encryption algorithms, performs cryptographic
`functions on Secret data and generates Session keys and
`
`6
`signatures. As is known in the art, HSM 130 is generally a
`tamper proof device, which uses Some level of physical
`Security measures to protect the Sensitive information inside.
`HSM 130 may be any security module used in the industry,
`such as a RACALHSM Model RG7000, or the security box
`attached to an automatic teller machines (ATM). In alterna
`tive embodiments, HSM 130 may be implemented on a
`Smart card within a card reader, on a Series of Smart cards,
`may be implemented on any Suitably Secure computer, or
`may be implemented in Software.
`HSM 130 is used either to generate or to store imported
`master keys Such as a master update key, a master load key,
`a Supplier update key, a key encryption key, a key exchange
`key, the issuer public and Secret keys, and the issuer public
`key certificate. HSM 130 also uses the master keys to
`generate card Specific keyS Such as a derived load key for
`each card, a derived update key for each card, the card public
`and Secret keys, and generates the card public key certificate.
`HSM 152 is a Similar device to HSM 130. HSM 152 is used
`to decrypt Secret data in output file 160 using a key encryp
`tion key, and to encrypt the Secret data under a key known
`to the card (for example, a Session key) prior to sending it
`to the card for personalization. HSM 152 also uses a supplier
`update key to unlock cards received from the card Supplier.
`Further use of HSM 130 and HSM 152 will be described
`below.
`Preparation processing device 154 may be implemented
`upon any Suitable computer System. By way of example, a
`suitable computer system is shown in FIG. 6 below. In one
`Specific embodiment, device 154 is implemented upon a
`personal computer. Device 154, as will be described in more
`detail below, is used to manipulate and Store cardholder data,
`application data, and other data Such as parameter data. The
`cardholder data includes data Such as the identification of the
`cardholder and the credit limit of the cardholder. The appli
`cation data includes data related to a credit application, a
`Stored value application, or other applications that may or
`may not require cryptography, Such as loyalty applications.
`A variety of other applications may be available for use on
`a Smart card to be personalized, including debit, dedicated
`funding Source applications, etc. The parameter data
`includes data not uniquely related to the particular
`cardholder, Such as the number of the card and the location
`of the issuer.
`Transport mechanism 158 may use any of the numerous,
`well-known file transfer methods for transferring file 160.
`By way of example, transfer via a floppy disk or over a
`Secure network connection may be used. Personalization
`device 150 may be any suitable personalization machine
`Such as are known in the art. By way of example, those
`machines made and used by Datacard, Inc. may be used. AS
`is known in the art, device 150 includes any number of
`processing modules for personalizing various aspects of a
`Smart card. Module identifier codes embedded in output file
`160 indicate following data which is to be used by the
`appropriate processing module to personalize a Smart card.
`According to one embodiment of the invention, prior to
`undergoing the Standard personalization process at the per
`Sonalization location, input data for each Smart card to be
`personalized is processed using preparation processing
`device 154 at the issuer's location. FIGS. 2, 3 and 4 describe
`one embodiment by which input data for a Smart card is
`processed using device 154. Preparation processing device
`154 produces output file 160, which includes data to be used
`in the personalization proceSS for all cards to be personal
`ized. File 160 is described in greater detail below in FIGS.
`5A-5D. Data in output file 160 may include: data for any of
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`GOOG-1010
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 15
`
`

`

`US 6,367,011 B1
`
`7
`a variety of applications Such as credit, Stored value, loyalty,
`etc., derived card keys and derivation data for particular
`applications, public key certificates, and other data. Result
`ing output file 160 is then transferred to personalization
`device 150 via transport mechanism 158.
`In one embodiment of the invention, input file 159 has the
`format of output file 160, although not all needed informa
`tion is yet present in the file. For example, as noted earlier,
`a wide variety of information is passed to the personalization
`location. Data destined for the magnetic Stripe of a card, for
`embossing on a card, and for graphics on a card may already
`be present and complete in input file 159 in the format
`described in FIGS. 5A-5D. Nevertheless, data for a particu
`lar application or applications, destined for the chip on the
`card, may not be entirely complete in input file 159. For
`example, derived keys, a card Secret key, an issuer certificate
`and a card certificate may not be present in input file 159. As
`described in FIGS. 2-4, this information is added to output
`file 160 during the preparation process. Furthermore, an
`issuer may have different Systems (Such as an on-line
`System, a cardholder System, a load System, etc.) from which
`input data destined for output file 160 is retrieved. For
`example, data for different applications on the chip card may
`come from different sources. Thus, output file 160 may be
`run through the process of FIG. 2 multiple times, each pass
`generating and adding information to records in the file for
`different applications.
`Once file 160 reaches the personalization location, device
`150 processes file 160 using Standard processing techniques
`to personalize the Smart cards whose personalization data is
`represented in file 160. In one embodiment, module identi
`fier codes in file 160 indicate which processing modules are
`to operate on which data. In particular, non-Secret data and
`Secret data (Such as derived keys, public key pairs and
`certificates) for each application available on a Smart card is
`read from file 160 by device 150 and transferred to each
`Smart card being personalized.
`Accordingly, when the remainder of the personalization
`proceSS is performed at the personalization location, perSon
`alization device 150 no longer needs to derive card keys, or
`to generate card key pairs which is typically very time
`consuming. A further advantage is that the present invention
`allows an increase in Security Since the master keys never
`need to leave the issuer's location or control.
`
`Security Embodiment
`Those of skill in the art will appreciate that a wide variety
`of keys and encryption algorithms may be used by the card
`Supplier, issuer, personalizer, and by the card itself to
`provide Security during card manufacture, transport and
`personalization. The following presents one possible
`embodiment for use of a variety of keys to provide Security
`in various aspects of the invention. Of course, a wide variety
`of other forms of keys may also be used. In this embodiment,
`the issuer generates various keys to provide Security. For
`example, the issuer may generate: a master load key (KML)
`used to create a derived unique load key (KDL) for each
`personalized card; a master update key (KMU) used to
`create a derived unique update key (KDU) for each person
`alized card; an issuer transport key (ZCMK); a Supplier
`update key (KMC) used to create a derived unique Supplier
`update key (KDC) for each personalized card; a key version
`update (VKUiep) which is initialized to the key version of
`the KMC used to create the initial diversified key for update
`transactions for a card; and a key encryption key (KEK) for
`Sending other keys to the personalization location. KDC is
`
`8
`preferably placed on each card by the card Supplier for use
`as a transport key to Secure the cards prior to personaliza
`tion. Key KMC is sent to the Supplier and to the personal
`ization location.
`HSM 130 is used either to generate or to store imported
`master keys such as KMU, KML, KMC, KEK, a key
`eXchange key, the issuer public and Secret keys, and the
`issuer public key certificate. HSM 130 also uses the master
`keys to generate card Specific keyS. Such as KDL, KDU, the
`card public and Secret keys, and generates the card