Problem: no support for AWS Nitro Enclave

[thomas-nguy]

No description provided.

[allthatjazzleo]

it may require two binaries.
One is the gorc helper which pushes the config to the enclave one and initializes the vscok proxy.
Another one is gorc eif which run on enclave and accept the config from helper through vsock and run what gorc used to do but the all the outbound traffic need to go through vsock proxy such as eth rpc and cosmos grpc(not sure vscok support grpc or not).
@tomtau

[tomtau]

@allthatjazzleo @thomas-nguy "AMS" == AWS?
Can I get more context of what this problem is about? What should be executed in NE and how / why?

if (all of?) gorc, then this will be a huge effort:

1. there's no file storage etc. in NE, so any configs or local storage-related logic will need to be rewritten
2. as @allthatjazzleo mentioned, NE can't do any networking directly, so it needs to be via vsock proxy... so that will entail rewriting / patching a lot of external dependencies for anything that hardcodes TCP at the moment (be it eth / cosmos rpc or that custom pricing oracle stuff)

[thomas-nguy]

"AMS" == AWS?

yes, corrected

[thomas-nguy]

Regarding the need for NE, it is to enhance the overall security over our orchestrator/relayers.

I guess the idea is to have the cosmos and eth tx signatures being executed in NE. Maybe just porting the tx signing would be enough?

It is not a blocker for mainnet release but could be look into as a feature to have in long term.

[tomtau]

I guess the idea is to have the cosmos and eth tx signatures being executed in NE. Maybe just porting the tx signing would be enough?

what would be the advantage over having AWS KMS tx signer? we used NE on a different project, because AWS KMS didn't support ed25519, but here both are secp256k1

[thomas-nguy]

Yeah, I have probably misunderstood the idea. So I guess we want the entire gorc to be run within NE to provide better isolation? @allthatjazzleo

If it is the case, we probably need to refactor gorc to make it simpler. Maybe dividing the building msg parts from the sending part..

[allthatjazzleo]

Was concerned about if someone somehow gets accessed to the machine, one can run his own version of gorc to submit malicious tx as one should also be able to get access to kms key.
If we run gorc in nitro, we can make only valid code can access the kms through PCR8 specified in Kms policy?

[tomtau]

what kind of malicious tx?

[thomas-nguy]

I guess if someone has access to our AWS KMW, it could sign and submit a crafted EthereumEventVote or sign a crafted SubmitBatch hashroot. But it still requires 2/3 of the powers to be valid.

In order to prevent this, we should do the eth rpc nodes query for events and build the msgs within the enclave

[tomtau]

NE won't prevent it if eth rpc returns crafted events

[tomtau]

Having said that, NE would prevent signing on other txs, such as draining out the account balance meant for covering gas costs etc. (but the risk/damage is small)

@thomas-nguy do you have concrete examples how a crafted EthereumEventVote or SubmitBatch would work? It may or may not be preventable by running light client protocol verification over the rpc inside NE (and maintaining some trusted+attested state)... the question would be what or if any client-side network state verification one can run on the current Eth mainnet.

[thomas-nguy]

Unfortunately gravity bridge security model is based on network validator set, not on some light client verification.

The message does not contains any merkle root for verification, but a sample object containing the contract events such as

	event SendToCosmosEvent(
		address indexed _tokenContract,
		address indexed _sender,
		bytes32 indexed _destination,
		uint256 _amount,
		uint256 _eventNonce
	); 

with nonce being an incremental number stored in state. In that sense it would be fairly easy to craft.

but for that one to be valid, it means that more than >2/3 of our server (in term of power) could be accessed by the attacker and this message to be sent simultaneously.

If the idea is to run a light client verification protocole within the NE, we would have to verify each events one by one which could be a bit heavy for the orchestrator.

[thomas-nguy]

https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/stateless-clients/

but prob not available anytime soon