Milagro (the project) needs a general purpose Milagro Server that can encapsulate all the required components to bring up and distributed / decentralized core security services. As an example, in the current Python versioned M-Pin server I believe there does not exist any flag on whether to run this as a D-TA (serving shares of secrets) or as an M-Pin Server. This means someone building a fully fledged M-Pin protocol based implementation needs to construct their own D-TA services, which is causing implementation drag.
I propose that we fix this going forward by having an install script that can pull down various components and complete installation according to config/install scripts. So, going forward, we just have something called 'Milagro Server'.
Second, in order for Milagro to stay relevant, Milagro should address use cases within the digital asset space that deliver on the security requirements for decentralized networks, in addition to the enterprise and IoT spaces. There is much interest from these communities for open source platforms that can secure escrow of private keys used to store value and transact cryptocurrencies (custody) but operate in a decentralized manner - capability that is native to Milagro.
Qredo has been working on such a platform using the Milagro crypto libraries, which has authentication based on M-Pin (using Milagro) and will grant the software to Apache in the next few weeks. This will enable Milagro to finally get a release out the door of a product, not just a release of the crypto libraries.
The list of capabilities for this product as it continues its development trajectory incorporates decentralized storage and backup. It is envisioned that M-Pin protocol authentication and D-TA's will also be a part of this mix.
Decentralized Milagro
Qredo has incorporated into its custody server product (based on Milagro) a distributed, immutable file system called IPFS, an immutable, operation-based conflict-free replicated data structure (CRDT) for distributed systems with MIT license. On top of IPFS, we have built a decentralized public key infrastructure that does away with certificates and certificate authorities. This decentralized public key infrastructure enables an encrypted messaging over IPFS pubsub. We propose to call this the 'Milagro encrypted envelope' format.
This functionality is required to enable Milagro Servers to distribute secrets over a decentralized infrastructure - imagine a D-TA operating in this manner and distributing shares of M-Pin secrets to clients.
The custody server that Qredo has created uses the encrypted envelope format to distribute Elliptic Curve keys between operators of the Milagro Server. This EC keys are ultimately used to create wallet addresses, or create private keys used to control digital assets inside a cryptocurrency wallet. This capability is also critical for D-TAs, so that decentralized D-TA services can distributed shares of M-Pin protocol based private/server keys to authenticated endpoints/clients.
I will create another blogpost describing the functional overview of the Milagro Server configured for decentralized custody services and a separate blogpost for decentralized backup of key stores.
PKCS#11
Qredo has also created a PKCS#11 implementation that enables secrets generated by a Milagro Server to be protected by AWS HSM-Clusters. We will contribute this code as part of the Milagro Server.
Docker Container
Apache has its own Docker registry now, so Milagro should take full use of this. I propose that we implement a Milagro Server in a docker container and this be part of the initial release schedule.
Release Schedule
July 1 - Milagro Crypto Library Release (milagro-crypto-c)
The C library is in good shape and will have additional fixes made by the end of the month. At the moment, all tests are passing.
Releasing the Milagro Crypto Library first will enable the contributors to Milagro to familiarize themselves with the processes for getting releases out the door under the 'Apache Way'. This experience is essential for the success of the project. We have some tasks outstanding on Milagro-JavaScript. Depending on resource availability, we may or may not be able to
August 1 - Milagro Server Release Candidate 1 of v0.1 (RC1)
First release candidate
September 1 - Milagro Server Release Candidate 2 of v0.1 (RC2)
Second release candidate
October 1 - Milagro Server v 0.1 GA
Incorporating Current Functional Code
Qredo has specifics in mind with regards to functionality available in each RC and GA releases in regards to decentralized custody and backup but an equal priority will be given to contributor's work done so far on ZKP MFA services, particularly with regards to Giorgio's work and the current working implementations of the M-Pin Server. Going forward, I propose we stop referring to the underlying protocol and be explicit about what the functionality is, as an example, this is the zero-knowledge proof multi-factor authentication (ZKP MFA) server.
Figuring out what is going into these releases should be our next immediate priority.
Some explanation is in order for why Milagro was ignored shortly after incubation and what prevented the original contributors from driving this project. But that's the subject of another post.
What the Milagro committers need to do now is to re-invigorate the project to make sure it has every chance of success. This is great, breakthrough technology that has already found a home at IBM, NTT, various intelligence agencies (GCHQ, CCSD USAF, etc.) and defense contractors, JPM, Experian, UK Government, the list goes on. This project deserves our attention to make it successful.
Milagro needs a refresh to a) make it relevant and attract a developer ecosystem, b) to package the core technology (ZKP MFA, etc.) into a MODERN server architecture for easier deployment and use (we are delivering a PRODUCT, remember) and c) showcase its capabilities by addressing use cases that tackle billion dollar problems.
Refresh Code Repos, Website and Documentation
Milagro was conceived as a distributed cryptosystem with a unique emphasis on providing solutions for securing decentralized systems in 2016. Since then, the problems of securing these systems have only grown more pronounced and the need for cybersecurity solutions that fit to distributed/decentralized networks and architectures is even greater. Even the core cryptographic technology on which Milagro is based, zero-knowledge proof (ZKP) itself has become a mainstream topic within cryptocurrency development.
Repos
The Milagro Auth Servers are horribly out of date. They are built on Python 2.6, and are dependent on out of date core C libraries that, now updated, break the builds. The mechanism to connect relying party web applications to Milagro servers uses a non-standard, non OICD way of doing this which makes integration very hard to do.
The M-Pin zero-knowledge proof multi-factor authentication crypto protocols are alive and well in the core lib, and C and JavaScript implementations. I recommend that we decommission the current class of Milagro server, standardize on OIDC and build a modern Milagro server using go-kit or some other type of automated system that will automatically build the right kind of server the customer wants/needs (D-TA, ZKP MFA, Crypto Custody) from the Milagro crypto components and libraries. This is covered further in a further section.
I propose we focus our development energy in two places.
- Update Milgro-Crypto-C and Milagro-JavaScript libraries to prep them for release within 30 days - This will be the first release from the Milagro project. There is much to do to make this happen, with a major effort on making sure disclaimers, right language in libraries regarding licensing and a filing with USA export control are all handled diligently. This our shot for us as committers to rebuild some goodwill with Apache so let's do this right.
- Build a minimal Milagro Server for release within 60 days - The committers working at Qredo have been developing a decentralized security system for protecting cryptocurrency private keys, effectively digital asset custody. This is all based on code within Apache Milagro. Qredo has signed a CCLA and so have all developers working on the project. We propose putting this server code into the a new, modern, Milagro server for release within 60 days. This will also enable us to build a modern deployment architecture for the 'type' of Milagro server the customer wants to deploy and make a way for us to take the great work that Giorgio and others have done, particularly with the D-TA's issuing secrets via gRPC, and incorporate this work into the new, modern Milagro server. Qredo, which has recently signed a CCLA will make a software grant to Apache which covers the custody use case.
Website and Documentation
I propose that we refresh the website to give it more emphasis on securing these decentralized/distributed systems (like Bitcoin, etc.) in addition normal enterprise use cases like multi-factor authentication.
Now that Confluence is setup, we can proof the new website language here to get PPMC discussion and agreement on the updated website before going live. I propose we do this straight away and will have a draft this next week for everyone to review.
NOTE: The current website is hosted within SVN. I propose that we also move the location of the website to the milagro-crypto repository, putting the static site content in there for build into a 'content' folder within an 'asf-site' branch. This is all documented https://www.apache.org/dev/project-site.html and in the last section of Apache Guacamole's README.md file here https://github.com/apache/guacamole-website/tree/master (be sure to look at the asf-site branch). We need to make a request to asf infra to do this but it shouldn't be an issue.
Modern Milagro Server
Some of the contributors have been working on a modern implementation of a Milagro server using Golang which we propose to contribute to Milagro. This version of the Milagro Server can perform zero-knowledge proof authentication with an M-Pin protocol enabled client, but also performs a custodial operation (securing) cryptocurrency private keys, again, using code from the Milagro crypto libraries.
The point is that we can refresh the Milagro server with a build process that enables easy integration into other Apache infrastructure projects and provides utility value for these projects as well by way of supporting Docker and having a modern build system. As an example, the Milagro Server should integrate with Apache Web Server and in particular the mod_oidc to offer any implementer of OIDC relying party capability the option to integrate into a Milagro Server, when, in ZKP MFA mode, will have an on-board OIDC IP (Identity Provider) function.
Milagro Server Direction
I propose that Milagro Server addresses three main uses cases that are possible to implement given the core crypto library capabilities.
- Decentralized Zero Knowledge Proof Multi-Factor Authentication - this is been the historical core of capability and nothing changes here (except we deploy the authentication server, or D-TA's using a modern method).
- Decentralized Custody for Digital Assets - The Milagro Server should be able to communicate with other Milagro servers to arrange themselves in a distributed manner to offer a custodial operation for issuing cryptocurrency wallet addresses. This 'type' of Milagro Server will be covered in another page on this Confluence site shortly as a basis for discussion and planning. As stated above, Qredo, which has recently signed a CCLA will make a software grant to Apache which covers the custody use case.
- Decentralized Backup for Secrets and Digital Assets - Using code and architecture from #2, we will also be able to offer a secure backup for secrets and digital assets that is sorely needed for decentralized systems today. As in #2 above, this 'type' of Milagro Server will be covered in another page on this Confluence site shortly as a basis for discussion and planning.
I will alert the committers over the dev@ channel to put their comments through this email list to discuss, debate and agree on direction this weekend.