Osuke

ユーザが認証情報を用いて特定のTEEノードから状態データをGETする際、レスポンスする状態データをTEEノードがアクセスすることができないように、クライアントが生成した暗号鍵をEnclave暗号鍵で暗号化してGETリクエストに含めて、Enclaveでクライアント生成暗号鍵で状態データを暗号化して、レスポンスする

Related: #374 論点 * 実際の運用時にKey-vaultノードを何台運用するべきか。 * 「鍵バックアップ専用」のKey-vaultノードとして運用するべきか、他に運用しているanonifyノードを兼Key-vaultノードとして運用するべきか

* `/.anonify` へ生成するビルド生成ファイル・path_secrets * `/config` に存在する設定ファイル群 を `/etc/anonify` で管理するように変更

[example/~/server] TEEノードのGraceful shutdown実装

2

* actix-webにより、基本的なgraceful shutdown機能は提供されている（https://github.com/actix/actix-website/blob/master/content/docs/server.md#graceful-shutdown） * 一方、別途 enclaveのdestroyもshutdown時に実行する必要がある（`sgx_destroy_enclave`） Reference * https://github.com/apache/incubator-teaclave/commit/196419554ad25dcb86fc2fb1e807f62e9ee6c8e0 * https://dingelish.github.io/sgx_tse/sgx_types/fn.sgx_destroy_enclave.html

`key_vault_endpoint`を複数設定可能なようにして、バックアップとリカバリ共に複数のKeyVaultノードにリクエストを送信可能なようにする https://github.com/LayerXcom/anonify/blob/f62df717a15f3c442bac1474394ccbca9c8fa015/modules/anonify-enclave/src/context.rs#L169-L172

[frame/mra-tls] attested TLS用のEE証明書を定期的に更新

1

### AsIs: KeyVaultサーバの`start`エンドポイントにリクエストを送るごとに、TLS証明書を発行・remote attestationし、`ServerConfig`の生成。 https://github.com/LayerXcom/anonify/blob/46a5ff4b27870d72b5926710f1c32ac91430eaa7/modules/key-vault-enclave/src/server.rs#L28-L32 ### ToBe: TLS証明書を発行してから、特定の期間(e.x. 1時間）を経過していないか、別スレッドでノード間通信(via attested TLS)時に監視し、経過している場合はTLS証明書を新規発行（remote attestationも実行） * https://github.com/apache/incubator-teaclave/blob/05769c80fd15612003d629603cadd2ecddbfca46/attestation/src/attestation.rs#L60-L62 * https://github.com/apache/incubator-teaclave/blob/05769c80fd15612003d629603cadd2ecddbfca46/rpc/src/server.rs#L81-L85 * https://github.com/apache/incubator-teaclave/blob/05769c80fd15612003d629603cadd2ecddbfca46/rpc/src/config.rs#L122-L139

Enclaveにおけるコード(TCB)を削減するために、必要なコードのみをインポートできるよう細かくパッケージを分割する 例： `frame/common` の `AccountId` はanonify enclaveでは用いるが、key-vault enclaveでは用いない。

Ensure all pathsecrets are backup in key-vault

2

* backup/recover Attested TLSにおけるcommunicationエラーなどでkey-vault側でbackupできていなく、anonify側でbackupできている場合、`key-vault`側に必要なpathsecretのバックアップができていなく、anonify側の処理が進んでしまうケースがある。 anonify側のpathsecret全てが必ずkeyvaultにバックアップされていることを保証するために、以下の処理を追加実装する * そもそもbackupされているpathsecretが不足していることに気づく仕組み * 定期的にanonify側が`pathsecrets/`配下のファイルをkey-vault側へ送り、key-vaultは足りていないファイルを記録 * backup apiをanonify側に生やし、マニュアルでpathsecretを送る

Ocallでpath secretをexportして保存

1

* #323 で消した `ocall_import_path_secret` を復活 * ocall ロジックとしては一旦ファイルdiskに記録。将来的には外部オブジェクトストレージへ記録。

スケーラブルな分、Tree部分がEnclave内にも関わらず複雑な実装になってしまっている。 update handshakeのメッセージサイズがO(logN)からO(N)に肥大化する分、TCBサイズを削減可能。 https://github.com/LayerXcom/anonify/blob/1aaf0c10cdc4a1b82345b9d4e2258cd54d89b4f9/modules/anonify-enclave/src/group_key.rs#L11-L17