GB2543359A

GB2543359A - Methods and apparatus for secure communication

Info

Publication number: GB2543359A
Application number: GB1518370.0A
Authority: GB
Inventors: Chawan Parashuram; Sérgio Alves Martins Paulo
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2015-10-16
Filing date: 2015-10-16
Publication date: 2017-04-19
Anticipated expiration: 2035-10-16
Also published as: GB201518370D0; GB2543359B

Abstract

A method of sending data in a secure communication system comprises receiving and storing a first private key share, obtaining a public key of an intended recipient of the data from an identity of the recipient according to an identity based public key cryptography protocol (IDPKC), encrypting the data using the obtained public key, communicating with a security mediator (SEM) to cooperatively sign the encrypted data using the first private key share and a second private key share held by the security mediator, and transmitting the signed encrypted data. A corresponding method of decrypting the signed encrypted data is also disclosed (fig. 5). In embodiments the Sakai-Kasahara Key Encryption in Multimedia Internet Keying (MIKEY-SAKKE) protocol is used. The invention enables immediate key revocation and key renewal. The encrypted data may be a shared secret value (SSV) for establishing a symmetric key. A key management entity obtains the private key and generates the first and second private key shares.

Description

Methods and Apparatus for Secure Communication Technical Field

The present invention relates to methods and apparatus for secure communication. In particular, the present invention relates to methods and apparatus for mediated Identity-based Public Key Cryptography (IDPKC).

Background

The Multimedia Internet KEYing (MIKEY) protocol defines a framework for key distribution. It provides a method for key exchange and source authentication designed for use in IP multimedia scenarios, but has a potential wider range of application. In particular, it maybe used in conjunction with the Session Initiation Protocol (SIP) and the Secure Real-time Transport Protocol (SRTP) to provide secure Voice over Internet Protocol (VoIP) communication.

The original protocol specified key distribution methods using pre-shared keys, the Rivest-Shamir-Adleman (RSA) cryptosystem, and, optionally, a Diffie-Hellman Key Exchange. With the intent of improving the latency of key distribution, since it is critical for real-time applications such as VoIP, while providing strong security, methods have been proposed to extend MIKEY, including the Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY-SAKKE) protocol which is designed for use in IP Multimedia Subsystem (IMS). MIKEY-SAKKE consists of an IDPKC scheme based on that of Sakai and Kasahara (SAKKE), and on Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI). In the context of IDPKC, the identity of users is used to derive their public-keys. A Key Management Service (KMS) is used as a root of trust, and provisions the corresponding secret-keys to the users. Whereas SAKKE is used to wrap symmetric key material, providing confidentiality, ECCSI is used for source authentication.

In IDPKC, public-keys are directly derived from the users’ identifiers, removing the need for Public-Key or Certificate servers. However, in traditional IDPKC systems there is a need to periodically force users to change their identifiers, so that if a device is compromised, its public-key can be eventually revoked from the system by instructing the KMS not to provision the device anymore. In order to achieve this, the identifiers are concatenated with a time-stamp, whose granularity dictates the validity period of a key. However, one drawback of this approach is that if the private-key of a user is compromised, an attacker may not only decipher messages directed to him, but may also sign message in his behalf while the key is valid. This prevents IDPKC-based methods being adopted in certain scenarios, such as corporate or government systems, where the credentials of a user must be able to be immediately revoked upon compromise or removal of the user from the system.

Another drawback of conventional IDPKC systems is that in the event of a device being lost or stolen, there is no efficient way to renew a user’s keys immediately to enable the user to remain in the system. Since other users expect a certain Identifier, which is only updated on certain dates, and the private-key is tied to that Identifier, immediate key renewal would require transmitting the new Identifier to all users in the system, which may not be practical.

The invention is made in this context.

Summary of the Invention

According to a first aspect of the present invention, there is provided apparatus for sending data in a secure communication system, the apparatus comprising: a storage unit configured to receive and store a first private key share (SSKi); an encryption unit configured to obtain a public key of an intended recipient of the data from an identity of the recipient, according to an identity based public key cryptography protocol, and to encrypt the data using the obtained public key; a signing unit configured to communicate with a security mediator to cooperatively sign the encrypted data, using the first private key share and a second private key share (SSK2) held by the security mediator; and a transmission unit configured to transmit the signed encrypted data.

The data to be securely transmitted can be a shared secret value SSV, and the apparatus can further comprise a shared secret value generator configured to generate the shared secret value, wherein after transmitting the signed encrypted SSV, the apparatus may be further configured to subsequently communicate with the recipient using symmetric key encryption based on the SSV.

The storage unit, encryption unit, signing unit and transmission unit may be included in a client device, and the apparatus according to the first aspect may further comprise: a key management entity separate to the client device; and the security mediator, embodied in a separate physical device to the client device and the key management entity, wherein the key management entity is configured to obtain a private key for the client device, generate the first private key share and the second private key share from the private key, send the first private key share to the client device, and send the second private key share to the security mediator.

The key management entity can be configured to perform key renewal by generating a new first private key share and a new second private key share from the private key for the client device, and send the new first private key share to the client device and the new second private key share to the security mediator.

The security mediator can comprise a permission manager configured to determine whether a client device has permission to participate in the secure communication system, wherein in response to a request from the client device to cooperatively sign the encrypted data, the security mediator is configured to only cooperatively sign the encrypted data in response to a determination by the permission manager that said client device has permission to participate in the secure communication system.

According to a second aspect of the present invention, there is provided apparatus for receiving data in a secure communication system, the apparatus comprising: a storage unit configured to receive and store a first private key share (RSKi); a receiving unit configured to receive encrypted data; an authentication unit configured to obtain a public key of a sender of the encrypted data from an identity of the sender, according to an identity based public key cryptography protocol, and to verify a signature of the received encrypted data, using a public key of the sender of the encrypted data; and a decryption unit configured to communicate with a security mediator to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the security mediator.

In some embodiments according to the second aspect, the decryption unit is configured to only decrypt the encrypted data in response to successful verification by the authentication unit.

The encrypted data can be a shared secret value SSV, and after receiving the encrypted SSV the apparatus can be further configured to subsequently communicate with the sender using symmetric key encryption based on the SSV.

The storage unit, receiving unit, authentication unit and decryption unit can be included in a client device, and the apparatus according to the second aspect may further comprise: a key management entity separate to the client device; and the security mediator, embodied in a separate physical device to the client device and the key management entity, wherein the key management entity is configured to obtain a private key for the client device, generate the first private key share and the second private key share from the private key, send the first private key share to the client device, and send the second private key share to the security mediator.

The security mediator may comprise a permission manager configured to determine whether a client device has permission to participate in the secure communication system, wherein in response to a request from the client device to cooperatively decrypt the encrypted data, the security mediator is configured to only cooperatively decrypt the encrypted data in response to a determination by the permission manager that said client device has permission to participate in the secure communication system.

According to a third aspect of the present invention, there is provided a method of sending data in a secure communication system, the method comprising: receiving and storing a first private key share (SSKi); obtaining a public key of an intended recipient of the data from an identity of the recipient, according to an identity based public key cryptography protocol; encrypting the data using the obtained public key; communicating with a security mediator to cooperatively sign the encrypted data, using the first private key share and a second private key share (SSK2) held by the security mediator; and transmitting the signed encrypted data.

According to a fourth aspect of the present invention, there is provided a method of receiving data in a secure communication system, the method comprising: receiving and storing a first private key share (RSKi); receiving encrypted data; obtaining a public key of a sender of the encrypted data from an identity of the sender, according to an identity based public key cryptography protocol; verifying a signature of the received encrypted data, using a public key of the sender of the encrypted data; and communicating with a security mediator to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the security mediator.

In some embodiments according to the fourth aspect, the encrypted data is only decrypted in response to successful verification.

According to a fifth aspect of the present invention, there is provided a computer-readable storage medium arranged to store computer program instructions which, when executed, perform any of the methods disclosed herein.

Brief Description of the Drawings

Embodiments of the present invention will now be described, byway of example only, with reference to the accompanying drawings, in which:

Figure 1 illustrates a system for secure communication, according to an embodiment of the present invention;

Figure 2 illustrates a method of securely sharing a Shared Secret Value (SSV) between a first device and a second device, according to an embodiment of the present invention; Figure 3 is a flowchart showing a method of sending data in a secure communication system, according to an embodiment of the present invention;

Figure 4 illustrates a structure of a client device and SEM for implementing the method of Fig. 3, according to an embodiment of the present invention;

Figure 5 is a flowchart showing a method of receiving data in a secure communication system, according to an embodiment of the present invention; and Figure 6 illustrates a structure of a client device and SEM for implementing the method of Fig. 5, according to an embodiment of the present invention.

Detailed Description

Referring now to Fig. 1, a system for secure communication is illustrated, according to an embodiment of the present invention. In the present embodiment, the system comprises a plurality of client devices 101,102,103, arranged to communicate over a network too, for example the Internet or a local network. Although three client devices ιοί, 102,103 are shown in Fig. l as an example, the system may generally comprise any number of client devices. The system further comprises a Key Management Service (KMS) in, and a Security Mediator (SEM) 112. The KMS 111 performs key management functions such as generating, distributing and renewing private key shares. The SEM 112 communicates with the client devices to cooperatively sign and decrypt data, as described in more detail below.

Figure 2 schematically illustrates a method of securely sharing a Shared Secret Value (SSV) between a first device 101 and a second device 102 in the system of Fig. 1. In accordance with conventional cryptographic nomenclature, an entity which is sending a message will hereinafter be referred to as ‘Alice’, and an entity with receives the message will hereinafter be referred to as ‘Bob’.

As shown in Fig. 2, the KMS 111 first produces two shares of Alice’s private-key. The first private-key share (SSKi) is transmitted to Alice 101, and the second private-key share (SSK2) to the SEM 112. Similarly, the KMS 111 produces two shares of Bob’s private-key, and distributes the first private-key share (RSKi) to Bob 102, and the second private-key share (RSK2) to the SEM 112.

When Alice wants to transmit data to Bob, she starts by randomly generating a Shared Secret Value (SSV). Afterward, she computes Bob’s public-key from his identity, and uses it to encrypt the SSV. The resulting cipher-text can only be decrypted using Bob’s private-key, and therefore if the SSV is correctly decrypted Alice has the assurance that she is communicating with Bob.

Additionally, in order to authenticate herself, Alice produces a signature of the cipher-text; however, since she only has access to a share of her private-key, she needs to cooperate with the SEM 112 to generate it. The composed message is then send to Bob, who begins by verifying the signature. After verifying that the message was produced by Alice, Bob decrypts the SSV with the help of the SEM 112. Finally, since both Alice and Bob now have a common SSV, they can use it to generate symmetric key material, and start securely transmitting data.

In the system illustrated in Figs. 1 and 2, a user’s permission to participate in the secure communication system can be immediately revoked by notifying the SEM 112. When a user is revoked, the SEM 112 will no longer cooperate with them to either sign a message when acting as the sender, or to decrypt data when acting as the recipient. Accordingly, the revoked user will not be able to complete the above-mentioned procedure. The use of a security mediator, with cooperative signing and decryption, therefore enables immediate revocation of users.

Furthermore, by distributing private-key shares to users rather than the actual private key itself, the compromise of Alice’s or Bob’s private-key share does not break the system since it is possible to generate new key shares. In embodiments of the present invention, the KMS can be configured to perform key renewal by generating a new first private key share and a new second private key share from the private key for a client device, and send the new first private key share to the client device and the new second private key share to the security mediator. In this way, the client device can continue to participate in the system even if the previous key-share has been compromised.

Embodiments of the invention will now be described in detail, in relation to specific encryption and signing algorithms based on MIKEY-SAKKE. However, it will be appreciated that the above-described advantages do not depend on a particular encryption or signing algorithm being used, and embodiments of the invention are not limited to use with MIKEY-SAKKE based protocols.

Figure 3 is a flowchart showing a method of sending data in a secure communication system. The method can be implemented by a device in a system as shown in Figs. 1 and 2, for example the device labelled ‘Alice’ in Fig. 2. In some embodiments, the method can be implemented by computer program instructions stored in a computer-readable storage medium accessible by the device. When executed, the instructions would cause the method steps shown in Fig. 3 to be performed.

First, in step S301 a first private key share (SSKi) is received from the KMS 111 and stored. Then, in step S302 a public key of an intended recipient of the data is obtained from an identity of the recipient, according to an identity based public key cryptography protocol. Next, in step S303 the data is encrypted using the obtained public key. Then, in step S304 the device communicates with the SEM112 to cooperatively sign the enciypted data, using the first private key share (SSKi) and the second private key share (SSK2) held by the security mediator. Finally, in step S305 the signed enciypted data is transmitted.

Figure 4 schematically illustrates a structure of a client device and SEM for implementing the method of Fig. 3, according to an embodiment of the present invention. The structure shown in Fig. 4 is provided for illustrative purposes only to aid understanding of the present invention, and is not intended to be limiting. The embodiment of Fig. 4 is based on the MIKEY-SAKKE protocol, but in other embodiments of the invention a different communication protocol could be used.

As shown in Fig. 4, the apparatus of the present embodiment comprises a storage unit 401, an encryption unit 402, a signing unit 403, and a transmission unit 404. The storage unit 401 is configured to store a first private key share (SSKi) provided by the KMS 111. The encryption unit 402 is configured to obtain a public key of the intended recipient of the data from an identity of the recipient (ID BOB), according to an identity based public key cryptography protocol, and to encrypt the data using the obtained public key. The signing unit 403 is configured to communicate with the SEM 112 to cooperatively sign the encrypted data, using the first private key share and a second private key share (SSK2) held by the SEM 112. The transmission unit 404 is configured to transmit the signed encrypted data. The transmission unit 404 maybe any suitable interface configured to transmit data over the network 100.

In the present embodiment the signing unit 403 is configured to use Elliptic Curve (EC) Schnorr signatures, which provide a more efficient platform to introduce a SEM than ECDSA or ECCSI signatures used in conventional MIKEY-SAKKE. However, in other embodiments a different type of signature may be applied.

As explained above, in the present embodiment the MIKEY-SAKKE protocol is used. Specifically, the encryption unit 402 is configured to use SAKKE encryption to generate SAKKE Encapsulated Data, and the transmission unit 404 is configured to create an I_MESSAGE as described in the MIKEY protocol. The encryption unit 402 is configured to wrap the data to be transmitted by creating an Encapsulated Data using Bob’s public-key, according to the SAKKE protocol. In Fig. 4, Z_T denotes the KMS public key. In the present embodiment, the private-key shares generated by the KMS 111 consists of additive shares of the private-keys of the underlying SAKKE and EC Schnorr signatures systems. However, embodiments of the present invention are not limited to use with MIKEY-SAKKE, and in other embodiments the mediated IDPKC secure communication methods disclosed herein can be used with other protocols.

Furthermore, in the present embodiment the data to be securely transmitted is a shared secret value (SSV) which can be used by both Alice and Bob to derive a symmetric key, as described above with reference to Fig. 2. Accordingly, the apparatus further comprises a shared secret value generator 405 configured to generate the shared secret value. In the present embodiment a Random Number Generator (RNG) is used, but in other embodiments the SSV maybe generated differently. After transmitting the SSV, Alice can subsequently communicate with Bob using symmetric key encryption based on the SSV. In other embodiments, a similar mechanism can be used to encrypt, sign and transmit data other than an SSV.

The SEM112 of the present embodiment comprises a storage unit 411 configured to store the second private-key share (SSK2) received from the KMS111, and further comprises a signing unit 412 for cooperatively signing the encrypted data. Additionally, in the present embodiment the SEM 112 further comprises a permission manager 413 for implementing immediate revocation of users. The permission manager 413 is configured to determine whether a client device has permission to participate in the secure communication system. For example, the permission manager 413 may query a database which stores a record of revoked users. In response to a request from a client device to cooperatively sign encrypted data, the SEM 112 is configured to only cooperatively sign the encrypted data in response to a determination by the permission manager 413 that said client device has permission to participate in the secure communication system.

In the present embodiment, the protocol for the encryption operation is adapted from the original SAKKE specification. Specifically, to encrypt the SSV the encryption unit 402 performs the following steps: (1) producing an ephemeral private-key based on the SSV and the identity of the recipient; (2) computing the recipient’s public-key by combining the recipient’s identity with the KMS public-key; (3) multiplying the public-key by the ephemeral private-key; (4) masking the SSV by XOR-ing it with a hash of the corresponding ephemeral public-key; and (5) outputting the result of the multiplication and the masked SSV as the cipher-text. In other embodiments, a different form of encryption other than SAKKE may be applied.

In the present embodiment, the mediated SAKKE secret-key shares are validated using the following method: (1) the user computing its public-key by combining his identity and the KMS public-key; (2) the user applying a bilinear mapping to his public-key and his share of the private-key; (3) transmitting the result to the SEM, as well as his identity; (4) the SEM checking if the user has not been revoked; (5) the SEM computing the user public-key by combining the user’s identity and the public-key of the KMS; (6) the SEM applying a bilinear mapping to the user’s public-key and the SEM share of the private-key; (7) transmitting the result to the user; (8) both the user and the SEM multiplying the two partial results, and checking that the product matches a public parameter, namely the generator of a certain group. The mediated IDPKC EC Schnorr shares are validated using the following method: (1) the user computing the public-key corresponding to his share of the private-key; (2) transmitting this public-key to the SEM, as well as the identity of the user; (3) the SEM checking if the user has not been revoked; (4) the SEM computing the public-key corresponding to the SEM share of the private-key; (5) transmitting this public-key to the user; (6) both the user and the SEM adding the two partial public-keys to produce the whole public-key; (7) both the user and the SEM checking if the result matches the public-key derived from a Public-Validation Token (PVT), identity-related information, and the public-key of the KMS.

It will be appreciated that different methods of validating the secret-key shares maybe used in other embodiments, according to the type of signature to be applied.

In the present embodiment, the cooperative signing procedure is as follows: (1) computing a first portion of an ephemeral private-key; (2) transmitting the corresponding partial ephemeral public-key, the message, and the user identity to the SEM; (3) checking in the SEM if the user identity has not been revoked; computing in the SEM a second portion of the ephemeral private-key, and combining the corresponding partial ephemeral public-key with the partial key transmitted by the user to produce the whole ephemeral public-key; computing in the SEM a challenge by combining the ephemeral public-key, the message, and identity-related information; computing in the SEM a portion of the challenge response, based on the SEM share of the long-term private-key of the user, and on the SEM partial ephemeral private-key; (4) the SEM transmitting the ephemeral partial public-key and the partial challenge response to the user’s device; (5) combining the user partial ephemeral public-key with the partial key transmitted by the SEM to produce the whole ephemeral public-key; computing the challenge as the SEM previously did; computing a partial challenge response, based on the user’s share of the long-term private-key and on the user’s partial ephemeral private-key, and combining it with the partial challenge response transmitted by the SEM to produce the whole response; (6) Outputting the challenge, the response and the PVT as the signature. In this method, steps (1), (2), (5) and (6) are performed by the signing unit 403 in the client device 101, and steps (3) and (4) are performed by the signing unit 412 in the SEM112.

Figure 5 is a flowchart showing a method of receiving data in a secure communication system. The method can be implemented by a device in a system as shown in Figs. 1 and 2, for example the device labelled ‘Bob’ in Fig. 2. In some embodiments, the method can be implemented by computer program instructions stored in a computer-readable storage medium accessible by the device. When executed, the instructions would cause the method steps shown in Fig. 5 to be performed.

First, in step S501 a first private key share (RSKi) is received and stored. Then, in step S402 signed encrypted data is received, for example in the form of an I_MESSAGE as described above in the example shown in Fig. 4. Next, in step S503 a public key of a sender of the encrypted data is obtained from an identity of the sender, according to an identity based public key cryptography protocol. Then, in step S504 the obtained public key of the sender is used to verify the signature. Finally, in step S505 the device communicates with the SEM 112 to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the SEM 112.

In the present embodiment, the encrypted data is only decrypted in response to successful verification. This has the advantage that decryption, which is computationally expensive, is only performed when necessary. However, in other embodiments decryption could be performed first, with the decrypted data being discarded if the signature cannot be verified.

Figure 6 schematically illustrates a structure of a client device and SEM for implementing the method of Fig. 5, according to an embodiment of the present invention. The structure shown in Fig. 6 is provided for illustrative purposes only to aid understanding of the present invention, and is not intended to be limiting. The embodiment of Fig. 6 is based on the MIKEY-SAKKE protocol, but in other embodiments of the invention a different communication protocol could be used.

As shown in Fig. 6, the apparatus of the present embodiment comprises a storage unit 601, a receiving unit 602, an authentication unit 603, and a decryption unit 604. The storage unit 601 is configured to store a first private key share (RSKi) received from the KMS 111. The receiving unit 602 is configured to receive encrypted data. The receiving unit 602 may be any suitable interface configured to receive data over the network too. The authentication unit 603 is configured to obtain a public key of a sender of the encrypted data from an identity of the sender, according to an identity based public key cryptography protocol, and to verify a signature of the received encrypted data, using a public key of the sender of the encrypted data. The decryption unit 604 is configured to communicate with the SEM112 to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the SEM 112.

Similar to the SEM illustrated in Fig. 4, the SEM 112 in the present embodiment comprises a storage unit 611 configured to store the second private-key share (RSK2) received from the KMS 111, and a permission manager 613 for implementing immediate revocation of users. The SEM 112 further comprises a decryption unit 612 for cooperatively decrypting the encrypted data. In the present embodiment, the SEM 112 is configured to only cooperatively decrypt the encrypted data in response to a determination by the permission manager 613 that the client device 102 has permission to participate in the secure communication system. This avoids data being decrypted unnecessarily when verification of a signature fails.

In the present MIKEY-SAKKE based embodiment, as shown in Fig. 6, the client device 102 receives the encrypted data as a MIKEY I_MESSAGE, and verifies the signature using EC Schnorr signature validation. If the signature is valid, the encrypted data, in this case a SSV, is decrypted in cooperation with the SEM 112. Specifically, in order to cooperatively decrypt the cipher-text of the I_MESSAGE in the present embodiment, the client device 102 and SEM 112 proceed as follows: (1) extract the value of the multiplication and the masked SSV from the cipher-text, and transmits the value of the multiplication to the SEM; (2) check at the SEM that the recipient has not been revoked; the SEM computes a bilinear pairing of the multiplication and the SEM share of the private-key, partially cancelling the recipient’s public-key; (3) transmit the partial result from the SEM to the recipient; (4) the recipient applies a bilinear pairing to the cipher-text multiplication and his share of the private-key, partially cancelling the public-key; the recipient multiplies the partial result of the recipient and the partial result of the SEM so as to obtain the ephemeral public-key; (5) the recipient unmasks the SSV, by XOR-ing the masked value with a hash of the ephemeral public-key, and outputs the value. Steps (1), (4) and (5) are performed by the decryption unit 604 in the recipient’s device 102, and steps (2) and (3) are performed by the decryption unit 612 in the SEM 112.

The corresponding validation procedure of the signature in the present embodiment is similar to the EC Schnorr procedure described above. To verify the signature, the authentication unit 603 performs the following steps: (1) deriving the public-key of the signer, by combining his identity, the public-key of the KMS and the PVT; (2) generating the ephemeral public-key by combining the challenge and the challenge response in the signature, and the public-key; (3) reproducing the challenge with the ephemeral public-key, the message, and identity-related information; (4) accepting the signature only if the challenge reproduction matches the challenge in the signature.

Embodiments of the invention, as disclosed above, enable immediate user revocation and key renewal in an IDPKC-based system, by using mediated signing at the sender and mediated decryption at the recipient. A user can be immediately revoked by instructing a SEM to no longer cooperate with that user, thereby preventing the revoked user from participating in the secure communication system. A secure communication system as disclosed herein may, for example, be used for Voice over IP (VoIP) communications. Enterprises as well as Government organizations are increasingly wishing to secure their communications. Traditional solutions based on the Public Switched Telephone Network (PSTN) suffer from multiple security issues, such as call diverting, rerouting, and eavesdropping. VoIP leverages the Internet as an infrastructure for voice communication. For example, in the UK, the Communications-Electronics Security Group (CESG) provisions standards and guidance to the Government and the Industry to ensure that appropriately assured products and services are available in the domain of Cyber Security. Recently, CESG has developed new key agreement standards, published as Internet Task Engineering Task Force (IETF) Requests for Comments (RFCs) to provide low-cost secure VoIP communications; which comprise the previously referred MIKEY-SAKKE protocol.

As described above, embodiments of the present invention can enhance the security features of MIKEY-SAKKE as described above, by enabling instant user revocation and key renewal. When applied in a VoIP context, embodiments of the invention can enable users to hold sensitive voice or multimedia communications in disparate locations between two or more parties connected via untrusted networks, and where reliable mutual authentication is imperative. It is possible to immediately revoke users in the event of them being removed from the system due to Enterprise or Government policies. It is further possible to renew a user’s key should it be compromised, without changing his identifier. This may be triggered, for instance, in the event of a device being stolen or lost, or an attacker having access to the user’s key.

As a further example, embodiments of the invention may be applied to Smart Grids (SGs). A SG may comprise an Advanced Metering Infrastructure (AMI), which is responsible for collecting, analyzing, storing and providing the metering data sent by Smart Meters (SMs) to the appropriate authorized parties. The AMI can comprise: (1) Home Area Networks (HANs) that include SMs, Smart Appliances (SAs), E-Cars (Electric Cars) and local renewable energy sources, which are located in the residential end-customers’ premises; (2) Gateways (GWs) that act as an interface between a set of SMs and the AMI head-end, collect data from several SMs using short-distance communication infrastructures (e.g. ZigBee or Bluetooth), and send them using longdistance communication infrastructures (e.g. GSM or WiMax) to the AMI head-end; (3) an AMI Communication Infrastructure that provides a communication path between the GWs and the AMI head-end; (4) an AMI back-end that uses data collected from the SMs for billing, grid status estimation, etc., and sends data and requests, such as software updates or real-time pricing.

The correct functioning of the SG relies upon the secure communication of data between its constituent elements. If the authenticity and integrity of the exchanged messages is not assured, an attacker would be able to impersonate the SMs and send false meter readings to the AMI back-end, resulting in financial losses and unbalanced energy production/consumption. Further, an attacker could masquerade as the AMI back-end, and send fake commands or fake pricing messages to the SAs or SMs, resulting in a financial loss for the user. Other attacks would be possible. Confidentiality is also an important feature to be integrated in AMIs so as to protect the privacy of the users.

Some SG devices, such as the SMs, may be limited in their computational power and ability to store cryptographic materials. This may deter the adoption of public-key infrastructures, due to the need of storing a multitude of certificates, as well as long certificate revocation lists and having to verify long certificate chains on the resource-constrained devices. On the other hand, the adoption of a conventional IDPKC protocol maybe detrimental, since a single entity (the KMS) would have to provision private-keys periodically to a prohibitively large amount of devices. Embodiments of the invention, as disclosed herein, could be used to mitigate the problems of IDPKC, since if SEMs handle the revocation it is not necessary to provision key material so often. Furthermore, it is not necessary for the SEM to be a single device. In some embodiments, a plurality of the SEMs could be deployed in a distributed manner in the AMI communication infrastructure, or alongside the GWs to improve scalability. In a distributed SEM embodiment, each individual SEM could be assigned to manage a specific group of users.

Advantages of applying embodiments of the invention in a SG context include: a stolen SA or E-Car could be immediately revoked from the system, and therefore be impossible to use; an end-user’s SM could be immediately revoked from the system if the end-user fails to pay his bills; sensitive components can use mediation, whereas non-critical devices may implement the non-mediated version of the scheme, reducing the load of the SEMs; the KMS needs not provision all devices on a short period basis.

These are just a few examples of possible applications of the invention, and it will be appreciated that embodiments of the invention can also find use in other contexts where secure communication is required.

Whilst certain embodiments of the invention have been described herein with reference to the drawings, it will be understood that many variations and modifications will be possible without departing from the scope of the invention as defined in the accompanying claims.

Claims

Claims

1. Apparatus for sending data in a secure communication system, the apparatus comprising: a storage unit configured to receive and store a first private key share (SSKi); an encryption unit configured to obtain a public key of an intended recipient of the data from an identity of the recipient, according to an identity based public key cryptography protocol, and to encrypt the data using the obtained public key; a signing unit configured to communicate with a security mediator to cooperatively sign the encrypted data, using the first private key share and a second private key share (SSK2) held by the security mediator; and a transmission unit configured to transmit the signed encrypted data.
2. The apparatus of claim 1, wherein the data to be securely transmitted is a shared secret value SSV, and the apparatus further comprises: a shared secret value generator configured to generate the shared secret value, wherein after transmitting the signed encrypted SSV, the apparatus is further configured to subsequently communicate with the recipient using symmetric key encryption based on the SSV.
3. The apparatus of claim 1 or 2 , wherein the storage unit, encryption unit, signing unit and transmission unit are included in a client device, the apparatus further comprising: a key management entity separate to the client device; and the security mediator, embodied in a separate physical device to the client device and the key management entity, wherein the key management entity is configured to obtain a private key for the client device, generate the first private key share and the second private key share from the private key, send the first private key share to the client device, and send the second private key share to the security mediator.
4. The apparatus of claim 3, wherein the key management entity is configured to perform key renewal by generating a new first private key share and a new second private key share from the private key for the client device, and send the new first private key share to the client device and the new second private key share to the security mediator. 5· The apparatus of claim 3 or 4, wherein the security mediator comprises: a permission manager configured to determine whether a client device has permission to participate in the secure communication system, wherein in response to a request from the client device to cooperatively sign the encrypted data, the security mediator is configured to only cooperatively sign the encrypted data in response to a determination by the permission manager that said client device has permission to participate in the secure communication system.
6. Apparatus for receiving data in a secure communication system, the apparatus comprising: a storage unit configured to receive and store a first private key share (RSKi); a receiving unit configured to receive encrypted data; an authentication unit configured to obtain a public key of a sender of the encrypted data from an identity of the sender, according to an identity based public key cryptography protocol, and to verify a signature of the received encrypted data, using a public key of the sender of the encrypted data; and a decryption unit configured to communicate with a security mediator to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the security mediator.
7. The apparatus of claim 6, wherein the decryption unit is configured to only decrypt the encrypted data in response to successful verification by the authentication unit.
8. The apparatus of claim 6 or 7, wherein the encrypted data is a shared secret value SSV, and after receiving the encrypted SSV the apparatus is further configured to subsequently communicate with the sender using symmetric key encryption based on the SSV.
9. The apparatus of claim 6, 7 or 8, wherein the storage unit, receiving unit, authentication unit and decryption unit are included in a client device, the apparatus further comprising: a key management entity separate to the client device; and the security mediator, embodied in a separate physical device to the client device and the key management entity, wherein the key management entity is configured to obtain a private key for the client device, generate the first private key share and the second private key share from the private key, send the first private key share to the client device, and send the second private key share to the security mediator. to. The apparatus of claim 9, wherein the key management entity is configured to perform key renewal by generating a new first private key share and a new second private key share from the private key for the client device, and send the new first private key share to the client device and the new second private key share to the security mediator.
11. The apparatus of claim 9 or 10, wherein the security mediator comprises: a permission manager configured to determine whether a client device has permission to participate in the secure communication system, wherein in response to a request from the client device to cooperatively decrypt the encrypted data, the security mediator is configured to only cooperatively decrypt the encrypted data in response to a determination by the permission manager that said client device has permission to participate in the secure communication system.
12. A method of sending data in a secure communication system, the method comprising: receiving and storing a first private key share (SSKi); obtaining a public key of an intended recipient of the data from an identity of the recipient, according to an identity based public key cryptography protocol; encrypting the data using the obtained public key; communicating with a security mediator to cooperatively sign the encrypted data, using the first private key share and a second private key share (SSK2) held by the security mediator; and transmitting the signed encrypted data.
13. A method of receiving data in a secure communication system, the method comprising: receiving and storing a first private key share (RSKi); receiving encrypted data; obtaining a public key of a sender of the encrypted data from an identity of the sender, according to an identity based public key cryptography protocol; verifying a signature of the received encrypted data, using a public key of the sender of the encrypted data; and communicating with a security mediator to cooperatively decrypt the encrypted data using the first private key share and a second private key share (RSK2) held by the security mediator.
14. The method of claim 13, wherein the encrypted data is only decrypted in response to successful verification.
15. A computer-readable storage medium arranged to store computer program instructions which, when executed, perform a method according to claim 12,13 or 14.