Modular-crypto-service

[davidkhala]

Signed-off-by: davidliu david-khala@hotmail.com

[yacovm]

Can you please explain, or give a formal (English) reference to the bespoken policy? Is this policy only for intra-national networks? I'm asking because most of the world uses the (American) NIST standard - America, Australia, Europe, Africa and Asia.

When a person from China connects to a non chinese website, with overwhelming probability, that website uses the NIST approved algorithms. So, does this policy actually take place? How does the browser of the end user know which protocol to use when connecting to a site?

[davidkhala]

We stored a copy of one of original specifications in Financial distributed ledger technology security specification
More recently, there is another related specifications in Financial application of blockchain technology -- Evaluation rules

There might be a blur expression from our original initiative. Policy means some points like:
To promote GM crypto adoption in Critical Industries. This has been mentioned by government from about 10 years ago. 2020 we see the above specifications responding to this policy trend.

Formal English reference does not exist theoretically. But we TWGC are also working on an Fabric Evaluation on the first specs in Tencent doc. It is better formatted to apply google translate and maturity is Beta

About these specification applying scope, both above are limited to 'Finance', in level of 'Recommended'. So it will not apply to all intra-national network or internet. We can see it as an extension from FIPS series when coming to Financial DLT domain.

[yacovm]

The two links you posted are in Chinese, I can't read them. Isn't there an English version somewhere?

About these specification applying scope, both above are limited to 'Finance', in level of 'Recommended'. So it will not apply to all intra-national network or internet. We can see it as an extension from FIPS series when coming to Financial DLT domain.

If it's recommended it means it's not mandatory, therefore since all businesses in China can still use the existing Fabric implementation, what business value does using Chinese crypto have?

[davidkhala]

It is required in practical use case. Increasing numbers of financial institution procument will add this specification as requirement to checklist. If it is indeed valueless, we would not have heard about questions and efforts to make a fabric-GM fork. Ignoring this is not prohibited but at least harmful.

Meanwhile I would like to highlight that this RFC does not aim to inject a native GM support in Fabric. We think for further.

@hartm Hart, what is your opinion?

[hartm]

I'm not a Fabric maintainer (or even contributor, just a free rider), so I don't think my opinion here will matter too much. But I do like the idea of a plugin crypto architecture for Fabric, which I think would be the cleanest way to do this (Fabric maintainers, please feel free to shoot me down if I'm way off), and I'm always happy to spout off an opinion, so I'll go ahead and comment.

There are other applications that a plugin architecture would enable. For instance, I'd like to be able to replace the core signing algorithms in Fabric with pairing-based signatures. We could then use threshold versions of these signature schemes for a number of useful blockchain applications. For instance, this would allow compact endorsements and small "proofs of blockchain state." I have a bunch more applications in mind that I'd be happy to talk about if people are curious that are too long for a comment here. These are obviously not related to government standards.

However, I think you probably want a much more detailed RFC than what is currently present (maybe I'm missing the details?). Can you propose the exact interfaces and functions you want for modular interoperability? I think the Fabric maintainers will potentially be much more receptive if you propose the kind of interface you want. It looks like just 1) a generic hash primitive and 2) a generic signature primitive will be enough. Figuring out what kinds of formats/functions will work best with Fabric will go a long way here.

Finally, doing something like this would be an ambitious project. The more you can do it in bite sized pieces, the better. It will make testing and security analysis much better. So it might be best if your plan was to come up with a generic interface, put your protocols in that interface, and then slowly migrate Fabric.

Anyways, I hope I'm not ruffling any feathers by commenting here. Thanks everyone for your hard work.

[davidkhala]

@hartm Thanks for your valuable feedback. Indeed we are hard working to provide more details, and further changes to the RFC proposal will be pushed later.

[yacovm]

The Fabric core is very, very tightly coupled with x509 standard:

All communication assumes TLS which uses x509 and doesn't have pluggable algorithms (though, it's possible to fork the TLS library and make your own version of it).

Fabric authentication infrastructure uses the BCCSP MSP which is also heavily based on x509 and doesn't abstract it out in any way.

It's going to be a lot of work to overhaul the entire code base to abstract out x509, and, if we do this, it'll make backporting changes and bug fixes a pain because the code base would diverge too much.

[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.

[sykesm]

Like @mastersingh24, I don't have a problem with the concept but I have a number of practical concerns. What is outlined in the RFC just barely scratches the surface of what is impacted.

Given the scope, I'd suggest breaking this RFC down into multiple proposals.

[sykesm]

BCCSP is not an abstraction worth saving and any work in this space should aim to replace it completely with something better.

[davidkhala]

Well, I do not dare to say so loudly. :- D. @guoger Jay has asked about this before. Yes, the design looks so Java than golang. But I personally have no idea how is a better practice in golang world.

[SamYuan1990]

For personal understanding here: even if the BCCSP looks like java than golang which still providing us with interface and we can design/change it following design patterns. We can implement particular design pattern via OO concept or else.

[sykesm]

This is too low a level to address the problem and. in my opinion, is not generally feasible.

[sykesm]

I keep seeing a reference to a fork for all of the "special sauce." So, is the goal to make it easier to fork or to integrate with Fabric?

[davidkhala]

Yes, it is our side goal. Make it easier and standardized for developer to have a crypto fabric fork in appropriate way.

[SamYuan1990]

maybe an easy way too fork, but I suppose we should aim at integrate before we have to fork.

[sykesm]

On a technical note, I do not support the definition of that interface. It's binding too many aspects of x509 behind an implementation. This is one of the problems with the existing "plug point" definitions of Fabric that we need to avoid as we move forward.

[SamYuan1990]

agree, for any kind of interface, we should kind about, if it is crypto lib level, or fabric level.
ex bccsp.key interface is fabric level, and x509.xxx is crypto lib level.

[sykesm]

This, to me, complicates the ecosystem quite a bit. This really does imply that once Fabric is forked for crypto, each of the SDKs get a fork, the documentation gets a fork, the build processes fork, CI gets a fork, the maintenance process forks, etc.

So, while I support making Fabric more malleable, it's a small piece of the overall solution space.

[davidkhala]

@sykesm we have similar concern and discussion of this complexity. Is there any better and smart roadmap per you think that we can switch to?

[SamYuan1990]

For this part, if we just make the bccsp package modular, which means we may don't need to impacts with CI and others. For SDK we will need it supports with a new module for crypto alg implementation...

[bestbeforetoday]

I would personally prefer to see SDK support focused on the Fabric Gateway client API, which is implemented in Go, Node and Java. This API has been designed with a pluggable approach in mind. For example:

• Uses application-provided hashing implementation so any hashing algorithm can easily be used with no SDK changes.
• Uses application-provided signing implementation so any encryption algorithm or implementation can easily be used with no SDK changes.
• Treats client credentials as opaque bytes, so any identity representation can easily be used with no SDK changes.
• Uses application-provided gRPC connection, so the application is free to configure this connection (including transport security) with no SDK changes.

Note that the Fabric Gateway API is focused on business application runtime, including transaction invocation and eventing, not on operational concerns such as identity enrolment with a CA.

It would be good to understand whether the current Fabric Gateway API meets your needs and, if not, what additional requirements you have related to this RFC.

[SamYuan1990]

Hi @bestbeforetoday ,

Yes, we can ref to Gateway API to make changes for SDK side and refresh this part making them up to date, and there are some questions before we update description for this part in this RFC.

Only for java specific

1. For my personal understanding, the grpcs changes is better/needed changed from grpc jar packages.

fabric-java-gateway/sdk
grpc.jar
connection level(netty?) we need change here to meet the request

so, at implementation level, we need to change at the connection level to match the "standard request".
sounds like we have two plan:

• Plan A, just recompile netty and replace netty jar packages via mvn/gradle to have a try without updates fabric-java-gateway/grpc.jar if it is possible.
• Plan B, making a customer impl for all the things and use application-provided gRPC connection

Also there maybe Plan C as with further considering that grpc matches TLS1.3 rfc and too see we can reuse TLS1.3 or not...
With reasons all above, you know that's the reason for now, just focusing on hash and sign logic in current documents.
But here I have a question about application-provided gRPC connection but where should user makes an object as io.grpc.Channel grpcChannel, compile fabric proto file and next?

1. I am agree gateway sdk client is more easy for user for use, but considering for any existing application using sdk, before we announced as duplicates sdk by gateway. I suppose we need considering any existing application in rfc scope?

2. if I am understand correctly, sign, hash, id(as cert import,export)... we are able to customer crypto related impls in java gateway sdk?

Considering other language

1. it there any language such as golang/nodejs gateway supposes this kind of sample?

---

Overall speaking, I am glad to see if the gateway interface you are sharing resolved parts for the questions and I would like to ask @xiaohui249 's help here to double check if the interface you provide can help resolve hash, sign and id.

CC: @davidkhala

:-)
Sam

[bestbeforetoday]

The Java client API for Fabric Gateway just requires a gRPC Channel object to be passed in as the gRPC connection to use. This is a very simple abstract class so you could provide your own complete channel implementation that just extends that class if the gRPC ManagedChannel implementation cannot be made to work for you as required. The Fabric Gateway client API should not need any changes.

The Fabric Gateway client API just uses whatever hash and signing implementation you provide, so you can use whatever crypto implementation you want with no changes to the Fabric Gateway client API. At least provided that crypto implementation uses the pattern of hashing a message to create a digest, and then generating signature bytes from that digest. At the server end the usual Fabric mechanisms are used so Fabric Gateway doesn't make it any easier (or more difficult) to provide a server crypto implementation that matches the client implementation.

The Fabric Gateway client API has very similar implementations in Java, Node and Go, so it is just as easy to plug in your own crypto implementation in each language. The gRPC connection details are slightly different as the gRPC implementation in each language are slightly different.

The Go client requires a grpc.ClientConn, which is a struct so not easily replaceable with your own implementation. The Node client requires a gRPC Client object. If we really had to allow alternative gRPC implementations in these languages, we could probably implement some abstraction to make that possible -- in fact the unit tests already make use of similar internal abstractions -- but I suspect a better route might be to enhance the gRPC libraries themselves if they don't currently provide the required capability.

Of course you are free to target existing SDKs too but I would definitely like for the Fabric Gateway client API to be included. Based on my understanding of what you are trying to achieve, it sounds like the Fabric Gateway client API will be much easier to use the way you want than the existing SDKs.

[SamYuan1990]

Hi All,

I found two interested commit in fabric history.
hyperledger/fabric@01c50ef
hyperledger/fabric@0cde017#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.

[SamYuan1990]

@denyeart , thanks you pointed out this modular crypto may need take a look at msp interface/package on contributor meeting last year when we do the review.
pre discussed with TWGC member, I had some attempt with bccsp interface and msp interface refactor/decouple idea as 3rd option here.
Please take a look at and have arrange/schedule review on contributor meeting.

[Varorbc]

Hi, everyone. Any updates?