KeyChain security
Choosing a means of storing keys is an important and responsible task that everybody needs to address when considering making transactions - irrespective of the type of blockchain they use. That is why here we show you the detailed structure of our KeyChain - so that your choice of key storage is an informed decision based on real knowledge of what stands behind the system.
KeyChain encrypts private keys using AES256 algorithm and stores the keys in an isolated environment that is protected with three security layers.
AES256 was first adopted by the U.S. government and now is used worldwide as a secure and reliable way of protecting information. It stands for Advanced Encryption Standard which handles 256-bit keys. This is a symmetric encryption algorithm that creates an output (ciphertext) from the input (plaintext) in 14 rounds which involve several steps of encryption. These steps combine the procedures of other symmetric encryption algorithms: substitution cipher with a reference table, adding round key, shifting rows, and mixing columns - all performed multiple times.
For Linux, we use a unique mechanism created by our team.
Typically, Linux offers the following algorithm of interacting with the user:
1. Client app = > connects => to X-server
2. Client app => sends some X-proto specified commands => X-server receives the commands => X-server renders an interface window
3. User enters a passphrase into the window => X-server catch the passphrase from the user => sends X-proto commands to the client => client app processes the passphrase from the user
However, around 1984, at the time when X11 was created, there existed no such task as performing secure operations via the Internet. The developers of X11 did not set out to protect the user’s data from someone capturing it. Even now, there is still no real mechanism against this kind of attack. To solve the problem of protecting the data, we have decided to look past the standard solutions. Instead of receiving a passphrase from a user through the X-server, we have chosen to receive the passphrase from the keyboard driver. This serves as a shortcut that allows KeyChain to work without connecting to the X-server, thus minimizing the risk of someone stealing the passphrase.
Therefore, now instead of the following sequence…
The user enters the passphrase into the window => X-server catches the passphrase => it sends the passphrase through X-proto => Client app processes the request
… we have:
The user enters the passphrase => KeyChain catches the keyboard’s events directly
The shorter the path, the fewer weak points can be found. We exclude the weakest link (X-server) from the process of entering the passphrase. Thus, for the third party to compromise the passphrase, they will need to intercept it right at the keyboard level, which requires to have root access and hence makes it almost impossible.
You might be asking yourself: if KeyChain functions without connecting to the X-server, why does the user see the dialogue window?
The answer is simple and is motivated by our concern with the user experience. Work through the command line is rather inconvenient for most people. That is why we use an emulator program that imitates the process of inputting the passphrase by receiving events from the KeyChain daemon. Note that no secret data goes into the emulator – like a mirror that only reflects light without absorbing any of it. This allows KeyChain to minimize the risks to the minimum.
Apps or websites send requests to the KeyChain through two types of communication - standard I/O streams (mostly called pipes), and the WebSocket. The architecture of the KeyChain software consists of the three independent layers:
-
API layer which integrates with your app, website or any external application. It is language-neutral. The protocol for the terminal application operates with the JSON format in synchronous request/response way. The main function of the API layer is to transmit and parse commands for given API. Each request carries information about commands, the type of key user wants to use to sign transactions and other relevant parameters which you can find in the Protocol.
-
Security layer receives the commands from the API layer and acts as an OS-specific protection mechanism for the interface window (third layer). It serves as a shield from potential attacks at sensitive data and information. Security layer is tailored for the Mac OS, Linux, and Windows OS and operates only with permitted files (through admin access). The request, transmitted to the Signing module which holds the private keys, works simultaneously with the Secured input module that uses OS-specific mechanism. The Secured input module protects the passphrase from key grabbers and malware.
-
Representation layer is the UI window which notifies the user about the details of transactions and necessary actions. The interface window is initiated from Security layer. Once the user inputs the correct passphrase, it sends the permission to the Signing module to unlock the demanded key. Passphrase input field is protected by the secured input module. Security layer decrypts the given key with the correct passphrase entered by the user. In this instance Signing module can operate with the open private key, for example it can extract information, sign transactions, therefore responding to given requests.