Shielded State Sync Server Architectures
Depending on whether we end up choosing a VM based TEE or process based TEE (namely SGX), we will have two different architectures for the server providing FMD. The components will remain the same, but IPC, API, and persistence choices will differ.
Common elements
The server will have three main components
- A masp indexer
- A detection process that checks if an FMD key flags a masp note
- A relevant database of processed detections and users
- An API for looking up index sets for clients on request and registering users to the service
The MASP indexer contains a database and will continuously fetch the latest masp notes from the chain, process them, and store them to the backing database. This code already exists and requires no further modifications.
If a user wishes to use this service, the must first register their decryption keys with the service. In reality, a key generation seed will be passed to the service along with a false positive parameter n
. The first generated key will be used to encrypt user data in the databases. The next n
derived keys will be for the fmd protocol.
Then the service will run the detect algorithm on all the masp notes fetched by the indexer along with the decryption keys. Masp blocks that contain txs relevant to the client will be stored in an index set.
A small database (hence FMD-DB)will be necessary to store these index sets. It will be keyed by a hash of the users key generation seed and the passed parameter n
. It’s values will be the index set and a block height indicating to which block this indexed set is synced to. These values will be encrypted using the first derived key from the seed as mentioned above. Users can pass a request to the service with their FMD-DB key and receive the encrypted value as response.
TDX
Since this is a VM based solution, we have all of the common components running inside the TEE. This removes the need for secure channels between the host and TEE. This can be a long running process and we can have user keys kept in-memory safely (AFAIK).
However, this is some difficulty in rebooting the service. TDX does not natively support sealing data, which would allow us to persist data to disk that is encrypted with a key that could be recovered by a TEE after restarting. This is in contrast to SGX which does support this. SGX has a sealing key seed that is constant and seals data by choosing a “derivation path” to derive a key from the seed and persists the encrypted data along with the derivation path.
Some solutions leveraging SGX can be used to providing data sealing to TDX TEEs, like Loose SEAL. Without this functionality, on restart all user registered decryption keys would be lost.
SGX
If using SGX, the MASP indexer, API, and FMD-DB will be run outside of TEE. A secure channel from the host and the TEE will need to be created.
When a user registers a decryption key seed, the API will forward this message to the TEE (the message payload should obviously be encrypted with a key know only to the TEE). Otherwise, the request is for an entry from the FMD-DB which will not involve the TEE and can be handled by host code directly.
The TEE will fetch batches of MASP notes from the MASP indexer to run fmd on and return key-value pairs to the host (the values will already be encrypted) to be stored in the FMD-DB.
The detection keys will need to be kept in SGX’s memory, which is an attack vector. Users should specify an expiration date after which SGX deletes and forgets about these keys (we might even need to clobber the cache). Users wishing to use the service further will need to re-register their keys.
Restarting SGX is trivial, as we can seal data to disk.