search

capsule-corp-ternoa / worker

SubstraTEE worker for SubstraTEE node
Apache License 2.0
0 stars 0 forks source link

[client] add new ternoa CLI subcommands #1

Closed brenzi closed 3 years ago

brenzi commented 3 years ago

binary renaming to ternoa-client

In addition to existing commands, prepare the following CLI. implementation of functionality is out of scope of this issue. just the CLI

encryption

ternoa-client encrypt <inputfile>
# will create inputfile.cyphertext and inputfile.aes256 with the symmetric key

NFT stuff

The NFT contains a filename of the capsule /cyphertext file. It is identified by a u32

ternoa-client nft create <owner> <filename>
# must return a u32 NFTId

# transfer ownership
ternoa-client nft transfer <from> <to> <NFTId>

# change filename
ternoa-client nft mutate <owner> <NFTId> <filename>

KeyVault stuff

ternoa-client keyvault list
# lists urls of registered enclaves, one per line

ternoa-client keyvault provision <NFTId> <urllist> <N>
# will read aes256 key, shamir-split shares, provision all keyvaults and verify
# N: number of shares needed to recover key (must be smaller than number of urls)

ternoa-client keyvault check <NFTId> <url>
# check if the key share for NFTId is stored in the keyvault with <url>. exit code 1 if negative

ternoa-client keyvault get <NFTId> <owner> <url>
# returns single key share

decryption

ternoa-client decrypt <inputfile> 
# decrypts cyphertext using the aes256 key stored in inputfile.aes256. for debug only

ternoa-client decrypt <inputfile> <keysharesfile>
# reads key shares from second file, shamir-combines the shares into the original assuming the exact number of shares given that is needed
haerdib commented 3 years ago

Update: NFT will be on the client side, keyvault ist on cli (where the other trustedoperations are handled).

Where should the encrypt and decrypt take place? stf or client?

brenzi commented 3 years ago

not sure what the difference between cli and client is. do you mean client vs stf/cli? encrypt and decrypt happens client side, that is for sure (no content is sent to the keyVault) I'd suggest to do encryption and decryption in client/src/main.rs because it has nothing to do with the KeyVault directly

haerdib commented 3 years ago

@brenzi is keyvault list really in the right place? It is necessary for keyvault interaction, but it does not talk with the keyvaults at all if I've understood correctly. Is it not a modified list-workers?

haerdib commented 3 years ago

EDIT: Look at the propsal below first.. I think this one is overcomplicating things..

According to the comments in PR #16 and discussion in https://github.com/integritee-network/worker/issues/197 & looking at the main.rs file again I'm proposing the following new client structure:

Summarizing it could look like:

client
|-- main.rs (+ encrypt & decrypt clap function)
|-- decrypt.rs
|-- encrypt.rs
|-- keyvault
|    |-- clap.rs
|    |-- provision.rs
|    |-- ...
|-- nft
|    |-- clap.rs
|    |-- ...

This is not the optimal solution, but somewhat close to what was decided on in https://github.com/integritee-network/worker/issues/197 without touching main.rs too much (which is more than a PoC task..)

@brenzi does this sound like a sound solution to you?

haerdib commented 3 years ago

Restructuring proposoal according to the discussion in https://github.com/integritee-network/worker/issues/197 and PR #16:

Add a new ternoa_commands.rs file, which contains all ternoa clap commands. It's handling all commands and subcommands of the newly added client calls. This way the main file can be left untouched.. it's quite messy and cleaning it up would be too much for a PoC. All actual functionalities will be implemented in different files:

client
|-- main.rs 
|-- ternoa_commands.rs
|-- ternoa_implementation
|    |-- encrypt.rs
|    |-- decrypt.rs
|    |-- keyvault
|    |    |-- provision.rs
|    |    |-- ...
|    |-- nft
|    |    |-- transfer.rs
|    |    |-- ...
brenzi commented 3 years ago

LGTM.

haerdib commented 3 years ago

Closing with merge of #16