BlockChainConstruction

서문

이 글에서는 주로 주목할 만한 퍼블릭 체인 감사 측면 몇 가지를 소개합니다. 보안 감사자와 퍼블릭 체인 개발자에게 이는 참고하고 생각해 볼 가치가 있는 프로젝트입니다.

아키텍처

퍼블릭 체인 시스템의 구성을 소개하기 전에 블록체인의 아키텍처를 살펴보겠습니다:

블록체인 1.0 시대:

아키텍처: 아래 그림과 같습니다

대표 제품: bitcoin, reborn coin, dogcoin, Leyte coin, MasterCard coin 등

블록체인 2.0 시대:

아키텍처: 아래 그림과 같습니다

대표 제품: Ethereum, lisk, hyperledger 등

주요 변경 사항:

• 애플리케이션 계층: 스마트 계약 추가
• 인센티브 계층: 블록 시간을 16초로 단축
• 합의 계층: dpos, POS, pbft 추가
• 데이터 계층: 블록 확장, 데이터 및 변수 전송 지원, 최적화된 암호화 알고리즘과 Merkle 트리 사용

블록체인 2.0 시대

아키텍처: 아래 그림과 같습니다

대표 제품: EOS, VaR, AE, ash, ELA, dfinity

주요 변경 사항: 금융 산업 외 모든 분야에서 블록체인의 애플리케이션 시나리오가 더 복잡한 비즈니스 로직을 충족할 수 있습니다

보안 구축

다음으로 블록체인의 아키텍처에 따라 블록체인 퍼블릭 체인의 보안 구축에서 고려할 가치가 있는 문제들을 간략히 소개하겠습니다. 문제의 약 75%가 퍼블릭 체인 보안 문제를 야기했으며, 이는 퍼블릭 체인 보안 감사에서 주목할 만한 사항이기도 합니다. 여기서는 질문 형식으로 제시하여 우리의 사고를 환기시키고자 합니다. 더 논의하고 싶다면 issue에서 직접 진행할 수 있습니다：

데이터 계층

데이터 계층은 최하위 계층 기술로, 주요 기능은 데이터 저장, 계정 및 트랜잭션 구현과 보안입니다. 데이터 저장은 주로 Merkle 트리를 기반으로 하며, 블록과 체인 구조로 구현됩니다. 대부분은 kV 데이터베이스로 영속화되며, 예를 들어 비트코인과 이더리움이 채택한 leveldb가 있습니다.

데이터 계층에서 생각해 볼 가치가 있는 사항은 다음과 같습니다:

1. 퍼블릭 체인 블록의 데이터 구조 설계가 합리적인가?
2. 퍼블릭 체인 암호화 알고리즘이 암호학 요구 사항을 충족하는가?
3. Merkle 트리 설계가 합리적인가?
4. Merkle 트리 노드의 CRUD 설계가 합리적인가?
5. 퍼블릭 체인 블록 타임스탬프 검증 로직 설계가 합리적인가?
6. 퍼블릭 체인 데이터베이스 데이터 저장 및 데이터 CURD 보안?
7. 공개 키/니모닉 생성 알고리즘이 충분히 안전한가?
8. 공개 키/니모닉이 암호화되어 있는가?
9. 공개 키/니모닉에 오용/메모리 잔존물이 있는가?

네트워크 계층

네트워크 계층의 주요 목적은 블록체인 네트워크의 노드 간 정보 상호 작용을 실현하는 것입니다. 블록체인의 본질은 피어 투 피어(P2P) 네트워크입니다. 각 노드는 정보를 수신할 수 있을 뿐만 아니라 정보를 생성할 수도 있습니다. 노드들은 공통 블록체인을 유지함으로써 통신을 유지합니다. 블록체인 네트워크에서 각 노드는 새 블록을 생성할 수 있습니다. 새 블록이 생성되면 브로드캐스팅을 통해 다른 노드에 알려집니다. 반대로 다른 노드들은 해당 노드를 검증합니다. 블록체인 네트워크의 사용자 중 51% 이상이 검증을 통과하면 새 블록이 메인 체인에 추가됩니다.

네트워크 계층에서 생각해 볼 가치가 있는 몇 가지 사항이 있습니다:

1. 퍼블릭 체인 노드 발견 알고리즘 설계가 합리적인가?

2. 퍼블릭 체인 노드 설계가 합리적인가?

3. 처벌 메커니즘 설계가 합리적인가?

4. 통신 프로토콜 설계가 합리적인가?

5. 퍼블릭 체인 노드의 요청 처리 설계가 합리적인가?

6. 요청 처리 패킷 크기에 제한이 있는가?

7. 퍼블릭 체인 트랜잭션 통신 메커니즘 설계가 합리적인가?

8. 블록 데이터 동기화 메커니즘이 합리적인가?

9. 트랜잭션 처리 로직 설계가 합리적인가?

합의 계층

합의 계층은 분산 시스템에서 고도로 분산된 노드들이 블록 데이터의 유효성에 대해 합의에 도달할 수 있게 합니다. 실행 중인 모든 블록체인은 블록 출력의 유효성과 순서를 보장하기 위해 합의 알고리즘이 필요합니다. 일반적인 합의 알고리즘에는 pow, POS, dpos, Poa, POC 등이 있습니다.

합의 수준에서 다음 사항을 고려해야 합니다：

1. 퍼블릭 체인 합의 알고리즘 설계가 안전한가?

2. 퍼블릭 체인 합의 검증 설계가 합리적인가?

3. 퍼블릭 체인 합의 몰수 설계가 합리적인가?

4. 퍼블릭 체인 서비스 수수료 설계가 합리적인가?

5. 퍼블릭 체인 채굴 설계가 합리적인가?

6. 블록 난이도 동적 조정 설계가 합리적인가?

7. 블록 난이도 검사 로직 설계가 합리적인가?

8. 체인 재구성, 체인 리셋, 체인 포크 등의 설계?

인센티브 계층

퍼블릭 체인 인센티브 계층의 목적은 특정 인센티브 조치를 제공하여 노드들이 블록체인의 보안 검증에 참여하도록 장려하고, 블록체인 생태계의 균형과 건강한 발전을 보장하는 것입니다. 분산형 퍼블릭 체인에서는 규칙을 준수하는 참여 회계 노드들을 장려하기 위한 해당 인센티브 메커니즘을 설정하고, 규칙을 준수하지 않는 참여 회계 노드들을 처벌하기 위한 처벌 메커니즘을 수립해야 합니다. 블록체인의 인센티브 계층은 블록체인 기술 시스템에 경제적 요소를 도입하여 생태계 내 조직 협업과 가치 교환의 효율성을 향상시킵니다. 퍼블릭 체인의 인센티브 메커니즘은 블록체인의 선순환 발전을 보장하는 중요한 메커니즘입니다.

인센티브 수준에서 우리가 고려할 가치가 있는 몇 가지 사항이 있습니다:

1. 퍼블릭 체인 발행 메커니즘 설계가 합리적인가?

2. 퍼블릭 체인 처벌 메커니즘 설계가 합리적인가?

계약 계층

계약 계층은 블록체인 시스템의 다양한 스크립트 코드와 알고리즘, 그리고 그로부터 생성되는 더 복잡한 스마트 계약을 캡슐화합니다. 데이터, 네트워크, 합의의 세 계층이 블록체인의 기반 "가상 머신"으로서 각각 데이터 표현, 데이터 전파, 데이터 검증 기능을 담당한다면, 계약 계층은 블록체인 가상 머신을 기반으로 하는 비즈니스 로직과 알고리즘으로, 블록체인 시스템의 유연한 프로그래밍과 데이터 운영을 실현하는 기반입니다. 비트코인을 포함한 대부분의 디지털 암호화폐는 튜링 완전하지 않은 단순 스크립트 코드를 사용하여 트랜잭션 프로세스를 프로그래밍하고 제어하며, 이는 스마트 계약의 시초이기도 합니다. 기술의 발전에 따라 이더리움과 같은 튜링 완전한 스크립트 언어가 등장하여 더 복잡하고 유연한 스마트 계약을 실현할 수 있게 되었고, 블록체인은 거시적 금융 및 사회 시스템의 많은 애플리케이션을 지원할 수 있습니다.

계약 계층에 대해 다음 사항을 고려해야 합니다:

1. 계약 가상 머신 보안 설계?

2. 계약 배포 / 실행 / 인터페이스?

3. 스마트 계약 관련 보안?

애플리케이션 계층

애플리케이션 계층은 블록체인의 다양한 애플리케이션 시나리오와 사례를 캡슐화하며, 이는 컴퓨터의 다양한 소프트웨어 프로그램과 유사합니다. 일반 사용자가 실제로 직접 사용할 수 있는 제품이며, B / S 아키텍처 제품의 브라우저로 이해할 수도 있습니다.

애플리케이션 계층에 대해 다음 사항을 고려해야 합니다 (퍼블릭 체인만 해당, 지갑 App/Exchange/DEFI 등 제외):

계정 관련

1. 지갑 계정의 CRUD 로직 설계?

2. 지갑의 가져오기 및 내보내기 권한 검사?

3. 지갑 비밀번호 복잡성 설계?

4. 지갑 계정 주소의 유효성 검사?

RPC 관련

1. 공개 RPC 인터페이스에 외부 공용 네트워크가 필요한가?

2. 퍼블릭 체인 RPC 인터페이스 권한이 명확하게 구분되어 있는가?

3. 공개 RPC 인터페이스에 민감한 유형의 작업이 있는가?

4. 공개 RPC 인터페이스가 예외를 처리하는가?

5. 퍼블릭 체인 RPC 인터페이스의 최대 데이터 처리 한도?

6. 퍼블릭 체인 RPC 인터페이스 요청 데이터 인코딩 및 디코딩?

7. 퍼블릭 체인 RPC 요청 처리에 SSL이 활성화되어 있는가?

동시성 관련

1. 퍼블릭 체인의 고동시성 요청 처리 설계?

2. 최대 연결 수 설정?

3. 퍼블릭 체인 Web UI 인터페이스가 원격 액세스를 허용하는가?

4. 퍼블릭 체인 webui 인터페이스에 웹 유형 취약점이 있는가?

5. 퍼블릭 체인 webui 인터페이스가 비밀번호 정보를 로컬에 저장하도록 허용하는가?

코드 계층

실제로 퍼블릭 체인에는 "코드 계층"이 없습니다. 여기서 저자는 주로 퍼블릭 체인 개발 과정에서 고려해야 할 문제들을 분류하기 위해 이를 제안합니다:

1. 퍼블릭 체인 개발 언어 특성, 예를 들어 go 언어 데이터 읽기에서 readall (), append 특성

2. 퍼블릭 체인 개발 언어 버전, 예를 들어 일부 go 언어 버전에는 원격 명령 실행이 가능함

3. 퍼블릭 체인 개발 규범 코딩, 예를 들어 널 포인터, 슬라이싱, 예외 처리 등의 작업

4. 퍼블릭 체인 암호화 및 복호화 처리, 예를 들어 길이 검사 없는 고복잡도 인코딩 및 디코딩

5. 데이터 타입 변환 처리, 예를 들어 hextobyte, integer. Parseint() 등

6. 기본 비즈니스 로직 설계, 예를 들

기타 항목

위에서 언급한 블록체인 아키텍처 수준에서 고려할 가치가 있는 문제들 외에도 다음과 같은 보안 문제를 고려해야 합니다:

노드 보안

1. 데이터 저장이 암호화되어 있는가?

2. 파일 권한이 합리적인가?

3. 실행 환경이 안전한가?

4. 노드가 root로 시작되지 않는가?

5. 노드 측에 취약한 웹 서비스가 있는가?

6. 노드 서버 측에 안전하지 않은 구성이 있는가?

7. 노드 서버 측에 무단 액세스 취약점이 있는가?

8. 노드 서버 측에서 SSH 계정 비밀번호가 유출되었는가?

컴퓨팅 파워 공격

1. 51% 공격

2. 퍼블릭 체인의 하드 포크

3. 컴퓨팅 하이재킹 (웜이 채굴기를 감염시킴)

타사 라이브러리

Jackson databind, fastjson 등 취약점이 있는 타사 라이브러리를 사용하는지 여부

미들웨어

tendermint의 하위 버전과 같은 취약한 미들웨어 사용

크로스 체인 요구 사항

1. 크로스 체인 모드가 신뢰할 수 있고 적절한가?

2. 동형 크로스 체인 & 이형 크로스 체인 구현 방안?

3. 위 섹션의 안전 문제를 반복 확인

유지 관리

• Al1ex@Heptagram

토론

issue에서 관련 문제 논의에 직접 참여하십시오