Cryptography

Cryptography is a method of protecting data from a malicious adversary. In other words, it is the art and science of encryption. In this documentation, you will find some definitions of some important concepts used by our solution and API.

Encryption

Always assume that the communication channel is not secure, i.e., someone can intercept the message and read it or modify it. To protect the message from eavesdropping, it can be encrypted with a secret key (also called symmetric-key encryption) shared by both end-points. The sender uses the key to encrypt the message (called ciphertext), and the receiver uses the key to decrypt the ciphertext. The only way someone can read the message is by having the key. However, the message can be corrupted. This brings us to authentication. For more detailed information check [1][6].

📘

Kerckhoff's principle holds that the security of the encryption scheme must depend only on the secrecy of the key and not on the secrecy of the algorithm. That is, always consider that the attacker knows the system and algorithm. So the only way to keep the system secure is by protecting the secret key.

Authentication

Authentication also uses a shared secret key (different from the encryption key), and it is used to verify that the message received matches the one sent. The authentication starts from the generation of the message authentication code (MAC) with the authentication key. Now the sender can send the message and MAC to someone that also knows the authentication key. The receiver then recomputes the MAC and compares it with the sender's. If they are the same, the message hasn't changed.
However, the authentication by itself is not enough. After all, the attacker can still read the message, delete it, or repeat old authenticated messages. Another type of attack is to change the message order or delay it. Many of these attacks can be stopped by using some messaging numbering.

Public-Key or Asymmetric-key Encryption

As mentioned previously, we need to keep both the authentication and encryption keys secret. This means that the sender can't send the key over to the receiver on the unsecured channel. Moreover, the number of keys grows proportionally to the increase of receivers over the communication channel.

One solution is to use a public and a private key. For example, the receiver has a private key for decryption and shares the encryption public key with everyone (even the attacker). This solves the problem of sharing keys (as you can make it publicly available) and still avoids eavesdropping (the decryption key is still private).

📘

In practice, you will see a mix of symmetric and asymmetric keys on a system.

ECDSA

The Elliptic Curve Digital Signature Algorithm (ECDSA) provides a digital signature for a message. Firstly, the signature is composed of two parts: R and S. The pair (R,S) is, therefore, your digital signature. To compute it, you must first generate a random value k and use point multiplication to calculate P=kG, where G and P are points of (x,y) coordinates. These points are on the elliptic curve y² = (x³ + ax + b) mod p, where p defines the total possible values (0 ≤ y² ≤ p-1).

🚧

Remember that we are dealing with integers. So p will only limit the interval, but the number of possible squares numbers N is lower than p. Due to y being squared, then x only has N/2 possible integer numbers.

The value of R is the x coordinate of P. Now you need to hash the message (z) with a private key d_A. Now you can compute S by solving S=k^-1(z+d_AR$) mod p [7][8].

RSA

It provides both digital signature and public-key encryption. Its algorithm relies on how hard it is to factor large numbers. In a very concise manner, RSA works like this:

1. p and g are publicly known.
2. If you know x, you can compute (g^x mod p), where mod is modulo. Otherwise, it is tough to compute x from (g^x mod p).

This means that if you keep x private, solving (g^x mod p) is impossible, even if the result is publicly available [9].

Digital Signature

The digital signature is very similar to authentication, but with asymmetric-key instead of symmetric. Basically, the sender generates public and private keys. The public key is publicly available. The sender computes the signature with the private key and the message. Then, the message and the signature are sent to the receiver. As the receiver owns the public key, it is hence possible to verify the origin of the message.

❗️

This implementation of the digital signature only guarantees that the authorized computer (with the private key) sent the message. However, an unauthorized user may have taken control of the computer and can create the signatures fraudulently.

Certificate Authority

A Certificate Authority (CA) idea is that a user takes his public key and identifies himself to the CA. After that, the CA will sign the user's public key and add helpful information, like an expiration date for the certificate. This way, if someone wants to verify if a message is from the user's, they only need the CA's public key. More details are available in [2].

Certificate Signing Request

One of the steps to order a certificate is to generate a Certificate Signing Request (CSR). This request is an encoded file that allows you to send your public key and some extra information (e.g., company name) to CA. You can read more about it in [4].

Intermediate Certification Authority

The intermediate certification authority is a CA that is signed by a superior CA. In other words, it acts as a middle-man between the server (your domain) and the root certificate (e.g., Digicert). The root CA (e.g., Digicert) signs the intermediate root with its private key, which is trusted. Then the CA uses the intermediate certificate's private key to sign and issue end-user certificates. You can read more about it in [10][13].

Device Certificate

A Device Certificate is basically an immutable identity for a distributed device. Its purpose is to prove the IoT device's authenticity. Read more in [5].

Block Cipher

A block cipher is an encryption function for a fixed-length block of data (currently, it is 128 bits). Thus, a block cipher encrypts a 128-bit plaintext message and generates a 128-bit ciphertext. The reverse is also true (it can decrypt a 128-bit ciphertext into a 128-bit plaintext).

We need a private key to encrypt with a block cipher. One type of block cipher is the Advanced Encryption Standard (AES), also known as Rijndael, which is among the ones accepted by the U.S. government.

AES

The design is based on the substitution-permutation network and has a key size of 128-, 192- and 256-bit. By increasing the key's size, there is also an increase in the number of transformation rounds (10, 12, and 14) that encrypt the plaintext into ciphertext.

📘

To learn more about AES, please check out [3][12].

However, it is used in a block cipher mode for security reasons.

CBC

If you want to encrypt data that isn't exactly one block long (128 bits), you should use block cipher mode. As a block cipher has fixed length, many block cipher mode requires the plaintext length to be a multiple of the block size. When the data length is not exactly a multiple of the block size, you can add padding. There are many ways you can add padding, but the padding must be reversible.

The most used block cipher mode is Cipher Block Chaining (CBC). It xor each plaintext block with previous ciphertext block. However, how can you encrypt the first plaintext block? The first plaintext block uses an initialization vector (IV) to xor with the plaintext. There are four possible ways to generate an IV:

1. Fixed IV: you shouldn't use a fixed IV, because if the message starts with the same plaintext block (likely), the encryption will also begin with the same ciphertext.

2. Counter IV: the IV increases as the number of message increase (counter). This is also not very secure, as it is normal for messages to start in similar ways. If the first blocks of the messages have simple differences, then the IV counter could cancel the differences in the xor, and generate identical ciphertext blocks again.

3. Random IV: this brings randomness to CBC. However, this brings the problem of how to let the recipient know the random IV. One solution is to send the IV on the first ciphertext block.

4. Nonce-Generated IV: the nonce should be used only once for each message (but it doesn't need to be secret). The steps are:

   • You can generate a nonce using some information from the message (e.g., the message counter) concatenated with the first nonce (as an example).
   • The nonce should be as large as a single block.
   • Encrypt the nonce with the block cipher to generate the IV.
   • Encrypt the message in CBC using the IV.
   • Add enough information to the ciphertext so the receiver can reconstruct the nonce.

📘

Nonce is a contraction of "number used once." So it should be used only once, never repeat it! If you do, you will face the same problem as the fixed IV.

Hash

A hash function (or message digest function) has as input an arbitrarily long string of bits and compute a fixed-sized result (also called digest). One possible use of hash functions is a digital signature, as asymmetric keys are usually very computationally costly. Therefore, instead of signing the message itself, you can use a hash function on the message and then sign its output.

Every hash function must have collision resistance: as there are infinite inputs, a hash function will generate an infinite number of collisions. The resistance, therefore, is on how hard it is to find a collision. Another critical aspect of a hash function is irreversibility, i.e., you can't obtain the original message through the digest.

📘

A collision is when two messages have the same digest.

SHA

The NSA designed Secure Hash Algorithm (SHA). There are SHA-1 (compromised), SHA-2 family (224-, 256-, 384-, and 512-bit outputs), and SHA-3 family (224-, 256-, 384-, and 512-bit outputs). They are designed to be used with the 128-, 192-, and 256-bit key sizes of AES. You can learn more in [11].

References