Source: cryptor        GUIDES |   July 14th, 2015   

We consider the scalable infrastructure for passwordless authorization for an unlimited number of independent web servers.

Система идентификации пользователей на основе криптовалюты EmerCoin

The infrastructure is based on blockchain cryptocurrency, using the latter as a decentralized trust store hash-sums of the SSL client-certificate. Sami certificates can be generated by clients locally, without the involvement of any external authorization service, and quickly replaced as needed, making effective as the planned replacement and quick recall of compromised certificates.

Also offered InfoCard system - decentralized distributed "business cards", with the ability to organize information in a hierarchical structure, which can be useful for quick content updates card member companies or other organizations.

Sharing offered services allows you to quickly, literally in one click to create and update accounts and have password-less login and secure connection with unlimited multiple servers.

The novelty of the proposal is to complete the system of decentralization, ie the absence of a group authorization servers under a single management that takes place in the Kerberos system, OpenID, TeddyID and the like. As a result, it is impossible to lock the user through the administrative resource, or the simultaneous denial of service throughout the system of authorization due to technical failures or malicious attacks on authentication servers.

Current state of affairs

In today's Internet the main way of authenticating the client to the server is password system. Her idea is that you are familiar with a secret password, which makes it a site in the authorization process, and this confirms their identity. This system, with external simplicity, has a number of disadvantages:

  • Weak passwords. Usually the right to come up with the password given to the user and he often comes up with a password that can easily be picked up in the dictionary or vocabulary variations. Details can be found here:

  • Complex passwords. To avoid weak passwords, many sites force people to invent complicated passwords, which must contain certain characters. As a result, sites exhibit excessive "clarity", and for them, even password «mWxbq7LECJ7m4Gtu95L» looks weak. And as password requirements are not standardized, the password can be rejected for another reason - for example, the above-stated password was rejected by some website, as its length exceeded 16 characters.

  • The complexity of managing passwords. Since there is no uniform standard requirements for passwords, it is impossible to create a universal password generator, the result of which is suitable to all sites. As a result, people invent "Password Keeper" - such as password-protected the master password repository, where all the other passwords are. In addition, many sites require regular password change that leads to the fact that this is simply not remember your password, and record anywhere, not to forget. Needless to say, the password entry in the clear - a direct path to the compromise?

  • The need for a unique password for each site. Since at login to the site you want to submit your password (that is, to reveal the secret), even in the event of good conduct site password can be intercepted in transit over the network, or stolen as a result of hacking site that is relatively regular. In the case of using the same password for different sites, leakage of the password, simply leading to catastrophic consequences - the owner, in case of suspicion of a password being compromised, forced to frantically to remember this password where he once used, and immediately get -srochno all of the sites and change your password (if you have time).

  • Recover forgotten and lost passwords. Surely this all faced, and passed the procedure of proving that "I am not a camel."And some when the procedure until the end of the pass and fails, and you have to throw your account (account).

There is an alternative

Currently, there are a number of solutions from different vendors. So, in the corporate sector is quite popular RSA Token - a special device that generates one-time passwords every few minutes. And these passwords must be entered on the website of the relevant company.

Also, there are more client SSL-certificates for browsers. In this case, a user buys a certificate signed by a trusted authentication center that costs money - as in the case of extension of the certificate, and in the case of the withdrawal and replacement in case of compromise. Much of the price, the constant reliance on the CA and complexity of generating the certificate with the participation of the center to the end user, making this authentication mechanism is practically inapplicable for the masses, so that this mechanism has received limited distribution in corporate networks, and the broad masses is virtually unknown, although technologically It is amazingly effective.

There is also an option when the authorization for use of a certificate issued by the same website, and only to them, and is recognized for a certain site. It is free for the customer, but leads to a permanent job of keeping urgency base certificates. It is easy to notice that if you have accounts on 52 sites (it is the actual number for the user of the Internet) and using standard certificates for a period of 1 year, on average once a week you will need to update a particular certificate.

Again, it certification procedure involving an external trusted agent is very complicated and is not standardized, making it necessary to study the characteristics of the interaction with all of them. 
Therefore, the last option, despite the technical perfection of the protection, the spread has not received practical and unlikely to receive in the future.

It is also worth mentioning the decision of cryptocurrency NXT «authorization token» - Its essence lies in the fact that for each pair (site, username) generates a unique authentication token that the client makes a server at login, and the checks received by token blockchain NXT. Unfortunately, this mechanism does not provide security, since the authorization token is passed as a whole, making it possible to intercept attacks the medal Main-In-the-Middle, or phishing sites or something similar, with the subsequent malicious and unlimited use of the token interceptor.

As now uses SSL

Currently, the most popular mechanism for the protection of the network connection is SSL - Secure Socket Layer. The most widespread system of server certificates, that is, the mechanism when the server to the client proves that he - he is, and not a fraudulent duplicate server. In addition to proof of the authenticity of the server, SSL establishes an encrypted connection between the client and the server. Here's how it works:

Как сейчас используется SSL

A typical installation of secure SSL-connection:

  1. The server sends its SSL-certificate containing a public key encryption, the user

  2. The user verifies the signature on the certificate and verifies that the server certificate was issued by a trusted agent who can be trusted.

  3. The user sends a random number, encrypted by the public key from the server

  4. In case of successful decoding of the numbers on the server establishes a secure SSL session

However, this protection mechanism of connection can be opened, if an attacker was able to make himself in the list of "trusted agents" for the user's browser, through the introduction of the system or the browser "fake" root certificate. Such an attack can be made, for example, on a corporate network where the administrator can implement their certificates in the "trusted agents" list and then organize an attack "man in the middle" in the https-connection. The example below illustrates this attack:

Проблема SSL соединений

SSL connection problem. If there is a possibility of introducing false root certificate X.509 to user devices (for the purpose of tracking, the traffic control), for example, in the corporate sector, there is the possibility of attack "man in middle"

  1. The server sends the public SSL key user

  2. The attacker intercepts a certificate and their substitutes.

  3. The user checks podmenёnny certificate, but the check is successful, since the attacker already listed of trusted agents, and believe him.

  4. The user encrypts a random number with a fake certificate and sends imaginary server, in fact - the man in the middle, man-in-the-middle.

  5. An attacker successfully decodes the number of users than establish a secure connection to the user. At the same time, the attacker establishes a secure connection to another server using the real server certificate.

  6. Running SSL connections to compromise under the attacker's control

The client is SSL-certificates that the client and the server prove their authenticity, is now hardly used time, and for client authentication using password mechanism.

Introduction to emcssl

Our login system is based on client SSL-certificates, which provide both client authentication and the creation of a secure encrypted link to the server - that is, all secure communications services in one package. Unlike other SSL-systems, our system does not have a trusted certificate authority, and the role of the latter performs a decentralized blokcheyn cryptocurrency EmerCoin. Thus, the client SSL-certificates without restrictions and interaction with someone else can be completely and quickly generated on the client side, and updated many times.

Note that only the client SSL-certificate can be reused for authorization on any server in the system, without compromising security. Thus, the user (you) for a normal life Interactive enough single certificate that radically simplifies the support of a huge group of accounts, and saves you from tens and hundreds of password management. The only exotic sense to have more than one certificate at a time not associated with safety (it is on top), and the possible need to have some "masks", that is, different variants of the account. 
In addition, emcssl will not permit an attack of the type described above, since the server checks the blokcheynu - whether it was a real certificate from the client, or podmenёnny (see below).

These differences make it possible to declare the practical applicability of our authentication system in the broad masses.


Excluding the possibility of attack «man in middle» via blokcheyna (emsssl application):

  1. The user sends the SSL-certificate server

  2. The server authenticates the received certificate for a signature stored in the NVS distributed repository.

  3. Secure SSL session is set only if the certificate of identity (no substitute).

As it looks to the user?

  1. You run the program locally, and generate (or update) the personal SSL-certificate.

  2. You publish (or update) "digital signature" certificate EmerCoin NVS.

  3. You upload the certificate to the browser.

  4. Paragraphs 1-3 should be done only one time. After that, during the term of the certificate lifetime (in our system, it is 5 years old by default, can be changed) you just do the following:

  5. Magic! You go to any site that supports the system, and log in to your account without a user name and password.Everything is done automatically! As if you have a "perpetual login."

  6. And if the account at this site did not previously exist - you just press the button of the "create a new account on the basis of the certificate," and entry is automatically created! Moreover, the user profile on the server is automatically populated with the data that you provide when the certificate generation. You can not give them, it is your right. But it is very nice when one clique immediately fill full.

How it works in practice

To generate user certificates emcssl you need to download the toolkit from the site for your operating system, and unzip to any directory. No installation is required. Toolkit consists of three * .sh scripts for unix-like operating systems. The Windows-based version also contains a set of win-bash and the openssl utilities, as well as the * .bat files that trigger the corresponding * .sh-script. The site also contains a link to the test page that you print the contents of the certificate and the InfoCard emcssl, if present.

Consider the process of generation and use of a certificate step by step.

1. Generate a template.

First, you generate the certificate template with the help of the first program, The program consistently asks you future certificate attributes:

  • CommonName - the user name. This parameter is required. As such, you can use loign name, username, or a first and last name, separated by a space.

  • Email - your e-mail address. This parameter is optional, can be skipped. But if you specify - it can be used by the server to populate the appropriate account field.

  • UID - Optional. This is a link to more information about the certificate owner, which he wants to give himself. As such, it is used to link EmerCoin infocard (prefikc NVS-service info). EmerCoin infocard blokcheyne stored in encrypted form, and info-link contains the decryption key. Thus, access to information is not anyone, but only those sites that you use a certificate that contains the link.

As a result of this program, a certificate template is created - a file containing the attributes you entered, and having a random name, represents the serial number of the certificate and the future suffix * .tpl, for example, 84aa5f2c6527eb33.tpl.

Further, based on this template will be able to generate different certificates with the same parameters. This will allow you to easily and conveniently update the certificates on their expiry date, or if you suspect that the certificate was compromised.

If desired, you can generate multiple patterns from which then produce more than one certificate, and then update the last if necessary.

2. Certificate generation.

Next comes the actual generate (or update) the certificate. To do this, we run the program, passing it as a parameter to the template file. Sample call: 
./ 84aa5f2c6527eb33.tpl

The program generates a self-signed certificate (file * .crt), and download the package in the browser (* .p12), containing a certificate and its associated private key. In the process of generating a package program asks you to enter a password. This password will then be prompted by the browser during download package (see. P. 4). Password protect the contents of the file * .p12 from further unauthorized use of this file. As a result, even if the file itself has been stolen, the attacker can not use it without knowing the password.

The private key that was used to generate a packet immediately removed as a separate use is not subject to the package. Upon completion of the work, in addition to creating two files (* .crt, * .p12), the program prints out an important message, such as:

Your new certificate in the file 84aa5f2c6527eb33.p12 
Please, deposit into EmerCoin NVS pair: 
Key: ssl: 84aa5f2c6527eb33 
Value: sha256 = 52cfd176a00756646fc73b6eecdf53c4d51cd077cc9b4ea49dd9bf660337fb52

The first line reports the name of the freshly generated * .p12 file. You will download it to the browser in step 4. Next - printed couple "key-> value" (in bold) to be loaded into the NVS-subsystem EmerCoin. Important: A pair of "key-> value" is printed only once, it will not be saved. We need to use it "off the screen." If it still turned out to be lost - do not worry, simply generate a new certificate from the same template, and you will have a new pair.

In the future, only the * .p12 file to be used from svezhesgenerirovanyh files. File ownership certificates, * .crt - left only "for reference". You can view it in a text editor and look at the structure and attributes of the certificate. If desired, * .crt file can be deleted.

3. Loading pair EmerCoin NVS.

Using a graphical interface EmerCoin name_new purse or command (in the case of a replacement certificate - name_update) emercoind command line, load NVS couple mentioned above. Wait a few block acknowledgments (though a confirmation is usually enough) - it's about 5-15minut. Once confirmation has appeared - congratulations! You have successfully registered your certificate in emcssl distributed system, and can proceed to the final stage. In the extremely unlikely event of a conflict (its probability is lower win millions in the lottery) when NVS does not accept your pair from the fact that a key has already been registered - repeat steps 1-3 again, thereby generating the certificate with a different serial number.

4. Download the package * .p12 in the browser and use.

Now, after a successful registration certificate in EmerCoin NVS, you can download the file * .p12 into the browser and start using all the advantages emcssl system. Download our packages does not differ from normal download client SSL-certificates is done through the respective setup menu of a browser. Examples of specific guidelines for

In general, the need to go to settings and find items such as Advanced / Security / Certificates, and then click the Import button, and upload your * .p12 file. In the process of import will need to enter a password, which you defended in claim 2 package. After downloading the certificate, some browsers (like Google Chrome) require a restart.

So, the work is done, and now remains to get an award for it - that is, without a password safe to walk to the sites, and if necessary - there automatically create accounts on the basis of certificates. Let's examine how this works.

  1. When you browser to it are present in the certificate goes to the party site system, the site requires a browser to present a client certificate. If the client has no certificate, or he refuses to present, the server, depending on its configuration, or moves to the password authentication scheme, or refuses to work on. We assume that there is a certificate, and the browser is ready to present his request on the server. The very first time you visit the site the browser will ask you "certificate then ask such a fit of storage, which will show?". You select the certificate and the browser at stores that have to go to this server with a certificate, and more than this question does not ask. Also, the browser can be set auto-select mode, but we do not recommend.

  2. The server received the certificate, first verifies the signature certificate. The successful signature verification proves that the certificate was generated for EMCSSL system, and no more. There is a discrepancy with the classic use of the certificate, which certifies the signature of the certificate and the values of other fields. In this case, only the signature verifies that the certificate is generated for this system, and no more. The rest of the check will be made on.

  3. The server generates a random number, encrypts it on the public key is placed in charge brought the certificate, and sends to your browser. This will be a one-time password for this (and only this) connection.

  4. Browser, with a full file * .p12, extracts the secret key, and decrypts the password sent by the server. The browser establishes a secure https-connection to the server. The fact that such a connection proves to the server that the browser has not only the presented certificate and its corresponding private key that is proof that the bearer of the certificate has a full * .p12 file. Note that in this system the private key never leaves your computer. You generate it locally, or locally using a browser. Thus, even if your certificate will be stolen by unscrupulous server or intercepted during transmission over the network, use it no one but you will still not be able to, as the attacker will not mate - a secret key.

  5. The server, making sure that the client has a valid private key, the certificate verifies the information through EmerCoin blokcheyn. To do this, it extracts from the certificate serial number, and performs EMC NVS search on a single serial number, getting what you downloaded in the Value field - certificate hash. The server calculates a checksum of newly received certificate and makes sure that the presented certificate with the appropriate serial number - the same one who was involved in the registration of pair NVS. In other words, the server verifies that the client, the certificate contains the number of N - this is the same client that previously came with the same number - the date of registration numbers in NVS.Thus, it verified the unique serial number of the certificate, which can be used for user authentication. Indeed, if an intruder will generate a different certificate with the same serial number as yours, then it will not be able to download the checksum in the NVS, as it is already occupied by you. And if it will generate a certificate with a different serial number - it will be a different ID, and the server will create another account for him.

After these inspections (which in reality occur in fractions of a second), the server verifies that the client has come:

  • It has the certificate of our system, but not horrible.

  • He owns private key.

  • He owns the relevant certificate serial number.

And it gives you access to your account.

Note that only the serial number of the certificate is verified in this system, which is your UserID. When the next generation of certificates, you can edit the file * .tpl, and to make other field values CN / Email / UID, and then generate a new certificate to replace it in the browser and change the checksum in the corresponding entry in the NVS. After that, the old certificate will be useless as claimed in claim 5 cease to be inspected.

The latter opens up the possibility of operative revocation and replacement certificate - both on the slightest suspicion of compromise of the certificate, and just as you wish. You can always quickly generate a new certificate from the same template, and reboot value in NVS. All this does not require interaction with the external certification authority, listing reviews and other things of the same kind.

The server can retrieve the certificate from your field CN (username) and Email, and instantly complete the minimum values of the fields of your profile when you create it. Additionally, the certificate may contain a value in the UID field (can be omitted). This value represents a link to infocard - additional information that you want to give yourself. The information is also stored in the NVS, but is encrypted and not available to everyone. UID field contains also the decryption key for InfoCard. Thus, access to the information contained in infocard can only get the server to which you are presented a certificate.

United possibility infocard emcssl and opens the possibility of creating a detailed and complete account simply by clicking - without entering a new password, fill in information about yourself, an email verification, and more. Click - and you're done! 
Also, due to the extended capabilities EmerCoin, in it there is an interesting possibility to send the payment in the name of the NVS. Thus, it becomes possible to obtain a secure payment. A server using this mechanism, guaranteed sends the payment to the owner of the certificate and no one else. Thus, even in case of hacking your account, it is impossible to replace her address and withdraw funds somewhere besides your wallet. We believe that the use of this opportunity to raise the security of exchanges and pools.

FAQ Frequently asked questions and their answers.

- Is it possible the same * .p12 file to download in multiple browsers? And on different computers? 
- Yes, you can!

- What if I stole a laptop or tablet, which was established by the browser with the certificate? 
- Then you need to generate a new certificate can be more quickly, and upload it to a digital signature in EmerCoin NVS. This step will automatically take the stolen certificate invalid. Fortunately, in this case you need to replace only one certificate, and not dozens of them. - And what more way you can protect the certificate from unauthorized use? - We need a computer or tablet to set a password to the attacker even after the computer is stolen could not be reached immediately to your the browser and start doing all. Additionally, some browsers (eg Firefox) allow to set an option in the settings, you need to enter the password for the certificate (which you entered when generating package * .p12) each time you use the certificate. As far as it is practical - you decide. There is also a possibility to store certificates in cryptographic hardware devices format PKCS # 11 (, but unfortunately, not all browsers support these devices. In any case, it's more a problem of your browser and control over the computer, not the network connection.

- Still, if an attacker got to my browser - which means that he can no password to visit all my sites participating in the system? 
- Well, yes. This system authorizes only computer (or rather, the browser) and makes the network connection safe, but do not authorize the operator - it is considered that the operator "a". For verification in critical services and the operator is also better to use multi-factor authentication - for example trёhfaktornuyu - on certificates, passwords, and cell phone. Emcssl not a silver bullet, and can not solve all the possible data protection issues. It is an effective alternative mechanism for storing passwords in the browser, the establishment of a secure connection without the possibility of interception on the network and auto-complete fields when registering another account, rather than a comprehensive security system for all occasions.

- And why EmerCoin? Can I use other blokcheyny cryptocurrency? 
- Can. If these are distributed cryptocurrency general purpose storage with an open interface, such EmerCoin NVS. The vast majority of cryptocurrency do not have anything like this. And store the ones that have (Namecoin, NXT) - have limitations that reduce either the functionality or security of the system.

- And where else, this system is already in operation? You can see it? 
- Yes, you can! This system, as one of the authentication mechanisms used in the main pool EmerCoin:

- How to access EmerCoin NVS service? 
- We need a purse free download EmerCoin wallet c, purchase some way a small amount of Emerkoinov, and upload your captions in a distributed database. - And how much is the signature download ? - Depends on several factors, but it is possible to navigate in the amount of ¼ EMC to download a single pair. At the current rate 1EMC = 0.02USD, we believe the price of half a cent for 5 years (the life of the certificate) is completely accessible to anyone, even the inhabitants of the poorest countries.

- And why not do it all free? 
- Payment services NVS introduced as a means of protection from malicious blokcheyna filling "junk information". This amount is acceptable for anyone, but not wanting to inflate blokcheyn to tens of gigabytes.

- And where you can buy EMCs? 
- You can buy or get them in any other way in any of the owner, on to the pool or namaynit, or receive as payment for their assistance in the world of science project folding @ home: /folding_home/about_en.php 
If you decide to buy, you can do this on the Exchange 
Or visit the forums where you will be helped: 
the Russian-speaking -pos 
English speaking 
you can write a private request

- And what happens to EMCs, spent on downloading a pair? Probably in the purse to the author? 
- Is burned. In other words, are permanently removed from the market, that is not captured by anybody.

- Good. For how long is best to record a couple? 
- We recommend the registration period of 6-10 years or more. When the term update value does not "burn", and a new life period is added to the residue of the old. In this case, the first certificate will expire, and the sites no longer accept it. And only after 1-5 years term expires recording actions in NVS. We believe that this time is enough to generate a new certificate and update the record. This approach will prevent a situation where an attacker registers a certificate after NVS-recording with the same serial number, and gain access to the accounts of the previous owner of the serial number. There is a direct analogy to the domain name - if the name does not renew in time, it will expire and will be able to capture anyone else. Fortunately, there is provided a simple recipe how to avoid a similar situation.


InfoCard - data format by which people or organizations can voluntarily report themselves some personal or corporate data. Its mission structure is somewhat similar to a business card (paper or electronic * .vcf), or user entry in the LDAP-directory.

InfoCard - alone product that uses the NVS-subsystem EmerCoin, and generally speaking, can be self-sufficient. However, the true value of it gets when sharing certificates c emcssl, UID field which contains a reference to infocard (UID). Thus to obtain server certificate infocard user can retrieve and use the information for filling out infocard online user profile, or contact with it on the basis of information contained in infocard, including payments in a specified cryptocurrency infocard address.

Here we see an analogy with the OpenID system in which the user can use to authenticate the site profile in any other known site such as facebook. However, unlike OpenID, infocard decentralized system, and does not depend on the health of a server as well as its behavior. For example, you can assume a hypothetical situation where facebook for the reasons to remove or block your account, and you no longer have the ability to write on dozens of forums, which had previously come through facebook OpenID.

In addition, in contrast to the storage of additional information OpenID, LDAP, vCard, which record (card) contains all the information about the person (or position), InfoCard recording allows you to import the information from other records that are already in the system. It becomes convenient for workers' organizations or other hierarchical structures.

For example, in the record of the organization may be contained infocard-system (for certainty - the company), which is incorporated in the company name, address, phone number and other attributes. A infocard-entry workers directive include imports of this general information worker business card. Then, if, for example, the company changed the phone number or office moved to a different address, or the company merged with another, and changed the name - all of these changes will be incorporated into a single infocard-record of the company, after which the cards of other workers, importing this information will be updated automatically and will contain the latest information. And now remember how many times you were handed a small, in which the hands of the crossed out phone number and entered another. That's right!

Link to infocard-record is as follows: the info: infocard_key: infocard_password

  • info - service prefix NVS system

  • infocard_key - key to find cards NVS

  • infocard_password - password decrypt the card

As noted above, all entries in infocard-partition is encrypted, and can not be removed by direct analysis blokcheyna. However, given the link that contains the password will be able to easily remove the record. 
The record structure in infocard simple, and allows you to edit the file in the usual text editor.

Let us consider an example Infomap (line numbers in real Infomap available):

1 Alias superabdul # Short name (username, login) 
2 FirstName Abdul # First (short) name 
3 LastName AbstulZadomBey # Remain part of full name 
4 HomeAddress 
5 Sinan Pasa Mah. Hayrettin Iskelesi # Free form address 
6 Sok. No \ # 1 # Free form address 
7 Besiktas, Besiktas # Free form address 
8 Istanbul # City 
9 # ZIP code 34353 
10 Turkey # Country 
11 HomePhone + 90-555-123-4567 
12 WorkPhone + 90-555-123-4568 
13 CellPhone + 90-555-123-4569 
14 Gender M 
15 Birthdate 27.05.91 # May, 27 1991 
16 Email 
17 WEB 
18 Facebook Abdul.AbstulZadomBey 
19 Twitter AbdulAbstulZadomBey 
20 EMC EdvJ7b7zPL6gj5f8VNfX6zmVcftb35sKX2 # EmerCoin payment address 
21 BTC 1MkKuU78bikC2ACLspofQZnNb6Vz9AP1Np # BitCoin payment address

Each entry represents a set (in the mathematical sense) pairs: 
the Key (one or more spaces) of value 
the Value - can contain spaces.

Alias superabdul # Short name (username, login)

After the key card processing can have multiple values, declared a general list for a given key. To add values to the desired key, they must enter the lines that begin with a space, that is, without its key. An example is HomeAddress in rows 4-10. 
The characters "#" and the fact that the right is a commentary and deleted when the card is read. If you need to enter the symbol "#" inside a string-value, it is necessary to him to put the escape character "\", as is done in line 6 example. 
Import the contents of the other possible infocard Import command like:

Import info: 2f2c5a7c57d60668: 74744c6e4443df490eab0807052bb9

Let multiple imports, that is possible to import multiple Infomap in yours. 
It must be borne in mind that when you enter Infomap lines are processed sequentially, from top to bottom, in sequence by modifying the contents of the result set. So let's say a sequence of instructions:

+ 90-555-123-4567 HomePhone 
HomePhone + 90-555-123-0000

It will create a unique value to HomePhone - + 90-555-123-0000. The previous value is overwritten.

To be able to correctly combine the values of the imported cards and their own, entered the qualifiers for the key. This is the "+" before or after the key. Plus before the key means "add this value to the tail of the list" after the key - "add this value to the head of the list." Without qualifiers - remove list for this value, and enter the current, if any. The examples below demonstrate these options:

+ 90-555-123-4567 HomePhone 
+ HomePhone + 90-555-123-0000 
Result: HomePhone -> [+ 90-555-123-4567] [+ 90-555-123-0000]

+ 90-555-123-4567 HomePhone 
HomePhone + 90-555-123-0000 + 
Result: HomePhone -> [+ 90-555-123-0000] [+ 90-555-123-4567]

+ 90-555-123-4567 HomePhone 
Result: HomePhone -> [] (the empty list)

This mechanism provides the flexibility to combine the imported values with their own. 
For the suppression of abuses and attacks on the system, the total number of imports is not in generating a response greater than 20. We believe that this is enough for any conceivable hierarchical structures. Also, of course prohibited circular dependency structure. In this case, the link on the ring is not imported.


In summary, it can be argued that the certificate infrastructure is proposed here has in common with these or other products and systems. So, naturally, it is a central part of a custom SSL-certificates, which are poorly useful in their original design, but are very useful and convenient in the proposal.

You can also specify a mechanism to security checks similar applied in Kerberos, which the client receives from the Kerberos server "authorization token", and the actual services server for Kerberos token prompts the decision what to do with this client. In this case, instead of a centralized server using decentralized EmerCoin NVS, as well as a unique token to detect a successful acts in NVS certificate serial number. Servers and services instead of Kerberos request to the central server of the client is verified in the local copy of the NVS, through requests to the local EmerCoin wallet.

The proposed InfoCard system also has much in common with the LDAP or OpenID, but unlike the latter is decentralized, and has import mechanism is absent in analogues that can effectively maintain the relevance of large maps of groups. 
But all together - create a safe and convenient mechanism. How to login to the site and automatically fill in the profile of new accounts.

How to get started

All software is distributed free of charge. Package client certificate generation is here:

You can also check the operation of your certificate on the test page, and download the full contents of this simple example server test page in PHP, and based on the code contained in the example, add the authorization emcssl in your server.

Scan QR Code & Share