EMCSSL - WWW user identification system based on the NVS cryptocurrency subsystem EmerCoin and decentralized client SSL certificates
Under the cat discussed in detail the scalable infrastructure for password-free authorization to an unlimited number of independent servers on the network.
The infrastructure is based on a cryptocurrency blockchain, using the latter as a decentralized trusted repository of hash sums of client SSL certificates. Certificates themselves can be generated by clients locally, without the participation of any external authorization services, and quickly replaced as needed, which makes both scheduled replacement and quick revocation of compromised certificates effective.
An InfoCard system is also proposed - decentralized distributed “business cards”, with the possibility of organizing information into a hierarchical structure, which can be useful for quickly updating the contents of cards of members of companies or other organizations.
')
Sharing the proposed services allows you to quickly and easily, in just one click, create and update accounts, as well as have a password-free login and a secure connection to an unlimited set of servers.
The novelty of the proposal lies in the complete decentralization of the system, that is, the absence of a certain group of authorization servers under a single management, which takes place in the systems Kerberos, OpenID, TeddyID and the like. As a result, it becomes impossible to block a user through an administrative resource, or a one-time denial of service to the entire authorization system due to technical failures or malicious attacks on authorization servers.
In the modern Internet, the main method of client authentication on the server is the password system. Her idea is that the user knows a certain secret password, which he presents to the site during the authorization process, which confirms his identity. This system, with external simplicity, has a number of significant drawbacks:
Currently there are a number of solutions from various suppliers. So, in the corporate sector, RSA Token is quite popular - a special device that generates one-time passwords every few minutes. And these passwords must be entered on the website of the relevant company.
There are also client SSL certificates for browsers. In this case, the user buys a certificate signed by a trusted authorization center, which costs money - both in the case of renewal of the certificate, and in the case of revocation and replacement in case of compromise. The significant price, constant dependence on the certification center and the complexity of generating a certificate with the participation of this center for the end user, makes this authentication mechanism practically inapplicable for mass use, as a result of which this mechanism has received limited distribution in corporate networks, and is widely unknown among the masses. is amazingly effective.
There is also an option when for authorization uses for a certain site a certificate issued by the same site and only recognized by them. It is free for the client, but leads to ongoing work to maintain the relevance of the certificate database. It is easy to see that if you have accounts on 52 sites (a very real number for an Internet user), and use standard certificates for a period of 1 year, then on average once a week you will have to renew one certificate or another.
Again, the certification procedure with the participation of an external trusted agent is very complex and not standardized, which leads to the need to study the features of interaction with all of them.
Therefore, the last option, despite the technical perfection of protection, did not receive practical distribution and is unlikely to receive in the future.
Also worth mentioning is the NXT “authorization token” cryptocurrency solution - nxtcoin.wikia.com/wiki/Nxt_Software . Its essence lies in the fact that for each pair (site, username) a unique authorization token is generated, which the client presents when logging in to the server, and the latter checks the received token through the NXT blockchain. Unfortunately, this mechanism does not provide security, since the authorization of a token is transmitted entirely, which makes it possible to intercept a token with a Main-In-the-Middle attack, or with a phishing site or something like that, followed by malicious and unlimited use of the token.
Currently, the most popular network connection protection mechanism is SSL - Secure Socket Layer. The most widespread system of server certificates, that is, the mechanism when the server proves to the client that he is the one, and not a fraudulent duplicate server. In addition to proving the authenticity of the server, SSL establishes an encrypted connection between the client and the server. Here's how it works:
A typical example of setting up a secure SSL connection:
However, this connection protection mechanism can be opened if the attacker managed to add himself to the list of “trusted agents” for the user's browser, by introducing into the system or the browser a “fake” root certificate. Such an attack can be made, for example, in the corporate network, where the administrator can inject his certificates into the list of "trusted agents" and then organize a man-in-the-middle attack on the https connection. The example below illustrates this attack:
SSL connection problem. If there is the possibility of introducing a fake X.509 root certificate onto user devices (for the purpose of tracking, traffic control), for example, in the corporate sector, the possibility of a man in middle attack will arise
The client SSL certificates, which the client also proves to the server for its authenticity, are currently almost not used, and a password mechanism is used to authenticate clients.
Our authorization system is based on client-side SSL certificates that provide both client authentication and the creation of an encrypted secure channel to the server — that is, all the secure connection services in one package. Unlike other SSL-systems, our system does not have a trusted certificate authority, and the role of the latter is performed by the Emercoin decentralized blockchain cryptocurrency. Thus, client SSL certificates without restrictions and interactions with anyone can be completely and quickly generated on the client side, and updated as many times as necessary.
Note that a single client SSL certificate can be reused for authorization on any server that is included in the system without compromising security. Thus, a user (you) for a normal Internet life needs only a single certificate, which radically simplifies the support of a huge group of accounts, and saves you from managing dozens and hundreds of passwords. The only exotic sense to have several certificates at the same time is not connected with security (it is at the height), but with the possible need to have several “guises”, that is, different account options.
In addition, emcssl does not allow for the type of attack described above, since the server checks on the blockchain - whether it received a real certificate from a client, or a substitute (see below).
These differences allow us to declare the practical applicability of our authorization system in the masses.
Exception of the possibility of man-in-the-middle attacks using the blockchain (emssl application):
To generate emcssl user certificates, you need to download the toolkit from the pool.emercoin.com/emcssl website for your OS, and unpack it into a directory. No installation required. Toolkit consists of three * .sh scripts for unix-like OS. In the Windows version, there is also a set of win-bash and openssl utilities, as well as * .bat files that run the corresponding * .sh scripts. The site also contains a link to a test page that prints you the contents of the emcssl certificate and InfoCard, if present.
Consider the process of generating and using a certificate step by step.
So, the work has been done, now it remains to receive a reward for it - that is, without passwords, it is safe to go to the sites, and if necessary - to automatically create accounts there based on certificates. Let's take a closer look at how this works.
After all these checks (which actually happen in a split second), the server makes sure that the incoming client:
And gives you access to your account.
Note that in this system only the serial number of the certificate is verified, which is your UserID. When generating subsequent certificates, you can edit the * .tpl file, and enter there other CN / Email / UID field values, then generate a new certificate, replace it in the browser and change the checksum in the corresponding entry in the NVS accordingly. After that, the old certificate will become useless, since it will cease to pass the test of item 5.
The latter opens up wide opportunities for prompt revocation and replacement of a certificate, either because of the slightest suspicion of compromising a certificate, or simply at your request. You can always quickly generate a new certificate from the same template, and reload the value in NVS. All this does not require interactions with an external certification authority, inclusion in the list of reviews and other things of the same kind.
The server can extract the CN (user name) and Email fields from your certificate, and instantly fill in the minimum field values ​​of your profile when it is created. In addition, the certificate may contain a value in the UID field (may be missing). This value is a link to the infocard - additional information that you wish to provide about yourself. Information is also stored in NVS, but is encrypted and inaccessible to all comers. The UID field also contains the decryption key for the infocard. Thus, access to the information contained in the infocard can be obtained only by the server to which you presented the corresponding certificate.
The combined capabilities of infocard and emcssl opens up the possibility of creating a detailed and complete account just by clicking - without entering a new password, filling in information about yourself, verifying an email, and so on. Click - and you're done!
Also in connection with the advanced features of EmerCoin, there is an interesting opportunity to send a payment to a name from NVS. Thus, it becomes possible to receive a secure payment. The server, using this mechanism, is guaranteed to send the payment only to the certificate holder, and to no one else. Thus, even if your account is hacked, it is impossible to replace the address in it and withdraw funds somewhere other than your wallet. We believe that using this feature will enhance the security of exchanges and pools.
- Is it possible to load the same * .p12 file into several browsers? And on different computers?
- Yes, you can!
- And if my laptop or tablet was stolen, which had a browser with the certificate installed?
— , EmerCoin NVS. . , , .
— ?
— , . , ( Firefox) , ( *.p12) . – . PKCS#11 (http://en.wikipedia.org/wiki/PKCS_11), , . , , .
— -, – , , ?
— . (, ) , – , «». , – — , . mcssl , . , , .
— EmerCoin? ?
— . , EmerCoin NVS. . , (Namecoin, NXT) — , , .
— - ? ?
— , ! , , EmerCoin: pool.emercoin.com
— EmerCoin NVS ?
— EmerCoin wallet c sourceforge.net/projects/emercoin/files , - , .
— ?
— , ¼ EMC . 1EMC = 0.02USD, 5 ( ) , .
— ?
— NVS « ». , .
— EMCs?
— - , pool.emercoin.com , folding@home: emerfor.org/folding_home/about_en.php
, www.livecoin.net
, :
forum.bits.media/index.php?/topic/3408-emc-emercoin-pos
bitcointalk.org/index.php?topic=362513.0
team@emercoin.com
— EMCs, ? ?
— . , , .
— . ?
— 6-10 , . update value «», . , , . 1-5 NVS. , . , NVS- , . – , - . , , .
InfoCard – , . - (, *.vcf), LDAP-.
InfoCard – , NVS- EmerCoin, , . c emcssl, UID infocard (UID). infocard , infocard , , infocard, infocard .
Here we see an analogy with the OpenID system, in which the user can authorize a site to use a profile on some other known site, for example facebook. However, unlike OpenID, the infocard system is decentralized, and does not depend on the performance of a particular server, as well as its behavior. For example, you can assume a hypothetical situation when facebook, due to its own considerations, deleted or blocked your account, and you no longer have the opportunity to write on dozens of forums that you previously logged into through Facebook OpenID.
, OpenID, LDAP, vCard, () ( ), infocard , . .
, infocard- ( — ), , , . infocard- . , , , , , – infocard- , , , . , , . That's the same thing!
infocard- :
info:infocard_key:infocard_password
, infocard- , . , .
infocard , .
( ):
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 34353 # ZIP code
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 abdul@bubbleinflators.com
17 WEB bubbleinflators.com/superabdul
18 Facebook Abdul.AbstulZadomBey
19 Twitter AbdulAbstulZadomBey
20 EMC EdvJ7b7zPL6gj5f8VNfX6zmVcftb35sKX2 # EmerCoin payment address
21 BTC 1MkKuU78bikC2ACLspofQZnNb6Vz9AP1Np # BitCoin payment address
( ) :
Key ( ) value
Value – .
Example:
Alias superabdul # Short name (username, login)
key values, key. values key, , , key. HomeAddress 4-10.
“#” , . “#” -, “\”, 6 .
infocard Import :
Import info:2f2c5a7c57d60668:74744c6e4443df490eab0807052bb9
, .
, , , . :
HomePhone +90-555-123-4567
HomePhone +90-555-123-0000
HomePhone — +90-555-123-0000. .
, key. “+” key. key « value », key — « value ». – , , . :
HomePhone + 90-555-123-4567
+ HomePhone + 90-555-123-0000
Result: HomePhone -> [+ 90-555-123-4567] [+ 90-555-123-0000]
HomePhone + 90-555- 123-4567
HomePhone + + 90-555-123-0000
Result: HomePhone -> [+ 90-555-123-0000] [+ 90-555-123-4567]
HomePhone + 90-555-123-4567
HomePhone
Result: HomePhone -> [] (empty list)
This mechanism gives you the flexibility to combine imported values ​​with your own.
To curb abuses and attacks on the system, the total number of imports in generating one answer cannot exceed 20. We believe that this is sufficient for any conceivable hierarchical structure. Also, ring dependency structures are naturally forbidden. In this case, import by ring link is not performed.
Summarizing the above, it can be argued that the certificate infrastructure proposed here has common features with various products and systems. So, of course, its central part is custom SSL-certificates, which are not very useful in their original design, but become very useful and convenient in the proposed one.
You can also point to a security check mechanism similar to that used in Kerberos, where the client receives an authorization token from the Kerberos server, and the service server itself by the token requests Kerberos to decide what to do with this client. In our case, instead of a centralized server, a decentralized EmerCoin NVS is used, and the serial number of the certificate registered in NVS is used as a unique token. The service servers also, instead of requesting the central Kerberos server, verify the client in the local copy of NVS, by querying the local EmerCoin wallet.
The proposed InfoCard system also has much in common with OpenID or LDAP, but, unlike the latter, it is decentralized, and has an import mechanism that its counterparts lack, which makes it possible to effectively maintain the relevance of large groups of maps.
But all together - creates a safe and convenient mechanism. Both authorization on sites, and automatic filling of a profile of new accounts.
. : pool.emercoin.com/emcssl
, PHP, , , emcssl .
The infrastructure is based on a cryptocurrency blockchain, using the latter as a decentralized trusted repository of hash sums of client SSL certificates. Certificates themselves can be generated by clients locally, without the participation of any external authorization services, and quickly replaced as needed, which makes both scheduled replacement and quick revocation of compromised certificates effective.
An InfoCard system is also proposed - decentralized distributed “business cards”, with the possibility of organizing information into a hierarchical structure, which can be useful for quickly updating the contents of cards of members of companies or other organizations.
')
Sharing the proposed services allows you to quickly and easily, in just one click, create and update accounts, as well as have a password-free login and a secure connection to an unlimited set of servers.
The novelty of the proposal lies in the complete decentralization of the system, that is, the absence of a certain group of authorization servers under a single management, which takes place in the systems Kerberos, OpenID, TeddyID and the like. As a result, it becomes impossible to block a user through an administrative resource, or a one-time denial of service to the entire authorization system due to technical failures or malicious attacks on authorization servers.
Current state of affairs
In the modern Internet, the main method of client authentication on the server is the password system. Her idea is that the user knows a certain secret password, which he presents to the site during the authorization process, which confirms his identity. This system, with external simplicity, has a number of significant drawbacks:
- Weak passwords. Usually, the right to invent a password is given to the user, and he often comes up with a password that can be easily selected according to the dictionary or variations of the dictionary. Details can be read here: www.volex-old.vlx9.ru/internet-news/3062
- Complex passwords. To avoid weak passwords, many sites force people to invent complex passwords that must necessarily contain certain characters. As a result, sites show excessive “legibility”, and even the password “mWxbq7LECJ7m4Gtu95L” seems weak to them. And since the requirements for passwords are not standardized, the password can be rejected for another reason - for example, the above password was rejected by a certain site, since its length exceeded 16 characters.
- The complexity of password management. Since there is no uniform standard for password requirements, it is impossible to create a universal password generator, the result of which is suitable for all sites. As a result, people invent “password keepers” - like the password stored on the master password of the repository, where all other passwords lie. In addition, many sites require a regular password change, which leads to the fact that such a password is simply not remembered, and recorded somewhere so as not to forget. Need I say that writing a password in clear text is a direct way to compromise it?
- The need for a unique password for each site. Since a login is required to provide a password (that is, to reveal a secret), even in the case of good website behavior, the password can be intercepted when sent over the network, or stolen as a result of hacking the site, which occurs relatively regularly. In the case of using the same password for different sites, the leakage of such a password simply leads to catastrophic consequences - the host, in case of suspicion of password compromise, has to frantically remember where he once used this password, and urgently bypass all sites and change the password (if you have time).
- Recover forgotten and lost passwords. Surely everyone faced this, and went through the procedure of proving that "I am not a camel." And here and there, the procedure is not fully completed and the account (account) has to be dropped.
Existing Alternatives
Currently there are a number of solutions from various suppliers. So, in the corporate sector, RSA Token is quite popular - a special device that generates one-time passwords every few minutes. And these passwords must be entered on the website of the relevant company.
There are also client SSL certificates for browsers. In this case, the user buys a certificate signed by a trusted authorization center, which costs money - both in the case of renewal of the certificate, and in the case of revocation and replacement in case of compromise. The significant price, constant dependence on the certification center and the complexity of generating a certificate with the participation of this center for the end user, makes this authentication mechanism practically inapplicable for mass use, as a result of which this mechanism has received limited distribution in corporate networks, and is widely unknown among the masses. is amazingly effective.
There is also an option when for authorization uses for a certain site a certificate issued by the same site and only recognized by them. It is free for the client, but leads to ongoing work to maintain the relevance of the certificate database. It is easy to see that if you have accounts on 52 sites (a very real number for an Internet user), and use standard certificates for a period of 1 year, then on average once a week you will have to renew one certificate or another.
Again, the certification procedure with the participation of an external trusted agent is very complex and not standardized, which leads to the need to study the features of interaction with all of them.
Therefore, the last option, despite the technical perfection of protection, did not receive practical distribution and is unlikely to receive in the future.
Also worth mentioning is the NXT “authorization token” cryptocurrency solution - nxtcoin.wikia.com/wiki/Nxt_Software . Its essence lies in the fact that for each pair (site, username) a unique authorization token is generated, which the client presents when logging in to the server, and the latter checks the received token through the NXT blockchain. Unfortunately, this mechanism does not provide security, since the authorization of a token is transmitted entirely, which makes it possible to intercept a token with a Main-In-the-Middle attack, or with a phishing site or something like that, followed by malicious and unlimited use of the token.
How SSL is now used
Currently, the most popular network connection protection mechanism is SSL - Secure Socket Layer. The most widespread system of server certificates, that is, the mechanism when the server proves to the client that he is the one, and not a fraudulent duplicate server. In addition to proving the authenticity of the server, SSL establishes an encrypted connection between the client and the server. Here's how it works:
A typical example of setting up a secure SSL connection:
- The server sends its SSL certificate containing the public encryption key to the user
- The user verifies the signature on the certificate and makes sure that the server certificate was issued by a trusted agent who can be trusted.
- User forwards random number encrypted with public key from server
- In case of successful decryption of this number on the server, a secure SSL session is established.
However, this connection protection mechanism can be opened if the attacker managed to add himself to the list of “trusted agents” for the user's browser, by introducing into the system or the browser a “fake” root certificate. Such an attack can be made, for example, in the corporate network, where the administrator can inject his certificates into the list of "trusted agents" and then organize a man-in-the-middle attack on the https connection. The example below illustrates this attack:
SSL connection problem. If there is the possibility of introducing a fake X.509 root certificate onto user devices (for the purpose of tracking, traffic control), for example, in the corporate sector, the possibility of a man in middle attack will arise
- The server sends the public SSL key to the user.
- The attacker intercepts the certificate and substitutes its own.
- The user checks the certificate that has been replaced, but the check is successful, because the attacker is already on the list of trusted agents, and they believe him.
- The user encrypts a random number with a fake certificate and sends it to an imaginary server, in fact, to a man in the middle, man-in-the-middle.
- The attacker successfully decrypts the user's number, which establishes a secure connection to the user. At the same time, the attacker establishes another secure connection to the server using this server certificate.
- Launching compromised SSL connection under attacker's control
The client SSL certificates, which the client also proves to the server for its authenticity, are currently almost not used, and a password mechanism is used to authenticate clients.
Introduction to emcssl
Our authorization system is based on client-side SSL certificates that provide both client authentication and the creation of an encrypted secure channel to the server — that is, all the secure connection services in one package. Unlike other SSL-systems, our system does not have a trusted certificate authority, and the role of the latter is performed by the Emercoin decentralized blockchain cryptocurrency. Thus, client SSL certificates without restrictions and interactions with anyone can be completely and quickly generated on the client side, and updated as many times as necessary.
Note that a single client SSL certificate can be reused for authorization on any server that is included in the system without compromising security. Thus, a user (you) for a normal Internet life needs only a single certificate, which radically simplifies the support of a huge group of accounts, and saves you from managing dozens and hundreds of passwords. The only exotic sense to have several certificates at the same time is not connected with security (it is at the height), but with the possible need to have several “guises”, that is, different account options.
In addition, emcssl does not allow for the type of attack described above, since the server checks on the blockchain - whether it received a real certificate from a client, or a substitute (see below).
These differences allow us to declare the practical applicability of our authorization system in the masses.
Exception of the possibility of man-in-the-middle attacks using the blockchain (emssl application):
- The user sends an SSL certificate to the server.
- The server verifies the authenticity of the received certificate against a signature stored in the NVS distributed storage.
- A secure SSL session is established only if the certificates are identical (no spoofing).
What does this look like to the user?
- You run the program and locally generate (or upgrade) a personal SSL certificate.
- You are publishing (or updating) the digital signature of the certificate in EmerCoin NVS.
- You upload the certificate to the browser.
- Items 1-3 must be performed only once. After that, during the lifetime of the certificate (in our system it is 5 years by default, it can be changed) you only do the following:
- Magic! Go to any site that supports this system, and log into your account without a login and password. Everything is done automatically! As if you have an "eternal login".
- And if the account on this site did not previously exist - you simply press the button “create a new account based on the certificate”, and the record is created automatically! Moreover, the user profile on the server is automatically filled with the data that you provided when generating the certificate. You can not provide them, it is your right. But it is very nice when one click immediately fills the full profile.
How it works in practice
To generate emcssl user certificates, you need to download the toolkit from the pool.emercoin.com/emcssl website for your OS, and unpack it into a directory. No installation required. Toolkit consists of three * .sh scripts for unix-like OS. In the Windows version, there is also a set of win-bash and openssl utilities, as well as * .bat files that run the corresponding * .sh scripts. The site also contains a link to a test page that prints you the contents of the emcssl certificate and InfoCard, if present.
Consider the process of generating and using a certificate step by step.
- Template generation
First, you generate a certificate template using the 1st program, gen_tpl.sh . The program consistently asks you for the attributes of the future certificate:- CommonName is the username. This is a required parameter. As such, you can use loign name, username, or just a first and last name, separated by a space.
- Email - your e-mail address. This parameter is optional, can be skipped. But if specified, it can be used by the server to fill in the corresponding account field.
- UID - Optional parameter. This is a link to additional information about the certificate holder, who he wishes to provide about himself. As such, it is supposed to use the link to EmerCoin infocard (prefix of the NVS service info). EmerCoin infocard is stored in an encrypted form on the blockchain, and the info-link contains a decryption key. Thus, not anyone has access to the information, but only those sites for which you use the corresponding certificate containing 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 representing the serial number of the future certificate and the * .tpl suffix, for example, 84aa5f2c6527eb33.tpl .
Further, on the basis of this template, it will be possible to generate different certificates with the same parameters. This will allow you to easily and conveniently renew certificates when they expire, or if you suspect that a certificate has been compromised.
If you wish, you can generate several templates, from which then produce several certificates, and then update the latter as needed. - Certificate generation
Next comes the actual generation (or update) of the certificate. To do this, run the program gen_crt.sh, passing it the template file as a parameter. Call example:
./gen_crt.sh 84aa5f2c6527eb33.tpl
The program generates the certificate itself (the * .crt file), and the download package into the browser (* .p12), containing both the certificate and the associated secret key. In the process of generating a package, the program asks you to enter a password. This password will subsequently be requested by the browser during the package download process (see clause 4). The password protects the contents of the * .p12 file from the subsequent unauthorized use of this file. As a result, even if the file itself was stolen, the attacker will not be able to use it without knowing the password.
The secret key that was used to generate the package is immediately deleted, since it cannot be used separately from the package. Upon completion, in addition to creating two files (* .crt, * .p12), the program prints an important message, like:
84aa5f2c6527eb33.p12
Please, deposit into EmerCoin NVS pair:
Key: ssl: 84aa5f2c6527eb33
Value: sha256 = 52cfd176a00756646fc73b6eecdf53c4d51cd077cc9b4ea49dd9bf660337fb52
The first line indicates the name of the newly generated * .p12 file. You will upload it to the browser in p 4. Next - the “key-> value” pair is printed (in bold) to be loaded into the Emercoin NVS subsystem. Important: A pair of “key-> value” is printed only once, it is not saved anywhere. It is necessary to use it "from the screen". If it is still lost - no problem, just generate a new certificate from the same template, and you will have a new pair.
In the future, only the * .p12 file will be used from the newly generated files. The file of the certificate itself, * .crt - is left only “for reference”. You can view it in a text editor and take a look at the structure and attributes of the certificate. If desired, the * .crt file can be deleted. - Loading pair in EmerCoin NVS.
Using the EmerCoin wallet GUI or the name_new command (if the certificate is replaced with the name_update) of the emercoind command line, upload the above pair to NVS. Wait for several confirmations of the block (although one confirmation is usually enough) - this is about 5-15 minutes. As soon as confirmation has appeared - congratulations! You have successfully registered your certificate in the emcssl distributed system, and you can proceed to the final step. In the extremely unlikely event of a collision (its probability is lower than winning a million in the lottery), when NVS does not accept your pair due to the fact that such a key is already registered - repeat steps 1-3 again, thereby generating a certificate with a different serial number. - Download package * .p12 in the browser and use.
Now, after successful registration of the certificate in EmerCoin NVS, you can upload the * .p12 file to the browser and start using all the advantages of the emcssl system. Downloading our packages is no different from downloading regular SSL client certificates, and is done through the appropriate settings menu of a particular browser. Examples of browser-specific guides:
Firefox: www.onlinehowto.net/install-ssl-certificate-in-firefox/784
Chrome: www.binarytides.com/client-side-ssl-certificates-firefox-chrome
IE: ipswitchmsg.force.com/kb/articles/FAQ/Using-client-SSL-certificates-in-Internet-Explorer-1307739573570
In general, you need to go to the settings, and find items like Advanced / Security / Certificates there, then click the Import button, and load your * .p12 file. In the process of importing, you will need to enter a password, which you defended in package 2 with. After downloading the certificate, some browsers (for example Google Chrome) need a restart.
So, the work has been done, now it remains to receive a reward for it - that is, without passwords, it is safe to go to the sites, and if necessary - to automatically create accounts there based on certificates. Let's take a closer look at how this works.
- When you go to the site of the system from the browser with the certificate that is in it, the site requires the browser to present the client certificate. If the client does not have a certificate, or he refuses to present it, then the server, depending on its settings, either switches to the password authentication scheme or refuses to work further. We assume that there is a certificate, and the browser is ready to present it at the request of the server. At the very first visit to the site, the browser will ask you "ask for a certificate here, do some of the repository fit, what will we show?" You choose a certificate, and the browser remembers that it is necessary to go to this server with such a certificate, and does not ask this question anymore. You can also set the auto-select mode in the browser, but we do not recommend doing this.
- The server, having received the certificate, first checks the signature of the certificate. A successful signature verification proves that the certificate was generated for the EMCSSL system, and no more. There is a discrepancy with the classic application of the certificate, where the signature certifies the values ​​of other fields of the certificate. In our case, the signature certifies only that the certificate is generated for this system, and no more. The remaining checks will be made further.
- The server generates a random number, encrypts it with a public key located in the submitted certificate, and sends it to your browser. This will be a one-time password for this (and only this) connection.
- The browser, having in itself the complete * .p12 file, extracts the secret key from it, and decrypts the password sent by the server. After that, the browser establishes a secure https connection to the server. The fact of establishing such a connection proves to the server that the browser owns not only the presented certificate, but also the corresponding secret key, that is, it proves that the certificate bearer owns the full * .p12 file. Note that in this system the secret key never leaves your computer. You generate it locally, and use it locally in the browser. Thus, even if your certificate is stolen by an unscrupulous server, or intercepted during transmission over the network, no one will be able to use it except for you, since the attacker will not have a counterpart - the secret key.
- The server, making sure that the client owns the correct secret key, verifies the certificate information through the EmerCoin blockchain. To do this, it extracts the serial number from the certificate, and searches in EMC NVS for this serial number, getting what you loaded into the Value field - the checksum of the certificate. After that, the server calculates the checksum of the certificate just received and makes sure that the certificate presented with the corresponding serial number is the same one that participated in the registration of the pair with NVS. In other words, the server makes sure that the client whose certificate contains the N number is the same client that came with the same number before, since the registration of the number in the NVS. Thus, a unique certificate serial number is verified, which can be used to authorize the user. Indeed, if an attacker generates another certificate with the same serial number as yours, he will not be able to load the checksum in the NVS, since it is already occupied by you. And if he generates a certificate with a different serial number, then this will be a different ID, and for him the server will create another account.
After all these checks (which actually happen in a split second), the server makes sure that the incoming client:
- Has a certificate of our system, and not anything.
- Owns the secret key.
- Owns the corresponding serial number of the certificate.
And gives you access to your account.
Note that in this system only the serial number of the certificate is verified, which is your UserID. When generating subsequent certificates, you can edit the * .tpl file, and enter there other CN / Email / UID field values, then generate a new certificate, replace it in the browser and change the checksum in the corresponding entry in the NVS accordingly. After that, the old certificate will become useless, since it will cease to pass the test of item 5.
The latter opens up wide opportunities for prompt revocation and replacement of a certificate, either because of the slightest suspicion of compromising a certificate, or simply at your request. You can always quickly generate a new certificate from the same template, and reload the value in NVS. All this does not require interactions with an external certification authority, inclusion in the list of reviews and other things of the same kind.
The server can extract the CN (user name) and Email fields from your certificate, and instantly fill in the minimum field values ​​of your profile when it is created. In addition, the certificate may contain a value in the UID field (may be missing). This value is a link to the infocard - additional information that you wish to provide about yourself. Information is also stored in NVS, but is encrypted and inaccessible to all comers. The UID field also contains the decryption key for the infocard. Thus, access to the information contained in the infocard can be obtained only by the server to which you presented the corresponding certificate.
The combined capabilities of infocard and emcssl opens up the possibility of creating a detailed and complete account just by clicking - without entering a new password, filling in information about yourself, verifying an email, and so on. Click - and you're done!
Also in connection with the advanced features of EmerCoin, there is an interesting opportunity to send a payment to a name from NVS. Thus, it becomes possible to receive a secure payment. The server, using this mechanism, is guaranteed to send the payment only to the certificate holder, and to no one else. Thus, even if your account is hacked, it is impossible to replace the address in it and withdraw funds somewhere other than your wallet. We believe that using this feature will enhance the security of exchanges and pools.
FAQ Frequently asked questions and answers to them.
- Is it possible to load the same * .p12 file into several browsers? And on different computers?
- Yes, you can!
- And if my laptop or tablet was stolen, which had a browser with the certificate installed?
— , EmerCoin NVS. . , , .
— ?
— , . , ( Firefox) , ( *.p12) . – . PKCS#11 (http://en.wikipedia.org/wiki/PKCS_11), , . , , .
— -, – , , ?
— . (, ) , – , «». , – — , . mcssl , . , , .
— EmerCoin? ?
— . , EmerCoin NVS. . , (Namecoin, NXT) — , , .
— - ? ?
— , ! , , EmerCoin: pool.emercoin.com
— EmerCoin NVS ?
— EmerCoin wallet c sourceforge.net/projects/emercoin/files , - , .
— ?
— , ¼ EMC . 1EMC = 0.02USD, 5 ( ) , .
— ?
— NVS « ». , .
— EMCs?
— - , pool.emercoin.com , folding@home: emerfor.org/folding_home/about_en.php
, www.livecoin.net
, :
forum.bits.media/index.php?/topic/3408-emc-emercoin-pos
bitcointalk.org/index.php?topic=362513.0
team@emercoin.com
— EMCs, ? ?
— . , , .
— . ?
— 6-10 , . update value «», . , , . 1-5 NVS. , . , NVS- , . – , - . , , .
InfoCard
InfoCard – , . - (, *.vcf), LDAP-.
InfoCard – , NVS- EmerCoin, , . c emcssl, UID infocard (UID). infocard , infocard , , infocard, infocard .
Here we see an analogy with the OpenID system, in which the user can authorize a site to use a profile on some other known site, for example facebook. However, unlike OpenID, the infocard system is decentralized, and does not depend on the performance of a particular server, as well as its behavior. For example, you can assume a hypothetical situation when facebook, due to its own considerations, deleted or blocked your account, and you no longer have the opportunity to write on dozens of forums that you previously logged into through Facebook OpenID.
, OpenID, LDAP, vCard, () ( ), infocard , . .
, infocard- ( — ), , , . infocard- . , , , , , – infocard- , , , . , , . That's the same thing!
infocard- :
info:infocard_key:infocard_password
- info – NVS
- infocard_key – NVS
- infocard_password –
, infocard- , . , .
infocard , .
( ):
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 34353 # ZIP code
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 abdul@bubbleinflators.com
17 WEB bubbleinflators.com/superabdul
18 Facebook Abdul.AbstulZadomBey
19 Twitter AbdulAbstulZadomBey
20 EMC EdvJ7b7zPL6gj5f8VNfX6zmVcftb35sKX2 # EmerCoin payment address
21 BTC 1MkKuU78bikC2ACLspofQZnNb6Vz9AP1Np # BitCoin payment address
( ) :
Key ( ) value
Value – .
Example:
Alias superabdul # Short name (username, login)
key values, key. values key, , , key. HomeAddress 4-10.
“#” , . “#” -, “\”, 6 .
infocard Import :
Import info:2f2c5a7c57d60668:74744c6e4443df490eab0807052bb9
, .
, , , . :
HomePhone +90-555-123-4567
HomePhone +90-555-123-0000
HomePhone — +90-555-123-0000. .
, key. “+” key. key « value », key — « value ». – , , . :
HomePhone + 90-555-123-4567
+ HomePhone + 90-555-123-0000
Result: HomePhone -> [+ 90-555-123-4567] [+ 90-555-123-0000]
HomePhone + 90-555- 123-4567
HomePhone + + 90-555-123-0000
Result: HomePhone -> [+ 90-555-123-0000] [+ 90-555-123-4567]
HomePhone + 90-555-123-4567
HomePhone
Result: HomePhone -> [] (empty list)
This mechanism gives you the flexibility to combine imported values ​​with your own.
To curb abuses and attacks on the system, the total number of imports in generating one answer cannot exceed 20. We believe that this is sufficient for any conceivable hierarchical structure. Also, ring dependency structures are naturally forbidden. In this case, import by ring link is not performed.
Summary
Summarizing the above, it can be argued that the certificate infrastructure proposed here has common features with various products and systems. So, of course, its central part is custom SSL-certificates, which are not very useful in their original design, but become very useful and convenient in the proposed one.
You can also point to a security check mechanism similar to that used in Kerberos, where the client receives an authorization token from the Kerberos server, and the service server itself by the token requests Kerberos to decide what to do with this client. In our case, instead of a centralized server, a decentralized EmerCoin NVS is used, and the serial number of the certificate registered in NVS is used as a unique token. The service servers also, instead of requesting the central Kerberos server, verify the client in the local copy of NVS, by querying the local EmerCoin wallet.
The proposed InfoCard system also has much in common with OpenID or LDAP, but, unlike the latter, it is decentralized, and has an import mechanism that its counterparts lack, which makes it possible to effectively maintain the relevance of large groups of maps.
But all together - creates a safe and convenient mechanism. Both authorization on sites, and automatic filling of a profile of new accounts.
How to start using
. : pool.emercoin.com/emcssl
, PHP, , , emcssl .
Source: https://habr.com/ru/post/257605/
All Articles