2017-11-10 6 views
0

나는 Hyperledger Fabric의 아키텍처를 연구 중입니다. 나는 확신 할 수있는 피어가 트랜잭션의 출처를 로컬에서 어떻게 확인할 수 있는지 궁금합니다.로컬에서 피어를 승인 할 때 트랜잭션의 출처를 확인하는 방법은 무엇입니까?

문서에 따르면 제출 클라이언트가 승인하는 피어에게 트랜잭션을 보낼 때 각 인증 피어는 클라이언트의 서명을 확인합니다. 내가 아는 한, 서명은 클라이언트의 개인 키로 암호화 된 메시지입니다. 서명을 검증하기 위해 인증 피어는 클라이언트의 공개 키가 필요합니다.

내 질문은, 어디에서 보증하는 피어가 클라이언트의 공개 키를 얻는가? 공개 키는 configtxgen 도구로 생성 된 채널의 창세기 블록 안에있는 것으로 추측됩니다. 동일한 채널의 모든 피어가이 창세기 블록을 가지고 있기 때문입니다. 맞습니까? 또는 트랜잭션에 https 연결과 같은 클라이언트의 공용 키 (클라이언트 인증서)가 포함되어 있습니까? (그러나 문서에 따르면 메시지 형식에 대한 클라이언트 공개 키의 여유는 없습니다.)

감사합니다.

답변

1

아니요, 창 블록에는 네트워크 노드의 공개 키가없고 루트 CA와 중간 CA 만있는 공개 키가 없습니다.

트랜잭션 내에서 클라이언트의 ID가 인코딩됩니다. Fabric v1.0은 x509 인증서를 기반으로하는 ID 만 제공합니다. 공개 키가 인증서 안에 있습니다.

서명에 인증서가 없습니다. 그것은 단지 서명 그 자체입니다. 인증서는 거래의 일부인 (작성자 필드의) 트랜잭션의 SignatureHeader에 포함됩니다. https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/protos/common/common.proto#L113-L119

message SignatureHeader { 
    // Creator of the message, specified as a certificate chain 
    bytes creator = 1; 

    // Arbitrary number that may only be used once. Can be used to detect replay attacks. 
    bytes nonce = 2; 
} 
+0

답장을 보내 주셔서 감사합니다. 당신의 대답은 나에게 논리적이라고 느낍니다. 문서에 따르면'PROPOSE' 메시지 형식은'이고'tx' 형식은 입니다. 내가 아는 한, 서명은 클라이언트의 개인 키로 암호화 된 다른 필드 (clientID, ... 등)입니다. 그래서, 당신은'clientSig'가 암호화 된 다른 필드 이외에 클라이언트의 인증서를 포함한다는 것을 의미합니까? 또는 인증서가 트랜잭션에 포함되어 있지만 의사가 'PROPOSE'메시지 형식의 일부로 언급하지 않았습니까? – byron1st

+1

서명이 암호화되는 이유는 무엇입니까? 목적은 모든 사람에 대한 소유권 증명을 제공하는 것이므로 암호화되지는 않지만 누구든지 (따라서 트랜잭션이 있으므로 신원을 갖고 따라서 공개 키를가집니다) 검증 할 수 있습니다. 답변을 업데이트하고 확인해보십시오. – yacovm