오늘날 블록체인 기술과 암호화폐에 대해 글을 쓰지 않는 사람은 게으른 사람들뿐입니다. 하지만 이 기사에서는 이 기술을 칭찬하지 않습니다. 이 보고서는 단점과 단점을 제거하는 방법에 초점을 맞출 것입니다.

Altirix Systems에서 프로젝트 중 하나를 진행하는 동안 블록체인을 위한 외부 소스의 데이터를 안전하고 검열 불가능한 방식으로 확인하는 작업이 생겨났습니다. 세 번째 시스템의 기록에서 변경 사항을 확인하고, 이러한 변경 사항을 기반으로 스마트 계약의 논리에서 하나 또는 여러 개의 분기를 실행하는 것이 필요했습니다. 이 작업은 언뜻 보기에 매우 사소한 것처럼 보이지만, 프로세스 당사자 중 한 사람의 재정 상태가 실행 결과에 따라 달라지는 경우 추가적인 요구 사항이 발생합니다. 첫째, 그러한 검증 메커니즘에 대한 포괄적인 신뢰입니다. 하지만 가장 중요한 것은 먼저입니다.

문제는 블록체인 자체가 자율적이고 폐쇄적인 개체이기 때문에 블록체인 내부의 스마트 계약은 외부 세계에 대해 아무것도 모른다는 것입니다. 동시에 스마트 계약의 조건은 종종 실제 상황에 대한 정보(항공편 지연, 환율 등)와 연결됩니다. 스마트 계약이 제대로 작동하려면 블록체인 외부에서 수신한 정보가 신뢰할 수 있고 검증되어야 합니다. 이 문제는 Town Crier와 DECO와 같은 오라클을 사용하면 해결됩니다. 이러한 오라클은 블록체인 네트워크의 스마트 계약을 통해 신뢰할 수 있는 웹 서버의 정보를 신뢰할 수 있도록 하므로 신뢰할 수 있는 정보 제공자라고 할 수 있습니다.

오라클

당신이 좋아하는 축구 클럽이 러시아 컵에서 우승하면 0.001 BTC가 당신의 비트코인 ​​지갑으로 전송되는 스마트 계약을 상상해보세요. 실제로 승리하는 경우, 스마트 계약에는 어느 클럽이 승리했는지에 대한 정보가 필요하며, 여기에는 여러 가지 문제가 발생합니다. 이 정보는 어디에서 얻을 수 있을까요? 어떻게 하면 이 정보를 스마트 계약으로 안전하게 전송할 수 있을까요? 그리고 스마트 계약에서 수신한 정보가 실제로 현실과 일치하는지 어떻게 확인할 수 있을까요?

정보 출처에 대한 질문에는 두 가지 시나리오가 있습니다. 스마트 계약을 경기 결과에 대한 정보가 중앙에 저장된 신뢰할 수 있는 웹사이트에 연결하는 것입니다. 두 번째 옵션은 여러 사이트를 한 번에 연결한 다음 동일한 데이터를 제공하는 대부분의 출처에서 정보를 선택하는 것입니다. 정보의 정확성을 보장하기 위해 TLSNotary(데이터 진위성 증명을 위한 TLS 수정)를 사용하는 Oraclize와 같은 오라클이 사용됩니다. 하지만 구글에서 Oraclize에 대한 정보를 충분히 찾을 수 있고, Habr에 대한 기사도 여러 개 있지만, 오늘은 정보 전달에 약간 다른 접근 방식을 사용하는 오라클인 Town Crier와 DECO에 대해 말씀드리겠습니다. 이 기사에서는 두 오라클의 작동 원리를 설명하고 자세한 비교를 제공합니다.

타운 크라 이어

타운 크라이어(TC)는 3년 CCS'2016에서 IC16(암호화폐 및 계약 이니셔티브)에 의해 소개되었습니다. TC의 주요 아이디어는 웹사이트에서 스마트 계약으로 정보를 전달하고 TC가 전달하는 정보가 웹사이트에 있는 정보와 동일한지 확인하는 것입니다. TC는 TEE(신뢰할 수 있는 실행 환경)를 사용하여 데이터 소유권의 신뢰성을 보장합니다. TC의 원래 버전에서는 Intel SGX를 사용하여 작업하는 방법을 설명합니다.
Town Crier는 블록체인 내부의 부분과 OS 자체 내부의 부분인 TC 서버로 구성됩니다.

TC 계약은 블록체인에 상주하며 TC의 프런트엔드 역할을 합니다. CU(사용자 스마트 계약)로부터 요청을 수락하고 TC 서버로부터 응답을 반환합니다. TC 서버 내부에는 인클레이브와 인터넷(양방향 트래픽) 간의 연결을 설정하고 인클레이브를 블록체인에 연결하는 릴레이가 있습니다. Enclave에는 블록체인에 요청을 보내고 디지털 서명과 함께 블록체인에 메시지를 반환하는 코드인 progencl이 포함되어 있습니다. progencl은 스마트 계약 코드의 일부를 포함하고 있으며 기본적으로 일부 기능을 수행합니다.

Intel SGX 인클레이브는 ecall을 통해 작동하는 API가 있는 공유 라이브러리로 생각할 수 있습니다. Ecall은 통제권을 해당 지역으로 이전합니다. 인클레이브는 종료되거나 예외가 발생할 때까지 코드를 실행합니다. 인클레이브 외부에서 정의된 함수를 호출하려면 ocall을 사용합니다. Ocall은 인클레이브 외부에서 실행되며 인클레이브에서는 신뢰할 수 없는 호출로 처리됩니다. ocall이 실행된 후 제어권은 인클레이브로 돌아갑니다.

Enclave 부분에서는 웹 서버와의 보안 채널이 구성되고, Enclave 자체가 대상 서버와 TLS 핸드셰이크를 수행하고 모든 암호화 작업을 내부적으로 수행합니다. TLS 라이브러리(mbedTLS)와 최소화된 HTTP 코드가 SGX 환경으로 내보내졌습니다. Enclave에는 원격 서버 인증서를 검증하기 위한 루트 CA 인증서(인증서 모음)도 포함되어 있습니다. 요청 핸들러는 이더리움이 제공하는 형식의 데이터그램 요청을 수락하고, 이를 복호화하고, 구문 분석합니다. 그런 다음 요청된 데이터그램이 포함된 Ethereum 트랜잭션을 생성하고 skTC를 사용하여 서명한 다음 Relay에 제출합니다.

릴레이 부분에는 클라이언트 인터페이스, TCP, 블록체인 인터페이스가 포함됩니다. 클라이언트 인터페이스는 인클레이브 코드를 검증하고 클라이언트와 통신하는 데 필요합니다. 클라이언트는 ecall을 사용하여 증명 요청을 보내고 skTC에서 서명한 타임스탬프와 att(증명 서명)를 수신합니다. 그런 다음 att는 Intel Attestation Service(IAS)를 사용하여 검증되고 타임스탬프는 신뢰할 수 있는 시간 서비스에서 검증됩니다. 블록체인 인터페이스는 들어오는 요청을 검증하고 블록체인에 거래를 등록하여 데이터그램을 전달합니다. Geth는 공식 Ethereum 클라이언트이며 Relay가 RPC 호출을 통해 블록체인과 상호 작용할 수 있도록 해줍니다.

TC는 TEE와 협력하여 여러 개의 인클레이브를 병렬로 실행하여 정보 처리 속도를 3배까지 높일 수 있습니다. 15개의 인클레이브가 실행 중일 때 속도가 초당 20tx라면, 65개의 인클레이브가 병렬로 실행되면 속도는 초당 26tx로 증가합니다. 비교를 위해 말씀드리자면, 비트코인 ​​블록체인의 최대 운영 속도는 초당 XNUMXtx입니다.

데코

DECO(TLS용 분산 오라클)는 CCS'20에서 발표되었으며, TLS 연결을 지원하는 사이트와 호환됩니다. 데이터의 기밀성과 무결성을 보장합니다.
TLS를 사용하는 DECO는 대칭 암호화를 사용하므로 클라이언트와 웹 서버 모두 암호화 키를 갖고 있으며, 클라이언트는 원하는 경우 TLS 세션 데이터를 위조할 수 있습니다. 이 문제를 해결하기 위해 DECO는 증명자(스마트 계약), 검증자(오라클), 웹 서버(데이터 소스) 간의 3방향 핸드셰이크 프로토콜을 사용합니다.

DECO의 원리는 증명자가 데이터 D를 수신하고 검증자에게 D가 TLS 서버 S에서 왔음을 확인하는 것입니다. 또 다른 문제는 TLS가 데이터에 서명하지 않아 TLS 클라이언트가 데이터가 해당 서버에서 왔다는 것을 증명하기 어렵다는 것입니다(출처 어려움).

DECO 프로토콜은 KEnc와 KMac이라는 암호화 키를 사용합니다. 클라이언트는 요청 Q를 보냅니다. 웹 서버서버 R의 응답은 암호화되어 도착하지만, 클라이언트와 서버는 동일한 KMac을 공유하므로 클라이언트가 TLS 메시지를 위조할 수 있습니다. DECO의 해결책은 클라이언트(증명자)가 요청에 응답할 때까지 KMac을 "숨기는" 것입니다. 이제 KMac은 증명자와 검증자(KpMac과 KvMac)로 분할됩니다. 서버는 키 분할 연산 KpMac ⊕ KvMac = KMac을 사용하여 응답을 암호화하기 위한 KMac을 얻습니다.

3방향 핸드셰이크를 설정함으로써 클라이언트와 서버 간의 데이터 교환은 보안이 보장된 상태에서 수행됩니다.

분산형 오라클 시스템에 대해 이야기할 때, Ethereum, Bitcoin, Hyperledger와 호환되는 오라클 노드의 분산형 네트워크를 구축하는 것을 목표로 하는 Chainlink를 언급하지 않을 수 없습니다. 이 시스템은 모듈성을 염두에 두고 있으며, 시스템의 각 부분을 업그레이드할 수 있습니다. 보안을 강화하기 위해 Chainlink는 작업에 참여하는 각 오라클에게 키(공개 키와 개인 키)의 조합을 제공하도록 요구합니다. 개인 키는 데이터 요청에 대한 답변을 담은 부분 서명을 생성하는 데 사용됩니다. 답변을 얻으려면 네트워크 오라클의 모든 부분 서명을 결합해야 합니다.

Chainlink는 Mixicles와 같은 분산형 금융 애플리케이션에 초점을 맞춰 DECO의 초기 PoC를 수행할 계획입니다. 이 글을 쓸 당시 Forbes에서는 Chainlink가 Cornell University로부터 DECO를 인수했다는 소식이 나왔습니다.

오라클에 대한 공격

정보 보안 관점에서 Town Crier에 대한 공격은 다음과 같습니다.

1. TEE 노드에 대한 사기성 스마트 컨택트 코드 주입.
   공격의 본질은 의도적으로 잘못된 스마트 계약 코드를 TEE로 전송하여, 노드에 접근한 공격자가 복호화된 데이터에 대해 자신의 (사기성) 스마트 계약을 실행할 수 있도록 하는 것입니다. 하지만 반환된 값은 개인키로 암호화되어 저장되며, 이러한 데이터에 접근할 수 있는 유일한 방법은 반환/출력 시 암호문을 유출하는 것입니다.
   이 공격에 대한 보호는 해당 지역이 현재 주소에 있는 코드의 정확성을 확인하는 것으로 구성됩니다. 이는 계약 코드를 해시하여 계약 주소를 결정하는 주소 지정 체계를 사용하여 달성할 수 있습니다.

2. 계약 상태 암호문 변경 사항이 누출됩니다.
   공격의 본질: 스마트 계약이 실행되는 노드의 소유자는 인클레이브 외부에서 암호화된 형태의 계약 상태에 접근할 수 있습니다. 노드의 제어권을 얻은 공격자는 거래가 실행되기 전과 후의 접촉 상태를 비교하여 어떤 인수가 입력되었고 어떤 스마트 계약 방법이 사용되었는지 확인할 수 있습니다. 스마트 계약 코드 자체와 기술 사양이 공개적으로 제공되기 때문입니다.
   장치 자체의 신뢰성을 보장하는 보호.

3. 사이드 채널 공격.
   다양한 시나리오에서 인클레이브 메모리와 캐시에 대한 액세스를 모니터링하는 특수한 유형의 공격입니다. 이러한 공격의 예로 Prime and Probe가 있습니다.
   
   공격 순서:

   • t0: 공격자는 피해자 프로세스의 전체 데이터 캐시를 채웁니다.
   • t1: 피해자는 피해자의 민감한 데이터(암호화 키)에 따라 메모리 액세스를 통해 코드를 실행합니다. 캐시 라인은 키비트 값을 기준으로 선택됩니다. 그림의 예에서 키비트 = 0이고 캐시 라인 2의 주소 X가 읽힙니다. X에 저장된 데이터는 캐시에 로드되면서 이전에 있던 데이터를 대체합니다.
   • t2: 공격자는 자신의 캐시 라인 중 어떤 라인이 제거되었는지 확인합니다. 즉, 피해자가 사용한 라인입니다. 이는 접근 시간을 측정하여 수행됩니다. 공격자는 각 키비트에 대해 이 작업을 반복함으로써 전체 키를 얻습니다.

공격 보호: Intel SGX는 캐시 관련 이벤트 모니터링을 방해하는 사이드 채널 공격에 대한 보호 기능을 갖추고 있지만, 공격자가 자신의 프로세스의 캐시 이벤트를 모니터링하고 피해자와 캐시를 공유하기 때문에 Prime 및 Probe 공격은 여전히 ​​성공할 것입니다.

따라서 현재로선 이 공격을 막을 수 있는 신뢰할 만한 보호책이 없습니다.

Prime과 Probe와 유사한 Spectre와 Foreshadow(L1TF) 공격도 알려져 있습니다. 이를 통해 제2자 채널을 통해 캐시 메모리에서 데이터를 읽을 수 있습니다. 이 두 가지 공격 모두에 대응하는 Spectre-vXNUMX 취약점에 대한 보호 기능이 있습니다.

DECO와 관련하여 3자 핸드셰이크는 보안을 보장합니다.

1. 증명자 무결성: 손상된 증명자는 서버의 출처에 대한 정보를 위조할 수 없으며 서버가 잘못된 요청을 수락하거나 유효한 요청에 잘못 응답하도록 할 수 없습니다. 이는 서버와 증명자 간의 요청 템플릿을 통해 가능합니다.
2. 검증자 무결성: 해킹된 검증자는 증명자가 잘못된 답변을 얻도록 할 수 없습니다.
3. 개인정보 보호: 해킹된 검증자는 공개적으로 사용 가능한 정보(쿼리, 서버 이름)만 검토합니다.

DECO에서는 트래픽 주입 취약점만 발생할 수 있습니다. 초기 3방향 핸드셰이크 과정에서 검증자는 새로운 nonce를 사용하여 서버의 신원을 확인할 수 있습니다. 그러나 핸드셰이크 이후에는 검증자는 네트워크 계층 지표에 의존해야 합니다.IP 주소그러므로 검증자와 서버 간의 연결은 트래픽 주입으로부터 보호되어야 합니다. 이는 프록시를 사용하여 구현됩니다.

오라클 비교

Town Crier는 서버 부분에서 인클레이브를 사용하는 방식을 기반으로 하는 반면, DECO는 3방향 핸드셰이크와 암호화 키를 사용한 데이터 암호화를 통해 데이터 출처의 진위성을 검증할 수 있습니다. 이러한 오라클의 비교는 속도, 보안, 비용 및 실용성이라는 기준에 따라 수행되었습니다.

타운 크라 이어
데코

성능
더 빠름(완료까지 0.6초)
더 느림(프로토콜 완료까지 10.50초)

보안
보안성이 낮음
더 안전하다

비용
더 비싸다.
싼

실용적인 사항
특수 하드웨어가 필요합니다
TLS를 지원하는 모든 서버와 작동합니다.

속도 성능: DECO는 0.37방향 핸드셰이크 설정이 필요하며, LAN을 통해 설정하는 경우 2초가 소요되고, 0,13PC-HMAC은 연결 후 통신에 효과적입니다(쓰기당 3초). DECO의 성능은 사용 가능한 TLS 암호 그룹, 개인 데이터의 크기, 특정 애플리케이션에 대한 증명의 복잡성에 따라 달라집니다. IC10,50의 바이너리 옵션 애플리케이션 예를 사용하면 LAN을 통해 프로토콜을 완료하는 데 약 0,6초가 걸립니다. 비교해 보면 Town Crier는 비슷한 애플리케이션을 실행하는 데 약 20초가 걸리는데, 이는 DECO보다 약 XNUMX배 빠릅니다. 모든 조건이 동일하다면 TC가 더 빠를 것입니다.

Безопасность: Intel SGX 인클레이브 사이드 채널 공격은 효과적이며 스마트 계약 참여자에게 실제 피해를 입힐 수 있습니다. DECO를 사용하면 트래픽 주입 공격이 가능하지만 프록시를 사용하면 이러한 공격을 무력화할 수 있습니다. 그러므로 DECO는 더 안전합니다.

비용: Intel SGX를 지원하는 하드웨어 비용은 DECO에서 프로토콜을 설정하는 비용보다 높습니다. 그래서 TC가 더 비싼 거예요.

실용성: 타운 크라이어를 사용하려면 TEE를 지원하는 특수 장비가 필요합니다. 예를 들어, Intel SGX는 6세대 Intel Core 프로세서 제품군 이상에서 지원됩니다. DECO를 사용하면 어떤 장비로든 작업할 수 있지만 TEE를 사용하는 DECO 설정도 있습니다. 설정 과정 측면에서 DECO의 XNUMX방향 핸드셰이크는 시간이 다소 걸릴 수 있지만 TC의 하드웨어 제한에 비하면 아무것도 아니므로 DECO가 더 실용적입니다.

결론

두 오라클을 따로 살펴보고 네 가지 기준에 따라 비교하면, 타운 크라이어가 네 가지 점 중 세 가지에서 DECO보다 떨어진다는 것이 분명합니다. DECO는 정보 보안 측면에서 더 안정적이고 저렴하며 실용적이지만, 2020자 프로토콜을 설정하는 데 시간이 걸릴 수 있으며 암호화 키를 사용해야 하는 추가 작업과 같은 단점이 있습니다. TC는 DECO보다 빠르지만 사이드 채널 공격과 관련된 취약점으로 인해 개인 정보가 유출될 위험이 있습니다. DECO가 4년 XNUMX월에 도입되었다는 점과, 아직 안전하다고 간주하기에는 충분한 시간이 지나지 않았다는 점을 고려해야 합니다. 타운 크라이어는 XNUMX년간 공격을 받아왔고 많은 테스트를 거쳤기 때문에 많은 프로젝트에서 사용하는 것이 타당합니다.

출처 : habr.com