A computer-implemented method of setting up a virtual card on a computing device

Abstract

A computer-implemented method of setting up a virtual card on a computing device is presented, in particular, a method of remotely digitizing and updating a virtual card independent of a simulation environment.

Description

Technical Field

[0001] This invention relates to a method and a system. Specifically, but not exclusively, this invention relates to a computer-implemented method and system. Furthermore, specifically, but not exclusively, this invention relates to an object-based method for digitizing and updating virtual cards on a mobile device in a secure element or host card emulation environment according to a uniform process. Background Technology

[0002] Virtual cards provide a digital representation of smart cards and are typically implemented via computing devices in conjunction with applications that implement, for example, contactless payments or access controls.

[0003] Virtual cards typically require an emulation environment to function because they enable the virtualization of smart cards. Various emulation environments exist, such as embedded secure element and host card emulation environments.

[0004] Virtual cards are managed over the air in the emulation environment. Over-the-air management of virtual cards includes card setup and updates. Over-the-air virtual card updates are required to maintain functionality and security. Alternatively, card updates can be performed via a contactless interface within the emulation environment.

[0005] Various aspects and implementation methods were conceived with the foregoing in mind. Summary of the Invention

[0006] This involves various aspects related to the setup and updates of virtual cards associated with applications implemented by computing devices.

[0007] From a first perspective, a computer-implemented method for setting up a virtual card on a computing device can be provided. Setting up a virtual card may correspond to generating an instance of a virtual card, which is implemented on the computing device using an emulation environment. The virtual card may be associated with an application executed by the computing device. For example, the application may be a digital wallet. The method can be implemented by processing resources. Examples of such processing resources may be application modules (e.g., device applications) that provide the processing, hardware, and software resources required to implement the setting up of the virtual card on the computing device. Examples of such computing devices may be mobile computing devices.

[0008] The method may include providing a request to a card management server for a virtual card associated with an application. An example of a card management server may be a card management service backend that generates setup and update data to manage virtual cards over the air. The card management server is a resource configured to receive requests from a computing device and generate the data required for the computing device to emulate the virtual card. The card management server may also include one or more hardware and software resources required to perform authentication and verification of the emulation environment upon receiving a request.

[0009] The request may include cryptographic data that identifies the emulation environment used to implement the virtual card on the computing device. This cryptographic data may include one or more cryptographic assets, such as a certificate chain and / or one or more public keys. The request can be submitted to the card management server using an environment-independent path.

[0010] One or more secret-sharing methods can be used in an emulation environment on an authentication card management server. These methods can be used to authenticate and encrypt card objects by the emulation environment or the card management server. This may involve sharing one or more digital certificates, certificate chains, or public keys.

[0011] An environment-independent path means that the data corresponding to the request is transmitted between the emulation environment and the card management server via a route independent of the emulation environment in which the virtual card will be implemented.

[0012] The method may further include receiving a card object corresponding to a virtual card from a card management server, wherein the card object is received using an environment-independent path. The card object may include one or more of the following: metadata for managing the virtual card (e.g., data identifying the emulation environment used to implement the virtual card), cryptographic assets for establishing a transmission session key, a data model of the card, card data, and a card key encrypted and signed using the transmission session key. The transmission session key is specifically set up to be shared between the emulation environment of the virtual card and the card management server. The transmission session key transmitted between the card emulation and the card management server, and between the card management server and the card emulation, is different for each card object. The transmission session key encrypts and signs the card object, excluding the card metadata.

[0013] The method may include importing a card object into a simulation environment. Importing may deploy one or more import Application Protocol Data Units (APDUs). APDUs are generated by an application module. APDUs are independent of the card data model, card data, and card key. The method may also include generating instances of virtual cards in the simulation environment. This may include generating a transmission session key, authenticating and decrypting card data and card key, and subsequently creating and setting up instances of virtual cards.

[0014] The method according to the first aspect unifies the process of setting up and digitizing virtual cards on computing devices (e.g., mobile computing devices) and provides a setup process independent of the simulation environment. The method unifies communication between all involved components (e.g., backend servers). This also means that the card backend server does not require separate logic for each simulation environment, thereby improving system maintainability and robustness.

[0015] Optionally, environment-independent paths include one or more components that are independent of the simulation environment. That is, the application programming interfaces (APIs) of these components do not depend on the simulation environment.

[0016] Optionally, the card object includes one or more of the following: metadata identifying the emulation environment implementing the virtual card; transmission session key generation data for establishing the transmission session key; the card's data model; card data; and the card key.

[0017] Optionally, a transmission session key can be used to encrypt one or more of the card data and card keys. The transmission session key can be determined by a cryptographic asset provided by a card management server and an emulation environment.

[0018] Optionally, the generation of an instance of a virtual card may include generating a transmission session key by generating data using a transmission session key and decrypting card data and card key using the transmission session key.

[0019] Optionally, the card data and card key are encrypted with a transmission session key and signed with a signature generated using the transmission session key.

[0020] Alternatively, the simulation environment can be either a host card emulation or a security element.

[0021] From a second perspective, a computer-implemented method for updating a virtual card on a computing device can be provided. The virtual card is configured according to the first aspect. The method is implemented by processing resources, which can be described as application modules or device applications. The processing resources can be used to implement applications associated with the virtual card.

[0022] The method may include initiating a card update process. The card update process may be initiated by processing resources. This may be in response to user input. This may be in response to a request from a card management server. This may include allocating one or more hardware and / or software resources required to implement the card update process. The method may also include obtaining a card object from an emulation environment associated with the application. The card object may include cryptographic assets associated with the emulation environment. The cryptographic assets may include data that can be used to establish a transmission session key, which can be used to encrypt card data and a card key. The transmission session key can also be used to sign the card data and the card key. The method may also send the card object along with a request for an updated card object to the card management server. An environment-independent path may be used to send the card object. An environment-independent path may mean that data corresponding to the request is transmitted between the emulation environment and the card management server via a route independent of the emulation environment to which the virtual card will be implemented. The card management server may be the card management server of the first aspect. The method may also include receiving an updated card object from the card management server via an environment-independent path. The method may also include using the updated card object to update the virtual card.

[0023] The method according to the second aspect unifies the process of updating virtual cards on computing devices (e.g., mobile computing devices) and provides an update process independent of the simulation environment. The method unifies communication between all involved components (e.g., backend servers). This also means that the card backend server does not require separate logic for each simulation environment, thereby improving system maintainability.

[0024] Optionally, the method further includes verifying the update and transmitting a verification notification to the card management server in response to updating the virtual card with the updated card object.

[0025] Optionally, the cryptographic assets may include at least one of the following: data used to establish a session key; card data; a cryptographic key associated with a virtual card; or a cryptographic key that is encrypted and signed using a transmission session key associated with an emulation environment.

[0026] Alternatively, the simulation environment is at least one of an embedded security element or a host card emulation.

[0027] Optionally, obtaining the card object from the simulation environment includes publishing a command application protocol data unit (APDU) that identifies the card object to the simulation environment, and receiving a response application data unit (APDU) containing the card object. The APDU may be referred to as an exported APDU.

[0028] Optionally, a request for an updated card object may include a call to an application programming interface that is independent of the simulation environment.

[0029] Optionally, updating the virtual card using the updated card object includes:

[0030] Receive updated card objects; and

[0031] Import the updated card object into the simulation environment.

[0032] Optionally, importing a virtual card object into the simulation environment includes the application module publishing an APDU containing the card object, which may be referred to as an import APDU.

[0033] Optionally, updating a virtual card may include one or more of the following: generating a transmission session key; using the transmission session key to decrypt at least one card key and card data received from a card management server; and setting up an instance of the updated card in the simulation environment based on the authenticated card data and card key, and the decrypted at least one card key and card data.

[0034] Optionally, cryptographic assets may include one or more of the following: nature data identifying the emulation environment; and / or a certificate chain used by the card management server to authenticate the emulation environment.

[0035] Optionally, the base key calculated by the card management service can be generated based on the public key associated with the card in the emulation environment and the private key associated with the card management service backend. The transmission session key is derived from the base key using a key derivation function. The base key is different for each virtual card. The key derivation function can be based on the HMAC function, where the session key is equal to HMAC(base key, SDR), where the SDR is different for each card object and is generated by the component that creates the card object.

[0036] Optionally, the base key calculated by the simulation environment can be generated based on the public key associated with the card in the card management service backend and the private key associated with the simulation environment. The transmission session key is derived from the base key using a key derivation function. The key derivation function can be based on the HMAC function, where the session key is equal to HMAC(base key, SDR), where the SDR is different for each card object and is generated by the component that generates the card object.

[0037] Optionally, the update card object can be certified by the simulation environment.

[0038] Alternatively, authentication may be based on one or more of the following: a certificate chain provided by the management server; and a public key associated with the card management server.

[0039] Optionally, the card object may include at least one of the following: card key and user data; certificate chain; or at least one randomized derived number for deriving the transmission session key.

[0040] The aspects may also relate to a non-transitory computer-readable storage medium having executable instructions stored thereon, the executable instructions causing the computer system to perform at least the method according to either the first or second aspect when executed by a processor of the computer system.

[0041] The aspects may also involve a system configured to implement the method according to either the first or the second aspect.

[0042] The aspects may also relate to a processing resource including a processor and a memory, the memory including executable instructions that, due to execution by the processor, cause a reader to perform a method according to either the first or second aspect. Attached Figure Description

[0043] The embodiments will now be described by way of example only and with reference to the following figures, in which:

[0044] Figure 1a A series of steps are shown as part of a method that can be used to create digital virtual cards;

[0045] Figure 1bA series of steps are shown as part of a method that can be used to update a virtual card associated with an application on a computing device;

[0046] Figure 2 A computing device configured to utilize a virtual card is shown, which can be updated according to an embodiment;

[0047] Figure 3 A schematic diagram illustrating the relationship between a computing device and a card management server according to an embodiment is provided;

[0048] Figure 4 The relationship between the certificate authority to be used, the service backend, and the simulation environment according to an embodiment is illustrated.

[0049] Figure 5 This illustrates an example of key management in the card management service backend;

[0050] Figure 6 The key management in the simulation environment is shown; and

[0051] Figure 7a and 7b This illustrates key management within a Certificate Authority. Detailed Implementation

[0052] Reference Figure 1a A method 100a is described for digitizing a virtual card on a computing device 200. The computing device 200 operates an application module 212, which enables the computing device 200 to implement specific functionalities, allowing a user of the device to use these specific functionalities. These specific functionalities may, for example, be used to facilitate financial transactions, access control, or transportation ticketing.

[0053] The following text is for reference only. Figure 1a The card setup process is described. A signature service is installed on the emulation environment 206 and application module 212. The signature service can be the same for both emulation environment 206 and application module 212. The emulation environment 206 is also configured to generate cryptographic keys using, for example, elliptic curve cryptography, and in practice, uses, for example, elliptic curve cryptography (ECC) to generate key pairs.

[0054] The key pair is called Application.ECKA, and it is generated for each virtual card 202 implemented using the emulation environment 206. The public key portion of this key pair is embedded in a certificate signed by a signature service.

[0055] Prior to step S100, the digital certificate (CERT.SIGN.AUT) is signed using a signature generated by a signature service. The signature service has a key pair (i.e., a private key and a public key) generated using, for example, elliptic curve cryptography. A public key is generated for application module 212.

[0056] In step S100, application module 212 initiates the card setup process. That is, application module 212 requests the data required to generate a virtual card on computing device 200. A virtual card is needed to implement the functionality associated with the application provided by application module 212. Application module 212 retrieves data identifying whether card emulation environment 206 is an embedded secure element (SE) or a host card emulation (HCE). Application module 212 also retrieves data indicating the type of emulation environment available on the computing device (e.g., emulation properties), including its properties such as the spare processing capacity of the corresponding card emulation environment, which may include the remaining available memory on the corresponding card emulation environment. The retrieved data is embedded by application module 212 in a device application property object. The device application property object may be a JSON object. The device application property object also includes cryptographic assets, such as certificate chains (CERT.Application.ECKA and CERT.SIGN.AUT). This is used to verify emulation environment 206. In step S102, the device application property object, along with the request for the data required to generate the virtual card, is transmitted to card management service backend 208. The requested transmission can be implemented using a suitable over-the-air (OTA) protocol, such as wireless internet or cellular networks.

[0057] The card management service backend 208 also utilizes a signature service to generate digital certificates and authorization certificates signed by a Certificate Authority (CA).

[0058] In step S104, the card management service backend 208 retrieves data from the identification card emulation environment 206 upon receiving a request and a device application nature object. The card management service backend 208 uses cryptographic assets (e.g., a certificate chain) to verify the emulation environment 206. The application public key (Application.ECKA public key) is combined with the card.ECKA private key (virtual card private key) using an ECC key negotiation algorithm or another suitable technique to generate a transmission base key. The transmission base key is then stored in a database at the card management service backend 208 and used to derive a transmission session key (using standard techniques) to encrypt / decrypt card data and to encrypt / decrypt the cryptographic key generated for the card object to be created.

[0059] The card management service backend 208 generates a card object corresponding to the corresponding card emulation environment 206. The card object can be implemented as a JSON object.

[0060] The resulting card object contains metadata associated with the target emulation environment (i.e., the emulation environment identified in the device application nature object), a public key (or other cryptographic data or cryptographic assets) required to establish the first transmission session key (transmission session key generation data), a virtual card data model (i.e., data indicating how the card data should be organized when implemented in the emulation environment), card data, and a card key (encrypted and signed with the transmission session key by the card management service backend 208). A cryptographic key is generated for each virtual card 202, and the public key is embedded in a certificate signed with the permission.AUT private key.

[0061] In step S106, the card management service backend 108 sends the card object to the application module 212. This can be done using OTA delivery methods, such as wireless internet or cellular transmission. However, any suitable data transmission method can be used. Any APIs used during transmission are independent of the emulation environment 206; that is, they can be used in either the SE or HCE emulation environment.

[0062] In step S108, application module 212 imports the card object received from card management service backend 108 into the corresponding simulation environment 206, i.e., the simulation environment 206 indicated by the metadata within the card object. When the simulation environment is SE, the import of the card object uses the Import Application Protocol Data Unit (APDU) according to ISO / IEC 7816-4. To import the card object from the HCE simulation environment, an API implemented by application module 212 is required. The card object is only decrypted / encrypted within simulation environment 206. Outside of the simulation environment and card management service backend, the card object is always encrypted and never transmitted in plaintext.

[0063] In step S110, the corresponding simulation environment 206 then uses the transmission base key to generate a transmission session key. This transmission session key is then used to authenticate and decrypt card data and a password key, which is encrypted by the card management service backend 208 using the transmission session key.

[0064] In step S112, the corresponding simulation environment 206 then uses the card data and password key to create and set up an instance of the virtual card 202. The card data and password key can be stored in the local storage device of the corresponding simulation environment.

[0065] In other words, steps S100 to S112 are used to set up the virtual card in a manner independent of the emulation environment 206 that will be used to implement the virtual card 202. By using the same process, the user experience when obtaining a virtual card used by the corresponding application will be improved, and the complexity of the card setup process will be reduced.

[0066] Reference Figures 1b to 7aSection 7b describes a method for remotely updating a virtual card 202 using application module 212, the virtual card 202 being associated with an application running on computing device 200. That is, application module 212 runs a specific application on the computing device. The application may provide one or more functional software applications for use with computing device 200. It may, for example, be used to facilitate financial transactions, access control, or transportation ticketing.

[0067] As will be shown, the method provides a way to remotely update a virtual card, which is independent of the emulation environment used to implement the virtual card. Application module 212 includes the software and / or hardware required to run the application. Application module 212 is configured to communicate with emulation environment 206. Emulation environment 206 provides a virtual representation of the physical card, referred to as virtual card 202. This can take the form of a built-in embedded secure element or a host card emulation environment.

[0068] refer to Figure 1b The described method provides a computer-implemented approach for remotely updating a virtual card 202 on a computing device 200. The virtual card 202 is associated with an application executed by the computing device 200 because it provides functionality implemented by an application (e.g., contactless payment, access control, or transportation ticketing) by generating command and response Application Protocol Data Units (APDUs) required during interactions between the computing device 200 and, for example, an NFC reader. Method 100 is implemented by an application module 212, which is an example of a processing resource. We describe the application module 212 as being separate from but communicating with an emulation environment 206. The emulation environment 206 can be, for example, a host card emulation environment or an embedded secure element.

[0069] Figure 1b The method shown provides an object-oriented approach to update a virtual card over-the-air on a computing device 200 (e.g., a mobile computing device) within an emulation environment 206 (e.g., an embedded secure element (SE) or host card emulation environment (HCE) of computing device 200). This update process can occur after a previous update of the card according to steps S114 to S130 as described below. The update process can also be the first update following the card setup process according to steps S100 to S112.

[0070] SE and / or HCE can deploy a signature service personalized with a certificate (CERT.SIGN.AUT), which is signed with a signature generated by the corresponding emulation environment 206. The signature service personalizes the emulation environment with an Elliptic Curve Cryptography (ECC) key pair and a digital certificate containing the public key of the key pair. The digital certificate is signed by a suitable Certificate Authority (SIGN.AUTCA). The emulation environment is personalized with a public key issued by a suitable Certificate Authority (APP.OWNER CA). Thus, all emulation environments controlled by APP.OWNER are personalized with the same public key. The emulation environment is also configured to generate an ECC key pair (for each virtual card), referred to as VirtualCard.ECKA. The public key of the key pair is embedded in the digital certificate signed by the signature service. In step S114, a card update process is initialized, which will result in the update of the virtual cards 202 created and set up as described above in steps S100 to S112. This can be in response to a notification from the application module indicating that the associated virtual card 202 needs to be updated. The update may not be a required application update, but rather, for example, a required update to the card data provided in the card object sent to the application module 212 in step S106. The update may also be an update to the card key in the card object received from the card management service backend 208 during the card's initial setup or a previous update.

[0071] Although the card update process can be initiated by application module 212, this initialization can also be in response to a request from card management service backend 208. A notification can be provided to the user of computing device 200 informing them that an update is about to begin. The user can be given the option to delay or reject the update. Optionally, the user can reject this option if, for example, the update to virtual card 202 is security-critical or safety-sensitive.

[0072] The request in step S114 may be generated by the user providing input requesting an update via the computing device 200.

[0073] The initialization of the card update process may include application module 212 allocating hardware and processing resources 204 to the card update process.

[0074] Optionally, if the computing device 200 utilizes both HCE and SE, the application module 212 can obtain an identifier that identifies the emulation environment 206. That is, the identifier indicating whether the emulation environment is HCE or SE is obtained, for example, by the application module 212. Using the identifier of the emulation environment 206, the application module 212 queries the identified emulation environment to determine at least one instance of, for example, the virtual card 202 to be updated. Subsequently, the emulation environment 206 can respond by confirming or denying the presence of the virtual card 202.

[0075] In any case, application module 212 requests the import of a card object into the corresponding simulation environment to be updated (as described in step S108). Application module 212 can use a card identifier to identify a specific card object because simulation environment 206 can store multiple virtual cards. That is, application module 212 begins the process of exporting the card object.

[0076] To export the card object, application module 212 can utilize the command and response application protocol data unit (APDU) constructed according to ISO 7816-4. This is in the case that the simulation environment is SE.

[0077] In step S116, if the simulation environment is SE, one or more command APDUs are used to obtain the transfer session key generation data, card data, and password key generated in step S104 and imported into the simulation environment in step S108. This data constitutes the card object imported into the simulation environment in step S108. An APDU can be described as an exported APDU.

[0078] In other words, application module 212 generates the APDU required to export the card object from simulation environment 206.

[0079] To import data (which constitutes card objects) into the HCE environment, an API implemented by application module 212 is required. Card objects are only decrypted / encrypted within the emulation environment 206. Outside the HCE environment and the card management service backend, card objects are always encrypted and never transmitted in plaintext.

[0080] The card object includes cryptographic assets that can be used to identify and authenticate the emulation environment 206. These cryptographic assets are provided by the card management service backend 208 in step S106. Specifically, the cryptographic assets may include certificate chains (CERT.Application ECKA and CERT.SIGN.AUT), which are used by the card management server (described below) to authenticate the emulation environment 206 during the card update process. The card object may also include a first derived random number for establishing a transmission session key. The transmission session key may be based on an HMAC function, where the session key is equal to the HMAC(base key, SDR), where the SDR is different for each card object and is generated by the component that produces the card object. The SDR may be equal to the derived random number.

[0081] Subsequently, in step S118, the card object is transferred to the card management service backend 208, which can be described as a virtual card management and card management server. Any suitable transport protocol or medium can be used to implement the transfer. One or more APIs can also be used to implement the transfer. Multiple backend servers may exist between the card management backend and the computing device. For example, if the application is a wallet, a wallet provider backend may also exist if the application module 212 implements the wallet application. The APIs of the card management backend 208, as well as the wallet application and wallet provider backends, are independent of the simulation environment.

[0082] The API of each backend server between the card management backend and the computing device is independent of the emulation environment. This means that requests are transmitted along an environment-independent path. This means that virtual cards can be updated remotely using a method that does not depend on the emulation environment, which is an improvement over previous methods used to update virtual cards on the computing device. That is, updates to virtual card 202 are independent of the specific emulation environment 206. In step S120, the card management service backend 208 verifies that the emulation environment 206 has received the card object from the emulation environment 206. This can be implemented using any suitable method to verify the shared secret transmitted from application module 212 to card management service backend 208.

[0083] In one example, the certificate chain (CERT.ApplicationECKA and CERT.SIGN.AUT) is verified by the card management service backend 208. This certificate chain is part of the cryptographic assets that form part of the card object transmitted from application module 212 to the card management service backend 208. After verification, a transmission base key is calculated by combining the Application.ECKA public key with the virtual card private key (card.ECKA) using a standard ECC key negotiation algorithm. The virtual card private key is received as part of the card object. The transmission base key is stored in a database and used to derive the transmission session key, which is used to encrypt / decrypt the card data and the cryptographic keys of the card object. Temporary asymmetric keys and certificates can also be used to derive the transmission session key.

[0084] In other words, the cryptographic assets provided with the card object are used to verify the card object by the simulation environment. The cryptographic assets are used to form a transmission base key, which is then used to derive a transmission session key. This transmission session key is used to encrypt and decrypt card data and to decrypt the card key, which is also part of the card object. The derivation can be based on a derived random number provided with the card object. Simply put, the cryptographic assets are used as part of the transmission session key generation data to derive the transmission session key. The derivation can be implemented using any suitable key derivation technique, for example, based on a hash of one or more cryptographic assets. The key derivation function can be based on an HMAC function, where the session key is equal to HMAC(Base Key, SDR), where the SDR is different for each card object and is generated by the component that generates the card object. The SDR can be equal to a derived random number. Temporary asymmetric keys and certificates can also be used to derive the transmission session key.

[0085] Upon receiving the card object and the request to update the virtual card 202 from the application module 212 in step S118 and completing the verification of the emulation environment 206 in step S120, the card management service backend 208 generates an updated card object in step S122. This generation utilizes the card data received in the card object (received in step S118) to generate the updated card object. The updated card object represents an updated card object containing the data required by the emulation environment 206 to update the virtual card at the computing device 200. For example, the updated card object includes metadata identifying the emulation environment (e.g., SE or HCE) identified by the card object, a public key (or other cryptographic asset) that can be used to establish a second transmission session key (and associated derived random numbers), a model of the updated card, the data required to emulate the updated card, and a cryptographic key encrypted and signed with the second transmission session key (which may be different from the first transmission session key). Temporary asymmetric keys and certificates can be used to derive the transmission session key.

[0086] The updated card object can be a JSON object, embedding virtual card data and the key corresponding to the updated card.

[0087] Subsequently, in step S124, the updated card object is transmitted to computing device 200, where it is received by application module 212. The transmission of the updated card object can be implemented using any suitable telecommunications medium or protocol, thereby allowing connection to the remote card management service backend 208. Alternatively, or optionally, the transmission can be implemented using one or more APIs independent of the emulation environment 206. That is, an environment-independent path is also used to transmit the updated card object to computing device 200. The transmission also includes the transmission of cryptographic assets, such as certificate chains (CERT.card.ecka and CERT.permission.AUT), sent to computing device 200 so that they can be provided to the emulation environment 206. The signature corresponding to the updated card object and the encrypted card data and cryptographic key are also transmitted with (or as part of) the updated card object. Application module 212 can verify the updated card object upon receipt using any suitable technique. For example, application module 212 is configured to verify the authenticity of the certificate chain using the CA public key corresponding to the application. This uses any standard technology.

[0088] Subsequently, in step S126, application module 212 transmits the updated card object along with a request to import it into simulation environment 206 to simulation environment 206. Application module 212 may first identify which simulation environment 206 is required. If the simulation environment is SE, an import APDU is generated to enable the import of the updated card object into the simulation environment. If the simulation environment is HCE, the updated card object is imported into the simulation environment using an API.

[0089] This completes the import of the updated card object, wherein in step S128, the public key (or other cryptographic asset) generated in step S122 is used to establish a second transmission session key, and then in step S130, the second transmission session key is used to decrypt the card data and card key received in the updated card object, and the provided model is used to generate an updated instance of the virtual card.

[0090] As described above, the card management service backend 208 remotely creates and updates a virtual card 202 residing in the emulation environment 206. Based on the device nature (which provides information on whether the mobile device supports SE, HCE, or both), the card management backend 208 selects the card emulation type and generates a card object accordingly. As a first step, the first card object digitized on the computing device 202 creates a virtual card 202 in the selected emulation environment 206 using a shared cryptographic asset (i.e., a shared secret). The shared secret is used to derive a base key shared between the card management service backend and the emulation environment. This base key is used to derive a transmission session key for each card object transmitted between the card management backend and the card emulation. The transmission session key is used to sign and encrypt the card object. The same base key is used for the generation of the transmission session key at both the card management service backend 208 and the emulation environment 206, enabling both entities to derive the same transmission session key for secure communication with each other. Once the virtual card 202 is created, it is fully functional and can be used by end users to enable mobile devices to tap on an NFC reader application to perform transactions such as access control or public transportation. A temporary asymmetric key and certificate can also be used to derive the transmission session key.

[0091] Alternatively or additionally, updates to the virtual card 202 may be implemented using any cryptographic protocol that enables the establishment of a shared secret between the two environments (the emulation environment SE / HCE on the computing device 200 and the card management service backend 208).

[0092] Application module 212 can initiate a virtual card update to update the virtual card and its contents. This may require changing the data stored in the card (e.g., increasing the stored value from $5 to $30 to have sufficient funds for public transportation, etc.).

[0093] One of the main benefits of the above is that the APDU does not need to be generated by the card management service backend 208 and passed down to the computing device 200. Instead, the card management service backend 208 generates and updates the complete card object and securely exchanges it with the computing device 200 (encrypted and signed). On the computing device 200, the device application ensures that the encrypted card object is imported / exported to the emulation environment (SE or HCE). For such import / export from the mobile device application to the SE emulation environment and from the SE emulation environment to the mobile device application, the APDUs described above for importing and exporting APDUs are required. For such import / export from the mobile device application to the HCE emulation environment and from the HCE emulation environment to the mobile device application, the application-based API is required.

[0094] Application module 212 is independent of the card objects generated by the card management service backend 208. Application module 212 imports and exports card objects to the simulation environment defined and selected by the card management backend 208. As described above, if the simulation environment 206 is SE, application module 212 generates APDUs to import or export card objects. If the simulation environment is HCE, card objects are imported and exported via API. Application module 212 is responsible for initiating the card creation and update process with the remote service backend, and executes the same process flow regardless of whether the simulation environment is SE or HCE.

[0095] Simulation environment 206 can be used to implement several virtual cards. Simulation environment 206 can, for example, implement virtual card contactless protocols (e.g., for NFC communication). Simulation environment 206 processes card objects to create and update virtual cards and perform functional simulation of the virtual cards.

[0096] All components of the described system (e.g., wallet services) residing between the card management service backend 208 that generates card assets (i.e., card data and card keys) and the application module 212 that imports or exports objects in an embedded secure element or host card emulation are independent of the emulation environment.

[0097] The described method improves the card setup and update process in several ways. First, for remotely updating virtual cards on mobile computing devices, typical existing end-to-end systems are based on the following components: a card management service backend that provides card assets (i.e., card keys and card data), an (optional) wallet service backend, and a mobile device application. The wallet provider entity manages the wallet service backend implementation and manages the mobile device users. The wallet provider provides the mobile device application to access HCE and / or SE.

[0098] In the original approach, when the card is digitized in an SE embedded in the computing device, an additional component called the SE Issuer Trusted Service Manager (SEI-TSM) manages the lifetime of applications installed on the SE. The SEI-TSM and the card management service backend 208 generate APDU commands to digitize and update the virtual card. The described method makes the update process independent of the emulation environment.

[0099] Additionally, to specifically update the virtual card via Host Card Emulation (HCE) on the mobile device, the mobile application requests a tokenized card object from the card management service backend through the wallet service. The tokenized card object is used to emulate the card on the mobile device (card protocol, card functionality, including pre-personalized card data and card keys). Card setup and personalization via HCE are accomplished through a single exchange of the complete card image, without requiring sequential exchanges of card-related commands.

[0100] Additionally, to update the virtual card in the (embedded) Secure Element (SE), the mobile application requests the SEI-TSM to create an application instance for emulating the card on the mobile device. Subsequently, the mobile application requests the Card Management Service backend to generate APDU commands via the wallet service backend to set up and update the SE application with card assets. The card setup and personalization on the SE is completed through the sequential exchange of card-related APDU commands. In other words, the process of updating the virtual card in the SE and HCE are different, resulting in different user experiences (impacting performance, user flow, and functionality and technical implementation). The claimed method aims to improve the user experience by eliminating this difference.

[0101] In summary, the described method allows for the remote creation and updating of virtual cards on mobile devices in the same manner using SE- or HCE-based environments, leveraging the same implementation scheme and use case flow. This ensures consistent system implementation and performance for both underlying technologies (SE and HCE) without any noticeable difference to the end user.

[0102] The described method improves upon the typical card digitization and card update process, which requires additional participants (i.e., SEI-TSM) and more steps. The typical process for SE would be significantly slower (resulting in a worse user experience) and cannot be implemented in the same way, independent of the simulation environment, but requires different implementations for each supported simulation environment (e.g., SE and HCE respectively).

[0103] Because of the need for SEI-TSM and the transfer of APDUs between the card management service and the SE, it is impossible to design the same processes for the SE and HCE using the usual methods. The simulation environment-independent approach described above completely alleviates this requirement, thereby improving system implementation, increasing simplification, reducing complexity, and simplifying system maintainability.

[0104] The added value of being independent of the supported simulation environment (reduced development costs, more robust solution implementation due to code reuse, better system performance, improved transaction performance) and sharing the same digitization and update processes for the same data objects in HCE and SE is the ability to design wallet services independent of card type (SE or HCE). Furthermore, card management services are simplified by being able to use common card digitization logic. This facilitates numerous improvements (reduced development costs, more robust solutions due to code reuse, better system performance) by having the same processes for SE and HCE.

[0105] The described method enables the updating of virtual cards in a manner independent of the emulation environment used for emulation updates. This method allows for a unified process and use case flow to digitize and update virtual cards within computing devices (e.g., mobile computing devices) independently of the underlying technology used (SE or HCE). The described embodiments unify communication between all involved components because the API implementation and exchange parameters are consistent, avoiding two different functional implementations.

[0106] Furthermore, to reduce the number of interactions with backend services, APDU commands are generated by the application located on the computing device. The application does not need to request the generation of an APDU from the card management backend service, then execute the APDU and send the response APDU to the backend. By reducing the number of interactions with backend services, the performance of card digitization, card personalization, and card updates is improved.

[0107] As another advantage, time to market and solution complexity become similar for both SE and HCE.

[0108] It should be noted that the aspects and embodiments mentioned above illustrate this disclosure but do not limit it, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals in parentheses in the claims should not be construed as limiting the claims. The words “comprising” and “including” do not exclude the presence of elements or steps other than those listed as an integral part of any claim or specification. In this specification, “comprising” means “including or consisting of”, and “including” means “comprising or consisting of”. Singular references to elements do not exclude plural references to those elements, and vice versa. This disclosure can be implemented by means of hardware comprising several disparate elements and by means of a suitably programmed computer. In an apparatus claim enumerating several components, several of these components may be embodied by one and the same item of hardware. The fact that certain measures are recited in mutually different dependent claims does not in itself imply that combinations of these measures cannot be advantageously used.

Claims

1. A computer-implemented method for setting up a virtual card on a computing device, characterized in that, The virtual card is associated with an application executed by the computing device, the method is implemented by processing resources, and the method includes: A request for a virtual card associated with an application is provided to a card management server. The request includes password data that identifies an emulation environment for implementing the virtual card on the computing device. The request is provided to the card management server using an environment-independent path. Receive a card object corresponding to the virtual card from the card management server, wherein the card object is received using an environment-independent path; Import the card object into the simulation environment; An instance of the virtual card is generated in the simulation environment.

2. The method according to claim 1, characterized in that, The environment-independent path includes components that are independent of the simulation environment.

3. The method according to claim 2, characterized in that, The components utilize an application programming interface that is independent of the simulation environment.

4. The method according to claim 1, characterized in that, The card object includes one or more of the following: a. Metadata, wherein the metadata identification will implement the simulation environment of the virtual card; b. Generate data for transmitting the session key, which is used to establish the transmission session key; c. The data model of the card; d. Card data; and e. Card key.

5. The method according to any one of the preceding claims, characterized in that, The simulation environment is either a host card simulation environment or a security element.

6. A computer-implemented method for updating a virtual card on a computing device, characterized in that, The virtual card is configured according to any one of claims 1 to 5, the method is implemented by processing resources, and the method includes: Initialize the card update process; A card object is obtained from a simulation environment associated with the application, wherein the card object includes cryptographic assets associated with the simulation environment; The card object is sent to the card management server along with a request for an updated card object, wherein the card object is sent using an environment-independent path; Receive updated card objects from the card management server via an environment-independent path; Use the updated card object to update the virtual card.

7. The method according to claim 6, characterized in that, The method further includes, in response to updating the virtual card using the updated card object, verifying the update and transmitting a verification notification to the card management server.

8. A non-transitory computer-readable storage medium having executable instructions stored thereon, characterized in that, The executable instructions, due to execution by the processor of the computer system, cause the computer system to perform at least the method according to any one of claims 1 to 7.

9. A system, characterized in that, Configured to implement the method according to any one of claims 1 to 7.

10. A method for processing resources, characterized in that, It includes a processor and a memory, the memory including executable instructions that, when executed by the processor, cause the computing device to perform the method according to any one of claims 1 to 7.

Images