[하이퍼레저 패브릭] CA,MSP,Identity Mixer 정리

 

이 글은  버전을 구분하지 않고 있으며 , 스스로가 공부하면서 메모식으로 두서 없이 정리/수정 하는 내용인지라 글 읽기가 힘들 수 있으며, 암호학 전문가가 아니기에 일부 오류룰 담고 있을 수 있음을 참고 하십시요.

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

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

1. 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 들이 구축된다. 즉 스스로 발급기관 역할도 한다는 것.

2.하이퍼레저 패브릭과 CA,MSP 

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

2-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 (intermediate CA) 를 만든다. 
 - Fabric-CA 는 고가용성을 위한 프록시가 front에 있는 클러스터로 구성하면 안정적이다.
 - Fabric CA에 접근해서 서비스를 받고 싶은 경우 Fabric-CA Client를 통하거나, Fabric SDK 를 통해서 이용 할 수 있다. 
 - Fabric-CA 는 주로 도커 이미지로 실행 되며, 설정파일을 통해 백엔드에 MySQL 같은 RDB 를 이용한다. 
 - Fabric CA 를 통해서는 아래와 같은 서비스를 제공 받을 수 있다.

• 각 조직,서비스등에 대한 신원 등록. LDAP 인증으로의 접속 매개.
   전체네트워크 범위 msp
   채널 범위 msp
   조직 자체의 msp
   조직 관리자의 msp
   조직 유저의 msp
   조직의 peer 의 msp 
• 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-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부터는 컨셉에서 사라진것으로 알고 있다. 대신 3번에서 소개 하는 Identity Mixer 가 사용된다. 

2-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 와 키 쌍을 출력 한다. 

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

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

2-5. MSP (ver1.0~)

  (Fabric 1.0 MSP)

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

 

•  전체네트워크 범위 msp
•  채널 범위 msp
•  조직 자체의 msp
•  조직 관리자의 msp
•  조직 유저의 msp

•  조직의 peer 의 msp  
  

자 그럼 이것이 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 셋업은 오더러에 채널에 대한 제네시스 블록 (오더러를 시작하기 위한 네트워크 범위의 제네시스 블록과는 다르다)을 포함하는것으로 시작한다. 

3. Identity Mixer 

신원보호(unlinkability, minimal attribute disclosure) 측면에서 TCert 방식의 비효율적인 문제점을 개선하기 위해 나온 기술로써 영지식증명을 활용한다. (Camenisch-Lysyanskaya (CL) signature scheme or BBS+으로 어떤 속성에 대해서 올바른 서명을 알고있다는 것을 실제 서명 자체를 노출하지 않고도 증명 할 수 있는 방식으로 Flexible public keys, Flexible credentials 라는 특징을 가지고 있다) 

기존의 ECert 즉 User에 대한 신원증명서는 x.509 형식으로 되어있으며 해당 정보는 CA로 부터 발급받는데 세부정보가 모두 노출되어 있다. 따라서 해당 신원증명서를 첨부하여 트랜잭션을 호출 할 시, 자신의 정보를 모두 노출시키는 프라이버시 침해가 발생할 소지가 있다. 그렇다고 해서 신원증명서의 일부분을 제거하고 보낸다면, CA가 서명한 sign 코드는 무용지물이 될 것이고.. 이것을 보완하고자 등장한 것이 Identity Mixer 이다.

이 녀석은 위에서 말한 신원증명서의 일부 내용을 감춰서 보내도, 검증자 입장에서 CA가 인증해준 증명서라는 것을 똑같이 검증 할 수 있다. 이때 User의 public key 또한 호출 할 때 마다 변경이 가능하니,여러모로 프라이버시가 강화되는 것이다. 즉 소속을 숨겼는데, 소속을 Verifier가 알 수 있다는 의미의 영지식증명은 아니고, attribute가 바뀌었는데도 불구하고, CA가 동일하게 증명 할 수 있다는 의미의 영지식증명이다. 즉 너의 속성중무엇이 바뀌었던간에 너라는 존재가 맞다는 것에 대한 증명이다.

Fabtoken 에서 UTXO 개념으로 소유권을 관리하는데, 매번 바뀌어지는 public key를 사용하여 처리하지 않을 까 추측한다. 

ECert / TCert 처럼 X.509 나 Certificate 라고 표현하지 않고, Credentials 라 표현하고 있다. 즉 서로 다른 것이다.

X.509형식의 인증서를 매번 받는게 아니라, 한번 받은 Credential로 부터 새로운 Presention Policy를 적용한 것을 이용해 트랜잭션을 보내고 있다. Verifier 는 CA의 공개키로 모든 것에 대해 검증 가능하다.

• Identity Mixer 크립토패키지는 발급자 키와 credentials 를 발급하고, presentation tokens를 생성하고 검증하며  key generation, signing, verification, zero-knowledge proofs 의 기능을 가지고 있다. (각 컴포넌트에서 가져다 사용하는 라이브러리라고 생각하면 된다. Fabric-CA처럼 단독실행서비스가 아니고, Fabric-CA에서도 가져다 쓰고, Java-SDK에서도 가져다 쓰는 라이브러리이다.)

• 기존의 CA 서비스는 Identity Mixer 크립토 패키지를 이용하여 ECert credentials 를 발급한다.  

• MSP는 Identity Mixer 크립토 패키지를 이용하여 트랜잭션에 대한 서명/검증을 수행한다. 

• 각기 다른 언어로 만들어진 Client SDK를 위한 Identity Mixer 크립토 패키지가 만들어지고 있다.
  
  

---

레퍼런스:

https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
https://www.blogsaays.com/configure-msp-hyperledger-fabric-blockchain/
https://hyperledger-fabric.readthedocs.io/en/release-1.2/idemix.html
https://walkingtree.tech/x-509-identity-mixer-hyperledger-fabric/