SGX as a signing provider about tmkms HOT 9 CLOSED

We'd be fine with supporting SGX builds of the KMS using the x86_64-fortanix-unknown-sgx Rust target.

Here's some example usage:

However note that after the Load Value Injection attack, which is a fundamentally unfixable issue impacting all Intel CPUs with SGX support, there are a complex set of mitigations which need to be applied.

I haven't kept up with how Fortanix handles this in their SGX target, however if it involves overly invasive/complex program changes it would be a case against SGX support in the KMS (and potentially a case for supporting a specialized SGX signer).

from tmkms.

I wrote the aes-gcm-siv crate, and it's one of the most mature AEAD implementations available in Rust right now.

It reuses many of the same underlying algorithms as the aes-gcm crate (namely the aes crate and polyval), which have been audited by NCC group. For pure Rust code, they're both highly optimized already, and can use AES-NI and CLMUL on SGX-capable hardware.

from tmkms.

Awesome, thanks for the response. I actually wasn't aware of x86_64-fortanix-unknown-sgx, but it seems way simpler than using apache/incubator-teaclave-sgx-sdk/, which I was doing, so I'll definitely take a look at that. From what I can tell the relative simplicity is a huge win for projects that benefit from abstracting away most of the boilerplate that comes with SGX (like this one).

Re: the LVI issue - I'm aware of it. On Baidu's sgx-sdk it involves setting compiler flags, and bundled primitives to validate input from the untrusted code, which ends up adding too much complexity (standard stuff for anyone coming from cpp!). Not sure how Fortanix handles it, but I would assume it wouldn't be much more complex than that.

Any other thoughts on specific features/things that you'd like an SGX signer to support?

from tmkms.

The main other things would be encrypting/keywrapping the Ed25519 keys used by the softsign backend, and potentially adding a MAC to the consensus state with an enclave-held key.

from tmkms.

LVI hardening for x86_64-fortanix-unknown-sgx just landed in Rust nightly:

rust-lang/rust#72655

from tmkms.

@Cashmaney some time ago, we had a small PoC prototype in EDP:
tendermint/tmkms@develop...crypto-com:sgx
tendermint/signatory@develop...crypto-com:sgx

You can have a look, but a few things to note:

1. It's a prototype experimental throwaway unpublished code -- when looking back to it now, I suspect e.g. those static refcells in the runner are leaking memory (as they seem to only be appended to); so don't take it as a reference how it should be done :)

2. it targeted older version of tmkms and EDP -- one thing that notably changed in EDP is that the UsercallExtension now works with async streams -- fortanix/rust-sgx@945297f

A few other things to consider:

• that prototype code has SGX as a signing provider, so the way it works is:

TM <-(TCP/UDP secret connection)-> TMKMS (EDP runner) <- (plain custom protocol over "sgx" stream) -> sgx signing provider (EDP app)

I guess it may be in line with the intended architecture. One alternative would be to push more TMKMS to SGX -- in that way, the EDP runner would just read TMKMS config, open the TCP or Unix socket and expose that to the EDP app via bind_stream: https://github.com/fortanix/rust-sgx/blob/master/examples/usercall-extension-bind/runner/src/main.rs#L246
(and EDP app would do SecretConnection, amino marshalling/unmarshalling etc. directly)

• for preserving the key ("encrypting/keywrapping the Ed25519 keys"), it used the sealing example: https://edp.fortanix.com/docs/examples/sealing/ + aes-gcm-siv. It's probably ok to use a different AEAD -- e.g. the Intel SDK uses AES-GCM: https://github.com/intel/linux-sgx/blob/master/sdk/tseal/tSeal_internal.cpp#L160 (one thing to note is that it always sets nonce as 0; derived key is unique per label)... Sealing is probably the most straightforward -- alternatively, one could have a "hot backup", i.e. another EDP enclave that would be running on a different machine, and TMKMS signing provider would connect to it (over attested secure channel) on its startup to fetch the keys or deposit keys to it during generation.

from tmkms.

aes-gcm-siv. It's probably ok to use a different AEAD

AES-GCM-SIV is ideal for keywrapping

from tmkms.

@tomtau Very cool! I actually started working on something very similar to what you have, as my implementation compiled the enclave as a library, so I had to go about building a stream interface with TMKMS anyway. Haven't had as much time as I'd like this past week to work on it, but I'll def dive deeper and probably use that as a good starting point - thanks for this.

Personally I would stay with the current TMKMS architecture, just appending SGX as just another signing provider, at least as a first step. The only thing I would consider adding inside the enclave is double-signing protection, but that can also be added as a stand-alone component.

One thing to remember about the sealing is to make sure MRENCLAVE is used as the sealing policy, but I see their API allows you to select either, which is nice (though either policy only applies to unsealing the same CPU, not trying to unseal the data on a different CPU).

@tarcieri Glad to see they finally pushed the mitigations as default! Agreed the AES-GCM-SIV is ideal as it limits the things that can go wrong due to misuse. It's a pretty new algorithm though, do you think that the available implementations are solid/mature enough to use in production?

from tmkms.

https://github.com/iqlusioninc/signatory/pull/51

from tmkms.