TEE용 개발자 가이드

저자: 프라텍, 로샨, 싯다르타, 링귀네(말린), 크레인(아술라)편집: 셰우, 페어리 로움굿리얼엠엑스

애플의 프라이빗 클라우드 발표 이후 와 NVIDIA가 GPU에서 기밀 컴퓨팅을 제공하면서 신뢰할 수 있는 실행 환경(TEE)이 점점 더 인기를 얻고 있습니다. 이러한 <강력한> 기밀성 보장은 사용자 데이터(개인 키 포함)를 보호하는 데 도움이 되며, 격리는 사람, 다른 프로그램 또는 운영 체제에 의해 배포된 프로그램의 실행을 변조할 수 없도록 <강력> 보장합니다. 따라서 암호화폐와 인공지능 분야에서 제품을 개발할 때 TEE를 많이 사용하는 것은 놀라운 일이 아닙니다.

다른 신기술과 마찬가지로 TEE는 낙관적인 실험 기간을 거치고 있습니다. 이 문서에서는 개발자와 일반 독자에게 TEE의 개념, TEE 보안 모델, 일반적인 취약점 및 TEE를 안전하게 사용하기 위한 모범 사례 방법에 대한 기본 개념 가이드를 제공하고자 합니다. (참고: 본문을 쉽게 이해할 수 있도록 의도적으로 TEE 용어를 더 간단한 용어로 대체했습니다.)

TEE란

TEE는 프로세서 또는 데이터센터의 격리된 환경으로, 나머지 시스템의 간섭 없이 프로그램을 실행할 수 있는 공간입니다. 시스템의 나머지 부분으로부터의 간섭을 받지 않습니다. TEE가 나머지 시스템의 간섭을 받지 않도록 하려면 주로 엄격한 액세스 제어, 즉 TEE 내부의 프로그램과 데이터에 대한 나머지 시스템의 액세스를 제어하는 등 일련의 설계가 필요합니다. TEE는 현재 휴대폰, 서버, PC 및 클라우드 환경에서 보편화되어 있어 접근성과 경제성이 매우 뛰어납니다.

위 내용은 모호하고 추상적으로 들릴 수 있으며 실제로 서버 및 클라우드 제공업체마다 다른 방식으로 TEE를 구현하지만 근본적인 목적은 다른 프로그램에 의해 TEE가 간섭받지 않도록 하는 것입니다.

독자 대부분은 지문으로 휴대폰 잠금을 해제하는 등 생체 정보를 사용하여 디바이스에 로그인할 가능성이 높습니다. 지문으로 휴대폰 잠금을 해제하는 등 생체 정보를 사용하여 디바이스에 로그인하는 경우가 많습니다. 그렇다면 악성 앱, 웹사이트 또는 탈옥된 운영체제가 이러한 생체 정보에 액세스하여 탈취하지 못하도록 하려면 어떻게 해야 할까요? 사실, 데이터를 암호화하는 것 외에 TEE 장치의 회로는 어떤 프로그램도 민감한 데이터가 있는 메모리 및 프로세서 영역에 접근하는 것을 허용하지 않습니다.

하드웨어 지갑은 TEE 적용 시나리오의 또 다른 예입니다. 하드웨어 지갑은 컴퓨터에 연결하여 샌드박스에서 컴퓨터와 통신하지만 컴퓨터는 하드웨어 지갑에 저장된 니모닉에 직접 액세스할 수 없습니다. 두 경우 모두 사용자는 디바이스 제조업체가 칩을 적절하게 설계하고 적절한 펌웨어 업데이트를 제공하여 TEE 내의 기밀 데이터를 내보내거나 볼 수 없도록 할 것이라고 신뢰합니다.

보안 모델

유감스럽게도 TEE 구현은 매우 다양하며, 이러한 다양한 구현(IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) 모두 별도의 보안 모델을 사용하여 모델링하고 분석해야 합니다. 이 백서의 나머지 부분에서는 사용자 수가 더 많고 다양한 개발 도구를 사용할 수 있는 TEE 시스템인 IntelSGX, TDX 및 AWSNitro에 초점을 맞출 것입니다. 위의 시스템은 Web3에서 가장 일반적으로 사용되는 TEE 시스템이기도 합니다.

일반적으로 TEE에 배포된 애플리케이션의 워크플로우는 다음과 같습니다:

1. "개발자"가 오픈소스일 수도 있고 아닐 수도 있는 코드를 작성합니다

2. 그런 다음 개발자가 코드를 패키징하여 엔클레이브 이미지 파일(EIF)로 패키징하여 TEE에서 실행합니다

3. EIF는 TEE 시스템을 갖춘 서버에서 호스팅됩니다. 경우에 따라 개발자는 TEE가 설치된 PC를 사용하여 EIF를 호스팅하여 대중에게 직접 서비스를 제공할 수 있습니다

4. 사용자는 미리 정의된 인터페이스를 통해 애플리케이션과 상호 작용할 수 있습니다.

다음은 분명히 있습니다. 3가지 잠재적 위험:

• 개발자: EIF를 준비하는 데 사용되는 코드는 실제로 어떤 기능을 수행합니까?EIF 코드는 다음과 같지 않을 수 있습니다. 프로젝트에서 대중에게 광고한 비즈니스 로직과 일치하지 않을 수 있으며 개인 사용자 데이터를 도용할 수 있습니다

• SERVER: TEE 서버가 예상대로 EIF 파일을 실행하고 있습니까? 아니면 EIF가 실제로 TEE 내에서 실행되고 있나요? 서버는 TEE 내에서 다른 프로그램을 실행할 수도 있습니다

• Vendor: TEE가 안전하게 설계되어 있습니까? TEE의 모든 데이터를 공급업체에 유출하는 백도어가 있나요?

감사하게도 이제 TEE에는 이러한 위험을 제거할 수 있는 솔루션, 즉 재생산 가능한 빌드 및 원격 증명(원격 증명)이 있습니다. 어테스티테이션).

복제 가능한 빌드란 무엇인가요? 현대 소프트웨어 개발에는 외부 도구, 라이브러리 또는 프레임워크와 같은 많은 종속성을 가져와야 하는 경우가 많으며 이러한 종속성 파일은 잠재적으로 위험할 수도 있습니다. npm과 같은 프로그램은 이제 종속성 파일에 해당하는 코드의 해시를 고유 식별자로 사용합니다. npm은 종속성 파일이 기록된 해시와 일치하지 않는 것을 발견하면 종속성 파일이 수정된 것으로 간주할 수 있습니다.

반복 가능한 빌드는 일련의 표준으로 생각할 수 있습니다. 목표는 임의의 코드가 어떤 기기에서 실행되더라도 미리 지정된 프로세스에 따라 빌드되는 한 일관된 해시로 끝나는 것입니다. 물론 실제로는 해시가 아닌 다른 제품을 식별자로 사용할 수도 있는데, 이를 코드 측정이라고 합니다.

Nix는 반복 가능한 빌드를 위해 널리 사용되는 도구입니다. 애플리케이션의 소스 코드가 공개되면 누구나 코드를 검사하여 개발자가 예외를 삽입하지 않았는지 확인할 수 있으며, 누구나 Nix를 사용하여 코드를 빌드하고 빌드된 제품이 프로덕션 환경에서 프로젝트 팀이 배포한 제품과 동일한 코드 메트릭/해시를 가지고 있는지 확인할 수 있습니다.하지만 TEE에서 애플리케이션의 코드 메트릭을 어떻게 알 수 있을까요? 이를 위해 "원격 증명"이라는 개념이 필요합니다.

원격 증명은 프로그램의 코드 메트릭, TEE 플랫폼 버전 등이 포함된 TEE 플랫폼(신뢰할 수 있는 당사자)의 서명된 메시지입니다. 원격 증명을 통해 외부 관찰자는 프로그램이 누구도 접근할 수 없는 안전한 위치(실제 TEE의 xx 버전)에서 실행되고 있음을 알 수 있습니다.

반복 빌드 및 원격 증명을 사용하면 모든 사용자가 다음을 수행할 수 있습니다. 반복 가능한 빌드와 원격 증명을 통해 모든 사용자가 TEE 내부에서 실행 중인 실제 코드와 TEE 플랫폼 버전을 알 수 있으므로 개발자나 서버가 악의적인 행위를 저지르는 것을 방지할 수 있습니다.

그러나 TEE의 경우 항상 해당 공급업체를 신뢰할 필요가 있습니다. TEE 공급업체가 악의적인 경우 원격 증명을 위조할 수 있기 때문입니다. 따라서 공급업체를 가능한 공격 경로로 고려한다면 TEE에만 의존하는 것을 피하고 ZK 또는 합의 프로토콜과 결합하는 것이 바람직합니다.

TEE의 매력

우리 의견으로는 특히 AI 에이전트의 배포 친화성 측면에서 TEE의 특징은 다음과 같습니다.

• 성능:TEE는 높은 수준의 성능으로 LLM 모델을 실행할 수 있고. strong>비용 오버헤드는 일반 서버와 비슷합니다. 반면 zkML은 LLM을 위한 zk 증명을 생성하는 데 많은 연산을 소비합니다

• GPU 지원: NVIDIA는 최신 GPU 제품군(Hopper, Blackwell 등)를 통해 TEE 계산을 지원합니다

• 정확성: LLM은 비결정적이기 때문에 동일한 큐 단어를 여러 번 입력하면 다른 결과가 나옵니다. 따라서 여러 노드(허위 증명을 생성하려는 옵저버 포함)가 LLM 실행 결과에 대한 합의에 도달하지 못할 수도 있습니다. 이 시나리오에서 우리는 TEE에서 실행되는 LLM이 악의적인 사람들에 의해 조작될 수 없으며, TEE 내의 프로그램이 항상 작성된 대로 실행된다는 것을 신뢰할 수 있으며,이러한 이유로 TEE는 opML이나 합의보다 LLM 추론 결과의 신뢰성을 보장하는 데 더 적합합니다

• 기밀성: TEE의 데이터는 외부 프로그램에서 볼 수 없습니다. 따라서 TEE에서 생성되거나 수신된 개인 키는 항상 안전합니다. 이 기능을 사용하면 해당 키로 서명된 모든 메시지가 TEE의 내부 프로그램에서 온 것임을 사용자에게 확신시킬 수 있습니다. 사용자는 개인 키로 TEE를 신뢰하고 몇 가지 서명 조건을 설정할 수 있으며, TEE의 서명이 미리 정의된 서명 조건을 충족하는지 확인할 수 있습니다

• 네트워킹:여러 도구를 사용하여 TEE의 내부 프로세스에서 메시지를 서명하는 데 TEE를 사용할 수 있습니다. strong>여러 도구를 통해 TEE에서 실행 중인 프로그램은 TEE가 실행 중인 서버에 쿼리나 응답을 공개하지 않고도 인터넷에 안전하게 액세스할 수 있으며 제3자에게 올바른 데이터 검색을 보장할 수 있습니다(제3자에게 올바른 데이터 검색을 보장하는 동시에). 이는 타사 API에서 정보를 검색하는 데 유용하며, 신뢰할 수 있지만 독점적인 모델 제공업체에 계산을 아웃소싱하는 데 사용할 수 있습니다

• 쓰기 액세스: zk 시나리오와 달리 TEE에서 실행되는 코드는 다음을 수행할 수 있습니다. 메시지(트윗이든 트랜잭션이든)를 작성하고 API 및 RPC 네트워크 방문을 통해 전송

• 개발자 친화:TEE 관련 프레임워크 및 SDK를 사용하면 사람들이 어떤 언어로든 어떤 언어로든 코드를 작성하고 클라우드 서버에 배포하는 것처럼 쉽게 TEE에 프로그램을 배포할 수 있습니다

좋든 나쁘든, 현재 TEE를 사용하는 상당수의 사용 사례는 대안을 찾기가 어렵습니다. TEE의 도입으로 온체인 앱의 개발 공간이 더욱 확장되어 새로운 애플리케이션 시나리오를 이끌어낼 수 있다고 생각합니다.

TEE는 만병통치약이 아닙니다

TEE에서 실행되는 프로그램은 여전히 다양한 공격과 버그에 취약할 수 있습니다. 스마트 컨트랙트와 마찬가지로 다양한 문제가 발생하기 쉽습니다. 간단히 설명하기 위해 가능한 취약점을 다음과 같이 분류했습니다:

• 개발자 감독

• 런타임 버그

• 아키텍처 설계 결함

• 운영 문제

개발자 과실

의도적이든 비의도적이든 개발자는 의도적이든 비의도적이든 코드를 통해 TEE에서 프로그램의 보안 보증을 약화시킬 수 있습니다. 여기에는 다음이 포함됩니다:

• 불투명한 코드: TEE의 보안 모델은 외부 검증 가능성에 의존합니다. 코드의 투명성은 외부 타사 검증에 매우 중요합니다.

• 문제가 있는 코드 메트릭: 코드가 공개되어 있더라도 제3자가 코드를 리팩터링하고 원격 증명에서 코드 메트릭 값을 확인한 다음 원격 증명에서 제공된 코드 메트릭을 기반으로 하지 않고는 원격 증명에 제공된 코드 메트릭을 기반으로 합니다. 이는 zk 증명을 받지만 검증하지 않는 것과 유사합니다.

• 안전하지 않은 코드: TEE에서 키를 올바르게 생성하고 관리하더라도 코드에 포함된 로직이 외부 호출 중에 TEE 내에서 키가 유출될 수 있습니다. 또한 코드에 백도어나 취약점이 포함되어 있을 수도 있습니다. 기존 백엔드 개발과 비교했을 때 스마트 컨트랙트 개발과 유사한 높은 수준의 소프트웨어 개발 및 감사 프로세스가 필요합니다.

• 공급망 공격: 최신 소프트웨어 개발에는 많은 써드파티 코드가 사용됩니다. 공급망 공격은 TEE의 무결성에 심각한 위협이 됩니다.

런타임 취약성

개발자 중 가장 주의를 기울이는 사람도 런타임 취약성의 런타임 취약점의 피해자가 될 수 있습니다. 개발자는 다음 사항이 프로젝트의 보안 보장에 영향을 미치는지 신중하게 고려해야 합니다.

• 동적 코드: 모든 코드를 항상 투명하게 유지하는 것이 가능하지 않을 수 있습니다. 모든 코드를 항상 투명하게 유지하는 것은 불가능합니다. 사용 사례 자체에 따라 런타임에 TEE에 로드된 불투명 코드를 동적으로 실행해야 하는 경우도 있습니다. 이러한 코드는 쉽게 비밀을 노출하거나 불변성을 깨뜨릴 수 있으므로 이를 방지하기 위해 세심한 주의를 기울여야 합니다.

• 동적 데이터: 대부분의 애플리케이션은 실행 중에 외부 API 및 기타 데이터 소스를 사용합니다. 보안 모델은 이러한 데이터 소스를 포함하도록 확장되며, 이러한 데이터 소스는 DeFi에서 예후 예측자와 같은 위치에 있으며 부정확하거나 심지어 오래된 데이터는 재앙으로 이어질 수 있습니다. 예를 들어, AI 에이전트 사용 사례에서 클로드와 같은 LLM 서비스에 과도하게 의존하는 경우입니다.

• 안전하지 않고 불안정한 통신: TEE는 TEE 구성 요소가 포함된 서버 내에서 실행되어야 합니다. 보안 관점에서 볼 때, TEE를 실행하는 서버는 사실상 TEE와 외부 상호 작용 사이의 완벽한 중간자(MitM) 역할을 합니다. 서버는 TEE의 외부 연결을 스누핑하여 전송되는 내용을 확인할 수 있을 뿐만 아니라 특정 IP를 검열하고, 연결을 제한하고, 상대방이 xx에서 온 것으로 속이도록 설계된 패킷을 연결에 주입할 수도 있습니다.

  예를 들어, TEE 내에서 매칭 엔진을 실행하면 암호화된 트랜잭션을 처리할 수 있습니다. 라우터/게이트웨이/호스트는 여전히 패킷이 시작된 IP 주소에 따라 패킷을 삭제, 지연 또는 우선 순위를 지정할 수 있기 때문에 매칭 엔진은 공정한 주문 보장(Anti-MEV)을 제공할 수 없습니다.

구조적 결함

TEE 앱은 사용되는 기술 스택에 주의를 기울여야 합니다. TEE 애플리케이션을 빌드할 때 다음과 같은 문제가 발생할 수 있습니다.

• 공격 표면이 큰 애플리케이션:. 애플리케이션의 공격 표면은 완전한 보안을 보장해야 하는 코드 모듈의 수를 의미합니다. 공격 표면이 큰 코드는 감사하기가 매우 어렵고 버그나 악용 가능한 취약점을 숨길 수 있습니다. 이는 일반적으로 개발자 환경과도 충돌합니다. 예를 들어, Docker에 의존하는 TEE 프로그램은 Docker에 의존하지 않는 TEE 프로그램에 비해 훨씬 더 큰 공격 표면을 가지고 있습니다. 성숙한 운영 체제에 의존하는 엔클레이브는 가장 가벼운 운영 체제를 사용하는 TEE 프로그램보다 훨씬 더 큰 공격 표면을 가지고 있습니다

• 성능 및 활동성: Web3에서 애플리케이션은 은 검열에 저항해야 합니다. 누구나 TEE를 시작하여 비활성 시스템 참가자를 인수하고 TEE 내의 애플리케이션을 이동 가능하게 만들 수 있습니다. 가장 큰 과제는 키 이식성입니다. 일부 TEE 시스템 내에 키 파생 메커니즘이 존재하지만, 일단 TEE 내의 키 파생 메커니즘을 사용하면 다른 서버는 외부 TEE 애플리케이션 내에서 로컬로 키를 생성할 수 없기 때문에 일반적으로 TEE 애플리케이션은 동일한 시스템으로 제한되어 이식성을 유지하기에는 충분하지 않습니다."

• 안전하지 않은 신뢰 루트: 예를 들어, TEE에서 AI 에이전트를 실행할 때 주어진 주소가 에이전트의 소유인지 어떻게 확인합니까? 여기서 신중하게 설계하지 않으면 실제 신뢰 루트가 TEE 자체가 아닌 외부 타사 또는 키 호스팅 플랫폼일 가능성이 있습니다.

운영 문제

마지막으로, TEE를 실행하는 서버를 실제로 실행하는 방법에 대한 몇 가지 실질적인 질문이 있습니다. 프로그램을 실행하는 서버를 실제로 실행하는 방법에 대한 몇 가지 실용적인 고려 사항도 있습니다.

• 안전하지 않은 플랫폼 버전: TEE 플랫폼은 때때로 플랫폼에 반영되는 원격 증명에 플랫폼 버전으로 반영되는 보안 업데이트를 받습니다. TEE가 보안 플랫폼 버전에서 실행되지 않는 경우 해커는 알려진 공격 벡터를 사용하여 TEE에서 키를 훔칠 수 있습니다. 더 나쁜 경우, 오늘은 보안 플랫폼 버전에서 실행되고 있지만 내일은 안전하지 않을 수도 있습니다.

• 물리적 보안 없음: 최선의 노력에도 불구하고 TEE는 사이드 채널 공격에 취약할 수 있으며, 이는 종종 TEE가 상주하는 서버에 대한 물리적 액세스 및 제어를 필요로 합니다. 따라서 물리적 보안은 중요한 심층 방어 계층입니다. 이와 관련된 개념으로 클라우드 증명이 있는데, TEE가 클라우드 데이터 센터에서 실행되고 있으며 클라우드 플랫폼이 물리적 보안을 보장한다는 것을 증명할 수 있습니다.

보안 TEE 프로세스 구축

우리는 권장 사항을 다음과 같이 나누었습니다. /strong>

• 가장 안전한 옵션

• 취하기

• 사용 사례에 따른 권장 사항

1. 가장 안전한 시나리오: 외부 종속성 없음

1. strong>

보안성이 높은 애플리케이션을 만들려면 외부 입력, API 또는 서비스와 같은 외부 종속성을 제거하여 공격 표면을 줄여야 할 수 있습니다. 이 접근 방식은 애플리케이션이 무결성이나 보안을 손상시킬 수 있는 외부 상호 작용 없이 독립적인 방식으로 작동하도록 보장합니다. 이 전략은 프로그램의 기능적 다양성을 제한할 수 있지만 매우 높은 수준의 보안을 제공할 수 있습니다.

모델이 로컬에서 실행되는 경우 대부분의 CryptoxAI 사용 사례에서 이 수준의 보안을 달성할 수 있습니다.

2. 필요한 예방 조치

애플리케이션에 외부 의존성이 있는지 여부에 관계없이 다음 사항이 필요합니다!

TEE 앱을 백엔드 앱이 아닌 스마트 컨트랙트로 생각하고 업데이트를 적게 하고 엄격하게 테스트하세요.

TEE 앱 구축은 스마트 컨트랙트를 작성, 테스트 및 업데이트하는 것만큼이나 엄격하게 이루어져야 합니다. 스마트 컨트랙트와 마찬가지로 TEE는 실수나 예상치 못한 동작으로 인해 자금 전액 손실 등 심각한 결과를 초래할 수 있는 매우 민감하고 변조가 불가능한 환경에서 작동합니다. TEE 기반 애플리케이션의 무결성과 신뢰성을 보장하기 위해서는 철저한 감사, 광범위한 테스트, 최소한의 신중하게 감사된 업데이트가 필수적입니다.

코드 감사 및 빌드 파이프라인 확인

애플리케이션의 보안은 코드 자체뿐만 아니라 빌드 프로세스에서 사용되는 도구에 따라 달라집니다. . 안전한 빌드 파이프라인은 취약점을 방지하는 데 매우 중요합니다. TEE는 제공된 코드가 의도한 대로 실행되도록 보장할 뿐, 빌드 프로세스 중에 발생한 결함을 수정할 수는 없습니다.

위험을 완화하려면 코드를 엄격하게 테스트하고 감사하여 오류를 제거하고 원치 않는 정보 유출을 방지해야 합니다. 또한 반복 가능한 빌드는 특히 한 쪽에서 코드를 개발하여 다른 쪽에서 사용할 때 중요한 역할을 합니다. 반복 가능한 빌드를 사용하면 누구나 TEE 내에서 실행된 프로그램이 원본 소스 코드와 일치하는지 확인할 수 있으므로 투명성과 신뢰가 보장됩니다. 반복 가능한 빌드가 없으면 TEE 내에서 실행되는 프로그램의 정확한 내용을 파악하는 것이 거의 불가능하여 애플리케이션의 보안이 손상될 수 있습니다.

예를 들어, TEE에서 웜의 뇌 시뮬레이션 모델을 실행하는 프로젝트인 DeepWorm의 소스 코드는 완전히 공개되어 있으며, TEE 내의 실행 파일은 Nix 파이프라인을 사용하여 재현 가능한 방식으로 빌드됩니다.

감사 또는 검증된 라이브러리 사용

TEE 애플리케이션에서 민감한 데이터로 작업할 때는 키 관리 및 비공개 데이터 처리에 감사된 라이브러리만 사용하세요. 감사되지 않은 라이브러리는 키가 노출되어 애플리케이션 보안이 손상될 수 있습니다. 데이터 기밀성과 무결성을 유지하기 위해 완전히 검증된 보안 중심 종속성의 우선순위를 정하세요.

항상 TEE의 증명을 검증

TEE와 상호작용하는 사용자는 TEE에서 생성한 원격 증명 또는 인증 메커니즘의 유효성을 검사하여 다음과 같이 보장해야 합니다. 안전하고 신뢰할 수 있는 상호작용을 보장합니다. 이러한 확인이 없으면 서버가 실제 TEE 출력과 변조된 데이터를 구분할 수 없는 방식으로 응답을 조작할 수 있습니다. 원격 증명은 TEE에서 실행되는 코드베이스 및 구성에 대한 중요한 증명을 제공하며, 원격 증명을 기반으로 TEE 내에서 실행되는 프로그램이 예상대로 실행되는지 여부를 확인할 수 있습니다.

특정 증명은 온체인(IntelSGX, AWSNitro), 오프체인(ZK 증명)을 사용하여 검증하거나 사용자 자신 또는 t16z 또는 MarlinHub와 같은 호스팅 서비스를 통해 검증할 수 있습니다.

3. 사용 사례별 권장 사항

앱의 대상 사용 사례와 구조에 따라 다음 팁이 앱의 보안을 강화하는 데 도움이 될 수 있습니다.

사용자와의 상호작용이 항상 보안 채널에서 이루어지도록 합니다

TEE가 상주하는 서버는 본질적으로 신뢰할 수 없는 서버입니다. 서버는 통신을 가로채고 수정할 수 있습니다. 어떤 경우에는 서버가 데이터를 읽지만 변경하지 않는 것이 허용될 수 있지만, 다른 경우에는 데이터를 읽는 것조차 바람직하지 않을 수 있습니다. 이러한 위험을 완화하려면 사용자와 TEE 사이에 안전한 엔드투엔드 암호화 채널을 구축하는 것이 중요합니다. 최소한 메시지의 진위 여부와 출처를 확인할 수 있는 서명이 포함되어 있는지 확인하세요. 또한 <강조>사용자는 항상 TEE가 원격 증명을 제공하여 올바른 TEE와 통신하고 있는지 확인해야 합니다. 이를 통해 통신의 무결성과 기밀성을 보장할 수 있습니다.

예를 들어, Oyster는 CAA 레코드와 RFC8657을 사용하여 안전한 TLS 발급을 지원할 수 있습니다. 또한 WebPKI에 의존하지 않는 Scallop이라는 TEE 네이티브 TLS 프로토콜을 제공합니다.

TEE 메모리가 일시적이라는 것을 알기

TEE 메모리가 일시적이라는 것을 알기

TEE 메모리는 일시적이므로 TEE가 종료되면 그 내용(암호화 키 포함)이 손실됩니다. 이 정보를 보존하는 안전한 메커니즘이 없으면 중요한 데이터에 영구적으로 액세스할 수 없게 되어 자금이나 운영이 위험에 처할 수 있습니다.

IPFS와 같은 분산형 스토리지 시스템을 갖춘 멀티파티 컴퓨팅(MPC) 네트워크를 이 문제에 대한 해결책으로 사용할 수 있습니다. MPC 네트워크는 여러 노드에 키를 분할하여 단일 노드가 전체 키를 보유하지 않도록 하면서 필요한 경우 네트워크가 키를 재구성할 수 있도록 합니다. 이 키로 암호화된 데이터는 IPFS에 안전하게 저장할 수 있습니다.

필요한 경우, 특정 조건이 충족되면 MPC 네트워크는 동일한 이미지를 실행하는 새 TEE 서버에서 키를 사용할 수 있도록 할 수 있습니다. 이 접근 방식은 신뢰할 수 없는 환경에서도 데이터 접근성과 기밀성을 유지하면서 탄력적이고 강력한 보안을 보장합니다.

또 다른 솔루션이 있습니다. 즉, TEE가 관련 트랜잭션을 별도의 MPC 서버에 넘기고, 이 서버가 서명한 다음 통합 서명을 수행하여 체인에서 트랜잭션을 마무리하는 것입니다. 이 접근 방식은 유연성이 훨씬 떨어지며 API 키, 비밀번호 또는 임의의 데이터를 저장하는 데 사용할 수 없습니다(신뢰할 수 있는 타사 저장소 서비스가 없음).

공격 표면 줄이기

안전이 중요한 사용 사례의 경우 개발자 경험을 희생하더라도 가능한 한 많은 주변 종속성을 최소화하는 것이 좋습니다. 예를 들어, Dstack은 Dstack이 작동하는 데 필요한 모듈만 포함된 최소한의 Yocto 기반 커널과 함께 제공됩니다. 부트로더나 OS가 TEE의 일부가 될 필요가 없는 SGX(TDX보다)와 같은 이전 기술을 사용하는 것이 더 나을 수도 있습니다.

물리적 격리

인간의 개입 가능성으로부터 TEE를 물리적으로 격리하여 보안을 더욱 강화할 수 있습니다. 데이터 센터와 클라우드 제공업체에서 TEE 서버를 호스팅하여 물리적 보안을 제공하는 데이터 센터를 신뢰할 수 있습니다. 그러나 스페이스코인 같은 프로젝트는 다소 흥미로운 대안을 모색하고 있습니다. 스페이스티는 위성이 궤도에 진입할 때 예상에서 벗어나지 않는지 확인하기 위해 발사 후 관성 모멘트를 측정하는 등의 보안 조치에 의존하고 있습니다.

멀티프로바이더

이더리움이 전체 네트워크에 영향을 미치는 버그의 위험을 줄이기 위해 다중 클라이언트 구현에 의존하는 것처럼, 멀티프로바이더는 전체 네트워크에 영향을 미치는 버그의 위험을 줄이기 위해 다양한 TEE 구현 방식을 사용하여 보안과 복원력을 향상시킵니다. <멀티프로바이더는 여러 TEE 플랫폼에서 동일한 계산 단계를 실행함으로써 한 TEE 구현의 취약점이 전체 애플리케이션을 손상시키지 않도록 보장합니다. 이 접근 방식은 계산 프로세스가 결정론적이어야 하거나 비결정론적 상황에서 서로 다른 TEE 구현 시나리오 간의 합의를 정의해야 하지만, 오류 격리, 중복성 및 교차 검증과 같은 상당한 이점을 제공하므로 신뢰성 보장이 필요한 애플리케이션에 적합한 선택이 될 수 있습니다.

앞으로 보기

TEE는 분명 매우 흥미로운 분야가 되었습니다. 앞서 언급했듯이, AI의 보편화와 민감한 사용자 데이터에 대한 지속적인 액세스는 Apple과 NVIDIA와 같은 대형 기술 기업들이 자사 제품에 TEE를 사용하고 TEE를 서비스의 일부로 제공하고 있음을 의미합니다.

반면, 암호화폐 커뮤니티는 보안에 매우 집중해 왔습니다. 개발자들이 온체인 앱과 사용 사례를 확장하려고 시도함에 따라, 기능과 신뢰 가정 사이에서 적절한 균형을 제공하는 솔루션으로 TEE가 인기를 얻고 있습니다. TEE는 완전한 ZK 솔루션만큼 신뢰를 최소화하지는 않지만, 저희는 TEE가 웹 3.0 기업의 제품과 대형 기술 기업의 제품을 천천히 융합하는 첫 번째 길이 될 것으로 기대합니다.