Secure device transactions

Abstract

A method for generating secure transactions involves a first device 210 authorised to generate transactions (e.g. smartphone) receiving a request for transaction authorisation from a second device 220

Description

Field of the Invention The present invention relates to a system and method for generating secure transactions, and enabling one authorised device to be used to provision an unauthorised device to conduct secure transactions. Background of the Invention It is often convenient for devices to generate transactions, such as payment transactions. This is safer than cash and avoids the need to carry physical plastic credit cards. Furthermore, security can be enhanced and transactions can be made more efficiently. However, it can be cumbersome to set up payments and other transaction capabilities on a new device as identity checks need to be made and security data must be sent to and from a transaction platform or card issuer. This can require several messages and complex authorisation may be required for the new device. This can delay authorisation and results in a poor user experience. Furthermore, certain devices may not have a required user interface to initiate such an authorisation procedure. Therefore, connected devices such as Internet of Things (loT) devices that may benefit from the ability to conduct secure transactions are not able to. DE102016209380 describes a system for enabling a vehicle to generate payment transactions. A user-related parameter set of a vehicle (e.g., biometric data or seat settings) is sent to a mobile radio provider together with a request to a payment service provider and assigned to a SIM of a mobile radio unit of the user. The payment service provider creates a virtual payment token and transmits this token to the mobile radio provider. The mobile radio unit is integrated with the vehicle. When paying for goods or services, the parameter set linked to the SIM of a mobile radio unit of the user, is compared to a stored parameter set to authenticate the user. However, this system is limited to vehicles and requires the same initial complex payment authorisation process to be repeated for every vehicle being provisioned with the payments system. Therefore, there is required a method and system that overcomes these problems. Summary of the Invention There is provided a method and system for enabling an unauthorised device to become authorised by making use of the trust already developed by an authorised device. The unauthorised device becomes authorised by obtaining a transaction token. In an any example implementation, the unauthorised device may be a vehicle (e.g., having cellular communications facilities and a console or graphical user interface) and the authorised device may be a smartphone, for example. The authorised device receives a request for transaction authorisation from the unauthorised device. In any example implementation, this request may be wired, wireless or optical. For example, the console on the unauthorised device (e.g., a vehicle) may display a QR code and a camera on a smartphone may view the displayed QR code and extract the data of the request from the image of the QR code or other graphical representation. A secure communication channel is provided between the authorised device and the unauthorised device and between the authorised device and a transaction provider (e.g., a payment provider that can issue authentication material (e.g., tokens or certificates). Before the secure channel is set up between the authorised device and the unauthorised device, the unauthorised device sends the authorised device security credentials associated with its identifier. This may be as part of the initial request or separately. These security credentials are sent to a server or security service, which validates the credentials and responds with first cryptographic material. The first cryptographic material is used to set up the first secure communications channel between the unauthorised device and the authorised device. The unauthorised device uses a security module (e.g., hardware security module, UICC, SIM, or eSIM) to generate second cryptographic material, which is sent to the authorised device over the newly formed first secure communications channel. The authorised device passes the second cryptographic material to the transaction provider (e.g., the payment provider) using the second secure channel. The second secure communications channel may be formed when the authorised device was set up with its own transaction capability (e.g., as part of a payment system). The transaction provider responds to this request (if validated) by providing the authorised device with a new transaction token or certificate over the second secure communication channel). The authorised device sends the transaction token or certificate to the unauthorised device using the first secure communications channel. The unauthorised device now becomes authorised for future transactions (i.e., becomes a second authorised device). The transaction token or certificate is different to a transaction token or certificate used to authorise the first or initial authorised device. In this way, trust developed by the authorised device can be used to enable an unauthorised device to become authorised to perform its own transactions in isolation (without the first device). Because a new transaction token (and any associated cryptogram) has been provisioned onto the second authorised device, the system and method can operate even when there is no or limited internet connectivity. In accordance with a first aspect there is provided a method for generating secure transactions, the method comprising the steps of: a first device receiving from a second device a first request for transaction authorisation, wherein the first device is authorised to generate transactions; the first device receiving from the second device security credentials associated with an identifier of the second device; the first device sending the security credentials associated with the identifier of the second device to the server; after validating the security credentials associated with the identifier of the second device, the server responding to the first device with first cryptographic material; the first device and the second device initiating a first secure communication channel using the first cryptographic material provided by the server; the second device providing the first device with second cryptographic material using the first secure communication channel, wherein the second cryptographic material is obtained from a security module within the second device; the first device sending a second request to authorise the second device for transactions with a transaction provider, wherein the request is based on the second cryptographic material and sent using a second secure communication channel; when the transaction provider validates the second request, the transaction provider sends a cryptographic transaction material to the first device using the second secure communication channel, wherein the cryptographic transaction material authorises the second device to generate transactions; and the first device sending the cryptographic transaction material to the second device using the second secure communication channel. Therefore, the trust obtained by an authorised device may be used to provide authorisation to an unauthorised device without requiring manual validation procedures to be repeated. The cryptographic transaction material (e.g., token or certificate) becomes bound to the security module of the second device (e.g., a SIM or eSIM) so that transaction security is enhanced. The binding occurs because the cryptographic transaction material can only be requested using an identifier of the second device (which can be associated with the SIM or eSIM) and only received over the secure communications channel between the first device and the second device, which requires the use of the SIM or eSIM of the second device. Preferably, the first device has been authorised by the transaction provider (e.g., a payments provider or system) before the method executes. This authorisation may be manual or automatic but may require credentials to be provided (e.g., credit card details, address details, images of identity cards, etc.). The second secure communication channel may be formed using any suitable technique but preferably using cryptographic material exchanged between the transaction provider and the first device when the first device was authorised by the transaction provider. Preferably, the method may further comprise the step of the transaction provider obtaining permission from an issuing authority before generating the cryptographic transaction material. The issuing authority may be a credit card issuing authority, for example. Optionally, the security module may be a UICC, SIM, or eSIM. Other types of security module may be used but a UICC, SIM, or eSIM may provide both telecommunications connectivity and secure processing of cryptographic material. Optionally, the first secure communication channel may be secured between a first UICC, SIM, or eSIM of the first device and a second UICC, SIM, or eSIM or of the second device. Such secure modules are well suited to securing communication channels. Optionally, the method may further comprise the step of the second device storing the cryptographic transaction material within the security module. The security module (such as a UICC, SIM, or eSIM) may have secure storage and / or one or more secure applications or software development kits (SDK) that can securely store the cryptographic transaction material and retrieve it when required. Optionally, the first request may be received from the second device by the second device displaying a QR code to a camera of the second device. There may be other ways for the request to be sent by the first device and received by the second device (e.g., wired, Bluetooth (RTM), wireless, Wi-Fi (RTM), etc.) but the use of a QR code provides convenience as the interface only requires a display screen and camera on the first device (e.g., a smart phone). Optionally, the second cryptographic material may be obtained from a security module within the second device using an application within the security module. The application may be a payments application and / or a software development kit (SDK), for example. Optionally, the transactions may be payment transactions and the transaction provider may be a payment provider. However, other types of transactions may be used. These may include transactions providing data (e.g., sensor data) or other exchanges of information (e.g., package delivery confirmation, utility meter readings, location information, status information, health information, etc.). Optionally, the method may further comprise the step of the second device using the cryptographic transaction material to initiate a transaction with the transaction provider. This may be using the cryptographic transaction material directly or using the cryptographic transaction material to generate further secure or cryptographic material for validating a transaction (e.g., in the absence of an internet connection). Preferably, the cryptographic transaction material may be associated with or comprises a payment account number (PAN) and / or cryptogram data. The cryptogram data may be generated by the secure module from the cryptographic transaction material. Optionally, the cryptographic transaction material may be a transaction authorisation token. The transaction authorisation token may contain a PAN or act as a credit card token (e.g., a virtual card), for example. Optionally, the cryptographic transaction material may be a digital certificate. The digital certificate may be issued by the transaction provider, that may include or be associated with a certificate authority. The certificate may then be used to initiate or digitally sign transactions, for example. Preferably, the cryptographic transaction material may be encrypted by the transaction provider (e.g., before being sent to the first device) and decrypted by the second device (e.g., after received from the first device). This provides enhanced security as the cryptographic transaction material may otherwise be in plain text when passing through the first device (and the first device should not have access to the cryptographic transaction material meant for the second device). The server and the second device may have already shared keys using a suitable method and so any material shared between them, even passing through the first and second secure communication channels (or tunnels) may be further encrypted. In summary, the transaction provider may encrypt the cryptographic transaction material before it is first sent through the second secure communication channel to the first device and then through the first secure communication channel to the first device. Preferably, the encrypted cryptographic transaction material may be decrypted by the security module of the second device. This provides a more secure way to handle the cryptographic transaction material. If the cryptographic transaction material is also stored within a portion of the security module (e.g., within an application), then access can be restricted to the security module alone (e.g., a SIM, eSIM, or HSM) further enhancing security. Preferably, one or more keys used to encrypt and / or decrypt the cryptographic transaction material may be agreed between the transaction provider and the second device using the server. The server may (e.g., in advance during a registration procedure, at manufacturer, or just before the cryptographic transaction material is sent) agree the keys with one or more second devices (e.g., all vehicles in a fleet). According to a second aspect, there is provided a non-transitory computer-readable medium storing instructions that, when read by one or more processors, cause the one or more processors to carry out the method or methods described within this disclosure. According to a third aspect, there is provided a system comprising: a second device comprising a security module configured to provide second cryptographic material and security credentials associated with an identifier of the second device, and to receive a cryptographic transaction material; a server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the server to: receive security credentials associated with the identifier of the second device; and after validating the security credentials associated with the identifier of the second device, responding with first cryptographic material; a transaction provider configured to provide over a second secure communication channel a cryptographic transaction material to authorise the second device to generate transactions after validating a second request; and a first device authorised to generate transactions and comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the first device to: receive from the second device a first request for transaction authorisation; send the security credentials associated with the identifier of the second device to the server; receiving the first cryptographic material from the server; initiate a first secure communication channel with the first device using the first cryptographic material provided by the server; receive from the first device the second cryptographic material using the first secure communication channel; send the second request to authorise the second device for transactions to the transaction provider using the second secure communication channel, wherein the request is based on the second cryptographic material; and receive from the transaction provider the cryptographic transaction material. There may be a plurality of first and / or second devices in the system. There may be one or more servers and one or more transaction providers. Optionally, the first device may be any one of: a mobile telephone; a laptop computer; or a remote computer system. Other devices may be used. In the case of the remote computer system, this may be a terminal managing a plurality of second devices (e.g., a fleet of vehicles). The first device may be the same or different to the second device. Optionally, the second device may be any one of: a vehicle; a mobile telephone; or an Internet of Things (loT) device. Other device types may be used. Optionally, system may further comprise an issuing authority configured to grant permission to the transaction provider to generate the cryptographic transaction material for the second device. The system may comprise a plurality of first devices and / or a plurality of second devices. One or more servers and / or transaction providers may also be present in the system and configured to operate with different sets of first and / or second devices or types of devices. Optionally, the security module of the second device may be a UICC, SIM, or eSIM. The security module may be a hardware security module (HSM), for example. Optionally, the security module may be further configured to store the cryptographic transaction material. Preferably, the security module may be further configured to store the cryptographic transaction material in a certificate store or a token store of the security module. The cryptographic transaction material may be stored within other locations on or in the second device. The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium, including a non-transitory computer-readable medium. The computer system may include a processor or processors (e.g., local, virtual or cloud-based) such as a Central Processing Unit (CPU), and / or a single or a collection of Graphics Processing Units (GPUs). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and nonvolatile storage medium. A computer-readable medium (CRM) may be included to store the logic or program instructions. For example, embodiments may include a non-transitory computer-readable medium (CRM) storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform the disclosed methods. Non-transitory CRM may refer to a CRM that stores data for short periods or in the presence of power such as a memory device or Random Access Memory (RAM). For example, a non-transitory computer-readable medium may include storage components, such as, a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, and / or a magnetic tape. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX (RTM), Windows (RTM) or Linux (RTM), for example. It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which: FIG. 1 shows a flowchart of a method for a device to generate secure transactions; FIG. 2 shows a schematic diagram of a computer system used to implement the method of Figure 1; FIG. 3 shows a schematic diagram of an example system used to implement the method of Figure 1; FIG. 4 shows a schematic diagram of a further example system used to implement the method of Figure 1; FIG. 5 shows a schematic diagram of a further example system used to implement the method of Figure 1; FIG. 6 shows a sequence diagram of a further example method for a device to generate secure transactions; and FIG. 7 shows a schematic diagram of a further example system used to implement the method of Figure 1. It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals. Detailed description of the preferred embodiments The described systems and methods show how an Internet of Things (loT) binding method utilises a security module (e.g., SIM Card as a Secure Element), which may be present on connected devices within a system, and enables payments to be carried out securely and conveniently. Wallets, identification, biometric, certificates, and / or other tokens can be stored locally for retrieval in short-range and long-range wave transmission. The system and method may establish a connection between a (mobile) device, a device specific payment account number (PAN) token, and an loT device (e.g., vehicle, wearable, container, etc.), whereby a Hardware Security Module (HSM) pairing is used to establish a trusted binding between two or more devices with an embedded HSM for authorised transfer of information between the devices. A transfer of a localised token on one device to embedded elements of the SIM, or a cloud reference to an embedded element in the SIM may be made for one or more bound devices. The system stores identification credentials, payment, biometric and / or other credentials on the SIM, or creates a reference token or certificate on the SIM, which refers back to a cloud service (or other payment service) for retrieval or authorisation of the information, allowing for a local signing of trust between the device and third-party services. In other words, a trusted HSM to another HSM for specific payment handlers is possible, as is the use of a host card emulation (HCE) environment, where retrieval of such credentials are stored on the loT device and can be retrieved or refreshed from a server on a regular basis to increase security. In specific vehicle applications, including but not limited to the retrieval of data such as the vehicle identification number (VIN), telematic information, location data and biometric info, for example, can be associated with the initial SIM binding in certain cases, or can be used during the SIM data retrieval process (e.g., for making a payment, identification of a person, or another transaction). This establishes a level of trust transmitting information via various wireless and / or internet protocols, preferably with secure SSL / TLS encryption. The SIM card functions as a service gateway, which handles vaulting secure payment and identification credentials, and also can be used as a common element for third party services to connect and enable loT (e.g., vehicle) devices. Multiple services can be enabled using the SIM interface, such as car washing, tolling, fuel payments, electric charging, and other types of vehicle-specific commerce scenarios. This system may be scalable and much easier to deploy based on the use of existing SIM architectures, where payment and identification credentials can be safely stored and passed along to third-parties to obtain services. The same system may be used with large number of other loT devices and device types, especially those that require a data connection for wireless connectivity. The system enables services, such as smartphone payments, to work in existing vehicle ecosystems without requiring a phone or other element to authenticate transactions (although phone proximity can be used as a security element via geolocation of the phone within the vehicle). The vehicle may be bound to the SIM secure element, which allows transaction services, such as payment systems to transfer a certificate or token for bound storage on loT devices. Payment services may use the HCE, which allows for cloud token storage, whereby cloud tokenization for bound SIM cards are also enabled by the continuous or intermittent retrieval of new tokens to store locally on the SIM card. Figure 1 shows a flowchart of a method 10 for enabling transactions. Two devices initially participate in the method 10. A first device is already authorised to conduct, participate in, and / or generate transactions. A second device is initially unauthorised but becomes authorised once the method 10 executes successfully. At step 15, the second device requests transaction authorisation. There may be different ways of issuing such a request, which may be directed to the first device. For example, a console of the second device (e.g., a vehicle) may display a QR code containing data describing the request. The first device may view the QR code using a camera and decode the request. Wired or wireless channels may also be used to process the request. At step 20, the second device provides the first device with security credentials associated with or linked to an identifier of the second device. The security credentials may be passed to the first device at the same time as the request (or as part of the request) or as a separate step. However, the first device receives these credentials, it passes them on to a server (e.g., a security service) using a suitable communication channel (e.g., a telecommunications system, cellular network or the internet) at step 25. The server validates the security credentials at step 30. For example, the server may already be familiar with the second device or may accept any credentials from a particular type of device (e.g., based on a manufacturer of the second device). Once validated, the server sends first cryptographic material (associated with or specific to the second device) to the first device at step 35. This first cryptographic material enables the first and second device to initiate a first secure communication channel or tunnel between them at step 40. For example, the first cryptographic material may contain keys or key material enabling each device to derive communication keys securely that are used to secure the channel. The second device can now obtain or derive second cryptographic material from a security module within the second device. This may be a hardware security module, a UICC, a SIM or an eSIM, for example. In any case, the second cryptographic material can only be generated by the second device, and cannot be replicated by another device. Therefore, the second cryptographic material can be validated against the second device by any other party. The second cryptographic material is sent from the second device to the first device over the first secure communication channel at step 45 (i.e., without the possibility of interception). As the first device is already authorised for transactions with a transaction provider, the first device and the transaction provider have a secure way to interact. This may be a second secure communications channel (e.g., secured by shared keys negotiated when authorisation was set up). This second secure communications channel is used to send an authorisation request to the transaction provider at step 50. The request is based on and / or contains the second cryptographic material from the fist device (and also can’t be intercepted or decrypted by another entity). As the authorisation request is received from the first device over a secure communication channel by the transaction provider and the transaction provider has already authorised the first device (and so trusts the first device), the transaction provider can extend this trust to the second device without needing to carry out the same level of validation and security procedures as were previously carried out on the first device during its authorisation process. For example, the procedures may have involved background checks, form checking, biometric information, credit checks, or other time-consuming actions. Preferably, the same user or account is used by both the first device and the second device. The transaction provider can now provide cryptographic transaction material that can be used by the second device to generate and participate in transactions (and so become an authorised device) in the same way as the first device. However, this cryptographic transaction material is provided to first device over the existing second secure communications channel (step 55). The cryptographic transaction material is sent from the first device to the second device over the first secure communications channel at step 60. Preferably, the cryptographic transaction material is securely stored by the second device (e.g., within the security module or an application within the security module). In any case, the cryptographic transaction material can be used by the second device to conduct transactions at step 65. The method 10 may be executed by a computer system or a group of computers or processors. As shown in Figure 2, the computer system 100 includes a number of components including communication interfaces 120, system circuitry 130, input / output (I / O) circuitry 140, display circuitry and interfaces 150, and a datastore 170. The system circuitry 120 can include one or more processors or CPUs 180 and memory 190. The system circuitry 130 may include any combination of hardware, software, firmware, and / or other circuitry. The system circuitry 130 may be implemented, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, and / or analogue and digital circuits. The display circuitry may provide one or more graphical user interfaces (GUIs) 160 and the I / O interface circuitry 140 may include touch sensitive or non-touch displays, sound, voice or other recognition inputs, buttons, switches, speakers, sounders, and other user interface elements. The I / O interface circuitry 140 may include microphones, cameras, headset and microphone input / output connectors, Universal Serial Bus (USB) connectors, and SD or other memory card sockets. The I / O interface circuitry 140 may further include data media interfaces (e.g., a CD-ROM or DVD drive) and other bus and display interfaces. The memory 190 may include volatile (RAM) or non-volatile memory (e.g., ROM or Flash memory). The memory may store the operating system 192 of the computer system 100, applications or software 194, dynamic data 196, and / or static data 198. The datastore or data source 170 may include one or more databases 172, 174 and / or a file store or file system, for example. Figure 3 illustrates schematically an example system 200 for implementing the method 10 described with reference to Figure 1. In this example implementation, the authorised device 210 is the first device and the vehicle 220 is the second device. The security service is the server 230 and the scheme provider is the transaction provider 240. An issuer 250 interacts with the scheme provider 240 to issue the cryptographic transaction material. The cryptographic transaction material in this example is a payment token 245. As can be seen from Figure 3, the authorised device 210 already has a payment token. A console 226 within the vehicle 220 interacts with the security service 230 and generates the request for authorisation presented to the authorised device 210 (e.g., as a QR code). A payments application 224 within the security module (SIM 222) provides the second cryptographic material through the first secure communication channel 215 to the authorised device 210 and onto to the scheme provider 240 through the second secure communication channel 217. The payment token may provide PAN data used in subsequent transactions by the vehicle 220, for example. The SIM 222 can secure the secure communication channel or data tunnels (and / or a SIM in the authorised device 210, which is not shown in this figure) to one or more third parties. The SIM may support multiple transaction (e.g., payment) identity bindings (multiple credit or debit cards). The third parties can verify the SIM of unauthorised devices using the security service 203. A user of an unauthorised device may interact with the system 200 through an authorised device 210, such as a smartphone, connected device, or other computer. The authorised device 210 may also be a device used to manage multiple devices or vehicles, such as a fleet management console or portal. The authorised device 210 has functionality to accept and process or action binding (transaction authorisation) requests. Preferably, the vehicle 220 interacts with a user (e.g., driver) using the (integrated) console or interface 226 (e.g., an infotainment system). The console 226 also has software or an interface to perform transactions, once authorised. In an initial state (before the vehicle is authorised for transactions) the SIM 222 has a payment (transaction) application 224 containing no credentials (cryptographic transaction material). The vehicle manufacturer, administrator for multiple vehicles, or OEM already has knowledge which SIM (security module) 222 is in which vehicle and an associated identifier of the vehicle (e.g., unique identifier). The user has a valid (and authorised) account with the transaction (scheme) provider 240. In system 200 described with reference to Figure 3, tunnels 215 and 217 have endpoints within the first device (authorised device) 210. In order to avoid interception of the cryptographic transaction material (e.g., token or certificate) 245, additional encryption may be used to protect this material. This material may be encrypted using one or more keys agreed between the second device (vehicle) 210 and the transaction provider (scheme provider) 240. The scheme provider 240 and the second device 210 may have already shared keys used for this purpose. The server (security service) 230 may provide functionality for sharing keys between devices and the scheme provider 240. Figure 4 shows a schematic diagram of a further example system 300 for implementing the method 10 described with reference to Figure 1. Similar features have the same reference numerals as shown in Figure 3. However, instead of a tokenised payment card, this example implementation uses digital certificates to authorise transactions. This requires a payment application 330 on the authorised device 210 and a payment application 326 on the vehicle 220. Optionally, these payment applications may be outside of a SIM. A software development kit (SDK) 310 may be installed on the authorised device 210 and an SDK 326 may be installed in the vehicle 220. However, the SIM 222 securely stores the digital certificate(s) in the SIM 222. In this example implementation, the two secure communication channels 215, 217 are both set up by the security service 230 using a REST application programming interface (API) or other mechanism. The SDKs 310, 326 terminate the secure communication channels 215, 217 in the devices 210, 220. In this further example implementation, the capture of a security certificate may provide a trusted secure communication between the SIM of the vehicle and the SIM of another object (e.g., CPO - Charge Point Operator for electric vehicle charging), whereby instead of an exchange of a network payment token, there may be an exchange of digitally signed certificates under the same architecture. The certificates can be provisioned in a similar manner as described with reference to Figure 1, so that certificates are bound to the SIM of the vehicle or other object unauthorised (at least initially) device 220. As these trusted certificates are not payment information, they have the advantage of not holding card information, meaning they are generally out of scope for PCI and EMVCo security aspects but can still initiate and facilitate payment transactions. In this example, after the devices have their security certificates bound within their SIMs 222, the vehicle communicates directly to the CPO (or other entity) using a secure SIM communication with the certificates initiating the transaction. As demonstrated in Figure 5, the method 10 allows a vehicle or other device to establish a secure connection with another device (e.g., cloud, parking meters, EV charge point, loT device, payment device, etc.) over any insecure communication channel using keys based on 3GPP SIM / HSM network authentication. The system’s protocols can be transported over any communication channel, including low-bandwidth channels, using an efficient design that minimises the size of the security overhead. Since device key creation can take place locally on the vehicle (or other device), this is a significant advantage over early systems, as no connectivity is necessary to generate a security key. When the transaction is a payment transaction, the method 10 enhances the security of card-present transactions within a vehicle commerce domain. The system 200, 300 and method 10 may integrate the ISO 15118 and ISO 14443 communication protocols with a vehicle Subscriber Identity Module (SIM or eSIM) 222 as a secure element environment. This integrated solution provides high security for credit card tokens and identity information. The method 10 may be extended to different use cases, including charging, tolling, parking, restaurants, car washes, and other applicable in-vehicle-enabled services, provided specific conditions are met. This approach enhances security and streamlines transactions across a spectrum of scenarios. The integrated security framework for vehicle access and transactions is designed to ensure a robust and justifiable card-present transaction environment. The use of physical key fobs or keys as a prerequisite for vehicle access may establish a tangible / physical possession requirement, aligning with the concept of card-present transactions. This physical possession ensures that only authorized users with the corresponding key or fob can initiate transactions (e.g., when this also secures the console 226), contributing to the overall system's security. Implementing digital user profiles may further enhance security by requiring initial verification through a mobile device and email address, for example. Access to the digital user profile may be protected by biometric or PIN entry each time a driver starts their vehicle 220. This also aligns with card-present transaction standards where user identity must be securely authenticated before initiating transactions. Integrating a SIM card within each vehicle establishes a secure element system, providing trusted communication unit (TCU) architecture scalable for all automotive and other manufacturers. Tokens are securely stored and retrieved locally on the SIM card, reducing dependence on cloud infrastructure and minimizing potential vulnerabilities. This local token storage, complemented by the SIM's secure hardware environment, substantiates further justification for deeming transactions card-present. The application of ISO 15118 in charging transactions enhances the card-present transaction model. The establishment of a physical connection between the vehicle and charging infrastructure, coupled with the exchange of trusted certificates and ISO data points, ensures a continuous and secure transaction process. This physical connection, verified through ISO standards, aligns with the principles of card-present transactions, as it involves a sustained physical link between the charging cable and the vehicle. Furthermore, ISO 14443 facilitates secure ultra-wideband communication for transactions such as tolling, restaurant ordering, parking, and car washing, bolstering the rationale for card-present transactions. The precision of short-range communication and a standardised approach, supported by ISO standards, enhances overall security and transaction integrity, aligning with card-present standards. This alignment is evident when leveraging the SIM as an additional authentication element. In this context, transitioning from a cloud communication approach, where the vehicle retrieves a network token from the cloud to a secure enclave approach using the SIM increases overall security, especially since it involves a physical vehicle with an embedded credential (hence, car-present). Overall, combining a physical vehicle, a car key, regular user authentication with a biometric or PIN, local token storage within the SIM security enclave, and adherence to ISO standards collectively justifies a level of security that meets the requirements for a card-present transaction model. Figure 6 shows a sequence diagram method 500, which is an example implementation of the method 10 described with reference to Figure 1. This figure illustrates how different components and entities send and receive messages and data. The second device 220 (vehicle in this example) comprises a console 226 and a SIM payment application 224, which is within the SIM 222 (or another secure module). In this example, the method 500 starts with a user interacting with the console 226 to trigger a process that binds the vehicle with an existing authorised device 210. The console 226 may include software for triggering this process. In this example, the console 226 generates and displays a two-dimensional graphical depiction or representation of data (a barcode or QR code). The authorised device 210 views and decodes the QR code using its camera and installed software (e.g., a payment application issued by a financial institution or the vehicle manufacturer). The console 226 and the authorised device 210 may both be connected to a telecommunications system (e.g., a cellular network) enabling them to send and receive data over the internet. As part of this binding process, the console 226 generates data to be sent to the authorised device 210 (e.g., using the QR code, Bluetooth (RTM), Wi-Fi (RTM), etc.) that may include any one or more of: identity information of the vehicle, identity information of an installed payment application within the console 226, and security credentials associated with the vehicle 220. These security credentials are credentials that can be used by the server 230 (security service in this example) to validate the vehicle or second device 220. The security credentials may have been provisioned to the vehicle or second device 220 by the manufacturer or in the field, e.g., using generic bootstrapping architecture (GBA), Battery Efficient Security for very low Throughput Machine Type Communication (MTC) devices (BEST), etc. The authorised device 210 receives these security credentials and sends them to the security service 230. The security service 230 authenticates and validates the security credentials and if successful, provides first cryptographic material (key materials in this example) back to the authorised device 210. This enables the authorised device 210 and the vehicle 210 to initiate a secure communication channel or secure tunnel. The authorised device 210 requests identity and trust information from the SIM payment application 224 through this secure tunnel. A response from the SIM payment application 224 is provided back through the secure tunnel. The response includes second cryptographic material (the identity and trust information). This identity and trust information is sent to a scheme provider 240 (which has already authorised the authorised device 210). The identity and trust information may be sent through a second secure communication channel or secure tunnel. This second secure communication channel may have been set up as part of the authorisation process of the authorised device 210. In any case, the scheme provider 240 validates the identity and trust information and if successful (e.g., if the extension of trust to a further device is allowable for the particular user of the authorised device 210 and / or the payment application 224 in the SIM 222 of the vehicle 220 is allowed to participate in this scheme) then the scheme provider 240 passes identifiers of the payment application 224 to the issuer 250 (e.g., a card issuer). The issuer 250 may be part of the scheme provider or a separate entity. The issuer 250 also carries out validation of the request. If successful, the issuer 250 generates cryptographic transaction material (e.g., a new payment token containing PAN data for generating new transactions) and sends the cryptographic transaction material to the scheme provider 240. The token (in this example) is sent over the second secure tunnel to the authorised device 210 and then through the first secure tunnel to the console 226. This is stored in the SIM payment application 224 or secure storage within the SIM 222. The second device 220 (vehicle in this example) can generate a cryptogram associated with the PAN and use this to participate in and generate transactions (e.g., payment transactions). The cryptogram may be generated by the SIM 222 or the SIM payment application 224 in such a way that is unique to the SIM 222 (i.e., it is not possible for another device to generate the same cryptogram). The cryptogram can be validated as part of the transaction procedure. The PAN or DPAN and cryptogram provide secure transactions for the vehicle 220. Figure 7 shows a schematic diagram of a further example implementation. The numbers represent steps taken to authorise a device and perform a transaction. 1. a.) A user enters their IBAN (or other account identifier) using their vehicle administration account. Alternatively, the IBAN may be retrieved from a vehicle administrator (e.g., for available to dealerships or fleet managers). b.) The IBAN is associated with the user account. 2. The payment application 224 saves the IBAN with customer information (e.g., name, address, phone number, etc.), scans the customer ID, and sends this information to their bank or scheme provider during and onboarding process. 3. a.) The bank or scheme provider receives customer information (e.g., over a telecommunications network), performs a risk check, and issues a decoupled debit card associated with the IBAN. b.) The bank issues a credit card network token c.) The network token (1) and customer ID token (2) is sent back to the vehicle SIM 222 and payment application 224. 4. The (1) network token &(2) customer ID token is bound with the vehicle SIM 222 and a secure storage (vault) of the payment application 224 for secure in-car storage. 5. A customer initiates payment with a third-party service. 6. The ID token can be sent for all transactions to seamlessly authenticate for third-party KYC / identification requirements. 7. The third-party acquirer routes the transaction to the issuer 250. 8. The network token sent to the issuer 250 is routed as a payment request to the scheme provider 240 for payment authorization. 9. The network token payment request is authorised by the scheme provider 240, who debits the customer IBAN, and remits funds back to the third-party acquirer for payment. 10. Transaction is complete and third-party services are delivered. The method and system may be implemented in hardware, software, or a combination of hardware and software. The method and system may be implemented either as a server comprising a single computer system or as a distributed network of servers connected across a network. Any kind of computer system or other electronic apparatus may be adapted to carry out the described methods. As used throughout, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as an ion multipole device) means "one or more" (for instance, one or more ion multipole device). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including but not limited to", and are not intended to (and do not) exclude other components. Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true, “B is true”, or both “A” and “B” are true. The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the disclosure and does not indicate a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. The terms “first” and “second” may be reversed without changing the scope of the disclosure. That is, an element termed a “first” element may instead be termed a “second” element and an element termed a “second” element may instead be considered a “first” element. Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed. It is also to be understood that, for any given component or embodiment described throughout, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. It will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise. Unless otherwise described, all technical and scientific terms used throughout have a meaning as is commonly understood by one of ordinary skill in the art to which the various embodiments described herein belongs. As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims. For example, whilst payment transactions have been described in the example implementations, other transaction types may be used, especially where secure transfers of data are required. The specific examples describe the unauthorized device being a vehicle (e.g., a car, van, truck, motorbike, etc.). However, other device types may be used, including loT devices and other devices owned by users (e.g., second phones, tablets, laptops, etc.). Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

Claims

1. A method for generating secure transactions, the method comprising the steps of:a first device receiving from a second device a first request for transaction authorisation, wherein the first device is authorised to generate transactions;the first device receiving from the second device security credentials associated with an identifier of the second device;the first device sending the security credentials associated with the identifier of the second device to the server;after validating the security credentials associated with the identifier of the second device, the server responding to the first device with first cryptographic material;the first device and the second device initiating a first secure communication channel using the first cryptographic material provided by the server;the second device providing the first device with second cryptographic material using the first secure communication channel, wherein the second cryptographic material is obtained from a security module within the second device;the first device sending a second request to authorise the second device for transactions with a transaction provider, wherein the request is based on the second cryptographic material and sent using a second secure communication channel;when the transaction provider validates the second request, the transaction provider sends a cryptographic transaction material to the first device using the second secure communication channel, wherein the cryptographic transaction material authorises the second device to generate transactions; andthe first device sending the cryptographic transaction material to the second device using the second secure communication channel.

2. The method of claim 1 further comprising the step of the transaction provider obtaining permission from an issuing authority before generating the cryptographic transaction material.

3. The method according to any previous claim, wherein the security module is a UICC, SIM, or eSIM.

4. The method according to any previous claim, wherein the first secure communication channel is secured between a first SIM of the first device and a second SIM of the second device.

5. The method according to any previous claim further comprising the step of the second device storing the cryptographic transaction material within the security module.

6. The method according to any previous claim, wherein the first request is received from the second device by the second device displaying a QR code to a camera of the second device.

7. The method according to any previous claim, wherein the second cryptographic material is obtained from a security module within the second device using an application within the security module.

8. The method according to any previous claim, wherein the transactions are payment transactions and the transaction provider is a payment provider.

9. The method according to any previous claim further comprising the step of the second device using the cryptographic transaction material to initiate a transaction with the transaction provider.

10. The method according to any previous claim, wherein the cryptographic transaction material is a transaction authorisation token.

11. The method of claim 10, wherein the transaction authorisation token is associated with or comprises a payment account number (PAN) and / or cryptogram data.

12. The method according to any of claims 1 to 9, wherein the cryptographic transaction material is a digital certificate.

13. The method according to any of claims 1 to 12, wherein the cryptographic transaction material is encrypted by the transaction provider and decrypted by the second device.

14. The method of claim 13, wherein the encrypted cryptographic transaction material is decrypted by the security module of the second device.

15. The method of claim 13 or claim 14, wherein one or more keys used to encrypt and / or decrypt the cryptographic transaction material are agreed between the transaction provider and the second device using the server.

16. A non-transitory computer-readable medium storing instructions that, when read by one or more processors, cause the one or more processors to carry out the method according to any of claims 1 to 15.

17. A system comprising:a second device comprising a security module configured to provide second cryptographic material and security credentials associated with an identifier of the second device, and to receive a cryptographic transaction material;a server comprising:a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the server to:receive security credentials associated with the identifier of the second device; and after validating the security credentials associated with the identifier of the second device, responding with first cryptographic material;a transaction provider configured to provide over a second secure communication channel a cryptographic transaction material to authorise the second device to generate transactions after validating a second request; anda first device authorised to generate transactions and comprising:a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the first device to:receive from the second device a first request for transaction authorisation;send the security credentials associated with the identifier of the second device to the server;receiving the first cryptographic material from the server;initiate a first secure communication channel with the first device using the first cryptographic material provided by the server;receive from the first device the second cryptographic material using the first secure communication channel;send the second request to authorise the second device for transactions to the transaction provider using the second secure communication channel, wherein the request is based on the second cryptographic material; andreceive from the transaction provider the cryptographic transaction material.

18. The system of claim 17, wherein the first device is any one of: a mobile telephone; a laptop computer; or a remote computer system.

19. The system of claim 17 or claim 18, wherein the second device is any one of: a vehicle; a mobile telephone; or an Internet of Things (loT) device.

20. The system according to any of claims 17 to 19 further comprising an issuing authority configured to grant permission to the transaction provider to generate the cryptographic transaction material for the second device.

21. The system according to any of claims 17 to 20, wherein the security module of the second device is a IIICC, SIM, or eSIM.

22. The system according to any of claims 17 to 21, wherein the security module is further configured to store the cryptographic transaction material.

23. The system of claim 22, wherein the security module is further configured to store the cryptographic transaction material in a certificate store or a token store of the security module.AMENDMENTS TO THE CLAIMS HAVE BEEN FILED AS FOLLOWS:-27CLAIMS:

1. A method for generating secure transactions, the method comprising the steps of:a first device receiving from a second device a first request for transaction authorisation, wherein the first device is authorised to generate transactions;the first device receiving from the second device security credentials associated with an identifier of the second device;the first device sending the security credentials associated with the identifier of the second device to a server;after validating the security credentials associated with the identifier of the second device, the server responding to the first device with first cryptographic material;the first device and the second device initiating a first secure communication channel using the first cryptographic material provided by the server;the second device providing the first device with second cryptographic material using the first secure communication channel, wherein the second cryptographic material is obtained from a security module within the second device;the first device sending a second request to authorise the second device for transactions with a transaction provider, wherein the request is based on the second cryptographic material and sent using a second secure communication channel;when the transaction provider validates the second request, the transaction provider sends a cryptographic transaction material to the first device using the second secure communication channel, wherein the cryptographic transaction material authorises the second device to generate transactions; andthe first device sending the cryptographic transaction material to the second device using the first secure communication channel.

2. The method of claim 1 further comprising the step of the transaction provider obtaining permission from an issuing authority before generating the cryptographic transaction material.

3. The method according to any previous claim, wherein the security module is a UICC, SIM, or eSIM.

4. The method according to any previous claim, wherein the first secure communication channel is secured between a first SIM of the first device and a second SIM of the second device.

5. The method according to any previous claim further comprising the step of the second device storing the cryptographic transaction material within the security module.

6. The method according to any previous claim, wherein the first request is received from the second device by the second device displaying a graphical representation of data to a camera of the second device.

7. The method according to any previous claim, wherein the second cryptographic material is obtained from a security module within the second device using an application within the security module.

8. The method according to any previous claim, wherein the transactions are payment transactions and the transaction provider is a payment provider.

9. The method according to any previous claim further comprising the step of the second device using the cryptographic transaction material to initiate a transaction with the transaction provider.

10. The method according to any previous claim, wherein the cryptographic transaction material is a transaction authorisation token.

11. The method of claim 10, wherein the transaction authorisation token is associated with or comprises a payment account number (PAN) and / or cryptogram data.

12. The method according to any of claims 1 to 9, wherein the cryptographic transaction material is a digital certificate.

13. The method according to any of claims 1 to 12, wherein the cryptographic transaction material is encrypted by the transaction provider and decrypted by the second device.

14. The method of claim 13, wherein the encrypted cryptographic transaction material is decrypted by the security module of the second device.

15. The method of claim 13 or claim 14, wherein one or more keys used to encrypt and / or decrypt the cryptographic transaction material are agreed between the transaction provider and the second device using the server.

16. A non-transitory computer-readable medium storing instructions that, when read by one or more processors, cause the one or more processors to carry out the method according to any of claims 1 to 15.

17. A system comprising:a second device comprising a security module configured to provide second cryptographic material and security credentials associated with an identifier of the second device, and to receive a cryptographic transaction material;a server comprising:a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the server to:receive security credentials associated with the identifier of the second device; and after validating the security credentials associated with the identifier of the second device, responding with first cryptographic material;a transaction provider configured to provide over a second secure communication channel a cryptographic transaction material to authorise the second device to generate transactions after validating a second request; anda first device authorised to generate transactions and comprising:a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the first device to:receive from the second device a first request for transaction authorisation;send the security credentials associated with the identifier of the second device to the server;receiving the first cryptographic material from the server;initiate a first secure communication channel with the second device using the first cryptographic material provided by the server;receive from the second device the second cryptographic material using the first secure communication channel;send the second request to authorise the second device for transactions to the transaction provider using the second secure communication channel, wherein the request is based on the second cryptographic material;receive from the transaction provider the cryptographic transaction material; and send the cryptographic transaction material to the second device using the first secure communication channel.

18. The system of claim 17, wherein the first device is any one of: a mobile telephone; a laptop computer; or a remote computer system.

19. The system of claim 17 or claim 18, wherein the second device is any one of: a vehicle; a mobile telephone; or an Internet of Things (loT) device.

20. The system according to any of claims 17 to 19 further comprising an issuing authority configured to grant permission to the transaction provider to generate the cryptographic transaction material for the second device.

21. The system according to any of claims 17 to 20, wherein the security module of the second device is a IIICC, SIM, or eSIM.

22. The system according to any of claims 17 to 21, wherein the security module is further configured to store the cryptographic transaction material.

23. The system of claim 22, wherein the security module is further configured to store the cryptographic transaction material in a certificate store or a token store of the security module.

Images