It is dangerous to use EDS in Kazakhstan

Recently, the state is trying to transfer all state services to electronic format as much as possible. Address certificates are actively issued, and other certificates are issued through the e-government portal. You can even register marriage marry through the portal. In fact, very convenient. Of course there are minuses, mostly organizational. regulatory at the level of laws, at the level of implementation. But this is another question, the main thing is very good initiatives. It's all good, but the post is not about that.

Obviously, to use public services, you need to somehow confirm your identity. For this, once a long time ago, the use of electronic signature was fixed by law. The basic formulation of the use of EDS such - EDS equates to a handwritten signature. Many do not know, but for the transfer of EDS keys (hereinafter I will use the term - EDS keys. Everyone calls simply EDS, and in fact these are two pairs of keys - for authentication and signature). For the transfer to third parties even have some responsibility. It is obvious that many people do not care, do not understand all the seriousness.

In general, the theme of the post about NCALayer, the layer between the browser and EDS keys. Security is a vulnerable mechanism for using EDS.

What is NCALayer

Since the main implementation of a crypto-provider in Java and in the latest versions of browsers is not possible to use applets, the NUC has come up with an original solution for using EDS in browsers. This solution is called - NCALayer. NCALayer - an intermediary between the browser, cryptographic provider and EDS keys.

NCALayer is installed locally on the user's computer. NCALayer works as follows - a web server is opened on a specific port where different requests are sent.

Omitting all the details of the connection, we’ll consider two requests so far to get a general idea of ​​how NCALayer works:

1. Select the key on the file system.

{ 'method': "browseKeyStore", 'args': ['PKCS12', 'P12', '/home/user'] } 

After sending the request, on the machine where the NCALayer is located, a dialog box opens that offers to select the EDS key file.

Accordingly, after selecting the key, we get the following answer through the socket.

 {"result":"/home/user/AUTH_RSA.p12","errorCode":"NONE"} {"errorCode":"NONE"} 

Attention: when using NCALayer, you get the real path to the file on the client machine.

1. If you have a path to the keystore, then for future work you must provide a password for this store. Usually the site somehow takes this password through the form. Here is an example of how to sign or put an EDS on any data.

 { "method": "signXml", "args": [ 'PKCS12', '/home/user/AUTH_RSA.p12', '1874abcef234', '!!!', '<login><timeTicket>1517997213006</timeTicket></login>' ] } 

I will not publish the answer, but it contains the signed part of the xml, which was in the request.
Again, get a password from the EDS keystore, falls on the shoulders of the site. That is, the site always knows where the user's keys and password are , otherwise it is impossible to work.

Cons of the current version of NCALayer

1. Here is one big minus - the path to the file and password is available to any site developer using EDS. Even using all sorts of tokens, when using NCALayer, the password from the device-token is also transmitted to the site. At the very least, the current implementation allows this.
2. Keeping paths to keys and password each site can store in its database. May not store. In general, to store or not to store paths and passwords - again, all this lies on the conscience of site developers.
3. Any site can sign data for you without your knowledge in the background if it knows about the path where the keys and password are stored. Again, if you have ever used a digital signature on a site, then the site already knows the path to the file and password. If the site is an attacker, then it is guaranteed to save the password somewhere at home.
4. I want to note that direct access to the carrier with the keys is not available. Access is limited to NCALayer features only.

A real example of how to access egov.kz, if you do not own a person’s EDS

I will not go deep into technical details and implementation. I will describe how to do it.
Now, in order to exploit this vulnerability, it is necessary to understand how the entry mechanism for egov.kz works through EDS. To login to egov.kz, xml from egov.kz is signed by the user and transmitted to the server, where it is checked. If the signature is valid, then log in. From the NCALayer side, the login process consists of the following steps:

The portal requests the following data from NCALayer - loadSlotList (here you can answer with an error), getKeys, getSubjectDN, getNotBefore, getNotAfter, and signXml. If NCALayer correctly substitutes this data from another user, then accordingly we will successfully log in. Here it is very important to get only the subjectDN and xml for the signature from NCALayer.
Now how to access egov.kz from another person, the mechanism:

1. On your computer, extract the xml string that you need to sign to enter egov.kz. This is done so, just in the developer console on idp.egov.kz, you need to request the following data - document.getElementById('xmlToSign').value .
2. You send the xml string to the signature of the right person who is sitting on the malicious site. He is on his computer, in the background, he signs the necessary xml string. Additionally, you get subjectDN.
3. SubjectDN and signed xml are now available.
4. Now the most interesting thing is that on your computer you emulate the work of NCALayer, which gives the necessary data.

Some statements

1. The post is not designed for a wide audience, more on techies who understand the principles of web development.
2. Vulnerable ALL resources that use NCALayer.
3. Knowledge of cryptography is not needed.
4. To exploit this vulnerability, you do not need to receive the SDK from the NUC. Accordingly, the NCA is not able to identify malicious sites.
5. The developers of NCALayer cannot guarantee that attackers will not be able to use such a mechanism. It will be stupid to answer for everyone. Technically, there is a possibility.
6. Vulnerable keys are not only on the file system, but also on tokens.
7. You are guaranteed to have lit the password from the digital signature key carrier, even from tokens. It is enough to log in only once on egov.kz. How to use the password on the site, it is on the conscience of the developers.
8. As I heard, there are already systems that store the path to EDS keys and password in the settings.
9. There are no vulnerabilities on the sites, just the scheme of using EDS through NCALayer is unsafe.

Update:

What can be done

1. It will be inconvenient - but at every use of keys, to request at least a password.
2. Promote web crypto api
3. ...

Emulator NCALayer
An application that, without the knowledge of the user, in the background signs data