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