npm audit가 당신을 구해주지 못한다: 우리가 TEEs(Trusted Execution Environments)로 전환한 이유
Source: Dev.to
개발자들은 코드 품질에 집착합니다. 우리는 린터를 실행하고, 정적 분석을 수행하며, 의존성을 패치합니다. 하지만 디지털 자산 보관 분야에서는 손상된 하드웨어에서 실행되는 완벽한 코드조차 여전히 취약점이 될 수 있습니다.
표준 Linux 인스턴스의 문제점
프라이빗 키 관리 서비스가 표준 Linux 인스턴스에서 실행된다면, 운영체제 커널에 좌우됩니다. 루트킷, 하이퍼바이저의 제로데이, 혹은 sudo 권한을 가진 악의적인 관리자는 메모리를 덤프하여 키를 추출할 수 있습니다. 디스크 암호화는 RAM에서 트랜잭션 서명을 위해 키를 복호화해야 한다면 의미가 없습니다.
엔클레이브(Enclave)로의 전환
이 때문에 우리는 Intel SGX나 AWS Nitro Enclaves와 같은 TEE(Trusted Execution Environment)의 사용을 강제하고 있습니다. TEE는 CPU 내부에 “블랙 박스” 역할을 하여 서명 로직과 키 조각을 시스템의 나머지 부분으로부터 격리합니다. 운영체제조차 내부를 들여다볼 수 없으며, 보안 담당자조차 SSH로 접속해 메모리를 읽을 수 없습니다.
구현 세부 사항
격리
서명 서비스는 엔클레이브 내부에서 실행됩니다.
증명(Attestation)
엔클레이브가 키 조각을 받기 전에, 올바르고 변조되지 않은 바이너리를 실행하고 있음을 암호학적으로 증명(원격 증명)해야 합니다.
일시적 실행
키는 MPC를 통해 재구성되고, 트랜잭션에 서명한 뒤 사라집니다—모두 CPU의 암호화된 메모리 공간 내에서 이루어집니다.
우리는 금융 애플리케이션을 소셜 네트워크처럼 구축하는 것을 멈춰야 합니다. 위험 수준이 다릅니다. 보관 솔루션을 구축한다면, 신뢰 앵커를 관리자에서 실리콘으로 옮기세요.
