출처

Nitin Guar, Hands-On Blockchain with Hyperledger, Packt Publishing Ltd(2018-06), p392-410

---

하이퍼레저 패브릭 보안

• 하이퍼레저 패브릭은 모듈화된 블록체인 구조임
• 하이퍼레저 패브릭은 허가된 사용자만 네트워크 안에 들어오게 함 –> 허가형 블록체인
• 모듈화 특성 때문에 배포를 다양한 형식으로 할 수 있음
• 이러한 다양한 모듈 특성 때문에 다양한 하이퍼레저 패브릭 보안을 생각해야 함
• 하이퍼레저 패브릭은 내부는 PKI 시스템이 있기 때문에 PKI가 가지는 보안 문제도 생각해야 함
• 여기서 다루는 보안 문제는 하이퍼레저 패브릭 1.1버전 기준임

이전 챕터에서 블록체인 네트워크를 설계하는 쪽의 보안 이슈를 다뤘는데 여기서는 더 넓고 깊게 하이퍼레저 패브릭의 보안 문제를 다룰 것이다.

이 챕터에서 다룰 내용

• 하이퍼레저 패브릭 보안 문제에 관한 설계 목표
• 하이퍼래저 페브릭 아키텍처 개요
• 네트워크 부트스트랩과 거버넌스 - 보안을 향한 첫 번째 단계
• 강력한 신원 - 하이퍼레저 패브릭 네트워크 보안의 핵심
• 체인코드 보안
• 흔한 보안 위협과 하이퍼레저 패브릭의 완화 방법
• 하이퍼레저 패브릭과 퀀텀 컴퓨팅
• GDRP 고려

---

하이퍼레저 패브릭 보안 문제에 관한 설계 목표

• 하이퍼레저 패브릭의 보안에 관해 이해하려면 설계 목표를 알아야 함

네트워크에 참여한 구성원(member)들은 새 구성원이 네트워크에 들어오는 방법을 결정해야 함

• 새 엔터티(entity)가 참여하려면 네트워크 내 다른 엔터티의 동의를 받아야 함 –> 허가형 블록체인의 기본 원칙
• 네트워크 구성원들은 반드시 정해진 하이퍼레저 패브릭의 정책에 따라 네트워크에 들어와야 함

네트워크 구성원들은 환경설정(configuration)/스마트 계약(smart contract) 방법을 정해야 함

• 네트워크 내 환경설정이나 배포, 스마트 계약의 인스턴스화의 변화는 네트워크 구성원들의 동의가 있어야 함
• 이 특징은 하이퍼레저 패브릭이 허가형 블록체인이라는 것을 보여줌

장부(ledger)와 장부에 연결된 스마트 계약(체인코드)은 프라이버시와 기밀 충족을 위해 관련 피어들 범주 안에서 행해져야 함

• 퍼블릭 블록체인은 모든 노드들이 블록체인의 장부를 가지고 있고 스마트 계약을 실행할 수 있음
• 기밀을 유지하고 구역을 정하기 위해서 피어들로 이루어진 몇 개의 그룹을 만들고 각 그룹마다 장부와 트랜잭션이 존재함
• 하이퍼레저 패브릭에서는 채널과 채널의 기밀 데이터로 구현이 됨
• 스마트 계약(체인 코드)은 정해진 범주의 장부를 업데이트 함

오직 채널에 참여하고 있는 구성원들만이 채널의 환경설정의 업데이트 방법을 결정한다.

스마트 계약 범용 언어로 작성될 수 있음

• 하이퍼레저 패브릭의 주 목표는 스마트 계약을 Go나 Javascript와 같은 범용 언어로 작성할 수 있게 하는 것
• 스마트 계약의 실행 전 검증과 배포를 대신하는 거버넌스나 절차가 없다면 다양한 보안 문제가 발생할 수 있음
• 기타 다른 원인으로 인해 범용 언어를 쓰는 것이 문제가 될 수 있음

트랜잭션 무결성이 보장되어야 함

• 트랜잭션은 스마트 계약을 실행하는 것
• 트랜잭션은 다른 피어들에 의해 변조되지 않아야 하고 트랜잭션 변조 시도도 잘 탐지하면서 생성되고 저장되어야 함
• 트랜잭션 무결성을 위해 암호학 과정이 있어야 함

산업 표준이 활용되어야 함

• 하이퍼레저 패브릭 시스템은 산업 표준이 쓰고 있는 디지털 신원을 활용해야 함
• 디지털 신원 확인으로는 X.509 인증서를 씀
• 피어들간의 통신으로는 TLS와 gRPC를 씀

트랜잭션 실행 및 검증을 합의와 구분해야 함

• 현존 블록체인 네트워크는 트랜잭션 실행 및 검증을 블록체인 노드들간의 합의와 합쳐버림
• 이렇게 합쳐버리면 합의 알고리즘을 마음대로 교체할 수가 없음

어디에나 탈착가능 해야 함

• 하이퍼레저 패브릭 시스템은 모듈화 된 디자인을 가지고 있음
• 각 모듈은 표준 인터페이스를 통해 탈착가능 함
• 모듈이 탈착 가능하게 되어 하이퍼레저 패브릭은 다양한 환경에서 유연하게 쓰임
• 탈착 가능한 점은 블록체인 네트워크에 여러 가지 인스턴스가 들어올 수 있게 된다는 것이고 이는 다양한 보안 문제를 생각해야 하게 됨

---

하이퍼래저 페브릭 아키텍처 개요¹

패브릭 CA 혹은 멤버십 서비스 프로바이더(MSP)

• 멤버십 서비스 프로바이더(membership service provider, MSP)는 피어들과 조직(organization) 내 사용자의 디지털 신원 생성을 담당함
• 채널안에 참여하려는 새로운 엔터티들에 관한 피어들의 신원은 네트워크 안에 설정되어 있어야 함
• 패브릭 CA는 MSP안에 있으며 네트워크에 사용자를 등록하고 X.509 인증서 발급 매커니즘을 제공함
• 패브릭 CA는 도커 컨테이너 안에서 실행됨
• 패브릭 CA 각각 백엔드 데이터베이스(보통 SQLite, 옵션을 주면 PostgreSQl, MySQL)안에 설정되어 있음
• 데이터베이스 안에는 등록된 신원들과 X.509 인증서도 있음
• 패브릭 CA는 사용자의 개인키는 저장하지 않음

피어

• 피어는 하이퍼레저 패브릭 네트워크에 참여하는 엔터티를 말함
• 피어의 신원은 MSP에 의해 만들어 짐
• 피어는 체인코드의 배포 및 인스턴스화, 장부 업데이를 함
• 피어는 다른 피어들과 트랜잭션에 담긴 비밀데이터를 갖고 상호작용을 함
• 피어는 순서화 서비스(ordering service)와 순서화 서비스가 실행하는 체인코드와 상호작용 함
• 패브릭 CA와 비슷하게 피어도 도커 컨테이너 안에서 실행됨

스마트 계약 혹은 체인코드

• 스마트 계약은 Go나 JavaSCript와 같은 고급 언어(high-level language)로 작성되어 있음
• 스마트 계약은 애플리케이션 논리를 작성하며 성공적으로 실행되면 데이터를 읽거나 씀
• 스마트 계약은 최종적으로 장부에 커밋을 함
• 스마트 계약은 장부에 직접적으로 접근하지 않음
• 도커 컨테이너 안에 있는 피어는 스마트 계약을 배포하거나 하지 않을 수 있음
• 피어는 다양한 버전의 스마트 계약을 배포할 수 있음

장부

• 각 피어들은 디지털 장부를 유지해야 함
• 디지털 장부에는 피어가 받은 트랜잭션의 커밋 기록을 담고 있음
• 하나의 키를 두고 새로운 값을 계속 기록하는 형태임
• 예전에 기록된 값 또한 장부 안에 계속 저장되어 있음
• 노드는 최신 값에 대한 쿼리를 효율적으로 제공하기 위해 키와 최신 값을 CouchDB에 저장해 놓음
• CouchDB를 하이퍼레저 패브릭 안의 월드 스테이트(world state)라고 함

피어는 참여하고 있는 채널 안에서만 블록을 받고 장부에 커밋할 수 있다. 피어는 여러 채널안에 있거나 아예 채널이 없을 수 있다.

기밀 데이터

• 하이퍼레저 패브릭 1.1부터 피어들은 기밀 데이터를 채널안에서 공유하고 싶은 피어들과 공유할 수 있음²

• 장부에 있는 블록들은 데이터의 해시 값만을 가지고 있으며 기밀 데이터는 장부가 아닌 기밀 데이터베이스에 저장 됨

순서화 서비스

• 순서화 서비스는 실행된 트랜잭션을 받고 블록에 합친 후 같은 채널 안 피어들에게 배포(broadcasting)하는 역할을 함
• 트랜잭션 블록을 받은 피어는 장부에 커밋하기 전에 검증을 함

• 이 피어는 한 채널에서 다른 채널로 가는 블록들이 섞이지 않게 순서화 서비스를 함

• 하이퍼레저 패브릭 1.0에서는 키와 read/write set으로 이루어진 값들로 이루어진 트랜잭션을 순서화 서비스에 보냄
• 순서화 서비스는 트랜잭션에 있는 모든 데이터를 볼 수 있는데 이는 기밀성을 지켜야 하는데 있어 영향을 줌
• 하이퍼레저 1.1에서는 클라이언트는 트랜잭션 데이터(입력, read/write set)의 해시를 순서화 서비스에 보낼 수 있음

• 순서화 서비스는 클라이언트로부터 받은 해시를 관련 피어들에게 보냄

• 현재 순서화 서비스는 Kafaka에 있으며 crash fault tolerant(CFT)를 씀(Byzantine Fault Tolerant(BFT)는 쓰지 않음)
• 하이퍼레저 패브릭은 합의 서비스가 탈착가능하기 때문에 이건 크게 중요한게 아님

• 탈착 가능하다는 것은 다른 합의 모델이 가능하기 때문

• 피어, 순서화 그리고 패브릭을 비롯한 하이퍼레저 패브릭 아키텍처를 위 그림에서 그렸음
• 그런데 새로운 hardware security modules(HSMs)³를 비롯한 새로운 암호화 알고리즘이 탈착 가능하며 암호 키 관리에 이를 쓸 수 있음

---

네트워크 부트스트랩과 거버넌스 - 보안을 향한 첫 번째 단계

• 기업에서 허가형 블록체인 네트워크를 구축하기 위해 하이퍼레저 패브릭을 사용한다고 치자
• 기업에서는 거버넌스 문제를 생각해야 할 것
• 거버넌스는 궁극적으로 네트워크의 보안을 결정하기 때문
• 거버넌스로 문제는 다음과 같이 있음

네트워크 부트스트랩을할 것인가 그리고 구성원들이 네트워크를 만들 수 있게 할 것인가?

• 네트워크 부트스트랩은 블록체인 네트워크 형성 첫 번째 단계
• 서로 다른 엔터티들은 네트워크를 생성하기 위해 합쳐질 것
• 엔터티들은 out-of-band⁴ 통신으로 구성원 집합과 거버넌스 정책 수립을 합의할 것

새 엔터티를 네트워크 혹은 채널에 참여시키는 절차는 어떻게 될까?

• 새 구성원을 네트워크에 참여시키는 정책을 정의하는 것은 네트워크에 대한 기업의 요구로 만들어 짐

누가 네트워크안에 있는 피어에게 체인코드를 배포하고 업그레이드할 것인가?

• 절차를 정의하는 것은 악의적인 체인코드가 하나 혹은 다수의 피어에게 설치되는 것을 막아야 하기 때문에 중요함

블록체인에 저장될 데이터 모델은 무엇인가?

• 구성원들은 블록체인에 저장될 동일한 데이터 모델을 합의해야 함
• 데이터 모델을 정의하는 것은 GDRP와 같은 형식을 지키기 위해서도 중요함

네트워크 생성

엔터티가 네트워크를 생성하고자 한다면 다음 두 가지를 고려해야 함

1. 누가 순서화 서비스를 실행할 것인가
2. 서로 다른 순서화 서비스는 네트워크에 몇 개를 둘 것인가?

• 순서화 서비스는 환경설정에 따라서 트랜잭션 해시나 트랜잭션 데이터를 전 체널에 아울러서 볼 수 있어 중요함
• 네트워크를 형성하는 엔터티들은 신뢰할 수 있는 엔터티를 순서화 서비스를 할 수 있도록 하게 해야 함
• 순서화 서비스를 실행하는 중립적인 제 3 그룹도 신뢰할지 말지 결정해야 함

순서화 서비스는 서비스를 시행하고 있는 채널들을 아울러서 모든 트랜잭션(해시 혹은 키/값 쌍)을 볼 수 있다. 따라서 피어들끼리 직접적으로 데이터를 교환하면서 순서화 서비스에게 제공하는 데이터를 숨기고 싶다면 read/write set의 해시를 보내야 한다.

• 순서화 서비스가 네트워크에 구축된다면 디지털 신원이 설정되어 있어야 함
• 환경설정은 순서화 서비스 제네시스 블록 안의 피어들의 디지털 인증서를 정하면서 설정됨
• 피어들 또한 순서화 서비스의 디지털 신원을 설정해야 함

새로운 구성원 추가하기

• 네트워크와 채널을 만든 개국공신 구성원들은 새 구성원이 네트워크와 채널에 어떻게 들어올지 정책을 만들어야 함
• 기본 정책은 다수결로 설정되어 있음
• 다른 정책을 설정할 수도 있음
• 새 구성원을 받아들이는 정책이 바뀌려면 기업간 합의가 필요함
• 기업간 합의가 되면 채널 환경설정에서 현재 정책은 새로운 정책으로 바뀔 수 있음

제네시스 블록을 생성하고 환경설정을 업데이트하는 것은 특권을 가진 명령으로 피어 관리자의 최종 승인을 받아야 한다.

체인코드의 배포와 업데이트

• 구성원이 채널에 참여하게 되면 체인코드를 배포하고 인스턴스화 함
• 체인코드는 채널안에서 한정된 키/값 쌍이 어떻게 배포되고 업데이트 되어야 할지 정해져 있음
• 체인코드는 보증 정책을 정의할 수 있음 –> 일부 혹은 모든 네트워크 안의 피어들의 디지털 서명이 필요할 수 있음
• 체인코드가 피어(보증 피어)에게 디지털 서명을 요구하려면 피어에 설치되어야 하며 인스턴스화 되어야 함
• 챕터 5와 챕터 7에 자세히 나옴
• 체인코드를 채널에 배포하기 전에 네트워크 구성원들이 체인코드가 정책을 잘 따르는지 봐야 함
• 이 절차는 관련 구성원들이 강제적으로 체인코드를 검토하도록 체인코드 거버넌스로 공식화할 수 있음

피어에 체인코드를 배포할 때 하나 하나 체인코드를 검토하고 체인코드 작성자의 디지털 신원을 확인하는 등의 절차를 세워야 한다.

데이터 모델

• 엔터티는 블록체인에 저장될 데이터 모델일 무엇으로 할지 합의해야 함 –> 체인코드로 정해짐
• 체인코드를 배포하는 네트워크 혹은 채널의 개국공신 구성원들은 채널에 저장될 키/값 쌍을 결정함
• 구성원들은 다른 구성원들과 어느 데이터를 공유할지 결정하고 어느 데이터를 기밀로 혼자 혹은 다른 구성원들과 가질지 결정함
• 데이터 모델은 기업이 원하는 기능에 유용하도록 만들어져야 함

데이터 모델이 어떻게 채널에 저장될지에 관한 절차를 만들어야 한다.

위에서 말한 것들을 요약하면 다음과 같음

1. 순서화 서비스를 누가 돌릴지 정해라
2. 순서화 서비스 안의 구성원들의 디지털 신원을 설정해라
3. 채널을 만들고 채널에 참여할 구성원에 관한 채널 정책을 만들어라
4. 체인코드를 쓰고 분산화하고 배포하고 인스턴스화하는 거버넌스를 정의해라
5. 데이터 모델을 정해라

---

강력한 신원 - 하이퍼레저 패브릭 네트워크 보안의 핵심

• 하이퍼레저 패브릭의 핵심은 강력한 신원임
• 신원을 만들고 관리하고 불러오는 것은 하이퍼레저 패브릭 기반의 배포의 명령 수행 보안에 있어 매우 중요함
• 신원은 MSP가 만듦
• 하나의 로컬 MSP는 하나의 피어와 연관됨
• MSP는 적절한 암호화된 신원을 발급함
• 하이퍼레저 패브릭은 X.509기반 인증서를 승인된 엔터티에게 발급하는 기본 MSP, 패브릭 CA를 지니고 있음

패브릭 CA 부트스트랩

• 패브릭 CA는 LDAP 서버로 설정되거나 독립(standalone) 모드 안에서 실행할 수 있음
• 독립 모드에서 실행한다면 패브릭 CA 데이터베이스에 저장된 부투스트랩 신원으로 설정되어야 함
• 기본적으로 SQLite 데이터베이스가 사용되는데 PostgreSQL이나 MySQL 데이터베이스도 사용할 수 있음

• 독립 서버가 사용된다면 패브릭 CA 서버와 데이터베이스는 TLS로 통신함

• 남은 챕터에서는 LDAP 서버를 사용하지 않고 엔터티를 부트스트랩하면 ca-admin이라고 지칭할 것

• LDAP 서버로 실행하지 않는다면 ca-admin과 패스워드는 패브릭 CA의 부트스트랩에 있어야 함

• ca-admin이 서버와 통신하고 X.509 인증서를 획득하려면 CSR(certificate signing request)을 패브릭 CA에 제출해야 함
• 이 절차는 enrolling an identity 혹은 enroll이라고 불림
• X.509 인증서를 획득하면 ca-admin은 다른 사용자들을 추가할 수 있음

root의 패스워드를 안전하게 보관해야 한다. root는 새로운 유저나 보안과 관련된 문제를 다뤄야 할 때를 제외하고는 쓰지 말아야 한다.

• 패브릭 CA는 register와 enroll 두 개의 중요한 명령을 제공함

Register

• Register 명령어는 새로운 엔터티를 패브릭 CA에 추가하는 것
• X.509 인증서를 만들지 않음 –> enroll 명령어가 만듦
• 패브릭 CA의 관리자가 정책과 절차를 정함

하이퍼레저 패브릭에서 register의 정책이 이메일 주소를 등록하는 것이라면 enroll 명령 수행시 이메일 주소가 인증서에 인코드되어 들어간다. 사용자가 트랜잭션을 발생시키면 이 인증서는 장부에 저장되며 트랜잭션에 커밋된다. 누구나 인증서를 디코드할 수 있고 이메일 주소를 확인할 수 있다.

패브릭 CA에 얼마나 엔터티들을 등록할 것인지 신중하게 결정해야 한다. 디지털 인증서들이 트랜잭션으로 발행될 때마다 장부로 들어가기 때문이다.

또 다른 중요한 사항은 얼마나 많은 enrollment를 허가해야 할지 정해야 한다는 것이다. 각 enrollment는 새로운 인증서를 발행해야 한다. 하이퍼레저 패브릭에서 새로운 사용자가 register되면 정해진 수의 enroll을 하거나 제한 없이 enroll을 할 수 있다. 보통 제한 없이 enroll을 해서는 안 된다.

enrollments에 제한을 두는 것이 좋다. 이 설정은 엔터티와 디지털 인증서를 1:1로 맞춰준다. 따라서 엔터티 관리가 쉬워진다.

하이퍼레저 패브릭 1.1에서는 registration에 엔터티의 특성을 정의할 수 있다. 이 특성은 X.509 인증서에 인코드 된다.

• 독립 모드에서 성공적으로 registration이 된다면 패브릭은 고유 암호를 줌
• ca-admin은 이 암호로 엔터티 registration에 쓰고 CSR과 enroll 명령어를 통한 인증서 획득에 사용할 수 있음

기본적인 패브릭 역할

• 엔터티를 패브릭 CA에 register한다면 엔터티는 역할들을 설정해야 함
• 패브릭 CA는 다음과 같은 기본적인 역할이 정해져 있음

hf.Registrar.Roles = client, user, peer, validator, auditor

• 패브릭 CA는 다음 중 하나의 역할에 해당하는 엔터티를 register 할 수 있음

hf.Registrar.DelegateRoles = client, user, validator, auditor

• 패브릭 CA는 다음과 같이 역할을 취소하게 할 수 있음

hf.Revoker = true

• 패브릭 CA는 중재 CA를 등록할 수 있음

hf.IntermediateCA

• 신원을 패브릭 CA에 register 하려면 엔터티는 hf.Registrar을 가져야 함
• 역할들은 “,”로 여러 개 적을 수 있음
• 호출자 신원의 affiliation은 같거나 접두사가 같아야 함
• 예) affiliation이 a, b이면 a.b.c로 등록할 수 있으나 a.c로 등록할 수 없음

Enroll

• 아이디와 비밀을 가지고 있는 엔터티는 패브릭 CA에 enroll할 수 있음
• enroll하면 공개/개인 키 쌍을 생성하고 CSR도 생성하고 이것들을 패브릭 CA에 보내는데 보낼 때 등록된 ID와 비밀을 Authorization헤더에 넣어 보냄
• 인증이 성공적으로 진행되면 서버는 X.509 인증서를 enroll된 엔터티에게 줌
• enroll 요청을 보낸 엔터티는 개인키를 관리해야 함
• 개인키들은 안전한 방법으로 저장되어 있어야 함

어떤 암호 프로토콜로 인증서 서명을 요청해야 할까

• CSR은 X.509 인증서와 키를 타원곡선 디지털 서명 알고리즘(ECDSA)로 만들 수 있음
• 다음 표가 지원하는 항목임

Size	ASN1 OID	Signature Algorithm
256	prime256v1	ecdsa-with-SHA256
384	secp384r1	ecdsa-with-SHA384
521	secp521r1	ecdsa-with-SHA512

신원 삭제

• CRLs(certificate revocation lists)로 삭제할 수 있음
• CSRLs는 모든 기업들과 연동되어 있어야 함

패브릭 CA에서 사용자를 관리를 위한 실질적인 고려사항

• 보통 기업들은 직원들을 관리하기 위한 각자 LDAP 서버를 가지고 있음
• 기업은 하나 이상의 패브릭 네트워크에 참여할 수 있지만 기업 직원들 중 일부만 각 네트워크에 참여 가능

• 각 네트워크의 패브릭 CA 관리자는 네트워크에 있는 직원들 중 일부를 등록하도록 선택할 수 있음

• 개인키와 인증서를 관리하는 책임은 직원에게 있음
• 따라서 직원에게 큰 부담이 가며 실수로 키를 노출할 수도 있음
• 이를 위해 기업이 직원들의 개인 키를 대신 저장해 줄 수 있음
• 개인 키의 저장은 보안 하드웨어를 통해 이루어짐