KR20200094618A - 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법 및 그 장치 - Google Patents

Abstract

본 발명의 일측면에 의하면, 블록체인 플랫폼상에서 수집된 스마트 컨트랙트 정보와 오픈 소스 Git 에 공개된 소스 코드를 저장하는 메모리, 스마트 컨트랙트 수집부, 특징 추출부, 취약점 그룹화부, 취약점 분류부, 및 동작 모드 제어부를 포함하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치가 제공된다.
본 발명에 의하면, 기존에 발생되었던 다양한 형태들의 취약점을 가지는 스마트 콘트랙트 코드들에 대해 특징점을 추출하고 분석 대상 스마트 컨트랙트와 유사도 분석을 수행한다. 유사도 분석 결과 클래스 X에 대해 임계점 Y를 넘게 되면 해당 분석 대상 스마트 컨트랙트는 클래스 X에 대해 취약함을 보이는 것으로 판단하고, 스마트 컨트랙트의 취약한 부분이 보완된 코드를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포함으로써 스마트 컨트랙트 개발, 또는 배포 시 소스 코드 내 발생 될 수 있는 취약점에 대해 빠르고 정확하게 파악하여 수정 보완할 수 있다.

Description

스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법 및 그 장치{METHOD FOR AUDITING SOURCE CODE USING SMART CONTRACT SIMILARITY ANALYSIS AND APPARATUS THEREOF}

본 발명은 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법 및 그 장치에 관한 것으로, 상세하게는 스마트 컨트랙트에서 발생되는 취약점들의 유사도 분석을 통해 정적, 동적 소스 코드 감사를 수행하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법 및 그 장치에 관한 것이다.

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

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

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

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

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

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

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

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

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

본 발명이 해결하고자 하는 과제는 기존에 발생되었던 다양한 형태들의 취약점을 가지는 스마트 콘트랙트 코드들에 대해 특징점을 추출하고 분석 대상 스마트 컨트랙트와 유사도 분석을 수행하고, 유사도 분석 결과 클래스 X에 대해 임계점 Y를 넘게 되면 해당 분석 대상 스마트 컨트랙트는 클래스 X에 대해 취약함을 보이는 것으로 판단하고, 스마트 컨트랙트의 취약한 부분이 보완된 코드를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포함으로써 스마트 컨트랙트 개발, 또는 배포 시 소스 코드 내 발생 될 수 있는 취약점에 대해 빠르고 정확하게 파악하여 수정 보완할 수 있는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법 및 그 장치를 제공하는데 있다.

본 발명의 일측면에 의하면, 블록체인 플랫폼상에서 수집된 스마트 컨트랙트 정보와 오픈 소스 Git 에 공개된 소스 코드를 저장하는 메모리, 스마트 컨트랙트 수집부, 특징 추출부, 취약점 그룹화부, 취약점 분류부, 및 동작 모드 제어부를 포함하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치가 제공된다.

스마트 컨트랙트 수집부는 학습 데이터를 구축하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집하거나 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집한다.

특징 추출부는 학습 데이터 구축 모드시에 수집된 취약점을 가지고 있는 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

한편, 특징 추출부는 취약점 감사 실행 모드시에 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

취약점 그룹화부는 학습 데이터 구축 모드시에 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다.

한편, 취약점 그룹화부는 취약점 감사 실행 모드시에 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다.

취약점 분류부는 취약점 감사 실행 모드시에 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단하고, 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포한다.

동작 모드 제어부는 학습 데이터 구축 모드와 취약점 감사 실행 모드를 수행한다. 이때, 취약점 그룹화부는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화한다.

동작 모드 제어부는 스마트 콘트랙트의 취약점을 분석함에 있어 스마트 콘트랙트의 주소를 입력받기 위한 사용자 인터페이스를 제공하거나, 오픈된 스마트 콘트랙트를 크롤링하여 새로 등장하는 취약점들에 대한 리포트를 하고 감사 엔진을 업데이트할 수 있다.

본 발명의 다른 일측면에 의하면, 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사를 위한 학습 데이터 구축 방법이 제공된다.

이를 위해, 스마트 컨트랙트 수집부에 의해, 학습 데이터를 구축하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집하거나 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집하는 단계가 수행된다.

특징 추출부에 의해, 학습 데이터 구축 모드시에 수집된 취약점을 가지고 있는 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하는 단계가 수행된다.

취약점 그룹부에 의해, 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하는 단계가 수행된다.

이때, 취약점을 그룹화하는 단계는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화한다.

본 발명의 또 다른 일측면에 의하면, 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법이 제공된다.

특징 추출부에 의해, 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하는 단계가 수행된다.

취약점 그룹화부에 의해, 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하는 단계가 수행된다.

취약점 분류부에 의해, 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단하고, 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포하는 단계가 수행된다.

여기에서, 취약점을 그룹화하는 단계는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화한다.

본 발명에 의하면, 기존에 발생되었던 다양한 형태들의 취약점을 가지는 스마트 콘트랙트 코드들에 대해 특징점을 추출하고 분석 대상 스마트 컨트랙트와 유사도 분석을 수행한다. 유사도 분석 결과 클래스 X에 대해 임계점 Y를 넘게 되면 해당 분석 대상 스마트 컨트랙트는 클래스 X에 대해 취약함을 보이는 것으로 판단하고, 스마트 컨트랙트의 취약한 부분이 보완된 코드를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포함으로써 스마트 컨트랙트 개발, 또는 배포 시 소스 코드 내 발생 될 수 있는 취약점에 대해 빠르고 정확하게 파악하여 수정 보완할 수 있다.

도 1은 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법을 설명하기 위한 도면이다.
도 2는 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치를 설명하기 위한 도면이다.
도 3은 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치에서 학습 데이터 구축 모드를 설명하기 위한 도면이다.
도 4는 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치에서 취약점 감사 실행 모드를 설명하기 위한 도면이다.

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

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

도 1은 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 기법의 개념을 설명하기 위한 도면이다.

도 1을 참조하면, 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 스마트 컨트랙트 감사 방법은 기존에 발생되었던 다양한 형태들의 취약점을 가지는 스마트 콘트랙트 코드들에 대해 특징점을 추출하고 분석 대상 스마트 컨트랙트와 유사도 분석을 수행한다.

유사도 분석 결과 클래스 X에 대해 임계점 Y를 넘게 되면 해당 분석 대상 스마트 컨트랙트는 클래스 X에 대해 취약함을 보이는 것으로 판단한다.

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

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

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

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

이더리움에서 스마트 컨트랙트는 새로운 스마트 컨트랙트를 생성하거나, 특정 스마트 컨트랙트상의 함수를 실행하거나, 이더를 전송하는 방식중의 하나로 실행이 된다. 또한 사용자 어카운트(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(가상머신)은 가상의 하드웨어를 소프트웨어 적으로 구현하여, 그 위에서 프로그램이 실행되도록 하는 것이다.

본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 스마트 컨트랙트 감사 방법은 스마트 컨트랙트 수집 단계(S100)와, 특징 추출 단계(S200)와, 취약점 그룹화 단계(S300), 및 취약점 분류 단계(S400)를 수행할 수 있다.

스마트 컨트랙트 수집 단계(S100)에서는 학습 데이터로 사용될 취약점을 가지는 스마트 컨트랙트를 수집하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트로부터 수집하거나 오픈 소스 Git 에 공개된 다양한 코드 형태들로부터 수집한다.

특징 추출 단계(S200)에서는 수집된 취약점을 가지는 스마트 컨트랙트에 대해 컴파일러에 의해 바이트 코드로 컴파일하고, 컴파일된 바이트코드를 기계어 형태로 변환한 뒤, 연산자와 피연산자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

취약점 그룹화 단계(S300)에서는, 벡터 공간에 저장된 취약점들에 대해 코사인 유사도를 통해 벡터간의 클래스 분류를 진행한다.

취약점 분류 단계(S400)에서는 분석을 원하는 스마트 컨트랙트를 입력받아 특징을 추출하고 취약점을 그룹화한 후에 해당 스마트 컨트랙트에 대해 위험 유무를 판단한다. 최종적으로 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포해줄 수 있다.

도 2는 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치를 설명하기 위한 도면이다.

도 2를 참조하면, 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치(100)는 스마트 컨트랙트 유사도 분석을 이용한 정적 소스 코드 감사 기법을 수행한다.

이를 위해, 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치(100)는 기존에 발생되었던 다양한 형태들의 취약한 형태의 스마트 콘트랙트 코드들에 대해 특징점을 추출하고 분석 대상 스마트 컨트랙트와 유사도 분석을 수행한다. 소스 코드 감사 장치(100)는 유사도 분석 결과 클래스 X에 대해 임계점 Y를 넘게 되면 해당 분석 대상 스마트 컨트랙트는 클래스 X에 대해 취약함을 보이는 것으로 판단한다.

본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치(100)는 메모리부(110)와, 스마트 컨트랙트 수집부(120)와, 특징 추출부(130)와, 취약점 그룹화부(140)와, 취약점 분류부(150)와, 동작 모드 제어부(160)를 포함하여 구성될 수 있다.

메모리부(110)는 블록체인 플랫폼상에서 수집된 스마트 컨트랙트 정보와 오픈 소스 Git 에 공개된 소스 코드를 저장할 수 있다.

스마트 컨트랙트 수집부(120)는 학습 데이터를 구축하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집하거나 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집할 수 있다. 이들 스마트 컨트랙트들은 다양한 취약점을 가지고 있다.

특징 추출부(130)는 학습 데이터를 구축하기 위해 수집된 취약점을 가지고 있는 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

또한, 특징 추출부(130)는 분석을 원하는 스마트 컨트랙트를 입력받아 특징을 추출한다. 이를 위해 특징 추출부(122)는 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

취약점 그룹화부(140)는 학습 데이터를 구축하기 위해 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다.

취약점 그룹화부(140)는 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다.

취약점 그룹화부(140)는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화할 수 있다.

취약점 분류부(150)는 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단한다.

취약점 분류부(150)는 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포할 수 있다.

동작 모드 제어부(160)는 학습 데이터 구축 모드와 취약점 감사 실행 모드를 수행한다.

동작 모드 제어부(160)는 스마트 컨트랙트 수집부(120)와, 특징 추출부(130)와, 취약점 그룹화부(140)를 제어하여 학습 데이터 구축 모드의 수행한다.

학습 데이터 구축 모드는 취약점을 가지고 있는 스마트 컨트랙트를 수집하여 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하고 특징을 추출한 후 코사인 유사도를 통해 벡터간의 클래스 분류를 진행하여 취약점을 그룹화한다.

동작 모드 제어부(160)는 특징 추출부(130)와, 취약점 그룹화부(140)와, 취약점 분류부(150)를 제어하여 취약점 감사 실행 모드를 수행한다.

취약점 감사 실행 모드는 분석을 원하는 스마트 컨트랙트를 입력받아 특징을 추출하고 취약점을 그룹화한 후에 해당 스마트 컨트랙트에 대해 위험 유무를 판단하고 스마트 컨트랙트의 취약한 부분이 보완된 코드를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포한다.

동작 모드 제어부(160)는 스마트 콘트랙트의 취약점을 분석함에 있어 스마트 콘트랙트의 주소를 입력받기 위한 사용자 인터페이스를 제공할 수 있다.

동작 모드 제어부(160)는 오픈된 스마트 콘트랙트를 크롤링하여 새로 등장하는 취약점들에 대한 리포트를 하고 감사 엔진을 업데이트할 수 있다.

취약점 그룹화부(140)는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화할 수 있다.

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 조건이 발생할 수 있다.

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

도 3은 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치에서 학습 데이터 구축 모드를 설명하기 위한 도면이다.

도 3을 참조하면, 동작 모드 제어부(160)는 학습 데이터 구축 모드를 실행모드로 실행한다.(S11)

학습 데이터 구축 모드가 실행되면, 스마트 컨트랙트 수집부(120)는 학습 데이터를 구축하기 위해 취약점을 가지고 있는 스마트 컨트랙트를 수집한다(S12)

구체적으로, 스마트 컨트랙트 수집부(120)는 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집할 수 있다. 스마트 컨트랙트 수집부(120)는 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집할 수 있다.

특징 추출부(130)는 학습 데이터를 구축하기 위해 수집된 취약점을 가지고 있는 각 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다(S13).

취약점 그룹화부(140)는 학습 데이터를 구축하기 위해 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다(S14).

이때, 취약점 그룹화부(140)는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화할 수 있다.

임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단된다.

동작 모드 제어부(160)는 그룹화된 취약점을 반영하여 학습 데이터를 업데이트하고, 그룹화된 취약점에 대한 리포트와, 오픈된 스마트 콘트랙트를 크롤링하여 새로 등장하는 취약점들에 대한 리포트를 하고 감사 엔진을 업데이트한다(S15).

도 4는 본 발명의 일실시예에 따른 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치에서 취약점 감사 실행 모드를 설명하기 위한 도면이다.

도 4를 참조하면, 동작 모드 제어부(160)는 취약점 감사 실행 모드를 실행한다.(S21)

취약점 감사 실행 모드가 실행되면, 특징 추출부(130)는 분석을 원하는 스마트 컨트랙트를 입력받아 특징을 추출한다(S22). 이를 위해 특징 추출부(122)는 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장한다.

취약점 그룹화부(140)는 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화한다(S23).

이때, 취약점 그룹화부(140)는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화할 수 있다.

취약점 분류부(150)는 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단한다(S24).

취약점 분류부(150)는 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포할 수 있다(S25).

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

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

Claims (5)

1. 블록체인 플랫폼상에서 수집된 스마트 컨트랙트 정보와 오픈 소스 Git 에 공개된 소스 코드를 저장하는 메모리;
   학습 데이터를 구축하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집하거나 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집하는 스마트 컨트랙트 수집부;
   학습 데이터 구축 모드시에 수집된 취약점을 가지고 있는 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하고, 취약점 감사 실행 모드시에 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하는 특징 추출부;
   학습 데이터 구축 모드시에 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하고, 취약점 감사 실행 모드시에 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하는 취약점 그룹화부;
   취약점 감사 실행 모드시에 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단하고, 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포하는 취약점 분류부; 및
   학습 데이터 구축 모드와 취약점 감사 실행 모드를 수행하는 동작 모드 제어부를 포함하되,
   상기 취약점 그룹화부는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치.
   
2. 청구항 1에 있어서,
   상기 동작 모드 제어부는 스마트 콘트랙트의 취약점을 분석함에 있어 스마트 콘트랙트의 주소를 입력받기 위한 사용자 인터페이스를 제공하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치.
   
3. 청구항 1에 있어서,
   상기 동작 모드 제어부는 오픈된 스마트 콘트랙트를 크롤링하여 새로 등장하는 취약점들에 대한 리포트를 하고 감사 엔진을 업데이트하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 장치.
   
4. 스마트 컨트랙트 수집부에 의해, 학습 데이터를 구축하기 위해 블록체인 플랫폼상에 배포되어 있는 스마트 컨트랙트중에서 취약점을 가지고 있는 스마트 컨트랙트를 수집하거나 오픈 소스 Git 에 공개된 소스 코드들로부터 취약점을 가지고 있는 스마트 컨트랙트를 수집하는 단계 ;
   특징 추출부에 의해, 학습 데이터 구축 모드시에 수집된 취약점을 가지고 있는 스마트 컨트랙트에 대해 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하는 단계; 및
   취약점 그룹부에 의해, 취약점을 가지는 다양한 스마트 컨트랙트로부터 추출되어 백터 공간으로 저장된 특징에 대하여 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하는 단계를 포함하되,
   상기 취약점을 그룹화하는 단계는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사를 위한 학습 데이터 구축 방법.
   
5. 특징 추출부에 의해, 분석을 원하는 스마트 컨트랙트를 입력받아 기계어 형태로 변환한 뒤, 연산자와 피연자로 나누어 특징을 추출하여 벡터 공간으로 저장하는 단계;
   취약점 그룹화부에 의해, 분석을 원하는 스마트 컨트랙트로부터 추출되어 벡터 공간으로 저장된 특징들에 대해 학습 데이터 구축 과정에서 추출되어 저장된 특징들과 코사인 유사도를 통해 벡터간의 클래스 분류(Class A, Class B, Class C.., Class X)를 진행하여 취약점을 그룹화하는 단계; 및
   취약점 분류부에 의해, 임의의 클래스 X에 대해 코사인 유사도가 취약성을 판단하기 위한 임계점 Y를 넘게 되면 해당 스마트 컨트랙트는 해당 클래스 X에 대해 취약함을 보이며 위험하다고 판단하고, 해당 스마트 컨트랙트에 대한 취약점 리포트와, 취약점이 보완된 스마트 컨트랙트를 제공하며, 사용자들의 선택을 통하여 자동 보완하여 배포하는 단계를 포함하되,
   상기 취약점을 그룹화하는 단계는 취약점 그룹화를 위해 SWC(smart contract weakness classification)를 기반으로 코사인 유사도를 통해 백터간의 클래스 분류를 진행하여 다양한 스마트 컨트랙트의 취약점을 그룹화하는 스마트 컨트랙트 유사도 분석을 이용한 소스 코드 감사 방법.

Images