Hyperledger Fabric CA / MSP

Updated:

CA(Certificate Authority)

인증 기관이라는 의미이다. 즉 내가 누구인지 혹은 이 웹싸이트가 누구인지 인증해 주는 기능을 하는 것을 말한다.

Hyperledger Fabric - CA

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

Hyperledger Fabric - CA Network

image

먼저 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 인증으로의 접속 매개.
    • Enrollment 인증서 발급 (ECerts 로써 아래 따로 설명함)
    • 인증서 갱신 및 폐지

Hyperledger 실제 네트워크 허가/인증 구성

peer

peerOrganizations
    ├── org1.example.com
    │   ├── ca
    │   │   ├── 44f4e56b8b5463659acaf69d8b4eaf833c42d9a0dc8be8f82870faacbe8aab25_sk
    │   │   └── ca.org1.example.com-cert.pem
    │   ├── msp
    │   │   ├── admincerts
    │   │   ├── cacerts
    │   │   │   └── ca.org1.example.com-cert.pem
    │   │   ├── config.yaml
    │   │   └── tlscacerts
    │   │       └── tlsca.org1.example.com-cert.pem
    │   ├── peers
    │   │   ├── peer0.org1.example.com
    │   │   │   ├── msp
    │   │   │   │   ├── admincerts
    │   │   │   │   ├── cacerts
    │   │   │   │   │   └── ca.org1.example.com-cert.pem
    │   │   │   │   ├── config.yaml
    │   │   │   │   ├── keystore
    │   │   │   │   │   └── 6f864251953ca4dc4149bd14dd46ee2012bf521d282d262416e953c0d16149d2_sk
    │   │   │   │   ├── signcerts
    │   │   │   │   │   └── peer0.org1.example.com-cert.pem
    │   │   │   │   └── tlscacerts
    │   │   │   │       └── tl  a.org1.example.com-cert.pem
    │   │   │   └── tls
    │   │   │       ├── ca.crt
    │   │   │       ├── server.crt
    │   │   │       └── server.key
    │   │   └── peer1.org1.example.com
    │   │       ├── msp
    │   │       │   ├── admincerts
    │   │       │   ├── cacerts
    │   │       │   │   └── ca.org1.example.com-cert.pem
    │   │       │   ├── config.yaml
    │   │       │   ├── keystore
    │   │       │   │   └── 1e3f97b9dd0794e760509f17ec803b5c0dafa189239fe85b2996bf3e1b4e8965_sk
    │   │       │   ├── signcerts
    │   │       │   │   └── peer1.org1.example.com-cert.pem
    │   │       │   └── tlscacerts
    │   │       │       └── tlsca.org1.example.com-cert.pem
    │   │       └── tls
    │   │           ├── ca.crt
    │   │           ├── server.crt
    │   │           └── server.key
    │   ├── tlsca
    │   │   ├── ec2a9c11f847eddd3d7f7d9736d7e7a4b57c4e2c611043fac5f598a9de7b4861_sk
    │   │   └── tlsca.org1.example.com-cert.pem
    │   └── users
    │       ├── Admin@org1.example.com
    │       │   ├── msp
    │       │   │   ├── admincerts
    │       │   │   ├── cacerts
    │       │   │   │   └── ca.org1.example.com-cert.pem
    │       │   │   ├── config.yaml
    │       │   │   ├── keystore
    │       │   │   │   └── de6985a304a73fe39f47efcfa5148c0ee624556189f7041006b9d81d4ca01645_sk
    │       │   │   ├── signcerts
    │       │   │   │   └── Admin@org1.example.com-cert.pem
    │       │   │   └── tlscacerts
    │       │   │       └── tlsca.org1.example.com-cert.pem
    │       │   └── tls
    │       │       ├── ca.crt
    │       │       ├── server.crt
    │       │       └── server.key
    │       └── User1@org1.example.com
    │           ├── msp
    │           │   ├── admincerts
    │           │   ├── cacerts
    │           │   │   └── ca.org1.example.com-cert.pem
    │           │   ├── config.yaml
    │           │   ├── keystore
    │           │   │   └── 93342538b0e99178a85a201c3eeec0539fe2f2b4703cb3ac1f67cea213a65a2e_sk
    │           │   ├── signcerts
    │           │   │   └── User1@org1.example.com-cert.pem
    │           │   └── tlscacerts
    │           │       └── tlsca.org1.example.com-cert.pem
    │           └── tls
    │               ├── ca.crt
    │               ├── client.crt
    │               └── client.key
    └── org2.example.com

orderer

ordererOrganizations
│   └── example.com
│       ├── ca
│       │   ├── 3d2aab44e999e3410898f46535549081add84e51cc7d15f13458a906a56d243e_sk
│       │   └── ca.example.com-cert.pem
│       ├── msp
│       │   ├── admincerts
│       │   ├── cacerts
│       │   │   └── ca.example.com-cert.pem
│       │   ├── config.yaml
│       │   └── tlscacerts
│       │       └── tlsca.example.com-cert.pem
│       ├── orderers
│       │   ├── orderer2.example.com
│       │   │   ├── msp
│       │   │   │   ├── admincerts
│       │   │   │   ├── cacerts
│       │   │   │   │   └── ca.example.com-cert.pem
│       │   │   │   ├── config.yaml
│       │   │   │   ├── keystore
│       │   │   │   │   └── 3134afcb58cf3ef8c6aeffdc77ef8cb4b40d6a7af7c97367dcbb0e3dfb2cd2d4_sk
│       │   │   │   ├── signcerts
│       │   │   │   │   └── orderer2.example.com-cert.pem
│       │   │   │   └── tlscacerts
│       │   │   │       └── tlsca.example.com-cert.pem
│       │   │   └── tls
│       │   │       ├── ca.crt
│       │   │       ├── server.crt
│       │   │       └── server.key

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

다음과 같은 정보를 알 수 있습니다.

$ openssl x509 -text -noout -in ca.org1.example.com-cert.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7f:7a:5a:d3:19:5e:93:85:16:be:46:39:d1:08:97:67
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
        Validity
            Not Before: Oct 27 10:23:00 2019 GMT
            Not After : Oct 24 10:23:00 2029 GMT
        Subject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:e9:62:9a:cd:1c:e2:e7:b1:0c:ca:d9:c5:db:4a:
                    8d:a6:e7:b7:89:b0:e0:fc:3b:8b:5c:8d:22:62:92:
                    6e:98:d2:e5:35:d4:1f:ba:17:29:82:a5:73:ef:f9:
                    8f:e3:93:42:b2:9f:4b:55:93:47:b2:ef:17:09:1f:
                    0e:42:6a:04:47
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                44:F4:E5:6B:8B:54:63:65:9A:CA:F6:9D:8B:4E:AF:83:3C:42:D9:A0:DC:8B:E8:F8:28:70:FA:AC:BE:8A:AB:25
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:2c:ac:c1:6e:7a:a8:58:9b:a3:13:61:b0:63:6f:
         84:96:f4:3c:4a:5d:30:12:e0:27:e9:94:33:76:ff:f5:14:50:
         02:20:07:5f:d9:5d:71:5e:57:26:b1:4a:4b:6c:c7:43:52:9d:
         6e:72:e2:ee:83:74:25:86:19:3c:09:db:f3:71:ec:60

MSP(Membership Service Provider)

image

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

즉 Fabric-CA 는 어떤 기본 정보를 제공해 주는 것이고, MSP 는 그 정보를 통해서 실제 어떤 오퍼레이션을 하는 것이라고 볼 수 있을 것이다.

MSP

MSP는 블록체인 네트워크에서 두 부분으로 나타난다. Channel configuration (channel MSPs)와 locally on an actor’s premise (local MSP)이다.

Local MSP / Channel MSP

image

Local MSPs는 클라이언트(사용자)와 노드(피어, orderers)을 위해 정의된다. Node local MSPs는 노드(예: 피어의 관리자)의 사용권한을 정의한다. Users local MSPs는 사용자가 채널의 구성원으로서 거래를 할 때 본인임을 인증하거나, 시스템안의 특정한 역할의 소유자(예: configuration transaction에서 조직 관리자)임을 인증할 수 있도록 해준다.

로컬 MSP는 로컬 레벨에서 관리 권한이나 참가 권한을 가진 사용자를 정의한다. 그렇기 때문에 모든 노드와 사용자는 정의된 로컬 MSP를 보유하고 있어야 한다.

채널 MSP는 채널 레벨에서 관리 권한 및 참여 권한을 정의한다. 채널에 참여하는 모든 조직은 정의된 채널 MSP가 있어야한다. 채널내의 피어 노드와 orderers는 채널 MSPs의 동일한 뷰를 공유하므로 채널 참가자를 올바르게 인증할 수 있다. 즉, 어떤 조직이 채널에 가입하고자 할 때 조직 구성원에 대한 신뢰 체계를 갖는 MSP를 채널 구성에 포함시켜야 한다. 그렇지 않으면 이 조직에서 발송하는 트랜잭션의 ID는 거부될 것이다.

로컬 MSPs와 채널 MSPs의 주요 차이점은 동작방식이 아니라 동작범위이다.

MSP Level

  • 네트워크 MSP
    • 네트워크 구성은 네트워크의 구성원을 정의한다. (참가자 조직의 MSP를 정의) 또한 이 구성원들은 관리 작업(예: 채널 생성)을 수행할 수 있는 권한을 부여받는다.
  • 채널 MSP
    • 채널에서 구성원의 MSP를 별도로 관리하는 것은 중요하다. 채널은 조직의 특정한 그룹안에서 개인 통신을 제공하며 순서대로 제어 권한을 갖는다.
    • 채널 MSP맥락에서 해석되는 채널 정책은 채널의 특정한 작업(예: 조직 추가, 체인코드 인스턴스화 등)을 수행할 구성원을 정의한다.
    • 채널의 관리 권한은 네트워크 구성 채널(또는 다른 채널)의 관리 권한과는 아무런 관계가 없으며 관리 권한은 관리 대상 범위 내에 존재한다.
  • 피어 MSP
    • 이 로컬 MSP는 각 피어의 파일 시스템에 정의되며 각 피어마다 단일 MSP인스턴스가 존재한다.
    • 개념적으로 피어 MSP는 채널 MSP와 정확히 동일한 기능을 수행하지만, 정의된 피어에만 적용된다는 제한이 있다.
    • 피어의 로컬 MSP를 사용하여 권한을 부여하는 작업의 예로는 피어에 체인 코드를 설치하는 것이 있다.
  • orderer MSP
    • 피어 MSP와 마찬가지로 orderer 로컬 MSP도 파일 시스템에 정의되어 있으며 해당 노드에만 적용된다.
    • 피어 노드와 마찬가지로 orderer는 단일 조직에서 소유하므로 신뢰할 수 있는 액터 및 노드를 나열하는 단일 MSP가 있다.

Leave a comment