We are pleased to announce our current technical white paper.

We welcome everyone to provide feedback and improve document.

Let`s start discussion and make it better together.

White paper

(v.0.1)
July 30, 2017

Contents

Background
REMME’s Edge
How REMME works
Use of multi-factor authentication
Conclusion
Links

Background

The goal of the REMME high-end secure system is to build a distributed Public Key Infrastructure (“PKI”) management on top of the x.509 standard [1] that will help big infrastructure companies, government authorities, financial and blockchain companies address the problem of security failings.

A look at the classical variant of certificate management used in most current systems shows that it is usually built in a hierarchical structure. This enables the certificates to be managed based on the certificate authority (CA) entity which stores, issues and signs the digital certificates.

The Certificate Authority uses a hierarchical tree system to build trust on the network all through to the root certificate. However, since the center of the system is always a point of attack, a compromise of the root certificate will expose the entire system to any form of vulnerability.

REMME will use the blockchain technology as a vehicle of transportation and a source of consensus to offer a solution to this problem: decentralization.

REMME’s Edge

Though not the first to build a distributed system using the blockchain technology to manage certificates, REMME comes with a difference from what DNS SSL by Namecoin developers [2] and EMCSSL [3] built on the Emercoin technology have to offer as the first to use the blockchain and SSL.

While the DNS SSL system allows the binding of DNS to the certificate hash, the EMCSSL built on the Emercoin decentralized solution for storing the key-value bundle enables the serial number of the certificate to be the key and the certificate hash as the value. The key is unique and the hash value can be changed. By this way, certificate management is implemented.

REMME differs from these two systems as it does not save the certificate’s data on the blockchain at the initial point. A revocation of the certificate has to be carried out by publishing a secret revocation message, which is signed by a private key of the network blockchain address. The scheme, which is used to connect blockchain address with a certificate, is very similar to the proxy certificate mechanism described in RFC3820 (X.509 Proxy Certificate Profile). [4]

How REMME works

In our case, the message is a normal blockchain transaction. The mechanism is very similar to that of classic certificate management systems, in which certificate revocation lists are used to manage CRLs. This comes in a data format that publishes a list of revoked certificates and signed by a Certificate Authority. There is an OCSP extension, which allows the central server to manage the status of certificates.

REMME also provides a self-managed certification center for the owner of the private key to the network’s block address as a unique opportunity for the decentralized management of certificates by the user. The same address is also an account on systems that use REMME authentication.

The system can be used with a number of different blockchains (Bitcoin, Emercoin, Ethereum, etc.) and sidechains (Rootstock, Exonum, etc.) by customer's choice. This document covers technology solution based on the Bitcoin network.

The four basic types of REMME certificates are determined according to the signature of the publisher:

1. Self-signed certificates;
2. Certificates signed by the organization;
3. Certificates signed by the certifying center REMME;
4. Certificates signed by an official certifying center

The first 3 types of certificate differ only in the subscription method, while the changes in the fourth type are related to the limitations of the certification centers and its use of the imperfection of the existing mechanism to issue certificates.

This document does not consider x.509 in details. To understand this document, it is advisable to get acquainted with RFC5280 [5] and a general idea of how the blockchain works. In short, the blockchain system is a data storage technology in a sequential chain based on a set of rules that allows users to add new data. All participants can use the consensus mechanism to add data at the same time, however data from the blockchain cannot be deleted. The unique identifier in the block system is the hash of the public part of the key (let it be the address in the future) while the private part of this key signs the data added to the blockchain.

Bitcoin addresses are identifiers that are used to send bitcoins from one person to another.

The REMME technology provides:

• the ability to associate a bitcoin address with a certificate;
• the ability to organize a decentralized system for revocation of certificates.

The address is linked by signing key certificate data such as the public key's hash, the hash of the revocation transaction etc using the private key. The certificate can be revoked by using the "warrant canary" mechanism [6]. A common bitcoin transaction is created - one of the outputs of which will be the activity marker of the certificate. As soon as the output is spent, the certificate is considered withdrawn. In RFC 6960 [7], it is described that in OCSP the answer can add CRLReason (the cause of revocation of the certificate) but this is not used in the basic version of REMME.

CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

In the certificate, it is necessary to save:
● Signature by private address key
● Hash of revoke transaction {txOutHash}
● Exit number of the revocation transaction {txOutNumber}

1. The first type is a self-signed certificate in which accessLocation [8] from OCSP [9] has a special format.

   AccessDescription ::= SEQUENCE {
   accessMethod OBJECT IDENTIFIER,
   accessLocation GeneralName }

   http://ocsp.REMME.io/{$txOutHash}/{$txOutNumber}/

This allows the server client to query the OCSP server about the status of the certificate even if the client does not know about the existence of the REMME add-on. But then, the service becomes centralized hence using this method is not recommended. The signature of the private address key is written to the extension x509 nsComment.

1. For the second type of certificate for the structure of additional data, REMME repeats the first type, but the certificate itself is signed by the private key of the organization that issued the certificate.

2. The third type of certificate is the same as the second type except that REMME acts instead of an organization and the certificate data is checked by the REMME certificate authority.

3. The fourth type of certificate is needed to enable the use of decentralized REMME technology in conjunction with the CA, which has no idea of the existence of REMME. In other words, there is no way to change the fields that the CA fills on its own, but the mechanism allows the use of traditional certification centers.

Though signed by third parties, the second and third types of certificate allow users to revoke the certificate using their own signature as well as the signature of the CA.

The standard X.509 certificate consists of several fields. The "Name of the subject" field is one of the most important fields. This field specifies the unique name (Dname) of the certificate owner. Dname is a unique name that points to an X.500 directory object. It consists of several attribute-value pairs (RDNS). Some of the most common RDN names are:

CN: CommonName
OU: OrganizationalUnit
O: Organization
L: Locality
S: StateOrProvinceName
C: CountryName

Example of subject:
CN=Sample Cert, OU=R&D, O=Company Ltd., L=Dublin 4, S=Dublin,C=IE

In the case of the fourth type of certificate, fields will be filled with special values:

O=Bitcoin 
UID=12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX (Bitcoin address)     
OU=0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd51298 (A transaction hash that marks a revoke of 
certificate)
ST=0 (transaction output number) 
L=Hy15Vc5HFHisgkB5sUiithUC6i0uPETcVBVYHHpMQePbTK6ZNwOombXS+I/PnouqYrkmV7H4Wl6egIyQuJc70Xs=(Signature 
by private address key)

All other values are set according to the needs of the CA.

The signature for all types of the certificate is formed by signing a special format message with a private address key.

Sign ("http://REMME.io/certificate/" + Certificate serial number + "/" + Public key hash + "/" + Revocation transaction hash + "/" + Revocation transaction number)

The certificate can be revoked using the "warrant canary" mechanism. A common bitcoin transaction is created - one of whose outputs will be the activity token of the certificate. As soon as the output is spent, the certificate is considered withdrawn:

gettxout 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098 0 
{ 
"bestblock" : "000000000000000000ff4c920d339f7211125f01957ac6d42a876162025764f9", "confirmations" : 462282, 
"value" : 50.00000000, "scriptPubKey" : { "asm" : 
"0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e
0a604f8141781e62294721166bf621e73a82cbf2342c858ee OP_CHECKSIG", 
"hex" : 
"410496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d
4e0a604f8141781e62294721166bf621e73a82cbf2342c858eeac", 
"reqSigs" : 1, 
"type" : "pubkey", 
"addresses" : [ 
"12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX" 
] 
}, 
"version" : 1, 
"coinbase" : true 
} 

In Bitcoin node, this mechanism is used as any full Bitcoin node keeps an indexed list of all UTXO (unspent transaction output) in its memory and replies to such requests are very fast and efficient.

Scenario for client authentication:

1. Check certificate.
2. Check signature of the certificate.
3. Check that the certificate data is signed with the private key of blockchain account.
4. Find UTXO (unspent transaction output) with number N of the hash transaction with hash X. If this output is unspent, then the certificate is still active.

Use of multi-factor authentication

The two-factor authentication is an additional layer of security ensuring that only the owner of the account can access it, even if the private SSL certificate key has been compromised. Multifactor authentication is a cryptographic system that allows access only in the case of a mathematically conditioned conjunction of several keys [10]. Commonly, the first key is generated according to one factor and is then used to decrypt the second one.

E.g., ATM systems around the world utilize a relatively successful two-factor authentication implementation. For more than 30 years, banks' clients obtain secure access to their accounts and withdraw cash using a PIN code and a bank card. This technological approach was remarkably successful due to its notable ease of use and, nonetheless, cryptographically solid authentication method. The ATM network does not store any credentials exchanged between the server and the client. No information regarding tokens, contacts or passwords is ever transmitted over the wires between the ATM and the bank. If any part of the system is compromised, it does not permit access to any other part.

The choice of technology for the second factor depends on the characteristics of the system, which is protected by REMME technology. However, when choosing technology, it should be taken into account that the more reliable the authentication solution is, the more complicated and expensive it is to use. Therefore, it is vital to choose the optimal balance between reliability and complexity.

For example, if a system requires a physical presence of an authorized person, then the best option for the second factor would be to use biometric data, such as a fingerprint scan or an eye retina scan. This data can be used to validate the certificate. [11]

If the system uses some local sensor, then the second factor would be the physical connection to the local network check.
If the system is remote, it is optimal to use a secondary device (a phone or another PC). The probability of simultaneous malware infection of two devices is lower than of one. It would also help to protect the account with a compromised certificate.

One of the simplest variations of two-step authorization is to use two separate certificates on two different devices. In this case, the use of one certificate should be confirmed with the second one. Additionally, an instant messenger can be installed on the second device to receive secret keys via messages from a protected system. In this case, the reliability of the second factor will be equal to the reliability of the messenger account. For example, it is possible to use Telegram (or other messengers), email, or email + PGP key.

Special consideration should be given to the standard TOTP (time-based one-time password) method, which generates one-time codes within certain time intervals (e.g., every thirty seconds). Such a scheme is implemented, for example, in the Google Authenticator application. [12] You can also use an entirely-hardware solution for generating access tokens, for instance with the help of YubiKey [13], Yubico or Trezor [14].

Conclusion

The goal of the REMME high-end secure system is to help organizations like infrastructure companies, IoT, medtech, financial and blockchain companies protect sensitive data. It is a distributed Public Key Infrastructure (“PKI”) management technology built on top of the X.509 certificate standard that uses SSL to protect the entire channel from an attack.

REMME does not save the certificate’s data on the blockchain at the initial point. A revocation of the certificate has to be carried out by publishing a secret revocation message, which is signed by a private key of the network blockchain address. According to this approach, user do not need to wait for few confirmation, the certificate will be valid immediately after creating transaction. The system can be used with a number of different blockchains (Bitcoin, Emercoin, Ethereum, etc.) and sidechains (Rootstock, Exonum, etc.) by customer's choice.

The two-factor authentication is an additional layer of security ensuring that only the owner of the account can access it, even if the private SSL certificate key has been compromised. The choice of technology for the second factor depends on the characteristics of the system, which is protected by REMME technology.

During the development of the REMME system, a number of standard and well-known components that are time-tested and proven effective by numerous audits were used.

Links

1. https://www.rfc-editor.org/rfc/rfc5912.txt
2. https://namecoin.org/
3. http://emercoin.com/EMCSSL
4. https://www.ietf.org/rfc/rfc3820.txt
5. https://tools.ietf.org/html/rfc5280
6. https://en.wikipedia.org/wiki/Warrant_canary
7. https://tools.ietf.org/html/rfc6960
8. https://tools.ietf.org/html/rfc5280#section-4.2.2.1
9. https://tools.ietf.org/html/rfc6960
10. https://www.miracl.com/miracl-labs/m-pin-a-multi-factor-zero-knowledge-authentication-protocol
11. http://www.cse.lehigh.edu/prr/Biometrics/Archive/Papers/Uludag05.pdf
12. https://www.google.com/intl/ru/landing/2step/features.html
13. https://www.yubico.com/products/yubikey-hardware/
14. https://trezor.io/