v.0.2November 16, 2017

remme.io© 2017 REMME. All rights reserved.

Technical Whitepaper

Authentication DApp, powered by REMME Core network

1. Introduction 3

2. Proof of concept 6

3. REMME product evolution 8

3.1. Consensus algorithm 10

3.2. Pricing policy 11

3.3. Inter-blockchain token migration 11

3.4. Certificate support 12

3.5. 2FA 13

4. Architecture 14

5. Token model 16

6. Roadmap 17

7. Use cases 21

7.1. Example 1 (managed system with public data) 21

7.2. Example 2 (private blockchain) 22

8. Conclusion 23

Links 24

!2

1. Introduction The primary means of accessing various local and network resources today is via

password, a method that has proven itself as a way of identifying and securing

users and resources. However, it has one serious drawback: in the event of a

password being stolen, the attacker gains access to all of the account-holder’s

data. Moreover, because users often deploy the same password for multiple

services, the situation is exacerbated, while weak passwords can be a subject to

vocabulary attack. Password databases from a variety of resources periodically

fall into open access, exposing hundreds of millions of passwords to hackers [1].

Even where the affected user has the ability to change their password, their

account is still vulnerable, since the user's mailboxes are usually protected by a

password that is often the same as that used on other resources. Thus,

passwords cannot serve as a sufficient instrument for protecting user data and

guaranteeing the security of the user session.

One solution to this problem is password managers. This software, which

provides a secure storage system for passwords, often integrated as a browser

extension, is able to withstand numerous attack vectors. Password managers are

often able to generate secure passwords that are unique to each resource, which

takes security to a new level. The obvious drawback to such protection is that

the storage is protected with a master password (Lastpass, 1Password), and in

the event of theft or bruteforcing the master password, the previously discussed

vulnerabilities apply.

Two-factor authentication (2FA) attempts to solve password problems. With 2FA,

in addition to password protection, the resource demands additional data that

should be available only to a particular user. Examples of 2FA include:

!3

1) One-time passwords that are generated every n seconds are the most

common option. Usually implemented with TOTP protocol.

2) One-time passwords sent in a message. Usually, SMS or instant

messengers are used.

3) Hardware tokens.

Another way of authorizing a user to access the system is with SSL/TLS

certificates, which are widely adopted in enterprise solutions such as banking

and tax services. An integral part of SSL certificates is their public key

infrastructure, which enables administrators to manage those certificates.

Modern PKI systems are built on the so-called "chain of trust": there is a root

certification authority that signs certificates for other centers. Other centers, in

their turn, sign certificates for end customers.

The key drawback to this system is that the entire framework is tied to trust in

the root and affiliated certification centers. If one of the links or root certificates

in the system becomes unavailable, the system completely loses its efficiency.

The critical point is the trusted certification authority and centralized

architecture.

�

!4

To combat these problems, we’ve trialled different approaches to decentralized

public key infrastructure based on blockchain technology. An efficient approach

to this problem should give end users a means of managing their PKI with high

fault tolerance (as the system is distributed) and a high level of trust.

REMME solves the following issues: 1. Trusting the centralized certification authority (CA)

2. CA keys being compromised

3. Fake certificate issuance

4. Issuance of "hidden" certificates, trying to intercept and redirect connections

This allows complete and transparent control and tracking of all issued

certificates, no possibility for issuing "hidden" certificates, and eliminated

attempts to intercept and redirect connections.

Various parties (including Google) have tried to solve those issues, but without

success [2]. Blockchain systems ensure the immutability of data stored within

them, providing an effective and practical solution.

!5

2. Proof of concept

!

To solve the problems posed by centralization in current PKI systems, a system

based on the Bitcoin protocol was proposed. This concept formed the basis of

the second version of REMME. Hereinafter, the use of self-signed X.509

certificates is implied [3]. In this system, Bitcoin software serves the following

tasks:

1) Certificate revocation management. Each certificate is bound with an

output of a certain Bitcoin transaction. The certificate is considered invalid

when this output is spent.

!6

2) Certificate authentication. Each certificate stores a digital signature of a

string (signed by the certificate holder; the string itself will be referred as

“canary string” [4]) defined by REMME standard and the Bitcoin address

of the certificate holder. In possession of that, the certificate data can be

used to form the string mentioned above and to check the validity of the

signature using the given Bitcoin address.

In the system framework, the following certificate fields are used:

Canary string is formed from the following pattern: https://REMME.io/

certificate/$CERT_SN/$PUBKEY_HASH/$CERT_OU/$CERT_ST, where:

$CERT_SN –  certificate serial number;

$PUBKEY_HASH – SHA256 hash of the certificate public key;

$CERT_OU – the identifier of the used transaction;

$CERT_ST – the number of the used transaction output.

This string is signed with the signmessage function of the standard Bitcoin

implementation (Bitcoin Core) and included in the corresponding field of the

certificate.

So the full process of creation of REMME-compatible certificates looks as

follows:

1) Generate a key pair.

UID Bitcoin address of the certificate holder.

L Digital signature of the canary string signed with Bitcoin signmessage.

OU The identifier of a transaction used for certificate revocation management.

ST The number of an output of the transaction mentioned above.

!7

2) Create a Bitcoin transaction to be used for revocation management.

3) Create a certificate and fill its subject fields according to REMME

specification.

4) Create a canary string.

5) Sign the canary string with the signmessage function.

6) Add the canary string to the corresponding certificate field.

7) Sign the certificate.

To check the certificate:

1) Fetch the certificate.

2) Ensure that the associated transaction output is unspent (i.e. the

certificate is valid).

3) Form the canary string from the certificate data.

4) Check the signature of the canary string included to the certificate using

Bitcoin’s verifymessage function.

This proposed system enables its users with certificate management based on

Bitcoin’s distributed storage ledger. It is worth noting that this system is highly

portable because it is based on features which are essentially the same for most

existing blockchains.

3. REMME product evolution Though not the first to build a distributed system using the blockchain

technology to manage certificates, first iteration or REMME was with a difference

from what DNS SSL by Namecoin developers [5] and EMCSSL [6] built on the

Emercoin technology have to offer as the first to use the blockchain and SSL.

!8

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, as mentioned above. 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). [7]

However, a system based on an existing cryptocurrency has obvious drawbacks:

low throughput and high transactional costs. So the solution is to build our own

decentralized system with a financial system which suits the product needs.

For such a system there are three main requirements:

1) The pricing policy should be pegged to an existing currency such as the

US dollar.

2) The blockchain should have high throughput to maintain quick certificate

management.

3) There should be the possibility of creating a private blockchain to be

integrated into different organizations.

!9

3.1. Consensus algorithm

The requirement for high throughput makes the consensus algorithm a crucial

part of the system. Widely adopted proof-of-work (PoW) consensus is not an

optimal solution for this task, because it is based on a high amount of

computation and thus can lead to unacceptable delays in the system [8]. Thus it

makes sense to research possible algorithms which do not involve vast amounts

of computation and which are fast enough. In addition, the consensus algorithm

itself should incentivize users to be online and serve as many transactions as

possible.

Existing consensus algorithms that allow for high performance are:

1) Proof-of-Stake (PoS). Uses the number of cryptocoins held by a user: the

more coins that are held, the higher the possibility that the user will be

chosen to produce a new block. As an additional factor, with many

systems, the user must hold a number of coins no lower than a defined

threshold value. The drawback to this method is that there is still a

possibility of a double-spending attack occurring. In attempting to solve

this problem, some cryptocurrencies have selected different approaches

that have evolved from PoS. For example, NEM tries to use other

parameters like uptime, but their impact on the system lowers with the

growth of the amount of coins on a node [9].

2) Proof-of-Authority (PoA). In this consensus algorithm, the list of nodes

allowed to create new blocks is stored in the blockchain. As the list of

nodes is fixed, it is easy to create a deterministic consensus algorithm

which will select the nodes in a fixed order. Private by design, such a

consensus algorithm can be extended to have a public system with high

performance. For example, Clique protocol allows for nodes to be added

and removed from the list by simple voting of the authorized nodes [10].

!10

The consensus algorithms mentioned above have one thing in common: they

always have a predefined set of nodes which fits certain requirements and the

order of nodes to produce a new block is defined by a consensus algorithm

itself, not by computing capability or anything else. As it is planned to use the

system as a public service as well as an integrated private system, two cases

should be maintained. The case of a private system is a typical use case of PoA,

because such systems usually have a fixed list of nodes maintaining the network.

As for the public system, to make the platform consistent, PoA consensus can be

extended in such a way that any node may nominate itself to the list of

authorized nodes and may be automatically added based on certain criteria like

the number of coins on its balance, uptime and so on.

3.2. Pricing policy

As one of the requirements is to peg prices to a fiat currency, the platform needs

some means of updating the prices for its services with respect to the exchange

rate of the token. Proposed methods are:

1) To use a trusted node owned by REMME to update prices stored on the

blockchain. The address of this node will be fixed to the software

specification.

2) Each node forms its own pricing lists based on a specified algorithm and

prices are updated by the node which produced a new block. Checks on

the accuracy of pricing lists should be included with the block verification

algorithm.

3.3. Inter-blockchain token migration Inter-blockchain token migration is needed to prepare for a migration

mechanism. This will enable users to utilize REM token, initially released on the

Ethereum platform, on the REMME blockchain. In terms of the current status of

!11

the project, the optimal choice is a centralized system similar to Waves

cryptocurrency gates. The idea is that one of the nodes is tracking transactions

in both Ethereum and REMME. When a user sends tokens to this node on

Ethereum (with the user’s REMME address enclosed in metadata – a smart

contract may be needed), the same amount of token is sent to the user’s

account on REMME, and the system works in the same way for transferring REM

to the Ethereum blockchain [11].

3.4. Certificate support

As in the first version of the system, X.509 certificates are used. The following

use cases are supported:

1) Self-signed certificates. In this case certificate data, such as public key,

signature, expiration date, and revocation status are stored on the

blockchain.

2) Certificate signed by an organization. In this case an organization (which

is our client) may use its own certificate to sign and manage certificates of

its clients and employees.

To support REMME-based certificates, integration of server-side software is

planned which will continuously check for the status of the certificate on the

blockchain. There can be different ways of achieving this, such as implementing

plugins for content management systems or incorporating self-signed

certificates to the system’s trusted certificates list. In the framework of this

system, the following certificate fields will be exploited:

Field Usage

Organization name

REMME

UID The address of a user on the REMME blockchain.

!12

3.5. 2FA

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 [12]. Commonly, the first key is generated according to one factor

and is then used to decrypt the second one.

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, the more complicated and expensive it is to use.

Therefore, it is vital to attain an optimal balance between reliability and

complexity.

For example, if a system requires the physical presence of an authorized person,

then the best option for the second factor would be to use biometric data, such

as a fingerprint or eye retina scan. This data can be used to validate the

certificate [13].

If the system uses some form of 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. This would

also help to protect an account with a compromised certificate.

One of the simplest variations of two-step authorization is to use two separate

!13

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 [14]. It is also possible to use a hardware-only

solution for generating access tokens, for instance with the help of YubiKey [15],

Yubico, or Trezor [16].

4. Architecture Based on the system requirements, the following list of system components is

formed:

1) REMME Core. The main task of this component is to safely and reliably

store self-signed certificates and handle their revocation status [17]. When

used as a public service, it is also responsible for payment processing.

a) In the framework of the REMME blockchain, there is a separate

type of nodes, called master nodes, which are responsible for

handling new block production. In a private network, the list of

master nodes is maintained by system administrators. In a public

!14

service it is maintained automatically as described in the

“Consensus algorithm” section.

b) Anyone can run a node which stores the whole blockchain for

verification purposes.

c) Most clients are supposed to work in light node mode. In this case,

the user is not required to store the whole blockchain, only certain

chunks of data that are needed to verify the user’s operations.

2) Client software (server side integration) needed to verify provided

REMME certificates.

3) Bitcoin anchoring system for improved auditability.

4) Oracle for pricing list updates. Needed as there is a requirement of

keeping prices bound to a fiat currency. This is also needed because the

system needs to know prices for Bitcoin and Ethereum as it is linked with

them.

5) The system for token cross-blockchain migration.

!15

5. Token model

!

REM token is needed for all internal operations inside of the ecosystem and

includes, but is not limited to, the following:

1) Initialization of a certificate creation process (an amount of tokens gets

blocked for revocation transactions).

2) Enabling a certificate revocation process.

3) Establishing a node (this option will be available after Q3 2018, see in

«Roadmap» section).

4) Fee for transferring REMME tokens between users on the REMME

blockchain.

5) Fee for cross-blockchain token transfers.

Fees structure will depend on amount raised:

1. Under $5 million USD raised during public token sale:

70% of those fees are stored on the account of a master node which created the

current block, while 30% are transferred directly to REMME and used to maintain

services such as Bitcoin anchoring, cross-blockchain transfers etc.

2. Between $5 million and $10 million USD raised during public token sale:

!16

80% of those fees are stored on the account of a master node which created the

current block, 20% are transferred directly to REMME and used to maintain

services.

3. Over $10 million USD collected during public token sale:

90% of those fees are stored on the account of a master node which created the

current block and 10% are transferred directly to REMME and is used to maintain

services.

Use cases with token flow examples: Usecase 1: Enterprise client from traditional economy (bank) wants to use

REMME. They pay REMME with fiat currency and REMME then exchanges this

for REM tokens and sends a percentage of the tokens to reward nodes for

certificates issuance.

Use case 2: Crypto exchange wants to use REMME. They buy tokens directly

from holders on the exchange where REM token is listed and send a percentage

of the tokens to reward nodes for certificate issuance

As more certificates are needed, the token price will increase considering the

limited token supply. Because the price for a certificate is fixed in fiat currency,

as mentioned above, it has nonlinear dependence.

6. Roadmap 1. Q4, 2015:

- Idea growth and concept validation

2. 2016:

!17

- REMME Core MVP V 0.1 with 2FA on Telegram based on Emercoin

blockchain.

- 5 pilot projects.

3. Q2 2017: - Blockchain Intensive Hackathon by Microsoft – winner.

- Memorandum of Understanding with Ukrinmash.

- Strategic partnership with Infopulse.

4. Q3 2017: - REMME Core MVP V 0.2 - CRL infrastructure on Bitcoin blockchain,

certificate generation in browser.

- White paper 1.0 release

- REMME’s 2018 Pilot program announced

5. Q4 2017: - December 4, 2017: Pre-sale for the REMME community whitelist.

- White paper 2.0 release

- Public GitHub release

6. Q1, 2018: - REMME Core public alpha

- Product security audits and pen-tests

- Extending team of software engineers

- REMME’s 2018 Pilot program launch

- Public sale phase.

- Legal structure

7. Q2, 2018:

!18

- At this stage private blockchains for integration with enterprise systems

will be implemented. The planned functionality is:

a) Blockchain-based certificate data storage.

b) Integration for different client systems.

c) Bitcoin anchoring for higher auditability.

- Open source integration libraries for websites and web applications

- Additional 2FA options such as Signal, Status, WeChat, Trezor

- Product security audits and pen-tests

- 20+ integrations

8. Q3, 2018:

- Public testing. At this stage a user can nominate themselves to become a

holder of a master node, which will be processed by the existing master

nodes and, if the user is eligible by all criteria, they will be included in the

list of approved nodes. At this stage, thanks to further development of

PoA, master nodes from the list of approved nodes will be added

periodically by REMME maintainers. Prices will be updated in a

centralized manner (see “Pricing policy”) from a REMME maintainer’s

trusted node. New prices will take their place after 10 confirmation of the

block they were introduced in. By this stage, the system will also have

cross-blockchain token transfers so that everyone who purchased REMME

tokens will be able to take full advantage of the service.

- REMME Core integration with Active Directory and SCADA systems

- Extending of decentralized ecosystem of nodes

- Product security audits and pen-tests

- Opening sales office in London: hiring dedicated sales responsible for EU,

extending existing marketing team and hiring support team.

!19

- 50+ integrations

9. Q4, 2018:

- At this stage the release of the public system is planned, so the process

of master node management on the public service will be fully automatic

without involving REMME maintainers.

- The consensus algorithm update is also planned. Master nodes are

ranked according to their performance and stability of operation (or

uptime) every n seconds. When a new block appears (every m seconds),

the pseudorandom algorithm selects one of the nodes in proportion to its

rank (the higher the rank the higher the possibility for the node to be

selected), and the system waits for the block signed by this node to

appear. If the selected node does not produce a new block for more than

k seconds, the algorithm automatically proceeds to the next node. In this

way, the system ensures maximum adherence to the specified parameters

and motivates the master nodes to remain in the system.

- Building DApps for IoT on top of REMME Core (with a focus on

automotive and smart cities)

- Product security audits and pen-tests

- Opening sales office in New York: hiring dedicated sales team

responsible for US, extending existing marketing team and hiring support

team

- 100+ integrations

10. Q1, 2019

!20

- Opening sales offices in Tokyo and Singapore: hiring dedicated sales

teams responsible for Asian market, extending existing marketing team

and hiring support team for the region

- Holding special cybersecurity events once every 3 months

- Special cybersecurity lessons and classes in Ukraine for training specialists

to contribute to the REMME ecosystem

7. Use cases

7.1. Example 1 (managed system with public data) A cryptocurrency exchange service adopts REMME for client authorization to

replace the default system with login password pairs. The number of users on

the site is 25,000, of which 20,000 are active. Daily workload is 2,000 users/day.

Monetization: the service pre-pays for a required number of certificates (valid

for 1 year) so that end users do not have to pay for certificates. Every year the

service pays for new certificates for its users.

Certificate validity: only for the service.

2FA: REMME provides the service with the software to provide messenger-

based 2FA.

User capabilities: - Generate a certificate.

- Quickly revoke the certificate if secret key is compromised.

- Automatically obtain a certificate when the old one has expired.

- Select a preferred 2FA method.

Administrator capabilities: - Reliable payment system (with REMME tokens).

- System monitoring (issued and revoke certificate numbers).

!21

- Root certificate management.

- Issuance of a new certificate when the old one has expired.

7.2. Example 2 (private blockchain)

A state company wants to integrate REMME for user authorization on its internal

services. Capability: up to 1,000 users.

Monetization: payments for integration and support.

Certificate validity: only for this service, using different certificates for different

components of the system.

2FA: hardware token.

User capabilities: - Generate a certificate.

- Quickly revoke the certificate if secret key is compromised.

Administrator capabilities: - System monitoring (issued and revoke certificate numbers, active

sessions).

- Root certificate management.

- Manage validity of certificates for different components of the system.

- Issuance of a new certificate when the old one has expired.

- Possibility to revoke user certificates as quickly as possible.

- Edit users’ data stored on the blockchain.

!22

8. Conclusion The objective of REMME’s secure system is to help organizations such as

infrastructure companies, IoT, medtech, financial, and blockchain companies

protect sensitive data. REMME will operate as a distributed Public Key

Infrastructure (“PKI”) management technology built on top of the X.509

certificate standard that uses SSL/TLS 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 the private key of the network

blockchain address. The REM token is needed for all internal operations inside

of the ecosystem, and thus operates as a utility token.

Hybrid PoS+PoA consensus is used for a mix of high throughput, scalability, and

security. With this approach, users do not need to wait for multiple

confirmations, as the certificate will be valid immediately after creating the

transaction.

Two-factor authentication provides an additional layer of security ensuring that

only the owner of the account can access it, even if the private SSL/TLS

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. REMME will use the blockchain technology as a vehicle of

!23

transportation and a source of consensus to offer a solution to this problem:

decentralization.

Links 1. Verizon data breach investigation report

2. http://www.certificate-transparency.org/

3. X.509 specification

4. https://en.wikipedia.org/wiki/Warrant_canary

5. https://namecoin.org/

6. http://emercoin.com/EMCSSL

7. https://www.ietf.org/rfc/rfc3820.txt

8. Proof-of-work description

9. Proof-of-stake description

10. Ethereum Clique PoA protocol description

11. Waves gate to Ethereum

12. https://www.miracl.com/miracl-labs/m-pin-a-multi-factor-zero-

knowledgeauthentication-protocol

13. http://www.cse.lehigh.edu/prr/Biometrics/Archive/Papers/Uludag05.pdf

14. https://www.google.com/intl/ru/landing/2step/features.html

15. https://www.yubico.com/products/yubikey-hardware/

16. https://trezor.io/

17. Our Github repositories

All materials contained in this presentation (whitepaper) are protected by copyright laws, and may not be reproduced, republished, distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior written permission of REMME ltd and REMME LLC. REMME’s names and logos and all related trademarks, tradenames, and other intellectual property are the property of REMME ltd and REMME LLC. and cannot be used without its express prior written permission from REMME ltd and REMME LLC.

!24