KR102247233B1

KR102247233B1 - 다중 레이어 기반 스마트 컨트랙트 감사 방법 및 그 장치

Info

Publication number: KR102247233B1
Application number: KR1020190134828A
Authority: KR
Inventors: 문경곤
Original assignee: 주식회사 린아레나
Priority date: 2019-10-28
Filing date: 2019-10-28
Publication date: 2021-05-03

Abstract

바이트 코드로 저장된 스마트 컨트랙트에 대한 감사를 수행하는 제1 스마트 컨트랙트 감사부와, 제1 스마트 컨트랙트 감사부에서 누락될 수 있는 SWC 취약점에 대하여 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일되어 소스코드로 저장된 스마트 컨트랙트에 대한 감사를 수행하는 제2 스마트 컨트랙트 감사부와, 및 제1 스마트 컨트랙트 감사부로부터 수신된 제1 감사 리포트와 제2 스마트 컨트랙트 감사부로부터 수신된 제2 감사 리포트를 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하는 취약점 리포트부를 포함하되, 제1 스마트 컨트랙트 감사부는 바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 바이트 코드를 일괄적으로 읽어들여서 메모리에 평면 배열로 저장하고, 메모리에 평면 배열 저장된 바이트 코드를 읽어들여 스마트 컨트랙트에 대한 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 장치가 제공된다.

Description

다중 레이어 기반 스마트 컨트랙트 감사 방법 및 그 장치{METHOD FOR AUDITING SMART CONTRACT WITH MULTI LAYER AND APPARATUS THEREOF}

본 발명은 다중 레이어 기반 스마트 컨트랙트 감사 방법 및 그 장치에 관한 것으로, 상세하게는 스마트 컨트랙트에서 발생되는 취약점들에 대하여 바이트 코드 레벨에서 감사를 수행하고 소스 코드 레벨에서 보완적으로 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 방법 및 그 장치에 관한 것이다.

블록체인(Block Chain) 기술은 탈중심화에 의한 동등 계층 통신망(peer-to-peer network)으로, 암호화 원리를 콘센서스 메커니즘과 결합함으로써, 분산 원장 기술에 의해 분산된 각 노드의 데이터 연관성과 지속성을 보장하고, 정보의 즉시 검증, 추적 가능성, 조작 어려움 등 특성을 구현하여, 비밀과 고효율적이고, 안전한 일련의 분포식 신뢰체계를 구축하였다.

블록체인은 일반적으로 접근 권한에 의해 퍼블릭 블록체인, 컨소시엄 블록체인 및 프라이빗 블록체인으로 분류된다. 퍼블릭 블록체인이란, 프로토콜을 통해서 누구나 접근 가능하고, 또한 콘센서스에 참가할 수 있는 블록체인이다. 컨소시엄 블록체인이란, 콘센서스 프로세스가 기설정된 노드에 의해 제어되는 블록체인이다. 프라이빗블록체인이란 어느 조직이 그 권한을 소유하고 있고, 해당 조직에 의해 완전히 제어되는 블록체인이다.

스마트 컨트랙트(smart contract)는 복잡한 기능을 구현하기 위해서 블록체인상에서 운행되고 있는 탈중심화된 응용 체계로서, 특정 계약을 스스로 수립, 검증, 이행하기 위한 컴퓨터 프로토콜이다.

스마트 컨트랙트는 분산 원장 기술에서 거래의 일정 조건을 만족시키면 당사자 간에 자동으로 거래가 체결되는 방식의 기술을 의미한다. 스마트 컨트랙트 시스템 하에서는 거래 조건과 내용을 등록하면 그에 해당하는 법률 및 절차 등이 자동으로 적용되어 거래 당사자에게 결과가 전달되게 된다.

스마트 컨트랙트에 의하면, 거래 절차가 간소화되고 거래상 발생되는 비용도 절감되는 이점을 가지고 있다.

이더리움(Ethereum)은 스마트 컨트랙트 기반 블록체인 플랫폼이다. 이더리움에서 스마트 컨트랙트는 이더리움의 상태를 변경할수 있는 프로그램 코드로서 블록에 포함되어 각 노드에 전파되고, EVM에서 작동되어 상태전이를 발생시킨다. 즉 스마트 컨트랙트는 블록헤더의 데이타뿐만 아니라 특정 값이나 발신자 및 수신되는 메시지의 데이타를 조작하는 등 이더리움의 상태변화와 데이타 저장등이 가능한 프로그램 코드이다.

여기에서는 스마트 컨트랙트 기반 블록체인 플랫폼을 간단하게 스마트 컨트랙트 시스템이라 칭하기로 한다.

스마트 컨트랙트는 고급 언어로 작성되며, 대응되는 컴파일러에 의해 컴파일된 후, 블록체인에 의해 식별되어 실행 가능한 코드를 생성하고, 블록 체인에 디플로이되어, 대응되는 기능을 제공한다.

스마트 컨트랙트 개발, 또는 배포 시 소스 코드 내 발생 될 수 있는 취약점에 대해 빠르고 정확하게 파악하여 수정 보완이 필수적이다. 스마트 컨트랙트의 행위 분석을 통한 취약점 분석의 경우, 테스트 케이스에 대해 모두 검증을 거쳐야 하며 테스트 케이스 또한 개발자가 개발을 해야 하기 때문에 검증에 시간이 걸리며 정확도에도 개발자에 의존적이다.

스마트 컨트랙트는 가상 머신에 의해 바이트코드(Bytecode) 또는 중간 코드로 컴파일되고 실행되기 때문에 대부분의 취약성은 언어 독립적일 수 있다.

그러나, 언어는 같은 기능(액세스 관리 등)을 달성하기 위해 다른 코드 구조를 도입하며 경우에 따라 이행하기가 더 어려울 수 있다.

한편, 스마트 컨트랙트를 배포할 때 소스 코드 없이 바이트 코드로 배포하는 경우도 있다. 이러한 경우에 스마트 컨트랙트의 취약점을 파악하고 분석하는데는 한계가 있다.

또한, 스마트 컨트랙트의 소스 코드 분석을 통해 취약점을 파악하여 정상으로 판단된 경우에도, 실제 실행에서는 기대하는 결과에 이르지 못하는 경우가 있다. 예를 들어, 해커는 소스 코드 레벨에서 우회를 통해 소스 코드 분석을 통한 취약점 감사를 통과할 수 있다.

본 발명이 해결하고자 하는 과제는 스마트 컨트랙트에서 발생되는 취약점들에 대하여 바이트 코드 레벨에서 감사를 수행하고 소스 코드 레벨에서 보완적으로 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 방법 및 그 장치를 제공하는데 있다.

본 발명의 일측면에 의하면, 바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장된 바이트 코드를 상기 메모리로부터 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 제1 감사 리포트를 생성함에 의해, 바이트 코드 레벨에서 바이트 코드에 대한 감사처리를 수행하는 제1 레이어를 구성하는 제1 스마트 컨트랙트 감사부와, 제1 스마트 컨트랙트 감사부에서 누락될 수 있는 SWC 취약점에 대하여 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일되어 소스코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행하되, 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 소스 코드 스마트 컨트랙트의 취약점에 대한 제2 감사 리포트를 생성함에 의해, 소스 코드 레벨에서 소스 코드에 대한 감사처리를 수행하는 제2 레이어를 구성하는 제2 스마트 컨트랙트 감사부와, 제1 스마트 컨트랙트 감사부로부터 수신된 제1 감사 리포트와 제2 스마트 컨트랙트 감사부로부터 수신된 제2 감사 리포트를 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하는 취약점 리포트부를 포함하는 다중 레이어 기반 스마트 컨트랙트 감사 장치가 제공된다.

제2 스마트 컨트랙트 감사부는 SWC 분류중에 변수에 관련된 SWC 분류만을 선별하여 소스 코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행할 수 있다.

제2 스마트 컨트랙트 감사부는 SSA(static single assignment) 기법을 이용하여 소스 코드를 읽어들여 감사를 수행할 수 있다.

본 발명의 다른 측면에 의하면, 스마트 컨트랙트 감사 장치가 분석할 스마트 컨트랙트를 수신하는 단계; 제1 스마트 컨트랙트 감사부가 바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장하는 단계; 제1 스마트 컨트랙트 감사부가 메모리로부터 바이트 코드를 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 제1 감사 리포트를 생성함에 의해, 바이트 코드 레벨에서 바이트 코드에 대한 감사처리를 수행하는 제1 레이어를 구성하는 단계; 제2 스마트 컨트랙트 감사부가 제1 감사 리포트를 생성하는 단계에서 누락될 수 있는 SWC 취약점에 대하여 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일되어 소스코드로 저장된 스마트 컨트랙트에 대한 감사를 수행하되, 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부를 감사하여 소스 코드 스마트 컨트랙트의 취약점에 대한 제2 감사 리포트를 생성함에 의해, 소스 코드 레벨에서 소스 코드에 대한 감사처리를 수행하는 제2 레이어를 구성하는 단계; 및 취약점 리포트부가 제1 감사 리포트와 제2 감사 리포트를 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하는 단계를 포함하는 다중 레이어 기반 스마트 컨트랙트 감사 방법이 제공된다.

제2 감사 리포트를 생성하는 단계는 SWC 분류중에 변수에 관련된 SWC 분류만을 선별하여 소스 코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행할 수 있다.

제2 감사 리포트를 생성하는 단계는 SSA(static single assignment) 기법을 이용하여 소스 코드를 읽어들여 감사를 수행할 수 있다.

본 발명에 의하면, 스마트 컨트랙트를 배포할 때 소스 코드 없이 바이트 코드로 배포하는 경우에 바이트 코드를 분석하여 스마트 컨트랙트의 취약점을 파악하고 리포트를 할 수 있다.

또한, 해커가 스마트 컨트랙트의 소스 코드 레벨에서 우회를 통해 소스 코드 분석을 통한 취약성 감사를 통과하더라도 바이트 코드 레벨에서 스마트 컨트랙트의 취약점을 파악하고 분석하기 때문에 해커의 우회 공격을 효과적으로 차단할 수 있다.

스마트 컨트랙트에서 발생되는 취약점들에 대하여 바이트 코드 레벨에서 감사를 수행하고 소스 코드 레벨에서 보완적으로 감사를 수행함으로써, 스마트 컨트랙트에 대하여 보다 완전한 취약점 감사가 이루어질 수 있다.

본 발명에 의하면, 분석을 원하는 스마트 컨트랙트의 바이트 코드와 소스 코드를 입력받아 해당 스마트 컨트랙트에 대해 위험 유무를 판단하고 스마트 컨트랙트의 취약한 부분이 보완된 코드를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포함으로써 스마트 컨트랙트 개발, 또는 배포시 소스 코드 내 발생될 수 있는 취약점에 대해 빠르고 정확하게 파악하여 수정 보완할 수 있다.

도 1은 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 장치를 설명하기 위한 도면이다.
도 2는 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 방법을 설명하기 위한 도면이다.

본 발명은 다양한 변경을 가할 수 있고 여러가지 실시예를 가질 수 있는바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일실시예를 상세히 설명한다.

도 1은 본 발명의 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 장치를 설명하기 위한 도면이다.

도 1을 참조하면, 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 장치(100)는 분석하고자 하는 스마트 컨트랙트(200)를 읽어들여 취약점이 있는지 여부를 감사할 수 있다.

스마트 컨트랙트(200)는 바이트 코드(210) 형태로 저장되어 있거나, 소스 코드(220) 형태로 저장될 수 있다. 스마트 컨트랙트 감사 장치(100)는 하드웨어적으로 구현될 수 도 있고, 소프트웨어적으로 스마트 컨트랙트 감사 엔진 형태로 구현될 수 있다.

이를 위해, 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 장치(100)는 제1 스마트 컨트랙트 감사부(110)와, 제2 스마트 컨트랙트 감사부(120)와, 취약점 리포트부(130)를 포함하여 구성될 수 있다.

제1 스마트 컨트랙트 감사부(110)는 바이트 코드(210)로 저장된 스마트 컨트랙트에 대한 감사를 수행하도록 구현된다.

제2 스마트 컨트랙트 감사부(120)는 소스 코드(220)로 저장된 스마트 컨트랙트에 대한 감사를 수행하도록 구현된다.

취약점 리포트부(130)는 제1 스마트 컨트랙트 감사부(110)로부터 제1 감사 리포트를 수신하고, 제2 스마트 컨트랙트 감사부(120)로부터 제2 감사 리포트를 수신하고 취합하여 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공한다.

제1 스마트 컨트랙트 감사부(110)가 메모리 레벨에서 바이트 코드(210)에 대한 감사처리를 수행하는 제1 레이어를 구성하고, 제2 스마트 컨트랙트 감사부(120)가 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일된 소스 코드(220)에 대한 감사처리를 수행하는 제2 레이어를 구성하여 스마트 컨트랙트에 대한 감사를 수행할 수 있다.

제1 스마트 컨트랙트 감사부(110)는 바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 바이트 코드를 일괄적으로 읽어들여서 메모리에 평면 배열로 저장하고, 메모리에 평면 배열 저장된 바이트 코드를 읽어들여 스마트 컨트랙트에 대한 감사를 수행할 수 있다. 제1 스마트 컨트랙트 감사부(110)는 스마트 컨트랙트에 대한 감사를 수행하고 제1 감사 리포트를 생성한다.

여기에서 제1 스마트 컨트랙트 감사부(110)의 동작이 주력적이고, 제2 스마트 컨트랙트 감사부(120)의 감사 동작은 제1 스마트 컨트랙트 감사부(110)의 동작만으로는 부족한 부분에 대하여 보완적 의미를 가질 수 있다.

예를 들어, 제2 스마트 컨트랙트 감사부(120)가 살펴보는 소스 코드는 스크립트가 있는 프로그래밍 랭귀지 레벨에 속한다. 따라서, 소스 코드에서는 ' A는 B이다.'라는 식으로 변수를 취급할 수 있다. 즉, 제2 스마트 컨트랙트 감사부(120)는 변수가 연관되는 취약점에 대하여 감사할 수 있다.

그러나, 제1 스마트 컨트랙트 감사부(110)가 살펴보는 바이트 코드(210)는 스크립트가 있는 프로그래밍 랭귀지 레벨이 아니다. 따라서, 바이트 코드 레벨에서는 변수를 취급할 수 없다. 즉, 제1 스마트 컨트랙트 감사부(110)는 변수가 연관되는 취약점에 대하여는 감사하지 못한다.

한편, SWC의 오버플로같은 취약점들에 대하여는 바이트 코드 레벨에서도 얼마든지 감사가 가능하기 때문에 바이트 코드 레벨에서 감사할 수 있는 사항들에 대하여는 제1 스마트 컨트랙트 감사부(110)에 의해 감사를 수행한다.

제2 스마트 컨트랙트 감사부(120)는 소스 코드(220)가 저장된 메모리로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장할 수 있다.

제2 스마트 컨트랙트 감사부(120)는 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부를 감사한다. 제2 스마트 컨트랙트 감사부(120)는 스마트 컨트랙트에 대한 감사를 수행하고 제1 감사 리포트를 생성한다.

이때, 제2 스마트 컨트랙트 감사부(120)는 제1 스마트 컨트랙트 감사부(110)에서는 할 수 없는 SWC 취약점을 기반으로 메모리로부터 읽어들인 소스 코드에 대하여 감사를 수행한다.

즉, 제2 스마트 컨트랙트 감사부(120)는 제1 스마트 컨트랙트 감사부(110)에서 누락될 수 있는 SWC 취약점에 대하여 소스코드로 저장된 스마트 컨트랙트에 대한 감사를 수행한다.

이와 같이 제2 스마트 컨트랙트 감사부(120)는 바이트 코드 레벨에서 감사가 이루어질 수 없는 사항들에 대하여 프로그래밍 언어 레벨에서 컴파일링된 소스 코드에 대하여 감사를 보완적으로 수행하게 한다.

제2 스마트 컨트랙트 감사부(120)는 소스 코드에 대하여 SWC의 모든 취약점을 일일이 감사하는 것이 아니라, 제1 스마트 컨트랙트 감사부(110)에서는 다룰 수 없는 SWC의 취약점 항목만을 선별하여 감사를 수행함에 따라 소스 코드에 대한 감사가 훨씬 더 간편해진다.

여기에서, SWC(smart contract weakness classification)는 예를 들어, 아래와 같이 분류될 수 있다.

예를 들어, 제2 스마트 컨트랙트 감사부(120)는 아래의 SWC 분류중에 제1 스마트 컨트랙트 감사부(110)에서 다룰 수 없는 변수 등에 관련된 SWC 분류만을 선별하여 소스 코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행할 수 있다.

SWC Function Default Visibility( 기능 기본 가시성)

SWC Integer Overflow and Underflow(정수 오버플로 및 언더 플로)

SWC Outdated Compiler Version(오래된 컴파일러 버전)

SWC Floating Pragma(플로팅 프라그마)

SWC Unchecked Call Return Value(확인되지 않은 통화 반환 값)

SWC Unprotected Ether Withdrawal(보호되지 않은 이더 인출)

SWC Unprotected SELFDESTRUCT Instruction(비보호 SELFDESTRUCT 명령)

SWC Reentrancy(재진입)

SWC State Variable Default Visibility(상태 변수 기본 가시성)

SWC Uninitialized Storage Pointer(초기화되지 않은 스토리지 포인터)

SWC Assert Violation(위반 주장)

SWC Use of Deprecated Solidity Functions(더 이상 사용되지 않는 견고성 함수 사용)

SWC Delegatecall to Untrusted Callee(신뢰할 수없는 수신자에게 위임 전화)

SWC DoS with Failed Call(통화가 실패한 DoS)

SWC Transaction Order Dependence(거래 주문 의존)

SWC Authorization through tx.origin(tx.origin을 통한 인증)

SWC Timestamp Dependence(타임 스탬프 종속성)

SWC Signature Malleability(시그니처 가변성)

SWC Incorrect Constructor Name(잘못된 생성자 이름)

SWC Shadowing State Variables(섀도잉 상태 변수)

SWC Weak Sources of Randomness from Chain Attributes(체인 속성에서 약한 무작위 소스)

SWC Missing Protection against Signature Replay Attacks(서명 재생 공격에 대한 보호 기능 결여)

SWC Lack of Proper Signature Verification(적절한 서명 확인 부족)

SWC Requirement Violation(요구 사항 위반)

SWC Write to Arbitrary Storage Location(임의 저장 위치에 쓰기)

SWC Incorrect Inheritance Order(잘못된 상속 순서)

SWC Arbitrary Jump with Function Type Variable(함수 유형 변수가있는 임의 점프)

SWC DoS With Block Gas Limit(블록 가스 제한이 있는 DoS)

SWC Typographical Error(인쇄상의 오류)

SWC Right-To-Left-Override control character (U+202E)(오른쪽에서 왼쪽으로 재정의 제어 문자 (U + 202E))

SWC Presence of unused variables(사용하지 않는 변수의 존재)

SWC Unexpected Ether balance(예상치 못한 이더 밸런스)

SWC Function Default Visibility( 기능 기본 가시성)

기능 기본 가시성 취약점은 코딩 표준에 대한 부적절한 준수에 관련된 것이다. 기능 가시성 유형이 지정되지 않은 기능은 기본적으로 'public'이다. 이는 개발자가 가시성을 설정하는 것을 잊고 악의적 사용자가 무단 또는 의도하지 않은 상태 변경을 수행할 수 있는 경우 취약점으로 이어질 수 있다.

예를 들어, function abc() { }처럼 함수에 대한 external, public, internal, private 지정 없을시에 해당될 수 있다.

취약점에 대한 보완책으로 기능들은 external, public, internal 또는 private으로 지정될 수 있다. 기능에 적합한 가시성 유형을 신중하게 결정하는 것이 좋다. 이는 계약 시스템의 공격 영역을 크게 줄일 수 있다.

SWC Integer Overflow and Underflow(정수 오버플로 및 언더 플로)

정수 오버플로 및 언더 플로 취약점은 잘못된 계산에 관련된 것이다. 산술 연산이 유형의 최대 또는 최소 크기에 도달하면 오버플로 / 언더 플로가 발생한다. 예를 들어 숫자가 uint8 유형에 저장된 경우 숫자는 0에서 2 ^ 8-1 범위의 8 비트 부호없는 숫자에 저장된다. 컴퓨터 프로그래밍에서, 산술 연산이 주어진 비트 수로 표현 될 수 있는 범위를 벗어난 숫자 값 (최대 값보다 크거나 최소 표현 가능 값보다 낮은 숫자)을 만들려고 할 때 정수 오버 플로우가 발생할 수 있다.

사칙 연산시 safemath 라이브러리 미사용하거나 오버플로우, 언더플로우에 대한 체크가 없을시 취약함을 나타낼 수 있다.

예를 들어 아래의 코드가 해당될 수 있다.

function buy(uint256 numTokens) public payable {

require(msg.value == numTokens * PRICE_PER_TOKEN);

function underflowtostate(uint256 input) public {

count -= input;

}

취약점에 대한 보완책으로 스마트 컨트랙트 시스템 전체에서 일관된 산술 연산을 위해 검증된 안전한 수학 라이브러리를 사용하는 것이 좋다.

SWC Outdated Compiler Version(오래된 컴파일러 버전)

오래된 컴파일러 버전 취약점은 알려진 취약점이 있는 구성 요소 사용에 관련된 것이다. 오래된 컴파일러 버전을 사용하면 특히 현재 컴파일러 버전에 영향을 미치는 공개 된 버그 및 문제가 있는 경우 문제가 될 수 있다. 취약점에 대한 보완책으로 최신 버전의 Solidity 컴파일러를 사용하는 것이 좋다. 예를 들어, pragma solidity 0.4.13; 이상 버전을 사용해야 안전할 수 있다.

SWC Floating Pragma(플로팅 프라그마)

플로팅 프라그마 취약점은 수명을 통한 자원의 부적절한 제어에 관련된 것이다. 계약은 철저히 테스트한 것과 동일한 컴파일러 버전 및 플래그로 배포해야 한다. 프라그마를 잠그면 계약 시스템에 부정적인 영향을 미치는 버그가 발생할 수 있는 오래된 컴파일러 버전을 사용하여 계약이 실수로 배포되지 않도록하는 데 도움이 될 수 있다. 취약점에 대한 보완책으로 프라그마 버전을 잠그고 선택한 컴파일러 버전에 대해 알려진 버그 ( https://github.com/ethereum/solidity/releases ) 도 고려할 수 있다.

라이브러리 또는 EthPM 패키지 계약의 경우와 같이 다른 개발자가 계약을 소비하도록 의도된 경우 프라그마문(Pragma statements)을 플로팅 할 수 있다. 그렇지 않으면 개발자는 로컬로 컴파일하기 위해 프라그마를 수동으로 업데이트해야 한다.

SWC Unchecked Call Return Value(확인되지 않은 통화 반환 값)

확인되지 않은 통화 반환값 취약점은 확인되지 않은 반환 값에 관련된 것이다. 메시지 호출의 리턴 값은 점검되지 않는다. 호출 된 계약에서 예외가 발생하더라도 실행이 재개된다. 실수로 호출이 실패하거나 공격자가 강제로 호출을 실패하면 후속 프로그램 논리에서 예기치 않은 동작이 발생할 수 있다. 취약점에 대한 보완책으로 저수준 호출 방법을 사용하기로 선택한 경우 반환 값을 확인하여 호출이 실패 할 가능성을 처리해야 한다.

SWC Unprotected Ether Withdrawal(보호되지 않은 이더 인출)

보호되지 않은 이더 인출 취약점은 부적절한 액세스 제어에 관련된 것이다. 액세스 제어가 없거나 불충분하기 때문에 악의적인 당사자는 계약 계정에서 일부 또는 모든 Ether을 철회할 수 있다. 이 버그는 때때로 실수로 초기화 기능을 노출하여 발생한다. 생성자로 의도된 함수의 이름을 잘못 지정하면 생성자 코드가 런타임 바이트 코드로 끝나고 계약을 다시 초기화하기 위해 누구나 호출 할 수 있다.

아래의 다양한 취약점과 연관된 취약점으로 아래 취약점들을 1차적으로 찾은 다음에 이더 인출과 연관되었는지 확인후 해당 취약점으로 분류할 수 있다.

1. integer overflow로 이더 탈취

2. anobody can withdraw

3. 소유주 주소 변경후 모두 인출

취약점에 대한 보완책으로 인출은 승인된 당사자에 의해서만 또는 스마트 컨트랙트 시스템의 사양에 따라 트리거 될 수 있도록 통제를 구현하는 것이 필요하다.

SW C Unprotected SELFDESTRUCT Instruction(비보호 SELFDESTRUCT 명령)

비보호 selfdestruct 취약점은 부적절한 액세스 제어에 관련된 것이다. 액세스 제어가 없거나 불충분하여 악의적인 당사자가 계약을 자체적으로 파기할 수 있다.

아래처럼 권한 체크 없을시 취약할 수 있다.

function kill_my_self() public {

selfdestruct(msg.sender);

취약점에 대한 보완책으로 자체 파괴 기능이 반드시 필요한 경우가 아니면 제거하는 것이 좋다. 유효한 사용예가 있는 경우 여러 당사자가 자체 파괴 조치를 승인하도록 다중 서명 체계를 구현하는 것이 좋다.

SWC Reentrancy(재진입)

재진입 취약점은 동작 워크 플로의 부적절한 시행에 관련된 것이다. 외부 계약을 호출 할 때의 주요 위험 중 하나는 제어 흐름을 인수할 수 있다는 것이다. 재진입 공격 (일명 재귀 호출 공격)에서 악의적인 계약은 기능의 첫 번째 호출이 완료되기 전에 호출 계약을 다시 호출한다. 이로 인해 함수의 다른 호출이 바람직하지 않은 방식으로 상호 작용할 수 있다.

call을 이용한 이더 전송시에 함수명이 없을시에는 폴백함수를 호출하게 되며, 가스의 제한이 없어 해커가 만든 컨트랙트와 상호작용하며 재진입이 발생할 수 있다.

취약점에 대한 보완책으로 저수준 통화를 사용하는 경우 통화가 실행되기 전에 모든 내부 상태 변경이 수행되는지 확인하는 것이 좋다.

그 외에 다음과 같은 취약점에 대한 보완책이 있을 수 있다.

1. send 또는 transfer를 사용

- 가스한도로 재진입불가

2. 인출전에 차감을 먼저 선행

- 두번째 재진입시 인출할 금액이 없어짐

3. 잠금 장치

- 아래 코드처럼 락 설정후 다음 함수를 호출하기 때문에 다음 함수가 끝나기전에 재 호출불가

modifier nonReentrant() {

require(!rentrancy_lock);

rentrancy_lock = true;

_;

rentrancy_lock = false;

}

require(msg.sender.call.value(amount)());

credit[msg.sender]-=amount;

SWC State Variable Default Visibility(상태 변수 기본 가시성)

상태 변수 기본 가시성 취약점은 코딩 표준에 대한 부적절한 준수에 관련된 것이다. 가시성에 레이블을 지정하면 변수에 액세스 할 수 있는 사람에 대한 잘못된 가정을 보다 쉽게 잡을 수 있다. 취약점에 대한 보완책으로 변수는 public, internal 또는 private 으로 지정할 수 있다. 모든 상태 변수에 대한 가시성을 명시적으로 정의하는 것이 좋다.

SWC Uninitialized Storage Pointer(초기화되지 않은 스토리지 포인터)

최기화되지 않은 스토리지 포인터 취약점은 초기화되지 않은 포인터의 액세스에 관련된 것이다. 초기화되지 않은 로컬 스토리지 변수는 계약에서 예기치 않은 스토리지 위치를 가리킬 수 있으며 이로 인해 의도적이거나 의도하지 않은 취약점이 발생할 수 있다.

취약점에 대한 보완책으로 많은 상황에서 실제로는 그렇지 않은 것처럼 계약에 스토리지 오브젝트가 필요한지 확인해야 한다. 지역 변수가 충분하면 memory 속성으로 변수의 저장 위치를 명시적으로 표시하는 것이 필요하다. 저장 변수가 필요한 경우, 초기화시 저장 위치 storage가 추가로 초기화된다. 컴파일러 버전 0.5.0 이상에서는 초기화되지 않은 스토리지 포인터와의 계약이 더 이상 컴파일되지 않으므로이 문제가 체계적으로 해결되었다.

SWC Assert Violation(위반 주장)

위반 주장 취약점은 항상 부정확한 제어 흐름 구현에 관련된 것이다. Solidity assert()함수는 불변을 주장하기 위한 것이다. 도달 가능한 assertion은 계약에 잘못된 상태가 될 수 있는 버그가 있는 경우나, 이 assert문장이 예를 들어 입력의 유효성을 검사하는 데 잘못 사용되는 경우에 해당된다.

취약점에 대한 보완책으로, assert() 내에서 체크된 조건이 실제로 변하지 않는지 고려해야 한다. 그렇지 않은 경우, assert()문을 require()문으로 대체하는 것이 좋다. 실제로 예기치 않은 코드 동작으로 인해 예외가 발생한 경우 assertion을 위반할 수 있는 기본 버그를 수정하는 것이 좋다.

SWC Use of Deprecated Solidity Functions(더 이상 사용되지 않는 견고성 함수 사용)

더 이상 사용되지 않는 견고성 함수 사용 취약점은 폐기된 기능 사용에 관련된 것이다. Solidity(견고성)의 여러 기능과 연산자는 더 이상 사용되지 않는다. 그것들을 사용하면 코드 품질이 떨어진다. 새로운 주요 버전의 Solidity(견고성) 컴파일러에서는 더 이상 사용되지 않는 함수와 연산자로 인해 부작용이 발생하고 컴파일 오류가 발생할 수 있다.

취약점에 대한 보완책으로 견고성은 더 이상 사용되지 않는 구성에 대한 대안을 제공한다. 그것들의 대부분은 별명이므로 오래된 구조를 교체해도 현재 동작이 중단되지 않는다. 아래 함수들은 권장하지 않으므로 사용하면 안된다.

block.blockhash(uint),sha3(...),callcode(...),throw,msg.gas,constant,suicide(address)

SWC Delegatecall to Untrusted Callee(신뢰할 수 없는 수신자에게 위임 전화)

신뢰할 수 없는 수신자엑 위임 전화 취약점은 신뢰할 수없는 제어 영역에서 기능 포함에 관련된 것이다. delegatecall라는 메시지 호출의 특별한 변형이 존재 떨어져 대상 주소의 코드가 호출 계약의 컨텍스트에서 실행되고 있다는 사실에서 메시지 호출과 동일 msg.sender하고 msg.value그 값을 변경하지 않아야 한다. 이를 통해 스마트 컨트랙트는 런타임시 다른 주소에서 코드를 동적으로 로드할 수 있다. 보관, 현재 주소 및 잔액은 여전히 통화 계약을 나타낸다. 대상 주소의 코드가 발신자의 저장 값을 변경하고 발신자의 잔액을 완전히 제어 할 수 있기 때문에 신뢰할 수없는 계약에 전화하는 것은 매우 위험하다. 취약점에 대한 보완책으로 주의해서 delegatecall를 사용하고, 신뢰할 수없는 계약을 절대로 호출하지 않아야 한다. 대상 주소가 사용자 입력에서 파생된 경우 신뢰할 수 있는 계약의 화이트리스트와 비교하여 확인할 필요가 있다.

아래 함수의 접근제어자는 public 이며, 누구든 호출할 수 있는 상태이다. 또한 delegatecall 은 호출한 컨트랙트에서 코드가 동작되고 상태 변경이 일어난다

마치 원격에 있는 코드가 인클루드 한 곳에서 실행되는 것으로 이해하면 쉽다.(웹의 RFI 취약점)

function forward(address callee, bytes _data)

public {require(callee.delegatecall(_data));

SWC DoS with Failed Call(통화가 실패한 DoS)

통화가 실패한 DoS 취약점은 예외 상태의 부적절한 점검 또는 처리에 관련된 것이다. 실수로 또는 고의로 외부 통화에 실패할 수 있으며 이로 인해 계약에서 DoS 상태가 발생할 수 있다. 이러한 실패로 인한 피해를 최소화하려면 각 외부 통화를 통화 수신자가 시작할 수 있는 자체 트랜잭션으로 분리하는 것이 좋다. 이것은 특히 지불과 관련이 있으며, 사용자가 자금을 자동으로 푸시하는 것보다 자금을 인출하는 것이 더 좋다.

for(uint i=0;i<numbers;i++) 처럼 반복된 동작으로 중요 기능을 구현시에 문제가 한번 발생하더라도 나머지 모든 동작이 마비가 될수 있는 문제점이 있다.

취약점에 대한 보완책으로, 단일 트랜잭션에서 여러 호출을 결합하지 말아야 한다(특히 루프의 일부로 호출이 실행될 때). 항상 외부 통화가 실패 할 수 있다고 가정해야 한다. 실패한 통화를 처리하기 위한 계약 논리 구현이 필요하다.

SWC Transaction Order Dependence(거래 주문 의존)

거래 주문 의존 취약점은 동기화가 잘못된 공유 리소스를 사용하는 동시 실행 ( '레이스 조건')에 관련된 것이다. 이더리움 네트워크는 약 17 초마다 새로운 블록이 확인되는 블록으로 트랜잭션을 처리한다. 채굴자들은 자신이 받은 거래를 보고 누가 포함할만큼 높은 가스 가격을 지불했는지에 따라 블록에 포함할 거래를 선택한다.

또한, 트랜잭션이 Ethereum 네트워크로 전송되면 처리를 위해 각 노드로 전달된다. 따라서 이더리움 노드를 실행하는 사람은 완료되기 전에 어떤 트랜잭션이 발생할지 알 수 있다. 경쟁 조건 취약점은 코드가 제출 된 트랜잭션의 순서에 따라 달라질 때 발생한다.

EOA(사용자)가 트랜잭션을 가스(보상)와 함께 요청을 하면 채굴자들이 보상을 받고 트랜잭션을 처리해주게 되는데 이때 다른 사용자의 트랜잭션에 정답이나 비밀키와 같은 중요한 트랜?Ъ굼? 그대로 복사하여 더 높은 보상으로 트랜잭션을 요청하면 악의적인 사용자의 트랜잭션이 선택될 수 있는 문제이다.

취약점에 대한 보완책으로 보상과 교환하여 정보를 제출할 때 경쟁 조건을 해결하는 가능한 방법을 커밋 공개 해시 체계라고 한다. 답변을 제출 한 당사자는 답변을 제출하는 대신 해시 (salt, address, answer) [선택한 수의 salt를 계약서에 제출한다. 발신자가 보상을 청구하기 위해 salt와의 거래를 제출하고 응답하십시오. 계약 해시 (salt, msg.sender, answer)는 해시가 계약과 일치하는 경우 저장된 해시와 비교하여 생성 된 해시를 확인하여 보상을 해제한다.

ERC20 경쟁 조건에 대한 최선의 수정은 예상 전류 값인 승인의 입력에 필드를 추가하고 이브의 현재 허용량이 Alice가 예상한 것이 아닌 경우 복귀를 승인하는 것이다. 그러나 이는 계약이 더 이상 ERC20 표준을 준수하지 않음을 의미한다. 계약서가 ERC20을 준수하도록 하는 것이 프로젝트에 중요한 경우 안전한 승인 기능을 추가 할 수 있다. 사용자 관점에서 승인을 변경하기 전에 승인을 0으로 설정하여 ERC20 경쟁 조건을 중재할 수 있다.

SWC Authorization through tx.origin(tx.origin을 통한 인증)

tx.origin을 통한 인증 취약점은 폐기된 기능 사용에 관련된 것이다. tx.origin는 거래를 보낸 계정의 주소를 반환하는 Solidity의 전역 변수이다. 권한 부여에 변수를 사용하면 권한있는 계정이 악의적 인 계약을 호출할 경우 계약이 취약해질 수 있다. tx.origin거래의 원래 발신자 (이 경우 인증된 계정)를 반환하므로 인증 검사를 통과하는 취약한 계약을 호출할 수 있다.

아래처럼 msg.sender를 사용하지 않고 tx.origin으로 인증할 시에 취약점이 발생하며 직접적인 공격은 아니며, 피싱으로 악용될 수 있다. tx.origin은 트랜잭션 호출자이고, msg.sender는 이전 호출자이다.

A: 지갑 컨트랙트(인출용)

B: A의 소유주. 피해자

C: 해커가 만든 악성 컨트랙트

(하는일 A컨트랙트에 있는 인출 함수 호출)

위와 같은 상황에서 B가 C를 호출하면 C에서 A를 호출하게 되며 아래와 같은 권한을 체크하게 되지만, A입장에서 tx.origin 값은 C가 아닌 B가 되고 owner 역시 B 이므로 권한 체크가 정상적으로 이루어지게 되며, 해커의 의도대로 인출이 되는 취약점이다.

require(tx.origin == owner);

receiver.transfer(amount);

취약점에 대한 보완책으로, tx.origin는 승인에 사용해서는 안된다. 대신 msg.sender를 사용할 필요가 있다.

SWC Timestamp Dependence(타임 스탬프 종속성)

타임 스탬프 종속성 취약점은 신뢰할 수 없는 제어 영역에서 기능 포함에 관련된 것이다. 계약은 종종 시간 종속 이벤트를 트리거하기 위해 현재 타임 스탬프에 액세스해야 한다. 이더리움이 분산되어 있으므로 노드는 어느 정도 시간을 동기화 할 수 있다. 더욱이 악의적인 채굴자는 블록의 타임 스탬프를 변경할 수 있다. 특히 그렇게 함으로써 이점을 얻을 수 있다면 더욱 그렇다. 그러나 채굴자는 이전 타임 스탬프보다 더 작은 타임 스탬프를 설정할 수 없으며 (그렇지 않으면 블록이 거부됨) 미래에 타임 스탬프를 너무 멀리 설정할 수 없다. 위의 모든 사항을 고려하면 개발자는 제공된 타임 스탬프의 정확성에 의존 할 수 없다.

시간은 채굴자에 의해 정해지고, 작은 오차는 노드에서 인정을 해주므로 조작이 가능하다. 아래와 같이 시간에 의존적인 경우 취약하다

return block.timestamp >= 1546300800;

치료 취약점에 대한 보완책으로, 개발자는 타임 스탬프 차단 및 실제 타임 스탬프가 최대 0.5 분까지 달라질 수 있다는 개념으로 현명한 계약을 작성할 필요가 있다. 블록번호 또는 외부 타임 스탬프 소스를 oracles를 통해 사용할 수 있다.

SWC Signature Malleability(시그니처 가변성)

스그니처 가변성 취약점은 암호화 서명의 부적절한 확인에 관련된 것이다. 이더리움 계약에서 암호화 서명 시스템의 구현은 종종 서명이 고유하다고 가정하지만 개인 키를 소유하지 않고도 서명을 변경할 수 있으며 여전히 유효하다. EVM 사양은 ecrecover 타원 곡선 공개 키 복구를 실행하는 소위 '사전 컴파일 된'계약을 정의한다. 악의적인 사용자는 세 가지 값 v , r 및 s 를 약간 수정하여 다른 유효한 서명을 만들 수 있다. 서명이 서명된 메시지 해시의 일부인 경우 계약 레벨에서 서명 확인을 수행하는 시스템이 공격에 취약할 수 있다. 악의적인 사용자가 이전에 서명 한 메시지를 재생하기 위해 유효한 서명을 만들 수 있다. 취약점에 대한 보완책으로 이전에 메시지가 계약에 의해 처리되었는지 확인하기 위해 서명 된 메시지 해시에 서명을 포함해서는 안된다.

SWC Incorrect Constructor Name(잘못된 생성자 이름)

잘못된 생성자 이름 취약점은 부적절한 초기화에 관련된 것이다. 생성자(constructors)는 계약 작성 중에 한번만 호출되는 특수 함수이다. 이들은 종종 계약 소유자 설정과 같은 중요하고 특권적인 조치를 수행한다. Solidity 버전 0.4.22 이전에는 생성자를 정의하는 유일한 방법은 이를 포함하는 계약 클래스와 이름이 같은 함수를 작성하는 것이다. 생성자가 되는 함수는 이름이 계약 이름과 정확히 일치하지 않으면 호출 가능한 일반 함수가 된다. 이 동작으로 인해 특히 스마트 컨트랙트 코드가 다른 이름으로 재사용되지만 생성자 함수의 이름이 그에 따라 변경되지 않는 경우 보안 문제가 발생한다.

취약점에 대한 보완책으로, Solidity 버전 0.4.22 constructor에는 생성자 정의를보다 명확하게 하는 새로운 키워드가 도입되었다. 따라서 계약을 최신 버전의 Solidity 컴파일러로 업그레이드하고 새 생성자 선언으로 변경하는 것이 좋다.

SWC Shadowing State Variables(섀도잉 상태 변수)

섀도잉 상태 변수 취약점은 코딩 표준에 대한 부적절한 준수에 관련된 것이다. 견고성은 상속이 사용될 때 상태 변수의 모호한 이름 지정을 허용한다. 변수 x를 가지고 있는 계약 A는 정의된 상태 변수 x를 가지고 있는 계약B를 상속할 수 있다. 이것은 x의 두 가지 버전을 만들게 되는데, 하나는 A계약에서 액세스하고 다른 하나는 B계약에서 액세스한다. 보다 복잡한 계약 시스템에서는 조건이 눈에 띄지 않게되어 보안 문제가 발생할 수 있다. 계약 및 기능 수준에 여러 정의가 있는 경우 단일 계약 내에서 섀도잉 상태 변수가 발생할 수도 있다.

취약점에 대한 보완책으로, 계약 시스템에 대한 스토리지 변수 레이아웃을 신중하게 검토하고 모호성을 제거할 필요가 있다. 단일 계약 내에서 문제를 표시 할 수 있으므로 항상 컴파일러 경고를 확인하는 것이 좋다.

SWC Weak Sources of Randomness from Chain Attributes(체인 속성에서 약한 무작위 소스)

체인 속성에서 약한 무작위 소스 취약점은 불충분 한 임의 값 사용에 관련된 것이다. 난수를 생성하는 기능은 모든 종류의 응용 프로그램에서 매우 유용하다. 명백한 예 중 하나는 의사 난수 생성기가 승자를 선택하는 데 사용되는 도박 DApp이다. 그러나 이더리움에서 강력한 임의의 소스를 만드는 것은 매우 어려운 일이다. 예를 들어, 채굴자가 몇 초 내에 타임 스탬프를 제공하고 다른 사람들이 자신의 블록을 수락하도록 선택할 수 있으므로 block.timestamp 의 사용이 안전하지 않을 수 있다. blockhash, block.difficulty및 기타 필드의 사용은 채굴자가 제어하므로 안전하지 않다. 지분이 높으면 채굴자는 하드웨어를 대여하여 짧은 시간에 많은 블록을 채굴하고, 블록 해시가 필요한 블록을 골라 다른 모든 것을 버릴 수 있다. 취약점에 대한 보완책으로 RANDAO와 같은 확약 체계 사용을 할 수 있다. 오라클을 통해 난수의 외부 소스를 사용하여, 이 접근 방식은 오라클을 신뢰해야 하므로 다중 오라클을 사용하는 것이 합리적일 수 있다. 비트코인 블록 해시를 사용하면 채굴 비용이 많이 든다.

SWC Missing Protection against Signature Replay Attacks(서명 재생 공격에 대한 보호 기능 결여)

서명 재생 공격에 대한 보호 기능 결여 취약점은 암호화 서명의 부적절한 확인에 관련된 것이다. 유용성을 높이거나 가스 비용을 절약하려면 스마트 컨트랙트에서 서명 확인을 수행해야하는 경우가 있다. 안전한 구현을 위해서는 예를 들어 처리된 모든 메시지 해시를 추적하고 새 메시지 해시만 처리할 수 있도록 하여 서명 재생 공격으로부터 보호해야 한다. 악의적인 사용자는 그러한 통제없이 계약을 공격하고 다른 사용자가 여러 번 처리 한 메시지 해시를 얻을 수 있다.

취약점에 대한 보완책으로, 서명 재생 공격으로부터 보호하려면 다음 권장 사항을 고려할 수 있다. 스마트 컨트랙트에 의해 처리된 모든 메시지 해시를 저장하는 것이 좋다. 새 메시지가 수신되면 기존 메시지를 확인하고 새 메시지 해시인 경우에만 비즈니스 논리를 진행하는 것이 좋다.

메시지를 처리하는 계약 주소를 포함하는 것이 좋다. 이렇게 하면 메시지를 단일 계약에서만 사용할 수 있다. 어떠한 경우에도 서명을 포함하여 메시지 해시를 생성하지 않는다. 이 ecrecover기능은 서명 가변성에 취약하다.

SWC Lack of Proper Signature Verification(적절한 서명 확인 부족)

직절한 서명 확인 부족 취약점은 데이터 진위성 검증 불충분에 관련된 것이다. 스마트 컨트랙트 시스템은 유연성과 증가된 전송성으로 인해 사용자에게 직접 온 체인 거래를 요청하는 대신 오프 체인 메시지에 서명할 수 있도록 하는 일반적인 패턴이다. 서명된 메시지를 처리하는 스마트 컨트랙트 시스템은 서명된 메시지를 처리하기 전에 서명된 메시지에서 진위를 복구하기 위해 자체 논리를 구현해야 한다. 이러한 시스템의 한계는 스마트 컨트랙트는 메시지에 서명할 수 없기 때문에 스마트 컨트랙트와 직접 상호 작용할 수 없다는 것이다. 일부 서명 확인 구현에서는 이 제한이 없는 다른 방법을 기반으로 서명된 메시지의 유효성을 가정하여 이 문제를 해결하려고 한다. 그러한 방법의 예는 msg.sender에 의지하는 것이다. 서명된 메시지가 발신자 주소에서 시작된 경우 발신자 주소로도 작성된 것으로 가정한다. 이로 인해 특히 프록시를 사용하여 트랜잭션을 릴레이 할 수 있는 시나리오에서 취약점이 발생할 수 있다.

취약점에 대한 보완책으로, ecrecover()를 통해 적절한 서명 확인이 필요하지 않은 대체 확인 체계를 사용하지 않는 것이 좋다. .

SWC Requirement Violation(요구 사항 위반)

요구 사항 위반 취약점은 발신자가 지정한 사양을 따르지 않음에 관련된 것이다. Solidity require() 구문은 함수의 외부 입력을 확인하기 위한 것이다. 대부분의 경우 이러한 외부 입력은 발신자가 제공하지만 수신자가 반환할 수도 있다. 전자의 경우 전제 조건 위반이라고 한다. 요구 사항을 위반하면 계약에 외부 입력을 제공 한 버그가 있거나, 요구 사항을 표현하는 데 사용된 조건이 너무 강한 문제중 하나가 나타날 수 있다.

취약점에 대한 보완책으로, 필요한 논리적 조건이 너무 강하면 모든 유효한 외부 입력을 허용하도록 약화되어야 한다. 그렇지 않으면, 버그는 외부 입력을 제공 한 계약서에 있어야 하며 유효하지 않은 입력이 제공되지 않도록 하여 코드 수정을 고려해야 한다.

SWC Write to Arbitrary Storage Location(임의 저장 위치에 쓰기)

임의 저장 취치에 쓰기 취약점은 어디에 쓰기 조건에 관련된 것이다. 스마트 컨트랙트의 데이터 (예 : 계약의 소유자 저장)는 EVM 수준의 일부 저장 위치 (예 : 키 또는 주소)에 지속적으로 저장된다. 계약은 승인된 사용자 또는 계약 계정만 민감한 저장 위치에 쓸 수 있도록 해야 한다. 공격자가 계약의 임의의 저장 위치에 쓸 수 있으면 권한 검사를 쉽게 우회 할 수 있다. 이로 인해 공격자가 저장소를 손상시킬 수 있다. 예를 들어 계약 소유자의 주소를 저장하는 필드를 덮어 쓴다.

취약점에 대한 보완책으로, 일반적으로 모든 데이터 구조가 동일한 스토리지 (주소) 공간을 공유한다는 점에서 한 데이터 구조에 대한 쓰기가 다른 데이터 구조의 항목을 실수로 겹쳐 쓰지 않아야 한다.

SWC Incorrect Inheritance Order(잘못된 상속 순서)

잘못도니 상속 순서 취약점은 잘못된 동작 순서에 관련된 것이다. Solidity는 다중 상속을 지원하므로 하나의 계약이 여러 계약을 상속 할 수 있다. 다중 상속은 다이아몬드 문제 라는 모호성을 유발한다. 둘 이상의 기본 계약이 동일한 기능을 정의하는 경우 하위 계약에서 어떤 기능을 호출해야 하는지에 대한 모호성이 있다. Solidity는 기본 계약 간 우선 순위를 설정하는 역 C3 선형화를 사용하여 이러한 모호성을 처리한다. 이렇게 하면 기본 계약의 우선순위가 다르므로 상속 순서가 중요하다. 상속 순서를 무시하면 예기치 않은 동작이 발생할 수 있다. 취약점에 대한 보완책으로 여러 계약을 상속할 때, 특히 계약이 동일한 기능인 경우 개발자는 상속을 올바른 순서로 신중하게 지정해야 한다. 경험의 원칙은 계약을 더 많은 / general /에서 더 많은 / specific /로 상속하는 것이다.

SWC Arbitrary Jump with Function Type Variable(함수 유형 변수가 있는 임의 점프)

함수 유형 변수가 있는 임의 점프 취약점은 하위 수준 기능 사용에 관련된 것이다. Solidity는 기능 유형을 지원한다. 즉, 일치하는 서명을 가진 함수를 참조하여 함수 유형의 변수를 지정할 수 있다. 이러한 변수에 저장된 함수는 일반 함수처럼 호출 할 수 있다. 문제는 사용자가 임의로 함수 유형 변수를 변경하여 임의 코드 명령어를 실행할 수 있는 능력이 있을 때 발생한다. Solidity는 포인터 산술을 지원하지 않기 때문에 이러한 변수를 임의의 값으로 변경할 수 없다. 그러나 개발자가 mstore 또는 할당 연산자와 같은 어셈블리 명령어를 사용하는 경우 최악의 시나리오에서 공격자는 필요한 유효성 검사 및 필요한 상태 변경을 위반하여 코드 형식에 함수 유형 변수를 지정할 수 있다.

private과 같이 누구나 실행할 수 없는 함수 타입이라고 가정했을 시 아래와 같은 assembly 호출로 함수 타입을 변경하고 특정 함수를 실행할 수 있는 취약점이다.

assembly { mstore(func, add(mload(func), callvalue)) }

취약점에 대한 보완책으로 조립 사용은 최소화되어야 한다. 개발자는 사용자가 함수 유형 변수에 임의의 값을 할당하도록 허용해서는 안된다.

SWC DoS With Block Gas Limit(블록 가스 제한이 있는 DoS)

블록 가스 제한이 있는 DoS 취약점은 통제되지 않은 자원 소비에 관한 것이다. 스마트 컨트랙트가 배포되거나 그 내부의 기능이 호출되면 이러한 액션을 실행하려면 계약을 완료하는 데 필요한 계산량에 따라 항상 일정한 양의 가스가 필요하다. 이더리움 네트워크는 블록 가스 제한을 지정하며 블록에 포함된 모든 트랜잭션의 합계는 임계 값을 초과할 수 없다. 중앙 집중식 애플리케이션에서 무해한 프로그래밍 패턴은 기능 실행 비용이 블록 가스 한계를 초과할 때 스마트 컨트랙트에서 서비스 거부 조건으로 이어질 수 있다. 시간이 지남에 따라 크기가 증가하는 알 수없는 크기의 배열을 수정하면 이러한 서비스 거부 조건이 발생할 수 있다.

취약점에 대한 보완책으로 시간이 지남에 따라 큰 어레이가 커질 것으로 예상되는 경우 주의가 권장된다. 전체 데이터 구조에서 루핑(looping)해야 하는 작업은 피해야 한다. 알 수 없는 크기의 배열을 반드시 반복해야 하는 경우 잠재적으로 다중 블록을 사용하도록 계획해야 하므로 다중 트랜잭션이 필요하다.

SWC Typographical Error(인쇄상의 오류)

인쇄상의 오류 취약점은 잘못된 연산자 사용에 관련된 것이다. 예를 들어 정의된 연산의 의도가 숫자를 변수(+ =)에 합산하려고 하지만 실수로 잘못된 방식으로 정의된 경우 오타(= +)가 발생하는 경우 인쇄상의 오류가 발생할 수 있다. 합계를 계산하는 대신 변수를 다시 초기화한다. 단항 + 연산자는 새로운 견고성 컴파일러 버전에서 더 이상 사용되지 않는다.

취약점에 대한 보완책으로 OpenZeppelin이 개발한 SafeMath와 같은 산술 계산을 위해 수학 연산에서 사전 조건 검사를 수행하거나 검증된 라이브러리를 사용하여 약점을 피할 수 있다.

SWC Right-To-Left-Override control character (U+202E)(오른쪽에서 왼쪽으로 재정의 제어 문자 (U + 202E))

오른쪽에서 왼쪽으로 재정의 제어 문자 취약점은 중요한 정보의 UI (사용자 인터페이스) 오해에 관련된 것이다. 악의적인 행위자는 Right-To-Left-Override 유니 코드 문자를 사용하여 RTL 텍스트 렌더링을 강제하고 사용자를 계약의 실제 의도와 혼동 할 수 있다.

취약점에 대한 보완책으로 U + 202E 캐릭터의 합법적인 사용은 거의 없다. 스마트 컨트랙트에 나타나지 않아야 한다.

SWC Presence of unused variables(사용하지 않는 변수의 존재)

사용하지 않는 변수의 존재 취약점은 관련없는 코드에 관련된 것이다. 사용하지 않는 변수는 Solidity에서 허용되며 직접적인 보안 문제는 없다. 가능한 한 피하는 것이 가장 좋다. 계산 증가 및 불필요한 가스 소비를 유발한다. 버그 또는 변형된 데이터 구조를 나타내며 일반적으로 코드 품질이 좋지 않음을 나타낸다. 코드 노이즈 발생 및 코드 가독성 감소를 유발한다.

취약점에 대한 보완책으로 코드 베이스에서 사용하지 않는 모든 변수를 제거하는 것이 좋다.

SWC Unexpected Ether balance(예상치 못한 이더 밸런스)

예상치 못한 이더 밸런스 취약점은 부적절한 잠금에 관련된 것이다. 계약서에서 특정 이더 잔액을 엄격하게 가정하면 계약이 잘못 작동 할 수 있다. selfdestruct를 사용하거나 계정에 마이닝하여 ether를 강제로 계약에 보낼 수 있다 (대체 기능을 트리거하지 않음). 최악의 시나리오에서는 계약을 사용할 수 없는 DOS 조건이 발생할 수 있다.

취약점에 대한 보완책으로 계약에서 이더 잔액에 대한 엄격한 동등성 검사를 피하는 것이 좋다.

스마트 컨트랙트 바이트 코드는 EVM의 스택 메모리에 저장된다. 제1 스마트 컨트랙트 감사부(110)는 스택에서 바이트 코드를 읽어들여 취약점을 분석하는 감사를 수행한다.

스택은 수직 구조로 되어 있다. 따라서, 제1 스마트 컨트랙트 감사부(110)가 스택에 저장된 바이트 코드에 대하여 취약점 분석을 수행하기 위해서는 스택의 아래부터 바이트 코드를 차례대로 읽어와야 한다. 이때, 스택에서 바이트 코드를 읽어들일 때 시간 지연이 일어나지 않게 하는 것이 중요하다.

본 발명의 일실시예에서는 스택에서 바이트 코드를 읽어들일 때 시간 지연이 일어나지 않도록 SSA(static single assignment) 기법을 적용하고 있다.

한편, 제2 스마트 컨트랙트 감사부(120)도 SSA(static single assignment) 기법을 이용하여 소스 코드를 읽어들여 변수가 연관되는 취약점에 대하여 감사할 수 있다.

스마트 컨트랙트(200)는 스크립트 언어를 제공하고 있다. 이더리움 같은 경우는 스마트 컨트랙트를 위해 솔리디티(Solidity)라는 스크립트 언어를 제공하고 있다. 프로그래밍 언어이다보니 코딩하듯이 스마트 컨트랙트를 작성할 수 있다.

프라이빗 블록체인들의 경우는 대부분 스마트 컨트랙트 기능을 제공하고 있다. IBM 주도하의 하이퍼레저(Hyperledger)같은 경우는 체인코드(Chaincode)라는 이름으로 스마트 컨트랙트를 제공하고 있다. 이외에도 스마트 컨트랙트는 다양한 스크립트 언어로 구현될 수 있다.

스크립트 언어를 실행하기 위해 인터프리터(interpreter) 기반의 가상머신이 널리 사용된다. 인터프리터 기반의 가상머신은 스크립트를 중간 단계 코드인 바이트코드(Bytecode)로 변환하고, 생성된 바이트코드를 실행한다.

인터프리터의 디스패치 루프(dispatch loop)는 생성된 바이트코드들을 실행하는 루프로써, 바이트코드는 인출(fetch), 해석(decode), 실행(execute) 등의 단계로 처리된다.

스마트 컨트랙트 감사 장치(100)는 바이트코드를 인출, 해석, 및 실행한다. 바이트코드는 프로그래밍 툴에서 다양한 종류의 프로그래밍 언어로 작성된 소스 코드(SC; source code)를 컴퓨터 내부에서 바로 처리 가능한 기계어로 변환하기 위한 코드일 수 있다.

예시적으로, 바이트코드는 바이트코드 변환 장치로부터 생성되는 코드일 수 있다. 예를 들어, 고급 프로그래밍 언어로 작성된 소스 코드(SC)는 컴파일러(compiler) 또는 인터프리터에 의해 바이트코드로 변환될 수 있다.

바이트코드는 동작코드(opcode)(OC)와 피연산자(operand)(OR)를 포함할 수 있다. 동작코드(OC)는 컴퓨터에서 연산의 종류를 나타내기 위한 코드이고, 피연산자(OR)는 연산의 대상이 되는 데이터나 정보를 포함한다. 즉, 동작코드(OC)는 피연산자(OR)의 데이터나 정보를 이용하여 대응하는 연산을 수행할 수 있는 형태의 코드를 의미할 수 있다.

예를 들어, "ADD r0 r0 r1"의 바이트코드는 "ADD"의 동작코드(OC)와 "r0 r0 r1"의 피연산자(OR)로 구분될 수 있다. "ADD"는 덧셈 연산을 나타내고, "r0 r0 r1"은 덧셈 연산의 대상이 되는 피연산자(OR)의 정보를 나타낼 수 있다. "ADD r0 r0 r1"의 바이트코드는 "r0" 레지스터의 값과 "r1" 레지스터의 값을 더하여 "r0" 레지스터에 저장하는 동작을 나타낸다.

따라서, 본 발명의 실시 예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 장치(100)에서 처리되는 바이트코드는 동작코드(OC)와 피연산자(OR)를 포함하는 형태의 모든 코드를 포함한다. 또한, 본 발명의 실시 예에 따른 바이트코드 처리 장치(100)에서 처리되는 바이트코드는 소스 코드(SC)로부터 변환된 코드뿐만 아니라 프로그램 툴에 의해 동작코드(OC)와 피연산자(OR)를 포함하는 형태로 프로그램 된 코드를 모두 포함할 수 있다.

다중 레이어 기반 스마트 컨트랙트 감사 장치(100)는 하나의 바이트코드를 처리하기 위해 컴퓨터 등의 기계가 인식할 수 있는 복수개의 명령어들을 처리할 수 있다. 즉, 다중 레이어 기반 스마트 컨트랙트 감사 장치(100)는 복수개의 명령어들의 처리를 통해 하나의 바이트 코드를 처리하는 과정의 동작들을 수행할 수 있다.

본 명세서에서 명령어는 바이트코드를 처리하기 위해 컴퓨터 등의 장치(예를 들어, 스마트 컨트랙트 감사 장치(100))가 인식 및 실행할 수 있는 기계어를 의미한다. 바이트코드는 컴퓨터 등의 장치가 직접 인식 및 실행할 수 있는 명령어와 다른 형태를 가지므로, 장치 내부에서 바이트코드가 처리되는 경우, 복수개의 명령어를 통해 바이트코드가 처리될 수 있다.

본 발명의 일실시예에서는 이더리움의 경우에 대하여 스마트 컨트랙트를 설명하지만, 본 발명은 이제 제한되지 않고 하이퍼레저와 그 외의 다양한 스크립트 언어를 제공하는 스마트 컨트랙트에 적절하게 변형하여 적용될 수 있다.

이더리움에서 스마트 컨트랙트는 새로운 스마트 컨트랙트를 생성하거나, 특정 스마트 컨트랙트상의 함수를 실행하거나, 이더를 전송하는 방식중의 하나로 실행이 된다. 또한 사용자 어카운트(EOA)에 의해서 발생한 트랜잭션이나 다른 컨트랙트에 의해서만 실행된다.

이더리움의 스마트 컨트랙트에서는 무한 반복같은 악의적인 코드를 막고 데이타의 무결성를 지키기 위해 모든 트랜잭션을 실행할때 해당 실행비용을 지급하도록 규정하고 있으며, 이와같은 모든 트랜잭션의 기본실행비용은 21,000 가스이다.

이와 같은 비용에는 발송자 어카툰트 주소에 대한 ECDSA를 위한 비용과 트랜잭션 저장을 위한 스토리지 비용, 네트워크 대역폭 비용이 포함된다. 이와같이 스마트 컨트랙트 실행시 비용을 지불하도록 정의하여, 의도적인 디도스 공격과 같은 무한실행과 같은 악의적인 의도를 방지할 수 있다.

스마트 컨트랙트간의 호출은 메시지라는 특별한 구조체를 사용하여 호출된다. 메시지는 외부 어카운트(EOA)가 아니라 컨트랙트 어카운트(CA)에 의해서만 생성되며, 함수 호출시에 다른 컨트랙트로 전달된다. 메시지는 트랜잭션과는 달리 EVM 내부에서만 존재하기 ??문에 가스비용이 발생하지 않는다.

다음은 메시지의 구조이다. 메시지는 EVM내에서 컨트랙트를 실행하기 위해서 Call, CallCode, DelegateCall, StaticCall 등이 호출될때에 생성된다. 이들 Call 코드들은 공통적으로 컨트랙트 주소를 매개변수로 전달받아 이를 실행하고 처리한다.

메시지 구조는 아래와 같다.

type Message struct {

to *common.Address

from common.Address

nonce uint64

amount *big.Int

gasLimit uint64

gasPrice *big.Int

data []byte

checkNonce bool

to : 메시지 수신처

from : 메시지 발신처

nonce : 거래 실행시 수행되도록 허용된 최대 트랜잭션 수행횟수

amount : 메시지와 함께 전달되는 이더(wei 단위)

gasLimit : 트랜잭션 수행시 소비될 총 가스량에 대한 추정치

gasPrice : 가스가격

data : 매개변수 전달시 사용되는 데이타 필드(Optional)

다음과 같이 Call, CallCode, DelegateCall 이 호출될때에 메시지가 만들어진다. Call, CallCode, DelegateCall 함수호출은 서로간에 차이점이 있다.

이더리움에서 스마트 컨트랙트는 솔리디티(Solidity) 언어로 프로그래밍되어진다. 솔리디티 언어로 프로그래밍된 스마트 컨트랙트는 컴파일러에 의해 바이트 코드로 컴파일되고, 컴파일된 바이트코드는 블록에 포함되어, EVM(Ethereum Virtual Machine)에 의해 실행된다.

Virtual Machine(가상머신)은 가상의 하드웨어를 소프트웨어 적으로 구현하여, 그 위에서 프로그램이 실행되도록 하는 것이다.

EVM(Ethereum Virtual Machine)은 이더리움 스마트 컨트랙트의 바이트 코드를 실행하는 32바이트 스택 기반의 실행환경으로 스택의 최대 크기는 1024이다. 이더리움의 각 노드는 EVM을 포함하고 있으며, EVM을 통해 바이트 코드를 OP코드로 변환하고 스택기반으로 각각의 OP코드를 실행한다.

EVM은 휘발성, 비휘발성 메모리로 구성되어 있으며, 여기에 바이트 배열 형태로 스택의 항목들을 저장한다.

휘발성(volatile) 메모리는 OP 코드를 실행하기 위한 스택영역(stack)과, 컨트랙트 호출시에 넘어오는 인자를 저장하는 args와, word 단위로 아이템을 저장하는 바이트 배열인 memory로 이루어져 있다.

비휘발성 (non-volatile) 메모리는 상태(state)가 저장되는 storage와 스마트 컨트랙트의 컴파일된 바이트 코드가 저장되는 code를 포함할 수 있다.

EVM은 바이트코드를 내부 OP 코드로 재해석한다. 즉, solidity 언어로 개발된 스마트 컨트랙트의 컴파일된 바이트 코드는 EVM에서 OP 코드로 치환하여 실행된다.

예를 들어, "1+2"를 계산하는 바이트 코드를 가지고 EVM의 동작을 알아보도록 한다.

1+2를 계산하는 코드의 바이트코드는 "6001600201" 이다. 이 바이트코드를 치환하여 OP 코드로 분리하면 "0x60, 0x01, 0x60, 0x02, 0x01" 이 된다.

0x60은 PUSH OPCODE를 의미하고, 0x01, 0x02는 값, 1, 2를 의미하고, 마지막 0x01은 ADD OPCODE를 의미한다. 즉 EVM의 스택에 1,2를 Push하고 Add 연산을 수행하라는 의미이다.

evm 도구를 사용하면 실제 바이트코드가 OP코드로 치환되어 실행되는 과정을 살펴볼 수 있다.

evm 도구를 사용하여 위의 바이트코드를 실행할 경우 결과값 3이 스택에 넣어지는 것을 확인할 수 있다. 또한 OP코드표상으로 PUSH, ADD 연산의 Gas 비용은 3임을 확인할수 있고, 해당 연산이 수행시에 3 Gas가 사용됨을 확인할수 있다.

EVM의 특징을 정리해보면 다음과 같다.

1. 임시 저장소와 영구 저장소를 구분하여, 임시 저장소에 저장한 값은 해당 인스턴스에서만 유효하고, 영구 저장소에 저장한 값은 해당 컨트랙트 전체에 유효하다.

2. EVM에서 바이트 코드를 실행하기 위해서는 다음의 3가지 요소가 필요하다.

- 컨테이너에 값을 Push, Pop하기 위한 스택

- 바이트 배열을 담을수 있는 메모리

- 영속적으로 값을 저장하기 위한 저장소. 현재 저장소로는 레벨DB를 사용하고 있다.

3. 4,8바이트 워드단위는 크기가 너무작아, 32바이트 워드 단위를 지원한다.

4. 32바이트 워드크기 등 이더리움에서 요구하는 VM기능과 명세를 지원하기 위해 단순화된 자체 VM을 개발하였다.

5. 메모리 크기가 가변적이고 스택의 크기에 제한이 없다.

6. 반복호출횟수를 1024로 제한하였다.

스마트 컨트랙트를 컴파일하고 배포하면 바이트코드가 생성되어 배포된다. 바이트코드에는 로직만 남고 원래 코드에 들어있는 정보가 많이 사라지게 되는데, 특히 메소드 이름과 관련된 인터페이스 정보가 사라지기 때문에 이를 편하게 하고자 abi라고 하는 파일이 생성된다.

스마트 컨트랙트를 컴파일하면 build/contracts 디렉토리에 abi 파일들이 json 형식으로 생성되게 된다. 다른 스마트 컨트랙트들을 import하면 해당 스마트 컨트랙트의 abi 파일에 그 모든 컨트랙트들의 인터페이스 정보가 다 담기므로 사용하고자 하는 컨트랙트의 abi 파일만 활용하면 된다.

이더리움 스마트 컨트랙트를 작성후 컴파일하면 바이트코드로 컴파일된 결과물이 생성되고, 이러한 바이트코드가 이더리움 블록체 저장이 된다. 그리고 스마트컨트랙트의 특정 함수를 호출할 경우, 해당 함수를 구분할 수 있는 정보를 통해, 호출할 함수를 구분하여 호출하게 되는데, Function selector를 통해서 이러한 함수를 구분하게 된다.

이더리움은 Stack, Memory, Storage 라는 세 개의 저장공간이 있고 컨트랙트 외부의 데이터가 컨트랙트에 접근할 수 있게 하는 CallData라는 개념이 있다.

Stack은 기본적으로 Stack 자료구조와 동일하다. Stack의 한 element는 256bits이며 총 1024개의 element를 가질 수 있다. Stack은 memory나 storage같은 저장소가 아니라 연산을 위한 공간이기 때문에 대다수의 Op코드는 stack과 함께 상호작용하게 된다.

Memory는 Stack과 같이 수직적인 자료구조가 아닌 수평적인 자료구조이다. 흔히 “메모리를 참조한다” 라는 표현을 쓰고는 하는데 그것과 동일하게 생각할 수 있다.

Memory는 휘발성(volatile)의 공간으로 컨트랙트가 종료되면 메모리는 컨트랙트와 함께 소멸된다.

Storage는 Memory 와 다르게 영구적(persistent)인 저장소이다. SSTORE와 SLOAD 두 개의 Opcode로 접근이 가능하며 이 공간은 블록과 함께 저장되어서 컨트랙트가 종료되어도 사라지지 않는다. 이는 이더리움의 소스를 사용한다는 뜻이기 때문에 Storage를 사용하게 되면 많은 gas비용이 든다.

Storage에 저장될 때에는 key-value 형식을 가지며 SSTORE는 Stack에서 key와 value를 꺼내서 Storage에 저장하게 된다.

도 2는 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 방법을 설명하기 위한 도면이다.

도 2를 참조하면, 본 발명의 일실시예에 따른 다중 레이어 기반 스마트 컨트랙트 감사 방법에서는 스마트 컨트랙트 감사 장치(100)는 분석할 스마트 컨트랙트(200)를 수신한다(S1). 스마트 컨트랙트(200)는 개발중인 상태로 개발 서버로부터 수신될 수 있다. 스마트 컨트랙트(200)는 Git 에서 개발중인 상태일 수 있다.

제1 스마트 컨트랙트 감사부(110)는 바이트 코드(210)가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장한다(S2). 메모리는 Stack과 같이 수직적인 자료구조가 아닌 수평 구조를 가지고 있다.

여기에서, 바이트 코드를 평면 배열로 저장을 한다는 것은 제1 스마트 컨트랙트 감사부(110)가 Stack과 같이 수직으로 순차적인 접속이 아닌 원하는 어드레스의 저장된 바이트 코드를 곧바로 읽어들일 수 있도록 펼쳐서 저장한다는 의미이다.

제1 스마트 컨트랙트 감사부(110)는 메모리로부터 바이트 코드를 읽어들여서 취약점이 있는지 여부를 감사한다(S3).

예를 들어, SWC의 오버플로같은 취약점들에 대하여는 바이트 코드 레벨에서도 얼마든지 감사가 가능하기 때문에 바이트 코드 레벨에서 감사할 수 있는 사항들에 대하여는 제1 스마트 컨트랙트 감사부(110)에 의해 감사를 수행한다.

제1 스마트 컨트랙트 감사부(110)는 바이트 코드에 대한 감사를 수행하여 제1 감사 리포트를 생성한다(S4)

제2 스마트 컨트랙트 감사부(120)는 소스 코드(220)가 저장된 메모리로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장한다(S5).

제2 스마트 컨트랙트 감사부(120)는 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부를 감사한다(S6).

소스 코드에 대하여 SWC의 모든 취약점을 일일이 감사하는 것이 아니라, 제1 스마트 컨트랙트 감사부(110)에서는 다룰 수 없는 SWC의 취약점 항목만을 선별하여 감사를 수행함에 따라 소스 코드에 대한 감사가 훨씬 더 간편해진다.

또한, 제1 스마트 컨트랙트 감사부(110)의 감사만으로는 부족할 수 있는 부분에 대하여 제2 스마트 컨트랙트 감사부(120)의 감사가 수행됨에 따라 스마트 컨트랙트에 대하여 보다 완전한 감사가 가능해질 수 있다.

제2 스마트 컨트랙트 감사부(120)는 소스 코드에 대한 감사를 수행하여 스마트 컨트랙트의 취약점에 대한 제2 감사 리포트를 생성한다(S7)

취약점 리포트부(130)는 제1 스마트 컨트랙트 감사부(110)로 제1 감사 리포트를 수신하고, 제2 스마트 컨트랙트 감사부(120)로부터 제2 감사 리포트를 수신하고 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포할 수 있다(S8).

본 발명의 일실시예에서는 이더리움의 경우에 대하여 스마트 컨트랙트를 설명하지만, 본 발명은 이제 제한되지 않고 하이퍼레저와 그 외의 다양한 스크립트 언어를 제공하는 스마트 컨트랙트에 적절하게 변형하여 적용될 수 있다

이상에서 본 발명에 따른 실시예들이 설명되었으나, 이는 예시적인 것에 불과하며, 당해 분야에서 통상적 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 범위의 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 다음의 특허청구범위에 의해서 정해져야 할 것이다.

Claims

바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장된 바이트 코드를 상기 메모리로부터 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 제1 감사 리포트를 생성함에 의해, 바이트 코드 레벨에서 바이트 코드에 대한 감사처리를 수행하는 제1 레이어를 구성하는 제1 스마트 컨트랙트 감사부;
상기 제1 스마트 컨트랙트 감사부에서 누락될 수 있는 SWC 취약점에 대하여 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일되어 소스코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행하되, 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 소스 코드 스마트 컨트랙트의 취약점에 대한 제2 감사 리포트를 생성함에 의해, 소스 코드 레벨에서 소스 코드에 대한 감사처리를 수행하는 제2 레이어를 구성하는 제2 스마트 컨트랙트 감사부; 및
상기 제1 스마트 컨트랙트 감사부로부터 수신된 제1 감사 리포트와 상기 제2 스마트 컨트랙트 감사부로부터 수신된 제2 감사 리포트를 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하는 취약점 리포트부를 포함하는 다중 레이어 기반 스마트 컨트랙트 감사 장치.
청구항 1에 있어서,
상기 제2 스마트 컨트랙트 감사부는 SWC 분류중에 변수에 관련된 SWC 분류만을 선별하여 소스 코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 장치.
청구항 1에 있어서, 상기 제2 스마트 컨트랙트 감사부는 SSA(static single assignment) 기법을 이용하여 소스 코드를 읽어들여 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 장치.
스마트 컨트랙트 감사 장치가 분석할 스마트 컨트랙트를 수신하는 단계;
제1 스마트 컨트랙트 감사부가 바이트 코드가 저장된 스택으로부터 SSA(static single assignment) 기법을 이용하여 일괄적으로 읽어들여서 메모리에 평면 배열로 저장하는 단계;
상기 제1 스마트 컨트랙트 감사부가 메모리로부터 바이트 코드를 읽어들여서 취약점이 있는지 여부에 대한 감사를 수행하여 제1 감사 리포트를 생성함에 의해, 바이트 코드 레벨에서 바이트 코드에 대한 감사처리를 수행하는 제1 레이어를 구성하는 단계;
제2 스마트 컨트랙트 감사부가 상기 제1 감사 리포트를 생성하는 단계에서 누락될 수 있는 SWC 취약점에 대하여 스마트 컨트랙트 프로그래밍 언어 레벨에서 컴파일되어 소스코드로 저장된 스마트 컨트랙트에 대한 감사를 수행하되, 메모리로부터 소스 코드를 읽어들여서 취약점이 있는지 여부를 감사하여 소스 코드 스마트 컨트랙트의 취약점에 대한 제2 감사 리포트를 생성함에 의해, 소스 코드 레벨에서 소스 코드에 대한 감사처리를 수행하는 제2 레이어를 구성하는 단계; 및
취약점 리포트부가 상기 제1 감사 리포트와 상기 제2 감사 리포트를 취합하여 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하는 단계를 포함하는 다중 레이어 기반 스마트 컨트랙트 감사 방법.
청구항 4에 있어서,
상기 제2 감사 리포트를 생성하는 단계는 SWC 분류중에 변수에 관련된 SWC 분류만을 선별하여 소스 코드로 저장된 스마트 컨트랙트에 대하여 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 방법.
청구항 4에 있어서, 상기 제2 감사 리포트를 생성하는 단계는 SSA(static single assignment) 기법을 이용하여 소스 코드를 읽어들여 감사를 수행하는 다중 레이어 기반 스마트 컨트랙트 감사 방법.