오늘날 게으른 사람들만이 블록체인 기술, 암호화폐 및 그것이 얼마나 멋진지에 대해 글을 쓰지 않았습니다. 하지만 이 기사에서는 이 기술을 칭찬하는 것이 아니라 단점과 이를 제거하는 방법에 대해 이야기하겠습니다.

Altirix Systems에서 프로젝트 중 하나를 진행하는 동안 블록체인 외부 소스의 데이터를 검열에 저항하는 안전한 확인 작업이 발생했습니다. 세 번째 시스템 기록의 변경 사항을 확인하고 이러한 변경 사항을 기반으로 스마트 계약 논리에서 하나 또는 다른 분기를 실행해야 했습니다. 언뜻보기에 작업은 매우 사소하지만 프로세스에 참여하는 당사자 중 하나의 재정 상태가 구현 결과에 따라 달라지는 경우 추가 요구 사항이 나타납니다. 우선, 이는 이러한 검증 메커니즘에 대한 포괄적인 신뢰입니다. 하지만 가장 먼저 해야 할 일이 있습니다.

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

오라클

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

정보 소스에 관해서는 2가지 시나리오가 있을 수 있습니다. 일치 결과에 대한 정보가 중앙에 저장되는 신뢰할 수 있는 웹사이트에 스마트 계약을 연결하고, 두 번째 옵션은 여러 사이트를 동시에 연결한 다음 대부분의 소스에서 정보를 선택하는 것입니다. 동일한 데이터를 제공하는 것입니다. 정보의 정확성을 확인하기 위해 오라클이 사용됩니다. 예를 들어 TLSNotary(데이터 진위를 증명하기 위한 TLS Notary Modification)를 사용하는 Oraclize가 사용됩니다. 하지만 Google에는 Oraclize에 대한 충분한 정보가 있으며 Habré에 대한 여러 기사가 있습니다 오늘은 정보 전송에 약간 다른 접근 방식을 사용하는 oracle인 Town Crier와 DECO에 대해 이야기하겠습니다. 이 기사에서는 두 오라클의 작동 원리에 대한 설명과 자세한 비교를 제공합니다.

타운 크라 이어

TC(Town Crier)는 3년 CCS'2016에서 IC16(암호화폐 및 계약 이니셔티브)에 의해 소개되었습니다. TC의 주요 아이디어는 웹사이트의 정보를 스마트 계약으로 전송하고 TC가 전달하는 정보가 웹사이트의 정보와 동일한지 확인하는 것입니다. TC는 TEE(Trusted Execution Environment)를 사용하여 데이터 소유권을 인증합니다. 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 부분에서는 웹 서버로 보안 채널이 구성되며, Enclave 자체는 대상 서버와 TLS 핸드셰이크를 수행하고 모든 암호화 작업을 내부적으로 수행합니다. TLS 라이브러리(mbedTLS) 및 축소된 HTTP 코드가 SGX 환경으로 내보내졌습니다. 또한 Enclave에는 원격 서버의 인증서를 확인하기 위한 루트 CA 인증서(인증서 모음)가 포함되어 있습니다. 요청 핸들러는 Ethereum에서 제공하는 형식의 데이터그램 요청을 수락하고 이를 해독하고 구문 분석합니다. 그런 다음 요청된 데이터그램이 포함된 이더리움 트랜잭션을 생성하고 이를 skTC로 서명한 후 Relay로 전송합니다.

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

TEE를 사용하면 TC를 통해 여러 엔클레이브를 병렬로 실행할 수 있으므로 정보 처리 속도가 3배 향상됩니다. 하나의 실행 중인 엔클레이브의 속도가 15tx/초라면 20개의 병렬 실행 엔클레이브의 속도는 65tx/초로 증가합니다. 비교를 위해 비트코인 ​​블록체인의 최대 작동 속도는 26tx/초입니다.

데코

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

DECO의 작동 방식은 검증자가 데이터 D 조각을 수신하고 D가 TLS 서버 S에서 왔음을 검증자에게 확인하는 것입니다. 또 다른 문제는 TLS가 데이터에 서명하지 않으며 TLS 클라이언트가 데이터임을 증명하기 어렵다는 것입니다. 데이터가 정확히 올바른 서버로부터 수신되었습니다(출처 어려움).

DECO 프로토콜은 KEnc 및 KMac 암호화 키를 사용합니다. 클라이언트는 웹 서버에 요청 Q를 보내고 서버 R의 응답은 암호화된 형식으로 제공되지만 클라이언트와 서버는 동일한 KMac을 소유하므로 클라이언트가 TLS 메시지를 위조할 수 있습니다. DECO의 솔루션은 요청에 응답할 때까지 클라이언트(증명자)로부터 KMac을 "숨기는" 것입니다. 이제 KMac은 증명자와 검증자(KpMac 및 KvMac)로 구분됩니다. 서버는 KpMac ⊕ KvMac = KMac 키 부분 작업을 사용하여 응답을 암호화하기 위해 KMac을 수신합니다.

XNUMX방향 핸드셰이크를 설정하면 클라이언트와 서버 간의 데이터 교환이 보안이 보장되면서 수행됩니다.

탈중앙화 오라클 시스템에 관해 이야기할 때, 모듈성을 고려하여 이더리움, 비트코인 ​​및 하이퍼레저와 호환되는 탈중앙화 오라클 노드 네트워크를 만드는 것을 목표로 하는 Chainlink를 언급하지 않을 수 없습니다. 시스템의 모든 부분을 업데이트할 수 있습니다. 동시에 보안을 보장하기 위해 Chainlink는 작업에 참여하는 각 오라클에게 키 조합(퍼블릭 및 프라이빗)을 발행하도록 제안합니다. 개인 키는 데이터 요청에 대한 결정이 포함된 부분 서명을 생성하는 데 사용됩니다. 답변을 얻으려면 네트워크 오라클의 모든 부분 서명을 결합해야 합니다.

체인링크는 Mixicles와 같은 탈중앙화 금융 애플리케이션에 중점을 두고 초기 PoC DECO를 수행할 계획입니다. 이 글을 쓰는 시점에 Chainlink가 Cornell University에서 DECO를 인수했다는 소식이 Forbes에 나왔습니다.

오라클에 대한 공격

정보 보안 관점에서 Town Crier에 대한 다음 공격이 고려되었습니다.

1. TEE 노드에 악성 스마트 접촉 코드 삽입.
   공격의 본질: 의도적으로 잘못된 스마트 계약 코드를 TEE에 전송합니다. 따라서 노드에 대한 액세스 권한을 얻은 공격자는 해독된 데이터에 대해 자신의 (사기성) 스마트 계약을 실행할 수 있습니다. 그러나 반환 값은 개인 키로 암호화되며 이러한 데이터에 액세스할 수 있는 유일한 방법은 반환/출력 시 암호문을 유출하는 것입니다.
   이 공격에 대한 보호는 현재 주소에 있는 코드의 정확성을 확인하는 엔클레이브로 구성됩니다. 이는 계약 코드를 해싱하여 계약 주소를 결정하는 주소 지정 체계를 사용하여 달성할 수 있습니다.

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

3. 부채널 공격.
   다양한 시나리오에서 엔클레이브 메모리 및 캐시 액세스 모니터링을 사용하는 특수한 유형의 공격입니다. 이러한 공격의 예로는 Prime과 Probe가 있습니다.
   
   공격 순서:

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

공격 보호: Intel SGX는 캐시 관련 이벤트 모니터링을 방지하는 부채널 공격으로부터 보호하지만 공격자가 프로세스의 캐시 이벤트를 모니터링하고 피해자와 캐시를 공유하기 때문에 프라임 및 프로브 공격은 여전히 ​​작동합니다.

따라서 현재로서는 이 공격에 대한 확실한 보호 장치가 없습니다.

Prime, Probe와 유사한 L1TF(Spectre and Foreshadow)와 같은 공격도 알려져 있습니다. 이를 통해 타사 채널을 통해 캐시 메모리에서 데이터를 읽을 수 있습니다. 이러한 공격 중 두 가지에 대해 작동하는 Spectre-v2 취약점에 대한 보호 기능이 제공됩니다.

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

1. 증명자 무결성: 해킹된 증명자는 서버 원본 정보를 위조할 수 없으며 서버가 유효하지 않은 요청을 수락하거나 유효한 요청에 잘못 응답하도록 할 수 없습니다. 이는 서버와 증명자 간의 요청 패턴을 통해 수행됩니다.
2. 검증자 무결성: 해킹된 검증자는 증명자가 잘못된 답변을 받게 할 수 없습니다.
3. 개인 정보 보호: 해킹된 검증자는 공개 정보(요청, 서버 이름)만 검사합니다.

DECO에서는 트래픽 인젝션 취약점만 가능합니다. 첫째, XNUMX방향 핸드셰이크를 통해 검증자는 새로운 nonce를 사용하여 서버의 ID를 설정할 수 있습니다. 그러나 핸드셰이크 후에 검증자는 네트워크 계층 표시기(IP 주소)에 의존해야 합니다. 따라서 검증자와 서버 간의 통신은 트래픽 주입으로부터 보호되어야 합니다. 이는 프록시를 사용하여 달성됩니다.

오라클의 비교

Town Crier는 서버 부분의 enclave 작업을 기반으로 하며, DECO를 사용하면 XNUMX방향 핸드셰이크 및 암호화 키를 사용한 데이터 암호화를 사용하여 데이터 원본의 진위 여부를 확인할 수 있습니다. 이들 오라클의 비교는 성능, 보안, 비용 및 실용성 기준에 따라 수행되었습니다.

타운 크라 이어
데코

성능
더 빠르게(완료까지 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가 더 실용적입니다.

결론

두 오라클을 별도로 살펴보고 2020가지 기준으로 비교하면 4점 중 XNUMX점에서 Town Crier가 DECO보다 열등하다는 것이 분명합니다. DECO는 정보 보안 관점에서 더 안정적이고 저렴하며 실용적이지만 타사 프로토콜을 설정하는 데 시간이 걸릴 수 있고 암호화 키를 사용한 추가 작업과 같은 단점이 있습니다. TC는 DECO보다 빠르지만 부채널 공격 취약성으로 인해 기밀성이 손실되기 쉽습니다. DECO가 XNUMX년 XNUMX월에 도입된 만큼 아직 안전하다고 판단할 시간이 충분하지 않다는 점을 고려해야 합니다. Town Crier는 XNUMX년 동안 공격을 받아왔고 많은 테스트를 거쳤으므로 많은 프로젝트에서의 사용이 정당합니다.

출처 : habr.com