본문으로 건너뛰기

커스터마이징, 테스트, 관리

Nautilus 서버 로직은 src/nautilus-server directory에 있다. 애플리케이션을 커스터마이즈하려면 Nautilus 사용하기를 템플릿으로 참조한다.

정보

이러한 customization, testing, management 단계는 자체 관리되는 TEE를 위한 것이다. 대안으로 Docker 기반 단순성으로 testing 및 management 오버헤드를 제거하는 Marlin Oyster marketplace를 사용할 수 있다.

custom server logic 생성​

Nautilus 서버를 커스터마이즈하여 허용할 endpoint를 정의하고 애플리케이션이 접근해야 하는 외부 domain을 지정할 수 있다. process_data 로직을 정의하고 추가 endpoint를 등록하기 위해 mod.rs를 만들 수 있다.

다음 file은 일반적으로 수정이 필요하지 않다:

  • common.rs는 get_attestation endpoint를 처리한다.
  • main.rs는 ephemeral key pair를 초기화하고 HTTP 서버를 설정한다.

local testing​

대부분의 기능은 서버를 로컬에서 실행하여 테스트할 수 있다. 그러나 get_attestation endpoint는 Nitro Secure Module(NSM) driver에 대한 접근이 필요하므로 로컬에서는 동작하지 않는데, 이는 구성된 EC2 instance 내부에서 code를 실행할 때만 사용할 수 있기 때문이다. 이 endpoint는 설정 단계에서 설명한 대로 서버가 enclave 내부에서 실행될 때 정상 동작한다.

로컬에서 process_data endpoint를 테스트하려면 다음을 실행한다:

$ cd src/nautilus-server/
$ RUST_LOG=debug API_KEY=045a27812dbe456392913223221306 cargo run --features=weather-example --bin nautilus-server
$ curl -H 'Content-Type: application/json' -d '{"payload": { "location": "San Francisco"}}' -X POST http://localhost:3000/process_data
Click to open
Output
{
  "response":
    {
      "intent":0,
      "timestamp_ms":1744041600000,
      "data":
        {
          "location":"San Francisco",
          "temperature":13
        }
    },
  "signature":"b75d2d44c4a6b3c676fe087465c0e85206b101e21be6cda4c9ab2fd4ba5c0d8c623bf0166e274c5491a66001d254ce4c8c345b78411fdee7225111960cff250a"
}

reproducibility 확인​

같은 source code(/src의 모든 내용)에서 빌드된 모든 enclave는 재현 가능한 빌드를 통해 동일한 PCR을 생성할 수 있다. 여기에는 run.sh에서 이루어진 모든 traffic forwarding 변경(branch example-configuration 참조)도 포함된다.

$ cd nautilus/
$ make ENCLAVE_APP=weather-example
$ cat out/nitro.pcrs
Click to open
Output
911c87d0abc8c9840a0810d57dfb718865f35dc42010a2d5b30e7840b03edeea83a26aad51593ade1e47ab6cced4653e PCR0
911c87d0abc8c9840a0810d57dfb718865f35dc42010a2d5b30e7840b03edeea83a26aad51593ade1e47ab6cced4653e PCR1
21b9efbc184807662e966d34f390821309eeac6802309798826296bf3e8bec7c10edb30948c90ba67310f7b964fc500a PCR2
# 나중에 enclave 등록 시 사용할 env var를 추가한다.
$ PCR0=911c87d0abc8c9840a0810d57dfb718865f35dc42010a2d5b30e7840b03edeea83a26aad51593ade1e47ab6cced4653e
$ PCR1=911c87d0abc8c9840a0810d57dfb718865f35dc42010a2d5b30e7840b03edeea83a26aad51593ade1e47ab6cced4653e
$ PCR2=21b9efbc184807662e966d34f390821309eeac6802309798826296bf3e8bec7c10edb30948c90ba67310f7b964fc500a

enclave 관리​

템플릿은 admin이 PCR을 정의하는 하나의 EnclaveConfig와 연결된 여러 Enclave object를 등록할 수 있게 한다. 각 Enclave object는 고유 public key를 가진 특정 enclave instance를 나타내고, EnclaveConfig는 PCR 값과 그에 연결된 version을 추적한다. 일관성을 보장하려면 모든 새 Enclave instance를 최신 config_version으로 등록할 수 있다.

이 설계는 admin이 서로 다른 public key를 가진 같은 enclave의 여러 instance를 실행할 수 있게 하며, 여기서 config_version은 Enclave object를 생성할 때 최신 version으로 설정된다. admin은 자신의 Enclave object를 등록하거나 파기할 수 있다.

PCR update​

스마트 계약의 deployer는 EnclaveCap을 보유하며, 이를 통해 Nautilus 서버 code가 수정된 경우 PCR과 enclave public key를 업데이트할 수 있다. 새 PCR은 make ENCLAVE_APP=<APP> && cat out/nitro.pcrs를 사용해 가져올 수 있다. PCR을 업데이트하거나 enclave를 다시 등록하려면 이전 섹션에 설명된 단계를 재사용한다.

Move의 verified computation​

연산을 위해 enclave와 상호작용한 뒤 그 결과 데이터를 Move contract로 보내 사용하도록 frontend code를 작성한다. weather example의 경우 특정 위치의 날씨 데이터를 가져오도록 enclave에 요청할 수 있다:

$ curl -H 'Content-Type: application/json' -d '{"payload": { "location": "San Francisco"}}' -X POST http://<PUBLIC_IP>:3000/process_data
Click to open
Output
{
  "response":
    {
      "intent":0,
      "timestamp_ms":1744683300000,
      "data":
        {
          "location":"San Francisco",
          "temperature":13
        }
    },
  "signature":"77b6d8be225440d00f3d6eb52e91076a8927cebfb520e58c19daf31ecf06b3798ec3d3ce9630a9eceee46d24f057794a60dd781657cb06d952269cfc5ae19500"
}

그런 다음 enclave response의 값인 signature, timestamp, location, temperature를 사용해 Move contract의 update_weather를 호출한다. 이 예시에서는 script를 사용해 call을 시연하지만, 실제로는 앱 frontend에 통합해야 한다.

$ sh ../../update_weather.sh \
    $APP_PACKAGE_ID \
    $MODULE_NAME \
    $OTW_NAME \
    $ENCLAVE_OBJECT_ID \
    "77b6d8be225440d00f3d6eb52e91076a8927cebfb520e58c19daf31ecf06b3798ec3d3ce9630a9eceee46d24f057794a60dd781657cb06d952269cfc5ae19500" \
    1744683300000 \
    "San Francisco" \
    13

created weather NFT의 예시는 network scanner에서 볼 수 있다.

payload sign​

Move에서 payload 서명은 Binary Canonical Serialization(BCS)을 사용해 구성한다. 이는 signature를 생성할 때 enclave Rust code에 지정된 구조와 일치해야 한다. 그렇지 않으면 enclave.move에서 signature 검증이 실패할 수 있다.

일관성을 보장하려면 Move와 Rust 모두에서 unit test를 작성한다. src/nautilus-server/src/app.rs의 test_serde()와 move/enclave/enclave.move의 예제를 참조한다.

FAQ​

커뮤니티에서 자주 묻는 몇 가지 질문에 대한 답은 다음 섹션에 있다.

Sui가 처음 AWS Nitro Enclaves를 선택한 이유​

  • 이용 가능한 TEE provider는 많지만, AWS Nitro Enclaves를 초기 지원 대상으로 선택한 이유는 그 성숙도와 재현 가능한 빌드 지원 때문이다. 추가 TEE provider 지원은 향후 고려될 수 있다.

For questions about Nautilus, use case discussions, or integration support, contact the Nautilus team on Sui Discord.

AWS root of trust 위치​

  • 이는 the Sui framework의 일부로 저장되며 AWS attestation 문서를 검증하는 데 사용된다. AWS에 설명된 단계를 따라 그 hash를 검증할 수 있다.
$ curl https://raw.githubusercontent.com/MystenLabs/sui/refs/heads/main/crates/sui-types/src/nitro_root_certificate.pem -o cert_sui.pem
$ sha256sum cert_sui.pem

6eb9688305e4bbca67f44b59c29a0661ae930f09b5945b5d1d9ae01125c8d6c0

$ curl https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip -o cert_aws.zip
$ unzip cert_aws.zip
$ sha256sum root.pem

6eb9688305e4bbca67f44b59c29a0661ae930f09b5945b5d1d9ae01125c8d6c0 # Sui repo에서 내려받은 것과 일치하는지 확인한다