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.

  1. 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.
  2. 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.

  1. 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).
  2. 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.
  3. 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.


  • No labels

1 Comment

  1. Giorgio Zoppi

    My idea for having and growing the community it to have something to present at the next Embedded Linux Conference in Lyon, the call for paper ends beginning of July. This will give us the right visibility for saying "We are back!". As always depends on us. Some thoughts:

    1. For the server i don't know what you have since in the repo we have just an excellent set of python servers. We can follows two paths or just one, port all to Modern C++ (programming in modern c++ is not so scary) or move the ideas to go grpc, depends on what you have.
    2. My vision for the server architecture is a federated system of different microservices both for the RPA and DTA. Here we have a lot of challenges on different things for example load balancing (look at envoy proxy), fault tolerance, kubernetes support. Brick over brick. The first thing is to a docker-enabled D-TA server. Then will come the RPS.
    3.  The current repos needs to be reorganized. For the c++ milagro library after the bug on config64.py will be resolved (filed today), i have  a CMakeLists.txt and a conan recipe. Conan  https://conan.io/ is a decentralized package manager for C++ (for java developers is  like gradle). So the library will be present in the JFrog repo.
    4. Further ideas:
      1. Modern Cloud enviroments support HSMs and an opportunity to evaluate is the to integrate pkcs11 support in the servers for storing and generating secrets. (https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library.html )
      2. The rpa/rps clients might be as well cars so we could explore how to use intel/arm in the tpm module for storing sensitive information in a board. I imagine a RPS client that from a car does authentication before dowloading navigation datas and stores in our servers sensitive information because they trust us.
      3.  For the javascript demo would be nice to hava a  react/login component to be integrated in asp.net core application. Just plug and play. Estimated time a couple of days.