incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <...@apache.org>
Subject [VOTE] Accept Milagro into the Incubator
Date Tue, 15 Dec 2015 08:56:22 GMT
I should like to call a vote to accept Milagro into
the Incubator.  The full proposal is available at
https://wiki.apache.org/incubator/MilagroProposal
as well as below.

Note that the project was first discussed here under
the name OpenMiracl.  The adoption of the Milagro name
is a response to that discussion.

[ ] +1 Accept Milagro into the Apache Incubator
[ ] 0
[ ] -1 Do not accept Milagro into the Apache Incubator ...

The vote remains open until at least the end of the week.

For myself:
[*] +1 Accept Milagro into the Apache Incubator


= Project Proposal: Milagro =
== Abstract ==
Milagro is a distributed cryptosystem for cloud computing. Its purpose
is to provide an open source alternative to proprietary key management
and certificate backed cryptosystems used for secure communication and
authentication. The adoption of Milagro will create a secure, free, open
source alternative to monolithic certificate authorities and eliminate
single points of failure.

== Background ==
The Cloud Computing industry is using 40-year-old cryptographic
algorithms and infrastructure, invented for a different era when
client-server computing was the dominant paradigm. At the heart of it,
is the continued reliance on outdated, and problematic, monolithic
cryptographic trust hierarchies such as commercial certificate
authorities.

A number of factors are aligning to make this the right time to bring
forth an alternative to the Internet's continued reliance on PKI.

The Cloud Infrastructure as a Service (IaaS) industry as a whole
encounters friction bringing the largest customers in regulated
industries onto their platforms because issues of cryptographic trust,
data residency, and data governance prevent total adoption among
regulated industries.

Devops teams tasked with running an IaaS provider's datacenter
automation encounter challenges scaling and automating data center
operations when confronted with the complexities of running encryption,
certificate and key management infrastructures built for a client-server
era.

Enterprises in regulated industries find challenges to transform
entirely into digital businesses because the economics of cloud
computing are unavailable to them.

Despite the astounding growth of cloud infrastructure as a service
platforms over the last few years, full adoption by organizations with
stringent data security requirements won’t be achieved until these
fundamental capability issues get resolved.

Lastly, the Internet as a whole is suffering from an erosion of trust
following incidents with commercial certificate authorities industry,
i.e., compromised root keys, and failures in due diligence issuing real
domain certificates.

Indeed, mass surveillance, a lack of easy end-user encryption, a growing
demand for key escrow under legal oversight, and general certificate
authority security concerns create the question: How appropriate is the
continued dependency on PKI when the goal is to advance the benefits of
cloud computing across the technology landscape?

Netcraft is the industry standard for monitoring Active TLS
certificates. In May 2015, they stated that “Although the global [TLS]
ecosystem is competitive, it is dominated by a handful of major CAs —
three certificate authorities (Symantec, Comodo, Godaddy) account for
three-quarters of all issued [TLS] certificates on public-facing web
servers.”

The Internet Security Research Group's (ISRG) "Let's Encrypt" initiative
aims to make Secure Sockets Layer/Transport Layer Security (SSL/TLS)
certificates available for free in an automated fashion. This a step in
the right direction, in that it removes the risk of profit before
ethics. The real issue, which is one entity acts as a monolithic trust
hierarchy, is not addressed. The monolithic trust hierarchy is a
fundamental design flaw within PKI itself.

The rate of attacks against certificate authorities seems to be
[increasing](http://wiki.cacert.org/Risk/History) as the obvious single
point of compromise design inherent to PKI is becoming a more popular
route to carry out attacks.

== Proposal ==
Milagro is an open source, pairing-based cryptographic platform to solve
key management, secure communications, data governance and compliance
issues that are challenging Cloud Providers and their customers.

It does this without the need for certificate authorities, putting into
place a new category of service providers called Distributed Trust
Authorities (D-TA's).

The M-Pin protocol, and its existing open-source MIRACL implementation
on which Milagro will build, are already in use by Experian, NTT, Odin,
Gov.UK and are being rolled out at scale for zero password multi-factor
authentication and certificate-less HTTPS / secure channel.

It is proposed that Milagro enter incubation at Apache.  At the same
time, a draft standard for M-Pin has been prepared and recently
submitted to IETF.  The standards process at IETF and the platform
implementation at Apache will run in parallel.

=== Why Pairing-Based Cryptography, why now? ===
Over the last decade, pairings on elliptic curves have been a very
active area of research in cryptography. Pairings map pairs of points on
an elliptic curve into the multiplicative group of a finite field. Their
unique properties have enabled many new cryptographic protocols that had
not previously been feasible.

Standards bodies have already begun standardizing various pairing-based
schemes. These include the IEEE, ISO, and IETF. Besides identity-based
encryption (IBE), the standardized schemes include identity-based
signatures, identity-based signcryption, identity-based key
establishment mechanisms, and identity-based key distribution for use in
multimedia.

NIST has also recommended the standardization and adoption of
pairing-based cryptographic systems __for government agencies__. In the
NIST "Report on Pairing-based Cryptography" issued in February 2015,
they state:

>"It has been a decade since the first IBE schemes were proposed. These
schemes have received sufficient attention from the cryptographic
community and no weakness has been identified. IBE is being used
commercially, primarily by Voltage Security and Trend Micro. Intel’s
EPID scheme is another example of pairings being used commercially. > As
a result of our study, we believe there is a good case for allowing
government agencies to use pairings. Pairings have been shown to have
numerous applications, helping to solve problems that are impossible,
difficult, or inefficient with traditional public-key cryptography or
symmetric encryption."

The biggest beneficiary of these new pairing-based cryptographic
protocols will be the Cloud Infrastructure as a Service industry.
Pairing-based cryptography can provide real world solutions, right now,
to the outstanding issues of cryptographic trust, data security,
governance and compliance that create roadblocks to adoption of the
Cloud by the industries that can most benefit from it.

Pairing cryptography also makes possible the world in which a fleet of
geographically distributed and organizationally independent Distributed
Trust Authorities act as multiple private-key generators (PKGs) where
trust need not reside in a single entity.

The difference between this new world of Distributed Trust Authorities
and the current PKI system will be a landscape that provides secure
ease-of-use encryption and authentication, does not rely upon a single
trusted third party, and yet allows for limited key escrow subject to an
end customer's requirement.

=== Milagro ===
The Milagro libraries and tools consist of:

 * Distributed Key Management Service API
 * Distributed Key Management CLI
 * Software Defined Distributed Security Module (SD-DSM) build platform
 * Distributed Key Management Endpoints (software)
 * Crypto Apps, consisting of:
  * M-Pin Authentication Platform (delivering password-less 2FA)
   * M-Pin Secure Channel (delivering certificate-less TLS-PSK)
   * M-Pin-in-Mobile Client Libraries for iOS, Android and Windows Phone
   * M-Pin-in-Javascript Libraries for Browsers
  * Cloud Encryption Gateway (under nascent development)
  * Distributed Trust Authority Crypto App
  * Generic library for IoT cryptographic library

The startingpoint for these is the existing MIRACL library and tools at
http://github.com/Certivox/

=== Distributed Trust Authorities ===
The Milagro project introduces a service concept called a Distributed
Trust Authority, to replace either single-authority certificates or
public key infrastructure.

The D-TA splits the functions of a pairing-based key generation server
into three services issuing thirds of private keys to distinct
identities. The shares of the private keys, received by Crypto App
clients or Distributed Key Management Endpoints, become the only
entities that possess any knowledge of the whole key created from the
shares.

To effect anything resembling a root key compromise that can occur in a
traditional PKI or commercial certificate authority, ***ALL***
Distributed Trust Authority servers must be compromised.
Cryptographically, one compromise of a Distributed Trust Authority does
not yield an attacker any advantage, all Distributed Trust Authority
master secrets inside each D-TA providing shares must be compromised.
Note that all 3 D-TA's operate independently and are under separate
organizational control.

For the following examples, envision a Distributed Trust Authority model
consisting of Cloud Provider (D-TA 1), Cloud Provider end customer (D-TA
2) and neutral third party (D-TA 3).

Under this three participant model, where each member is responsible for
the security of their D-TA, the Cloud Provider can not subvert the
security of the end customer, even with the collusion of the neutral
third party. The end customer will not suffer an internal insider attack
unless the Cloud Provider and neutral third party also collude.

=== Distributed Key Management API, CLI, Endpoints ===
The core infrastructure that consumes these thirds of private keys and
is responsible for their distribution is a message bus and API (D-KMS
API), a command line interface (CLI) and software (D-KMS Endpoints)
which builds the Crypto Applications from source.

Any entity can run any mix or combination of components with other
entities, but there is no restriction on configuration. One party may
operate all three D-TAs, Endpoints and APIs if they wish.

The D-KMS CLI communicates securely with the API. The API is responsible
for either creating cryptographic keys and secrets or protecting
existing keys and secrets through cryptographic encapsulation, via a
choice of pairing-based protocols. In either case, the API encapsulates
the keys and secrets for the identity of particular D-KMS Endpoints.

The D-KMS Endpoints are server operating systems with D-KMS Endpoint
software installed. The D-KMS Endpoint software, in conjunction with the
D-KMS CLI, has the appropriate pairing-based cryptographic keys to be
able to de-encapsulate secrets and keys received from the D-KMS API.
These de-encapsulated secrets and keys can be stored, distributed or
used in Crypto Applications, such as M-Pin Authentication, Secure
Channel or Encryption Gateway.

=== SD-DSM / Crypto Applications ===
Software Defined Distributed Security Modules, otherwise known as Crypto
Applications "Crypto Apps" get compiled from source files on-demand.
Crypto App source files will be hosted on major public repositories such
as Github and Apache.

Crypto Applications are scaled across the datacenter through the D-KMS
API in conjunction with orchestration tools such as Apache Mesos and
consume the de-encapsulated secrets and keys.

==== M-Pin Authentication and Secure Channel ====
M-Pin is already deployed by such organizations as NTT and Experian in a
two node Distributed Trust Authority model, where MIRACL and its
customer each host a D-TA node. In Experian's case, M-Pin was selected
to provide authentication for Experian's identity assurance platform,
contracted to the UK Government, for secure authentication of online
citizens into UK government websites, including HMRC (tax office). M-Pin
was selected based on its security efficacy and ability to scale to an
Internet scale user population (UK online citizenry).

The M-Pin Authentication Platform serves as an example of what is
possible exploiting a pairing based protocol. M-Pin is capable of
running in a native browser mode, delivering two-factor authentication.
M-Pin binds to any identity (as long as it is worldly unique) and
improves the user authentication experience as it can be visualized in a
familiar ATM-style pin pad.

It's most unique trait is the exploitation of zero knowledge proof
authentication. The M-Pin Client proves to the M-Pin Server it possesses
its cryptographic authentication key without revealing it to the server.
As a result, the M-Pin Server stores no authentication credentials,
eliminating the possibility of credential (i.e., password) smash n' grab
attacks.

M-Pin Secure Channel extends the protocol to include authenticated key
agreement between server and client and mutual client-server
authentication. The 'agreed key' is unique for each session, possessing
perfect forward secrecy.

M-Pin Secure Channel takes the agreed key and injects the key into a
TLS-PSK session between client and server, providing mutual
authentication and perfect forward secrecy without the need for PKI.
This cryptographic underpinning can be extended to create secure VPN
sessions over various protocols.

In an M-Pin client and server context, clients and servers receive their
shares of their private keys from all three Distributed Trust
Authorities. In the previously mentioned example, this could be Cloud
Provider, end customer and neutral third party or any combination
thereof.

M-Pin Client and Server code are already open source, having been
previously released under BSD-Clause-3.

The next iteration and revision will be licensed under the Apache
License.

==== Cloud Encryption Gateway ====
Many proprietary solutions have appeared on the information security
market to solve data governance issues about securing data in the cloud
with encryption keys managed by an end customer. To date, most of these
solutions involve purchasing hardware or virtualized appliances to run
in an end customer's datacenter, with nothing more delivered than a
single encryption key under control of the end customer, performing
sub-optimum deterministic encryption on data sent to the cloud.

The Milagro Cloud Encryption Gateway will be a virtualized or container
based software, deployed in an end customer's environment. This CEG will
exploit pairing-based capabilities such as attribute-based encryption
(anyone in possession of the correct set of attributes can decrypt) and,
more generally, predicate-based encryption (anyone in possession of the
right set of attributes and a decryption key corresponding to a
particular predicate can decrypt).

Doing so increases the flexibility of the solution by being enabled to
address data residency and governance requirements such as geo-location
while allowing key management and rotation protocols to be enforced.

== Rationale ==
The benefits of a strong authentication, secure channel and cloud
encryption via an identity framework for people and things are
self-evident, and the plethora of homebrew proprietary solutions and
password nightmares seen today is clear evidence of a need for better
solutions.

Milagro's distributed trust model is particularly attractive, by virtue
of dispensing with need for (and potential for abuse of) any central
trust authority without requiring sophistication - such as understanding
a Web of Trust - from end users.

A move to incubation at Apache will help the community to grow and take
on new members in an environment that guarantees open development and
protection of participants.

This is particularly relevant right now as a second corporate team, NTT
Data, with its own culture joins as core developers. For the outside
world, it offers the strong promise of openness.

== Initial Goals ==
Milagro will seek to integrate the existing projects at Certivox (now
MIRACL) and NTT, and will invite participation from a nascent broader
community evidenced by the core MIRACL library's 65 watchers and 29
forks at Github.

As well as looking to broaden direct participation, it will seek
synergies with relevant Apache projects, for example by providing
Milagro plugins for HTTPD and Trafficserver.

The initial software products will be the current standing M-Pin Core
platform, client libraries and the SD-DSM and Distributed Key Management
API and client CLI (as noted above).

== Current Status ==
Certivox (now MIRACL) has developed open source software at Github since
2014, though the core MIRACL library goes back much further. Projects
currently at Github include the M-Pin Authentication Platform and the
MIRACL cryptographic libraries under BSD-Clause-3 and AGPL licenses.

These have attracted both community and corporate interest taking them
beyond the realm of a single-company project, with NTT being the second
corporate team to take a substantial part in development.  The project
now seeks to transition smoothly to a full Open Development model.

The core team at Certivox (now MIRACL) is geographically dispersed and
developers are well-accustomed to using online infrastructure and tools
for their everyday work.  The team at NTTi3 and NTT DATA and other
contributing developers are included amongst the initial committers.

In addition to MIRACL operating a community D-TA, NTT, Experian and
Dimension Data have all agreed to host no-charge community D-TAs.  Other
cloud providers are considering and have been engaged. An open source
platform from which to offer these services is a necessary component to
finalizing and launching community D-TA's.

== Meritocracy and Community ==
The project is moving from a single (startup) company open source
project seeking a wider community, to embrace a second corporate
development team and third-party developers.  The project is committed
to broadening the community through meritocracy, and expects to welcome
contributions and recognize contributors.

It is hoped that incubation at Apache will help with this broadening, by
providing a widely-recognised and well-understood framework for working
collaboratively, growing communities, and protecting contributors.

== Core Developers ==
Dr. Michael Scott, Chief Cryptographer at Certivox (now MIRACL), has
been a major open source and standards contributor to the field of
elliptic curve cryptography for over twenty-five years.

Others include

=== Existing team at Certivox/MIRACL: ===
 . Patrick Hilt - CTO
 . Kealan Mccusker - Cryptographer
 . Stanislav Mihaylov - Architect
 . Simeon Aladhem - Developer

=== Existing team at NTT: ===
 . Go Yamamoto - Cryptographer
 . Kenji Takahishi - Developer

=== Existing ASF Member: ===
 . Nick Kew - Developer

== Alignment: ==
Whereas Milagro has no track record of its own, the Certivox (now
MIRACL) team have been working on related projects at Github.  Being
geographically diverse, the team is well-accustomed to day-to-day
working in a similar environment to Apache and with similar tools and
processes. The anticipated role of Apache is to help the community to
grow without fragmentation of communities, code, or intellectual
property.

We are not aware of any link with existing Apache projects.  However, it
is likely that several Apache projects may be interested in working with
Milagro to provide distributed identity services.  Plugins for HTTPD and
Trafficserver are already anticipated.

== Known Risks ==
=== Orphaned products ===
Milagro, as successor to the existing MIRACL and M-Pin software at
github, is at the core of Certivox (now MIRACL)'s business and important
to NTT, Experian, and other platform adopters who are in the process of
coming online.

Interest, and with it both developer and user communities, are expected
to grow strongly.  There is little risk of the project losing momentum
in the foreseeable future.

=== Experience with Open Source ===
The software has a history as open source, developed until recently by a
geographically distributed team within a single company. Github activity
shows some evidence of a wider community.  The major new development
that leads the proposers to seek incubation at Apache is the coming of
new corporate interest: while both corporate teams have open-source
experience, their cultures and backgrounds differ.

We hope that incubation at Apache may help the teams collaborate in an
environment of mutual benefit, as well as attract independent developers
to play a full part.

=== Homogenous Developers. ===
The established corporate teams are dispersed across several European
countries and Japan.  Prospective developers (whose companies are
interested in Milagro) are located in other countries, and we anticipate
a global community.

=== Reliance on Salaried Developers ===
Most of the initial committers are salaried developers from the core
corporate teams.  Github activity, including 29 forks of the Miracl
library, indicates wider community interest, and it is hoped that the
developer community will grow substantially at Apache.

=== Apache Brand ===
The Apache brand is of course seen as an advantage.  However, the
project is more directly concerned with the Apache platform and
environment to unite diverse teams.

== Relationships with Other Apache Products ==
See Alignment above.

== Documentation ==
Milagro derives from Certivox's existing M-Pin, MIRACL and associated
tools at github.com/Certivox/ Documentation at http://docs.certivox.com/
may also inform and feed into the Milagro project.

== Initial Source and Intellectual Property ==
As soon as Milagro is accepted into the Incubator, Certivox (now MIRACL)
will transfer the source code and trademark to the ASF with a Software
Grant, and licensed under the Apache License 2.0. Certivox/MIRACL
retains rights to its existing MIRACL mark.

== External Dependencies ==
There are no external dependencies and all software is under the sole
ownership of Certivox/MIRACL.

== Cryptography ==
This is advanced cryptographic software, and as such may be subject to
government interest and red tape in some countries. However, the
architecture by which SD-DSM / Crypto Apps are distributed, via open
source freely available code repositories, is intentional to exploit the
near universal interpretation of the Wassenar agreement to permit export
of open source cryptography without restriction (in most cases).

== Required Resources ==
Mailinglists:

 * private
 * dev
 * users

Git repository (to mirror existing github repo)

 * https://git-wip-us.apache.org/repos/asf/incubator-milagro.git

Issue Tracking

 * JIRA repository to be requested

==== Trust Authority Service ====
The podling would like to request a VM at
"ta.milagro[.incubator].apache.org" with which to run a Community Trust
Authority.  It is anticipated that this will serve as a test facility
for developers and may become a Trust Authority for the community of ASF
committers.

== Initial Committers ==
 * Akira Nagai             (NTT)
 * Brian Spector           (Certivox/MIRACL)
 * Fuji Hitoshi            (NTT)
 * Genoveffa Pagano        (Certivox/MIRACL)
 * Go Yamamoto             (NTT)
 * Jordan Katserov         (Certivox/MIRACL)
 * Kealan Mccusker         (Certivox/MIRACL)
 * Kenji Takahishi         (NTT)
 * Michael Scott           (Certivox/MIRACL)
 * Milen Rangelove         (Certivox/MIRACL)
 * Mitko Yugovski          (Certivox/MIRACL)
 * Michael Scott           (Certivox/MIRACL)
 * Nick Kew                (Apache)
 * Nick Pateman            (Certivox/MIRACL)
 * Patrick Hilt            (Certivox/MIRACL)
 * Simeon Aladhem          (Certivox/MIRACL)
 * Stanislav Mihaylov      (Certivox/MIRACL)
 * Tetsutaro Kobayashi     (NTT)

== Sponsors ==
=== Champion ===
 . Nick Kew

=== Mentors ===
 * Sterling Hughes
 * Jan Willem Janssen
 * Nick Kew

=== Sponsoring Entity ===
 . The Apache Incubator



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message