Benefits and Disadvantages of Cryptography Implementation
Application
Introduction
Secure Boot/Secure Download
TRNG (True Random Number
Generator)
Bidirectional Authentication
Implementing security features using Analog's
Authenticators
Threats and Security Planning
Threats/Countermeasures
Invasive Attack
Countermeasures
Security Planning
Implementing security features using Analog's
Authenticators
DeepCover^{} Learning
Our goal is to provide you with clear and concise explanation of various
cryptographic concepts.
The topics listed on the left discuss these concepts in a non-mathematical
graphical way so that you can get a very clear idea quickly and efficiently.
The accompanied textual explanations are there to guide you through the process
and provide additional information.
If you are new to cryptography, please start at the top and work your
way through the topics. Otherwise you can explore any of the other
topics as you need them.
0
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.
0
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
Security Services and Feature Implementation
Algorithm Method
Symmetric Key
Asymmetric Key
Confidentiality
Yes
Yes
Identification and Authentication
Yes
Yes
Integrity
Yes
Yes
Non-repudiation
Yes-Combined with public/private key algorithm
Yes
Encryption
Yes-Fast
Yes-Slow
Decryption
Yes-Fast
Yes-Slow
Overall Security
High
High
Key Management
Key Exchange and Securing the Key on both the Sender and Recipient side is needed.
One party holds the private key: the sender (for asymmetric message authentication and decryption)
or the receiver (for asymmetric encryption)
Algorithm Complexity
Easy to understand
Can be difficult to understand
Key Size
128 bits, 192 or 256 bits or longer but do not need to be as long as asymmetric key (Depends on
secrecy of keys)
256 bits,1024 bits, 2048, 3072 bits or longer. Depends on the intractability (The amount of time
and resources needed to solve)
System Vulnerabilities
Improper key management, generation and usage
Improper implementation
Attack Approaches
Brute Force, Linear/Differential Cryptanalysis
Brute Force, Linear/Differential Cryptanalysis and Oracle
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 Integrated 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:
Secure Hash
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.
0
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:
01001000 01100101 01101100 01101100 01101111
XOR
11110011 11110011 11110011 11110011 11110011
--------------------------------------------
=
10111011 10010110 10011111 10011111 10011100
And conversely, for decryption:
10111011 10010110 10011111 10011111 10011100
XOR
11110011 11110011 11110011 11110011 11110011
--------------------------------------------
=
01001000 01100101 01101100 01101100 01101111
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:
Variable input length
Fixed output length
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.
If the same input message is fed to the SHA function it will always generate the same resultant
hash.
Low probability of generating the same hash value using two different input values. This is called
"Collision Resistance".
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:
SHA-224 – hash is 224 bits long
SHA-256 – hash is 256 bits long
SHA-384– hash is 384 bits long
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.
SHA3-224 – hash is 224 bits long
SHA3-256 – hash is 256 bits long
SHA3-384– hash is 384 bits long
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^{2}, 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.
0
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.
0
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.
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
PC running Windows^{®} 7 or higher with USB port
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.
MAXAUTHDEMO#1 with DS28C36
The hardware includes a USB adapter and DeepCover DS28C36 evaluation board. The module includes the DS28C36 authenticator that has been preprogrammed to work with the lab demos.
MAXAUTHDEMO#2 with DS28E38
The hardware includes a USB adapter and DeepCover 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.
A remote back-end webserver is always running and listening to any browser connection or PC connection.
A web socket connection is established directly to the remote back-end server when the user opens the Security Lab website.
Attach the hardware to the computer's USB port and run the Security Lab application.
The Security Lab application connects to the remote back-end server and the hardware attached to the USB port.
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
The left side of the DeepCover^{} Security Lab window contains the list of all available labs. The list will change depending on the hardware selected.
The sections contain help buttons that guide you to through the steps and provides detailed information for each sequence.
Navigation through the sequences is controlled by the Previous and Next buttons.
Hyperlinks provide access to device documentation, ordering information, datasheets and customer support.
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
Go to the Lab and follow the instructions provided on the Lab landing page
The Security Lab application will open a command window with a prompt to enter the link code.
On the left side of the DeepCover^{} Security Lab window, click the desired lab to start.
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.
To return to the main Lab landing page, simply click the selected topic a second time.
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.
An attacker may deliver malware to an IoT device by various means:
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:
The firmware developer uses the private key for signing
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
Integrated’s DS28C36 DeepCover
Secure Authenticator represents a cost-effective hardware-based IC solution.
Secure Boot and Secure Download using DS28C36
Steps:
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.
The system private key is used to compute the digital signature of the firmware or data.
The Analog DS28C36 with the preprogrammed system public key is physically connected to the host processor.
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.
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.
After the DS28C36 receives the ECDSA signature the processor sends commands to use the preinstalled
system public key to perform a signature verification.
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.
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 about Analog Integrated’s Secure Boot and Secure Download solutions and services please
visit the following two related Authenticators:
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.
0
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:
Threats to Systems
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
Authenticity
Confidentiality
Integrity
Against Counterfeiting
X
Against Eavesdropping
X
Against Malware Injection
X
X
Against Calibration Data Change
X
X
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.