Modular-crypto-service #34
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,164 @@ | ||
| --- | ||
| layout: default | ||
| title: RFC Template | ||
| nav_order: 3 | ||
| --- | ||
|
|
||
| - Feature Name: modular_crypto_service | ||
| - Start Date: 2020-09-19 | ||
| - RFC PR: (leave this empty) | ||
| - Fabric Component: core, fabric-sdk-*, fabric-ca | ||
| - Fabric Issue: (leave this empty) | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| One paragraph explanation of the feature. | ||
|
|
||
| This RFC aims to provide broader crypto service configurability or pluggable capability. | ||
| It mainly changes design of crypt/X509 usage and hash algorithm opt-in in several layer. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| Why are we doing this? What use cases does it support? What is the expected | ||
| outcome? | ||
|
|
||
| Following is the original initiative post, translated from Chinese. | ||
| ``` | ||
| The Hyperledger Fabric code project has a very wide range of adoptions in many domestic industries and institutions, and has a very basic role in the application of the blockchain industry. | ||
| According to Chinese policy requirements, it is necessary to support the national secret (GM) encryption algorithm. Many domestic enterprises and Fabric enthusiasts have successively carried out some corresponding national secret (GM) fabric forks with outstanding achievements. However, in this matter, there is serious duplication of working hours and waste of human resources. | ||
| Here, the Hyperledger Technical Working Group China (TWGC) proposes that the majority of Fabric enthusiasts and users gather and work together to create a standard national cryptographic project of Hyperledger Fabric, which is shared by everyone, and finally meet the needs of community maintainer request, merge into the Fabric up-stream. | ||
| ``` | ||
| We now have 3 streams of China crypto libraries under Hyperledger-TWGC github organization. | ||
| Some of them has also provided successful ane enterprise-proven bccsp implementations. | ||
| But as along as we go deeper into fabric source, we notice implementing bccsp only could not fulfill all of Chinese national crypto specification requirements. | ||
|
There was a problem hiding this comment. BCCSP is not an abstraction worth saving and any work in this space should aim to replace it completely with something better. There was a problem hiding this comment. Well, I do not dare to say so loudly. :- D. @guoger Jay has asked about this before. Yes, the design looks so There was a problem hiding this comment. For personal understanding here: even if the BCCSP looks like |
||
| There are some cypro library usages outside of bccsp, such as communication protocol, X509 format conversion. | ||
|
There was a problem hiding this comment. 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. |
||
| It relates to fabric architect design thus we need broader consensus and feedbacks from community as an RFC level change. | ||
|
|
||
|
|
||
| Additionally, the new design should take care of not only Chinese but for any other national crypto standards. | ||
|
|
||
| # Guide-level explanation | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| There are 3 configurations controlling hash algorithm used in fabric, separately. | ||
| - Fabric uses hash function in bccsp related to peer/orderer (controlling feature samples: signing) | ||
| - Fabric uses hash function based on `crypto_config` section in organization/msp level (controlling feature samples: private data) | ||
| - Fabric uses hash algorithm based on `HashingAlgorithm` value in channel level (controlling feature samples: block hash) | ||
|
|
||
| Beside bccsp, a new X509 interface is introduced. Rework of usage of `crypto/X509` includes making `crypto/X509` as an implementaion of new X509 interface. | ||
|
There was a problem hiding this comment. This is too low a level to address the problem and. in my opinion, is not generally feasible. |
||
|
|
||
| This change should not impact Fabric usages if they are on default configuration. But it may impact on Fabric fork developers since we exposed more extensibility. | ||
|
|
||
| To fulfill national crypto standards, security of communication is a must. | ||
| Fabric family replies on classical https and gRPCs communication. So any implementation should firstly have another fork of crypto-complaint https/gRPCs. | ||
| After these forks become mature, incorporate them into individual national crypto fork of fabric. | ||
|
There was a problem hiding this comment. 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? There was a problem hiding this comment. Yes, it is our side goal. Make it easier and standardized for developer to have a crypto fabric fork in appropriate way. There was a problem hiding this comment. maybe an easy way too fork, but I suppose we should aim at integrate before we have to fork. |
||
| TWGC could provide a sample guideline of incorporation for Fabric forks, but not Fabric main-stream. | ||
|
|
||
| [**WIP**] feature examples, migration guideline | ||
|
|
||
| # Reference-level explanation | ||
| [reference-level-explanation]: #reference-level-explanation | ||
|
|
||
| This is the technical portion of the RFC. Explain the design in sufficient | ||
| detail that: | ||
|
|
||
| - Its interaction with other features is clear. | ||
| - It is reasonably clear how the feature would be implemented. | ||
| - Corner cases are dissected by example. | ||
|
|
||
| The section should return to the examples given in the previous section, and | ||
| explain more fully how the detailed proposal makes those examples work. | ||
|
|
||
| [**WIP**] along with previous feature examples | ||
|
|
||
| crypto/X509 ==> [X509 interface](https://github.com/Hyperledger-TWGC/fabric-gm-plugins/blob/078c5bac196c2c89190b48b9fa05102800a56c34/interfaces.go#L13) | ||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. agree, for any kind of interface, we should kind about, if it is crypto lib level, or fabric level. |
||
| crypto/sha256 => hash.Hash interface | ||
| bccsp implemtation copy to bccsp folder before rebuild fabric | ||
|
|
||
|
|
||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| Why should we *not* do this? Are there any risks that must be considered along with | ||
| this rfc. | ||
|
|
||
| **AS IS**. No matter how we improve fabric pluggable flexibility, developer still have to maintain a Fabric fork with all plugin equipped. | ||
| Does this RFC really help a lot when comparing fashions: | ||
| 1. let developer change every hardcode cryptoSuite into another national crypto hardcode cryptoSuite. | ||
| 1. let developer implement a plugin under the restriction of interface, and carefully port into fabric source. | ||
|
|
||
| **Fabric Family interopt** | ||
| For Fabric surrounding projects such as SDKs and other hyperledger projects with Fabric support, for a specific nation crypto standard Fabric fork. | ||
| developer community still have to make another SDK fork in order to satisfy secured communication. A lot of cross validation is there. | ||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. @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? There was a problem hiding this comment. For this part, if we just make the |
||
|
|
||
| **System incompatible** | ||
| For a running fabric network (mainstream) using current default configuration value, according to our design, there is no upgrade operation needed. | ||
| But some corner cases and risks are: | ||
| - if channel config `HashingAlgorithm` is changed to an unrecognizable value, there will be unpredictable behavior | ||
| - if channel config `HashingAlgorithm` is changed in the middle, there will be unpredictable behavior | ||
|
|
||
|
|
||
| # Rationale and alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| - Why is this design the best in the space of possible designs? | ||
| - What other designs have been considered and what is the rationale for not | ||
| choosing them? | ||
| - What is the impact of not doing this? | ||
|
|
||
| same as Motivation section | ||
|
|
||
| # Prior art | ||
| [prior-art]: #prior-art | ||
|
|
||
| Discuss prior art, both the good and the bad, in relation to this proposal. | ||
| A few examples of what this can include are: | ||
|
|
||
| - For consensus, global state, transaction processors, and smart contracts | ||
| implementation proposals: Does this feature exists in other distributed | ||
| ledgers and what experience have their communities had? | ||
| - For community proposals: Is this done by some other community and what were | ||
| their experiences with it? | ||
| - For other teams: What lessons can we learn from what other communities have | ||
| done here? | ||
| - Papers: Are there any published papers or great posts that discuss this? If | ||
| you have some relevant papers to refer to, this can serve as a more detailed | ||
| theoretical background. | ||
|
|
||
| This section is intended to encourage you as an author to think about the | ||
| lessons from other distributed ledgers, provide readers of your RFC with | ||
| a fuller picture. If there is no prior art, that is fine - your ideas are | ||
| interesting to us whether they are brand new or if it is an adaptation. | ||
|
|
||
| Note that while precedent set by other distributed ledgers is some motivation, | ||
| it does not on its own motivate an RFC. Please also take into consideration | ||
| that Fabric sometimes intentionally diverges from common distributed | ||
| ledger/blockchain features. | ||
|
|
||
| [**WIP**] We take several references from FISCO/BCOS for multiple language implementation of Chinese national standard. | ||
| We also take reference from famous Crypto library BouncyCastle which has almost native support for Chinese national EC. | ||
| BouncyCastle also provide a reference in X509 interface design. | ||
|
|
||
|
|
||
| # Testing | ||
| [testing]: #testing | ||
|
|
||
| - Test plan automates importing this implementation to fabric and run regression fabric test | ||
|
|
||
|
|
||
|
|
||
| # Dependencies | ||
| [dependencies]: #dependencies | ||
|
|
||
| https://jira.hyperledger.org/browse/FAB-5496 | ||
|
|
||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| Current clumsy but fast solution is that we copy a bccsp into fabric source and rebuild. | ||
| If fabric community can agree on a framework supporting dependency-inject in golang (aside from go plugin), it could be smarter. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two links you posted are in Chinese, I can't read them. Isn't there an English version somewhere?
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.