USD | INR

IoT Security Fundamentals—Part 1: Using Cryptography

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Editor’s Note: This multi-part series provides practical guidance to help developers ensure best practices are followed from the outset. Here, Part 1 discusses the cryptography algorithms underlying secure designs. Part 2 discusses the role of private keys, key management, and secure storage in secure systems. Part 3 examines the mechanisms built into secure processors to mitigate threats designed to subvert system and application software execution on IoT devices. Part 4 identifies and shows how to apply security mechanisms in advanced processors to help ensure the isolation needed to mitigate attacks on the runtime environment of IoT devices. Part 5 describes how IoT security continues from IoT devices through higher level security measures used to connect those devices to IoT cloud resources.

The rapidly growing reliance on IoT applications in industrial, medical, transportation, and other critical applications has dramatically altered the security landscape. Unlike earlier enterprise applications with readily available resources for processing security algorithms, enterprise-level IoT applications find themselves vulnerable to a growing array of threats that target expanding networks of resource-constrained IoT devices. In their rush to respond to rapidly emerging IoT opportunities, organizations too often deploy IoT devices functionally incapable of supporting basic security measures for protecting stored data and protecting the exchange of data and commands across vulnerable networks.

How far developers need to go to secure a design of course depends on multiple factors. Each application faces its own set of threats and requires an appropriate assessment of risks from those threats. Because connected devices face an uncommon number of threats, any IoT device will require at least some minimal security measures.

To some, implementing robust security measures for a simple IoT device might seem like a case of overengineering, but even simple temperature sensor devices that lack sufficient protection can provide hackers with a point of entry into corporate networks [1]. Indeed, IoT security faces constant challenges due to the combination of pervasive connectivity provided by IoT applications and the resource limited devices underlying these applications. In fact, even in IoT device designs with sufficient resources to run cryptography algorithms in software, applications can remain vulnerable due to subtle errors in implementation of those algorithms.

This article describes the basic classes of cryptography algorithms and explores their role in security. It then shows how developers can take advantage of processors and specialized devices—from Maxim Integrated, Microchip Technology, and Texas Instruments—that are designed to accelerate these algorithms, enhancing different aspects of security while simplifying its implementation.

The various types of cryptographic algorithms and their roles

Cryptography algorithms fall into three broad categories that address fundamental security principles of confidentiality, authentication (verify the source of the message), non-repudiation (prove that the sender created an encrypted or signed message), and integrity:

  • Symmetric key algorithms, where the algorithm or cipher, uses the same secret key to encrypt a human-readable (plaintext) message to a protected version (ciphertext), and later to decrypt the ciphertext back to plaintext. Symmetric key ciphers are typically used to ensure confidentiality. Common symmetric cryptography algorithms include:
    • Triple DES (Data Encryption Standard), also known as 3DES, or officially by the U.S. National Institute of Standards and Technology (NIST) as the Triple Data Encryption Algorithm (TDEA).
    • Advanced Encryption Standard (AES)[2] algorithms such as AES-256, which uses 256-bit keys.
  • Asymmetric key algorithms, where the cipher uses a paired set of private and public keys to encrypt and decrypt a message, typically as part of more extensive security protocols for key agreement and digital signatures. Asymmetric ciphers are typically used to ensure confidentiality, authentication, or non-repudiation. Public key cryptography algorithms include:
    • Algorithms using finite field cryptography (FFC), including:
      • Federal Information Processing Standard (FIPS) Digital Signature Algorithm (DSA)
      • Internet Engineering Task Force (IETF) Diffie-Hellman (DH)[3] key exchange
    • Algorithms using integer factorization cryptography (IFC), including:
      • RSA (Rivest–Shamir–Adleman)[4] algorithm
    • Algorithms using elliptic-curve cryptography (ECC), including:
      • Elliptic Curve Diffie-Hellman (ECDH)[5] key exchange
      • Elliptic Curve Digital Signature Algorithm (ECDSA)[6]
  • Hash algorithms, where the algorithm reduces an original message to a much smaller, unique fixed length value, variously called a hash, digest, or signature. These one-way conversion functions play a critical role in verifying that the message has not been altered (integrity) and find application in multiple protocols involving a message authentication code (MAC), keyed-hash message authentication code (HMAC), or key derivation functions (KDF), among others. Cryptographic hash algorithms include:
    • MD5 (message digest 5)
    • Secure Hash Algorithms (SHA)[7] such as SHA-256, which generates a 256-bit hash value for a message.

As with any effective crypto algorithm, the algorithms mentioned above are designed with multiple critical requirements that lie well beyond the scope of this brief article. From a broad perspective, however, key-based algorithms need to generate ciphertext that is virtually impossible (or at least economically unfeasible) to decrypt without the key. For their part, hash algorithms need to generate hashes quickly, producing the same hash for the same input message but generating a markedly different hash for even a slight change in the input message, while never producing the same hash value for two different messages, and never producing the original message given a particular hash value.

Although the details of these and other crypto algorithms differ widely, they all rely on a series of low-level manipulations, transformations, and other mathematical operations designed to meet these overall objectives. For example, the AES cipher converts plaintext to ciphertext using a series of "rounds" that incorporate unique "round keys" derived from the user's original secret key (Listing 1).

Copy
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)]) 
begin 
   byte  state[4,Nb]
 
  state = in
 
   AddRoundKey(state, w[0, Nb-1])
 
    for round = 1 step 1 to Nr–1
        SubBytes(state)
        ShiftRows(state)
        MixColumns(state)
        AddRoundKey(state, w[round*Nb, (round+1)*Nb-1]) 
    end for 
 
    SubBytes(state)
    ShiftRows(state)
    AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1]) 
 
    out = state
end

Listing 1: This pseudo code describes the sequences of operations involved in message encryption, converting plaintext (in) to ciphertext (out) using a set of values (w) derived from the sender's private key. (Code source: NIST)

Within a round, the SubBytes() transformation replaces each byte using a substitution table (S-box), which itself is the result of a series of transformations (Figure 1).

Diagram of SubBytes() stage replaces each byte using a substitution table (S-Box)Figure 1: In the AES cipher, the SubBytes() stage replaces each byte using a substitution table (S-Box). (Image source: NIST)

In the next step in the sequence, the ShiftRows() transformation shifts bytes in the last three rows, each by a different number of bytes (Figure 2).

Diagram of ShiftRows() stage in the AES cipher execution sequenceFigure 2: The ShiftRows() stage in the AES cipher execution sequence shifts rows by increasing offsets. (Image source: NIST)

In the final steps in the sequence, MixColumns() applies a transformation to each column that replaces each byte in the column with the results of a polynomial, while AddRoundKey() transforms the result by performing a bitwise XOR operation on each column using a round key created for that purpose.

The total number of rounds varies with key size. AES-128, which uses a 128-bit key, requires 10 rounds, while AES-192 (key size 192 bits) and AES-256 (256 bits) require 12 and 14 rounds, respectively. Decryption follows the same pattern, inverting the process steps and their separate transformations.

More recent ciphers like ECDH used for key exchange and ECDSA used for digital signatures rely on more complex mathematics such as the elliptic curve algebraic structures broadly defined by the formula:

Equation 1 Equation 1

With careful selection of curve parameters a and b and use of additional constraints, the curves exhibit useful cryptographic properties (again, beyond the scope of this article). Although simple in concept, the specific set of parameters is critical: Poor selection of curve parameters can result in curves that remain vulnerable to sophisticated attacks. To help eliminate this possibility, NIST provides a standard set of cryptographically robust curves including P-192, P-224, P-256, and others of increasing strength. The curve names correspond to the bit length of the prime number p of elements in the curve's underlying prime field.

A developer can use these properties with ECDSA to sign some message using an agreed upon curve and provide the recipient with the public key and the signature—a pair of numbers labeled r and s. The actual signing process involves the following steps:

  • Starting with some point on the curve, called the base point G(x,y), the algorithm creates a public key Q(x,y) by multiplying the base point by the developer's private key (d) modulo p:

Equation 2 Equation 2

  • Another coordinate point (x1,y1) is created using a random number k in the range [1 ... n-1]:

Equation 3 Equation 3

  • H(m), the SHA hash of message m, is generated
  • Using the modulo inverse of random number k, k-1, the final r and s components of the digital signature are generated as follows:

Equation 4 Equation 4

Equation 5 Equation 5

The end result is an exchange that authenticates the message, confirms its integrity, and ensures non-repudiation.

How to implement cryptography algorithms

The object lesson of this admittedly superficial look at these algorithms is that cryptographic algorithms rely on a sequence of mathematical operations designed to make attempts to compromise the results so computationally expensive that it is impossible—or impractical—to complete them fast enough to be useful to the perpetrator. In addition, even a cursory inspection of each algorithm suggests that a resource-constrained IoT device will likely have little chance of executing a software implementation of the algorithm without potentially compromising the device's primary functional requirements. Finally, the precise details of the algorithm beyond the steps shown here mean that even a subtle coding error or minor misinterpretation of the standard can result in security vulnerabilities, or even outright failure of the cryptographic process.

Errors in algorithm implementations can occur even in the largest development organizations, and in applications that critically depend on those algorithms. For example, a well-known vulnerability in a game console arose because the company-built implementation of ECDSA used a constant value of k, rather than a random value for the type of calculation shown in Equation 3. As a result, hackers could derive the secret key d. Use of a faulty random generator for creating k led to a similar exploit resulting in a major Bitcoin loss.

Hardware-based cryptography capabilities built into processors and dedicated security ICs let developers largely ignore the complex details of cryptography algorithm execution and focus instead on the benefits of using those capabilities to secure their applications. These devices add an extra layer of security by integrating the data flows and operations within the device, removing a common form of attack that monitors external buses for signs of privileged information. Besides providing a trusted implementation of a particular algorithm, a hardware-based solution allows developers to build security into designs without compromising fundamental requirements such as response latency and overall performance.

Crypto accelerators built into these devices offload cryptography execution from the main processor, freeing it to handle the design's primary function. In fact, hardware-based crypto support has become an increasingly common feature of processors. At the same time, not every application requires the full force of security measures supported by the algorithms described above. Indeed, developers can find a broad range of accelerated crypto algorithms and combinations of algorithms in processors such as the following:

  • Maxim Integrated's MAX32631 32-bit microcontroller, which supports AES and DSA ciphers
  • Maxim Integrated’s MAX32520 32-bit MCU, which supports AES, SHA, and ECDSA algorithms
  • Microchip Technology's PIC 24F XLP 16-bit microcontroller family members, where devices such as the PIC24FJ256GA406 support AES and 3DES ciphers
  • Microchip Technology's 32-bit PIC 32MZ MCU and 32-bit SAM9X60 MPU family members, where devices such as the PIC32MZ2048EFM144 and SAM9X60T support AES and 3DES ciphers as well as SHA and HMAC hash functions
  • Texas Instruments' SimpleLink MCU family members such as the CC1312R and CC2652R wireless MCUs, which support AES, ECDH, and ECDSA ciphers as well as SHA hash functions

Other security devices such as the Maxim Integrated DS28E38 and Microchip Technology ATECC608A integrate crypto accelerators and related functionality needed to speed authentication protocols. Among their broad crypto capabilities, these devices support the kind of ECDSA operation described earlier. In an IoT device or smart peripheral, a host processor can use authentication ICs such as these to quickly create ECDSA P-256 digital signatures to send to another device or authenticate the ECDSA P-256 signatures from other devices.

Security-enabled processors and specialized devices are typically built with a broad hardware-based security framework that provides additional security functionality such as high quality random number generators. Many devices that provide this level of capability take advantage of random noise sources inherent in semiconductor designs to maximize the entropy needed in true random number generators (TRNGs). As suggested in the Bitcoin example mentioned earlier, these kinds TRNGs are an essential factor in the proper operation of cryptographic algorithms.

Integrated support for secure storage of private keys and other secret data provide one of the most important capabilities of secure designs. Other architectural features available with these and similar processors provide an even deeper level of security support.

For all their capabilities, processors with integrated crypto accelerators and related features help simplify development of secure designs through use of straightforward application programming interface (API) libraries. Intuitive API function calls let developers abstract security implementations, relying on the API to access the underlying hardware functionality. For example, developers can use the Maxim Integrated MAX32520-KIT evaluation kit for the MAX32520 MCU in combination with the Maxim Integrated Micros software development kit (SDK) to rapidly build secure IoT devices. Along with associated drivers and middleware, the Maxim Integrated Micros SDK includes sample functions that demonstrate the basic design patterns required to encrypt (AES128_ECB_enc()) and decrypt (AES128_ECB_dec ()) messages using the AES cipher (Listing 2).

Copy
int AES128_ECB_enc(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "00000000000000000000000000000000";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_EncryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Encrypt(&cipher_req);
    }
    const char *_expected = "322FD6E503395CDB89A77AC53D2B954F";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
 
}
 
int AES128_ECB_dec(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "322FD6E503395CDB89A77AC53D2B954F";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_DecryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Decrypt(&cipher_req);
    }
    const char *_expected = "00000000000000000000000000000000";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
}

Listing 2: Developers can inspect sample code in the Maxim Integrated Micros SDK distribution package to learn basic design patterns needed to perform AES encryption (AES128_ECB_enc()) and decryption (AES128_ECB_dec ()) using the MAX32520 MCU's integrated cryptography functions. (Code source: Maxim Integrated)

Authentication protocols

Robust cryptography algorithm implementations are particularly critical for providing a secure foundation for higher level protocols used in applications. Higher level protocols such as Transport Layer Security (TLS) typically perform their operations using a defined set of cryptographic algorithms, called a cipher suite. In TLS, algorithms drawn from an agreed upon cipher suite help ensure authentication and confidentiality in communication sessions between an IoT device client and host server. TLS 1.2[8] proceeds through a specific sequence of transactions to negotiate parameters, perform authentication, and exchange session keys before proceeding to data exchange (Figure 3).

Diagram of TLS 1.2 session creation protocolFigure 3: The TLS 1.2 session creation protocol uses a variety of algorithms from an agreed upon cipher suite for authentication, key exchange, and ongoing data exchange. (Image source: Texas Instruments)

Authentication is ensured by establishing the identity of the server (and optionally the client) by verification of security certificates, which contain the respective public key for each participant. Here, each participant sends a message encrypted with its private key. Because the received public key can only decrypt a message encrypted with its associated private key, each participant can confirm that the provider of a certificate actually owns that certificate.

In the next TLS stage, the participants execute a series of transactions to create a shared session key. This shared session key is then used to encrypt the actual message traffic, ensuring the confidentiality of message exchanges for that session.

Multiple protocol options allow developers to refine this generic TLS session creation process, sometimes to the detriment of overall security. In addition, during the parameter exchange process, developers can use a different cipher suite by selecting a suitable combination of TLS 1.2 supported algorithms for each phase of the protocol, including:

  • Key establishment: RSA, DH, ECDH
  • Authentication: RSA, DSA, ECDSA
  • Ciphers: 3DES, AES
  • Message authentication: SHA

The latest version of TLS, TLS 1.3[9], adds additional security by performing key exchange first to better protect the session creation process. More fundamentally, TLS 1.3 largely disposes of the TLS 1.2 cipher suite in favor of more robust algorithms including use of the HMAC-based extract-and-expand Key Derivation Function (HKDF), and authenticated encryption with associated data (AEAD) algorithms. AEAD algorithms address the broad need for ensuring message authenticity, integrity, and confidentiality. These algorithms do so by combining the encrypted message with a MAC that can be generated in series (Figure 4, left), in parallel (Figure 4, right), or in some combination of the two.

Diagram of AEAD provides authentication and confidentialityFigure 4: AEAD provides authentication and confidentiality by including a MAC with the ciphertext using, among other techniques, methods called encrypt-then-MAC (left) and encrypt-and-MAC (right) that compute the MAC in series or in parallel, respectively. (Image source: Wikipedia)

Increasing security strength

This evolution of cryptography algorithms and associated protocols tracks the continuing race between cryptography experts determined to strengthen security and those equally determined to defeat it. For example, in an effort to enhance security, experts created ECDSA as an ECC variant of DSA, itself a variant of earlier ciphers. The result is that ECDSA can achieve the same security strength as DSA but with a much smaller key size.

In cryptography, algorithm security strength is defined in terms of x bits and the expectation that an attack would require about 2x operations to derive the private key underlying the algorithm. Defined in these terms, the different classes of algorithms can require significantly different key lengths to achieve comparable levels of security (Table 1).

Table of different classes of cryptography algorithmsTable 1: Different classes of cryptography algorithms can require significantly different key sizes for the public keys (L) or private keys (N, k, f) to achieve comparable levels of security strength. (Image source: NIST)

In this table from NIST, the FFC algorithm parameters L and N correspond to the sizes of the public key and private key, respectively. For IFC and ECC algorithms, k and f, respectively, correspond to the the key size. NIST notes that algorithms with security strength £80 (orange background in the table) are no longer approved for government information protection, while others (yellow background) are not yet included in NIST standards due to efficiency concerns.

This move to higher security strength continues to drive the evolution in ciphers and recommended cipher suites. For example, the U.S. National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite displaced the earlier NSA Suite B with recommendations for use of more robust parameters needed to protect information classified as top secret (Table 2).

Table of cryptography algorithms with recommendations for minimum levels of security strengthTable 2: The NSA recommended CNSA Suite includes cryptography algorithms with recommendations for minimum levels of security strength required to protect highly sensitive information. (Image source: Digi-Key, from NSA data)

Looking ahead, the availability of quantum computing capabilities will present a dramatic discontinuity in security in general, and cryptography algorithms in particular.

Conclusion

IoT devices and other connected designs face a growing number of threats that require increasingly robust security methods based on a wide range of cryptography algorithms. Designed to make cracking security an impractical proposition, these algorithms rely on a series of transformations and mathematical operations to encrypt plaintext to ciphertext and decrypt ciphertext back to plaintext. As shown, it’s possible to use hardware-based implementations of these algorithms to let developers more easily build strong security into a design without compromising its primary requirements for functionality and performance.

References:

  1. How a fish tank helped hack a casino
  2. FIPS PUB 197: the official AES standard
  3. IETF RFC 3526 (DH)
  4. NIST SP 800-56B Rev. 1 (DOI) (RSA)
  5. NIST SP 800-56A (ECDH)
  6. FIPS Pub 186-4 (digital signature)
  7. FIPS PUB 180-4: Secure Hash Standard (SHS)
  8. IETF RFC 5246 (TLS 1.2)
  9. IETF RFC 8446 (TLS 1.3)

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors