GB2605961A

GB2605961A - Method and system for secure transfer of confidential data

Info

Publication number: GB2605961A
Application number: GB2105421.8A
Authority: GB
Inventors: Rtveliashvili Denys
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-04-16
Filing date: 2021-04-16
Publication date: 2022-10-26
Anticipated expiration: 2041-04-16
Also published as: GB202105421D0; GB2605961B

Abstract

One or more shared secrets are established, between a provider of confidential data and a consumer, by performing key agreement communications (eg Diffie-Hellman) over communication paths S101. Symmetric keys are derived from the shared secrets S102, and used by the provider to encrypt the confidential data S103 which is then transferred to the consumer S104, using a different communication path to those used for key agreement. The provider may establish initial communication using an initially-known address for the consumer, and may then obtain an additional address of the consumer for communication between the provider and consumer. The consumer may comprise an outer layer, which communicates with the provider and an inner layer (fig. 3), which implements cryptographic operations of the consumer (key agreement and decryption) but does not communicate directly with the provider. In such embodiments the outer layer cannot access the decrypted data.

Description

Method and System for Secure Transfer of Confidential Data

Field

The specification relates to secure transfer of confidential data.

Background

Confidential data which is being transferred between entities may be protected in a number of ways in order to improve the security of the confidential data. For example, confidential data may be encrypted prior to transfer and decrypted by the receiving io entity, using a protocol such as Transport Layer Security (TLS).

Summary

According to an aspect of the present specification, there is provided method for secure transfer of confidential data between a provider of confidential data and a consumer of the confidential data, the method comprising: performing key agreement communications over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; deriving one or more shared symmetric keys based on said one or more shared secrets; encrypting the confidential data, by the provider, using one or more of the shared symmetric keys to generate encrypted data; transferring the encrypted data from the provider to the consumer; decrypting the encrypted data by the consumer; wherein transfer of the encrypted data is performed over different paths to the paths used for the key agreement communications.

The method may further comprise: the provider establishing initial communication with the consumer at an address of the consumer which is initially known to the provider; and obtaining from the consumer, by the provider, at least one additional address of the consumer for communication between the provider and the consumer, wherein each path between the provider and consumer is determined at least partially by a corresponding combination of an address of the provider and addresses of the consumer.

Key agreement -a procedure resulting in establishing a shared secret by the provider and the consumer without transmitting the secret itself -may be based on a variant of 35 Diffie-Hell man key agreement protocol.

Two or more key agreements using one or more different cryptosystems may be performed.

Messages relating to a given transfer of confidential data may comprise a transfer-5 specific identifier in order to identify which given transfer of confidential data those messages correspond to.

The paths between the provider and the consumer may be provided with one or more additional protective methods. The one or more additional protective methods may u) comprise one or more of: encrypted channels provided by one or more of TLS, SSL, H'TTPS, or IPsec; steganographic channels of communication; physically secure channels of communication, such as the ones based on quantum entanglement.

Two or more symmetric keys may be used to encrypt a single item of confidential data 15 and then decrypt it.

The method may further comprise deriving a number m of shared secrets from a number n of shared secrets established by the key agreement communication.

The method may further comprise confirming an identity of the consumer to the provider.

The method may further comprise testing communications using an agent of the consumer to enable an ongoing MITM (man-in-the-middle) attack on the or communications to be revealed.

Messages constituting one or more transfers of encrypted data and/or unencrypted data may be delivered together as aggregated messages or aggregated flows of information.

The provider may be a web browser or a web page in a browser.

The consumer may be a web site or a web service.

The consumer, or a part of the consumer, may be an authentication system. -3 -

The consumer may comprise a tokenization system.

The method may further comprise: generating, by the consumer, an asymmetric key pair comprising a private key and a public key; sending the public key from the consumer to the provider over a path different to the paths used for key agreement communications; signing key agreement communications with the private key; and verifying, by the provider, the identity of the consumer using the public key.

The consumer may comprise an inner layer logically separated from an outer layer, io wherein: the inner layer of the consumer does not communicate directly with the provider, implements cryptographic operations of the consumer including performing key agreement and decrypting the encrypted data, and accesses the confidential data, and wherein the outer layer of the consumer cannot access the decrypted confidential data and communicates with both the provider and the inner layer of the consumer.

The inner layer may comprise a cryptographic unit for performing the cryptographic operations related to key agreement operations; and a data unit for decrypting and accessing the confidential data, wherein the outer layer comprises a key agreement proxy for performing key agreement communications with the provider and which communicates with the cryptographic unit, and wherein the outer layer further comprises a reception unit for performing other communications with the provider and which communicates with the data unit, wherein the data unit and key agreement proxy do not directly communicate, and the cryptographic unit and reception unit do not directly communicate. or

According to a second aspect, the specification provides a system for performing secure transfer of confidential data from a provider of confidential data to a consumer on confidential data, the system being arranged to perform the steps of the method according to the first aspect.

According to a third aspect, the specification provides a provider of confidential data, the provider being arranged to: perform key agreement communications with a consumer of confidential data over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; derive one or more shared symmetric keys based on said one or more shared secrets; encrypt the confidential data using one or more shared symmetric keys to -4 -generate encrypted data; and transfer the encrypted data to the consumer over different paths to the paths used for the key agreement communications; According to a fourth aspect, the specification provides a consumer of confidential data, 5 the consumer being arranged to: perform key agreement communications with a provider of confidential data over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; derive one or more shared symmetric keys based on said one or more shared secrets; receive encrypted data from the provider over a different path to the paths used io for the key agreement communications; decrypt the encrypted data using the one or more shared symmetric keys.

The consumer may further comprise: an outer layer and an inner layer, the outer layer being logically separated from an inner layer, the outer layer comprising: a key agreement proxy for key agreement communications with the provider; and a reception unit for the other communications with the provider including receiving encrypted data, wherein the inner layer performs cryptographic operations related to key agreements to establish the one or more shared secrets with the provider, derives the one or more shared symmetric keys, and decrypts the encrypted data, wherein the inner layer does not directly communicate with the provider.

The inner layer may comprise: a cryptographic unit which performs the cryptographic operations related to the key agreements; and a data unit which decrypts encrypted confidential data using the one or more shared symmetric keys, wherein the data unit -3 or does not communicate directly with the key agreement proxy, and the cryptographic unit does not communicate directly with the reception ii nit.

One or more key agreement proxies and a single cryptographic unit may be provided for performing key agreement communications and key agreement cryptographic 30 operations for a plurality of data units and reception units.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a flow diagram illustrating steps of a method for performing secure transfer of confidential data according to aspects of the specification; -5 -Figure 2 is a diagram illustrating transmissions between the provider and consumer according to aspects of the specification; Figure 3 is a schematic illustration of a system for performing secure transfer of confidential data; Figure 3A is a schematic illustration of a system for performing secure transfer of confidential data, demonstrating key agreement proxy and cryptographic unit servicing multiple providers and multiple simplified consumers; Figure 4 is a schematic illustration of a system for performing secure transfer of confidential data, the system comprising a tokenization system according to aspects of io the specification; Figure 5 is a schematic illustration of a system for performing secure transfer of confidential data, the system comprising a tokenisation system and authentication system according to aspects of the specification.

Detailed Description

The invention enables secure transfer of confidential data from one entity (provider of confidential data) to another entity (consumer of confidential data) by making use of different transmission paths for communications combined with encryption. The provider and consumer may be any entities, for example software systems, hardware systems, etc., although the entities are not limited hereto. The skilled person will recognise any suitable entities which may perform the function of the provider of confidential data and a consumer of confidential data.

Furthermore, while provider" and "consumer" are mentioned in singular in most or cases, it will be recognised that there may be more than one provider and more than one consumer in any of the examples described herein.

The terminology "provider" and "consumer" refer to entities which are capable of providing and consuming data respectively. For example, the provider is capable of producing data to other entities, where the data may include confidential data. Such confidential data may include personal data relating to an individual, or other kinds of confidential data. The consumer is capable of consuming the data produced by the provider. For example, the consumer may receive the data produced by the provider. The consumer may perform additional processing on the received data. -6 -

The invention involves one or more communication media between the provider and the consumer. The media support the notion of addresses at which provider and consumer can be contacted at. The information is transmitted through a communication medium from one entity to another along a path determined at least partially by the addresses of the communicating entities.

Example #1: in a telephone network, addresses may be represented by phone numbers, and the information which makes up the telephone conversation traverses a path determined by these phone numbers, the path comprising phone lines, telephone exchanges, mobile networks, etc. Accordingly, the information corresponding to the telephone conversation is transmitted between telephones of the telephone network.

Example #2: in a UDP (User Datagram Protocol), addresses are IP addresses of communicating entities, and the path is determined by the IP addresses, network 15 topology, and routing rules.

More generally, the method can be operated using a variety of different media: phone networks, mobile networks, Internet, computer networks, radio communications etc. It is assumed that at least one address of the consumer is known to the provider from the onset.

As described in more detail below, the invention protects the confidential data by transferring it in an encrypted form. or

Examples of the invention may additionally address the problem of man-in-the-middle (MITM) attacks -where an attacker compromises the communication medium and attacks the communications by standing in between the provider and the consumer and impersonating both of them. in particular, some examples address MITM attacks where an attacker would attempt to intercept all or most of communications with the consumer and would therefore have to subvert medium close to the consumer's addresses.

The specification describes examples which provide: assurance that the provider does 35 not send the data to a system other than the correct consumer and so resist the -7 -impersonation attacks; resistance to eavesdropping attacks, potentially even in case of a vulnerability in a cmitosystem, for example; and resistance to MITM attacks.

Furthermore, in situations where the provider has no practical or reliable way of 5 confirming the identity of the consumer, approaches according to aspects of the specification still allow to provide a degree of protection, as described in more detail below.

A conventional method of protecting data in motion is TLS (Transport Layer Security). io As described in more detail below, aspects of the invention are intended to provide improved security features.

In the description below the secure transfer of confidential data is performed by executing a communication protocol where the provider and the consumer send messages to each other. The messages may be provided in any suitable format. In some situations the messages can be implied. The messages may also contain additional information not covered by the protocol or be aggregated, multiplexed, or demultiplexed where beneficial for a particular implementation.

According to a first aspect, the specification provides a method for secure transfer of confidential data between a provider of confidential data and a consumer of the confidential data, the method comprising: performing key agreement communications over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; deriving one or more -3 or shared symmetric keys based on said one or more shared secrets; encrypting the confidential data, by the provider, using one or more shared symmetric keys to generate encrypted data; transferring the encrypted data from the provider to the consumer; decrypting the encrypted data by the consumer; wherein transfer of the encrypted data is performed over different paths to the ones used for key agreement communications.

The method will now be described in more detail with respect to Figure 1, which is a flow chart illustrating steps of the method. It will be appreciated that the method may include further steps in addition to the ones described herein, or in some examples 35 some of the steps may be performed in a different order to that described. -8 -

At step 8101, the method comprises the provider and the consumer performing one or more key agreement communications over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer. Each key agreement results in a shared secret being established, so that both the provider and the consumer know the secret without sending the secret explicitly. The key agreement process is described in more detail below, with reference to Figure 2.

At step 8102, each of the provider and the consumer derive symmetric keys from shared secrets. In some examples, further information may be transmitted between the provider and the consumer in order to derive symmetric keys from the shared secrets. The symmetric keys derived by the provider are the same as the symmetric keys derived by the consumer as a result of this operation.

At step 8103, the provider encrypts confidential data with the derived set of symmetric keys. To particular, the confidential data is encrypted with the derived set of symmetric keys using one or more symmetric ciphers.

At step 8104, the provider transfers the encrypted data to the consumer over a path 20 different to the paths used for key agreement communications.

At step 8105, the consumer decrypts the confidential data with the set of symmetric keys. The same symmetric ciphers and the set of symmetric keys are used to decrypt the confidential data. or

The method includes further examples described below which are intended to address the problem of MITM attacks.

Similarly to TLS, a MTTM attack on a secure transfer of confidential data operating according to the described method is hard unless there is a fault in a cryptosystem or an attacker finds a way to impersonate the communicating entities. Unlike TLS, the transfer of confidential data operating according to the described method is harder to attack because the attacker needs to subvert more than one communication path as key agreements and delivery of encrypted data are performed over different paths. -9 -

An example of the method will be further described with reference to Figure 2, which illustrates transmissions which occur between the provider and the consumer.

In some examples, the provider initially knows only one address of the consumer. The 5 provider begins by establishing initial communication with the consumer at that address already known to the provider (201). The address maybe, for example, the address of a website, telephone number, or IP (Internet Protocol) address. This initial communication can be established by provider either explicitly by sending a message to the consumer such as by sending a request from a web browser or a page in a web io browser which may be received at a server of a website or implicitly by opening a communication channel to the consumer, such as by opening a TCP (Transmission Control Protocol) connection, or by starting a telephone conversation.

In response to the provider establishing the initial communication, the consumer may reply to the provider by sending one or more additional addresses of itself (202). This results in the provider obtaining from the consumer at least one additional address of the consumer which can be used for communication between the provider and the consumer. This allows the provider and consumer to perform key agreement and transmission of encrypted data via different paths, thus improving the security of confidential data transmitted from the provider to the consumer.

The consumer may also generate a transfer identifier. The transfer identifier may have a limited lifetime, limited to the lifetime of the transfer, as described in more detail below. or

The consumer may send the transfer identifier and any desired cryptographic settings to the provider. If the consumer is providing additional addresses to the provider, the transfer identifier and cryptographic settings may be sent together with the additional addresses.

Once the provider has obtained the additional address(es) from the consumer where necessary, key agreement can be performed between the provider and the consumer (203). Key agreement is a cryptographic protocol which results in both parties of the communication establishing a shared secret (a shared secret is a secret number, for example) which is known only to these parties. The secret itself is not transmitted. By using key agreement, an attacker is prevented from being able to directly obtain the -10 -shared secret by passively intercepting the communications between the provider and the consumer. A number of key agreement communications may be performed in order to establish more than one shared secrets if desired.

Key agreement may be performed according to any suitable key agreement schema. In some examples, the key agreement is based on a Diffie-Hellman key agreement schema. For example, the key agreement may be Diffie-Hellman key exchange, ECDH (Elliptic-Curve Diffie-Hellman), STS (Station-to-Station protocol), etc. The method of the present specification is not limited to the examples of key agreements described herein.

io The skilled person will recognise any suitable key agreement schema which may be used for performing key agreement communications to establish one or more shared secrets.

In some examples, such as where the provider is not anonymous, the key agreement 15 messages sent by the provider may be signed by the provider, and verified by the consumer in order to identify the provider or to prove the identity of the provider.

The key agreement messages sent by the consumer may be signed by the consumer, and verified by the provider in order to prove the identity of the consumer to the provider.

However, the skilled person will appreciate that any suitable method for confirming the identity of the consumer may be used, examples of which are described in more detail below.

In some examples, more than one key agreement is performed for the same secure or transfer of confidential data. Performing more than one key agreement results in the increase of shared entropy, which can be used to improve the security properties of symmetric encryption.

Where more than one key agreement is performed, the agreements may all use the 30 same cryptosystem. in other examples, where more than one key agreement is performed, the key agreements may use different cryptosystems.

For example, the parties (the provider and the consumer) may perform two key agreements, where one is based on RSA and another one is based on elliptic-curve cryptography, resulting in two different shared secrets. However, it will be recognised that the cryptosystems used are not limited hereto. The skilled person will recognise any suitable cryptosystems which may be used for key agreement. Using a variety of cryptosystems has an additional benefit that in case a weakness in one of the cryptosystems is discovered by an attacker, the other cryptosystem(s) provide an additional layer (or layers) of cryptographic security.

Once the shared secret(s) are established by key agreement, symmetric keys are derived from the shared secret(s).

In some circumstances it may be beneficial to transform a first set of shared secrets ic) established via key agreements into second set of shared secrets, before using the latter for generation of symmetric keys. In general, a number n of shared secrets may be established by the key agreement communications. The method may then further comprise deriving a number of m shared secrets from the n established shared secrets. This will be described in more detail below.

Shared secrets are (or can be represented as) integer numbers within specific ranges. Therefore, to obtain m shared secrets from n initial shared secrets, a group of integer numbers are obtained in appropriate ranges from another group of integers in their respective ranges. The ranges of the numbers corresponding to the initial shared secrets are determined by the parameters of key agreements performed to establish them. This allows them to be combined using a variety of methods and combinations of methods. Some of the examples of the methods may include, but are not limited to: Example 1: Combine one or more numbers into a single number by using a linear 25 function.

Example 2: Using a modulo, addition, and subtraction operations on a number to produce another number in a desired range.

Example 3: Using one-way hash function of one or more numbers, or one or more numbers and a constant number, to produce another number, resulting in a number which belongs to a specific range and does not have an easily observable relation to the original one or more numbers.

-12 -However, the skilled person will recognise any suitable method(s), not limited to the above examples, may be used for combining shared secrets to produce further shared secrets.

There are several reasons why it may be desirable to perform this procedure of producing m shared secrets from n shared secrets.

For example, the original shared secrets may be not random enough, so using them directly to produce symmetric keys may result in weak symmetric encryption. Mixing io together shared secrets resulting from several key agreements based on a variety of cryptosystems to produce a shared secret not easily relatable to the original shared secrets has an additional advantage that in case of a failure of a single cryptosystem the other one serves as a backup.

Another example may be that a long symmetric key is required by a cipher but the shared secrets are shorter and so cannot be used directly. Therefore, combining shared secrets in particular ways may result in a shared secret meeting the requirements of the cipher.

The shared secrets, either as established by key agreement or subsequently derived shared secrets, are then used to derive one or more symmetric keys for encryption of the confidential data.

Symmetric keys are numbers which can be used by relevant cryptosystems in order to -3 or encrypt or decrypt data. The keys are derived from shared secrets and there are multiple ways of how this can be done.

In some cases this would involve sending additional data such as random numbers between the provider and the consumer.

The ways in which the symmetric keys are derived may include, but are not limited to, the methods described below. It will be recognised that the methods may be used alone or in combination.

In one example, the symmetric key is the shared secret. That is, the shared secret is used directly as the symmetric key, without any further modification.

-13 -In another example, the symmetric key is a function of a shared secret. For example, a modulo operation or a hash function can be used to ensure the value of symmetric key is in the desired range. Any suitable operation may be used provided that the consumer and provider perform the same operation on the shared secret(s) in order to derive the symmetric key(s).

In another example, a random number r in an appropriate range is generated on one of the sides of communication. The number r is the symmetric key. In order for the other io side to derive the same symmetric key r, the first one encrypts r using the shared secret (or a function of the shared secret) as a symmetric key, transmits the encrypted r to the other side, where the encrypted r is decrypted.

In another example, a random number r in appropriate range is generated on one of the sides of communication and is sent to the other side in the plain. Then both sides combine the shared secret with the random number r to derive a symmetric key. XOR, modulo, one-way hashes and other mathematical operations on integer numbers, as well as combinations thereof can be used to combine the shared secret and the random number. The skilled person will appreciate that any suitable operations may be performed on the shared secret and random number in order to derive the symmetric key.

Cryptographic operations such as key agreements and some forms of deriving symmetric keys depend on the quality of the available source of random numbers. In or exceptional circumstances where either the provider or the consumer does not have a high quality random number generator the problem may be partially mitigated by the other party (the consumer or the provider accordingly) providing a random number, which is then mixed with the locally-generated random number. A skilled person will recognise where the approach may be appropriate.

After deriving one or more symmetric keys from the shared secret(s), the provider encrypts the confidential data using the one or more symmetric keys, and transfers the encrypted confidential data to the consumer (204), where the confidential data is decrypted.

-14 -Encryption and decryption can be performed by using a variety of symmetric ciphers: stream ciphers or block ciphers.

In some cases, stream ciphers like Salsa2o, Phelix, and Rabbit can be used.

In other cases, block ciphers like AES, Blowfish, DES, Triple DES, SEED, Kalyna, and Kuznyechik can be used.

The skilled person will recognise that any suitable cipher or ciphers may be used, and that the method is not limited to the examples described herein.

Where block ciphers are used, encryption and decryption would be performed according to a given block cipher mode of operation. For example, the block cipher mode of operation may be GCM, CBC, CFB, and crR.

The skilled person will recognise that any suitable block cipher mode of operation may be used, and that the method is not limited to the examples described herein.

When encrypting the confidential data with a symmetric key, the provider may need to perform a few operations first, such as padding, chaffing, compression, winnowing, Russian copulation, or any other reversible operations in order to make the data be less predictable as well as make it be suitable for encryption by the given combination of symmetric key and symmetric cipher. The skilled person may recognise suitable operations for performing on the confidential data before encrypting it with the symmetric key. or

Some ciphers, or a combinations of ciphers, require a nonce or an initialisation vector (IV) in order to encrypt or decrypt data. This additional information is not secret but similarly to encryption keys it must be available to both provider and consumer in order to encrypt and then decrypt confidential data. Where required, the nonce or initialisation vector is generated by one of entities and then transmitted to other entities which require it.

In some examples, the nonce or the initialisation vector is generated by one of the entities, i.e. the provider or consumer, as a random or pseudorandom number in a 35 required range.

-15 -In other examples, the nonce or the initialisation vector is a function of other data. For example, the data may comprise shared secrets, addresses of the provider and the consumer, current time, random or pseudorandom numbers, and so on.

In some examples, the nonce or the initialisation vector is generated by the provider and is sent to the consumer prior to the key agreement procedure.

In other examples, the nonce or the initialisation vector is generated by the provider and is sent to the consumer as an additional data during the key agreement procedure.

In other examples, the nonce or the initialisation vector is generated by the consumer and is sent to the provider as an additional data during the key agreement procedure.

In other examples, the nonce or the initialisation vector is generated by the consumer 15 and is sent to the provider along with the encrypted data.

In other examples, the nonce or the initialisation vector is generated by the consumer and is sent to the provider after key agreement procedure but separately from the encrypted data.

In other examples, the nonce or the initialisation vector are generated independently and identically by the consumer and the provider based on the data which is available to both of them. The examples of the data are shared secrets, current time, and addresses of the provider and the consumer.

The skilled person will recognise that the list of approaches for generating and distributing nonces and initialisation vectors is non-exhaustive and will recognise and choose suitable approaches based on their merits in a specific circumstances.

Where more than one symmetric key is available for protecting a single item of confidential data, a number of approaches is possible.

For example, it is possible to encrypt the data with a first key, then encrypt the encrypted data with a second key, and so on. The decryption process would decrypt the 35 data key-by-key in the reversed direction. That is, the final key used to encrypt the data -16 -is the first key to decrypt the data, and the first key used to encrypt the data is the final key to decrypt the data.

In some examples, block ciphers are used and it is possible to encrypt the data block by 5 block using a chosen block cipher mode of operation by varying symmetric keys used to encrypt different blocks. If multiple symmetric ciphers are in use it may be possible to vary ciphers from block to block.

The skilled person will recognise that any suitable approach for decrypting and io encrypting a single item of confidential data may be used, and that the method is not limited to the examples described herein.

In many situations more than one secure transfer is performed. Each transfer may be made up of a number of messages and it is important for the provider and the consumer to be able to distinguish between messages related to different secure transfers. In order to achieve that the provider and the consumer may use transfer-specific identifiers and include these identifiers in the messages sent to each other, as described above.

In some examples, transfer-specific identifiers may have limited lifetimes. For example, an identifier may expire after a defined period of time after its allocation or use. Also, an identifier may expire for the purposes of key agreements as soon as a given number (one, for example) of key agreement operations related to the identifier are performed. Also, an identifier may expire for the purpose of obtaining a shared secret in the or consumer as soon as a given number (one, for example) of operations relating to obtaining a shared secret in the consumer are performed.

In the example described above, the consumer generates the transfer-specific identifier, however more generally, the transfer-spccific identifiers can be generated either by provider or the consumer. In case more than one provider or more than once consumer are involved there is a possibility that the same identifier would be generated by different systems for different transfers. In that case it is still possible to tell which transfers messages correspond to by considering both the identifiers and the addresses of the communicating systems.

-17 -Not every message has to be attributed to a specific data transfer and therefore not every message needs to have an identifier included. For example, requests for additional addresses of the consumer and responses to those requests are examples of messages which may not require a transfer-specific identifier.

A given transfer of data may comprise encrypted confidential data, unencrypted data, or a combination of encrypted and unencrypted data. Messages constituting transfers of encrypted confidential data and/or unencrypted data may be delivered together as aggregated messages or aggregated flows of information.

In some examples, such as where the provider is not anonymous, the provider may sign the data in order to prove the identity of the provider to the consumer.

To further improve the security of communications, the method may comprise 15 confirming the identity of the consumer. In this way, confidential data is not transferred to the wrong recipient.

A number of methods can be employed in order to ascertain the identity of the consumer. It will be recognised by the skilled person that the examples of confirming 20 the identity of the consumer listed below may be used individually or in various combinations.

In one example, the identity of the consumer may be confirmed according to the well-known address or addresses of the consumer. Where messages received by the provider or appear to be sent from the previously known and reliable address of the consumer then the provider concludes the messages were indeed sent by the consumer. The method is usually straightforward to implement. However, in some examples, an attacker has a capability to execute a MFFM attack where messages from the provider to the consumer are intercepted and the attacker can generate new messages for providing to the provider which appear as if they are coming from the consumer. The practicality of the attack may be dependent on the specific communication media between the provider and the consumer.

In another example, the identity of the consumer may be confirmed by making use of 35 public-key cryptography. One or more key pairs are used where the consumer signs its messages with one of its private keys, while the provider verifies the messages using the -18 -corresponding public key. The method depends on the security of the private key which may be burdensome in some situations. The method allows for a plurality of private-public keys to exist with the provider accepting signatures verifiable by a set of public keys. This allows the provider and the consumer to introduce new private-public key pairs and phase out old private-public key pairs.

In another example, the consumer generates a new asymmetric key pair for each transfer and sends the public key to the provider along with the transfer-specific identifier over a path which is not used for key agreements. Then, the consumer uses io the private key to sign its messages to the provider when participating in key agreement operations. This allows the provider to verify the signatures and confirm that on the consumer's side the communications over key agreement path and the other path are likely under control of the same entity and therefore the likelihood of a successful ongoing MITM attack on either key agreement path or the other path separately is low.

In another example, the identity of the consumer may be confirmed by making use of PKI (public key infrastructure). In this method the consumer would sign its messages with a private key and the provider would verify them with a public key, while a third party certifies that the consumer is the rightful owner of the corresponding asymmetric key pair. In some examples the third party may distribute corresponding public keys on behalf of the consumer. In other examples, the third party may confirm whether the public key presented by the consumer does correspond to the consumer. In other examples, the PM may make use of digital public key certificates, such as the ones defined by X.5o9 standard. or

In another example, the identity of the consumer may be confirmed by the secure transport used to deliver data between the provider and the consumer. In some examples, technologies such as TLS, HTTPS, or IPsec can be used to further protect data in motion and provide guarantees in regards to identity of communicating systems. in these cases the provider may rely on the capabilities of the secure transport to identify the consumer. in some examples different technologies may be used for different paths of communication between the provider and the consumer.

The method of the present specification is not limited to the examples described herein.

-19 -While each example listed above has its limitations and costs, the skilled person will recognise any suitable method(s) or combination thereof which can be utilised to achieve the required level of assurance given the specific circumstances.

Additional security mechanisms can be used to protect communications between the provider and the consumer and/or to identify the parties to each other. Examples of such mechanism include, but are not limited to: TLS, HTTPS, IPsec, SSH, steganographic channels of communication, physically secure channels of communication (such as communication mechanisms leveraging quantum mechanics), etc. The skilled person will recognise any suitable additional security mechanisms in order to further protect communications between the provider and the consumer and/or to identify the parties to each other. Such methods may provide confidentiality, acting as an additional line of defence against attacks. They may also provide a confirmation of consumer's identity, to confirm that the data being sent would be delivered to the correct recipient.

A man-in-the-middle (MUM) attack is an attack where communications may be intercepted by an attacker posing as the consumer to the provider and occasionally posing as the provider to the consumer. This allows the attacker to decrypt and potentially modify the data sent by the provider to the consumer. If unnoticed, the attack can be active for a long time with neither the provider nor the consumer being aware that information is being intercepted. For a successful attack, an attacker has to intercept all paths used by the provider and the consumer and actively take part in the communication protocol. The attacker may then attempt to impersonate the consumer or when communicating with the provider and may also impersonate the provider when communicating with the consumer.

The method according to the present specification has an advantage against MITM attacks targeting the consumer in that the attacker has to intercept and actively alter communications via more than one path in order to access communications related to both the transfer of encrypted data and the key agreement, as they are performed over different paths. By itself this can create significant practical difficulties for the attacker.

In addition, as described in more detail below, the method may comprise testing 35 communications using an agent of the consumer to enable a M1TM attack on the communications to be revealed.

-20 -In some examples, the consumer may change some of its addresses while keeping others fixed. Therefore, where an attacker commits time and resources to prepare a MITM attack on a first set of communication paths, a change in the addresses results in communications being sent over a second set of communication paths, and the attacker would need to determine the new paths over which the communications are being sent after the change in addresses, and would need to prepare a new attack on the new set of paths.

u) In other examples, the consumer may be configured to discover an ongoing MITM attack by using an agent of the consumer to perform a test. An agent is an entity which acts as if it is the provider and begins the communications with the consumer in the same way the provider would. The agent may, but does not have to, deliver encrypted data to the consumer. The agent and the consumer perform key agreement steps (for example as described with reference to Figure 1, step Slot and Figure 2, 203). After performing the steps the agent compares its records with the records of communications on the consumer's side. As the communications between the agent and the consumer involve one or more transfer-specific identifiers, each of the identifiers as observed by the agent is expected to be also known to the consumer.

Furthermore, the messages related to each individual key agreement must match when records of the agent and the consumer are compared. Any discrepancies in the records of the agent and consumer with regard to key agreement messages or transfer-specific identifiers signal that there is an ongoing MITM attack, while the lack of discrepancies suggests that no MITM attack is happening along the paths between the agent and the or consumer. Repeated tests with the agent communicating with the consumer from a variety of addresses can help to increase the probability of discovering a MITM attack.

A system 300 for performing the method described herein is illustrated in Figure 3. The system 300 comprises a provider 310 of confidential data and consumer 320 of the 30 confidential data. The system is configured to perform secure transfer of confidential data from the provider 310 to the consumer 320.

According to an aspect, the specification provides a provider 310 arranged to perform key agreement communications with the consumer 320 over one or more paths 330 35 between the provider 310 and the consumer 320, to establish one or more shared secrets between the provider 310 and the consumer 320. The provider 310 derives one -21 -or more shared symmetric keys based on the one or more shared secrets. The provider 310 encrypts the confidential data using one or more of the shared symmetric keys to generate encrypted data, and transmits the encrypted data to the consumer 320. The encrypted data is transferred to the consumer 320 over different paths 340 to the key agreement communications.

According to another aspect, the specification provides a consumer 320 arranged to perform key agreement communications with the provider 310 over one or more paths 330 between the provider 310 and the consumer 320, to establish one or more shared /0 secretes between the provider 310 and the consumer 320. The consumer 320 derives one or more shared symmetric keys based on one or more shared secrets. The consumer 320 receives encrypted data from the provider 310 over a different path 340 to the key agreement communications, and decrypts the encrypted data using the one or more shared symmetric keys.

The provider 310 and consumer 320 communicate with each other via a plurality of transmission paths 33o, 34o. The paths 330, 340 are determined, at least partially, by the corresponding addresses of the consumer 320. The system is configured to perform any of the method steps as described above with reference to Figures 1 and 2.

Transmission path 330 may be a single transmission path. In some examples, transmission path 330 may comprise a plurality of transmission paths.

The transmission path 340 may be a single transmission path. In some examples, the transmission path 340 may comprise a plurality of transmission paths.

In some examples, all addresses of consumer 320 are initially known to the provider 310 and therefore all transmission paths 330 and 340 are initially defined.

In other examples, at least one of the addresses of the consumer 320 is initially known while at least one of the addresses is initially unknown. in such examples the provider 310 would contact with the consumer 320 and the consumer 320 would provide the provider 310 with one or more additional addresses of the consumer 320 which are not initially known to the provider 310 (for example at steps 201 and 202 of Figure 2 as described above). The result of the procedure is that a plurality of addresses of the consumer 320 defining the transmission paths 330 and 340 becomes known to the provider 310.

-22 -Key agreement operations between the provider 310 and the consumer 320 are performed over path(s) 330. Transmission of encrypted confidential data is performed over path(s) 340. As described above, the use of different transmission paths for transmission of confidential data to the paths used for key agreement provides additional security in the case that one of the paths is intercepted by an attacker.

In a case of computer systems, there may be a risk of an attacker finding and exploiting a vulnerability in a system, resulting in that system being subverted and all unprotected data available to the system being exposed. The consumer 320 can be seen as a valuable io target open to potential attacks by external parties. Some measures of protecting the consumer 320 from attacks exploiting vulnerabilities (including zero day vulnerabilities) are described below.

The consumer 320 will now be described in more detail.

In some examples the consumer 320 can be split into two layers: an outer layer 326 and an inner layer 323. The layers do not necessarily correspond to individual systems. They are a logical separation and each layer may comprise more than one system. Similarly, both layers may be a part of a single system. The inner layer 323 performs cryptographic operations (key agreements as well as decryption of confidential data) and may work with the decrypted confidential data but is not allowed to communicate with the provider 310 directly. The outer layer 326 communicates with the provider 310 directly but is not performing cryptographic operations related to the secure transfer of data and does not access the confidential data in the decrypted form. This separation allows the consumer 320 to be resistant to attacks where an attacker is able to find and or exploit a vulnerability in the systems directly visible to the attacker (the outer layer 326). A successful attack on the outer layer 326 does not allow access to unencrypted confidential data.

Additionally, attempts by an attacker to perform a MITM attack can be noticed with the help of a testing agent as described above. The effectiveness of the protection may be improved by reducing the size of an attack surface of the system or systems constituting the inner layer 323, and by controlling and monitoring the communications between the inner layer 323 and the outer layer 326.

The outer layer 326 may be split into two logical parts. In the example of Figure 3, the two logical parts comprise key agreement proxy 321 and reception unit 322. Key -23 -agreement proxy 321 may be configured to deal exclusively with key agreement communications with the provider 310. The path(s) 330 provides for key agreement communications to be received at the consumer 320 at an address corresponding to the key agreement proxy 321. The key agreement proxy 321, being part of the outer layer 326, does not perform cryptographic operations related to key agreements.

Reception unit 322 may deal with the rest of communications with the provider 310. Reception unit 322 may therefore be configured to receive communications transmitted from the provider 310 via path(s) 340. The communications between the provider 310 io and consumer 320 received via path(s) 340 at the reception unit 322 include transfer of confidential data encrypted by the provider 310 to the reception unit 322 of the consumer 320.

In some examples, the key agreement proxy 321 and the data reception unit 322 are unable to communicate directly with one another. By preventing communication between the key agreement proxy 321 and the reception unit 322, MITM attacks through subversion of outer layer 326 may be rendered more difficult: the attacker would have to find and exploit vulnerabilities in both the key agreement proxy 321 and the reception unit 322. Furthermore, the attacker would need to find a way to co-ordinate the actions of both subverted parts.

However, the key agreement proxy 321 and reception unit 322 can communicate with the provider 310 and with the inner layer 323.

The inner layer 323 of the consumer 320 performs the cryptographic operations or relating to key agreement, establishes the one or more shared secrets, derives the one or more shared symmetric keys, and decrypts the data. The inner layer 323 does not communicate directly with the provider 310. Instead, all transmissions from the provider 310 are received at either the key agreement proxy 321 or the reception unit 322, depending on the messages being transmitted from the provider 310.

In some examples, the inner layer 323 may be divided into a cryptographic unit 324 and a data unit 325. The cryptographic unit 324 performs the cryptographic operations related to the key agreement operations and derives the shared secrets. In some examples, the cryptographic unit 324 is the only part of the consumer 320 which is responsible for cryptographic operations related to key agreement.

-24 -Depending on the particular implementation, one or more symmetric keys are derived from the shared secrets either by cryptographic unit 324 or by data unit 325.

The final decryption of the confidential data may be performed by the data unit 325 using the one or more symmetric keys. The decrypted data may subsequently be used or processed further by the consumer 320 as appropriate in the particular circumstances. While the data unit 325 may access and make use of the decrypted data, the cryptographic unit 324 cannot.

The data unit 325 does not directly communicate with the key agreement proxy 321.

Similarly, the cryptographic unit 324 does not communicate directly with the reception unit 322. In this way, the flow of information inside of the consumer 320 is well defined and can be controlled with ease. In particular, the key agreement proxy 321 communicates with the cryptographic unit 324 and these communications can carry information related to key agreements but do not carry symmetric keys or encrypted or decrypted confidential data. The cryptographic unit 324 communicates with the data unit 325 and these communications can carry shared secrets, symmetric keys, transfer-specific identifiers, and other auxiliary information but do not carry encrypted or decrypted confidential data or key agreement communications. The data unit 325 communicates with the reception unit 322 and these communications can carry encrypted confidential data, transfer-specific identifiers, and other auxiliary information but do not carry symmetric key for decrypting the encrypted confidential data or key agreement communications or shared secrets.

The consequence of this arrangement is that the cryptographic unit 324 and the key agreement proxy 321 do not access the confidential data even in an encrypted form or while data unit 325 and reception unit 322 do not participate in key agreements or deriving the symmetric keys for decrypting the confidential data.

However, in some examples, the reception unit 322 may communicate with the cryptographic unit 324 directly. For example, the reception unit 322 may indicate to the cryptographic unit 324 that assistance with a secure transfer is required. The cryptographic unit 324 may provide the transfer-specific identifier and alternative address of the consumer 320 directly via the reception unit 322, bypassing the data unit 325. This may simplify implementation in some cases however it will be recognised that the security properties of the consumer 320 may be stronger where the reception unit 322 and cryptographic unit 324 are not able to communicate directly.

-25 -In some examples, as illustrated with reference to Figure 3a, for example, a combination of one of more key agreement proxies 321 together with the cryptographic unit 324 can act as a service for multiple simplified consumers 320a, 3201), which do not contain their own key agreement proxies and cryptographic units and contain only data units 325a, 325b, and reception units 322a, 322b.

Such a service may allocate transfer-specific identifiers, perform key agreement operations, and derive symmetric keys. The service may also provide for data units 325a, 325b to make use of its functionality by arranging for new secure transfers and io obtaining the relevant transfer-specific identifiers and any required auxiliary information, as well as obtaining the symmetric keys for decrypting the confidential data. The service may also implement access control so that its functionality is accessible only according to specified rules.

Furthermore, the cryptographic unit 324 may be configured to enforce separation of roles and recognise ownership of secure transfers. in some examples, the cryptographic unit 324 may allow only some of the consumers 320a, 320b to request new secure transfers and would allocate transfer-specific identifiers appropriately. In some examples, the cryptographic unit 324 may allow only some of the consumers 320a, 320b to obtain a shared secret or a symmetric key corresponding to a specific secure transfer as identified by a transfer-specific identifier.

In the example of Figure 3a, the providers 31oa, 310b can only communicate with the key agreement proxy 321 and reception units 322a, 322b, such that the key agreement proxy 321 and reception units 322a, 322b correspond to the outer layer 326 of Figure 3.

-3 or The cryptographic unit 324 and data units 325a and 325b do not communicate directly with the providers 3ioa, 31ob, and as such correspond to the inner layer 323 of Figure 3.

In some examples, the consumer 320 or at least part of the consumer 320 may comprise an authentication system. An authentication system is a system which provides for verification of the identity of an entity. in many cases the entity to be authenticated is a human. In most cases the approach involves the entity producing its identification (such as user name, user number, e-mail address, passport number) to the authentication system. In addition to that, the entity proves his / her / its authenticity by either participating in a challenge-response authentication process with -26 -the authentication system or by producing to the authentication system a secret (such as a password).

The method can be used to improve security properties of generic authentication 5 systems.

In addition to that, where a tokenization system can be used to tokenize the identifiers, in some examples an authentication system may be altered as explained in more detail below so that the authentication system (or a part of the authentication system) does io not have access to the identifiers. The method provides for a secure transfer of confidential data (the identifier in this case) from the moment where it is presented by the entity and up to the tokenization system. Once the transfer of the confidential data is complete, the tokenization system may provide the authentication system with a non-sensitive token and the authentication system may use the token instead of the identifier when implementing its authentication logic. A tokenization system will now be described in more detail with reference to Figure 4.

In some situations it is desirable to strictly control the transmission and storage of personal or business identifiers (for example, due to legal requirement or obligations).

In such situations tokenization systems may be employed to securely store these sensitive identifiers and replace them with non-sensitive tokens. Other applications would normally work with non-sensitive tokens.

However, before the identifier reaches the tokenization system and gets substituted with a token, it may often have to pass through one or more intermediate systems 401.1 or -401.n, some of which may be able to access the identifier. For example, an identifier is input through a data input system 402 such as a web browser. Then the identifier is sent to a first intermediate system 401.1 such as a web server. Then the identifier is sent to a second intermediate system 401.2 such as a messaging system. Eventually, it is sent to a final intermediate system 401.n such as an application implementing a part of business logic of the web server. And finally, the identifier is sent to a tokenization system 403. Therefore, each of the systems 401.1-401.n from input of the identifier to its tokenization may require protection. In the example described herein, three intermediate systems are listed, however the skilled person will recognise that any number of intermediate systems may be provided along the transmission pathway between the data input system 402 and tokenization system 403.

-27 -In some examples, the specification provides additional steps of the method to improve the security of a tokenization system 403, as described in more detail below. As described in more detail below, the system may be arranged substantially as described with reference to Figure 3. In particular, the data input system 402 according to 5 aspects of the specification corresponds to the provider 310 of Figure 3, and the tokenization system 403 may correspond to the consumer 320 of Figure 3. In some examples, a key agreement proxy 321 and cryptographic unit 324 may be provided remotely to the tokenization unit, as described in more detail with respect to Figure 5. The data input system 402 and tokenization system 403 may communicate via a path 404 for performing key agreement, while data such as the identifier is encrypted and sent via the intermediate systems 401.1 -401.n, as described in more detail below.

In the example of Figure 4, whenever an identifier is to be provided, a new secure transfer is arranged for by the system accepting the input, the tokenization system 403, 15 or by any intermediate system. if appropriate, the relevant information for the new secure transfer is delivered to the system directly accepting the input.

The data input system 402 and the tokenization system 403 perform the steps described with reference to Figure 1 and/or Figure 2 via path 404, in order to arrive at symmetric keys. The data input system 402 then encrypts the identifier using the symmetric key, to thus protect the identifier in motion. Then the data input system 402 sends the encrypted identifier to the next system in the chain.

Each intermediate system 401.1-401.n in the chain sends the encrypted identifier to the next intermediate system 401.1-401.n until the identifier reaches the tokenization or system 403. No intermediate system 401.1-401.n is able to decrypt the identifier, such that the identifier is only decrypted by the tokenization system 403.

The tokenization system 403 decrypts the identifier and performs the tokenization procedure.

The result is that only the data input system 402 and the tokenization system 403 are able to access the identifier in an unprotected form while all the intermediate systems 4o1.1-401.n in between do not have access to this sensitive data.

Figure 5 illustrates a sequence of communications occurring in an example in which the key agreement proxy 505 and cryptographic unit 506 are provided remotely from the -28 -tokenization system 503. For example, the cryptographic unit 506 and the key agreement proxy 505 may be provided as a service which one or more tokenization systems 503 or other consumers may make use of. An authentication system 501 may arrange for a new secure transfer (e.g. of a sensitive identifier) with the tokenization system 503 when it expects a new attempt at authentication.

Following communications from the authentication system 501 to arrange a new secure transfer, the tokenization system 503 arranges for the secure transfer with the cryptographic unit 506, which allocates a new transfer-specific identifier and io determines any relevant parameters of communications. The transfer-specific identifier and other relevant information required for the transfer is passed back to the tokenization system 503 from the cryptographic unit 506. The tokenization system 503 subsequently transmits the transfer-specific identifier and other parameters to the authentication system 501. The authentication system 501 passes that information received from the tokenization system 503 to the data input system 502. Tn this example, a user inputs an identification and proof of identification to the data input system 502.

Following input of the identification at the data input system 502, the data input 20 system 502 performs key agreement with the key agreement proxy 505 via transmission path 504_ The key agreement proxy 505 communicates with the cryptographic unit 506 and so one or more shared secrets are established between the data input system 502 and the cryptographic unit 506.

The data input system 502 derives one or more symmetric keys based the one or more shared secrets.

The data input system 502 encrypts the identifier with the one or more symmetric keys 30 and sends the encrypted identifier to the authentication system 501.

The authentication system 501 passes the encrypted identifier to the tokenization system 503. It will be appreciated that the encrypted identifier therefore passes along a different transmission path to the transmission path 504 used for key agreement.

-29 -Depending on the particular implementation, on the consumer side, either the cryptographic unit 506 derives one or more symmetric keys based the one or more shared secrets and provides the tokenization system 503 with the keys, or the cryptographic unit 5o6 provides the tokenization system 503 with the shared secrets and the tokenization system 503 derives the one or more symmetric keys based the shared secrets.

The tokenization system 503 subsequently decrypts the previously encrypted sensitive identifier.

The tokenization system 503 tokenizes the sensitive identifier and sends a non-sensitive token to the authentication system 501 so that the authentication system 501 is able to perform the rest of its authentication logic based on that token rather than the original identifier.

In some examples key agreement proxy 505 and cryptographic unit 5o6 can be implemented as a single system.

A skilled person will recognise that the approach is not limited to authentication systems -other systems accepting user input may arranged in the same way to benefit from tokenization and protection of confidentiality.

Referring again to Figure 3, there may exist some situations in which confidential data needs to be securely transferred from a web page in a web browser over a computer or network to a web site or a web service, or another computer system. The confidential data may be a form or a part of a form on a web page. The confidential data may alternatively / additionally comprise other kinds of data related to the web page. The web browser, the web page, and the scripts or applications related to the web page or the web browser may be considered to be the provider 310 of the confidential data, e.g. with reference to Figure 3, and may also correspond to the data input system 402 or 502 with reference to Figures 4 and 5.

According to examples of the method described herein, the web browser or web page already knows at least one initial address of the consumer 320. The initial address will 35 be referred to in the description hereinafter as "the main address". In some examples the main address may be an address at which the provider 310 routinely communicates -30 -with the consumer 320. For example, the main address may be a publicly known address of a web site or a web page of a web site. In many examples the communications to the publicly known address would be protected by TITTPS or WebSocket Secure.

According to the method of the present specification, the provider 310 would also either obtain one or more addresses suitable for key agreement operations, or they may already have prior knowledge of one or more addresses suitable for key agreement operations, different to the main address.

In some examples the one or more addresses for key agreement operations are obtained by the provider 310 from third-party sources such as Domain Name System (DNS). In such examples, DNSSEC or similar methods may be employed in order to protect the integrity of DNS records providing the addresses.

In other examples the provider 310 would receive the one or more addresses for key agreement operations from the consumer 320 during initial communications with the consumer 320 at the main address of the consumer 320.

In other examples the provider 310 may explicitly contact the consumer 320 at the main address, via path 340 for example, request from the consumer 320 the addresses for the key agreement operations, and receive the requested addresses for key agreement operations, which may be performed via path 330, for example.

In some examples, the provider 310 and the consumer 320 may agree on the specific or configuration of one or more secure data transfers to be performed and may agree on the corresponding transfer-specific identifiers. This process of agreement can be either explicit, where the provider 310 explicitly initiates it, or implicit, where the provider 310 is provided with the information by the consumer 320 during the initial communication between them.

For example, the web browser (the provider 310) may request a new page from the web server (the consumer 320). The web server may then send the web page to the provider 310 and the page may contain a form to be filled out with confidential information as well as one or more sets of data required for secure transfers such as provisional transfer-specific identifiers, cryptographic configurations to be used, and possibly -31 -addresses to be used for the key agreement operations. A single form on a web page may contain a mix of confidential and non-confidential data.

It may also be necessary to protect different confidential data in the form separately. This may be important where ultimately the data will be consumed by separate systems. For example, a form may contain person's e-mail address and medical details. In some examples it may be important that the e-mail address is delivered to a tokenization system, such as that described with reference to Figures 4 and 5, while the medical details are delivered to a medical database. Therefore, it may be appropriate to securely transfer this data as two secure transfers even though the data is initially io contained in a single form on a web page. Once the data is ready, scripts on the page or an application servicing the page or a web browser where the page is opened would perform key agreement operations with the consumer 320, derive symmetric keys, encrypt the confidential data, package the unencrypted non-confidential data (if any), encrypted confidential data, and any other auxiliary information, and send all of it to the consumer 320.

When the provider 310 communicates with the consumer 320 at its main address e.g. via path 340 or addresses for key agreements e.g. via path 330, the communications can happen via HTTPS and WebSocket Secure. It will be recognised that the communications may happen via HTTP, WebSocket, or indeed any other suitable communication protocol available for both parties.

In some examples the web site or a web service allocates transfer-specific identifiers, performs key agreements, accepts data from the provider 310, decrypts it, and uses it directly. or

Web sites and web services are often complex applications with a large attack surface.

As a result of that, costly security reviews may have to be done every time they are changed. By separating the applications into the inner layer 323 and the outer layer 326 as explained above with reference to Figure 3, it is possible to achieve the following 30 benefits: exploitation of zero day vulnerabilities by an attacker does not lead to exposure of confidential data and the scope of security review for the critical parts of the system is made smaller. By further splitting the outer layer 326 and the inner layer 323 as explained above, further security benefits and cost savings can be obtained.

As described above, web sites and web services often need to communicate with other 35 systems such as authentication systems and tokenization systems. In some examples, the web site or web service receives confidential data and needs to pass it to other -32 -systems but does not need to access the confidential data directly. In this case, other systems may be the final consumers, comprising a data unit 325 for decrypting and accessing confidential data. it will be understood that aspects of the specification may provide for the arrangement of final consumers with respect to a web site or web service may be done in a number of ways, as described in more detail below.

In some examples, the web site or web service requests a new transfer-specific identifier (as well as all relevant information) from a cryptographic unit 324, passes that to the provider of the confidential data. The website or web service then obtains io encrypted confidential data from the provider. It may then pass this encrypted data and the transfer-specific identifier to the final consumers. The final consumers may then use the transfer-specific identifier from the cryptographic unit 324 to obtain the symmetric key and use that key to decrypt the data. Alternatively the final consumer uses the transfer-specific identifier from the cryptographic unit 324 to obtain the shared secret from which it can derive the symmetric keys. Note, that the web site or web service are unable to decrypt the data because the cryptographic unit 324 is configured to enforce separation of duties: the web site or web application can arrange for the secure transfer to happen but the final decryption can only be done by the final consumer.

In other examples, the final consumer arranges for the secure transfer by requesting transfer-specific identifier (as well as all relevant information) from a cryptographic unit 324 The final consumer then passes this information to the web site or web service, which passes it to the provider of the confidential data. The web site or web 23 service then obtains the encrypted confidential data from the provider. Encrypted confidential data is then passed from the web site or web service to the final consumer, which retrieves the appropriate symmetric key, or a shared secret from which the symmetric key is then derived, from the cryptographic unit 324 and uses the symmetric key to decrypt the confidential data. In this arrangement the web site or web service does not need to communicate with the cryptographic unit 324 or key agreement proxies and cannot decrypt the confidential data. At the same time, the final consumer may be protected from exposure to potential attacks.

Both arrangements may correspond substantially to the arrangement of Figure 4, with 35 the web site or web service corresponding to an intermediate system 401.1-401n, and a final consumer having a cryptographic unit 324 and key agreement proxy being -33 - arranged relative to the web site or web service in the same way as the tokenization system 403 of Figure 4. The final consumer in such an example may be any suitable system of combination thereof and may or may not comprise a tokenization system 403-Similarly, the arrangements may correspond substantially to the arrangement of Figure 5, with the web site or web service arranged with respect to the provider in a similar way to the authentication system 501 of Figure 5, the final consumer being arranged in a similar way to the tokenization system, using an external cryptographic unit 506 and io key agreement proxy 505.

The provider and consumer may each comprise at least one processor and a memory. The memory may be a tangible, non-transitory memory configured to communicate with the processor. The tangible, non-transitory memory may have instructions stored thereon. When executed by the processor, the instructions may cause the provider and/or consumer to perform at least some of the method as described herein with reference to Figures 1 to 5.

Although various aspects of the invention are set out in the independent claims, other 20 aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims and not solely the combination explicitly set out in the claims.

It is noted herein that while the above describes various examples, these descriptions or should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

-34 -Claims 1. A method for secure transfer of confidential data between a provider of confidential data and a consumer of the confidential data, the method comprising: performing key agreement communications over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; deriving one or more shared symmetric keys based on said one or more shared secrets; encrypting the confidential data, by the provider, using one or more of the shared symmetric keys to generate encrypted data; transferring the encrypted data from the provider to the consumer; decrypting the encrypted data by the consumer; wherein transfer of the encrypted data is performed over different paths to the paths used for the key agreement communications.
2. A method according to claim 1 further comprising: the provider establishing initial communication with the consumer at an address of the consumer which is initially known to the provider; and obtaining from the consumer, by the provider, at least one additional address of the consumer for communication between the provider and the consumer, wherein each path between the provider and consumer is determined at least partially by a corresponding combination of an address of the provider and addresses of the consumer. or
3. A method according to claim 1 or 2, wherein key agreement is based on a variant of Diffie-Hellman key agreement protocol.
4. A method according to any of claims 1, 2, or 3, wherein two or more key 30 agreements using one or more different cryptosystems are performed.
5. A method according to any of claims ito 4, wherein messages relating to a given transfer of confidential data comprise a transfer-specific identifier in order to identify which given transfer of confidential data those messages correspond to.
6. A method according to any of claims 1 to 5, wherein the paths between the provider and the consumer are provided with one or more additional protective methods.
7. A method according to claim 6, wherein the one or more additional protective methods comprise one or more of: encrypted channels provided by one or more of TLS, SSL, HTTPS, or IPsec; steganographic channels of communication; physically secure channels of communication, such as the ones based on quantum entanglement.
8. A method according to any of claims 1 to 7, wherein two or more symmetric keys are used to encrypt a single item of confidential data and then decrypt it.
9. A method according to any of claims claim ito 8, further comprising deriving a number m of shared secrets from a number n of shared secrets established by the key agreement communication.
10. A method according to any of claims 1 to 9, further comprising confirming an identity of the consumer to the provider.
A method according to any of claims 1 to 10, further comprising testing communications using an agent of the consumer to enable an ongoing M1TM (man-inthe-middle) attack on the communications to be revealed. or
12. A method according to any of claims i to 11, wherein messages constituting one or more transfers of encrypted data and/or unencrypted data are delivered together as aggregated messages or aggregated flows of information.
13. A method according to any of claims ito 12, wherein the provider is a web browser or a web page in a browser.
14- A method according to any of claims ito 13, wherein the consumer is a web site or a web service.
15. A method according to any of claims ito 14, wherein the consumer or a part of the consumer is an authentication system.
16. A method according to any of claims ito 15, wherein the consumer comprises a 5 tokenization system.
17. A method according to any of claims 1 to 16, comprising: generating, by the consumer, an asymmetric key pair comprising a private key and a public key; io sending the public key from the consumer to the provider over a path different to the paths used for key agreement communications; signing key agreement communications with the private key; and verifying, by the provider, the identity of the consumer using the public key.
18. A method according to any of claims ito 17, wherein the consumer comprises an inner layer logically separated from an outer layer, wherein: the inner layer of the consumer does not communicate directly with the provider, implements cryptographic operations of the consumer including performing key agreement and decrypting the encrypted data, and accesses the confidential data, 20 and wherein the outer layer of the consumer cannot access the decrypted confidential data and communicates with both the provider and the inner layer of the consumer.
19. A method according to claim 18, wherein the inner layer comprises: a cryptographic unit for performing the cryptographic operations related to key agreement operations; and a data unit for decrypting and accessing the confidential data, wherein the outer layer comprises a kcy agreement proxy for performing key 30 agreement communications with the provider and which communicates with the cryptographic unit, and wherein the outer layer further comprises a reception unit for performing other communications with the provider and which communicates with the data unit, wherein the data unit and key agreement proxy do not directly communicate, 35 and the cryptographic unit and reception unit do not directly communicate.
20. A system for performing secure transfer of confidential data from a provider of confidential data to a consumer on confidential data, the system being arranged to perform the steps of the method according to any of claims ito 19.
21. A provider of confidential data, the provider being arranged to: perform key agreement communications with a consumer of confidential data over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; derive one or more shared symmetric keys based on said one or more shared io secrets; encrypt the confidential data using one or more shared symmetric keys to generate encrypted data; and transfer the encrypted data to the consumer over different paths to the paths used for the the key agreement communications;
22. A consumer of confidential data, the consumer being arranged to: perform key agreement communications with a provider of confidential data over one or more paths between the provider and the consumer, to establish one or more shared secrets between the provider and the consumer; derive one or more shared symmetric keys based on said one or more shared secrets; receive encrypted data from the provider over a different path to the paths used for the key agreement communications; decrypt the encrypted data using the one or more shared symmetric keys. or
23. A consumer according to claim 22, comprising: an outer layer and an inner layer, the outer layer being logically separated from an inner layer, the outer layer comprising: a key agreement proxy for key agreement communications with the provider; and a reception unit for the other communications with the provider including receiving encrypted data, wherein the inner layer performs cryptographic operations related to key agreements to establish the one or more shared secrets with the provider, derives the 35 one or more shared symmetric keys, and decrypts the encrypted data, -38 -wherein the inner layer does not directly communicate with the provider.
24. A consumer according to claim 23, wherein the inner layer comprises: a cryptographic unit which performs the cryptographic operations related to the key agreements; and a data unit which decrypts encrypted confidential data using the one or more shared symmetric keys, wherein the data unit does not communicate directly with the key agreement 10 proxy, and the cryptographic unit does not communicate directly with the reception unit.
25. A consumer according to claim 24, wherein one or more key agreement proxies and a single cryptographic unit are provided for performing key agreement communications and key agreement cryptographic operations for a plurality of data units and reception units.