In detail about the encryption in the Cryptia service.

Encryption of the connections between the client and the Cryptia server.

Traffic between the client and the server is being encrypted using TLS v 1.1.

Encryption of the direct connections between the clients.

Direct connection between the clients includes two UDP channels. One channel is used to send signal messages and files, another one is used for real time traffic (voice, video). Each of the channels is being encrypted with proven symmetrical encryption algorithm (by default AES-256, but it is possible to set up other algorithms included in the OpenSSL 1.0: AES-128, AES-192, BlowFish, Camelia-128, Camelia-192, CAST5, DES, TripleDES, IDEA, SEED and GOST 28147-89 as well. Encryption keys are single session ones. For agreement of the symmetrical session keys Diffi-Hellman algorithm or ECDH are being used, and to protect the Diffi-Hellman algorithm from attacks, the parameters and public keys exchanges are signed with digital signature of the clients, based on the asymmetrical algorithms (RSA, DSA, ECDSA).

Vital part is that the client independently generates the key pairs for asymmetrical algorithms and set of parameters for Diffi-Hellman algorithm. To generate it OpenSSL library integrated into the client software is being used, however, the subscriber is able to generate the keys independently with freeware utility OpenSSL, or any other similar tool, that he trusts to, and then import the keys to the client Cryptia software. Also there is a capability to export keys into the standard file formats for further analysis.

Symmetrical encryption

Symmetrical channel encryption modes are different. For signal channel CFB (cipher feedback) encryption mode is used.
For real time channel encryption CTR (Counter Mode) is used. The choice of the CTR mode was stipulated by the fact that we do not need to ensure 100% reliability of the packages delivery there. For voice applications, the transmission delay is much more critical. Correspondingly, we need to have the possibility to synchronize the cipher text for cases of package loss, instead of trying to achieve identity of the sent and received streams by continuously resending the packages. The size of the package with real time data being sent, is usually larger than the block size of the symmetrical encryption algorithm, therefore inside the package the blocks are being linked via OFB (output feedback mode) or CFB modes.

You can read more about encryption modes here:encryption modes

There are 4 ciphers and 4 initialization vectors used in the system. Two per each of the channels and different ones for data directions. Certain fragments of the output value of the Diffi-Hellman algorithm used for the creation of the agreed-upon session key are being utilized as cipher and initialization vectors’ values.

Diffi-Hellman algorithm (DH)

You can read about Diffi-Hellman algorithm in detail here: http://en.wikipedia.org/wiki/Diffie-Hellman
This algorithm is used in the Criptia.com client software to agree the session keys of the symmetrical encryption algorithms. Clients need to have a set of parameters for algorithm to work. Generation of the algorithm parameters is a long and resource-intensive process, that is why parameters are being generated in advance (independently by each user). This can be done with the generator integrated in the client software or using the freeware utility OpenSSL (openssl.org) or with any other utility of user’s choice. Generation of the 1024-bit long key parameters on the modern PC takes from dozens of seconds up to a minute, while generation of the 4096-bit long parameters might take up to several hours.

In its pure form, Diffi-Hellman algorithm is vulnerable to a “man-in-the-middle” attack, that is why to defend from such attacks, messages with the open session algorithm keys have to be protected from substitution (but not from the interception). For these purposes, the messages are being signed by each party with digital signature based on the asymmetrical algorithm. Moreover, the signature contains the unique connection number – random number created by the server and sent to the both parties via secure connection with the server. It was done to prevent hypothetical attack when the intruder simulates the key exchange messages saved earlier.

Digital signatures, private keys, certificate requests, certificates.

Digital signature algorithms are based on the asymmetrical cryptography. Each client independently generates a pair of his own keys (public / private). To sign the message digitally, the private key is required, while it is possible to verify the signature with the public key only.
The user independently generates his own pair of keys using the generator integrated into the client software version, or via freeware utility OpenSSL (www.openssl.org), or using any other utility he trusts to. However, in case if the user A has relayed his public key to the user not directly in person yet somehow via the network, how user B can be sure he has indeed received the user A’s public key? There could have been an intruder on the way of the key transmission, which could generate his own pair of keys and give his key to the user A instead of user B’s key, allowing him to interfere in the exchange.

This problem is eliminated with the public keys infrastructure (PKI).

Private key and public key are just set of parameters for the algorithm. Private key is safely kept by the user (it can be protected by the password to be entered any time the key is used) and the public key is to be distributed to the other users. However, it is unsafe to just transmit the set of parameters. The problem was mentioned above. To eliminate it, other user sends not just the set of parameters (namely, the public key) but a special file which contains, apart from the public key, the information whose key it is – key subject, as well as the digital signature and information who issued such signature (whose signature it is).

Such file is called “public key certificate” of the user. In order to retrieve the public key certificate from the public key, user creates a special file – “Certificate Request”, containing, apart from the public key, the information on the key subject, and sends such request file to the “Trusted Certification Authority” via the protected communication channel. Upon receipt of the file request for the certificate, “Trusted Certification Authority” creates a “public key certificate” of the user, including the information about itself (Issuer), expiry term of the certificate and its own digital signature.

But how can user verify the signature of somebody else’s certificate? Naturally, he has to have a public key (public key certificate) of the signing party to this certificate and the user has to trust such person (body). Or the certificate of the person who signed the certificate of the user is signed by the digital signature of the person the user trusts to. It is called chain of trust. Root certificate is a certificate at the end of the trust chain.

Also, there is a concept of the self-signed certificates. It means a certificate signed with its own public key. In practice such signature would get you nowhere, yet the certificate file complies with the corresponding specifications (presence of signature). Any person is able to create a self-signed certificate with the subject, e.g. Microsoft Corporation. Use of the client’s self-signed certificates is strongly non-recommended and is disabled in client Cryptia software by default setting. All root certificates are self-signed by definition. That is why you need to be very cautious while installing the root certificate. As a rule, root certificates are integrated into the devices or operating system by the manufacturer.
Cryptia.com server combines the functions of the connections server and the certification authority server. The cryptia.com server certificate is signed by the trusted certification authority and such trusted certification authority’s certificate is integrated into all versions of the client Cryptia software.

Certificate revocation.

Let us suppose that your private key was lost. Or even worse: you were forced to give it away by the intruder. A certificate of the public key corresponding to such private key was distributed among other users. How to get protection from unauthorized use of the private key? Of course, you could contact all those whom you have provided your public certificate with and ask to delete it but if you had no luck reaching some of them? It is much easier to revoke you certificate. You send your request for revocation to the certification authority and certification authority marks it in its database as revoked and enters it in the special certificate revocation list. The same procedure as with your lost passport – you are advised to write the statement of loss and the body that issued your passport in its turn would put it in the list of the lost passports. Before using unknown certificate, client software has to verify if it were not revoked. There are several ways to do it.

CRL (Certificate revocation list). Certification authority creates the list of the revoked certificates and grants users with the free access to it.

CRL delta. Similar to CRL, but the client receives not the whole list but only updates of the list, starting from the certain date. It is suggested that the client keeps older list records.

OCSP (Online certificate status protocol). Protocol for the online certificate status validation. Client connects to the certification authority server and requests the status of the particular certificate. Since the Cryptia server combines the functions of the connections server and certification authority server, it sends to the client the certificates revocation list of the other client at the moment the connection to him is attempted. It was done to increase the efficiency and to reduce the network traffic.

Mechanism of the establishment of the direct encrypted connection between the clients.

In order to establish the direct connection between the clients A & B the following is required:

Client A initiates the connection.
Client A has to have the generated set of parameters for DH (ECDH) algorithm (or several sets of parameters)
Client A has to have a public key certificate of the Client B (or several certificates)
Client B has to have a public key certificate of the Client A (or several certificates)
Client A and Client B have to be connected via the Cryptia server.

1. Client A sends to the Cryptia server the message indicating that he wishes to establish the direct connection with the Client B. The server generates the random number which serves as an ID for this session. The server sends the message to the Client B containing such session ID and requesting from the Client B his temporary UDP port numbers for this session.

2. Client B saves the session ID, opens the temporary UPD ports for connection and sends them to the server.

3. The server sends to the Client A the current IP address of the Client B and his port numbers, obtained in step 2. As well as session ID. All following steps are taken between the Clients A & B directly, bypassing the server.

4. Client A sends to the Client B the message containing the list of his certificates, list of the Client B’s certificates in his possession, list of supported symmetrical algorithms (in order of preference) and list of hash function results from his sets of parameters for DH (or ECDH).

5. Client B chooses the certificate he already has from the list of the Client A’s certificates received, chooses one of his own certificates that are present in Client A’s list, and chooses first supported algorithm from the list of supported symmetrical algorithms, and also looks into his DH parameters cache for set of parameters for Client A with the same hash value as those sent to him by the Client A. Client B sends to the Client A indices of the chosen certificates, symmetrical algorithm and, if any, index of the set of DH parameters of the Client A found in his own system.

6. Client A sends to the Client B the message containing the following fields:

DH parameters, in case if the Client B could not find those in his cache. If parameters were found by the Client B, Client A does not send them. Own public key, calculated with the chosen set of DH parameters. Generated secret DH key is stored in RAM. Digital signature, calculated with the chosen set of DH parameters, public DH key and unique session ID, obtained in step 3. Digital signature is made based on the private key from the pair of keys for which certificate was found by the Client B in step 5.

7. Client B verifies the message signature. To verify the signature public key is used from the Client A’s chosen certificate. If the signature is validated, Client B generates his secret session DH key, calculates its own public DH key with it, and also calculates the agreed-upon key from his own secret key and public key of the Client A, and sends to the Client A the message containing his public DH key as well as signature of his public DH key. Signature is made with private key from the pair of keys, for which Client A has certificate for. (Agreed upon in steps 4 & 5).

8. Client A verifies the message signature. For validation public key is used from the certificate that Client B has chosen and had sent to the Client A in step 5. If the signature is successfully validated, Client A calculates the agreed-upon key with its secret DH key and public DH key of the Client B.

Further on, all the traffic between the clients is sent in encrypted form based on the symmetrical algorithm agreed upon in steps 4 & 5.

Notes:

1. Steps 1 through 3 are provided in a strongly simplified form, important for understanding the cryptography basics. In real system during these steps a number of service exchanges is made between the server and each for the clients for NAT traversal. From the cryptography point of view it is crucial that after the finalization of these operations, Clients A & B have same session ID obtained from the server via the protected channel, Client A has external IP address and knows Client B ports, and network infrastructure is “ready” to deliver packages from A to B (NAT traversal through tunneling).

2. Long-term session resistance to hijacking is determined by the length of the DH (ECDH) algorithm key and not by the key that is used for digital signature. Key that is used for digital signature does not need to be very long, as the intruder has only about 20 seconds to forge the signature (time period during which client software is waiting for a reply from the other client). Signature forged within 1 minute has no value whatsoever and does not bear the risk of the session hijacking.

3. Server is not aware and has no means to find out which set of DH (ECDH) parameters and what keys were used to establish the connection since all of these parameters are relayed from the client to client directly.

4. DH (ECDH) parameters are relayed from the initiating client to the client-recipient in the open form which bears no risk, however it is done so only at the first session established. Client-recipient stores the received DH (ECDH) parameters in its cache and such parameters will not be relayed during the following sessions. There is a possibility to manually put the set of parameters into the cache. In such case DH (ECDH) parameters will not be transmitted in the open form at all and the intruder would have to solve the equation in three unknowns, while such an equation (A=g^a mod p) even in one unknown can be solved only by the exhaustive method, which makes no sense.

5. Steps 4 and 5 mention the “list of certificates”. In fact, the certificates themselves are not being sent, only SubjectKeyID values from the certificates are sent, which are the hash function values, calculated based on the certain certificate field values.

6. If the key agreed-upon with DH (ECDH) algorithm is shorter than 1536 bits, required to use four 256-bit ciphers and four 128-bit initialization vectors, in such case the cryptographically secure pseudo-random sequence generator is used, utilizing the AES algorithm, and the value created with DH (ECDH) algorithm is used as a key for AES (as well as initialization vector).

7. During the steps 1 through 3 the server also sends out to the clients the certificate revocation list of the other party, if any, and client software does not attempt to use them further on.

Check Code

Check code is a simple tool for users to check for presence of the “man-in-the-middle”. As a result of the DH algorithm operations both parties to the session will obtain an agreed-upon key (the same one). The length of such key will be equal to the length of the set of parameters for DH algorithm (minimum 1024 bits). Check code is calculated as follows: agreed-upon DH key is split into 16-bit blocks and all of them are XOR-ed with circular shift after each iteration. Naturally, the resulting code should be same on both ends. Such code is shown in the window to the user and the users can check if those match orally. Check code is not sent via the network and is not stored anywhere. In fact it is redundant security.

Advantages of the keys agreement with DH algorithm over the random key encryption with the asymmetrical algorithm (PGP, etc.)

PGP (GNUPG) is also using symmetrical algorithms to encrypt files, using the random session key as an encryption key, which, in its turn, is encrypted with the asymmetrical algorithm (EL Gamal-Encryption or RSA). Such scheme has a fundamental defect:
Let us suppose that the intruder has a possibility to register all of your sessions. Naturally, he would not be able to decipher those in either case. However, if he ever manages to obtain the access to the secret key, he would be able to decipher all of the earlier stored messages, in case if the encryption was made via the second option (PGP, etc.). In case if key agreement with DH algorithm is used, disclosure of the secret key would not lead to deciphering of all of the earlier stored messages, since the secret session keys of the DH algorithm are stored in RAM for a limited period of time only and are not relayed or saved anywhere else. If old sessions are of any value to you, in case of using the random key encryption option you have the risk that intruders would attempt to “derive” your secret key. How unpleasant actions related to the word “derive” can become – it is for you to decide. In case of using the option of the key agreement with DH algorithm, you are free to give away your secret key upon request, without fear of your old sessions being deciphered.

Client certificates issuance policies for Cryptia service.

Request for obtaining the certificate are accepted only via the protocol integrated in the client software.

User sending out the request for certificate has to successfully pass the authentication at the server using the password and other pair of keys. CommonName (CN) field of the certificate has to match user Login on the server. Requests in which CN field does not match Login are refused.

All of the values from the Subject field are cleared except CommonName (CN). Server signs only something it can verify.

Certificate serial number has 64 bits.
Date of certificate issue is set at the current time at the moment of certificate generation.
Extended certificate fields (X509 Extension) contain the following data:

Key Usage: Digital Signature.
Subject Key Identifier: HASH SHA1.
Basic constraints: CA: FALSE
Authority Key Identifier: HASH SHA1 – Subject Name

Certificate request can be revoked only prior finalization of the generation of the certificate by the server. After that, only certificate itself can be revoked.

Certificate revocation requests are accepted only via the protocol integrated into the client software.

User sending out the certificate revocation request has to successfully pass the server authentication.

After finalization of the certificate revocation procedure it is impossible to convert its status back to normal.

Versions

Cryptia client x86 for Debian based Linux distro
Cryptia client x86 for RPM based Linux distro

Cryptia client x64 for Debian based Linux distro
Cryptia client x64 for RPM based Linux distro

Cryptia client for Mac OS X

Cryptia client for Windows

Cryptia SIP Gateway

Enterprise solution for companies looking to integrate secure communications with customers in the existing infrastructure.

Integrate secure solutions into existing corporate infrastructure

Usually there is a telephone infrastructure and streamlined business processes in the working companies. This solution allows to implement a secure voice communications without changing the working infrastructure and retraining staff. Corporate client installs our software to the server, that converts the protected traffic from the Internet to unprotected SIP traffic and gets it to his PBX. Almost all new PBX supports SIP. Even if the client's PBX does not support SIP, there are enough solutions in the market that convert SIP traffic to the regular phone lines, which are suitable for any PBX..

Business Accounts

Sorry, purchasing is now available only from the mobile application.