TEE Concise Handbook: 기본 개념부터 안전한 사용까지 모범 사례 가이드

원제: TEE 앱 보안: 개발자 가이드

원저자: prateek, roshan, siddhartha & linguine(Marlin), krane(Asula)

편집자: Shew, GodRealmX

Apple이 프라이빗 클라우드를 발표하고 NVIDIA가 GPU에 기밀 컴퓨팅을 제공한 이후 TEE(신뢰할 수 있는 실행 환경)가 점점 인기를 얻고 있습니다. 기밀성은 개인 키를 포함할 수 있는 사용자 데이터를 보호하는 데 도움이 되며, 격리는 배포된 프로그램의 실행이 사람, 다른 프로그램 또는 운영 체제에 의해 변조될 수 없도록 보장합니다. 따라서 Crypto x AI 분야에서 TEE를 광범위하게 사용하여 제품을 만드는 것은 놀라운 일이 아닙니다.

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

TEE 란 무엇입니까?

TEE는 나머지 시스템의 간섭 없이 프로그램을 실행할 수 있는 프로세서 또는 데이터 센터의 격리된 환경입니다. TEE가 다른 부분의 간섭을 받지 않도록 하려면 주로 엄격한 액세스 제어, 즉 TEE의 프로그램 및 데이터에 대한 시스템의 다른 부분의 액세스를 제어하는 ​​일련의 설계가 필요합니다. TEE는 이제 휴대폰, 서버, PC 및 클라우드 환경 어디에나 존재하므로 접근성이 뛰어나고 저렴합니다.

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

대부분의 독자는 지문으로 휴대폰 잠금을 해제하는 등 생체 인식 정보를 사용하여 장치에 로그인할 수 있습니다. 하지만 악성 앱, 웹사이트 또는 탈옥된 운영 체제가 이러한 생체 정보에 액세스하여 이를 훔칠 수 없도록 어떻게 보장할 수 있을까요? 실제로 데이터를 암호화하는 것 외에도 TEE 장치의 회로는 어떤 프로그램도 민감한 데이터가 차지하는 메모리 및 프로세서 영역에 액세스하는 것을 허용하지 않습니다.

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

보안 모델

불행하게도 TEE 구현에는 다양한 유형이 있으며 이러한 다양한 구현(IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone)에는 독립적인 보안 모델 모델링 분석이 필요합니다. 이 기사의 나머지 부분에서는 Intel SGX, TDX 및 AWS Nitro에 대해 주로 설명하겠습니다. 이러한 TEE 시스템에는 더 많은 사용자가 있고 사용 가능한 완전한 개발 도구가 있기 때문입니다. 위 시스템은 Web3에서 가장 일반적으로 사용되는 TEE 시스템이기도 합니다.

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

1. "개발자"는 오픈 소스일 수도 있고 아닐 수도 있는 일부 코드를 작성합니다.
2. 그런 다음 개발자는 코드를 EIF(Enclave Image File)로 패키징하여 TEE에서 실행할 수 있습니다.
3. EIF는 TEE 시스템이 있는 서버에서 호스팅됩니다. 경우에 따라 개발자는 TEE가 있는 개인용 컴퓨터를 직접 사용하여 EIF를 호스팅하여 외부 서비스를 제공할 수 있습니다.
4. 사용자는 사전 정의된 인터페이스를 통해 애플리케이션과 상호 작용할 수 있습니다.

분명히 여기에는 세 가지 잠재적 위험이 있습니다.

• 개발자: EIF를 준비하는 데 사용된 코드는 정확히 무엇을 합니까? EIF 코드는 프로젝트 당사자가 추진하는 비즈니스 로직을 따르지 않을 수 있으며 사용자의 개인 데이터를 도용할 수 있습니다.
• 서버: TEE 서버가 예상대로 EIF 파일을 실행합니까? 아니면 EIF가 실제로 TEE 내에서 실행됩니까? 서버는 TEE 내에서 다른 프로그램을 실행할 수도 있습니다.
• 공급자: TEE는 안전하도록 설계되었나요? TEE 내의 모든 데이터를 공급업체에 유출하는 백도어가 있나요?

다행스럽게도 TEE에는 이제 위의 위험을 제거할 수 있는 솔루션, 즉 재현 가능한 빌드 및 원격 증명(원격 증명)이 있습니다.

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

반복 가능한 빌드는 일련의 표준으로 생각할 수 있습니다. 목표는 미리 지정된 프로세스에 따라 빌드되는 한 어떤 장치에서든 코드가 실행될 때 결국 일관된 해시 값을 얻을 수 있다는 것입니다. 물론 실제로는 해싱 이외의 제품을 식별자로 사용할 수도 있습니다. 여기서는 이를 코드 측정이라고 합니다.

Nix는 반복 가능한 빌드를 위한 일반적인 도구입니다. 프로그램의 소스코드가 공개되면 누구나 코드를 통해 개발자가 비정상적인 내용을 삽입하지 않았는지 확인할 수 있습니다. 프로덕션 환경의 프로젝트. 하지만 TEE에서 프로그램의 코드 메트릭을 어떻게 알 수 있습니까? 여기에는 "원격 증명"이라는 개념이 포함됩니다.

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

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

하지만 TEE의 경우 공급업체에 대한 신뢰가 항상 필요합니다. TEE 공급업체가 악의적인 행위를 하면 원격 인증서를 직접 위조할 수 있습니다. 따라서 공급자가 가능한 공격 벡터로 간주되는 경우 TEE에만 의존하는 것은 피해야 하며 이를 ZK 또는 합의 프로토콜과 결합하는 것이 좋습니다.

TEE의 매력

우리의 의견으로는 TEE의 특히 인기 있는 기능, 특히 AI 에이전트에 대한 배포 친화성은 주로 다음 사항에 있습니다.

• 성능: TEE는 일반 서버와 유사한 성능 및 비용 오버헤드로 LLM 모델을 실행할 수 있습니다. 그러나 zkML은 LLM의 zk 증명을 생성하기 위해 많은 컴퓨팅 성능이 필요합니다.
• GPU 지원: NVIDIA는 최신 GPU 시리즈(Hopper, Blackwell 등)에서 TEE 컴퓨팅 지원을 제공합니다.
• 정확성: LLM은 비결정적입니다. 동일한 프롬프트 단어를 여러 번 입력하면 다른 결과가 나타납니다. 따라서 여러 노드(사기 증명을 생성하려는 관찰자를 포함)는 LLM 작업 결과에 대한 합의에 도달하지 못할 수 있습니다. 이 시나리오에서는 TEE에서 실행되는 LLM이 악의적인 행위자에 의해 조작될 수 없다는 것을 신뢰할 수 있습니다. TEE 내의 프로그램은 항상 작성된 대로 실행되므로 LLM 추론 결과의 신뢰성을 보장하기 위해 TEE가 opML 또는 합의보다 더 적합합니다.
• 기밀성: TEE의 데이터는 외부 프로그램에 표시되지 않습니다. 따라서 TEE에서 생성되거나 수신된 개인키는 항상 안전합니다. 이 기능을 사용하면 이 키로 서명된 모든 메시지가 TEE의 내부 절차에서 비롯된 것임을 사용자에게 확신시킬 수 있습니다. 사용자는 개인키를 TEE에 안전하게 위탁하고 일부 서명 조건을 설정할 수 있으며, TEE의 서명이 미리 설정된 서명 조건을 충족하는지 확인할 수 있습니다.
• 네트워킹: 일부 도구를 통해 TEE에서 실행되는 프로그램은 TEE가 실행되는 서버에 대한 쿼리나 응답을 공개하지 않고 제3자에게 올바른 데이터 검색을 보장하면서 인터넷에 안전하게 액세스할 수 있습니다. 이는 타사 API에서 정보를 검색하는 데 유용하며 신뢰할 수 있지만 독점 모델 제공자에게 계산을 아웃소싱하는 데 사용할 수 있습니다.
• 쓰기 액세스: zk 솔루션과 달리 TEE에서 실행되는 코드는 메시지(트윗이든 트랜잭션이든)를 작성하고 API 및 RPC 네트워크 액세스를 통해 보낼 수 있습니다.
• 개발자 친화적: TEE 관련 프레임워크 및 SDK를 통해 사람들은 어떤 언어로든 코드를 작성하고 클라우드 서버에서처럼 쉽게 TEE에 프로그램을 배포할 수 있습니다.

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

TEE는 만능이 아니다

TEE에서 실행되는 프로그램은 여전히 ​​다양한 공격과 버그에 취약합니다. 스마트 계약과 마찬가지로 다양한 문제가 발생하기 쉽습니다. 단순화를 위해 가능한 취약점을 다음과 같이 분류합니다.

• 개발자 과실
• 런타임 취약점
• 건축 설계 결함
• 운영 문제

개발자 과실

의도적이든 아니든 개발자는 의도적이거나 의도하지 않은 코드를 통해 TEE에 있는 프로그램의 보안 보장을 약화시킬 수 있습니다. 여기에는 다음이 포함됩니다.

• 불투명 코드: TEE의 보안 모델은 외부 검증 가능성에 의존합니다. 코드 투명성은 외부 제3자 검증에 매우 중요합니다.
• 코드 측정항목에 문제가 있습니다. 코드가 공개되어 있어도 코드를 다시 빌드하고 원격 증명에서 코드 측정항목을 확인한 후 원격 증명에서 제공되는 코드 측정항목과 대조하는 제3자가 없는 경우 . 이는 zk 증명을 받았지만 확인하지 않는 것과 유사합니다.
• 안전하지 않은 코드: TEE에서 키를 올바르게 생성하고 관리하도록 주의를 기울이더라도 코드에는 외부 세계로 호출하는 동안 TEE 내의 키를 유출할 수 있는 논리가 포함되어 있습니다. 또한 코드에 백도어나 취약점이 포함될 수 있습니다. 기존 백엔드 개발과 비교할 때 스마트 계약 개발과 유사하게 소프트웨어 개발 및 감사 프로세스에 높은 표준이 필요합니다.
• 공급망 공격: 최신 소프트웨어 개발에서는 대량의 타사 코드를 사용합니다. 공급망 공격은 TEE의 무결성에 심각한 위협이 됩니다.

런타임 취약점

개발자가 아무리 조심하더라도 런타임 취약점의 희생양이 될 수 있습니다. 개발자는 다음 사항이 프로젝트의 보안 보증에 영향을 미치는지 여부를 신중하게 고려해야 합니다.

• 동적 코드: 모든 코드를 투명하게 유지하는 것이 항상 가능하지는 않습니다. 때로는 사용 사례 자체에서 런타임 시 TEE에 로드된 불투명 코드의 동적 실행이 필요한 경우가 있습니다. 이러한 코드는 쉽게 비밀을 공개하거나 불변성을 깨뜨릴 수 있으므로 이를 방지하려면 세심한 주의를 기울여야 합니다.
• 동적 데이터: 대부분의 애플리케이션은 실행 중에 외부 API 및 기타 데이터 소스를 사용합니다. 보안 모델은 DeFi의 오라클과 동일한 기반에 있는 이러한 데이터 소스를 포함하도록 확장됩니다. 이러한 데이터 소스는 부정확하거나 오래된 데이터로 인해 재난이 발생할 수 있습니다. 예를 들어 AI Agent 사용 사례의 경우 Claude와 같은 LLM 서비스에 대한 의존도가 과도합니다.
• 안전하지 않고 불안정한 통신: TEE는 TEE 구성 요소가 포함된 서버 내에서 실행되어야 합니다. 보안 관점에서 볼 때 TEE를 실행하는 서버는 실제로 TEE와 외부 상호 작용 사이의 완벽한 중개자(MitM)입니다. 서버는 TEE의 나가는 연결을 들여다보고 전송되는 내용을 볼 수 있을 뿐만 아니라 특정 IP를 검열하고 연결을 제한하며 한 당사자가 xx에서 오는 것으로 생각하도록 속이기 위해 연결에 패킷을 주입할 수도 있습니다.

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

구조적 결함

TEE 애플리케이션에서 사용되는 기술 스택은 주의해서 사용해야 합니다. TEE 애플리케이션을 구축할 때 다음과 같은 문제가 발생할 수 있습니다.

• 공격 표면이 큰 애플리케이션: 애플리케이션의 공격 표면은 완전히 보안되어야 하는 코드 모듈의 수입니다. 공격 표면이 넓은 코드는 감사하기가 매우 어려우며 버그나 악용 가능한 취약점을 숨길 수 있습니다. 이는 종종 개발자 경험과 충돌하기도 합니다. 예를 들어 Docker를 사용하는 TEE 프로그램은 Docker를 사용하지 않는 TEE 프로그램보다 공격 표면이 훨씬 더 큽니다. 성숙한 운영 체제를 사용하는 엔클레이브는 가장 가벼운 운영 체제를 사용하는 TEE 프로그램보다 더 큰 공격 표면을 갖습니다.
• 이식성 및 활성: Web3에서 애플리케이션은 검열에 저항해야 합니다. 누구나 TEE를 시작하고 비활성 시스템 참가자를 인수하고 TEE 내에서 애플리케이션을 이식 가능하게 만들 수 있습니다. 여기서 가장 큰 과제는 키 이식성입니다. 일부 TEE 시스템에는 키 파생 메커니즘이 내장되어 있지만 TEE 내의 키 파생 메커니즘이 사용되면 다른 서버는 외부 TEE 프로그램 내에서 로컬로 키를 생성할 수 없습니다. 이로 인해 TEE 프로그램은 일반적으로 동일한 시스템으로 제한됩니다. 휴대성을 유지하기에는 부족합니다.
• 안전하지 않은 신뢰 루트: 예를 들어 TEE에서 AI 에이전트를 실행할 때 주어진 주소가 에이전트에 속하는지 어떻게 확인합니까? 이것이 신중하게 설계되지 않으면 실제 신뢰 루트는 TEE 자체가 아닌 외부 제3자 또는 주요 에스크로 플랫폼일 수 있습니다.

운영 문제

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

• 안전하지 않은 플랫폼 버전: TEE 플랫폼은 때때로 보안 업데이트를 수신하며, 이는 원격 증명의 플랫폼 버전으로 반영됩니다. TEE가 보안 플랫폼 버전에서 실행되지 않는 경우 해커는 알려진 공격 벡터를 악용하여 TEE에서 키를 훔칠 수 있습니다. 더 나쁜 것은 TEE가 오늘은 안전한 플랫폼 버전에서 실행되고 내일은 안전하지 않을 수 있다는 것입니다.
• 물리적 보안 없음: 최선의 노력에도 불구하고 TEE는 일반적으로 TEE가 있는 서버에 대한 물리적 액세스 및 제어가 필요한 부채널 공격에 취약할 수 있습니다. 따라서 물리적 보안은 심층 방어의 중요한 계층입니다. 관련 개념은 TEE가 클라우드 데이터 센터에서 실행되고 클라우드 플랫폼에 물리적 보안이 보장된다는 것을 증명할 수 있는 클라우드 증명입니다.

안전한 TEE 프로그램 구축

우리는 권장 사항을 다음 사항으로 분류합니다.

• 가장 안전한 솔루션
• 취해야 할 필수 예방 조치
• 사용 사례에 따른 권장 사항

1. 가장 안전한 솔루션: 외부 종속성이 없습니다.

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

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

2. 취해야 할 필요한 예방 조치

애플리케이션에 외부 종속성이 있는지 여부에 관계없이 다음은 필수입니다!

TEE 애플리케이션을 백엔드 애플리케이션이 아닌 스마트 계약으로 취급하고 업데이트 빈도를 낮게 유지하고 엄격하게 테스트하세요.

TEE 프로그램 구축은 스마트 계약 작성, 테스트 및 업데이트만큼 엄격해야 합니다. 스마트 계약과 마찬가지로 TEE는 오류나 예상치 못한 행동이 자금의 완전한 손실을 포함하여 심각한 결과를 초래할 수 있는 매우 민감하고 불변적인 환경에서 작동합니다. TEE 기반 애플리케이션의 무결성과 안정성을 보장하려면 철저한 감사, 광범위한 테스트, 최소한의 주의 깊게 감사된 업데이트가 중요합니다.

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

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

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

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

감사되거나 검증된 라이브러리 사용

TEE 프로그램에서 민감한 데이터를 처리할 때 키 관리 및 개인 데이터 처리를 위해 감사된 라이브러리만 사용하십시오. 감사되지 않은 라이브러리는 키를 노출하고 애플리케이션 보안을 손상시킬 수 있습니다. 잘 조사된 보안 중심 종속성에 우선순위를 부여하여 데이터 기밀성과 무결성을 유지합니다.

항상 TEE의 증거를 확인하세요.

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

특정 증명은 온체인(IntelSGX, AWSNitro), ZK 증명을 사용한 오프체인(IntelSGX, AWSNitro) 또는 사용자 자신이나 호스팅 서비스(예: t16z 또는 MarlinHub)를 통해 확인할 수 있습니다.

3. 사용 사례에 따른 권장사항

애플리케이션의 대상 사용 사례와 해당 구조에 따라 다음 팁은 애플리케이션을 더욱 안전하게 만드는 데 도움이 될 수 있습니다.

TEE와의 사용자 상호 작용이 항상 보안 채널을 통해 수행되는지 확인하세요.

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

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

TEE 메모리는 일시적이라는 것을 알고 있습니다.

TEE 메모리는 일시적입니다. 즉, TEE가 꺼지면 암호화 키를 포함한 해당 콘텐츠가 손실됩니다. 이 정보를 보관하는 보안 메커니즘이 없으면 중요한 데이터에 영구적으로 액세스할 수 없게 되어 잠재적으로 자금이나 운영에 어려움을 겪을 수 있습니다.

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

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

또 다른 솔루션이 있습니다. 즉, TEE는 MPC 서버가 서명한 후 관련 트랜잭션을 각각 다른 MPC 서버에 전달하고 집계 서명을 수행한 후 최종적으로 트랜잭션을 체인에 업로드합니다. 이 방법은 유연성이 훨씬 낮으며 API 키, 비밀번호 또는 임의의 데이터(신뢰할 수 있는 타사 스토리지 서비스 없이)를 저장하는 데 사용할 수 없습니다.

공격 표면 감소

보안이 중요한 사용 사례의 경우 개발자 경험을 희생하면서 주변 장치 종속성을 최대한 줄이는 것이 좋습니다. 예를 들어, Dstack은 Dstack이 작동하는 데 필요한 모듈만 포함하는 최소 Yocto 기반 커널과 함께 제공됩니다. SGX(TDX 이상)와 같은 이전 기술을 사용하는 것이 가치가 있을 수도 있습니다. 이 기술은 TEE의 일부가 되기 위해 부트로더나 운영 체제가 필요하지 않기 때문입니다.

물리적 격리

TEE를 사람의 개입 가능성으로부터 물리적으로 격리하면 TEE의 안전성이 더욱 향상될 수 있습니다. 데이터 센터 및 클라우드 제공업체에서 TEE 서버를 호스팅함으로써 이를 수행할 수 있지만 데이터 센터가 물리적 보안을 제공할 수 있다고 믿습니다. 그러나 Spacecoin과 같은 프로젝트는 다소 흥미로운 대안인 우주를 탐색하고 있습니다. SpaceTEE의 논문은 위성이 궤도에 진입하는 과정에서 예상에서 벗어나는지 여부를 확인하기 위해 발사 후 관성 모멘트 측정과 같은 안전 조치에 의존합니다.

여러 증명자

Ethereum이 전체 네트워크에 영향을 미치는 버그의 위험을 줄이기 위해 여러 클라이언트 구현에 의존하는 것처럼 다중 증명자는 다양한 TEE 구현을 사용하여 보안과 탄력성을 높입니다. 여러 TEE 플랫폼에서 동일한 계산 단계를 실행함으로써 다중 검증을 통해 하나의 TEE 구현의 취약점이 전체 애플리케이션을 손상시키지 않도록 보장합니다. 이 접근 방식에서는 계산 프로세스가 결정적이거나 비결정적 상황에서 서로 다른 TEE 구현 간의 합의를 정의해야 하지만 결함 격리, 중복성 및 교차 검증과 같은 중요한 이점도 제공하므로 좋은 선택일 때 신뢰할 수 있는 솔루션이 됩니다. 섹스 안심 앱을 위해.

미래를 바라보며

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

반면 암호화폐 커뮤니티는 항상 보안에 중점을 두었습니다. 개발자가 온체인 애플리케이션과 사용 사례를 확장하려고 시도하면서 TEE가 기능과 신뢰 가정 간의 올바른 균형을 제공하는 솔루션으로 인기를 얻는 것을 확인했습니다. TEE는 전체 ZK 솔루션만큼 신뢰가 최소화되지는 않지만 TEE가 Web3 회사와 대규모 기술 회사의 제품을 천천히 통합하는 첫 번째 경로가 될 것으로 기대합니다.