Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/kudelskisecurity/sgx-reencrypt

PoC of an SGX enclave performing symmetric reencryption
https://github.com/kudelskisecurity/sgx-reencrypt

Last synced: about 2 months ago
JSON representation

PoC of an SGX enclave performing symmetric reencryption

Awesome Lists containing this project

README 

        
# SGX-reencrypt 



**Disclaimer**: This is a PoC of an SGX-based application, but is

insecure as it is. To build secure SGX-based applications, you'll need

to perform the remote attestation step after being approved as an SGX

licensee. Even if you managed to get an attested release-mode enclave

from our code you shouldn't use it to protect real stuff; neither the

architecture nor the code have been properly reviewed, hence they're

probably not secure.



## Introduction



SGX-reencrypt is an SGX-based application that performs symmetric-key

*proxy reencryption*: SGX-reencrypt runs as a service that receives

encrypted requests containing



* A nonce `N` unique for this request



* A ciphertext `C` encrypted and authenticated with key with key id  `i`



* The key id `i` of the original ciphertext



* A key id `j` for the new ciphertext



The SGX-reencrypt service then



1. Decrypts and verifies the request

2. Verifies that the policy allows to reencrypt from key id `i` to key id

`j`. Upon failure, returns `N || 0x01 || C`

3. Decrypt and verifies the ciphertext `C` using key with key

id `i`, returning a plaintext `P`. Upon failure, returns `N || 0x02 || C` 

4. Encrypt and authenticate `P` using key id `j` to get a ciphertext

`C0`, returns `N || 0x00 || C0`



Requests are encrypted using the `crypto_box()` function from TweetNaCl

(public-key authenticated encryption).  Plaintexts are encrypted using

AES-GCM.



Responses are encrypted too using `crypto_box()`, and error responses

include `C` to make them indistinguishable from success responses.



This assumes that keys and a policy have been sealed to the reencrypt

enclave, as well as the enclave's Curve25519 private key.



## Setup 



A enclave's TweetNaCl keypair needs to be generated before using it.

The enclave provides the trusted call `generate_keypair`, that will

generate a new keypair and output the public key on success. This

information can be sealed to the filesystem using the trusted call

`seal_keypair`. After service restart, `unseal_keypair` will try to

recover the previously sealed keypair.



Once an enclave keypair has been generated, the returned public key

can be distributed amongst clients; it will be used to encrypt each

request and authenticate responses.



## Usage



The SGX-reencrypt functionality is accessed through two trusted calls

(ecalls): `register_key()` and `reencrypt()`. Both accept an encrypted

request and returns an encrypted response that can be opened using the

client private key and the enclave public key.



### Key registration



Key registration is the process by which symmetric keys are provisioned

to the enclave. These keys can later be used during reencryption

requests to decrypt and encrypt given ciphertexts.



Each key registration request is composed by an encrypted datagram,

using the enclave public key, containing these fields:



 * `key`, 16 bytes

 * `expiration_date`, 8 bytes

 * `policy_from`, 1 byte

 * `n_keys_from`, 4 bytes

 * `policy_to`, 1 byte

 * `n_keys_to`, 4 bytes

 * `n_authorized_clients`, 4 bytes

 * `keys_from`, [16 bytes]

 * `keys_to`, [16 bytes]

 * `authorized_clients`, [32 bytes]



On success, the enclave response contains the 16-byte key ID assigned.



#### Key ID generation



At the moment, 16-byte value `BLAKE2b(key || expiration_date)`. See security note 1.



#### Client authentication



Each authorized client is authenticated using its TweetNaCl public key.



### Reencryption



Reencryption is the process by which, given a ciphertext, `c`, and a

pair of previously registered key identifiers, `k1id`, `k2id`, the user

gets the new ciphertext `encrypt(k2, decrypt(k1, c))`. This process

allows to reencrypt a given ciphertext without exposing the plaintext

nor the keys to observers out of the enclave.



Each key reencryption request is composed by an encrypted datagram,

using the enclave public key, containing these fields:



```

 [K1ID   (16B)][K2ID   (16B)][IV (12B)]

 [MAC    (16B)][ciphertext       (...)]

```



On success, the enclave response contains a new ciphertext.



#### Policy check



Given a reencryption request, a set of policies is enforced:



 1. Does key-in allows encryption to key-out?



 2. Does key-out allows encryption from key-in?



 3. Is the client authorized to use key-in and key-out?



 4. Is the current timestamp lower than key-in and key-out exp. date?

    See security note 2.



Only when every policy is passed the reencryption is computed.



## Security



 * An eavesdropper on the channel shouldn't be able to extract clear

   information about the requests nor the responses (only relative

   data, as request size).



 * An attacker that interacts with the enclave shouldn't be able to

   extract the keys.



 * Non-authorized users shouldn't be able to use registered keys.



 * Ciphertexts should be indistinguishable.



## Security notes



1. As Key ID is deterministic, a party knowing a symmetric key and

expiration date could overwrite the registered key and replace the

policy with a malicious one without the user noticing it.



2. At the moment, there's no trusted absolute time source inside the

enclave, and the timestamp is requested through an untrusted call to

the system, rendering the expiration date policy forgeable by a 

malicious enclave host.



## Intellectual property



Copyright (c) 2016, Nagravision S.A.



Code under GPLv3