# Secret Network ![](https://i.imgur.com/Z7WAhJb.png) Title --- - Secret Network: A privacy-preserving secret contract & decentralized application platform Abstract --- - 블록체인의 본질은 immutability 와 transparency 이다. 여기서 immutablility는 블록체인에 한 번 기록된 내용은 수정할 수 없어야 함을 의미하고, transparency는 블록체인 데이터의 내용이 모두 공개되어 있어야함을 의미한다. 하지만, 모든 경우에 데이터를 오픈하지 않을 수 있다. 예를 들어, 개인에게 중요한 데이터인 경우, 블록체인 기술을 사용하여 보안성은 높이고 싶지만, 외부로 공개하고 싶지 않을 수 있다. - 이를 해결하기 위해, **Secret Network 는 'programmable' 한 privacy 를 통한 tool 과 app 을 제공하고 있다.** 그리고 **Secret Contract**를 제공하는데, Secret Contract 는 암호화된 input, state 와 output로 구성된 스마트 컨트랙트를 의미하고 이는 디자인과 구현에 있어서 유연성을 제공할 수 있다. Protocol --- - Secret Network는 **Cosmos SDK과 Tendermint 의 BFT 합의 알고리즘기반의 레이어 1 솔루션**이다. Cosmos SDK를 사용하면 좋은 점은 Cosmos SDK 로 개발된 다른 레이어 1 네트워크와 Cosmos InterBlockchain Communcation Protocol (IBC) 기반으로 네트워크 간 통신이 가능하다는 것이 특징이다. - 그러면 Secret Network 는 보안을 위해 어떤 기능을 제공하고 있을까? **(1) Key management - 암호화에 필요한 키, (2) encryption protocol 그리고 (3) Trusted Execution Environment* (TEE) 를 관리하고 있다.** #### **SGX 와 TEE** - TEE 란 무엇일까? 간단히 설명하면 노드가 별도로 마련한 **암호화된 물리적인 영역**이라고 보면 된다. 이 TEE에 암호화된 데이터를 저장하고 처리한다. Secret Network는 이를 기반으로 programmable 한 privacy 를 제공하는데, 그 예시 중 하나가 SNIP-20 표준 기반의 SCRT 토큰이라고 볼 수 있다. - 블록체인에서 저장된 tx가 신뢰할 수 있는 프로토콜을 제공했다면, **TEE 는 하드웨어 내에서 신뢰할 수 있는 데이터 저장과 처리를 담당하는 기술**이다. TEE 는 메모리의 일정 부분을 암호화된 데이터 저장과 처리를 위해서 사용하고, 이 공간은 메인 OS와 별개로 운영된다. 새로운 노드가 추가될 때, 이 TEE 의 유효성에 대한 검토를 한다. TEE 에 대한 접근은 Intel 프로세서에서는 SGX 로 한다. SGX 는 Software Guard Extension 으로 TEE 에 대한 접근 권한을 갖는 특수 목적의 instruction set 이라고 볼 수 있다. Validator --- - 먼저 Validator가 되기 위해서는 다음과 같은 과정을 거쳐야 한다. 1. **부트스트랩 (초기 노드) 과정** 1) remote attestation* proof 을 통해서 TEE 의 유효성 검사 2) `consensus seed`가 생성되어 특정 디렉토리 위치에 저장. consensus seed는 Secret Network에서 가장 중요한 데이터임. 3) consensus seed exchange 와 consensus IO exchange 의 public key 값과 remote attestation proof 정보가 genesis.json 파일에 담김 2. **노드 등록** : 1) registration을 위한 curve25519 curve private/public key 페어를 생성한다 2) registration query 가 network consensus layer 에 요청이 되고, bootstrap 과 같이 remote attestation proof 를 진행한다 3) (부트스트랩 노드는) 복잡한 암호화 과정을 통해서 consensus seed 를 후보 노드에게 전송한다. 여기서 복잡한 암호화 과정이란, consensus seed exchange 의 private key 와 registration public key (1에서 생성한 key) 로 ECDH 를 만들어서 seed exchange IKM 을 생성한다. 이 값과 HKDF salt 를 활용해서 HKDF-SHA256을 활용하여 seed exchange key 를 생성한다. 이 값과 후보 노드의 public key를 입력으로 하여 AES-128-SIV 를 통해서 암호화된 consensus seed 를 생성한다. 4) 암호화된 consensus seed를 후보 노드가 받으면 이것을 복호화할 수 있는 값들이 있고, 이렇게 복호화된 key 는 특정 위치에 보관된다. 5) 이렇게 얻은 consensus seed 는 block 수행과 block 검증에 사용될 수 있다. - Validator 는 BFT consensus 기반으로 투표를 하여 block proposal 을 진행한다. SCRT 를 많이 보유할수록 block proposal 에서 선택될 가능성이 높아진다. 개인은 자신의 SCRT 를 validator 에게 위임하고 수익을 나눠 받을 수 있는 형식으로 이러한 메커니즘에 참여할 수 있다. #### **Remote Attestation Proof** - (추가 자료) SGX Attestation Process: 원격으로 - (참고자료: SGX Attestation Process - Research seminar in Cryptography) Privacy Preserving Secret Contracts --- - Secret Contract 는 CosmWasm 을 지원하기 때문에, IBC 를 통해서 멀티 체인에서 구동될 수 있다. Secret Contract 를 개발하는 언어는 Rust 이고, Rust 가 선택된 이유는 Wasm 을 컴파일하고, 낮은 가스비용과 최적화된 런타임 퍼포먼스를 보여주기 때문이다. 기본적인 Contract 인풋은 block height, time, chain id, sender, address, sent funds, contract 해시와 같은 암호화되어있지 않아도 되는 정보들과 client 가 만든 암호화되어야 하는 정보로 이뤄져있다. Contract state 는 항상 암호화가 되면 TEE 안에서 보관된다. Output 에 대한 정보는 tx 보낸 사람과 contract 자체적으로만 알고 있다. - Cosmos 와 다른 점은 query 를 날린 사람의 신원을 파악할 수 있다는 것이다. 암호화된 viewing key* 라는 것이 있는데, 이 것을 통해서 contract가 누구에 의해서 호출되었는지 알 수 있다. 또한 secret contract 는 ERC20 contract 의 approve 와 같게 다른 사람이 contract 의 balance 를 조작할 수 있는 권한을 줄 수 있다. #### **Viewing Key** - Viewing key는 사용자들이 암호화된 데이터나 자산을 볼 수 있는 툴이다. 뿐만 아니라 wallet 이나 explorer 등 제 3자 또는 다른 smart contract에서 자신의 암호화된 잔고를 볼 수 있도록 한다. Secret Network는 기본적으로 사용자들의 데이터와 자산을 암호화하고, 그 자산이 누구의 것인지에 대한 정보도 함께 암호화하여 저장한다. - SNIP-20 표준 기반의 Secret Token 은 기본적으로 Cosmos SDK 를 사용하기 때문에 데이터에 대해서 query 한 사람에 대한 인증 기능을 제공하고 있지 않다. 즉, 데이터에 대한 접근을 요청한 사람이 권한이 있는 사람인지 아닌지에 대한 정보가 없다. 이는, 암호화된 데이터에 대해서 복호화 할 수 있는 사람인지에 대한 정보가 없다는 것과도 같은 말이다. 이를 해결하기 위해서 viewing key 라는 개념이 도입되었다. - Viewing key는 암호화된 비밀번호와 같다. 사용자들이 이러한 비밀번호를 생성하고, 제 3자에게 공유함으로써 접근 권한에 대한 조절을 할 수 있다. (…) 한가지 문제점은, 이렇게 viewing key 를 생성하는 과정은 가스비를 필요로 하는데, 완전히 새로운 계정을 생성하고 SCRT 토큰이 하나도 없는 사용자의 경우 viewing key 를 생성할 수 없는 문제점이 있다. 또한, bottleneck 을 발생시키는 문제점이 생긴다. 예를 들어 민팅을 하는 경우 viewing key 를 사전에 발행해야하고, 이 때문에 사람들이 몰리게 되면 viewing key 가 민팅하는데 bottleneck 이 되어 사용성을 떨어뜨릴 수 있다는 문제가 있다. 요약하자면 viewing key 의 문제점은 다음과 같은 2가지가 있다. 1. 신규 사용자가 유입되었을 때 viewing key 생성에 대한 비용이 없어 가스비를 지불할 수 없음 2. UI/UX 플로우에서 불필요한 viewing key 생성은 전체 노드의 생성을 떨어뜨리는 문제점이 있음 - 이를 해결하기 위해 'Query Permit' 기능이 추가된 SNIP-24 design spec 이 제시되었다. Query permit 은 공개키 암호화 방식을 사용한다. Viewing key 와 다른 점은 secret contract 에 소유자의 identity를 저장하기 위해서 state를 mutate 하지 않기 때문에 추가적인 tx가 필요없다 (viewing key 에서 소유자의 identity 를 함께 저장하기 위해서 state update를 필요로 하기 때문에 추가적인 tx 와 가스비가 필요함을 위의 사례에서 알 수 있다) 공개키를 사용한 방식은 위에서 발생한 1) 가스비 지불의 문제와 2) 노드의 전체 성능을 저하시키는 문제점을 해결함으로써 최종적으로 사용성을 개선했다고 볼 수 있다. 또한, multiple token 에 대해서 동일한 permission 관리를 할 수 있다는 점도 query permit 방식의 장점 중 하나이다. - 하지만, tradeoff 를 보면 사용자의 identity 가 저장되지 않기 때문에 permit 은 항상 새로운 query에 대해서 검증하는 과정을 거쳐야 한다. Viewing key 방식이 secret contract 의 state 에 저장되는 방식은 단순 데이터 비교방식이지만, 공개키 방식은 더 많은 리소스를 필요로 한다. - 출처: https://medium.com/@secretnetwork/secret-network-access-control-viewing-keys-vs-permits-97baad539e72 Secret Contract State Encryption --- - Secret contract 에서는 암호화된 데이터 (state) 와 인터페이스하기 위해서 1) read_db(field_name), ) 2) write_db(field_name) 그리고 3) remove_db(field_name) 이렇게 3가지 기능을 제공하고 있다. 이 function call 들을 위한 암호화키는 consensus state IKM과 field_name, contract key를 통해서 HKDF-SHA256 로 생성된 암호화된 키를 사용한다. Contract key 는 signer id 와 인증된 contract key 의 조합으로 생성되고 이 contract key 의 목적은 secret contract 에 고유한 암호화된 키를 부여하기 위함이다. 이러한 방법은 가짜 키로 다시 암호화시키는 것을 방지하고, 가짜 키로 복호화하는 것을 방지한다. 또한 이는 다른 contract 의 동일한 코드 내용이더라도 각각 고유한 값을 가지도록 한다. - 맨 처음 contract 가 validator node의 TEE에서 초기화 될 때, contract key는 signer id 와 인증된 contract key의 조합으로 만들어진다 했다. 여기서 인증된 contract key는 HKDF salt 값과 consensus state IKM 과 signer id ㅇ를 이어붙여서 만든 IKM 에서 나온 값이다. Contract key (input) 가 보내지면 validator node 에서 assertion/ check 를 진행해서 예상한 contract key 값 (정답)과 비교하여 검증을 한다 Theoretical Attacks --- 1. Deanonymizing with ciphertext byte count 2. Two contracts with the same contract key deanonymize state 3. Transaction replay attack 4. Search-to-decision millionaire problem 5. Partial storage rollback during contract runtime 6. Transaction output data leakage 7. TEE vulnerability enabling a Byzantine node to acquire the consensus seed from the enclave 여담 --- - 지인 중 한 분이 일하는 Ramper라는 회사 또한 백엔드 시스템 구축을 할 때 사용한 보안 기술 중 `TEE`를 사용한다고 한다. TEE 는 비교적 최근에 인텔에서 소개한 기술로, 하드웨어 레벨의 보안 측면에서 많이들 사용하는 것으로 보인다.