The Need for Cryptography

In our day-to-day lives, the use of cryptography is everywhere. For example, we use it to securely send passwords over vast networks for online purchases. Bank servers and e-mail clients save your passwords using cryptography as well. Cryptography is used to authenticate people and devices, devices to other devices, and secure all transmitted information in our IoT ( Internet of Things) connected world.

If for a day all the cryptographic services stopped working, modern communication will stop as we know it. Bank transactions will not go through, internet traffic would come to a halt and cell phones would no longer function. At that point all our important information would be exposed, and could be exploited to do unimaginable harm to us all. Cryptography prevents this from happening. It secures information and communications using a set of rules, so that only those authorized can access and process the information.

Security by Obscurity

In some cases, "security by obscurity" has been used as a method to keep transmitted information secured. In those cases, the technique used was kept secret from all but a few, hence the term “obscurity”. This made the communication secure but was not easy to implement on a wide scale.

Unlike "security by obscurity", modern cryptographic methods make the operations available to the public for scrutinization.

One-Time-Pad

Classical 'closed loop' cryptographic ecosystem

In the above diagram we show a classical cryptographic system. The sender and the receiver first agreed upon a set of pre-shared encryption/decryption keys. These keys were then used sequentially to encrypt and then de-crypt each subsequent message.

The term ‘One-Time Pad’ is an artifact of having each shared key on separate pages of a notepad that was used and then destroyed. Once the pre-shared keys were exhausted, the sender and the receiver needed to meet in a location to securely exchange a new set of keys that would be used for the next set of message exchanges.

Next Phase of Cryptography

Clearly with the new technology advances we need to continue protecting a vast system of electronic communication, commerce and intellectual properties across oceans and continents that can otherwise be intercepted by people with hostile intentions.

So, how do you implement such a massive system that can carry out billions of transactions in a short period but still provide an excellent level of security? Modern cryptography is an essential component of secure but accessible communication that is part of our everyday life.

The massive amount of information that is exchanged around clock rely on publicly known security algorithms. These algorithms are standards-based and vetted in an open environment, so that any vulnerabilities can be quickly found and addressed.

A Modern Symmetric Key Cryptography System

The above diagram shows a simplified modern cryptographic system. Let’s investigate these systems and algorithms more in depth.

The basic tenet of a modern cryptographic system is that we no longer depend upon the secrecy of the algorithm used, but instead the secrecy of the keys.

There are four essential goals of a modern cryptographic system:

• Confidentiality: The information can never be disclosed to someone who is not authorized to see it.
• Identification and Authentication: We need to identify and then authorize both the sender and the recipient before any information is exchanged.
• Integrity: Data must not be modifiable when stored or transmitted. Any modification must be detectable.
• Non-repudiation: Cannot deny the authenticity of their signature on a message. This provides the transaction ‘digital’ legitimacy and traceability.

Current cryptographic systems provide all the above or a combination of the features in various forms for an intended application.

Let’s explore each of these goals some more to get a basic idea of how they are achieved.

Confidentiality

The requirement is to keep the information secured from unauthorized access. This is accomplished by encrypting the message to be sent using a cryptographic algorithm with a key that is only known by the sender and recipient. An interceptor might be able to obtain an encrypted message but will not be able to decipher it.

Making Information "Confidential"

In the above diagram we have shown a simple case of how encryption is used. In this case, the sender and recipient have worked out a system to share the encryption/decryption key and they use that key to encrypt/decrypt the messages they exchange between each other. If a malicious individual intercepts the message, no harm is done as that person will not have the key to decrypt the message. We will discuss the key sharing and encryption algorithms in a later section.

Identification and Authentication

The goal here is to first identify an object or a user and then authenticate them prior to initiating communication or other operations. Once the sender has authenticated the recipient, further communication can resume.

Play the video below for further details.

We have described authentication in one direction in the above example. The bank (sender) is authenticating the customer’s PC (recipient) using a simple User Name and Password combination before letting the customer use the bank’s website. The actual process is much more complex but we are using this simple example to illustrate the concepts. Identification and Authentication can also be a bidirectional process, where the sender and recipient both may need to identify each other before starting message exchanges. We will explore all those topics in detail later.

Integrity

How do we make sure that a message sent and then received over a communication network or data link hasn’t been altered during transit? For example, there could be an attempt to intercept a message and insert a virus or malicious program to take control of the recipient’s PC or equipment without their knowledge. To prevent this from happening, it is vital to make sure that any message transmitted is not modified.

Preserving Integrity"

<

As shown above, one way to do this is to use a message digest. The sender and recipient are using an agreed upon Message Digest Algorithm to create and verify the message digest output. If the message is altered the message digest will not match and the recipient can then conclude that tampering has occurred or there was a transmission error. There are many Message Digest Algorithms that are being used in modern cryptographic applications including SHA-2 and most recently SHA-3.
We will dive into the details within the Common Algorithms section.

Non-repudiation

In a communication system where a multitude of messages are exchanged, there’s a need to trace the incoming message back to the Sender. This is required to ensure that the Sender does not deny sending the message. Very similar to a pen-and-paper legal document where we sign on the dotted line to finalize a contract, a digital signature is used to achieve similar goals in the digital domain.

The above example is a simplified view of the digital signature generation, transmission, and verification process. First, the Sender takes the outgoing message and puts it through a Message Signing Algorithm to generate a digital signature related to the message and the Sender’s verified identity. The Sender then attaches the digital signature to the original message and sends it to the Recipient. The Recipient takes the incoming combined message and separates the original message and the digital signature. Both are then input into a Message Verification Algorithm. The result can then be used by the Recipient to prove that the message was signed by the Sender. We will discuss digital signature algorithms in detail in the Common Algorithms section.

Let’s Dive into Cryptographic Algorithms

The security of cryptographic applications critically relies upon symmetric keys and private keys continually being kept secret and that the method used to keep them secret is also protected.

There are two fundamental types of algorithms that are used in modern cryptography. Asymmetric and Symmetric key algorithms. Asymmetric key algorithms use a combination of Private and Public keys and Symmetric algorithms use only private, commonly referred to as secret keys. The following chart gives us a snapshot of the main features of each of the Algorithmic methods.

Cryptographic Algorithm Comparison

Now let us investigate how we can achieve each of the cryptographic goals using these two algorithms

Confidentiality Using Symmetric Key Algorithms

The main goal of confidentiality, as you recall, is to keep the information secured from all that are not privy to it. On a Symmetric Key Cryptographic System this is very straightforward and can be achieved by encrypting the data that is exchanged between the Sender and the Recipient. Both the Sender and the Recipient has access to the same secret key that is used to encrypt and then decrypt the exchanged message. This is shown in the video below.

As long and the Key is secured and only the Sender and the Recipient have access to the encryption/decryption key, no one else can get to the transmitted message even it is intercepted mid transmission. Thus, the message stays confidential.

Confidentiality Using Asymmetric Key Algorithm

On an Asymmetric Key System, the Recipient freely distributes her/his public key. The sender receives this public key and verifies the authenticity of this Public Key. There are a few steps to how that is accomplished. We will get into the details of that process in a later section. But for simplicity, lets assume that the sender has access to the verified public key of the recipient. The Sender then uses that Public key to encrypt the message and send it over to the Recipient.

The Recipient’s Public key is mathematically related to the Recipient’s Private key. The Sender and anyone else for that matter has no access to the Recipient’s Private key. Once the Recipient receives the Sender's message, the Private key is used to decrypt the message. The Recipient’s Private Key is the only key that can be used to decrypt the message that was encrypted with the related Public Key. As the Private key only resides with the Recipient, any other person or organization can’t decrypt the sent message. Thus, the message stays “Confidential”.

Identification and Authentication Using Symmetric Key Algorithm

Let’s recall that the goal for Identification and Authentication is to first identify an object or a user and then authenticate them.

How is this achieved using a Symmetric Key Scheme? The following animation shows a simple example of a Symmetric key Identification and Authentication Process. Please follow through steps 1 to 6 to get an understanding of the process.

Why do we need a “Nonce”?

An imposter could get hold of the last digest transmitted by the recipient and then requests an “Authenticate me” with that digest. These types of attacks are called “Replay Attacks” (i.e. resend a previously used digest). Use of a “Nonce” or single use random number for authentication prevents such attacks. In this case the authentication will fail because each authentication sent will require a new digest with a new “Nonce”. These numbers are usually generated using an approved random number generator.

Now let’s look into a real-life example of Identification and Authentication using the SHA3-256 algorithm.

Symmetric Key Algorithm-Identification and Authentication

The following video shows a more complete example of a Symmetric Key Identification and Authentication Process. This uses the SHA3 Symmetric Key Algorithm.Analog Devices is the first to have a SHA3-256 secure authentication device in production. Please follow the steps in the video to get an understanding of the process.

The “Random Number” is basically the “Nonce” that is needed to prevent replay attacks.

Identification and Authentication using Asymmetric Key Algorithm

Let’s recall that the goal for Identification and Authentication is to first identify an object or a user and then authenticate them so that we know that we are communicating with some one that we really meant to communicate with.

How is this achieved using an Asymmetric Key Scheme? The following video shows a simple example of a Asymmetric key Identification and Authentication Process.

Why do we need a “Nonce”?

An imposter could get hold of the last signature transmitted by the recipient and then issues an “Authenticate me” with that signature. These types of attacks are called “Replay Attacks” i.e. resend a previously used signature. Use of a “Nonce” or single use random number for authentication prevents such attacks. In this case the authentication will fail, as for each authentication the Sender requires a new signature with a brand new “Nonce” number. These numbers are usually generated using an approved random number generator.

Now let’s look into a real-life example of Identification and Authentication using the ECDSA algorithm

Asymmetric Key Algorithm-Identification and Authentication

The following video shows a more complete example of an Asymmetric Key Identification and Authentication Process. This uses the ECDSA Asymmetric Key Algorithm.

This completes the device authentication

However, it doesn’t cover the complete System Authentication process, which includes verifying that the Recipient is part of the system. This requires verifying the device's digital certificate. We will cover digital certificates along with more detailed description of digital signatures in the Non-repudiation section.

Comparing Cryptographic Algorithms

Here is a side by side comparison of key usage for Symmetric and Asymmetric key algorithms.

The following diagram shows a more complete example of an Asymmetric Encryption Process using the ECDSA Asymmetric Key Algorithm.

Before we go into the next topic, we need to understand the differences between the following two concepts:

1. Secure Hash
2. HMAC (Hash-based Message Authentication Code)

The following diagram illustrates the differences between the two. Essentially, the Secure Hash uses a hashing algorithm such as SHA-3 to produce a fixed length hash of the message regardless of the message length. HMAC is similar but uses a key as an additional input to the hashing engine. It also produces a fixed length hash regardless of the input message length.

Preserving Integrity using Symmetric Key Algorithms

The goal of preserving the integrity of a message is to make sure that any message received or any new device being connected is not carrying unwanted code or information.

Let's look at an example of how this can be achieved using a Symmetric Key Algorithm such as SHA-3.

We will go into the specifics of how these algorithms work later.

Symmetric Key Algorithm-Preserving Integrity with SHA-3

An HMAC is a digest/hash that is generated using Specific key. Hence it is a “keyed” digest/hash of a message.

In the above diagram, the sender calculates the digest of a message by using a specific key. As this is a symmetric key scheme, the key is shared between the Sender and the Recipient. We will discuss secure methods of key sharing in a later section. The digest/hash that is generated using a key is called an HMAC (Hash-based Message Authentication Code).

This is generated by feeding the message and the key to the SHA-3 Engine. The resultant HMAC along with the message is then sent to the Recipient. The Recipient then generates an HMAC using their key. The two HMACs are then compared and if they match the message has not been tampered with. In this scenario, an attempt to intercept the HMAC and alter the message will be unsuccessful without the knowledge of the Recipient's Shared Key.

Preserving Integrity using Asymmetric Key Algorithms

The goal of preserving the integrity of a message is to make sure that any message received, or any new device being connected is not carrying unwanted code or information.

Let’s look at an example of how this can be achieved using an asymmetric key algorithm such as ECDSA (Elliptic Curve Digital Signature Algorithm).

We will go into the specifics of how these algorithms work later.

In the above diagram the Sender calculates the digest of a message by feeding the message to a SHA-2 hashing engine. As this is an asymmetric key scheme, this key is not shared between the Sender and the Recipient. The Sender has a private key that is never shared, and the recipient has a public key that can be shared with many people. Unlike the symmetric key algorithm, the digest/hash that is generated doesn’t use a key.

This generated digest is then fed to the ECDSA engine along with the sender’s private key to generate a digital signature of the message. This signature along with the message is sent to the recipient. The recipient then computes a message digest from the received message. This digest, along with the received digital signature and the public key are fed into ECDSA verification engine. If the verification engine produces an affirmative result, the message is authentic, and the recipient can be assured that the integrity of the message has been preserved.

Non-repudiation Using Asymmetric Key Algorithms

A message signed by a Digital Signature from the sender can be used to prove that the message was sent by the sender and that the message was unaltered. However, a Digital Signature cannot prove the identity of the sender. Prove of identity is achieved by using a Digital Certificate. The following diagram shows the steps needed to achieve a complete Public Key System where messages exchanged cannot be repudiated by either party.

Step 1: Sender and the Recipient exchange each other’s Digital Certificate that is signed by a trusted third party (Certificate Authority – CA)

Step 2: Sender and the Recipient extracts the CA’s Digital Signature from each other’s Digital Certificate and then verifies it. This Verifies the authenticity of the two certificates

Note: The CA's Certificate was signed by the CA's Private Key not shared with the Sender or the Recipient.
The Certificate is verified using the CA's Public Key (Freely distributed).

Non-repudiation Using Asymmetric Key Algorithms

Step 3: Now that the Sender and the Recipient have verified the Authenticity of each other’s Certificates, they Extract each other’s Public Keys from the Certificate.

Step 4: The Sender and the Recipient can exchange messages using each other’s Public Keys. These Messages can’t be repudiated by either as they were exchanged using Public Keys that were extracted from a Digital Certificate signed by a trusted third party (CA Authority).

Note: This diagram shows a Sender to Recipient example. It can be reversed to show a Recipient to Sender Transaction

The main idea is that both the Sender and Recipient need to prove their identity to one another, and their respective public keys need to be proven authentic by a trusted third party.

Digital Certificates are important because they protect against someone from impersonating the Sender. For example, an Attacker could send a message encrypted with Recipient’s public key along with a Digital Signature signed with the Attacker’s Private key. The Attacker’s message to the Recipient will contain his own made up Public Key, which the recipient will use to verify the Message Digest. Since the Key was not verified by other means, it will pass the verification.

The message from the Attacker will contain malicious information that could affect the Recipient. The Digital Certificate verifies the Sender’s public key belongs to an authorized source before it is used by the Recipient.

XOR Function

XOR (Exclusive Or) is a vital logical operation that is used in numerous cryptographic algorithms. The following diagram shows how this function works. This basic understanding is needed before we go into describing any of the algorithms.

Exclusive OR (XOR) – A fundamental element of reversible (i.e. lossless) encryption

Data can be encrypted with an XOR algorithm by using one input as data and the other input as a secret key bit stream. The XOR result will be an encrypted message that can be unencrypted by XOR'ing it with the secret key.

For example, the string "Hello" (‭01001000 01100101 01101100 01101100 01101111‬ in 8-bit ASCII) can be encrypted with the repeating key 11110011 as follows:

And conversely, for decryption:

SHA (Secure Hash Algorithms)

The basic idea behind a SHA function is to take data of variable size and condense it into a fixed size bit string output.

This concept is called hashing. The SHA functions are a family of hashing algorithms that through NIST (National Institute of Standards and Technology) oversight have been developed over time. The latest of these is the SHA-3 function. Analog has a family of secure authenticator products that use both SHA-2 and SHA-3 functions.

The following diagram shows the basic concept of secure hash generation.

Secure Hash Generation-Basic Concept

The SHA function has the following characteristics:

1. Variable input length

2. Fixed output length

3. It is a one-way function.
   In the above diagram, it is impossible to use the resultant hash value to regenerate the input text, other than trying each possible input text.
   This becomes computationally impossible for sufficiently large inputs.

4. If the same input message is fed to the SHA function it will always generate the same resultant hash.

5. Low probability of generating the same hash value using two different input values. This is called "Collision Resistance".

6. Small change in the input value, even a single bit, completely changes the resultant hash value. This is called the "Avalanche effect".

If a hash function satisfies all the above, it is considered a strong hash function.

Some of the SHA function currently in use are:

• SHA-1
• SHA-2
• SHA-3

Now let's explore how SHA functions work. We will only cover SHA-2 and SHA-3 here. SHA-1 is being phased out and it is not recommended for any new designs.

How does SHA-2 work?

The SHA-2 function has four main types based on output bit length:

1. SHA-224 – hash is 224 bits long

2. SHA-256 – hash is 256 bits long

3. SHA-384– hash is 384 bits long

4. SHA-512– hash is 512 bits long

Let's take a look at SHA-256 as an example. The following diagram shows a block diagram of a SHA-256 engine.

Secure Hash Generation-SHA-256 Function

The input message is first padded to make sure that it will completely fit in “n” number of 512-bit blocks.

The first 512-bit block is then fed into a compression function along with an initial 256-bit hash value. The compression function essentially shuffles the message 64 times then compresses it to 256-bits and sends it out to the next compression block or out as the final hash. Thus, a variable input message gets shuffled many times to prevent it from being used to get to the original message. Once that is done, the output hash is generated.

How does SHA-3 work?

The SHA-3 function has no predefined output length. The input/output lengths have no Analogums. But just for comparison purposes with SHA-2, lets define four main types based on output bit lengths as per NIST standard.

1. SHA3-224 – hash is 224 bits long

2. SHA3-256 – hash is 256 bits long

3. SHA3-384– hash is 384 bits long

4. SHA3-512– hash is 512 bits long

Let’s take a look at SHA3-256 as an example. SHA3 uses a Keccak sponge function. Just like a sponge, the first step is to soak in or absorb the input message. In the next phase the output hash is squeezed out. The following diagram shows a block diagram of a SHA3-256 function.

Secure Hash Generation-SHA3-256 Function

The iteration function on the above diagram takes in the 1600 bits of data and then puts it through 24 rounds of permutation using a specific algorithm and then passes it to the next stage as a 1600-bit block. This continues until the absorbing phase has completed.

Once the absorbing phase has been completed, the last 1600-bit block is passed to the squeezing phase. In this case, as SHA3-256 output hash length is less than 1088-bits, the squeezing phase do not need any iteration functions. We take the first 256 bits from the last stage and that is the output hash.

If the required hash length was for example 2,500 bits, we would have needed three more instances of the iteration function to get the desired length hash.

Go to the Tools tab if you would like to apply or test these hash functions

AES (Advanced Encryption Standard)

Like older encryption algorithms such as DES (Data Encryption Standard) and 3DES (Triple Data Encryption Standard) the purpose of the AES algorithm is to scramble and substitute input data based on the value of an input key in a reversible way. The result is called Ciphertext. The AES algorithm was designed to replace the DES and 3DES algorithms developed in prior decades and are vulnerable to attack. A description of the AES is shown below.

Advanced Encryption Standard-AES Algorithm

The AES algorithm is a fixed-width encryption algorithm. Therefore, the input message is first padded to make sure that it will completely fit in “n” number of 128-bit blocks.

Each 128-bit block is fed into the encryption algorithm, along with an encryption key. Depending on the number of bits in the encryption key, the AES algorithm performs a certain number of rounds of obscuring the input block bits. This obscuring is accomplished by shuffling data bits, taking portions of the data and substituting them with values from a look-up table (like a decoder wheel), and performing XOR operations in order to flip bits from 0 to 1 according to the values of bits in a set of “round keys” generated from the input encryption key. A round key is used one time for one of the obscuring rounds and is created by “expanding” a portion of the encryption key by copying bits and inserting the copies in between other bits.

The AES decryption function simply performs the reverse of the operations in the encryption function using the same encryption key in order to unscramble the original input block data.

3DES (Triple Data Encryption Standard)

The basic idea behind the Triple DES (aka. 3DES) algorithm is to scramble and substitute input data based on the value of an input key in a reversible way. The result is called Ciphertext. The 3DES algorithm is a reprise of the original DES algorithm (Data Encryption Standard), developed in the 1970s. When DES was compromised in the 1990s, the need for a more secure algorithm was clear. 3DES became the near-term solution to the problems with single DES. In order to understand 3DES, a description of the original DES is first shown below.

DES Data Encryption Standard– Algorithm

The DES algorithm is a fixed-width encryption algorithm. Therefore, the input message is first padded to make sure that it will completely fit in “n” number of 64-bit blocks.

The each 64-bit block is fed into the encryption algorithm, along with a 56-bit encryption key (most versions of the algorithm take a 64-bit key, but 8 bits are ignored). The encryption function uses the input key to generate 16 “subkeys”, each used for 16 rounds of obscuring the input block bits. This obscuring is accomplished by shuffling data bits, taking portions of the data and substituting them with values from a look-up table (like a decoder wheel), and performing XOR operations in order to flip bits from 0 to 1 according to the values of bits in the subkeys.

The DES decryption function simply performs the reverse of the operations in the encryption function using the same encryption key in order to unscramble the original input block data.

How does 3DES work?

The Triple DES Algorithm

After DES was shown to be vulnerable to attacks shorter than a “brute force attack” (or, cycling through every possible key value until the original message blocks are revealed), a simple method of effectively increasing the size of the encryption key was developed. Below is the 3DES solution:

Triple Data Encryption Standard– 3DES Algorithm

The 3DES algorithm is literally 3 DES operations. The first and last operations are encryption operations, while the middle operation is a decryption operation. It is important to note that “encryption” and “decryption” are just names assigned to scrambling operations that are the reverse of each other

For each of the DES operations performed in 3DES, a dedicated key is used for that operation. Often, the key for the first and third operations is the same. Using the same key for the first and third operations, and a different key for the middle operation effectively doubles the total key length, making a brute force attack much harder, and eliminating the vulnerabilities of single DES.

RSA Public Key Cryptosystem

RSA is named after its creators, Ron Rivest, Adi Shamir, and Leonard Adleman, and is one of the first asymmetric, public-key encryption/decryption systems. It uses the properties of modular arithmetic of prime numbers to generate a public key that can be used for encryption and a private key that can be used for decryption. The encryption and decryption operations are also based in modular arithmetic. An overview of the RSA is shown below.

RSA Encryption

The key generation and encryption/decryption operations are known as one-way or “trapdoor” functions. They are mathematical operations that are relatively simple to calculate in one direction, but difficult to calculate in the other direction. For instance, it is easy to calculate X², but harder to calculate the square root of X.

In the case of RSA, two large prime numbers are multiplied together to create a part of the public and private keys. The multiplication is easy; factoring back to discover the secret prime numbers is difficult.

It is also much easier to encrypt a message with the public key than to try to go in reverse to obtain the message without the private key. However, the private key can also easily unlock the message, and must therefore never be shared.

The private key can be viewed as opening a trapdoor, revealing a shortcut to bypass the complex maze of attempting to breaking an encrypted message.

RSA’s security relies on large prime numbers and complex operations. Even the easy path through its trapdoor functions with large keys is cumbersome for most computing systems. Therefore, RSA is often used as a vehicle to send shared encryption keys that can be used in faster, symmetrical algorithms like DES, 3DES, and AES for individual transactions.

ECDSA Algorithm

The Elliptic Curve Digital Signature Algorithm (ECDSA) allows a participant in a communication to prove authenticity by generating a digital signature for an input message based on a hidden piece of information known as private key. This key can be used to generate a public key that can be used by others to verify the participant's authenticity.

Digital signatures are generated with an input message, a private key, and a random number. The public key can then be used to verify that the signer (the participant) is in possession of the corresponding private key and is therefore authentic. This concept is illustrated below.

Elliptic Curve Digital Signature Algorithm– ECDSA

The Digital Signature Algorithm was first introduced with modular arithmetic, which depends on large prime numbers and calculations requiring heavy use of computing power. The introduction of Elliptic Curve Cryptography utilizes the mathematical properties of elliptic functions to simplify the math without sacrificing security.

The key generation and signing operations are known as 1-way or “trapdoor” functions. They are elliptic curve calculations that are relatively simple to compute in one direction, but difficult to compute in the other direction. The private key can be viewed as opening a trapdoor, revealing a shortcut to bypass the complex maze of attempting to breaking a key generation or signing operation.

ECDSA allows one party to sign messages, from any party. However, to prove authenticity with ECDSA, a signer must not have foreknowledge of the message to be signed. This lack of control over the message allows another participant in communication to “challenge” the signer with new information to prove possession of the private key.

ECDH Key Exchange Protocol

The Elliptic Curve Diffie-Hellman (ECDH) key exchange allows for two parties to establish a shared key for communication with only one piece of hidden information called a private key. Without the private key of one of the parties involved, an eavesdropper cannot easily determine the shared key. However, the algorithm allows the private key of one party and the public key of the other party to be combined to produce a resulting key that is the same for both parties. This concept is illustrated below.

Elliptic Curve Diffie Helman Key Exchange– ECDH

The Diffie-Hellman key exchange was first introduced with modular arithmetic, which depends on large prime numbers and calculations requiring heavy use of computing power. The introduction of Elliptic Curve Cryptography utilizes the mathematical properties of elliptic functions to simplify the math without sacrificing security.

The key generation and key combination operations are known as 1-way or “trapdoor” functions. They are elliptic curve calculations that are relatively simple to compute in one direction, but difficult to compute in the other direction. The private key can be viewed as opening a trapdoor, revealing a shortcut to bypass the complex maze of attempting to breaking a key generation or combination operation.

The ECDH algorithm allows two parties to establish a key together, but it does not guarantee that either party is to be trusted. For this, additional layers of authentication are required. For instance, if a public key is given a certificate such as an ECDSA (Elliptic Curve Digital Signature Algorithm) signature calculated with a private key from a trusted key holder, the certification of the public key is verified by authenticating the certificate with the trusted holder’s public key.

One method of proving the identity of the correspondent in an ECDH protocol exchange would be for party A to sign a nonce with an ECDSA private key. Party B can verify the signature by obtaining the public verification key from a trusted key authority and applying the ECDSA verification algorithm.

Physical Unclonable Functions (PUF)

In cryptography and within embedded security ICs, Physically Unclonable Functions (PUF) are used to create persistent keys that are generated on demand and instantaneously erased once used. Because PUF is dependent on random physical factors (unpredictable and uncontrollable) that exist natively and/or are incidentally introduced during a manufacturing process and is virtually impossible to duplicate or clone.

PUF technology natively generates a digital fingerprint for its associated security IC, which can be utilized as a unique key/secret to support cryptographic algorithms and services including encryption/decryption, authentication, and digital signature.

Except for the momentary duration of a cryptographic operation, the PUF key value never exists in digital form within the circuitry of the security IC. Further, since the key is derived and produced on-demand from physical characteristics of circuit elements, it is never present in the device’s non-volatile memory.

As it will be described, any attempt to discover the PUF key value through micro-probing or other invasive techniques results in a disturbance to the sensitive circuitry rendering the output useless. Thus, they provide a level of security that is very desirable in today’s embedded systems.

This short lesson is designed to outline and explain a simplified hypothetical PUF architecture and its usage. The PUF elements are much more complex and sophisticated. But this lesson should be enough to give the user an understanding of why PUF based key generation can provide such excellent protection against inadvertent key disclosure in cryptographic applications.

A Hypothetical Ring Oscillator Based PUF

The following diagram shows two separate example devices, each with a 64 bit PUF based key. (This is a simplified general view – not Analog’s implementation)

Physically Unclonable Function (PUF) – Key Generation

The devices in the above diagram have 64 different PUF blocks that generate 1 bit of data. The bits are then shifted to create the 64-bit key. Each device will have independent keys that are repeatable over voltage, temperature, and age. Device #1 will produce a key that will have enough bits that are different from the key produced by Device#2. Each of the device keys however will stay constant over the specified voltage and temperature range.

Next let's explore a possible implementation of the PUF blocks of one of the devices in detail.

Physically Unclonable Function (PUF)

Data Bit Generation (simplified general view)

In this example we show a simple PUF implementation scheme based on frequency variation of ring oscillators. The next section will expand on ring oscillators and why they produce slightly different frequencies for each instance of the block.

For now, let’s assume that each of the PUF blocks have two ring oscillators that produce slightly different frequencies. In PUF BLOCK#1, F1 will be slightly different than F2 and this will let the compare block produce a bit 0 or bit 1 based on whether or not F2 is faster than F1.

How does this design help us with voltage, temperature and age variations?
We are comparing the two input values used to generate bits rather than using one frequency output. For example if voltage increases for F2, F1 voltage will increase as well. Yet the delta between the two should stay the same. This results in the same bit value produced with a different applied voltage. The same applies to temperature and age variations.

As PUF BLOCK#2 to #64 are instantiated, the ring oscillator blocks inside them will produce slightly different frequencies from each other in an unpredictable way. This results in an unpredictable bit pattern for bits 1 to 64. Although the overall bit patterns can’t be predicated, the actual bit pattern produced is repeatable as each block always produces the same bit.

Now let’s look at a simplified ring oscillator design.

A ring oscillator is constructed from an odd number of inverters arranged as shown above. The output frequency of the oscillator is dependent upon the delay of each of the stages of the ring. From an integrated circuit perspective, this delay is dependent on wafer characteristics including oxide thickness, capacitance and threshold voltage of each transistor gate that makes up the inverter stages. Due to imperfection and variation in the semiconductor manufacturing process, all these parameters vary slightly and with complete randomness. No matter how controlled the process is, it is impossible to avoid this random variation. All of this turns out to be a good thing for PUF implementation as the key produced needs to have cryptographic-quality randomness.

A primary value that a PUF brings to cryptography is the inherent protection of the key/secret value that it derives and produces from the physical characteristics of circuit elements. As described for the ring oscillator example, electrically sensitive parameters such as threshold voltages, capacitance and gate oxide thickness directly influence delays through the circuit. Probing or modifying the PUF to obtain key data in turn permanently modifies and disrupts these sensitive characteristics. This results in a change to the key value the PUF would output making it useless and rendering the crypto IC permanently nonfunctional. Similarly, any attempt to reverse engineer and clone a PUF results in a circuit that cannot output a key value which is correct for the system environment in which the security IC is deployed.

Analog’s ChipDNA™ PUF Technology

Analog’s PUF technology is known as ChipDNA. It is not ring oscillator based like the hypothetical example. ChipDNA fundamentally operates from the naturally occurring random variation and mismatch of the analog characteristics of MOSFET semiconductor devices. This randomness originates from factors like those described previously: oxide variation, device-to-device mismatch in threshold voltage, interconnect impedances and variation that exists within wafer manufacturing through imperfect or non-uniform deposition and etching steps. ChipDNA also operates from a patented approach to ensure that the unique binary value generated by each PUF circuit has high cryptographic quality and is guaranteed to be repeatable over temperature and voltage and as the device ages.

Next section explores some ChipDNA Applications

ChipDNA Applications

The following two examples show use cases for ChipDNA PUF integrated into a Analog secure authenticator cryptographic IC.

Securing Stored Data

In this case, we are using the ChipDNA PUF key, when needed, to decrypt the EEPROM-stored SHA3 secret used for an authentication sequence. Any attempt to obtain the secret from EEPROM will result in AES encrypted data that is useless to an attacker. Additionally, any effort to probe the PUF will result in permanent disruption of its operation resulting in the device being inoperable and again useless to the attacker. However, if the device is not modified ,it will serve its purpose faithfully by generating the PUF key on demand and decrypting the SHA3 secret for a momentary authentication operation.

Key Generation for Authentication

In this example the ChipDNA PUF key is used directly as the private key for an ECDSA signature computation. With ECDSA, by definition, the private key is a random number. With ChipDNA producing a high cryptographic quality random number, it is ideal for this use. With asymmetric ECDSA there is also a public key required to verify signatures and it is mathematically associated with the private key. In this example the ECDSA private key(PUF) is never exposed outside the IC. The public key would be computed by the ECC engine on request and stored in EEPROM for transmission to a host controller when requested.

This second example also demonstrates the use of ChipDNA PUF within the scope of benefiting key infrastructure and management. In more complex use cases ChipDNA becomes the immutable root key of the security IC.

Hardware vs Software Cryptography

Modern cryptographic algorithms can be implemented on microcontrollers having dedicated cryptographic hardware or software running on general purpose hardware. For various reasons, dedicated cryptographic hardware provides a better solution for most applications. The following diagram shows a list of reasons why hardware based cryptographic solutions are more desirable.

Hardware vs Software Cryptography Comparison

Analog Integrated Secure Authenticator Applications:

This section gives you a window into various applications whereAnalog Devices's Authenticators can be used to secure your devices and system.

• Secure Boot and Secure Download
• Related Devices

• DS28C36
• DS2476
• DS28E83
• DS28E84
• MAXQ1061
• MAXQ1065

• TRNG (True Random Number Generator) Source
• Related Devices

• DS28C36
• DS2476
• DS28E83
• DS28E84
• DS28E38
• MAXQ1061
• MAXQ1065

• Introduction
• Requirements
• How the website communicates with hardware
• Navigating the lab
• Running a lab sequence

Introduction

The Lab section is your next step in your cryptography learning path.
If you are here for the first time or are unfamiliar with the basic concepts of cryptography, we recommend you to review the Learning Section first.

It is recommended to get familiar with the hardware used on this section to better understand each lab sequence.

Hyperlinks provide access to device documentation, ordering information, datasheets and customer support.

Requirements

1. PC running Windows^® 7 or higher with USB port

2. Security Lab Application. The provided PC software application provides a web socket connection between the user’s hardware and the Security Lab website.
   More details are explained in the next section.

3. MAXAUTHDEMO#1 with DS28C36 The hardware includes a USB adapter and DS28C36 evaluation board. The module includes the DS28C36 authenticator that has been preprogrammed to work with the lab demos.

4. MAXAUTHDEMO#2 with DS28E38 The hardware includes a USB adapter and DS28E38 evaluation board. The module includes the DS28E38 authenticator has been preprogrammed to work with lab and demos.

Server/Client Communication

The communication between the webpage and the hardware is not executed locally on the computer. All communication is handled remotely by a back-end server.

1. A remote back-end webserver is always running and listening to any browser connection or PC connection.
   
   


2. A web socket connection is established directly to the remote back-end server when the user opens the Security Lab website.
   
   


3. Attach the hardware to the computer's USB port and run the Security Lab application.
4. The Security Lab application connects to the remote back-end server and the hardware attached to the USB port.
   
   




5. To send and receive communication between the two clients an access code is needed to establish a connection.
   
   
   
   
   The Security Lab application and the webpage are two different clients to the server and in order to start communication, the website provides its own number that the Security Lab application could use to start the "call."
   
   Since both applications are normally running in the same computer it looks like a single connection. Yet the connections are separate and depend on the back-end connection.

Navigating the lab

1. The left side of the Security Lab window contains the list of all available labs. The list will change depending on the hardware selected.

   

2. The sections contain help buttons that guide you to through the steps and provides detailed information for each sequence.

   

3. Navigation through the sequences is controlled by the Previous and Next buttons.

   
4. Hyperlinks provide access to device documentation, ordering information, datasheets and customer support.
5. To return to the top menu, simply the selected topic a second time. To execute a different lab, simply click the lab. For labs requiring a different hardware, return to the main lab page, and make the desired selection. The new labs will be displayed.
   
   

Running a lab sequence

1. Go to the Lab and follow the instructions provided on the Lab landing page
   
   
2. The Security Lab application will open a command window with a prompt to enter the link code.
3. On the left side of the Security Lab window, click the desired lab to start.
4. Navigate the lab using the Next button. A small instructional message is always displayed with details of the step to be executed.
   Each section contains an Info button that provides details of what is being executed on the hardware side and information about the specific sequence.
   
   
5. To return to the main Lab landing page, simply click the selected topic a second time.

If you are ready to start, click the Lab tab

For any other questions or request, feel free to contact Analog Technical support  Close section

---

• Bidirectional Authentication
• Related Devices

• DS28C36
• DS2476
• DS28E83
• DS28E84
• MAXQ1061
• MAXQ1065

Secure Boot and Secure Download

What are they and why are they important?

IoT devices that proliferate in our lives use embedded hardware such as :

• Home devices like Wi-Fi cameras, IoT thermostats and smoke detectors

• Medical devices

• Wearables, fitness trackers or smartwatches

• Industrial machines such robotic arms in factories

Almost all these devices contain boot firmware or downloadable data that requires access to the Internet, so they are at risk. Boot firmware is essentially data saved in non-volatile memory and are the instructions that make the device operational. This firmware is updated from time to time to fix bugs and enhance its features.

Why protect IoT device firmware or data?

IoT devices must be trustworthy and that means the device firmware and critical data must be verified to be genuine. In a perfect world boot firmware and configuration data would be locked down at the factory, but customers have come to expect firmware updates and reconfiguration to be available over the Internet. And that’s the problem: malicious actors can use these network interfaces as a conduit for malware. If someone gains control of an IoT device, they may be able to take control of the device for malicious purposes. For this reason, any code that purports to come from an authorized source must be authenticated before it’s allowed to be used.

• If the attacker can gain physical access to the device, then malware may be introduced by means of a physical connection (USB, Ethernet, etc.)

• Operating systems often exhibit vulnerabilities that are closed as they are discovered by means of a patch. If an attacker can access an unpatched system, they may be able to introduce malware.

• Frequently, IoT devices will contact update servers to determine if updated firmware or configuration data is available. An attacker may intercept the DNS request and redirect the IoT device to a malicious source that hosts the malware or corrupt configuration data.

• The authentic website may be misconfigured in such a way to allow an attacker to take control of the website and replace authentic firmware with one that contains the attacker’s malware.

Infiltrating a non-protected IoT device vs. a secured IoT device

We can prevent infiltration and protect against malware injection by using Secure Boot and Secure Download. This means the IoT device can trust the updates being received from the command/control center.

Please take note, if the command/control center wants to fully trust the IoT device then an additional step of authenticating the IoT device’s data needs to occur.

So how do we go about protecting these devices by using Secure Boot and Secure Download?

Firmware Authentication and Integrity

Authentication and Integrity can provide a way to:

• Ensure that the targeted embedded device runs only authorized firmware or configuration data.

• Ensure that the data is trusted and not subsequently modified.

• Prove that data is both authentic and has integrity.

One method is to utilize cryptographic digital signatures, like a seal or written signature at the bottom of a letter. With this method, the firmware and configuration data are loaded during the manufacturing phase and all subsequent updates are digitally signed. The digital signature enables trust during the device’s entire lifetime.

The following two features of digital signature are paramount to providing security:

• The digital signature used must be computed by a cryptographic algorithm.

• The algorithms need to be public and well proven to bring the highest level of security.

The next example uses asymmetric cryptographic algorithms, specifically, the FIBS 186 Elliptic Curve Digital Signature Algorithm (ECDSA).

Asymmetric Cryptography applied to Secure Boot/Download

Asymmetric cryptography uses a public/private key pair for algorithm computations.

• The start of any key pair generation is selecting a random number to be used as the private key.

• The random number is used by the key generator, which outputs a public key.

• The public key can be distributed freely to all without any security risk.

• However, the private key is critical information that must be kept confidential.

The fundamental principles of secure download in asymmetric cryptography are:

1. The firmware developer uses the private key for signing

2. An embedded device (that is an IoT device) uses the public key for verification.

You may ask, so why use asymmetric key cryptography?

• The advantage is no private key is stored on the embedded device. Hence, the attacker cannot retrieve the private key.

• Lastly, the algorithm chosen (e.g. ECDSA) makes it mathematically infeasible to derive the private key from the public key.

First, let's look a t what must occur at the R&D Facility.

R & D Facility

• Initial firmware is developed.

• The firmware must be put through a SHA-256 multi-block hash computation.

• The private key and hash are inputted into the ECDSA signing algorithm. The output is a unique signature that could have only been signed by the private key.

• Combine firmware with the signature and send it out upon request for field usage.

The following diagram illustrates the above points.

R & D Facility

Now let’s examine what occurs during Field Usage.

Field Usage (Firmware Update)

• The embedded device receives the firmware and signature.

• The firmware will go through a SHA-256 multi-block hash computation.

• The embedded device will already contain the public key created during the key generation at the R&D facility.

• The signature and the other ingredients will then be used as input for the ECDSA verify.

• The result from the ECDSA verify will determine if the firmware can be used by the embedded device.

• If the result is a PASS, then the embedded device accepts the firmware that has both authenticity and integrity.

• If the result is a FAIL, then the firmware is rejected.

The following animation shows the process.

Field Usage

For embedded devices that do not have a secure microcontroller with the computational power to perform the calculations required to verify the authenticity and integrity of downloaded firmware or data, Analog Devices DS28C36 Secure Authenticator represents a cost-effective hardware-based IC solution.

Secure Boot and Secure Download using DS28C36

Steps:

1. As discussed previously, a system public-private key pair for the secure boot or secure download function is established at the R&D facility. The system private key of this pair is used to sign firmware, or data, that ultimately is verified by the DS28C36 embedded in the end system. This system private key never leaves the controlled development environment. The system public key of this pair is installed in the DS28C36 in a key register location that has an "authority key" attribute; this is a configurable setting in the DS28C36.

2. The system private key is used to compute the digital signature of the firmware or data.

3. The Analog DS28C36 with the preprogrammed system public key is physically connected to the host processor.

4. When firmware is required to be run by the processor, it is first retrieved by the processor's boot manager and delivered to the DS28C36 in sequential 64-byte blocks to compute a SHA-256 hash.

5. After the DS28C36 completes the SHA-256 hash computation, the processor delivers the ECDSA signature of the firmware or data that was computed in the development environment and appended to the file.

6. After the DS28C36 receives the ECDSA signature the processor sends commands to use the preinstalled system public key to perform a signature verification.

7. If the DS28C36 verifies the signature, the GPIO pin is toggled and a pass result parameter byte is returned to the processor. The status of this pin and parameter byte result acts as a go/no-go result to the processor to run the now known trusted firmware or data update.

8. In addition, if the command/control center would like to trust the DS28C36 an extra ECDSA signature engine is optionally available.

In summary, we have now seen a proven security solution for Secure Boot or Secure Download by using the DS28C36 to address security vulnerabilities on IoT devices. This IC offloads the heavy computational math involved to prove both authenticity and integrity of firmware or data updates.

For more information aboutAnalog Devices’s Secure Boot and Secure Download solutions and services please visit the following two related Authenticators:

• I2C interface DS28C36
• 1-Wire interface DS28E36

Go to the Lab section under MAXAUTHDEMO1 hardware to execute this sequence example or other additional hardware labs.

TRNG (True Random Number Generator)

Output and Typical Use

Analog’s ChipDNA Secure Authenticators have a built in TRNG, which is used by the device for internal purposes or can be send out to the user on requests. Currently, the Analogum length of the TRNG output length is 64 bytes. This hardware NIST compliant random number source can be used for cryptographic needs such as a “Challenge (Nonce)”.

Bi-directional Authentication

Bi-directional (or Mutual) authentication is an important part of secure communication. Both parties of communication should be certain that their counterpart can be trusted. This can be accomplished by proving possession of private information. This information can be shared between the parties or kept completely private, if the ability exists to prove possession.

Symmetric authentication systems require information to be shared among all participants in a given communication. This information is usually called a ‘secret’. A secret is a piece of information known to only those authorized. The secret is used in concert with a symmetric authentication algorithm such as SHA, along with other data shared between participants. The ability to generate a matching signature on both sides of communication proves possession of the secret.

Asymmetric authentication systems, like ECDSA, employ a hidden private key that is used to sign information. The public key, which is shared between parties, verifies the information's authenticity. Proper use of the public key proves possession of the private key, because the private key is needed to decrypt a message encrypted by the public key.

Authentication of the Peripheral:

To authenticate a device, random data known as a “challenge”, along with any other shared data are sent to a Peripheral. The challenge is run through a signing operation with a secret or private key to produce a signature (response). The signature can be verified by the Controller because the Controller is in possession of the shared secret or a public key corresponding to the peripheral’s private key. The general flow of this process is shown below.

Peripheral Authentication

Authentication generally depends upon algorithms that produce signatures that prove possession of a participant’s hidden information but make it difficult to discover the information itself. These are known as one-way functions. SHA and ECDSA are examples of such algorithms.

Authentication of the Controller:

The Controller must prove authenticity to the Peripheral before it can read or modify protected data. An example of this process is shown below in the form of an authenticated write.

Controller Authentication

In the above diagram, the Controller is writing new data into a Peripheral device. However, in order to complete the write, the Peripheral must verify authenticity of the information by requiring the Controller to produce a signature based on the information and the controller’s secret or private key. The Peripheral can verify that the signature is authentic by using either the shared secret or the public key corresponding to the controllers’s private key.

The use of 1-way functions may allow any eavesdroppers to see all data being transmitted but prevents them from determining the hidden information that produced the signatures associated with the data. Without this hidden information eavesdroppers cannot become impersonators.

Threats, Countermeasures and Security Planning

There are threats from various sources to all connected systems, which could be interconnected by the Internet or other means. It could be a Pulse Oximeter that is connected to a patient in a hospital environment or a printer cartridge that is connected to printer. Off course the plethora of IoT (Internet of Things) devices like thermostats and refrigerators are susceptible to hacking. Let’s look at a few of these threats and how to protect devices and what kind of planning is needed to achieve this goal.

Threats …

There are two kinds of threats facing developers today:

1. Threats to Systems
2. Threats to Security ICs

Threats to systems has been well covered by other sources thus we will only cover threats to security ICs. A security IC can be attacked by one or more of the following methods:

• Side channel attacks – such as glitch attack (active) and differential power analysis (passive).

  Any information that is available as a side effect of the physical hardware implementation.This may include power consumption, injection of faults etc.

• Invasive attacks - De-capping and micro-probing to find open ports and traces that can be exploited

• Line snooping - such as man-in-the-middle

• Memory array tampering – such as cold boot attack

Most side channel attacks are non-invasive and do not destroy the IC. De-capping and micro-probing, which physically looks into various features of the IC is an invasive attack that can destroy the IC.

We are not going to get into too much detail about how these attacks are carried out but will show a couple of simple examples.

The following diagram shows an example of a non-invasive side channel attack using clock glitches.

Active Side Channel Clock-Glitch Attack

An attacker with enough technical expertise might intentionally introduce a glitch into the clock or may intentionally run the clock faster than its intended operating frequency. Under these conditions, the output from the security device might provide clues that would make key determination easier.

Next, we will talk about de-capping, which is short for decapsulation.

Decapsulation (Invasive Attack)

Decapsulation involves soaking the plastic package that encapsulates the silicon die into fuming nitric acid that dissolves the package away.

Semiconductor Package

Once the package is dissolved, the exposed die provides an opportunity to directly probe all the available pads including the ones the manufacturer used for internal setup. The top protective glass can be polished away allowing access to the internal connections of the device. With this direct method, one could gain access to the device’s secrets.

Top View of a chip (Simplified)

Countermeasures

To prevent people with malicious intent from breaking into a secure device it needs to be designed with features that not only provide security but also protect the device itself from attacks.

Analog Integrated’s devices have robust countermeasures implemented to protect against all these attacks. Here are some of the implemented features:

• Patented Physically Unclonable Function (PUF) to secure device data

• Actively monitored die shield that detects and reacts to physical intrusion attempts

• All stored data is cryptographically protected

Security Planning

The user needs to decide what features of cryptography are appropriate for deployment depending on their application. The following chart gives some examples of application requirements and the resultant measures that need to be applied.

Security Planning based on Application Security Needs

Examples

For example, if someone is trying to prevent a medical surgical tool from being counterfeited, they must ensure the authenticity of the tool every time it is connected to the host controller. It will also need protection against any malware being installed in the tool that can harm the patient. The need to protect any calibration data that was stored is paramount as well. But as the possibility of snooping between the tool and the host controller is next to impossible due to closed system connectivity, this system will not need protection against eavesdropping. Thus, in this case the system designer needs to plan for all the protections under “Authenticity” but can skip unnecessary protection under the column “Confidentiality”.

Example System – Security Planning

Analog Integrated currently has a multitude of authentication products that can satisfy any and all cryptographic security needs. Follow the Security Authenticators link for additional details.