Keywords

1 Introduction

Public key cryptosystems (PKCs) are fundamental security ingredients in applications and protocols. They underpin various Internet standards, such as Transport Layer Security (TLS), S/MIME, PGP, and GPG. PKCs often adopt public key algorithms relying on cryptographic algorithms based on mathematical problems, such as integer factorization, discrete logarithm, and elliptic curve, all of which currently admit no efficient solution and are computationally intensive. Public key algorithms known so far are relatively computationally costly compared with most symmetric key algorithms of equivalent security.

Intel Software Guard Extensions (SGX) [1,2,3] enables execution of user-level sensitive code in an isolated environment, called enclave. The processor identifies and distinguishes enclaves in hardware-level by the measurement of the enclaves, which typically is the hash of enclave code. Isolation provided by SGX prevents other enclaves, other processes, and privileged code such as the OS and hypervisor, from reading or modifying the memory of an enclave at runtime. To protect enclave data across executions, SGX provides a security mechanism called sealing that allows each enclave to encrypt and authenticate data for persistent storage, with an enclave specific key derived from both processor-specific secrets and enclave measurement. SGX-enabled processors are equipped with certified cryptographic keys that can issue remotely verifiable attestation statements. A statement typically includes enclave measurement, fingerprint of enclave issuer, as well as user custom data, e.g., temporary public key. A verified attestation statement indicates that the enclave with given measurement is securely running on a SGX-enabled platform as expected. Through these security mechanisms, namely isolation, sealing, and attestation, SGX hardens the security of applications and services.

In this paper, we propose PoS, constructing practical and efficient PKCs based on symmetric cryptography with SGX. PoS provides two type cryptographic interfaces: private interfaces for signing/decrypting on the recipient side, and public interfaces for verifying/encrypting on the sender side. PoS allows PKCs to adopt symmetric key algorithms to implement those interfaces. To achieve this, as paradoxical as it may seem, a big challenge is that making symmetric keys shared between the sender side and the recipient side while being kept secret from the sender. We leverage the security mechanisms provided by SGX to solve such a challenge: Firstly, we separate private and public interfaces into two different dedicated SGX enclaves, private enclave and public enclave, hosted on the recipient and sender sides respectively. The two enclaves are isolated from each other, as well as privileged code like the OS and hypervisor, in hardware-level, making the code and data of cryptographic operations free from any modification and misuse. Secondly, we construct a secure private channel by leveraging remote attestation provided by SGX and provision symmetric keys to public enclave through it. The provisioned symmetric keys are limited within public enclave and never be exported. Isolation provided by SGX ensures that only public enclave can access the keys while preventing access from any other entities including the sender, other enclaves, or privileged code.

The security of PoS relies on SGX and symmetric cryptography and PoS gains security guarantees when the security assumptions of SGX and symmetric cryptography stand. To demonstrate the practicality and efficiency of the PKCs based on PoS, we have constructed PKE-PoS and IBE-PoS: PKE-PoS acts as traditional public key encryption (PKE) systems like RSA, while IBE-PoS acts as traditional identity-based encryption (IBE) systems like Boneh-Franklin IBE [4].

We have implemented both PKE-PoS and IBE-PoS with AES-256-GCM and HMAC-SHA256, and evaluated the performance of them. We also benchmarked most commonly used PKCs, such as RSA-2048, RSA-4096, DSA-1024, DSA-2048, ECDSA-p224, ECDSA-p256, ECDSA-p384, and IBE systems with most commonly used schemes, including Boneh-Franklin scheme (BF) [5] and NTRU lattices-based scheme (GPV) [6]. All experiments were conducted on SGX-enabled computers. The benchmark results show that PoS-based PKCs gain very excellent performance, far better than any other ones: the performance of PKE-PoS signing and decryption operations is up to 195 times of that of RSA-2048 while the performance of PKE-PoS verifying and encryption operations is about 5.4 times of that of RSA-2048; the performance of IBE-PoS decryption is about 745 times of that of GPV scheme and is more than 4 orders of magnitude higher than that of BF scheme; the performance of IBE-PoS encryption is about 390 times of that of GPV scheme and is about 4 orders of magnitude higher than that of BF scheme.

Contributions. In summary, our main contributions are:

  • We propose propose PoS, constructing practical and efficient PKCs based on symmetric cryptography with SGX. To the best of our knowledge, PoS is the first one that allows constructing practical PKCs based on symmetric cryptography.

  • We have constructed two PKCs on our PoS, PKE-PoS and IBE-PoS, and demonstrated their practicality.

  • We have implemented PKE-PoS and IBE-PoS and evaluated the efficiency of them on SGX-enabled computers. The results show that PoS-based PKCs gain excellent performance and are far more efficient than traditional PKCs.

2 Security Assumptions

We consider that PKCs based on our PoS will always employ provably secure symmetric key algorithms and symmetric keys of sufficient key length. We also consider that SGX security mechanisms, namely isolation, sealing, and attestation, provided by the processor will not be compromised. Our PoS does not aim to protect SGX enclaves against side-channel attacks [7, 8] and rollback attacks [3, 9]. Such attacks can be mitigated by existing solutions, e.g., [10, 11] for side-channel attacks and [12, 13] for rollback attacks. Our PoS is compatible with those solutions.

3 Principles of PoS

3.1 Overview

PoS consists of two dedicated SGX enclaves, private enclave and public enclave, hosted on the recipient and sender sides respectively. Both enclaves are isolated from the untrusted components of the host processes, as well as the OS and hypervisor. Private enclave only provides private interfaces, i.e., sign and decrypt, while public enclave only provides public interfaces, i.e., verify and encrypt. The attestation and isolation mechanisms provided by SGX make sure that enclaves act as expected, and any modification to the code and data of the enclaves will be prevented.

In PoS, a symmetric key is used as a private key in private enclave while used as a public key in public enclave. Symmetric keys are provisioned to public enclave, limited within public enclave, and marked as not exportable, so that access from any other entities including other enclaves, specially private enclave, privileged code, and the sender are prevented by SGX. As such, the provisioned symmetric keys can only be used to perform cryptographic operations specified by public enclave, namely encrypt and verify. The sender is able to encrypt/verify messages to/from the recipient through the public interfaces while the shared symmetric keys are kept secret from the sender.

3.2 Typical Cryptographic Interfaces

PoS defines two type cryptographic interfaces: private interfaces, i.e., sign and decrypt, which use symmetric keys as private keys, and public interfaces, i.e., verify and encrypt, which use symmetric keys as public keys. For encrypt and decrypt, they can be typically implemented the same as in traditional symmetric key encryption and decryption of secure symmetric key algorithms, e.g., AES. For sign and verify, they can typically adopt secure Message Authentication Code (MAC) algorithms, e.g., HMAC. PKCs constructed based on PoS should implement those cryptographic operation interfaces.

PoS allows PKCs to extend additional interfaces that needed, e.g., key generation interfaces. The only requirement is that all those additional interfaces should comply with PoS policies, i.e., porting into different enclaves according whether the symmetric keys are used as private keys or public keys and not exporting the shared symmetric keys in enclaves.

3.3 Provisioning Symmetric Keys

Since PoS adopts symmetric key algorithms, to make the sender able to encrypt/verify messages to/from the recipient through the public interfaces, symmetric keys should be shared to public enclave. Before symmetric keys are provisioned, a secure private channel over untrusted network is constructed, leveraging remote attestation mechanism provided by SGX. To achieve that, public enclave generates a pair of temporary keys (\(sk_{tmp}, pk_{tmp}\)) and a signed remote attestation statement, \(Q = Quote(pk_{tmp})\), which includes the measurement of public enclave, fingerprint of enclave issuer, and \(pk_{tmp}\) as the user custom data. Once verifying Q successfully, one accepts \(pk_{tmp}\) with assurance, uses it to protect the symmetric keys to be provisioned to public enclave.

The shared symmetric keys are limited within public enclave and not exportable, so that they are kept secret from any other entities.

3.4 Sealing Symmetric Keys

To protect symmetric keys across executions if necessary, PoS leverages the sealing mechanism provided by SGX to encrypt and authenticate symmetric keys for persistent storage. SGX ensures that the keys sealed by an enclave can only be extracted by the enclave that seals them. To make the sealed symmetric keys resist rollback attacks, one can, for example, employ SGX Monotonic Counter [12].

4 Constructing PKE on PoS

In this section, we construct PKE-PoS, a public key encryption (PKE) system based on PoS, employing a symmetric key algorithm, e.g., AES.

Like traditional PKE systems, keys are generated on the recipient side in PKE-PoS, except that a symmetric key (noted as mk) is generated within the private enclave. To enable a sender to encrypt/verify a message to/from a recipient, mk is provisioned to public enclave online. The key distribution procedure is as shown in Fig. 1, leveraging SGX remote attestation mechanism to construct a secure private channel. On success, mk is shared between public enclave and private enclave and can be sealed for persistent storage across executions. Note that mk is used as a public key within public enclave on the sender side while used as a private key within private enclave on the recipient side.

Fig. 1.
figure 1

Public key distribution in PKE-PoS

Full size image

PKE-PoS implements encrypt and decrypt interfaces the same as in traditional symmetric key encryption and decryption provided by a secure symmetric key algorithm, e.g., AES-256-GCM, while sign and verify interfaces adopt a MAC algorithm, e.g., HMAC-SHA256.

5 Constructing IBE on PoS

Identity-based public key encryption (IBE) [4] allows an entitys public key to be derived from an arbitrary identification value (ID), such as name or email address. In this section, we construct IBE-PoS, an identity-based encryption (PKE) system based on PoS, employing symmetric key algorithms, e.g., AES, Blowfish, Twofish, ChaCha, etc. Formally, IBE-PoS is composed by four algorithms [4], namely Setup, Extract, Encrypt, and Decrypt, as usual IBE cryptosystems:

Setup. A PKG takes a security parameter l, generates a master key mk, and outputs public system parameters params. l specifies the key length of user’s private keys. params includes the security parameter l, a selected symmetric key algorithm as well as encryption mode, and a key derivation function (KDF) that used to extract the recipient’s private keys.

Extract. The PKG takes params, mk, and recipient’s ID as inputs, and then extracts a symmetric key \(sk = KDF(mk, ID)\) of length l.

Encrypt. A sender takes params, recipient’s ID, and a message as inputs, and then outputs the ciphertext. This is done within public enclave. params is retrieved from the PKG. Specially, mk is also provisioned to public enclave along with params. Figure 2 shows the procedure of public enclave requesting params and mk from the PKG. Public enclave first extracts \(sk = KDF(mk, ID)\) of length l, encrypts the message with sk, using the symmetric key algorithm and encryption mode specified in params, and then outputs the ciphertext. Note that mk is kept secret from the sender. Both mk and params can be sealed for persistent storage across executions.

Fig. 2.
figure 2

System parameter request

Full size image
Fig. 3.
figure 3

Private key request

Full size image

Decrypt. A recipient takes params, sk and ciphertext, and then outputs the message. params and sk are requested from the PKG. Figure 3 shows the procedure of a recipient to request a private key from the PKG, the same as usual IBE systems: the PKG accepts the recipient’s private key request, and after successfully authenticating the recipient in some way, extracts the private key \(sk = KDF(mk, ID)\) for the recipient, and provisions sk to private enclave. Private enclave then decrypts the ciphertext with sk, using the symmetric key algorithm and encryption mode specified in params, and then output the message. Note that mk is not provisioned to private enclave. Both sk and params can be sealed for persistent storage across executions.

6 Implementation

We implemented PKE-PoS and IBE-PoS for the experimental purposes. The code of PKE-PoS and IBE-PoS is built on top of the popular OpenSSL library, which incorporates a multitude of cryptographic functions and large-number arithmetic primitives, and Intel SGX SDK. Both PKE-PoS and IBE-PoS are implemented on Linux. Currently, PKE-PoS employs AES-256-GCM for encryption and decryption, and HMAC-SHA256 for signatures; IBE-PoS employs AES-256-GCM for encryption and decryption, and HKDF [14] with HMAC-SHA256 for key derivation.

7 Evaluation

The security of PoS relies on SGX and symmetric cryptography and PoS gains security guarantees when the security assumptions of SGX and symmetric cryptography stand. In this section, we focus on performance evaluation of PKE-PoS and IBE-PoS.

7.1 Experiment Setup

Our experiments were conducted on a Intel NUC6 with an SGX-enabled i3-6100U processor and 8 GB DRAM. The processor is designed for low power (15 W) usage, whose maximum frequency is 2.3 GHz. The operating system was Ubuntu 16.04 with Linux kernel version 4.13.0.

We benchmarked the speed of PKE-PoS and some commonly used traditional PKCs, including RSA-2048, RSA-4096, DSA-1024, DSA-2048, ECDSA-p224, ECDSA-p256, and ECDSA-p384, using openssl speed command. Also, we benchmarked the speed of IBE-PoS and compared it with most commonly used implementations of IBE schemes, including Boneh-Franklin scheme (BF) [5] and NTRU lattices-based scheme (GPV) [6]. All the benchmarks took data of same length as input.

Fig. 4.
figure 4

Speed benchmarks for PKCs

Full size image

7.2 Speed Benchmarks

Figure 4 shows the benchmark results of PKE-PoS, RSA, DSA, and ECDSA systems. We can see that the performance of PKE-PoS is far better than that of RSA, DSA, and ECDSA—compared with RSA-2048, the performance of PKE-PoS decryption is more than 195 times of that of RSA-2048, while that is more than 182 times for signing, and for public operations, i.e., encryption and verifying, the performance of PKE-PoS is more than 5 times of that of RSA-2048.

Table 1. Comparing IBE-PoS with most commonly used implementations of IBE schemes, Boneh-Franklin scheme (BF) and NTRU lattices-based scheme (GPV).
Full size table

Table 1 gives the speed benchmarks of GPV, BF, and our IBE-PoS schemes. It shows that decryption and encryption of our IBE-PoS are very fast, far better than GPV and BF schemes—the performance of IBE-PoS decryption is about 745 times of that of GPV scheme and is more than 4 orders of magnitude higher than that of BF scheme; the performance of IBE-PoS encryption is about 390 times of that of GPV scheme and is about 4 orders of magnitude higher than that of BF scheme.

Fig. 5.
figure 5

The throughput of encryption in PoS-based systems

Full size image

Besides, we can calculate that for each operation of PKE-PoS and IBE-PoS, it takes more than 10000 cycles, far more time-consuming than that of original symmetric key algorithms, which takes only several dozen cycles. Take decryption operation of PKE-PoS for an example, which is the most efficient, it takes about 10600 cycles (recall that maximum frequency of the processor on our platform is 2.3 GHz). This is as expected, since enclave context switching as well as initialization of symmetric key algorithms would introduce overhead. The overhead of enclave context switching could be approximated to the time it takes for an empty enclave call, about 8914 cycles. In addition, it takes several hundred or thousand cycles for original symmetric key algorithms to setup key or Initialization Vector (IV), e.g., 1107 cycles for AES-GCM. As such, we can see that the time spent in a PKE-PoS decryption operation, 84.1% is spent in enclave context switching, 10.4% is spent in setup key or IV, while only 5.5% is spent in decryption. Nevertheless, as shown in Fig. 5, such overhead becomes less significant when the size of data processed per operation increases as the throughput of encryption and decryption in PoS-based systems increases fast when the data size increases.

8 Discussion

In principle, PKE-PoS can employ any secure symmetric key algorithm with any encryption mode for encrypt and decrypt interfaces, and any secure MAC algorithm for sign and verify interfaces. However, there would be a risk that the sender might be able to forge a valid signature through encrypt interface in some cases. For example, CMAC adopts CBC mode and one is able to generate a CMAC signature for any message by encrypting the message in CBC mode with IV set to zero, and thus if PKE-PoS happens to employ a symmetric key algorithm with CBC mode, the sender would be able to forge signatures. As such, PKE-PoS should make sure that the selected symmetric key algorithm and MAC algorithm do not adopt same encryption mode. A preferable solution is to adopt an HMAC algorithm for sign and verify interfaces, instead of encryption based MAC algorithms like CMAC and GMAC.

A disadvantage of PKE-PoS is that requiring an online key distribution. A sender in PKE-PoS has to retrieve recipient’s public key online from private enclave on the recipient side. This can be mitigated by introducing a provision enclave hosted on a public service, which keeps online—private enclave provisions symmetric keys to the provision enclave and then can go offline, while public enclave can request the symmetric keys after successfully authenticating to the public service if required. The provision enclave can also be incorporated into a certificate authority, making PKE-PoS compatible with PKI.

9 Related Work

Prior works have proposed many cryptosystems, leveraging system and network security mechanisms to equip cryptosystems with dedicated security features.

IB-MKD [15] employed a key distribution center (KDC) equipped with an RSA key pair to distribute message keys without the need to revoke any keys. HIBE [16] introduced lower-level PKGs to reduce the workload of the centralized PKG, in a way that a root PKG need only generate private keys for domain-level PKGs, who in turn generate private keys for users in their domains in the next level. [17] proposed solutions to mitigate key escrow problem in an IBE system, by employing some distributed PKGs to generate the private keys, so that the keys are still secure when the PKGs are partially compromised. In contrary, RIKE [18] integrated the ‘inherent key escrow’ of IBE into PKIs to enable key escrow in PKIs while keeping the complete compatibility with PKI certificates.

Intel SGX provides preferable security mechanisms, namely isolation, sealing, and attestation, in protecting applications on the untrusted OS. VC3 [19] employed SGX to provide shielded execution to protect the confidentiality and integrity of the code and data of a program from the hosting untrusted platform. REM [20], a new blockchain mining framework, leveraged the partially decentralized trust model inherent in SGX to achieve Proof-of-Useful-Work (PoUW), reducing the waste of PoW (Proof-of-Work).  [21] used SGX to design a proof of luck consensus protocol and constructed a blockchain based on such a protocol.

10 Summary and Future Work

In this paper, we presented PoS, constructing practical and efficient PKCs based on symmetric cryptography with SGX. PoS makes this possible by sharing symmetric keys between dedicated SGX enclaves and limiting the keys within the enclaves, so that the keys are kept secret from other processes, privileged code like the OS, and the sender. PoS gains security guarantees when the security assumptions of SGX and symmetric cryptography stand. We have constructed two PKCs based on PoS to demonstrate the practicality and efficiency of PoS-based systems. The evaluation results have shown that PoS-based systems gain excellent performance, far better than traditional PKCs.

Our PoS can also be used to construct other PKCs, such as an IBE system supporting identity-based signatures with non-repudiation. A more formal analysis of semantic security of PoS remains for our future work.