SYMMETRIC-KEY APPLICATION-LOADING SMARTCARDS

BACKGROUND OF THE INVENTION

[0001] The present invention relates generally to multi-application smartcards, and more particularly to providing for asymmetric post-issuance loading of applications onto multi-application smartcards that are configured on issuance for symmetric-key loading of applications.

[0002] Multi-application smartcards are smartcards that may execute more than one application. Providing multiple applications on a smartcard allows for several benefits. For example, users of such cards do not have to carry as many single-application cards in their wallets. For card issuers a benefit is the ability to load additional applications onto their customers' cards, thus avoiding the expense of issuing additional cards to them when the cards they already carry are compatible with a new application, resulting in substantial savings.

[0003] In some cases a multi-application smartcard may be issued with several applications preloaded. However, it is often the case that it is desirable to load new applications after the card has been issued. Loading applications after issuance provides several advantages. For one, it is possible to provide updates of existing applications after a card has gone into use. Another advantage is the possibility of making new applications available to a consumer already using the card.

[0004] Smartcards are often entrusted with highly sensitive information and are key components in securing otherwise risky transactions. Smartcards are designed to be highly secure devices that are particularly suitable for storing private information such as encryption keys, login credentials, account numbers, and even to function as electronic wallets that carry account balances. By maintaining a user's private information such as encryption keys and login credentials it is possible for a smartcard to provide end-to-end security with remote servers without ever revealing keys or credentials even to the computer or terminal to which the smartcard is connected. [0005] The security provided by smartcards requires secure loading of applications. Both the end-user and issuing institution have an interest in being assured that an application loaded onto a card originates from a trusted party and has not been tampered with in some fashion. Similarly, modification and deletion of applications should only be possible without fear of compromised security. Secure application loading mechanisms operate to ensure that only authentic and issuer-specified applications may be loaded onto a smartcard issued by the issuer. Furthermore, a smartcard with a secure applications- loading mechanism rejects any unauthorized accidental or intentional modifications of applications.

[0006] Nevertheless, it is crucial to the flexibility of multi-application smartcards that loading, modification, and deletion of applications may be performed over insecure public networks after the initial issuance of the cards.

[0007] In the prior art, there are two different approaches to securely loading (as well as modifying and deleting) applications onto a multi-application smartcard: asymmetric key cryptographic loading and symmetric key cryptographic loading of applications. In each of these, crypto key loading refers to the loading of an application secured by a key, e.g., an asymmetric or a symmetric key. Which type of application loading to use with a smartcard is decided at card personalization. A card issuer basically decides in advance how the issuer may want to manage their card base in the future, and commits to that decision up front. Once the decision has been made, the decision as to whether a card is an asymmetric-key loading or a symmetric key-loading card cannot be changed.

[0008] Multos operating system, also from the Multos Consortium, is an example of an asymmetric-key crypto application-loading scheme. Multos is a highly secure multi- application smartcard operating system. Multos is loaded onto smartcards during chip manufacture. The entire process of loading the operating system and applications that run under it are protected using asymmetric cryptography, namely, RSA cryptography.

[0009] In contrast, Multos Step/One, also from the Multos Consortium, is an example of a symmetric-key crypto application-loading scheme. In Step/One, however, application loading is protected using symmetric key cryptography, namely, Triple DES.

[0010] An issuer who anticipates that they will never desire to perform multi-party secure application loading after a card has been issued may select the symmetric-key application loading mechanism to perform application loading and card personalization. However, a negative aspect of this option is that the issuer will have committed the cards to symmetric cryptography to protect application loading for the remainder of the cards' life cycle. Under the current symmetric-key loading scheme no change to the application- loading scheme is possible. Symmetric-key loading is described herein below in

conjunction with Figure 2.

[0011] Conversely, if an issuer intends to perform multi-party secure post-issuance application loading, i.e., enabling secure loading of applications from third-party service providers as well as from the issuer, the issuer may select to use the asymmetric-key crypto application loading scheme. The asymmetric-key loading technology is more powerful. Each smartcard has associated therewith its own unique key pair; a private key and a public key. Applications to be loaded onto the smartcard are encrypted into an Application Load Unit (ALU) using the public key of the smartcard, and the smartcard then decrypts the applications from the ALU by using its private key prior to loading the application. Asymmetric-key loading is described herein below in conjunction with Figure 1.

[0012] Thus, when compared to symmetric-key loading, asymmetric-key loading provides more powerful mechanisms for multi-party application loading. Circumstances may occur in which an issuer may have reasons to make application loading onto a smartcard that was initially configured as a symmetric-key loading card available to third parties. Application loading by third parties is preferably performed using asymmetric-key loading, thus resulting in the need for a method to enable asymmetric-key application loading on smartcards configured for symmetric-key application loading.

[0013] From the foregoing it will be apparent that there is still a need for an improved method to provide for asymmetric-key loading of applications on smartcards that are initially configured for symmetric-key loading of applications.

[0014] In particular, there is a need for an improved method to provide for asymmetric- key loading of applications on smartcards that are initially configured for symmetric-key loading of applications and not initially configured for asymmetric-key loading of applications.

[0015] International patent application WO 98/52163 A2 describes a method and apparatus for transporting application programs onto an IC card from a source located outside the card. A secret key and public key pair is stored on the card. The application provider sends an application load unit (ALU) to the card. The ALU includes an application unit (AU) and a key transformation unit (KTU). The AU contains both the program code and associated data which is to be loaded onto the card of the card user. In an example, discrete areas of the AU are encrypted using single and triple DES techniques. The KTU contains information relating to the encryption of the AU (the code and data of the application) which allows the card to decrypt the designated portions so that the application and data can be accessed by the card but protects the data during transmission between the application provider and the card. The KTU is encrypted with the public key of the card for which the application is intended which ensures that only the intended card can decrypt the application code and data using the KTU information.

SUMMARY

[0016] A smartcard may be initially configured for symmetric key cryptographic loading of applications. A mechanism is provided for enabling secure loading of applications from third-party service providers as well as from the issuer. In particular, the mechanism may enable symmetric-key application-loading smartcards to function in asymmetric-key application-loading mechanisms. Once asymmetric-key application- loading is enabled the smartcard may use asymmetric loading mechanisms rather than the original symmetric loading mechanisms. This mechanism affords both functional and cost- saving advantages to card issuers in that it allows for greater flexibility in issuing cards. In particular, it allows card issuers to initially configure smartcards using the symmetric-key application-loading mechanisms without being locked into that mechanism for the life of the smartcard. The symmetric key may be stored on the smartcard and also known or derivable by a key management authority. Thus, card issuers are able to avoid issuing smartcards with asymmetric-key application loading when that functionality is not known to be necessary.

[0017] According to a first aspect, there is provided a method for replacing the cryptographic loading mechanism of a smartcard after the smartcard has been enabled and personalized, including after issuance, the smartcard having been assigned a symmetric key that is stored on the smartcard, the method comprising: operating the card- issuer client-computer to request a key management authority to issue an asymmetric

cryptography key-pair comprising a private key and a public key certificate associated with the smartcard; operating a server-computer of the key management authority to generate the requested asymmetric cryptography key-pair and encrypting the asymmetric cryptography key-pair using the symmetric key assigned to the smartcard into an encrypted key-pair packet; transmitting the encrypted key-pair packet to the card- issuer; transmitting the encrypted asymmetric cryptography key-pair packet to the smartcard; and storing the private key of the asymmetric cryptography key-pair on the smartcard, thereby enabling the smartcard to use asymmetric loading mechanisms in addition to or instead of the original symmetric loading mechanisms. The method may comprise the steps of assigning a symmetric key to the smartcard and storing the symmetric key on the smartcard.

[0018] According to a further aspect there is provided a smartcard that is operable for symmetric-key application- loading and not, in an initial state, operable for asymmetric-key application loading, comprising: a card ID and a symmetric key stored in non-volatile memory of the smartcard; and instructions, stored in non- volatile memory of the smartcard, containing instructions to cause a processor of the smartcard to: receive a packet encrypted with the symmetric key purporting to contain an asymmetric-key pair, having a private key and a public key, for loading applications onto the smartcard; upon receiving the packet, decrypting the packet using the symmetric key; and storing the asymmetric-key pair private key for subsequent use in decrypting application load units received for loading on the smartcard.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a high-level message flow diagram illustrating the mechanism of loading applications onto a smartcard using the asymmetric-key application-loading mechanism.

[0019] Figure 2 is a high-level message flow diagram illustrating the mechanism of loading applications onto a smartcard using the symmetric-key application-loading mechanism.

[0020] Figure 3 is a top-view of an integrated circuit card 101, for example, a smartcard.

[0021] Figure 4 is a schematic illustration of the hardware architecture of an integrated circuit card 101, specifically, the chip-module 105 of an integrated circuit card 101.

[0022] Figure 5 is a schematic illustration of computer programs and data, such as cryptographic keys, loaded onto a symmetric-key application-loading integrated circuit card. [0023] Figure 6 is a timing sequence diagram illustrating one exemplary flow for enhancing a symmetric-key application-loading integrated circuit card to support application loading using the asymmetric-key application-loading mechanism of Figure 1.

[0024] Figure 7 is a schematic illustration of computer programs and data of the symmetric-key application- loading smartcard of Figure 5 enabled for use with asymmetric- key application-loading mechanisms.

[0025] Figure 8 is a block diagram of the key management authority server computer extended to support the mechanism for enabling asymmetric-key application loading of smartcards using the mechanism of Figure 6.

DETAILED DESCRIPTION

[0026] In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various

embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0027] Herein we use the apostrophe character to indicate a variation from the generic version of an element carrying the same base number. Thus, for example, 101 ' is a variation of the integrated circuit card 101. If a letter follows a reference numeral, e.g., 101a, the letter refers to a particular member of a class or may be a variable (e.g., i or x) which can stand for any member of the class. Thus integrated circuit card 101a is one particular integrated circuit card 101.

[0028] In one embodiment of the invention, a mechanism is provided for enabling symmetric-key application- loading smartcards to function in asymmetric-key application- loading mechanisms. This mechanism allows card issuers to initially configure smartcards using the symmetric-key application-loading mechanisms without being locked into that mechanism for the life of the smartcard. Thus, card issuers are able to avoid issuing smartcards with asymmetric-key application loading when that functionality is not known to be necessary.

[0029] Figure 1 is a schematic illustrating message flow for loading and deleting of applications in an asymmetric-key application-loading mechanism for loading of third party applications onto an integrated circuit card 101. One implementation of asymmetric- key application loading is Multos. The Multos version of asymmetric-key application loading is described in Multos GLDA, Guide to Loading and Deleting, Mao-doc-tec-008 v2.24, www.multos.com/uploads/GLDA.pdf, accessed on April 20, 2014, incorporated herein by reference in its entirety. Using the asymmetric application-loading scheme, as illustrated in Figure 1, a card issuer 123 may control creation and customization of an issued integrated circuit card 101, with modifications to the card being possible throughout the life cycle of the card including pre- through post-issuance. Applications that execute on the integrated circuit card may be downloaded securely anytime and anywhere, including over unsecure networks.

[0030] In asymmetric key application loading, the security of the loading and deletion of applications is provided for by associating an asymmetric key pair with each integrated circuit card 101.

[0031] In addition to the integrated circuit card 101, there are five other entities involved in the loading of applications onto the integrated circuit card 101 : the application provider 121, the card issuer 123, the key management authority 125 (which in the case of Multos is referred to as the Multos Certificate Authority), the application load unit generator 127 and the application load facility 129.

[0032] While entities such as card issuer 123, application provider 121, and key management authority 125 are referred to using functional terms, it must be realized that these functionalities are performed by computer systems having processors and memory or storage devices that include instructions to direct such processors to perform the actions performed by the entities. Thus, unless explicitly stated otherwise, "card issuer 123", "application provider 121", "key management authority 125", "application load unit generator 127", and "application load facility 129" - as well as analogous elements described herein below - refer both to the entities that perform these functions, and, particularly, to the computers that are operated by such entities.

[0033] Each individual integrated circuit card 101 has associated therewith:

• a unique card identifier

• an issuer identifier

[0034] Additionally, an integrated circuit card 101 may have associated therewith a symmetric key, which may be known or derivable by the key management authority 125.

[0035] In asymmetric key application loading, the security of the loading and deletion of applications is provided for by associating an asymmetric key pair with each integrated circuit card 101. Thus, for cards provisioned for asymmetric-key application loading, the integrated circuit card 101 also contains the private key of the integrated circuit card 101.

[0036] In order to load an application onto the integrated circuit card 101, an application must first be created. In the illustration of Figure 1, the application provider 121 creates the application that is to be loaded. To be allowed to load an application onto an integrated circuit card 101, that application must be approved by the card issuer 123. However, it is not necessary for the application provider 121 to provide the application itself to the card issuer 123. Rather, the application provider 121 sends to the card issuer 123 an application header together with the public key of the application provider 121, step 131.

[0037] The application provider 121 provides the application to be loaded to an application load unit generator 127, which together with card public keys 137 obtained from the key management authority 125 via the card issuer 123, builds application load units (ALU) 139.

[0038] The card issuer 123 coordinates the loading of the application on the integrated circuit card 101. Having received the public key of the application provider 121 and the application header, the card issuer 123 then provides this information to the key management authority 125, step 133, together with card identifiers 135 for cards to which it wants to load the application. The key management authority 125 provides the card issuer 123 with enablement data, i.e., public keys 137 for the cards corresponding to the card identifiers provided by the card issuer 123, and an application load certificate 139. The application load certificate is a digital certificate, signed by the key management authority 125, which verifies that the card issuer has authorized the loading of the application. The application load certificate 139 contains the application identifier, issuer identifier, and a mechanism for identifying the cards onto which the application may be loaded, for example, by listing the card identifiers or providing a range of card identifiers.

[0039] The card issuer 123 forwards the public keys 137 for the target integrated circuit card 101 to the application load unit generator 127. An application load unit 139 contains the code and data of the application to be loaded and is encrypted using the public key of the target integrated circuit card 101. The application load unit 139 is forwarded to the application load facility 129.

[0040] The application load facility 129 receives the application load unit 139 and verifies that there is an application load certificate 139 that confirms the authorization to load the application onto the target integrated circuit card 101. If so, the application is loaded onto the integrated circuit card 101. Since the ALU 139 has been encrypted using the public key of the integrated circuit card 101, the integrated circuit card 101 may decrypt the ALU, extract the application and load it.

[0041] As may be appreciated from the foregoing discussion of the asymmetric key application loading mechanism, in order for the mechanism to work an integrated circuit card 101 must be provisioned to participate in the mechanism by having a public key that may be used for encrypting and decrypting the ALUs that are to be loaded on the integrated circuit card 101.

[0042] Figure 2 illustrates the symmetric key application-loading mechanism. The period beginning with the manufacturing of a smartcard and ending with the eventual termination of services associated with the smartcard is often referred to as the smartcard life cycle. The smartcard life cycle contains several phases: manufacturing, enablement, personalization, issuance, use, and destruction or termination. Figure 2 is an illustration of two phases of a symmetric-key application- loading smartcard: (1) manufacturing and enablement and (2) post-issuance application loading.

[0043] There are many facets to card manufacturing 251, e.g., placement of a chip and connectors into a plastic substrate, however, these are outside the scope of this discussion. Typically, during manufacturing 251 cards are assigned Card IDs 253. After

manufacturing 251, cards are provided to a card issuer 123'. The card issuer 123, performs actions of the personalization and enablement phase 255. During card personalization or card enablement 255, each card is assigned, for example, by the card issuer 123', a unique symmetric key SKa 257 used for loading applications onto the card. Thus, after the personalization and enablement phase 255, the card 101 ' has been assigned a Card ID and a card specific symmetric key (SKa).

[0044] Certain tasks relating to the management of the card issuer's issued smartcards 101 ' are performed by a control center program 256.

[0045] The card issuer computer 123' stores the symmetric keys and card IDs 259 for smartcards 101 ' issued by the card issuer 123', for example, as data managed by the control center program 256.

[0046] During the application loading phase, an application is created and provided, for example, by an application provider 121 '. The application provider creates 138 an application load unit (ALU) 139 and transmits it to the card issuer 123'. There are many possible variations on this that all fit within the scope of this discussion; for example, the application provider 121 ' and the card issuer 123' may be the same entity. If not, typically there would be a trust relationship between the the application provider 121 ' and the card issuer 123'.

[0047] The card issuer 123' encrypts the ALU with the symmetric key of the target card onto which the application is to be loaded and provides the encrypted ALU 261 to the smartcard 101 '. The card issuer 123' also provides a signed application load certificate 263 which verifies that the issuer has approved of the loading of the application in the provided ALU 139/261.

[0048] The card 101 ' verifies the ALC 263 and upon successful verification, decrypts the encrypted load unit 261 to extract the ALU 139, and load the application contained in the ALU 139.

[0049] In an alternative embodiment (illustrated with the dashed line in Figure 2), the application provider 121, being in a trust relationship with the card issuer 123', has been provided by the card issuer 123' with the symmetric keys/card IDs database 259 and encrypts the ALU and provides it directly to the smartcard 101 '.

[0050] To enhance security of the mechanism of Figure 2, additional symmetric keys may be used. [0051] Figure 3 is a top-view of an integrated circuit card 101, for example, a smartcard. Briefly, a manufacturer may provide the integrated circuit card 101 in a bulk form; that is without personalization features identifying an issuer, e.g., a bank, or the customer to which the card is provided. In its pre-personalization form, the integrated circuit card 101 typically encompasses a plastic substrate 102 on which an image area 103 is provided. The integrated circuit card further includes an embedded integrated circuit card chip 105, which is typically connected to a contact pad 107. In alternative

embodiments, the integrated circuit card chip may connect to external readers using connectors such as Universal Serial Bus (USB) connectors or wirelessly using techniques such as near- field communication (NFC) or radio -frequency identification (RFID) protocols.

[0052] During personalization of the integrated circuit card 101, physical identifying information may be added to the card, e.g., the issuer's logo 201, a photograph 203 of the customer to which the integrated circuit card is issued, and the customer's name 207. While these are mere visual manifestations of the personal nature of the integrated circuit card 101, they are indicative of the personal nature of each individual card. The issuer also personalizes the specific integrated circuit card 101 assigned to a customer by storing information pertinent to that customer and with applications that the user can execute using the card 101 in non- volatile memory of the card. For example, the cryptographic keys associated with loading applications may be stored on the card 101 during card

personalization.

[0053] Figure 4 is a schematic illustration of the hardware architecture of an integrated circuit card 101, specifically, the chip-module 105 of an integrated circuit card 101. The chip-module 105 may include a processor 301 connected via a bus 302 to a random access memory (RAM) 303, a read-only memory (ROM) 304, and a non-volatile memory (NVM) 305. The chip-module 105 further includes an input/output interface 307 for connecting the processor 301, again typically via the bus 302, to the connector 107 by which the integrated circuit card 101 may be connected to a card reader. As noted above, the integrated circuit may alternatively connect to the outside world wirelessly and would in such embodiments typically include an antenna rather than the connector 107.

[0054] The ROM 304 may or may not be present. Herein is described a technology in which much of the functionality that has hitherto been placed in ROM is now located in the NVM 305. However, that does not preclude that the integrated circuit card 101 has a ROM for some other purpose.

[0055] Figure 5 is a schematic illustration of computer programs 401 loaded onto a symmetric-key application- loading integrated circuit card 101 ' as well as data such as cryptographic keys supporting symmetric-key application loading. The NVM 305 may include computer programs 401 as is illustrated in Figure 5. While it is here depicted that the computer programs 401 are all co-located in the NVM 305, in actual practice there is no such restriction as programs may be spread out over multiple memories and even temporarily installed in RAM 303. Furthermore, the symmetric-key application- loading integrated circuit card 101 ' may include multiple NVMs. The programs 401 include operating system programs as well as application programs loaded on to the integrated circuit card 101.

[0056] The symmetric-key application- loading integrated circuit card 101 ' programs 401 may include the operating system OS 219 as well as other system programs 213a, e.g., cryptography, user authentication, and communications modules. The system programs 213a may include functionality of the symmetric-key application- loading integrated circuit card 101 ' required to perform the methods described herein.

[0057] The symmetric-key application- loading integrated circuit card 101 ' programs 401 may further include one or more applications 221 (e.g., 221a and 221b) for causing the integrated circuit card 101 to perform various tasks associated with the integrated circuit card 101.

[0058] The applications 221 may be loaded onto the symmetric-key application- loading integrated circuit card 101 ' when the issuer personalizes the symmetric-key application- loading integrated circuit card 101 ' for a specific customer. Applications 221 may also be loaded after personalization onto the smartcard using symmetric-key loading as discussed in conjunction with Figure 2. As will be discussed in greater detail herein below, according to a preferred embodiment, the symmetric-key application-loading integrated circuit card 101 ' may be extended to support asymmetric-key loading of applications.

[0059] To support loading of applications using the symmetric-key application loading mechanism of Figure 2, the NVM 305 may contain an application loader 227. [0060] The personalization stage, introduced in conjunction with Figure 3, further includes personalizing the electronics of the integrated circuit card 101 by loading the applications 221 that are appropriate for the particular customer to which the integrated circuit card 101 is to be issued. That personalization further includes storing a customer's personal information 225 in the NVM 305. Such personal information 225 may include account details, cryptography keys, and customer identifying data. Notably, the smartcard 101 in NVM 305, for example, includes a symmetric key 229 (herein below, referred to as SKi (i being an index for the card)) that may be used to decrypt application load units created for use with the symmetric-key application-loading mechanism of Figure 2.

[0061] As discussed herein above, it is only possible to use an integrated circuit card 101 with the asymmetric-key application- loading mechanism, e.g., as discussed in conjunction with Figure 1, if the integrated circuit card 101 is provisioned for participating in that mechanism. In many cases, integrated circuit cards 101 are only provisioned for use with symmetric key application loading.

[0062] Figure 6 is a timing sequence diagram illustrating one exemplary flow for enhancing a symmetric-key application- loading integrated circuit card 101 ' to support application loading using the asymmetric-key application- loading mechanism of Figure 1.

[0063] The mechanism of Figure 6 involves three entities, a symmetric-key application- loading integrated circuit card 101 ', a card issuer 123', and a key management authority 125 '. As a symmetric-key application- loading integrated circuit card 101 ' (CARDa), the integrated circuit card 101 ' has associated therewith a unique Card ID, a symmetric key (SKa), and an Issuer ID. The card issuer 123' has associated therewith an Issuer ID and a list of Card IDs for cards that the card issuer 123' has issued or may issue.

[0064] The key management authority 125' has associated therewith a High-level Symmetric Key (HSK). The HSK may be used by the key management authority to derive the symmetric key (SKa) for any given card based on the Card ID of that card.

[0065] When a card issuer 123' wishes to enable a card or a set of symmetric-key application- loading cards for asymmetric-key application loading, the card issuer 123' transmits a request to do so including the Card ID for the card that it wishes to enable for asymmetric-key application- loading, step 601. Figure 6 illustrates the enablement of one card. However, if multiple cards of a set are to be enabled for asymmetric-key application loading, the steps are repeated for each such card in the set. [0066] The key management authority 125' derives the symmetric key associated with that card, step 603, from the card ID. The symmetric key is, for example, a function of the high-level symmetric key stored by the key management authority 125' and the Card ID associated with the card 101 for which the symmetric key is to be derived.

[0067] The key management authority 125' creates an asymmetric key pair including a public key certificate signed by the KMA 125' and a private key to be associated with the card to be enabled and creates a packet that includes the key pair and other identifying information such as Issuer ID or Card ID for the card to be enabled, step 605.

[0068] The key management authority 125' encrypts the packet that includes the asymmetric key pair and transmits to the card issuer 123' the packet and other metadata including the Card ID and the public key certificate of the card 101 ', step 607.

[0069] When the card issuer 123' receives the packet and meta data from the key management authority 125 ', the card issuer 123' stores the asymmetric public key certificate and the Card ID associated with the public key, step 609, so that it may in the future use the card ID when loading an application onto a particular card, for example, as seen in Figure 1 in which the card issuer 123' transmits the card public key certificates 137 of cards to which applications are to be loaded to an application load unit generator 127.

[0070] Further, the card issuer 123' transmits the encrypted packet to the card 101 ', step 611.

[0071] The integrated circuit card 101 ', as noted above, stores a symmetric key SKa that is associated with the card by Card ID. Using the symmetric key, the integrated circuit card 101 decrypts the Packet, step 613.

[0072] To ensure that the packet has not been corrupted or manipulated in transit, the card checks a digest or checksum that verifies the integrity of the packet, step 615.

[0073] The integrated circuit card 101 next extracts the Issuer ID and verifies that the received issuer ID matches the Issuer ID that the card stores, step 617.

[0074] Having verified the digest or checksum (step 615) and the issuer (step 617), the integrated circuit card 101 ' extracts the asymmetric private key from the packet and stores it for use in the asymmetric-key application-loading mechanism (as described above in conjunction with Figure 1), step 619. [0075] At the conclusion of the process associated with the timing sequence diagram of Figure 6, the integrated circuit card 101 ' has been enabled to participate in the asymmetric-key loading of applications thereby allowing an issuer to flexibly and economically upgrade a card that originally was deployed solely as a symmetric-key application-loading card to a much more powerful asymmetric-key application-loading card.

[0076] In a preferred embodiment, the steps 613 through 619 of Figure 6 are performed by a processor of the smartcard 101 ' executing instructions stored as part of the systems programs 213a of Figure 5 or as an application 221 loaded using the symmetric- key application loading scheme of Figure 2.

[0077] Figure 7 is a revisit of the a schematic illustration of computer programs 401 loaded onto a symmetric-key application- loading integrated circuit card 101 ' previously illustrated in Figure 5; namely, in Figure 7, the non- volatile memory illustrated in Figure 5 has been updated using the procedure of Figure 6 and therefore now includes an asymmetric-key 701, which was extracted and stored in step 619.

[0078] In embodiments described herein above, a symmetric-key application-loading smartcard is enabled for asymmetric loading of applications. In an alternative embodiment, after card manufacturing, a smartcard 101 is not committed to any application loading mechanism. During enablement, the card issuer either provides for asymmetric-key application loading as discussed in conjunction with Figure 1 or for symmetric-key application loading as discussed in conjunction with Figure 2. Such a symmetric-key application-loading smartcard may then be enabled for asymmetric-key application loading, as discussed herein above, or remain as a symmetric-key application- loading card. Furthermore, the card may be locked from being transformed to an asymmetric-key application-loading card.

[0079] Figure 8 is a block diagram of the key management authority server computer 125' extended to support the mechanism for enabling asymmetric-key application loading of smartcards using the mechanism of Figure 6. The KMA server computer 125' includes a processor 801 and a memory 803. The memory 803, which may be a hard disk, nonvolatile memory or the like, includes computer instructions and data 807 to allow the processor 801 to perform the steps of Figure 6 assigned to the key management authority 125' to enable a smartcard to participate in asymmetric-key application loading. The key management authority server computer 125' further includes a communications mechanism 805 to allow the key management authority server computer 125' to communicate with other network nodes to send and receive messages, for example, as set forth in Figure 6. The computer instructions and data 807 include the high-level symmetric key 809 used to derive the symmetric key of smartcards based on Card ID, the instructions 811 to derive the symmetric key based on Card ID, and cryptography functions including the mechanism 813 to generate and sign asymmetric key-pairs, and the mechanism 815 to encrypt the key-pairs using symmetric key cryptography.

[0080] From the foregoing it will be apparent that the herein described technology affords both functional and cost-saving advantages to card issuers in that it allows for greater flexibility in issuing cards. Specifically, cards may be issued using the symmetric- key application-loading mechanism without the fear that it will not be possible to later use such cards using the much more powerful asymmetric-key application-loading mechanism.

[0081] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.