Modular-crypto-service

[davidkhala]

trafficstars

Signed-off-by: davidliu [email protected]

[mastersingh24]

Fundamentally, I don't have any issues with the concept, but how something like this is implemented requires careful thought and likely some redesign on the internal Fabric architecture.

I do think we need a more simplified version of which algorithms needs to be supported and for which actions. I assume most of this is really about SM2 (signature) and SM3 (hashing). I think SM4 (encryption) should remain at the application layer. I also see some specs for ciphers for TLS 1.3 as well as definitions for X509 constructs as well.

We'll need to go through and figure out all the crypto settings .... especially the ones related to ledger data and transactions as those must be deterministic across releases and capabilities.

As an example, for channels, MSPs really drive the crypto which is used for the most part for signing, although the block hashing also is set independent of this. What Fabric really has is two MSP implementations .... and while we call the main one "BCCSP MSP / Fabric MSP", it is really an X509 PKI-based MSP which happens to delegate crypto functions to the current bccsp.

So to me, I'd drive this top down from the MSP layer and of course check to see where other crypto settings come from and ensure that we can delegate to registered algorithms where necessary.

I'd likely also add an alternative to PKCS11 with a remote interface (http, unix domain sockets, Hashicorp go-plugin, etc) or possibly allow C-based plugins which we can load via dlopen. But we'd want to take a holistic look at plugin architecture in general.

Side note: I do not think you need a fork of gRPC. I think you can leverage custom transport credentials to handle TLS with alternative additional ciphers.

[hartm]

I think Gari gets it right here. Well said.

[SamYuan1990]

Hi All,

I found two interested commit in fabric history. https://github.com/Hyperledger/fabric/commit/01c50efbf2d0831c86e234d371ab21f9656b03c6 https://github.com/hyperledger/fabric/commit/0cde0177ddcc219134014451505d286acf8d42d4#diff-62806c7dcf924402565d4ef558b602db6197cb4b1075bacb8514f95ca073392d

mapping to jira tickets https://jira.hyperledger.org/browse/FAB-6189 and https://jira.hyperledger.org/browse/FAB-15340

with above things, which means in historical, we support fabric BCCSP running in plugin mode and may I know the reason we removed BCCSP plugin mode support?

[denyeart]

I replied to @SamYuan1990 in the mailing list, copying here as well...

The work item that removed BCCSP plugin support explains the rationale and points to a Go issue about plugin restrictions: https://jira.hyperledger.org/browse/FAB-15338

In a nutshell, nobody was using them and while they sound good on the surface, it was unlikely that anybody would want to use them after understanding the Go restrictions.

[SamYuan1990]

Topics: Who is going to work on this pluggable crypto service?

As I mentioned in Dec contributor meetings, from Hyperledger Fabric point of view. So far it just supports crypto algs as ECDSA. Let's think about how to make Hyperledger Fabric supports any kind of cruves as ed25519 or Chinese national crypto. I can understand when most friend from world wide hearing about "the pluggable crypto service, e.g. Chinese national crypto" thought it is some country specific or it's hard for me to contribute as I don't have knowledge about "Chinese national crypto"... Here some facts:

• "Chinese national crypto" is a cruve, and Asymmetric encryption as same as ECDSA. (for my understanding, just use different parameter on EC Curve.
• Knowledge of other cyrpto algs for contribution? As I am nearly zero knowledge for crypto curves, from sample below we can see the different, something just parameter from libaray point of view.)

var oidPublicKeyECDSA = asn1.ObjectIdentifier{1, 2, 840, 10045, 2, 1}
var oidNamedCurveSm2 = asn1.ObjectIdentifier{1, 2, 156, 10197, 1, 301}

Not everyone can explain the differents as sample code above, but we just need to do things as Asymmetric encryption as below:

func sign(sth string){}
func verify(sth string){}
func encrypt(sth string){}
func decrypt(sth string){}

• Is current fabric code supports other Asymmetric encryption as ed25519? No, so far if we go through sw package, we can found it not only hard code with x509 but also ecdsa

As a summary, let's think about "the pluggable crypto service for any kind of crypto"(Chinese national/ed25519/...). And we hope by this rfc, we can make fabric able to adapt with any kind of crypto in a pluggable way, so that we don't need hard code and recomplie when we swtich from ecdsa to others.

Topic: Size of this item?

Language

• For SDK, we already have online sign mode and offline sign mode designed there, I asked other members in TWGC to help verify.
• Java specific, bouncycastle lib already has Chinese cyrpto support.

Channel config

As crypto been used everywhere in any blockchain system with fact that crypto works within same cruve only. Yes, the crypto pluggable should able to work with channel config.

MSP and BCCSP together or not?

My personal understanding for this is it related with AAA.(authentication, authorization, admin) If I am right, fabric now relay on x509 with certs to make AAA, which means MSP as user interface at top layer and BCCSP at buttom layer to ensure crytpo with curves. if we just wanna to add a new cruve, it just doing things at BCCSP layer for now. but an interesting thing here new to me, it that do we need to decouple BCCSP and MSP ?

• [ ] how fabric use MSP ?
• [ ] how MSP use BCCSP ?
• [ ] is there any possbile to make interface level as MSP within/without BCCSP? so far, I can't answer this question.

TLS

For me current I hope service mesh/side car can help with this kind of problem. As TLS need to changes at GRPC level, which sounds like out of fabric code repo scope maybe?

Topic: Golang plug in?

Before go to details, in general speaking, assume we already defined the interface for MSP/BCCSP what's on implementation level is making fabric binary invokes a pluggable binary in run time. so it is a general things as golang binary invokes other binarys. As I am still in investigating, just some comments with approaches we mentioned on the meeting.

• Golang: Fabric written by golang, by default we hope to keep our code in same language for programming. But golang pluggable is not so good as some leaving bugs without plan to fix....
• Hyperledger Ursa: In TWGC, we discussed Ursa in the past. It's a way to make it, but the problem is Ursa written by Rust.
• Rust: Recently, I am look at the golang invoking code in WebAssembly, as I see a demo that golang invokes binary as WebAssembly written by Rust.

Sorry guys, as time conflicts I missed contributor meeting at Jan 5. I write down comments above with topics on contributor meeting related with this rfc.

[Varorbc]

Hi, everyone. Any updates?