SECURE END-TO-END PERSONALIZATION OF SMART CARDS

TECHNICAL FIELD

The present disclosure relates generally to smart card programming. In particular, the present disclosure relates to secure personalization of smart cards.

BACKGROUND

A personalization system, such as a smart card printer, may support personalization of a smart card, such as a multi-application IC card, in addition to performing a regular “printing” (e.g., image printing) operation. Personalization of smartcard application data is accomplished, in many cases, by sequential exchange of Application Protocol Data Units (APDUs), via a smartcard reader, between an external personalization system (software application) and the IC card. When the personalization system personalizes IC cards over the internet/network, the personalization system faces many challenges. For example, network and system performance, network reliability, and end-to-end security must be considered to ensure that such smart cards are personalized accurately and rapidly.

For example, in many instances, smart card personalization requires iterative communication with a smart card, for example for authentication and acquisition of encryption keys, followed by communication sequences between a personalization system and a smart card to exchange APDUs, sometimes to program Application Load Units (ALUs) onto the smart card. In instances where many smart cards are issued concurrently or sequentially, or where a personalization system is located remotely from the smart card printer, it is possible that network traffic may cause a delay in communication of data between a personalization system and the smart card. Furthermore, because the issuance system requires encryption keys of the smart card to form the ALUs or to complete the APDU exchange required for programming, the rate at which smart cards can be personalized is limited by not only data exchange rates/bandwidth issues, but also a rate at which the personalization system is capable of generating data to be stored on a card, which typically happens concurrently with personalization of the smart card. Additionally, because key exchange is required for formation of APDUs, smart card keys may be transmitted over the Internet, in the case of a remote personalization system, causing further security concerns. Additionally, if network communication is interrupted for some reason, programming of smart cards will fail.

For these and other reasons, improvements in mechanisms for personalization of smart cards are desirable.

SUMMARY

In general, the present disclosure relates to secure personalization of smart cards. In some aspects, a customized dataset used for programming a smart card can be created using a virtual smart card, and secured for communication with the card issuance device using a device-specific encryption key. At the card issuance device, the customized dataset can be decrypted and used to personalize the real smart card.

In a first aspect, a method of personalizing a smart card is disclosed. The method includes generating, at a personalization system, a customized dataset including personalization data for installation onto a smart card, the customized dataset being generated based on an operating system of the smart card by performing a personalization process using a virtual smart card formatted according to the operating system, and encrypting at least a portion of the customized dataset, at a personalization system, using an encryption key that is associated with a card issuance device that is separate from the personalization system, the encryption key being different from any encryption key used to secure the customized dataset when stored on the smart card. The method further includes transmitting the customized dataset to the card issuance device.

In a second aspect, a secure end-to-end smart card personalization system is disclosed. The system includes a personalization system comprising a programmable circuit communicatively connected to a memory storing computer executable instructions. When executed, the instructions cause the personalization system to generate a customized dataset including personalization data for installation onto a smart card, the customized dataset being generated based on an operating system of the smart card by performing a personalization process using a virtual smart card formatted according to the operating system; encrypt at least a portion of the customized dataset, at a personalization system, using an encryption key that is associated with a card issuance device that is separate from the personalization system, the encryption key being different from any encryption key used to secure the customized dataset when stored on the smart card; and transmit the customized dataset to the card issuance device.

In a third aspect, a secure end-to-end smart card personalization system is disclosed. The system includes a personalization system communicatively connected to a card issuance device. The personalization system is configured to generate a personalized virtual smart card including personalization data for installation onto a real smart card, the customized dataset being generated based on an operating system of the real smart card by performing a personalization process using a virtual smart card formatted according to the operating system. The personalization system is also configured to encrypt at least a portion of the customized dataset using a public key of a public-private key pair unique to a printer and different from a public key of the real smart card. The personalization system is further configured to transmit the customized dataset to the card issuance device.

In a further aspect, a method of personalizing a smart card is disclosed. The method includes receiving at a personalization system an operating system type of a smart card to be personalized, and generating a customized dataset including personalization data for installation onto the smart card to be personalized by performing a personalization process using a virtual smart card formatted according to the operating system without requiring a concurrent secured connection to the card issuance device. The method further includes, after the customized dataset is generated, transmitting the customized dataset to the car issuance device.

In a still further aspect, a method of personalizing a smart card includes transmitting to a personalization system an operating system type of a smart card to be personalized; receiving, at a card issuance device, a customized dataset including personalization data for installation onto the smart card to be personalized, the customized dataset including a personalized virtual smart card formatted according to the operating system; and personalizing a real smart card using the customized dataset.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example network in which secure personalization of applications on smart cards can be accomplished;

FIG. 2A illustrates a flowchart of a method of generating personalization data at a personalization system, according to an example embodiment;

FIG. 2B illustrates a flowchart of a method of printing a smart card using personalization data generated at a personalization system as described in accordance with FIG. 2A;

FIG. 3 illustrates a computing device with which aspects of the present disclosure can be implemented;

FIG. 4 illustrates a personalization system, according to an example embodiment;

FIG. 5 illustrates an example communication sequence utilized to personalize a smart card according to example embodiments of the present disclosure;

FIG. 6 illustrates a system for secure personalization of a smart card, according to a first example embodiment;

FIG. 7 illustrates a system for secure personalization of a smart card, according to a second example embodiment;

FIG. 8 illustrates an example communication sequence utilized to authenticate a smart card; and

FIG. 9 illustrates a system for secure personalization of a smart card, according to a third example embodiment.

DETAILED DESCRIPTION

As briefly described above, embodiments of the present invention are directed to systems and methods for secure personalization of smart cards. In example aspects, the secure personalization of smart cards disassociates creation of Application Protocol Data Units (APDUs) and Application Load Units (ALUs) from programming of the smart card itself, thereby allowing creation of application data intended to be installed on a smart card during a personalization process to be disconnected from the smart card, in either or both of time and location. This allows for pre-creation of application programming and personalization data for a smart card and/or creation of personalization data at a location other than at a printing system that is interfaced directly to the smart card. Further, it allows for securing of personalization data that is transmitted to a smart card printer using a security key other than the one used by the smart card; because personalization of the smart card is moved to the printer from the personalization system, concerns regarding security of personalization data in transmission to the printer are reduced.

In some aspects, a customized dataset used for programming a smart card can be prepared for transmission to a smart card, and used in personalizing the smart card. The customized dataset can be, for example, a personalized “virtual” smart card that is transmitted to a location that is local to the “real” smart card that is to be personalized. The virtual smart card can be, for example, encrypted with an encryption key that is associated with the card issuance device (e.g., printer) at which the smart card resides. The encryption key can be an asymmetric or symmetric key, and optionally can be a key that is unique to that card issuance device. The use of such a key ensure security during transmission of the customized dataset (e.g., the personalized “virtual” smart card).

At the end device, the personalization that is reflected in the virtual smart card can be conveyed to the real smart card, so the real smart card can be correctly personalized. Furthermore, the card issuance device can handle programming the smart card using personalization data reflected in the virtual smart card. As such, the personalization system need not be configured to accommodate personalization at a plurality of different card issuance devices, but rather configuration of data for different smart card operating systems can be handled by the card issuance device, simplifying the requirements of the personalization system. Additionally, a secured connection between the personalization system and card issuance device is not required during personalization of the real smart card, simplifying security and communication requirements of such distributed card issuance systems. Still further, use of an encryption key associated with, or in some cases unique to, the card issuance device allows for validation of the card issuance device. This improves security by avoiding distribution of personalization data, or decryption of that data, at an incorrect card issuance device.

The secure personalization features described herein can be used in conjunction with a plurality of different types of smart card platforms. By way of background, a number of different types of platforms exist, and each of which has an operating system including hardware-specific firmware useable to provide secure access to on-card storage, authentication, and encryption. Generally, the smart card operating system controls a communication protocol of the smart card, manages files and data held in memory, and provides access control and card security features for the smart card. Examples of operating systems include MULTOS, GlobalPlatform, and a variety of proprietary or native operating systems. Each has a different personalization process that is card dependent, in that the personalization system typically is required to identify the card type or operating system, and then select an appropriate method or process with which to generate the APDUs used to personalize the application on that card. In accordance with the present disclosure, the methods and systems described herein provide for secure personalization of smart cards that use a variety of smart card platforms.

Furthermore, and as noted in further detail below, the term smart card is intended to encompass not only physical smart cards (both contact smart cards and contactless cards), but also electronic smart cards, such as electronic representations of banking cards or other cards that store sensitive personal data and can be used in conjunction with trusted transactions (e.g., for access or financial transactions). For example, electronic smart cards may be stored in an electronic wallet on a smartphone or other mobile device.

Referring to FIG. 1, an example network 100 in which secure personalization of applications on smart cards can be accomplished. The network 100 includes a variety of types of network locations, only some of which may be present in the context of any particular personalization scenario (as further described below).

In the example shown, the network 100 can include a card issuance location 102 having a card issuance computing system 104 that is communicatively connected to one or more card issuance devices, shown as printers 106. In the example shown, a personalization system 108 and a personalization data server 109 are communicatively connected with the card issuance computing system 104 via a network 110. The network 110 can correspond to a public network, such as the Internet.

The card issuance location 102 generally corresponds to a location at which a smart card will be “personalized”. Specifically, the card issuance location 102 is a location at which a smart card may be printed, and at which the smart card will receive, via a smart card printer 106, programming of specific applications and/or data that are unique to that smart card. Example smart card applications and/or data can include information associated with an intended user of the smart card, information regarding access rights, programming logic defining security access and/or financial account access, retail loyalty, and/or other types of applications. Accordingly, the card issuance location 102 may be a bulk card issuance facility, or may be a location at which smart cards may be issued to users in an “on demand” manner, such as at a financial institution or secured facility.

The card issuance computing system 104 can, in example embodiments, correspond to a printing system, such as a printing data coordination system from which customized datasets can be provided to the card issuance devices (e.g. printers 106) for programming of smart cards. In example embodiments, the card issuance computing system 104 can be interfaced to a single printer 106, or, as seen in FIG. 1, to a plurality of printers 106. In such a configuration, the card issuance computing system 104 can coordinate data transmission to the various printers 106 to ensure adequate throughput to those printers as each printer becomes available and ready to personalize a new smart card. The printers 106 generally can be configured to perform a personalization process by which personalization data is programmed onto a smart card, as well as optionally a physical printing process in which the smart card is imprinted with text, graphics, or other labeling.

However, in some applications of the present disclosure, a card issuance computing system 104 is not present. For example, and as further seen in FIG. 1, a card issuance device, such as a printer 107, can be directly connected to network 110. In such arrangements, the printer 107 can operate as a stand-alone issuance system, from which smart cards can be issued. The printer 107 may be located, for example, at a branch location of a financial institution where lower quantities of smart cards are required to be issued, and as such, the plurality of printers 106 are not required.

Example types of smart cards that can be personalized by printers 106, 107 can include, for example, physical smart cards including financial cards (e.g., debit cards or credit cards) having a magnetic stripe and an integrated circuit card (ICC) chip. Accordingly, in such cases, personalization of the smart card can include encoding data to the magnetic stripe, as well as printing or embossing text and/or graphics onto the physical card.

In still further examples, rather than use of a card issuance device such as printers 106, 107, a software-based card issuance device could be used to issue a smart card to a user. As seen in FIG. 1, a mobile device, such as a smartphone 112 having mobile wallet software installed thereon, can act as a card issuance device by including card issuance software capable of generating a real personalized software-implemented smart card.

The personalization system 108 generally corresponds to a computing system having a software tool installed thereon that is capable of generating programming for storage on and execution from a smart card. In some cases, the personalization system 108 is located proximate to the printers 106, for example within a same local network as the card issuance computing system 104, or integrated therewith into the same computing system. However, in accordance with the secured aspects of the present disclosure, the personalization system 108 can more easily be located remotely from the printers 106, since the personalization system 108 can be used to generate personalized card data at a time other than the time at which a card is personalized. In some aspects, the personalization system 108 can be available to a user either as a discrete computing system, or as a cloud-based system accessible via a remote computing system having a browser installed thereon. In such situations, the personalization system 108 may be remote from both a user requesting card issuance and a printer or other card issuance device, although the user requesting card issuance may be local to the card issuance device. Such arrangements may be used, for example, in the case of cloud-based card issuance initiated at branch locations of financial institutions or facilities where limited card issuance volumes are required.

In example embodiments, the personalization system 108 prepares personalization data in accordance with a format of a “virtual” smart card, and transmits that personalization data to a card issuance device, such as the card issuance computing system 104 and printer 106, the printer 107, or the software-based card issuance device (mobile device 112), for personalization of a smart card.

The personalization data server 109 stores data to be used in forming personalized, or custom, datasets for programming of smart cards using printers 106. In example embodiments, the personalization data server 109 can include a database of application data and/or user data transferrable to smart cards.

The personalization system 108 can, in such arrangements, transmit to the card issuance device a customized dataset that can be used for personalization of the smart card at the card issuance device. The customized dataset can be, for example, a personalized virtual smart card, which can be created using personalization data either local to the personalization system 108 or obtained from a personalization data server 109.

In example embodiments, the various computing systems, including the card issuance computing system 104, the personalization system 108, and the personalization data server 109, can be located at a common location or at a common computing system, such as might be the case if personalization were performed locally at the card issuance location 102. In other embodiments, such as the one shown, one or more of these systems can be located remotely from the printers 106, 107, or mobile device 112, as previously noted.

As noted herein, printers 106, 107 generally correspond to one example of a card issuance device. Printers generally include a card programming and a physical printing component, such that each printer can imprint images or characters on a smart card and correspondingly program the smart card for a particular application. Example printers may include, for example, an MX-series card issuance system, or a CD- and/or CR-series printing system, each of which are commercially available from Entrust Datacard Corporation of Shakopee, Minn. It is noted that in alternative implementations, card issuance devices may be used that include additional functionality, or which lack the physical character/graphical printing characteristics of printers 106. For example, a card issuance device may include mobile device 112, which includes software for instant issuance of a software-based smart card. For simplicity, in the present specification, the term “printer” will be used generally for a card issuance device, although such card issuance devices are not necessarily limited to printers.

Referring to FIG. 1 generally, and reviewing the various card issuance devices (e.g., the card issuance location 102, the networked printer 107, and the mobile device 112) it is noted that one or more of these subsystems of the network 100 can be included in an overall system for card issuance, and that not all such subsystems are required to be present to implement aspects of the present disclosure. Generally, in accordance with the present disclosure, at least one card issuance device will be associated with a smart card, and is communicatively connected to a personalization system (e.g., either local, remote, or cloud-based) that can provide to it personalization data for personalization of a smart card by providing a personalized virtual smart card or other format of personalized data prepared to be used in personalization of the “real” (hardware or software-based) smart card.

Referring now to FIGS. 2A-2B, flowcharts of methods of generating personalization data (e.g., data customized to a particular smart card for programming on that smart card, such as APDUs), and printing a smart card using personalization data, are shown. The methods described herein can be performed at a personalization system 108 and a printer 106, 107, respectively. Referring first to FIG. 2A, a method 200 of generating a customized dataset for installation onto a smart card is described. The customized dataset can be, for example personalization data formed as ALUs, which can in turn be programmed onto the smart card via APDU exchange. The personalization data can be, for example, included in a virtual smart card that is personalized with a particular end user's personalization data, with the virtual smart card transmitted to the printer for personalization of the “real” smart card.

In the embodiment shown, the method includes obtaining, from a card issuance device, a format of a smart card to be personalized (step 202). This can include, for example, obtaining input from a user identifying a type of smart card to be personalized, or querying a card issuance device to determine the type of smart card to be personalized. By type, or format, it is generally intended that an operating system or platform architecture of the smart card is determined, since different smart cards are personalized differently and using different data formats.

The method 200 further includes, in the embodiment shown, generating the customized dataset for installation onto a smart card (step 204). The customized dataset is constructed for use with the determined operating system of the smart card. As noted above, each of a plurality of different smart card operating systems have different requirements for programming of the smart card in terms of secured programming sequence and formatting of data to be programmed. In example embodiments, the customized dataset includes personalization data, and can optionally include one or more applications that use the personalization data to be stored on the smart card. The personalization data can include, for example, a set of specific encryption keys to be used by the card, information about a person to whom the card will be issued (e.g., the cardholder's name) or access or account details for which the card is used. The customized dataset represents a formatting of the personalization data that occurs after a personalization sequence with a smart card. In some cases, the customized dataset corresponds to a personalized version of a “virtual” smart card that is selected to have a same operating system as the “real” smart card that ultimately will be personalized. In other embodiments, the personalized “virtual” smart card is selected to have an operating system that is based on and/or compatible with the operating system of the “real” smart card.

In the embodiment shown, the method 200 further includes obtaining an encryption key that is specific to the card issuance device (step 206). The encryption key can be a public key of a public-private key pair unique to a card printer, or a symmetric key used to wrap encrypted personalization data, as is further described below. Notably, the encryption key that is used is a different key from any key of the real smart card, which is typically used to form the customized dataset. The encryption key can be retrieved from the card issuance device, or a key repository used to manage keys of card issuance devices. Although various key types could be used, a printer-specific public-private key pair allows for verification of the card issuance device, since only the card issuance device will have access to the private key, with the key repository merely managing public key access. In such instances, the encryption key is specific to the device performing the programming of the smart card (e.g., the printer 106, 107 or mobile device 112) so that card issuance device (e.g., printer) is capable of processing the customized dataset at the time of programming to encrypt that customized dataset for use with the specific card being personalized. For example (and as explained below), the printer can decrypt the customized dataset using the private key of its public-private key pair, and re-encrypt the customized dataset using the public key of the smart card's public private key pair, thereby preparing the customized dataset for storage on the smart card. Of course, in other embodiments, the encryption key that is used may not be device-specific, but may be associated with the device. For example, a symmetric key may be issued to both the card issuance device and personalization system by an authentication system, with the symmetric key being maintained in a key repository in association with an identifier of the card issuance device. Other configurations are possible as well, which allow for sharing of the key or complementary keys between the card issuance device and personalization system.

The method further includes encrypting the customized dataset at the personalization system using the encryption key that is unique to a card issuance device, such as a printer (step 208). This can include use of the printer-specific encryption key obtained in step 206, above. In some instances, the encryption key can be used in the same way as the public key of a public-private key pair of a smart card; the encryption key can also be a symmetric key. In either event, the encryption key can either be a separate key used for communication between the personalization device 108 and an intended card issuance device (e.g., printer 106, 107, or mobile device 112) or can be treated, in effect, as a key of a “virtual” smart card that is used by the personalization device to create personalized virtual smart cards which can then be transmitted to card issuance devices for personalization of real smart cards. In either instance, because the personalization device 108 creates a personalized virtual smart card largely without maintaining open a communication session with the real smart card to be personalized, the real smart card does not need to be concurrently present at the printer to allow a separate personalization system to generate a customized dataset for transmission at the printer.

As seen in FIG. 2A, once the customized dataset is encrypted using the encryption key that is specific to the card issuance device, the encrypted customized dataset can be transmitted to the card issuance device (step 210). Depending upon the specific network arrangement of the personalization system and the card issuance device, transmitting the encrypted customized dataset can occur, for example, via the Internet.

FIG. 2B illustrates a flowchart of a method 220 of printing a smart card using personalization data generated at a personalization system as described in accordance with FIG. 2A. The method 220 can be performed, for example, at a card issuance device, such as printers 106, 107, or mobile device 112 of FIG. 1. In the example shown, the method 220 includes sending a printer-specific key to a personalization system, as well as identifying a type (e.g., operating system) of the smart card to be personalized (step 222). The printer-specific key can be a key that is uniquely known to the printer or which is complementary to a key of the printer, such as a public key of a public-private key pair of the printer, and can be sent from the printer or other card issuance device, or from a key repository. The method 220 also includes receiving an encrypted dataset (step 224). The encrypted dataset can be, for example, the customized dataset including personalization data received from a personalization system (e.g., an encrypted, personalized virtual smart card). It is noted that transmission of the encryption key to the personalization system will typically occur prior to receiving the encrypted dataset from the personalization system, since the encrypted dataset will be encrypted using, among other keys, the encryption key provided by the printer or key repository.

In the example shown, the method 220 includes obtaining unique card keys (step 226). The unique card keys can be, for example, a public-private key pair of a real smart card to be personalized. The unique card keys can be obtained in a variety of ways. In example embodiments, the unique card keys can be stored on the smart card, and obtaining unique card keys includes receiving at a printer the public key of the smart card's public-private key pair. This can occur, for example, during an APDU exchange sequence between the printer and smart card, such as may occur during a traditional smart card personalization sequence. In other examples (e.g., where a smart card does not have encryption keys stored thereon, or where the smart card is to be reprogrammed), obtaining unique card keys can include either generating the public-private key pair at the printer (e.g., from a cryptographic engine local to the printer) or receiving the public-private key pair from a computing system assigning that key pair to a particular smart card.

The method 220 further includes converting the customized dataset for storage on the smart card (step 228). In the example as seen in FIG. 2B, converting the customized dataset can include decrypting the received encrypted dataset using a private key of the public-private key pair that is unique to the printer (or using s symmetric key if used for encryption), and, at the printer, forming one or more programming datasets for storage on the smart card. It is noted that sending the customized dataset to the smart card can include establishing, at the printer, a secure channel from the printer to the smart card, and performing a series of APDU exchanges to obtain a public key of the smart card and encrypting personalization data for storage on the smart card. The APDU exchanges can transmit personalization data from the virtual smart card to the real smart card, thereby causing transmission of the personalization data, now encrypted with the “real” smart card's encryption key, to the smart card for storage and use according to the operating system of the smart card (step 230). Accordingly, the real smart card is therefore personalized using the personalization data included in the virtual smart card received from the personalization system 108. It is noted that in some instances, at least a portion of the converting of personalization data for storage on a smart card and transmission to the smart card may happen concurrently, in that there may be some communication with the smart card necessary to obtain card-specific encryption key(s) to be used to both create “real” card personalization data and to form a secure channel to the card for transmission of that data.

Referring to FIGS. 2A-2B generally, is noted that in typical instances where personalization data is prepared for storage on a smart card, a communication sequence occurs between a personalization system and the smart card including multiple message exchanges, during which keys are exchanged that are used to generate data used to program or personalize the smart card. However, and as reflected in FIGS. 2A-2B, a single transmission occurrence (e.g., as in step 208 of FIG. 2A) can be used to transmit an encrypted customized dataset to the printer for smart card personalization. This mitigates the likelihood of network interruptions causing failure of the personalization process. Furthermore, because a “virtual” smart card and printer-specific key can be used to generate the encrypted customized dataset, the customized dataset that is transmitted to the printer is secured by the printer's encryption key, and therefore interception of the dataset when sent to the printer will not generally compromise the dataset at the smart card. Also, the method 200 can be performed at a different time from smart card personalization itself, as in method 220. As such, creation of a customized dataset can be temporally decoupled from programming of the smart card as well, thereby mitigating the extent to which creation of such customized datasets limits the speed with which smart cards can be personalized (e.g., in the instance of bulk personalization processes at a card processing facility). This also allows personalization systems to be implemented using lower-cost, lower-performance computing systems.

Referring now to FIG. 3, a computing device is shown, with which aspects of the present disclosure can be implemented. The computing device 300 can be used, for example, to implement a personalization system 108, personalization data server 109, or card issuance computing system 104 of FIG. 1, above.

In the example of FIG. 3, the computing device 300 includes a memory 302, a processing system 304, a secondary storage device 306, a network interface card 308, a video interface 310, a display unit 312, an external component interface 314, and a communication medium 316. The memory 302 includes one or more computer storage media capable of storing data and/or instructions. In different embodiments, the memory 302 is implemented in different ways. For example, the memory 302 can be implemented using various types of computer storage media, and generally includes at least some tangible media. In some embodiments, the memory 302 is implemented using entirely non-transitory media.

The processing system 304 includes one or more processing units, or programmable circuits. A processing unit is a physical device or article of manufacture comprising one or more integrated circuits that selectively execute software instructions. In various embodiments, the processing system 304 is implemented in various ways. For example, the processing system 304 can be implemented as one or more physical or logical processing cores. In another example, the processing system 304 can include one or more separate microprocessors. In yet another example embodiment, the processing system 304 can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processing system 304 provides specific functionality by using an ASIC and by executing computer-executable instructions.

The secondary storage device 306 includes one or more computer storage media. The secondary storage device 306 stores data and software instructions not directly accessible by the processing system 304. In other words, the processing system 304 performs an I/O operation to retrieve data and/or software instructions from the secondary storage device 306. In various embodiments, the secondary storage device 306 includes various types of computer storage media. For example, the secondary storage device 306 can include one or more magnetic disks, magnetic tape drives, optical discs, solid-state memory devices, and/or other types of tangible computer storage media.

The network interface card 308 enables the computing device 300 to send data to and receive data from a communication network. In different embodiments, the network interface card 308 is implemented in different ways. For example, the network interface card 308 can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WiFi, WiMax, etc.), or another type of network interface.

The video interface 310 enables the computing device 300 to output video information to the display unit 312. The display unit 312 can be various types of devices for displaying video information, such as an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, an LED screen, a cathode-ray tube display, or a projector. The video interface 310 can communicate with the display unit 312 in various ways, such as via a Universal Serial Bus (USB) connector, a VGA connector, a digital visual interface (DVI) connector, an S-Video connector, a High-Definition Multimedia Interface (HDMI) interface, or a DisplayPort connector.

The external component interface 314 enables the computing device 300 to communicate with external devices. For example, the external component interface 314 can be a USB interface, a FireWire interface, a serial port interface, a parallel port interface, a PS/2 interface, and/or another type of interface that enables the computing device 300 to communicate with external devices. In various embodiments, the external component interface 314 enables the computing device 300 to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers.

The communication medium 316 facilitates communication among the hardware components of the computing device 300. The communications medium 316 facilitates communication among the memory 302, the processing system 304, the secondary storage device 306, the network interface card 308, the video interface 310, and the external component interface 314. The communications medium 316 can be implemented in various ways. For example, the communications medium 316 can include a PCI bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing system Interface (SCSI) interface, or another type of communications medium.

The memory 302 stores various types of data and/or software instructions. The memory 302 stores a Basic Input/Output System (BIOS) 318 and an operating system 320. The BIOS 318 includes a set of computer-executable instructions that, when executed by the processing system 304, cause the computing device 300 to boot up. The operating system 320 includes a set of computer-executable instructions that, when executed by the processing system 304, cause the computing device 300 to provide an operating system that coordinates the activities and sharing of resources of the computing device 300. Furthermore, the memory 302 stores application software 322. The application software 322 includes computer-executable instructions, that when executed by the processing system 304, cause the computing device 300 to provide one or more applications. The memory 302 also stores program data 324. The program data 324 is data used by programs that execute on the computing device 300.

Although particular features are discussed herein as included within an electronic computing device 300, it is recognized that in certain embodiments not all such components or features may be included within a computing device executing according to the methods and systems of the present disclosure. Furthermore, different types of hardware and/or software systems could be incorporated into such an electronic computing device.

In accordance with the present disclosure, the term computer readable media as used herein may include computer storage media and communication media. As used in this document, a computer storage medium is a device or article of manufacture that stores data and/or computer-executable instructions. Computer storage media may include volatile and nonvolatile, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid state memory, read-only memory (ROM), electrically-erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

Referring now to FIG. 4, a particular computing system 400 is illustrated that can be used to implement a personalization system according to an example embodiment. Generally, the computing system 400 can be implemented using a device such as that described above in connection with FIG. 3. However, in the example shown, the computing system 400 includes a memory 404 that can be implemented on one or more memory or storage devices, such as memory 302 and/or secondary storage device 306. The memory 404 includes a programming software tool 402 and a database 406.

The programming software tool 402 generally obtains personalization data to be included in a customized dataset to be programmed onto a smart card, and configures that personalization data in accordance with one or more smart card operation system formats.

The database 406 stores an encryption key 408, a virtual card 410, and virtual card dataset 412. The encryption key 408 can be, for example, a key of a card issuance device that can be used for secure transmission of a personalized virtual smart card that is created at the personalization system. The virtual card 410 represents a particular smart card, and can include an operating system and optionally one or more applications that are constructed according to a known smart card operating system architecture. The virtual card 410 is therefore capable of operating in conjunction with the programming software tool 402 to perform a sequential process of APDU exchange to establish a virtual secure connection between the virtual card 410 and programming software tool 402, provide to the programming software tool 402 any virtual card keys that are associated with the virtual card 410, and allow the programming software tool to create the customized dataset 412 for personalizing the virtual card 410, thereby creating a personalized virtual smart card, seen as the customized dataset 412. As such, locally at the personalization system 400, the programming software tool 402 and the virtual card 410 perform the equivalent of a personalization process. It is noted that once the customized dataset 412 (shown as a “virtual card dataset” 412) is created, it can then be transmitted to a printer for conversion from a virtual card customized dataset to a real card customized dataset for storage on a real smart card (e.g., as described above in conjunction with FIG. 2B).

It is noted that although a single virtual smart card 410 is shown, the personalization system 400 can include more than one virtual smart card can be included. For example, a separate virtual smart card 410 can be maintained on the personalization system for each operating system that may be supported by that personalization system. Once the personalization system receives an indication of a particular operating system of a real smart card to be personalized, the personalization system can select the appropriate virtual smart card having a compatible operating system, and can perform a personalization process on a copy of that virtual smart card to create a customized dataset in the form of a personalized virtual smart card. That personalized virtual smart card can then be encrypted with the device-specific encryption key 408 for secured transmission to the card issuance device, which can then decrypt the personalized virtual card and use the personalization data from that virtual card to personalize the real (hardware or software-based) smart card at that card issuance device, either at a time of receipt or at some later time convenient to the card issuance device.

An overall, generalized sequence 500 of data transmissions to accomplish the secured smart card personalization is described in connection with FIG. 5. The sequence of transmissions is performed between for example, a personalization system 108, a card issuance device 404 (e.g., such as printer 106, printer 107, or mobile device 112), and a smart card 402 interfaced with the card issuance device 404.

In the example sequence 500 as shown, the personalization system 108 can send an authentication request to the card issuance device 404. The card issuance system device 404 can then respond to the security processing communication sequence by providing to the personalization system 108 a printer-specific key (e.g., the public key of the printer/card issuance device) that can be used to secure transmissions between the personalization system 108 and the card issuance device 404. The card issuance device 404 can provide the printer-specific key by, for example, either transmitting the key directly to the personalization system 108, or by providing a key reference to a key repository from which the personalization system 108 can retrieve a key identified by the key reference. The card issuance device 404 can also optionally transmit to the personalization system 108 a type of smart card to be personalized (e.g., the OS type of the smart card).

The personalization system 108 can then, based on the type of smart card, select a virtual smart card available at the personalization system and generate a customized dataset, including personalization data, thereby forming a personalized virtual smart card. The virtual smart card can also be secured, for example using the printer-specific key. This includes encrypting that customized dataset, including personalization data, with the printer-specific key. Optionally, the virtual smart card can be secured by using the printer-specific key as the public key of the virtual smart card, thereby ensuring that only the printer can decrypt and access personalization data.

In the example shown, the personalization system 108 then transmits the encrypted personalization data to the card issuance device 404. As noted above, this can occur in a single transmission or short transmission sequence that avoids lengthy handshaking or communication sequences that would typically be required to form and maintain a secure channel between the personalization system 108 and card issuance device 404 throughout a real smart card personalization process. This is because the customized dataset is encrypted and formatted in a different form (personalized to a different card) from the form in which it will be stored on a real smart card. The card issuance device 404 can decrypt the customized dataset using its private key (or otherwise, its key that is complementary to the key provided to the personalization system 108) and can reformulate (as necessary) the customized dataset for storage on a real smart card. This reformulation can take a variety of forms. At a minimum, where the formatting of the customized dataset transmitted between the personalization system 108 and the card issuance device 404 is the same as the format of storage on a smart card, the printer can decrypt the customized dataset using the private key of the public-private key pair it shared with the personalization system, extract personalization data from the customized dataset (the personalized virtual smart card), and perform a personalization process using a local communication session between the card issuance device 404 and the real smart card 402. In other instances, where an operating system or format of a smart card is known at the printer and different from the format in which the customized dataset is received (e.g., if the personalized virtual smart card is formatted using a different operating system or other change in formatting is required), the reformulation can include reformatting of the customized dataset for use with that different operating system. An APDU exchange sequence allows the card issuance device 404 to obtain an encryption key of the smart card 402, establish a secure communication tunnel to the smart card using the smart card's encryption key (e.g., the public key of the smart card for which the customized dataset was created), and transmitting the encrypted data to the smart card 402 via the secure tunnel to complete personalization of the smart card.

Optionally, a completion status message can be returned to the personalization system 108 from the card issuance device 404 to indicate success/failure of the personalization process with respect to a specific smart card. This information can include an identity of a particular smart card and a status message, for example a time of completion of the personalization process and/or a simple pass/fail status. Other information can be included in such a completion status message as well.

Referring now to FIGS. 6-9, specific examples of smart card personalization systems implemented using the methods and systems of the present disclosure are depicted, in which different smart card operating systems are utilized by the target smart card to be personalized.

Referring first to FIG. 6, a system 600 for secure personalization of a smart card using a first operating system, such as the MULTOS operating system. In this example, a printer 602 is communicatively connected to a printing system 604, which is in turn communicatively connected to a data preparation system 606. The printer 602 can be implemented using one or more of the printers 106 of FIG. 1, while the data preparation system 606 can correspond, for example, to the personalization system 108. The printing system 604 can assist with coordinating printing and personalization activities, for example as card issuance computing system 104. Of course, in other example implementations, a printing system such as system 604 could be excluded entirely, and a printer 602 could be directly connected to a remote data preparation system 606.

In the embodiment shown, the data preparation system 606 includes an Application Load Unit (ALU) Generator 634, which is a software tool configured to generate application load units (ALUs) capable of being stored on and executed from a smart card hosting the MULTOS operating system. The ALU generator 630 will generate an ALU 620, which is encrypted at the data preparation system 606 using a device encryption key (DEK) of the printer 602. An Application Load Certificate (ALC) 632 can be used as well, and corresponds to a certified copy of the public key of an application provider, as well as an application header. The ALC 634 can be signed using a MULTOS card authority's private key certifying key (KCK), allowing any MULTOS card that are appropriately implemented to verify the authenticity of the certificate. Accordingly, the ALU 620 can be certified to the smart card to which it is directed.

The encrypted ALU 620 can be passed to the printer 602 via the printing system 604. The printer 602 includes a cryptographic engine 610, a processing engine 612, a printing component 614, and a smart card personalization and programming device 616.

The cryptographic engine 610 is configured to generate encryption keys associated with the printer, and to manage storage of encryption keys received from other devices, such as smart cards interfaced to the smart card personalization and programming device 616. In some embodiments, the cryptographic engine 610 can be in memory of the printer 602 to ensure security, and in some embodiments, can include hardware encryption circuitry. However, in other implementations, the cryptographic engine 610 can be communicatively accessible to and separate from the printer (e.g., at the printing system 604 or other computing system communicatively connected thereto). In the example shown, the cryptographic engine 610 generates a device encryption key, which corresponds to a public key of a public-private key pair unique to the printer 602. The printer 602 can therefore provide the device encryption key to the data preparation system 606 for encrypting the ALU 620 prior to sending the ALU to the printer.

The processing engine 612 includes a plurality of executable components configured to personalize smart cards received by the smart card personalization and programming device 616. In the example shown, the processing engine 612 receives the encrypted ALU 620. The processing engine includes an operating system loader 622 and a Key Transformation Unit (KTU) converter 624. The operating system loader 622 generates commands (e.g., in the form of APDUs) that can be exchanged with a smart card via the smart card personalization and programming device 616 to program a smart card interfaced to that device. The KTU converter stores details of encryption of the ALU, and is encrypted using the public key of the target smart card.

The printing component 614 corresponds generally to a physical printing device that can imprint images and characters on a physical smart card. The smart card personalization and programming device 616 is a device having an electrical interface capable of communication with a smart card; in example embodiments, the electrical interface can include either electrical contacts or correspond to a wireless (e.g., near field) interface capable of exchanging APDUs with the card to accomplish a card programming process. In example personalization processes, the printing component 614 and the smart card personalization and programming device 616 are sequentially or concurrently utilized to generate a personalized smart card. Additionally, in instances where the card issuance device is a mobile device rather than a printer, the printing component 614 can optionally be excluded, with the smart card personalization and programming device 616 in those instances corresponding to a secure software interface to a software-based real smart card to be personalized.

In a typical MULTOS programming arrangement, an ALU generation system would generate an ALU using a KTU encrypted using the MULTOS card public key or a symmetric key encryption key; the ALU is then programmed onto the smart card, in accordance with the MULTOS Guide to Loading and Deleting [GLDA]. In this scenario, where the printer 602 and the data preparation system 606 are remote from one another, either the MULTOS card public key or a symmetric key encryption key is transmitted via the Internet, which represents a security risk.

By contrast, when the system 600 is in use, the printer 602 receives or generates a device encryption key (DEK), which can be either a symmetric key or an asymmetric key (e.g., a public-private key pair). When the system 600 is to personalize a smart card using the printer 602, the data preparation system 606 will retrieve the device encryption key from the printer 602, e.g., by querying the printer or requesting the key from a centralized key store. Optionally, the data preparation system 606 can verify the device encryption key using a certificate. The data preparation system 606 then generates the ALU 620 by protecting the KTU with the device encryption key. At this stage, the data preparation system 606 is not required to, and preferably does not have, any knowledge of a specific card encryption key, such as the smart card's MULTOS card public key. The data preparation system 606 transmits the ALU 620 to the printer 602 in a single command sequence, as noted above in connection with FIGS. 2A-2B and FIG. 5. Accordingly, only the specific printer 602 which provided its device encryption key is capable of decrypting the received ALU 620.

At the printer 602, the processing engine 612 will query a smart card available to the printer at the smart card personalization and programming device 616, to obtain the card public key. Once the printer 602 receives the ALU 620, the processing engine 612 will generate the ALU 626 that is encrypted with the card public key using the KTU converter 624. In particular, the processing engine 612 uses the cryptographic engine 610 to decrypt the received encrypted ALU 620, and converts that ALU to a real card ALU 626. The OS loader 622 then transfers the real card ALU 626 to the smart card via the smart card personalization and programming device 616. It is noted that other public information may be required (e.g., the ALC and/or MULTOS hash); such additional information can be provided to the smart card as well by the OS loader 622. Once complete, optionally the printer 602 can transmit back to the data preparation system 606 a status indicator, which may indicate success in programming a particular smart card (e.g., success or failure).

FIG. 7 illustrates a system 700 for secure personalization of a smart card using a second possible operating sequence, in this instance where an EMV application is personalized on a smart card. Generally, EMV applications can be personalized on smart cards that utilize any of a number of different smart card operation systems, including not only the MULTOS operating system as depicted in FIG. 6, but also a GlobalPlatform operating system or other proprietary operating systems. Personalization of EMV applications is specifically card-dependent, in that the personalization system must identify the card type and operating system and then select an appropriate method by which APDUs are generated for personalizing the EMV application on the smart card. Furthermore, EMV applications often require mutual authentication for personalization on a smart card, using a random challenge/response scheme between a personalization system and the card. As such, the generalized method described above in connection with FIG. 5 is a required, but incomplete, messaging sequence for EMV applications.

In the example shown in FIG. 7, a printer 702 capable of personalizing a smart card using an EMV application is communicatively connected to a printing system 704, which in turn is communicatively connected to an issuance system. As in FIG. 6, the printer 702 can be implemented using one or more of the printers 106 of FIG. 1, while the issuance system 706 can correspond, for example, to the personalization system 108. The printing system 704 can assist with coordinating printing and personalization activities, for example as card issuance computing system 104.

In the example shown, the issuance system 706 includes a data preparation and personalization component 740 that uses a virtual CPS card 742. The virtual CPS card 742 is used by the data preparation and personalization component 740 to precompute all APDUs 720 that are required for programming of a smart card. Those APDUs are generated based on mutual authentication with the virtual CPS card 742, as well as preparation of any EMV data required by the application.

A secure channel key 744 at the issuance system 706 is used to establish a secure communication channel between the issuance system 706 and printer 702. The secure channel key 744 can be either pre-shared between the printer 702 and the issuance system 706, or may be randomly generated at the issuance system 706 by the virtual CPS card 742. If the secure channel key 744 is obtained from the printer, it can be constructed as a device-specific encryption key. If the secure channel key 744 is generated by the virtual CPS card 742, it can be encrypted using a device encryption key obtained from the printer 702 (e.g., from cryptographic engine 710, which generally corresponds to cryptographic engine 610, described above). Accordingly, in either event, data transmitted between the issuance system 706 and printer 702 is encrypted by a device encryption key—in one possible instance, that data is the APDUs themselves (if the device encryption key is obtained from the printer before APDU generation), in which case the secure channel key 744 corresponds to the device encryption key. In another instance, the secure channel key is generated from the virtual CPS card 742, but the secure channel key 744 is itself encrypted by the device encryption key, and is transmitted to the printer alongside the APDUs in encrypted form so the printer can process the APDUs accordingly. The APDUs, after being created at the issuance system 706, are transmitted, in a single transaction, to the printer 702. If a device encryption key was used to encrypt the secure channel key, the single transaction can also include transmission of the virtual CPS card 742 as well as the secure channel key 744.

At the printer 702, a processing engine 712 queries an available smart card interfaced via the smart card personalization and programming device 716 to identify the card. The processing engine 712 will select a card profile from among a plurality of card profiles 730a-n, and trigger a card profile APDU converter 728 to convert the pre-computed APDUs 720 to real card APDUs 726, using an APDU parser 724. This can include, for example, performing one or more cryptographic calculations. In example embodiments, based on a selected card profile requiring certain information, the real card APDUs 726 may include less than all of the information included in the APDUs 720; additionally, APDUs 720 can in some instances be used to generate more than one set of real card APDUs 726.

Once the processing engine 712 successfully crease the real card APDUs 726 for a particular smart card, it can issue those APDUs using the smart card personalization and programming device 716, in accordance with the EMV Card Personalization Specification, available at https://www.emvco.com. The smart card personalization and programming device 716 may operate in sequence with the printing component 714 in a manner analogous to that described above with respect to similar components in FIG. 6. Additionally, once complete, optionally the printer 702 can transmit back to the issuance system 706 a status indicator, which may indicate success in programming a particular smart card (e.g., success or failure).

Referring now to FIGS. 8-9, and example communication sequence and system for personalizing smart cards according to a third possible embodiment are shown. In a particular example, the communication sequence and system are particularly applicable to personalizing smart cards utilizing a GlobalPlatform card specification in a secured manner, allowing for remote, secure personalization according to the concepts described herein. By way of background, smart cards utilizing the GlobalPlatform card specification use security domains to perform card content management and personalization. Each security domain uses a secure channel protocol (SCP) defined in the GlobalPlatform card specification to provide secure communication between an off-card entity (e.g., a personalization system, such as personalization system 108) and a smart card. Generally, the SCP defines a first step of authenticating a card using authentication cryptograms that are based on an off-card challenge, card challenge, and session keys. The card challenge is a random or pseudo-random value generated by the smart card (based on an option defined in the SCP). If pseudo-random generation is not supported, the off-card application first most obtain a card challenge to calculate authentication cryptograms, and subsequently generate APDUs required for personalization. Accordingly, off-card entities, such as a personalization system, are not able to prepare APDUs in advance for personalization, preventing batch data preparation, and limiting the ability to remotely personalize GlobalPlatform cards over unreliable or slow networks.

GlobalPlatform-compliant smart cards have a runtime environment that hosts a security domain separated from applications (e.g., card issuer applications, application provider applications, etc.), which execute via an API layer between the runtime environment and the applications.

An illustration of a communication sequence 800 useable for authentication of a GlobalPlatform smart card is illustrated in FIG. 8. In that communication sequence 800, both the smart card (including an application 804 and security domain 802) and the off-card entity 806 (e.g., the personalization system 108) generate an authentication cryptogram (the host challenge and card challenge, respectively). The off-card entity verifies the card cryptogram and the smart card verifies the host cryptogram in the security domain 802. Session keys are used to secure communications between the off-card entity 806 and the smart card. Card and host cryptograms can be generated, for example, by concatenating a sequence counter, host challenge, and card challenge into a block; the card challenge can be generated as a random or pseudo-random number unique to a particular secure channel session.

Because of the mutual authentication requirement of GlobalPlatform cards reflected in FIG. 8, a system constructed for secure GlobalPlatform-compliant personalization requires close cooperation of a smart card and personalization application. Accordingly, a system 900 for secure personalization of such cards is illustrated in FIG. 9, and represents a slight modification over the systems of FIGS. 6-7. The system 900 includes a printer 902, printing system 904, and data preparation system 906. As in FIG. 6, the printer 902 can be implemented using one or more of the printers 106 of FIG. 1, while the data preparation system 906 can correspond, for example, to the personalization system 108. The printing system 904 can assist with coordinating printing and personalization activities, for example as card issuance computing system 104.

In the example shown, a smart card personalization application 940 and a virtual GlobalPlatform smart card 942 are stored at the data preparation system 906. The virtual GlobalPlatform smart card 942 implements the GlobalPlatform SCP, and optionally supports pseudo-random card challenge generation. The virtual GlobalPlatform smart card 942 shares a set of master keys 944 with the printer 902; as such, the master keys 944 of the virtual GlobalPlatform smart card 942 are selected such that they are unique to the printer 902, but are not the same master keys as would be used by the real GlobalPlatform smart card on which the personalized application is to be stored. In example embodiments, the master keys 944 can include a set of derived keys, for example using a device ID as the data from which the key is derived. Alternatively, a random set of SCP keys can be generated using a common card sequence counter (either shared or predefined), and those keys can be encrypted using a device encryption key that is specific to the printer 902. As such, similarly to the configuration for EMV applications in FIG. 7, either the master keys are printer-specific or are encrypted using printer-specific keys.

At the personalization system 906, the smart card personalization application 940 generates all of the APDUs that would be required for personalization using the virtual GlobalPlatform smart card 942, to form APDUs 920. The virtual GlobalPlatform smart card 942 stores all of the APDUs 920 that are generated, which are then transferred to the printer 902. This transfer can include the various personalization information reflected in the constructed APDUs. Those APDUs may be encrypted using either a device encryption key or secure channel keys; if encrypted using secure channel keys, those keys can also be transmitted to the printer 902, and are encrypted using a device encryption key. As such, at least a portion of the customized dataset to be sent to the printer 902 is encrypted using a device-specific key of the printer.

At the printer, after the APDUs 920 are received, each of the APDUs 920 is processed by the processing engine 912. If an APDU within the APDUs 920 matches a secure channel protocol (SCP) APDU defined for secure channel authentication, the GlobalPlatform SCP authenticator 922 is called by the smart card personalization and programming device 916 to generate a “real” secure channel session key and perform the authentication sequence of FIG. 8 with the real card, via the smart card personalization and programming device 916. Once the card is successfully authenticated, the GlobalPlatform SCP converter 924 converts the APDU from a virtual card APDU to a real card APDU, for example by reformatting the APDU by decrypting that APDU using the device encryption key and/or secure channel key, and re-encrypting the APDU using the “real” secure channel session key for transmission to and storage on the smart card. As with the prior-described arrangements, optionally the printer 902 can transmit back to the data preparation system 906 a status indicator, which may indicate success in programming a particular smart card (e.g., success or failure).

Referring to FIG. 9 generally, it is noted that the transformation of APDUs, and the key exchange process required for GlobalPlatform-compliant smart cards generally involves two authentication processes as described in conjunction with FIG. 8—one between the data preparation system 906 and the virtual GlobalPlatform smart card 942, and a second between the printer 902 and the real GlobalPlatform smart card at the smart card personalization and programming device 916. This allows a complete dataset to be transmitted from the data preparation system 906 to the printer 902 in a single instance, and decouples timing of creation of APDUs from the timing at which those APDUs are transferred to the real GlobalPlatform smart card. Accordingly, similar advantages to those described herein can be realized.

This disclosure described some aspects of the present technology with reference to the accompanying drawings, in which only some of the possible aspects were shown. Other aspects can, however, be embodied in many different forms and should not be construed as limited to the aspects set forth herein. Rather, these aspects were provided so that this disclosure was thorough and complete and fully conveyed the scope of the possible aspects to those skilled in the art.

As should be appreciated, the various aspects (e.g., portions, components, etc.) described with respect to the figures herein are not intended to limit the systems and methods to the particular aspects described. Accordingly, additional configurations can be used to practice the methods and systems herein and/or some aspects described can be excluded without departing from the methods and systems disclosed herein.

Similarly, where steps of a process are disclosed, those steps are described for purposes of illustrating the present methods and systems and are not intended to limit the disclosure to a particular sequence of steps. For example, the steps can be performed in differing order, two or more steps can be performed concurrently, additional steps can be performed, and disclosed steps can be excluded without departing from the present disclosure.

Although specific aspects were described herein, the scope of the technology is not limited to those specific aspects. One skilled in the art will recognize other aspects or improvements that are within the scope of the present technology. Therefore, the specific structure, acts, or media are disclosed only as illustrative aspects. The scope of the technology is defined by the following claims and any equivalents therein.

SECURE END-TO-END PERSONALIZATION OF SMART CARDS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims