관리 메뉴

HAMA 블로그

[하이퍼레저 패브릭 vs CORDA] 보안(CA,MSP 등) 정리 본문

블록체인

[하이퍼레저 패브릭 vs CORDA] 보안(CA,MSP 등) 정리

[하마] 이승현 (wowlsh93@gmail.com) 2018.08.21 10:51


이 글은  버전을 구분하지 않고 있으며 , 스스로가 공부하면서 두서 없이 정리/수정 하는 내용인지라 글 읽기가 힘들 수 있으며, 오류룰 담고 있을 수 있음을 확인해 주시길 바랍니다.  


이더리움을 위시한 퍼블릭 블록체인에서는 굳이 네트워크에 붙는 노드들에 대한 신뢰가 필요 없기 때문에, 이 글에서 설명 할 하이퍼레저 패브릭이나 코다에서 신뢰,허가 작업을 하기 위한 복잡한 CA 관련 기술이 필요 없습니다. 대신 이더리움은 아무나 참여하는 네트워크에 대한 신뢰를 다른 방식으로 추가 하기 위한 더 어려운 일에 도전하고 있는 상황입니다. 

이 글에서는 하이퍼레저 패브릭과 코다에서 네트워크에 참여하는 노드들의 신뢰,허가작업들이 어떤게 있는지 살펴보겠습니다. 실제 메뉴얼들은 이 글 보다 훨씬 방대한 내용을 담고 있으며, 특히 허가,보안 부분은 패브릭의 가장 어려운 내용이라 할 수 있겠습니다.  

하이퍼레저 패브릭을 처음 공부하시는 분들이라면 다음 링크를 참고 하십시요. 훌륭한 길라잡이가 될 것입니다. 
1.  [developerWorks 밋업] 프라이빗 블록체인 하이퍼레저를 공부해보자!
2.  한국IBM : Hyperledger Fabric 을 이용한 블록체인 시작하기 (공무제님)


CA (certificate authority)

인증 기관이라는 의미이다. 즉 내가 누구인지  혹은 이 웹싸이트가 누구인지 인증해 주는 기능을 하는 것을 말한다.예를들어 네이버에 접속한다고 치면, 사용자의 브라우저는 네이버 서버에 접속을 하게 될 것이다. 이때 중간에 무엇인가 접속 신호를 가로채서 이상한 서버로 접속 할 수도 있을텐데, 이때 브라우저는 자신이 접속한 서버가 네이버라는 것을 어떻게 알 수 있을까? 

답은 네이버는 자신이 네이버라는 이름이 적힌 종이(예를들어)를 브라우저 한테 보내준다. 그럼 "아~ 네이버가 맞네" 하고 받아드린다. 응?? 뭔가 어설프다. 그 종이가 진짜 맞는지를 확인(인증)해주는 무엇인가가 필요하지 않을까? 그때 CA가 필요해진다. 

여기서 공개키/비밀키에 대한 얘기를 먼저 해야겠다. 사실 이 글을 읽는 분들이라면 다 아는 것이라고 생각하지만 간단히 설명하자면, 누구든 자신의 공개키/비밀키 한쌍을 만들 수 있으며, 비밀키는 자신만 고히 간직하고, 공개키는 사람들에게 뿌린다. 이때 "안녕하세요" 라는 문서를 비밀키라는 것으로 변환시켜서 "114ae2" 라고 변경된다고 할 경우, "114ae2" 를 다시 "안녕하세요" 라고 변경하기 위해서는 공개키로 풀면된다. 이 얘기는 공개키로 풀어서 "안녕하세요" 가 나오지 않는다면 비밀키나 공개키가 잘못되었다는 것을 의미한다. 즉 엘리스가 밥에게 "사랑한다" 라고 편지를 보내며 자신의 비밀키로 변환시켜서 "224eaf3" 이 나왔다고하자. 엘리스는 "사랑한다" 라는 편지와 새로 생성된 "224eaf3" 를 중간대리자를 통해 밥에게 전달하면, 밥은 엘리스의 공개키로 "224eaf3" 를 풀었을때 "사랑한다" 가 나온다면, 아 진짜 엘리스가 보낸게 맞구나. 라고 인정할수있게 된다. 이는 부인방지가 될 수도 있는데, 엘리스 자신이 "사랑한다" 라고 보내놓고, "응 그거 내가 보낸거 아니야" 라고 부인할 수 없다는 뜻이다. 

이 공개키/비밀키는 위에 언급한 CA에서 적극적으로 사용되는데, CA의 공개키는 브라우저에 뿌려져서 누구나 가지고 있게 된다. CA의 비밀키로는 네이버가 적은 "내가 네이버야" 종이를 변환해서 "3232DASF3" 라고 변환시킨후에 이 둘을 브라우저에 보내면, 브라우저는 CA의 공개키로 "3232DASF3" 를 복구 할 때 "내가 네이버야" 라고 복구된다면 신뢰 할 수 있게 되는 것이다. 

끝!! ???

근데 여기서 딴지를 거는 센스있는 분들이 있을 수 있겠다. 그렇다.  CA의 공개키는 브라우저에 뿌려져서 누구나 가지고 있게 된다이게 문제인데. 그럼 그 CA라는 놈의 공개키는 어떻게 믿을 수 있냐? 라고 말 할 수 있는데, 그땐 그 CA의 상위 CA가 인증을 해 줄 것이다. ㅎㅎ 아래 이미지를 보자. 

제일 위의 Root CA 는 스스로 인증을 하며, 그 아래 CA들은 그 부모(상위) CA에 의해서 인증된다. 
대략 이런 메커니즘이 있다는 것을 이해하고 하이퍼레저와 CORDA의 CA에 대해 알아보자.
조금 다른 것은 위의 CA 설명에서는 네이버라는 서버에 대한 인증이었다. HTTPS 에셔 사용되는 인증은 이런 서버에 대한 것이고, 서버가 아닌 클라이언트 즉 모든 피어가 CA 에 의해서 인증 받아서 서로에 대한 신뢰를 구축 할 수도 있는데,  하이퍼레저와 CORDA 에서는 하나의 중앙 서버가 아니라, 모든 노드들이 자신들의 인증을 CA 를 통해서 받게 된다. 탈중앙화 아니던가!!! 

* 2017년에는 구글이 직접 Root CA 를 운영한다고 한다. 구글이라면 믿을 만 하지 ㅎㅎ 
* 하이퍼레저나 CORDA 에서는 자신의 인프라 안에서 Root CA 및 자식 CA 들이 구축된다. 즉 스스로 발급기관 역할도 한다는 것.


하이퍼레저 패브릭

하이퍼레즈 패브릭에서 
CA(인증 기관)는 사용자 등록, 블록체인에서 호출된 트랜잭션 블록체인의 사용자 또는 구성요소 간의 TLS 보안 연결과 관련이 있다.


1. 네트워크 구성 및 Fabric-CA (ver1.0~)

 
위의 그림은 일반적인 하이퍼레저 패브릭의 네트워크 구조도 이다. 아래와 같은 특성이 있다.

 - 먼저 CA 와 Fabric-CA 는 다른 것이니 혼동하지 말자. CA 는 간단히 말해 어떤것에 대한 증명 해 줄 수 있는 문서 목록이며, MSP를 통해 기관으로의 실시간 오퍼레이션을 하며, Fabric-CA 는 CA 기능에 관한 여러가지 오퍼레이션을 하는 서비스이다. 예를들어 cryptogen 유틸을 통해 CA 들을 구성 할 수 있으며, Fabric CA Server 를 통해서도 구성 할 수 있다. 
 - 전체 네트워크에는 중간 중간 마다 Fabric-CA 서비스가 있을 수 있다. (하나만 있어도 된다) 
 - 전체 네트워크의 CA 들의 Root CA 도 있다. 
 - 보통 조직마다 하나의 Root CA 를 만든다. 
 - Fabric-CA 는 고가용성을 위한 프록시가 front에 있는 클러스터로 구성하면 안정적이다.
 - Fabric CA에 접근해서 서비스를 받고 싶은 경우 Fabric-CA Client를 통하거나, Fabric SDK 를 통해서 이용 할 수 있다. 
 - Fabric-CA 는 주로 도커 이미지로 실행 되며, 설정파일을 통해 백엔드에 MySQL 같은 RDB 를 이용한다. 
 - Fabric CA 를 통해서는 아래와 같은 서비스를 제공 받을 수 있다.

  • 각 조직,서비스등에 대한 신원 등록. LDAP 인증으로의 접속 매개. 
  • Enrollment 인증서 발급 (ECerts 로써 아래 따로 설명함) 
  • 인증서 갱신 및 폐지 
개인적으로 아직 정확하게 cryptogen 과 Fabric-CA 의 기능상(API 갯수 및 능력)  차이점을 확인하진 않고 있으며 다음에 정리 할 예정이다. 일반적으로는 cryptogen 은 거의 모든 기반 cryptographic material 만들 수 있고, (미리 만들어 두고) 반면 Fabric-CA 는 PEER, USER, APP 에 대한 신원등록은 할 수 있으나, Orderer 는 아닌 것으로 알고 있으며,  Fabric-CA 는 주로 User (admin이나 일반) 의 신원 등록 (X.509 certificates) 를 동적으로  생성/저장/갱신/폐기 하기 위해 사용하고 있는 것으로 생각한다. 따라서 cryptogen 으로 만들 수 있는 것은 미리 만들어두고, 그 후로 Fabric-CA 를 사용하는 패턴을 활용하면 될 거 같다. 참고로 Fabric-CA 에는 User의 개인키를 저장해 두고 있진 않다. 더 자세한것은 이 링크를 참고하시라. -> Fabric CA User's Guide 

                                                         (Fabric 1.0 Fabric-CA)


2.  CA 계층도  (ver 0.6) 

패브릭의 CA 구조는 위의 그림과 같은데, 하나의 Root CA 로부터 가지쳐서 내려오며 상세 설명은 아래와 같다.

 - Enrollment CA 는 새로운 user 를 네트워크에 등록하는데 사용되는 CA 이다. 
 - Tranaction CA 는 등록된 사용자가 트랜잭션을 요청하는것에 사용되는 CA 이다.
 - TLS CA 는 사용자들이 원격피어와 통신을 할 때 보안 채널로써 활용된다. HTTPS 또한 TLS를 사용한다.
 - ECerts 는 CA 가 각각의 멤버 컴포넌트(사용자,서버서비스)들에게 등록에 사용하라고 발행 인증서 자체이다.RA에서 만들어진 개인증명서를 통해 발행 
 - TCerts 는 CA 가 사용자가 트랜잭션 요청에 사용하라고 발행하는 인증서 자체이다. ECert 를 통해 발행

각각의 CA 를 통해 각각의 ECerts / TCerts 가 최종 생성된다. 참고로 TCerts 는 1.x부터는 컨셉에서 사라진것으로 알고 있다.  대신 IDMixer 가 사용된다. 관련링크 ( https://jira.hyperledger.org/browse/FAB-2005)

3. 실제 네트워크의 허가/인증 관련 구성  (ver 1.0~)
first-network 예제의 cryptogen 유틸을 이용해서 생성된 디렉토리를 보면,

위 처럼 org1 이라는 조직에 대한 ROOT CA가 있으며, 즉 조직마다 CA가 생기며, 그 아래 peers, users 각각에 대한 MSP(와 조직 ROOT CA로 부터 생성된  CA) 가 존재하고 있음을 알 수 있다. 또한 각 폴더에 생긴 인증서파일인 .pem 을 열어보면

 

위처럼 org1 이라는 이름의 조직을 대표하는 CA가 있고,그것은 스스로 서명을 하는 Root CA로 작동하고 있으며, 그것을 이용하여 아래와 같이 peer0,Admin,orderer 각각의 인증서가 만들어진 모습을 볼 수 있다,

이런 인증서를 기반으로 Fabric CA 서버/클라이언트를 통해 각각의 ECerts / TCerts 가 최종 생성 될 것이다.
참고로 fabcar 예제의 enrollAdmiin.js 과 registerUser.js 를 실행시키면 프로젝트의 루트에 있는  hfc-key-store 디렉토리에 아래와 같이 admin과 User에 대한  eCert 와 키 쌍을 출력 한다. 

4.  Tranaction Certificates 요청 프로세스 ( ver 0.6 )
 

트랜잭션시 사용되는 TCerts 인증서가 사용되는 과정에 대해 좀 더 디테일하게 살펴 볼 수 있는데,
자세한 설명은 이 링크를 참고 하시라~ https://rezamtfabric.readthedocs.io/en/stable/protocol-spec.html
이 부분은 (실험버전) 으로 지금(1.2버전)에서과 많이 다르지만, 설명이 너무 자세해서 읽어볼만 하다.



4. MSP (ver1.0~)

  (Fabric 1.0 MSP)

MSP (Membership Service Provider)는 이름 그대로 멤버쉽 서비스에 대한 아키텍처의 추상을 제공하는 목적의 컴포넌트이다. 인증서를 발급하거나 검증하고 사용자 및 서비스의  신원에 대한 작업과 관련된 일을 한다는 의미이다. 조직마다 보통 하나의 MSP가 있으며 MSP ID로 구분된다. 추가 정보로 MSP는 조직마다의 로컬의 범위에도 존재하고, 채널에 들어가고 싶은 각 PEER에도 존재 한다. 


자 그럼 이것이 Fabric CA와는 무엇이 다른 것일까? 

fabric의 표준 심플인 
fabric-samples/first-network 에서는 cryptogen 유틸을 통해 MSP가 작동하기 위한 초기 정보들을 제공해 주고 있다. 아래 그림과 같이 조직마다 CA (Fabric CA 서비스가 아니다) 와 MSP 를 가지고 있는 모습이다. 조직마다 생성된 CA 와 MSP 는 전체 네트워크에 정보가 공유 되어 서로 검증하는데 사용 될 수 있다. 참고로 cyrptogen 을 이용하지 않고 fabric-CA 를 이용해서 생성 할 수도 있으며 (Orderer 제외),fabric-CA 는  fabric-ca-server init  명령어를 통해서 디폴트로 fabric-ca-server-config.yaml  환경파일을 생성하며 디비설정등을 할 수 있으며, cryptogen 유틸은 crypto config.yaml 설정파일을 이용한다. 


여기서 알 수 있는 것이 MSP,CA는 조직이 가지고 있어야 하지만, Fabric-CA 는 없어도 된다.(근데 실제 서비스에서는 없을 수가 없다)  cryptogen 을 통해서 조직이 사용할 각종 신원증명 매터리얼 들을 MSP의 초기화에 제공해 주면 되는 것이다. (실제 서비스에서는 이렇게 하긴 좀 머하지 않을까?) 반대로 cryptogen 없이 Fabric-CA 를 통해서 그런 신원증명 매터리얼을 만들 수도 있다.  즉 Fabric-CA 는 어떤 기본 정보를 제공해 주는 것이고, MSP 는 그 정보를 통해서 실제 어떤 오퍼레이션을 하는 것이라고 볼 수 있을 것이다. 

따라서 Fabric-CA 는 전체 네트워크에 하나만 있어도 되고, 여러개 있어도 되는 것이다. (글 초반에 말한것처럼 보통 한개가 HA로 구성되어 있을 것이다)


* 이 글을 쓸 현재는 Fabric CA 서버를 통해 생성된 사용자의 enrollment certificate (eCert)  fabcar 예제에서는 hfc-key-store 에 저장되는데, 이것들이 MSP와 어떤 연관관계를 가지고 고 있는지는 불명확하다. 실제 MSP 폴더를 열어보면 cryptogen 으로 부터 생성된 CA 정보들(조직의 root CA, PEER CA, USER CA, ORDERE CA,TLS CA)이 존재하는데 혹시나 MSP 가 enrollment certificate (eCert) 도 관여하는지는 잘 모르겠다. Fabric-CA 서버를 통해 만들어진 enrollment certificate (eCert)  가 사용시 이것을 검증하기 위한 CA로써의 역할을 MSP 가 하지 않을까 추측하고는 있다. 


체인코드에서의 MSP 사용 

하이퍼레저 패브릭의 체인코드적으로 MSP 를 말하자면 "어떤 조직에 속 할 경우" 에만 "어떤 체인코드의 메소드를 호출" 할 수 있는 권한을 부여하게 하는 역할을 한다. 실제 예를 생각해 보자, 개인들은 자신의 바이오인포매틱스 정보를 제공하고, 병원은 개인들의 의료정보를 저장하고, 연구조직에서는 해당 정보들을 가져다가 분석한다고 해보면, 각자의 그룹들이 나누어 질 것이며, 해당 그룹들은 체인코드(스마트 컨트랙트)의 모든 메소드를 호출 할 수는 없을 것이다. 즉 자신의 그룹과 관련된 메소드만 호출 할 수 있을 것인데, 그럼 개인들은 어떤 메소드만을 호출 할 수 있을까? 뭐 uploadPersonalData(....) 같은 것이겠지 않을까? 연구조직이라면 GetSomeKindOfPersonsBloodInfo(....) ? 

// 조직의 전용 mspID 와 certCN 을 통해서 확인하여, 호출 할 수 있는 조직을 경우에만 호출하게 제한한다. func authenticateExportingEntityOrg(mspID string, certCN string) bool {
return (mspID == "ExportingEntityOrgMSP") && (certCN == "ca.exportingentityorg.trade.com")
}

Hyperledger fabric 소스코드에서의 MSP 설명. 


Hyperledger Fabric 의 MSP api 란? 

하이퍼레저패브릭 네트워크에 참여하는 클라이언트나 피어들에게 (익명의) 증명서를 제공하기 위한 시스템의 추상 api 인터페이스이다.

클라이언트는 이 증명서를 트랜잭션을 위해 사용하며, 피어들은 보증에 대한 트랜잭션 프로세싱의 결과를 인증하기 위해 사용한다. 
이 인터페이스는 멤버쉽 서비스 컴포넌트 정의를 위해 사용되며, 이것을 통한 구현들은 코어 트랜잭션 프로세싱 컴포넌트의 수정없이 자연스겁게 플러그인 될 수 있을 것이다.이 소스파일은 MSP 인터페이스를 포함하고 있으며, MSPManager 는 MSPs 의 매니저를 정의하는 인터페이스이다. MSP를 호출하거나 라우팅하기 위한 매개객체로 행동한다. 

소스를 잠시 감상해보자. 

type MSPManager interface {
// IdentityDeserializer interface needs to be implemented by MSPManager
IdentityDeserializer
// Setup the MSP manager instance according to configuration information
Setup(msps []MSP) error
// GetMSPs Provides a list of Membership Service providers
GetMSPs() (map[string]MSP, error)
}

// MSP is the minimal Membership Service Provider Interface to be implemented
// to accommodate peer functionality
type MSP interface {
// IdentityDeserializer interface needs to be implemented by MSP
IdentityDeserializer
// Setup the MSP instance according to configuration information
Setup(config *msp.MSPConfig) error
// GetVersion returns the version of this MSP
GetVersion() MSPVersion
// GetType returns the provider type
GetType() ProviderType
// GetIdentifier returns the provider identifier
GetIdentifier() (string, error)
// GetSigningIdentity returns a signing identity corresponding to the provided identifier
GetSigningIdentity(identifier *IdentityIdentifier) (SigningIdentity, error)
// GetDefaultSigningIdentity returns the default signing identity
GetDefaultSigningIdentity() (SigningIdentity, error)
// GetTLSRootCerts returns the TLS root certificates for this MSP
GetTLSRootCerts() [][]byte
// GetTLSIntermediateCerts returns the TLS intermediate root certificates for this MSP
GetTLSIntermediateCerts() [][]byte
// Validate checks whether the supplied identity is valid
Validate(id Identity) error
// SatisfiesPrincipal checks whether the identity matches
// the description supplied in MSPPrincipal. The check may
// involve a byte-by-byte comparison (if the principal is
// a serialized identity) or may require MSP validation
SatisfiesPrincipal(id Identity, principal *msp.MSPPrincipal) error
}


MSP 정리 

- MSP 는 멤버쉽 오퍼레이션을 위한 추상층을 제공한다.
- MSP 추상층은 인증서 발생/검증 및 사용자인증에 관련된 암호적 메커니즘에 관련된 프로토콜이다. 
- 각 MSP 는 이름/ID 가 있어야 한다. 그 이름을 토대로 해당 멤버쉽 룰을 따르기 때문.
- 시스템 레벨에서는 채널생성, 채널레벨에서는 읽기/쓰기 컨트롤, 체인코드레벨에서는 함수호출제한 역할을 한다.
- 디폴트 MSP가 구현되어 있는데, RFC5280 에 따라서 다음 요소들이 포함한다.
ㅇ ROT 를 위한 
셀프 사인드 인증서 (X.509)
ㅇ intermediate CAs 의 X.509 인증서 리스트 (ROT를 바라봐야한다) 
ㅇ Organizational Units 리스트 
ㅇ ertificate revocation lists (CRLs) 리스트 
ㅇ 자가사인된  TLS ROT 
ㅇ intermediate TLS CAs 의 X.509 리스트 

MSP가 돌아가기 위한 기본 암호적 요소( signing keys and certificates) 들을 만들기 위해  “Cryptogen tool”  과 Fabric CA를 이용한다.
- MSP 를 셋업하기 위해 PEER & ORDERE 에는 6개의 서브폴더와 파일이 있어야 한다. (위에 폴더구성그림 참고)
- 노드의 설정파일을 셋업하는 동안 mspconfig폴더와 노드의 MSP의 MSP indentifier 패스를 설정해줘야한다.peer 를 위한 mspConfigPath 그리고 orderer 를 위한 LocalMSPDir 
- 채널에 대한 MSP 셋업은 오더러에 채널에대한 시스템 제네시스 블록을 포함하는것으로 시작한다. 

CORDA

Corda 네트워크는 아래와 같은 4가지 타입의 CA 를 가지고 있다. 

  • The root network CA

  • The doorman CA

  • The node CAs

  • The legal identity CAs

다음과 같은 주요 내용이 있다. 

  • Doorman 인증서는 네트워크 루트에 의해 발행 된다.  
  • Well-known 서비스 신원 인증서는 Doorman 인증서와 함께 포함된 엔터티에 의해 발행 된다. 
  • Node CA 인증서들은 Doorman 인증서와 함께 포함된 엔터티에 의해 발행 된다. 
  • Well known 법적(legal)  identity/TLS 인증서는 node CA에 의해 표시된 인증서에 의해 발행 된다.
  • 비밀 legal identity 인증서는 Well known 법적(legal)  identity에 의해 표시된 인증서에 의해 발행 된다.

참고로 

doorman 은 네트워크에 참여하려는 노드들에 대한 허가에 관여 한다. 모든 노드들은 Doorman  서비스에 요청된 정보를 제공해야하며, 허락이 떨어진경우에 한해 root-authority-signed TLS 인증서를 받게 된다. 이 인증서는 다른 참가 노드와의 통신에서 자신을 증명하는데 사용 된다. 


Q/A 

질문) 패브릭 기반 서비스를 백만명 이상 사용하게 하는 것이 가능한가요? MSP가 참여자 모두에게 CA 인증을 하게 되는지요?

답변)
성능상 User 100만이라는 지표는 별 문제 되지 않을 거 같으나 운영상으로는 말이 안된다고 생각 하는게 장부에 백만명의 기록을 저장해 두는 것과, 네트워크에 백만명을 참여시키는것과는 완전히 다른 이야기죠. 기술적으로는 일단 모든 User 는 해당 조직의 MSP의 제어권에 (MSP의 기본 6개폴더중하나) 스스로를 대표하는 기본 암호적 키를 만들게 될 것 이고, Enrollment 를 위한 인증서를 Enrollment CA 를 통해서 Ecerts 를 발부 받아서 네트워크에 참여하게되는 것으로 알고 있습니다. 실제로 fabcar예제를 보면 Fabric CA 서버를 통해 생성된 사용자의 enrollment certificate (eCert) 가 hfc-key-store 에 저장되는데, 이것들과 별개로 해당 조직의 user 디렉토리안의 msp폴더에는 다른 pri/pub 키가 있죠. (참고로 그것은 crypto-config.yaml 선언에 따라서 cryptogen툴에 의해 만들어진것)



레퍼런스:

Hyperledger fabric 
https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
https://rezamtfabric.readthedocs.io/en/latest/https://www.blogsaays.com/configure-msp-hyperledger-fabric-blockchain/

CORDA 
https://docs.corda.net/permissioning.html

0 Comments
댓글쓰기 폼