‘이더리움 댑 개발’ 세미나 33. 12장. 12. Smart Contract Security

이번 세미나는 12장. Smart Contract Security의 내용을 포함한 이더리움 블록체인에서 솔리디티를 사용해서 컨트랙트를 작성할 때 고려해야 할 보안 전반적인 내용을 다룹니다.

생명이나 돈을 다루는 소프트웨어는 일반적인 업무를 다루는 소프트웨어와 같지 않습니다. 같은 수준의 문제에 대해 그 피해는 비교할 수 없을 정도로 클 수 있습니다. 대부분의 스마트 컨트랙트는 돈과 같은 가치를 갖는 코인과 토큰을 다룹니다. 따라서 우주항공이나 원자력이나 금융에서 요구하는 수준은 아니더라도 매우 주의를 기울여 개발해야 합니다.

스마트 컨트랙트는 배포 후 변경할 수 없다는 특징이 있기 때문에 더 주의를 기울여야 합니다. 배포 후에 문제가 발견되더라도 쉽게 대응하기 어렵습니다. 물론 업그레이드 가능한 컨트랙트를 만드는 방법이 있습니다. 하지만 이렇게 하려면 배포 전에 생태계 참여자들 사이에 합의가 이루어져야 합니다. 사실 변경가능한 컨트랙트를 만드는 것은 단순히 기술적으로 가능하느냐의 문제를 넘어 블록체인에 적합한 것인지에 대한 근본적 고찰이 필요합니다.

스마트 컨트랙트는 금융 소프트웨어와 마찬가지로 개발 과정에서 발생하는 버그도 신경써야 하지만 취약점을 이용한 공격에도 신경써야 합니다. 돈이 흘려다는 곳에는 그것을 탈취하려는 자들도 항상 꼬이기 마련입니다. 스마트 컨트랙트에 있을 수 있는 다양한 취약점들에 대해서 알고 대응할 수 있도록 해야 합니다. 아는 만큼 막을 수 있습니다.

대부분의 스마트 컨트랙트 보안 취약점은 이더리움 블록체인의 특성과 스마트 컨트랙트 언어(솔리디티와 같은)의 특성이 맞물려 발생합니다. 스마트 컨트랙트 개발자들이 이더리움 블록체인의 특성과 스마트 컨트랙트 언어의 특성을 깊이 알지 못하고 컨트랙트를 작성할 경우 공격자들의 좋은 먹이감이 된다는 것입니다.

스마트 컨트랙트 버그를 최소화하기 위해서는 개발 과정에서 테스트주도설계 기법을 사용하고, 배포 전에 다양한 테스트 기법들을 사용해서 철저한 테스트를 진행해야 합니다.

스마트 컨트랙트  보안 취약점을 해결하기 위해서 첫 번째로 보안 취약점이 발생할 수 있는 이더리움 블록체인의 특성과 스마트 컨트랙트 언어의 특성에 대해 철저히 알아야 합니다. 이미 발생했던 취약점들이 어떤 특성들을 노리고 있는지를 살펴보면 도움이 될 것 입니다. 두 번째로 취약점 별로 대응 패턴들을 만들고 적용해야 합니다.

배포 전 감사 절차를 거치는 것도 좋은 방법입니다. 체크리스트나 감사 소프트웨어를 사용해서 감사합니다. 내부 대응 만으로 충분하지 않을 수 있으니 외부 감사를 요청하거나 버그 바운티를 진행하는 것도 좋은 방법입니다.

 

본문 내용은 ‘마스터링 이더리움 9장. 스마트 컨트랙트 보안‘에서 자세하게 다룬 내용들입니다. 복습한다고 생각하고 읽습니다. 아래 요약한 내용을 다시 한 번 읽어 봅니다.

  • ConsenSys provides a list of common smart contract attacks that you should review when writing your smart contracts.
  • CryptoFin provides a great checklist for securing your smart contracts here.
  • Auditing Companies – Authio, Platform – Solidified
  • Free Auditing Resources
    • Echidna is a popular tool from Trail of Bits that provides unit tests and allows you to write tests for your contract. Trail of Bits also provides a long list of resources for smart contract auditing.

EVM 보강

EVM이 데이터를 쓰고 읽는 위치는 다양합니다.

  • 스택
    • 바이트 코드를 실행하는 동안 EVM 연산 코드들(opcodes)은 스택에 데이터를 push하거나 pop 합니다.
  • Calldata
    • 트랜잭션 데이터 필드가 저장되는 읽기 전용 위치입니다.
  • 메모리
    • 컨트랙트 함수 실행을 위한 메모리 위치로 함수 실행 동안에만 일시적으로 사용할 수 있습니다. 함수 실행이 끝나면 메모리는 클리어 됩니다.
  • Storage
    • 컨트랙트의 모든 함수에서 글로벌하게 사용할 수 있는 메모리 위치로 영속성을 갖습니다. 상태 변수는 storage를 사용합니다.
  • Code
    • 실행 코드가 저장되는 곳으로, static data storage location으로 사용될 수도 있습니다.
  • Logs
    • 컨트랙트로 부터 발생하는 이벤트의 출력이 저장되는 곳입니다.

 

컨트랙트 함수 실행을 위한 변수 값을 저장하는 위치는 calldata, 메모리, 스택, storage 입니다.

About the Author
(주)뉴테크프라임 대표 김현남입니다. 저에 대해 좀 더 알기를 원하시는 분은 아래 링크를 참조하세요. http://www.umlcert.com/kimhn/

Leave a Reply

*