Protocol properties

The protocol for establishing a secure connection should provide the following services:

• confidentiality
• authentication
• undeniability
• integrity
• negotiation of the session key
• perfect forward secrecy

Confidentiality

It is the protection of information transmitted in an public channel by preventing it from being known by an unauthorized person. This protection is realized by converting (encrypting) this information with the ‘key’ (that is, additional information known only to the persons authorized to read this information). If the ciphertext (encrypted information) gets into unauthorized person’s hands, then this person won’t be able to decrypt it (decoding of the ciphertext) because he does not have a key.
It must be assumed that ciphertexts transmitted in an public channel are ALWAYS eavesdropped.

A separate issue is the distribution of keys, which must be carried out in such a way that the key has only authorized persons. Generally, secure key distribution can look like this:

• in symmetrical cryptography through another secure channel (for example a personal meeting, diplomatic mail, a channel of a trusted provider who will not be interested in ciphertext’s content)
• in asymmetric cryptography keys are partially transmitted in an explicit channel in such a way that getting the full keys through the eavesdropper was “computationally difficult”
• in quantum cryptography keys are sent directly through a public channel, eavesdropping of the key is immediately detected.

Information encryption is carried out using ciphers operating in a specific mode (ECB, CBC, counter mode, etc.). Being created protocol will probably use AES-Twofish-Serpent cascade working in counter mode (as in Truecrypt, but counter mode will be simplified, and thus more robust)

Authentication

This is proving own identity to other side. It is a protection against the impersonation for someone else. If you receive data from an public channel, you can never be sure of the real sender – you should assume that transmission in the public channel AT EVERY TIME can be changed or intercepted (for example in”Man in the middle” attack).

Authentication allows to “gives credence” to received data. It is usually realized by:

• data signing – in asymmetric cryptography, data is signed by a private key, and the signature obtained is verified with a public key (but we must be sure that this public key belongs to the sender); you can also use the symmetric cryptography authentication function (hmac)
• encrypting data in such a way that it can be decrypted only by the recipient (that is, the confidentiality service can theoretically also serve as authentication: in symmetric cryptography we must be sure that only sender and receiver are having the key; in asymmetric encryption we encrypt data with the public key of the recipient – only the recipient will be able to decrypt the ciphertext with his private key).

Distribution of public keys from the authentication’s point of view (making sure that the public key definitely belongs to a given person) may look like this:

• transmission via another secure channel – à la PGP model (in this way Mr. Snowden wanted to communicate with journalists at the beginning of his activity)
• authentication by a certificate issued for a given public key by a third party, trusted for both parties (authentication center – CA)
  In the being created protocol, the PGP model will be used with ECDSA algorithm (the default curve will probably be the P-521 elliptic curve, but it may also be possible to use own curves over the Fp field)

undeniability

This is protection against others party’s denial or negation of active participation in done activities, which takes place in the following cases:

• the other party wants to deceive us by saying that the negotiated connection is a manipulated older negotiation (this scenario is difficult to implement and not practical but not impossible)
• the other party didn’t participate in negotiation, which was reproduced by a third party older negotiation (the attacker may for some reason forcibly forge a secure connection between us and him, although he will not be able to generate correct ciphertexts, he will be able to send a prepared “garbage” or fragments of eavesdropped earlier transmission)

Authentication alone may not be enough, and especially the latter case can be quite dangerous if the negotiation protocol is too simple.

A little fairy-tale example: Secret military base. At night, an unexpected convoy comes to its gates. They claim that it is “urgent” and base have to quickly contact the Ministry. The base is connected to the Ministry by a direct transmission channel with a defective secure protocol. The base commander calls the ministry, the secured connection is negotiated and link is created (terminal shows that the connection is “safe”). There are strange squeaks in the receiver, but before the base commander can ask for the third time “Hello?” he hears the voice of a familiar general “… this convoy, it is urgent! Open them immediately, this order! …” after which there are only squeaks. The base commander may think at the moment that this convoy is really something urgent, and the communication line with the ministry must be little broken – it is better to let the convoy and report a communication failure in the morning. Unfortunately, the commander of the base did not connect with the Ministry, but with a hostile attachment, who plugged themselves in a badly secured communication line somewhere in nearest forest. The General actually issued such an order in a conversation with the base, but it was half a year ago, and the commander didn’t recall this conversation in time.

How the negotiation protocol should be secured from similar cases:

• a temporary session key generated for each new session (it is not possible to use a previously recorded other transmission)
• using the unique challenge for each new session – in this case manipulation attempt will be detected already at the final stage of the negotiations.

The being created protocol will have above safeguards ensuring undeniability, because it should be assumed that in public channel the transmission can be AT ANY TIME intercepted and manipulated.

integrity

This is protection against data misrepresentation. It is not a cryptographic service. To done it sometimes a parity bit is enough, sometimes a checksum (for example, crc), sometimes a cryptographic hash function. However, these are only safeguards against unintentional changes arising during data transport or storage. Cryptographic protection against intentional change could be done by the signature of data with a private key or the hmac function – the attacker does not know the key, so he can not change the data in such a way that it will not be detected (in previous mechanisms he could recalculate the checksum or hash).

When sending data through an public channel, it must be assumed that data AT ANY TIME can be manipulated. In the being created protocol, data integrity against unintentional changes will be ensured by the lower layer transport protocols. However, in the negotiation phase indirect detection of intentional changes will be ensured (through the other cryptographic services mentioned here). As for the transmission phase, there will probably be no such protection – manipulations will be immediately detected by the user (incorrect ciphertext decryption). Entering cryptographic checksums before encryption would generate vulnerability (like for example, in the protocol for GSM call encryption – see A5 breaking history). The only thing that needs to be assured here is that ciphertext traffic cannot be repeated in the same session.

negotiation of the session key

To obtain a secure, encrypted connection, both parties must have a key of the same value. This can be done in the following ways:

• the (symmetric) key has been previously agreed between the parties (another secure channel) and is used for each connection between these pages (pre-shared key)
• initiator of a new connection generates randomly a session key, then sends it in an encrypted form – encrypting it with either pre-shared symmetric key or an asymmetric public key of remote party
• sides using asymmetric cryptography send themselves “prekey” data to the calculation of a common secret (for example using the Diffie-Hellman or Menezes-Qu-Vanstone algorithms), based on which a key will be created by key derivation function (KDF). Negotiation in this case is protected by the fact that obtaining a common secret using only eavesdropping “semi-products” is difficult to calculate (you can do it, but you need such computing power that using currently available means it is impractical in time – for example, it needs 100 billion years).
  The being created protocol will use the ECDH algorithm for elliptical curves over Fp field probably with the prf-hmac-sha3 KDF.

perfect forward secrecy

It can not be assumed that the cryptographic mechanisms are perfect. With each past year there are more and more attacks created on used algorithms and protocols. The available computing power is increasing all time. The algorithms used 50 years ago (in the ‘sixties’) today would easily be disarmed both with the brute force of an ordinary PC commuter and with the possibility of ‘modern’ cryptanalysis (which was not known at that time and their existence was not even suspected). This situation can be compared to the inventors of knight armor who did not foresee that it can not protect from machine gun bullets.
Therefore, in secure communication protocols it should be foreseen that some of the components used may be compromised. And as it must be assumed that communication in the public channel is ALWAYS recorded and remembered, so breaking part of it must have the least impact on the security of the communication history.

Let’s look at the case of encrypted transmission using the pre-shared key. Two pages using the same key for each session for a long time risk that the attacker, having enough time for the computing power, will eventually break the key (or simply overhear it or break to system and copy it). Having the key and all recorded transmissions, the attacker can easily decipher them and get to know content.

Perfect forward secrecy is a protocol property that prevents historical transmission from being revealed based on a future successful attack. It can be achieved by using session keys generated and distributed independently from other owned keys (whose role will be limited to supporting other services such as authentication). An attacker in this situation has two options to choose from:

• attack the key possessed by one party (if successful, it can steal its identity, but will not have access to previously recorded connections content)
• attack the session key of one of the connections (in the case of success, the connection content is revealed, but access to other connections content will be still impossible).

The designed protocol will provide perfect forward secrecy by generating a random temporary key pairs to compute a session key using the session key negotiation service.