# Cryptography ## Introduction to Cryptography This section summarizes a training webinar from WolfSSL. The session is led by Chris Conlon, engineering manager at WolfSSL.  ## Historical Context and Classical Ciphers WolfSSL’s training begins with a discussion of insecure classical ciphers to demonstrate the evolution of cryptographic thinking: - **Caesar Cipher**: Shifts each letter of the message by three positions in the alphabet. Easily broken. - **Vigenère Cipher**: Uses a repeating key to shift letters, offering slightly more security. - **One-Time Pad**: Theoretically unbreakable when the key is truly random, as long as the message, and never reused. ### Caesar Cipher Example ``` Plaintext: A B C D E F G Ciphertext: D E F G H I J ``` ## Cryptographic Terminology Several acronyms and key concepts are defined to help participants navigate cryptographic literature and tooling: - **SSL**: Secure Socket Layer - **TLS**: Transport Layer Security (replacement for SSL) - **DTLS**: Datagram TLS for unreliable transport - **CRL**: Certificate Revocation List - **OCSP**: Online Certificate Status Protocol - **DH**: Diffie-Hellman key exchange - **ECC**: Elliptic Curve Cryptography - **AES/DES**: Symmetric ciphers - **FIPS**: Federal Information Processing Standards - **PKCS**: Public Key Cryptography Standards - **MAC**: Message Authentication Code ## Categories of Cryptographic Algorithms ### Symmetric Cryptography Symmetric encryption uses the same key for encryption and decryption. Common symmetric block ciphers include: - AES - Triple DES - CAST Symmetric encryption is faster and efficient for large datasets. ### Asymmetric Cryptography Asymmetric systems use a public/private key pair. Examples: - **RSA** (first public-key system, still widely used) - **ECC** (more efficient, smaller key sizes) - **ECDSA, ECDH, ECIES**: Signature, key exchange, encryption, respectively ### Asymmetric Key Exchange ``` [Client] ---> Public Key ---> [Server] [Client] <--- Encrypted Data <--- [Server using Private Key] ``` ### Hash Functions Used for integrity checking and digital signatures. Examples: - SHA-1, SHA-2 (256, 384, 512), SHA-3 - MD5 (obsolete) ## Hash Functions and Message Authentication ### Hash Functions Good hash functions are: - Collision-resistant - Produce fixed-size digests - Sensitive to even one-bit changes ### SHA-1 Digest Comparison ``` Input: "a" -> SHA-1: 86f7e437...f00 Input: "b" -> SHA-1: da23614e...f67 ``` ### HMAC & CMAC - **HMAC**: Uses a hash function with a secret key (e.g., HMAC-SHA256) - **CMAC**: Uses a symmetric block cipher (e.g., AES-CMAC) ### Poly1305 A high-speed MAC optimized for modern CPUs, though not standardized under FIPS yet. ## Block and Stream Ciphers ### Block Ciphers Operate on fixed-length data blocks. - **ECB**: No chaining. Leaks plaintext patterns. - **CBC**: Uses IV and chaining. Safer than ECB. - **CTR**: Encrypts counter values, then XORs with plaintext. ### ECB vs CBC (Penguin Image Reference) ``` [Image Left] Original [Image Mid] Encrypted w/ ECB (patterns visible) [Image Right] Encrypted w/ CBC (randomized) ``` ### Stream Ciphers Encrypts byte-by-byte using a key and nonce. - Faster than block ciphers - Examples: RC4, ChaCha20 ## Authenticated Encryption and AEAD AEAD combines encryption and authentication. - Output: Ciphertext + Authentication Tag - Input: Plaintext, Key, Optional Associated Data (AAD) ### AEAD Algorithms - AES-GCM - AES-CCM - ChaCha20-Poly1305 ### AEAD Flow ``` [Plaintext + AAD + Key] --> AEAD --> [Ciphertext + Tag] ``` AEAD is essential for protocols like TLS 1.3 where header fields remain visible (e.g., IP routing) but need authentication. ## Asymmetric Cryptography and Key Exchange ### RSA - Oldest public key encryption - Still in widespread use - Used for both encryption and signing ### ECC - Introduced in 1985 - Uses algebraic curves over finite fields - Smaller keys, faster operations ### Key Exchange - **Diffie-Hellman**: Establishes shared secret - **ECDH**: Elliptic curve variant ### Paint Mixing Analogy (From Slides) ``` Alice + Yellow = Orange Bob + Blue = Green Exchange & Mix = Shared Secret = Brown ``` ## Random Number Generation and Entropy ### Why Randomness Matters All cryptographic security ultimately depends on good entropy. Bad RNG = weak keys, predictable sessions. ### RNG Types - **TRNG**: Hardware-based, physical entropy - **PRNG**: Algorithmic, requires good seeding - **DRBG**: NIST standard PRNGs (e.g., Hash-DRBG) ### Good RNG Sources vs. Bad Ones ``` ✅ /dev/random ✅ Hardware RNG (TPM) ❌ MAC address ❌ System clock ``` ## Secure Key Storage and Device Security ### Key Storage Options - Embedded in firmware (not recommended) - Transferred from secure server - Generated on device (recommended) ### Best Practices - Use different keys for different roles - Use secure enclaves or TPM - Keys should rotate regularly ### Key Lifecycle on Device ``` [Key Gen] -> [Secure Storage] -> [Session Use] -> [Expire/Rotate] ``` # Security No discussion about systems that carry computers would be complete without discussing security aspects. If digital systems are about data interfaces sending bits back and forth, their storage, and processing, an important aspect would be to ensure all this is done securely. Note that I didn't use the term "cybersecurity", but "security" to title this section. There are multiple terms used when it comes to discussing security around digital systems like the aforementioned cybersecurity, but also infosec and others. The terms "cybersecurity" and "information security" (infosec) are often used interchangeably, but they have slightly different focuses within the broader field of protecting digital and non-digital information. Cybersecurity primarily deals with protecting electronic information from unauthorized access, attack, or damage. It focuses on defending computer systems, networks, and data from cyber attacks, including hacking, phishing, malware, and ransomware. The scope is generally broader, encompassing not just the protection of data but also the systems and networks that store and transmit this data. It includes securing internet-connected systems, including hardware, software, and data, from cyber threats. The main objective is to ensure the confidentiality, integrity, and availability of data in the cyber domain, protecting against attacks that could disrupt or disable digital operations, steal or manipulate data, and compromise digital privacy. Information security, on the other hand, is a broader term that encompasses the processes and methodologies designed to protect any form of confidential, private, and sensitive information or data, whether it's in digital, paper, or other forms, from unauthorized access, use, disclosure, disruption, modification, inspection, recording, or destruction. Infosec covers a wider range of data protection aspects, including physical security measures and operational security processes, in addition to cybersecurity measures. It's concerned with the privacy, integrity, and availability of data regardless of the form the data may take. The main goal of infosec is to protect information assets against the risks of loss, misuse, disclosure, and damage, including implementing policies, procedures, and controls to ensure data is used properly and kept secure across its entire lifecycle, from creation through disposal. While cybersecurity is a subset of information security focused specifically on the digital or cyber aspect of protection, information security is a broader field that includes cybersecurity as one of its elements. Infosec is concerned with protecting information in all forms, not just digital, and includes a wider range of controls and measures to ensure data security. The systems we are discussing in this text require both, cybersec and infosec, and thus I will use the overarching _security_ term that encompasses the two. Security must be added by design. It cannot be an afterthought; ==a system that has not been conceived with security measures cannot be made secure once deployed==. Moreover, any approach to creating secure systems needs to understand that security must grow aware of the system's hierarchy: there must be security measures at every hierarchical level: at system level, unit level, board level, and chip level. And, of course, it must be added to the interfaces that couple the system together. > [!Storytime] > Twenty years ago, I was an all-rounder in a small, family-owned tech company in Buenos Aires. One of this company's business units was payphones (feel old yet?). Back in the day, payphones would carry quite a lot of money in their boxes. During the time I worked at that company, I learned about all the intricate attacks for gaining access to the box, but one in particular caught my attention due to its originality. It involved sticking a condom through the coin slot, and inflating the condom until it popped inside the pay phone housing. The popped condom would get entangled with some cables inside the phone case, including the cables that controlled the relay that opened the safe for the servicing and collecting operator. The attacker would pull the remains of the condom out, bringing with it the cables out of the case. Then, the perpetrator would selectively cut the proper wires (this made me think the attacker probably had good knowledge about the phone internals) and use a small battery to actuate the relay, gaining unrestricted access to a box full of shiny coins. > Speaking of coins, while working there I also learned a lot about coin fraud; basically how to fool the phone into taking small coins as bigger coins. The coin detector was based on a combination of material detection and diameter measurement. The material detection process consisted of having the coin pass through the center of a tuned LC circuit. Then coins would briefly become part of the circuit while passing, modifying the properties of the LC circuit; then, the voltage drop in the envelope of the LC oscillator would be measured by a microprocessor and the processor would compare the signature of each coin to gauge the material. The final check was the coin diameter measurement by clocking the time the coin would take to block two optocouplers as the coin was falling. One not-so-elegant hack back in the day was to hammer a .25 pesos coin (which was the same material as a .5 coin) to make it bigger and make it pass as a 0.5. That one was tricky to detect; for the system as designed, there was no way of telling from an artificially-expanded 0.25 coin for a .5 coin. As the story above describes, systems may suffer from attacks way beyond the "cyber" space. Physical security is as a big concern for digital systems as cybersecurity is. An attacker having physical access to a system can obtain invaluable information about it. If the attacker combines physical access with insider knowledge, the system will peak in vulnerability. > [!important] Here's a presentation from 2021 where I speak about radio links, security and satellites: > > > > And a panel where I discussed the combo of NewSpace approach and cybersecurity: > > ## Keys Related to my story about people hacking payphones, an important principle on this matter is Kerckhoffs' principle. Kerckhoffs' principle, named after the Dutch cryptographer Auguste Kerckhoffs, is a concept in cryptography that emphasizes the importance of designing cryptographic systems with the assumption that the details of the system, except for the key, are known to the adversary. In other words, a cryptosystem should remain secure even if all details about the system are public knowledge, except for the secret key. Kerckhoffs' principle is often summarized as follows: > [!quote] _"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge"._ This principle underlines the idea that the security of a cryptographic system should rely primarily on the secrecy of the cryptographic keys rather than on the secrecy of the algorithm or system details. The rationale behind Kerckhoffs' principle is to ensure that a cryptographic system remains secure even if it falls into the hands of adversaries, who may have full knowledge of its design and implementation details. By focusing on the security of the keys, cryptographers can create systems that are robust and resistant to various attacks, including those based on knowledge of the system's internal mechanisms. In cryptographic theory, there are two general types of keys, symmetric keys and public (or asymmetric) keys. Symmetric encryption (also called private-key encryption) uses the same key for both encryption and decryption. This means that both the sender and the receiver need to have the same key. Here's a simple Python example using symmetric encryption (specifically, using the Caesar Cipher, which is a basic example of symmetric encryption): ```Python def caesar_encrypt(text, key): result = "" for char in text: if char.isalpha(): shift = ord('a') if char.islower() else ord('A') result += chr((ord(char) - shift + key) % 26 + shift) else: result += char return result def caesar_decrypt(text, key): return caesar_encrypt(text, -key) # Example text plaintext = "Hello, World!" # Encrypt the plaintext key = 3 ciphertext = caesar_encrypt(plaintext, key) print("Encrypted text:", ciphertext) # Decrypt the ciphertext decrypted_text = caesar_decrypt(ciphertext, key) print("Decrypted text:", decrypted_text) ``` This code defines two functions `caesar_encrypt` and `caesar_decrypt`, which perform encryption and decryption using the Caesar Cipher, respectively. We then encrypt the example text "Hello, World!" with a key of 3 and decrypt it back. The output is: ```Shell Encrypted text: Khoor, Zruog! Decrypted text: Hello, World! ``` Another type of encryption is asymmetric encryption. Asymmetric encryption uses two different keys—a public key and a private key. The public key is used for encryption, while the private key is used for decryption. This enables secure communication without needing to share a secret key. As the names suggest, one of these keys is intended to be private, and the other is intended to be shared with everyone. There’s a special mathematical relationship between these keys that enables some useful features. If you encrypt data using someone’s public key, only their corresponding private key can decrypt it. On the other hand, if data is encrypted with the private key anyone can use the public key to unlock the message. The latter operation doesn’t provide confidentiality, but it does function as a digital signature. ==Despite its interesting properties, public-key cryptography is rather slow and unsuitable for use with large quantities of data. For this reason, it’s usually deployed for authentication and negotiation of private keys, which are then used for fast symmetric encryption.== Below is an example of asymmetric encryption using RSA in Python: ```Python from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_OAEP import time # Generate key pair key = RSA.generate(2048) # Example text plaintext = "Hello, World!" # Encryption using public key start_time = time.time() cipher_rsa = PKCS1_OAEP.new(key.publickey()) ciphertext = cipher_rsa.encrypt(plaintext.encode()) end_time = time.time() print("Encrypted text:", ciphertext) print("Encryption time:", end_time - start_time, "seconds") # Decryption using private key start_time = time.time() cipher_rsa = PKCS1_OAEP.new(key) decrypted_text = cipher_rsa.decrypt(ciphertext).decode() end_time = time.time() print("Decrypted text:", decrypted_text) print("Decryption time:", end_time - start_time, "seconds") ``` This code generates an RSA key pair, encrypts the plaintext using the public key, and then decrypts it using the private key, measuring the time both for encryption and decryption. The code outputs the following: ```Shell Encrypted text: b'Y\xd0,\xad\xb8\x90y\x14\xdd\xaa\xba\xd8\xe1\xad\x08\xd2\x1b\x0c\x97\xb1\xfd\xd5PF\x9a\x8e\xd4\xc9.t\x917\xbe\xf7\xbb\xaa\xe9\xa4B\xaai\xab\xcc\xec\xcd\x9e)\xe0\xf3\xdc\x9aSh\x03\x15\xb3P\xed\xc1\xedj\xad"U6\x98q\xc18\xcb\t\xf7\x02\x07\xd7\r\xb8\xedd\xed\x11\xcb\xcc\xb1[\xf2\xd2F\xdb\xa2>D\xec\xa5-6\xee\xef|\xa7V\xa1\xe9\x95\xfe\x8f\xe7"`\x97\xa5\n\xcf\x07\xe1P\x03\x19i^\x8e\x13wN@\x93*\xf0&m\x06^\xa5\x07\xbd\xe4\xb1\xe9\xd8]\xf0\x02D\x1d \x07\'\xa1\xae\xc5\xc2\x19\xd6B\xa7\xb4T\xfa{d]\xd9\xc5\xe0\x13\xcc\xd9\xd6Z\x1a\xb5W\xb2\xf8\xe1\x9e\n\xdc&v\r\x94\xfa\x11\xf65\x91\xa5\x99\x84\xa9}\x19&\x96\xb8PK\x15\xe6\x99q\x1de\x1d\x99\xc1J\xc7\x91\xc4U{\x13\xf0\xb5n\xd6\x83\xb1\x89\xb6\xd2\xb3A\x83\x05\x91j\xae\xddNiK\xb8\xb5n\x88%$\xa7\x8a\xc9+\xe8\xbf"\xb8\xe6\xcb\xdd\x12\xc7\x04}-' Encryption time: 0.0006682872772216797 seconds Decrypted text: Hello, World! Decryption time: 0.0014500617980957031 seconds ``` > [!Storytime] > Around the year 2008, I was working in a company that made access controls. Back in the day, ATMs in Argentina would be always placed behind a glass door, with the door being equipped with a magstripe reader. Customers were supposed to swipe their bank cards in the magstripe reader at the door to get to draw money in the ATM. The company I was working for had sold magstripe readers for practically every single ATM in the city of Buenos Aires. One day, a customer bank employee brought a reader that was not working and said reader landed on my desk. Upon closer inspection, I saw the reader had been tampered with and its control electronics had been replaced with a tiny, crappy-looking PCB that had an 8-pin Microchip microcontroller, a USB port, a real-time clock, and a small, serial flash memory (an AT45DB041D from Atmel). I unsoldered the memory and put it in a breadboard with a microcontroller of mine and read the content through its [[Physical Layer#SPI|SPI]] interface. It was full of credit card data with timestamps (ok, the attacker did not have the PIN code but I bet that was tried with some other scheme, for instance using a camera or by just looking). Two lessons I learned that day from doing forensics with that tampered reader: that it doesn't take high-quality electronics to create malicious hardware to steal data, and that banks were in fact never validating the magstripe data to open the ATM door. From that day on, I started using any magstripe card instead of my bank card for opening ATM doors, for instance, the metro card. A good encryption algorithm produces seemingly random ciphertext, which can’t be analyzed by the attacker to reveal any information about plaintext. For example, the substitution cipher is not a good algorithm, because the attacker could determine the frequency of each letter of ciphertext and compare it with the frequency of the letters in the English language. Because some letters appear more often than others, the attacker could use his observations to recover the plaintext. If a cipher is good, the only option for the attacker should be to try all possible decryption keys, otherwise known as an exhaustive key search. At this point, the security of ciphertext depends entirely on the key. If the key is selected from a large keyspace and the breaking encryption requires iterating through a prohibitively large number of possible keys, then we say that a cipher is _computationally_ secure. ### On Randomness (and Lava Lamps) Keys can be generally obtained from sources of randomness within the system itself or through computations performed on these sources of randomness. Alternatively, keys can be obtained from cryptographically secure pseudorandom number generators executed by circuitry or software running on the system. System information, such as status registers, system clock, interrupt vectors, date, time, etc., is often used as a seed for the cryptographic pseudorandom number generators. Each new key that a computer uses to encrypt data must be truly random so that an attacker won't be able to figure out the key and decrypt the data. However, computers are designed to provide predictable, logical outputs based on a given input. They aren't designed to produce the random data needed for creating unpredictable encryption keys. To produce the unpredictable, chaotic data necessary for strong encryption, a computer must have a source of random data. The "real world" turns out to be a great source of randomness, because events in the physical world are unpredictable. One somewhat eccentric example of randomness is lava lamps. As one might expect, lava lamps are consistently random. The "lava" in a lava lamp never takes the same shape twice, and as a result, observing a group of lava lamps is a great source of random data.  Reportedly, the company Cloudflare has arranged about 100 lava lamps on one of the walls in the lobby of the Cloudflare headquarters and mounted a camera pointing at the lamps. The camera takes photos of the lamps at regular intervals and sends the images to Cloudflare servers. All digital images are stored by computers as a series of numbers, with each pixel having its own numerical value, and so each image becomes a string of totally random numbers that the Cloudflare servers can then use as a starting point for creating secure encryption keys. ## Embedded Systems Security Known for their humble resources, security has historically not been the topmost priority while designing small, cost-effective computerized systems. The main issue with this is the inescapable trade-off between cost-effectiveness, computing resources, and security. Embedding security into devices is not a straightforward process. First, the type of security functionality to embed into the device must be determined. This is often a challenge since specifying security requirements largely depends upon attack or threat models, which may not be fully known at the time. Designers must also ensure that their implementations are secure since this is typically the focus of attacks. Unlike other embedded constraints such as energy, performance, and cost, which can be verified and quantified, the verification of security is often not straightforward (apart from functionality). In general, the security cannot be quantified nor can it be readily verified due to the possibility of unforeseen future attacks. From a security point of view, a complete understanding of the device from the process level and up is necessary to verify that the security and its implementation are sound. Embedded systems are conceived very differently from those systems generally thought of as general-purpose CPUs. General-purpose CPUs are generally designed for high performance supporting full programmability and supporting a wide range of workloads and applications. In contrast, embedded systems generally utilize processors and/or devices embedded in specific systems that are highly constrained. Embedded devices may be constrained by cost, memory, energy, clock frequency, word size, mass, volume, etc. Typically these embedded devices are a part of our everyday life (automobiles, entertainment systems, etc). The networking of these embedded devices has led to a new emerging topic of great interest known as the Internet-of-Things (previously called pervasive or ubiquitous computing). Security is an important requirement for these embedded devices. There are many reports of attacks on various systems including automobiles, IoT, etc. A few are listed below. ### Automotive There were some significant, high-profile examples of vulnerabilities in cars: 1. **Jeep Cherokee Hack (2015)**: One of the most notable car hacking incidents involved a Jeep Cherokee in 2015. Security researchers Charlie Miller and Chris Valasek demonstrated how they could remotely take control of the vehicle's systems, including steering, brakes, and transmission, through vulnerabilities in its Uconnect infotainment system. This incident prompted a large-scale recall by Fiat Chrysler Automobiles and led to increased awareness about the cybersecurity risks in connected vehicles. 2. **Tesla Model S Hack (2016)**: Researchers from Tencent's Keen Security Lab demonstrated vulnerabilities in the Tesla Model S that allowed them to remotely control various functions of the car, including the brakes, door locks, and dashboard touchscreen. Tesla quickly addressed the vulnerabilities through over-the-air updates, highlighting the importance of timely software patches in mitigating cybersecurity risks. 3. **Nissan Leaf Vulnerability (2016)**: Security researcher Troy Hunt discovered a vulnerability in the Nissan Leaf's companion app that allowed attackers to remotely control certain features of the vehicle, such as turning on the climate control system. The vulnerability stemmed from insufficient authentication mechanisms in the app, which Nissan subsequently patched. 4. **Fiat Chrysler Recall (2019)**: Fiat Chrysler Automobiles issued a recall for 1.4 million vehicles after researchers identified vulnerabilities in the company's connected vehicle systems. The vulnerabilities could potentially allow attackers to gain remote control of the vehicles' systems, highlighting the ongoing challenges in securing modern automobiles against cyber threats. 5. **Tesla Key Fob Cloning (2019)**: Researchers demonstrated how they could clone the key fobs of Tesla Model S vehicles by intercepting and amplifying the key fob's signals. This could potentially allow thieves to unlock and steal the vehicles without the owners' knowledge. Tesla addressed the issue by implementing stronger encryption methods in its key fobs. ### Internet-of-Things The Internet of Things (IoT) encompasses a wide range of devices connected to the Internet, including smart home appliances, wearable devices, industrial sensors, and more. There have been some notable examples of successful and documented IoT hacks: 1. **Mirai Botnet (2016)**: The Mirai botnet gained notoriety for launching massive distributed denial-of-service (DDoS) attacks by exploiting vulnerable IoT devices, such as routers, IP cameras, and DVRs. The botnet infected hundreds of thousands of devices worldwide, including prominent websites and services like Twitter, Netflix, and GitHub, causing widespread disruption. 2. **Vulnerabilities in Smart Home Devices**: Security researchers have identified numerous vulnerabilities in smart home devices, including smart locks, thermostats, cameras, and voice assistants. These vulnerabilities range from weak authentication mechanisms and insecure communication protocols to lack of firmware updates, exposing users to risks such as unauthorized access, data breaches, and physical intrusions. 3. **St. Jude Medical Pacemaker Vulnerability (2017)**: Researchers discovered vulnerabilities in certain models of St. Jude Medical's implantable cardiac devices, including pacemakers and defibrillators, which could potentially allow attackers to remotely control the devices and deliver inappropriate shocks to patients. St. Jude Medical issued firmware updates to mitigate the vulnerabilities and enhance device security. 4. **Ransomware Targeting IoT Devices**: Cybercriminals have increasingly targeted IoT devices with ransomware attacks, encrypting data or disrupting device functionality until a ransom is paid. In some cases, IoT devices like network-attached storage (NAS) devices, smart TVs, and even coffee makers have been affected, highlighting the diverse range of targets for ransomware attacks. 5. **Industrial IoT (IIoT) Security Concerns**: The convergence of operational technology (OT) with IoT in industrial settings has raised significant cybersecurity concerns. Attacks targeting IIoT devices and industrial control systems (ICS) can have serious consequences, including production downtime, safety risks, and environmental damage. Notable incidents include the Triton malware attack on a petrochemical plant in 2017, which targeted safety instrumented systems (SIS). 6. **Security Camera Breaches**: Numerous incidents have been reported where attackers gained unauthorized access to IoT security cameras, allowing them to spy on users, their homes, or businesses. Weak or default passwords, insecure configurations, and unpatched vulnerabilities have been common vectors for such breaches. Often embedded devices are complex and contain proprietary IP. Attackers have to gain as much information as possible concerning the system under attack. This includes sources of information such as company patents, errata, schematics, white papers, blogs, etc. Equipment supporting attacks include probes, ROM readers, logic analyzers, scopes, disassemblers, etc. ### Types of Attacks Although there is no universal taxonomy of attacks for embedded systems, there have been some classifications for attacks. However, the definition of attack terminology does vary. For example, some define an invasive attack to mean physically tampering with the device or decapsulating chips while others refer to opening up the device or injecting faults into the device without damaging the device, etc. Some general attack definitions are provided below. - Probing attack or penetration attack: these attacks are generally active and invasive. The attacker typically breaks into the boundary of the device, intercepts communication lines, or dumps memory contents from the device. The attack focuses on the bus structures of the embedded system. Typically accessible buses are probed so that data can be made observable as well as possibly controllable. Most often these are busses on the PCB, which are visible or that pass through pins that are accessible. An example of this is the attack on the Xbox, also known as a boot attack, where bus probing on the PCB allowed the attacker to obtain the secret key used to authenticate applications. Attacks sometimes include on-chip buses as well. For example, decapsulating the chip and placing tiny probes on the silicon is a concern in high-security devices such as credit cards based on smart card or chip card technology. The concern here is that an attacker can obtain sufficient information from probing the internals of chips and then clone many smartcards with this information - Monitoring attack: These are passive and noninvasive attacks. The side channel is an example of this type of attack. This attack is often referred to as a “lunchtime attack”. For example, attackers can temporarily take a credit card to charge the lunch meal to it but additionally run the attack on the card and return the card to the owner who is unaware that their secrets have been stolen. If an attacker is well-versed in attacking cards, it would only take minutes to acquire the traces for later analysis. The attacker can now clone credit cards and thus steal money from the owner. This is not only a concern for these chip cards but many other embedded systems including PDAs, cellphones, and even automobiles. For example, an attacker may be able to rent a car, extract the secret key from the remote keyless entry device, and later return to steal the car. - Manipulation attack: This attack is also noninvasive, and the device boundary is left intact. However, the attacker can change the temperature, supply voltage, clock, etc. For example, spiking the supply voltage may inject faults into the device. These faults may be an injection of zeros, which would cause the cryptographic algorithm to reveal the key. Alternatively, this type of attack may also be used in conjunction with the monitoring attack, for example, providing important boosting of signals so that a side-channel attack is easier to perform. - Substitution attack: In this attack, the module is removed and replaced with an emulating device. For example, a module that communicates with a crypto unit may be replaced by a malicious device that succeeds in obtaining a sufficient number of plaintext, and ciphertext pairs to mount an attack to obtain the secret key. Another example here is replacing chips in automobiles with modchips, which provide higher levels of performance typically only available to more expensive car models. There are also modchips for gaming consoles, which reportedly bypass the authentication allowing users to play unauthenticated programs on their stations. Additional attack terminology is outlined below. - Replay attack: is an attack where data sent to and from the device is recorded and used later in time. This replay attack can be done to impersonate another authentic user or authentic device. - Modification attack: this is an active invasive attack supporting the modification of internal connections or memory. The software version of a modchip is an example of this. - Spoofing attack: replaces part of the message with their own data. - Splicing attack: allows the attacker to permute data from the original message, so the device receives the permuted data. The next section will examine some different embedded systems outlining some possible attacks and security requirements. - Pervasive Monitoring: Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artifacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing, or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise. ### Side-Channel Analysis ==All systems that carry electronic devices leak information about themselves.== This information can take different forms, and attackers might be interested in unpacking this information to gain insight into the system. Side channel analysis (SCA) refers to the use of any information unintentionally leaked from a device as it works, and in particular while cryptographic computations are performed. Unintentional information leakage could be in the form of timing information, acoustics, radiated electromagnetic energy (EM), power consumption, etc. The most well-known are timing, EM, and power. However, there has been work on the acoustic side channel, optics (where light emitting diodes (LEDs) have indicated serial data being transmitted, etc), thermal, etc. Although all electronic devices radiate electromagnetic energy, it was not known whether information in the waves radiating from a complex device could be used to determine the secret key of a cryptographic computation. The understanding of the side channel is directly linked to how integrated circuits work, and in particular how [[Semiconductors#MOSFETs|MOSFET]] transistors work. One of the simplest types of logic circuits is the [[Semiconductors#MOS inverter|inverter]].  > [!Figure] > _CMOS inverter_ One can represent the instantaneous power consumption for this circuit based on its current state, $i$, and its next state, $j$ , as $P_{ij}$. The state is represented by the output voltage of the inverter. For example, $P_{00}$ represents the condition where a zero value is output from the inverter (e.g., the input is a 1). The term $P_{01}$ represents the condition where the output of the inverter makes a transition from a zero value to a one value. The switching at the output of an inverter from 1 to 0 is represented by $P_{10}$. The basis of the side channel attack is: If we subtract the instantaneous power consumption of the inverter when it is switching from zero to one, from the instantaneous power consumption of it switching from one to zero, we would get a difference, or power spike, which is greater relatively speaking than the power consumed in the inverter when no switching is taking place. The dynamic power consumption in a MOSFET inverter can be divided into switching power and short-circuit power. The total dynamic power consumption $P_{\text{dynamic}}$ can be expressed as the sum of these two components: $\large P_{\text{dynamic}} = P_{\text{switching}} + P_{\text{short-circuit}}$ Switching power $P_{\text{switching}}$ is due to the charging and discharging of the load capacitance, and it can be expressed as: $\large P_{\text{switching}} = \frac{1}{2} \alpha C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}}$ Short-circuit power $P_{\text{short-circuit}}$ arises when both the NMOS and PMOS transistors are conducting simultaneously during switching. It is given by: $\large P_{\text{short-circuit}} = \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} I_{\text{SC}}$ Where: - $I_{\text{SC}}$ is the short-circuit current. The total dynamic power consumption is then the sum of these two components: $\large P_{\text{dynamic}} = \frac{1}{2} \alpha C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} + \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} I_{\text{SC}}$ $\large P_{\text{dynamic}} = \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} (\alpha + I_{\text{SC}})$ When an inverter is transitioning from output state 0 to 1 (charging) and from 1 to 0 (discharging), the dynamic power consumption can be further elaborated. Let's denote the transition time from 0 to 1 as $t_{\text{transition}}^{0 \rightarrow 1}$ and from 1 to 0 as $t_{\text{transition}}^{1 \rightarrow 0}$. For the transition from 0 to 1 (charging), the dynamic power consumption consists of both the charging and short-circuit power. The equations are: $\large P_{\text{dynamic}}^{0 \rightarrow 1} = \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} \alpha t_{\text{transition}}^{0 \rightarrow 1} + \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} I_{\text{SC}} t_{\text{transition}}^{0 \rightarrow 1}$ For the transition from 1 to 0 (discharging), the dynamic power consumption consists only of the short-circuit power since no switching activity is involved: $\large P_{\text{dynamic}}^{1 \rightarrow 0} = \frac{1}{2} C_{\text{eff}} V_{\text{DD}}^2 f_{\text{CLK}} I_{\text{SC}} t_{\text{transition}}^{1 \rightarrow 0}$ Where: - $t_{\text{transition}}^{0 \rightarrow 1}$ is the transition time from output state 0 to 1, - $t_{\text{transition}}^{1 \rightarrow 0}$ is the transition time from output state 1 to 0. In summary, if one could measure the instantaneous power consumption of a circuit without noise, there would be a noticeable difference between a switching to a zero and a switching to a one. In practice, many different measurements of instantaneous power are averaged to remove the impact of noise. The amplitude of the instantaneous power consumption is not only proportional to the amount of switching (which is related to the number of bits that have switched or the [[Fault-Tolerant Design Techniques#Hamming codes|hamming]] distance) but the size of the capacitance being switched, thus areas of the chip with larger capacitances (therefore larger power spikes) such as off-chip transfers/etc will have larger side channel radiated power. Cryptographic algorithms executing on an embedded processor or a specific crypto core will create current switching on the die. The current switching will include key-dependent switching. Thus the power side channel can leak information concerning the key. The current drawn and switched by transistors will also create radiated [[Physical Layer#Electromagnetic Interference (EMI)|EM energy]] through the interaction of the package, printed circuit board, and other components on the board, etc. #### Mitigation There are many proposed countermeasures for side channel resistance that can be used at the circuit/gate level, architecture level, software level, and system level. In most cases, countermeasures at the chip level will come at the expense of area, power consumption, or speed. At the architecture level, techniques such as pre-charging the bus with random data and performing redundant parallel operations may be used. At the software level, some obvious countermeasures involve inserting redundant instructions, removing data-dependent instructions such as loops or jumps, and randomly changing the order of operations. But also inserting random delays. This may be achieved using a random number of NOPs at different points in the cryptographic algorithm. Other approaches include for example the use of random clocks, randomly inserting operations, or using more than one differently structured algorithm. ## Securing Semiconductors The security of semiconductors, and in particular complex System-on-Chips is becoming an increasingly important design concern. Beyond the traditional attacks on connected devices, attacks originating from or assisted by malicious components in hardware are becoming more common. For example, Quo Vadis Labs has reported backdoors in electronic chips that are used in weapons control systems and nuclear power plants [^1], which can allow these chips to be compromised remotely. The well-publicized Spectre [^2] and Meltdown [^3] attacks highlight how sensitive data can be stolen from threads executing on multicore processors. It is widely acknowledged that all algorithmically secure cryptographic primitives and protocols rely on a hardware root-of-trust that is resilient to attacks to deliver the expected protections when implemented in software. Hardware platforms are at an elevated risk for security compromises. The increasing number of cores integrated into SoCs demands the use of scalable on-chip interconnection architectures, for instance, [[Semiconductors#System-on-Chips#Network-on-Chip (NOC)|Network-on-Chip]] (NoC). A typical SoC utilizes NoC to communicate between multiple IP cores including processor, memory, controllers, converters, input/output devices, peripherals, and so on. NoC IPs are used in a wide variety of market segments, such as mobile phones, tablets, automotive, and general-purpose processing, leading to an exponential growth in NoC IP usage. The drastic increase in SoC complexity has led to a significant increase in SoC design and validation complexity. Reusable hardware IP-based SoC design has emerged as a pervasive design practice in the industry to dramatically reduce design and verification costs while meeting aggressive time-to-market constraints. Growing reliance on these pre-verified hardware IPs, often gathered from untrusted third-party vendors, affects the security and trustworthiness of SoC computing platforms. Third-party IPs may come with deliberate malicious implants to incorporate undesired functionality (e.g., hardware Trojan), undocumented test/debug interfaces working as hidden backdoors, or other integrity issues. As can be seen, one of the major strengths of the SoC industry (a diverse IP ecosystem) can also be thought of as its main weakness. The NoC itself can be a threat when different IP blocks come from different sources and vendors. A compromised NoC IP can corrupt data, degrade performance, or even steal sensitive information. NoC security is important for two reasons: (i) NoC has access to all system data, and (ii) NoC spans across the entire SoC, and NoC elements are repetitive in a way that any modification can be easily replicated. ### Vulnerabilities in System-on-chips Security vulnerabilities in SoCs can of course be created intentionally, but also unintentionally by EDA tools or by designers’ mistakes. These vulnerabilities can lead to untrusted (potentially malicious) IPs. Attacks based on malicious implants, such as hardware Trojans, rely on Trojans being integrated into the SoC without being detected at the post-silicon verification stage or during runtime. Hardware Trojans can be inserted into the design in several places, such as by an untrusted EDA tool or designer or at the foundry via reverse engineering. Even if all the IPs are tested before integrating, hardware Trojans can still go undetected because of the complexity of designs with billions of transistors that make physical inspection or 100% coverage in design verification/validation a costly or impossible process. Furthermore, Trojans can mask their behavior as transient errors and can be activated only when a specific condition or a combination of conditions are satisfied. A smart attacker can carefully craft the Trojan activation method so it becomes difficult to detect. The usage of third-party NoC IPs has grown rapidly over the years. Due to the widespread use of NoC IPs, outsourcing NoC IP fabrication has become a common practice. The general problem of securing the on-chip interconnect has been well studied in the computer networks domain and other related areas. However, the implementation of security features introduces area, power, and performance overhead. While bigger computer networks can allow for complex security countermeasures, the resource-constrained nature of embedded and IoT devices poses additional unique challenges: - Conflicting Requirements. While enabling communication between IPs, NoCs need to satisfy a wide variety of requirements, including security, privacy, energy efficiency, domain-specific requirements, and real-time constraints. It is difficult to satisfy conflicting requirements such as security and energy efficiency. For example, it may not be possible to implement traditional security measures such as encrypting text with the AES cipher and using SHA hash functions in resource-constrained IoT devices. Similarly, security and domain-specific requirements may not be compatible. For example, in an automotive network, when a potential security breach is detected, pausing all systems to check the malfunction is not an option, since the car is moving, and stopping it abruptly can lead to catastrophic consequences. Thus, there is a need for innovative solutions to secure NoCs with lightweight security mechanisms customized for application domains. - Increased Complexity. The complexity of SoC designs has made exhaustive security validation an impossible task. Most IPs come as black boxes from vendors that do not reveal design details to maintain a competitive advantage in a niche market. As a result, the complete design is not visible to verification engineers. Modern verification tools often try to detect missing or erroneous functionality, whereas security vulnerabilities can be hidden in dormant functions in large and complex designs that get triggered only by a specific set of inputs. Therefore, using security validation tools during design time to capture all security vulnerabilities is not feasible. There is a wide variety of security vulnerabilities in NoC-based SoCs. The most commonly discussed vulnerabilities in the context of on-chip communication architecture include information leakage, denial-of-service, as well as data corruption. A summary is provided below: 1) Eavesdropping: Listening to confidential information (secure NoC packets) passed through the NoC when other IPs are communicating. 2) Spoofing/Data integrity: Intentional data corruption causes erroneous behavior and/or system failure, whereas spoofing is an impersonation type of attack that disguises communication from an untrusted IP as a trusted IP. 3) Denial-of-service: Attacks that overwhelm the network resources to cause performance degradation, real-time guarantee violations, and reduction of battery lifetime. 4) Buffer overflow/Memory extraction: Gain access to unauthorized privilege levels and memory locations. 5) [[Security#Side-Channel Analysis|Side Channel]]: Mount attacks by utilizing non-functional properties such as time, power, and electromagnetic radiation. ## FIPS 140-3 FIPS 140-3 (Federal Information Processing Standard Publication 140-3) is a standard published by the National Institute of Standards and Technology (NIST) in the United States. It defines security requirements for cryptographic modules, which are used to protect sensitive information in computer and telecommunication systems. FIPS 140-3 provides a framework for the design, implementation, and testing of these cryptographic modules to ensure they meet security standards. The Cryptographic Module Validation Program (CMVP) validates cryptographic modules to Federal Information Processing Standard (FIPS) 140-3 and other cryptography-based standards. The CMVP is a joint effort between the National Institute of Standards and Technology and the Canadian Centre for Cyber Security. Modules validated as conforming to FIPS 140-3 are accepted by the Federal agencies of both countries for the protection of sensitive information (United States) or Designated Information (Canada). The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. In the CMVP, vendors of cryptographic modules use independent, accredited Cryptographic and Security Testing (CST) laboratories to have their modules tested. National Voluntary Laboratory Accreditation Program (NVLAP) accredited laboratories perform cryptographic module compliance/conformance testing. In the context of FIPS 140-3, a cryptographic module refers to a hardware security module (HSM) or a software library that implements cryptographic algorithms and provides secure cryptographic services. These modules are designed to protect sensitive information and ensure the integrity and confidentiality of data in various applications, including government, military, financial, and healthcare sectors. FIPS 140-3 specifies the security requirements for cryptographic modules, including both hardware and software, used by the U.S. government and other regulated industries. The standard defines four security levels (Levels 1 through 4), with each level representing an increasing degree of security assurance and protection against various threats and attacks. Cryptographic modules that comply with FIPS 140-3 undergo rigorous testing and validation processes conducted by accredited testing laboratories to ensure they meet the specified security requirements. These modules are often used in applications such as data encryption, digital signatures, secure communications, and secure key management. > [!warning] > This section is under #development ## Securing Data Interfaces ### Security on IP-based protocols ==When the Internet was originally designed, little thought was given to security. As a result, the core communication protocols are inherently insecure and rely on the honest behavior of all involved parties.== It might have worked back in the day when the Internet consisted of a small number of nodes—mostly universities—but falls apart completely today when everything is connected. At its core, the Internet is built on top of IP and TCP protocols, which are used to package data into small packets for transport. As these packets travel thousands of miles across the world, they cross many computer systems in many countries. Because the core protocols don’t provide any security by themselves, anyone with access to the communication links can gain access to the data as well as change the traffic without detection. IP and TCP aren’t the only vulnerable protocols. There’s a range of other protocols that are used for routing—helping computers find other computers on the network. DNS and BGP are two such protocols. They, too, are insecure and can be hijacked in a variety of ways. If that happens, a connection intended for one computer might be answered by the attacker instead. #### TLS To address the security concerns associated with plain text communication on the Internet, SSL was developed by Netscape Communications Corporation in the mid-1990s. SSL provided a way to establish a secure, encrypted connection between a client and a server, ensuring that data exchanged between them remained confidential and tamper-proof. SSL underwent several iterations, with version 3.0 being the last release by Netscape. In 1999, the Internet Engineering Task Force (IETF) began working on a new protocol based on SSL 3.0, which eventually resulted in the development of Transport Layer Security (TLS). TLS builds upon the principles of SSL but incorporates improvements and enhancements to address known vulnerabilities and weaknesses. Key Features of TLS/SSL: 1. **Encryption**: TLS/SSL protocols use cryptographic algorithms to encrypt data transmitted over the network, making it unreadable to anyone who intercepts it without the proper decryption key. 2. **Authentication**: TLS/SSL enables both the client and server to authenticate each other's identities using digital certificates. This ensures that clients are communicating with legitimate servers and vice versa. 3. **Data Integrity**: TLS/SSL protocols include mechanisms to ensure the integrity of data during transmission. This helps detect any tampering or modification of data by unauthorized parties. 4. **Forward Secrecy**: TLS supports forward secrecy, which means that even if the long-term private key of the server is compromised, past communications remain secure because they were encrypted with ephemeral session keys. TLS/SSL quickly gained widespread adoption as the standard protocol for securing web communications. It became an integral part of the HTTPS (HTTP Secure) protocol, which is the secure version of HTTP. Over time, various versions of TLS have been released, with each iteration addressing security vulnerabilities and improving performance. SSL and TLS rely on an important technology called PKI (public-key infrastructure), which ensures that the traffic is sent to the correct recipient. In terms of the [[The OSI Model|OSI model]], SSL and TLS sit above TCP but below higher-level protocols such as HTTP. When encryption is not necessary, one can remove TLS from the model, but that doesn’t affect the higher-level protocols, which may continue to work directly with TCP. When we do want encryption, we can use it to encrypt HTTP, but also any other TCP-based protocol. At a high level, TLS is implemented via the record protocol, which is in charge of transporting—and optionally encrypting—all lower-level messages exchanged over a connection. Each TLS record starts with a short header, which contains information about the record content type (or subprotocol), protocol version, and length. Message data follows the header.  > [!Figure] > TLS record (source: #ref/Ristic ) The TLS Record header contains the following data structures: ```C struct { uint8 major; uint8 minor; } ProtocolVersion; enum { change_cipher_spec (20), alert (21), handshake (22), application_data (23) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; /* Maximum length is 2^14 (16,384) bytes. */ opaque fragment[TLSPlaintext.length]; } TLSPlaintext; ``` In addition to the visible fields, each TLS record is also assigned a unique 64-bit sequence number, which is not sent over the wire. Each side has its own sequence number and keeps track of the number of records sent by the other side. These values are used as part of the defense against replay attacks. Before a client and server can start communication protected by TLS, they must mutually authenticate and derive key material. They must also agree on the version of the TLS protocol to use as well as which cipher to use for encrypting data. As mentioned above, the TLS protocol defines the TLS Handshake protocol for this purpose, during which mutual authentication, key derivation, TLS version negotiation as well as negotiation of cipher suites takes place. In many cases, public key cryptography is used for the authentication. This allows the two end-points to authenticate each other via certificates. The use of certificates and the established chain of trust built into the certificate infrastructure with certificate authorities avoids the need for the two communicating parties to have prior explicit knowledge of each other. This is one of the key properties that make TLS/ HTTPS work in practice for web traffic on the Internet. The TLS Handshake runs on top of TCP. Once the TLS Handshake has been completed, the two sides have enough information to start communication that is protected by TLS.  > [!Figure] > Example TLS 1.2 Handshake procedure (source: #ref/Rommer ) 1. The TCP three-way handshake is initiated to setup a TCP connection. 2. The consumer (client) sends a TLS ClientHello message indicating the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use. 3. The producer (server) selects the TLS protocol version to use for the rest of the communication, selects a ciphersuite from the list provided by the consumer, includes additional TLS extensions if needed, and sends the response (ServerHello) to the consumer. Then the server sends its certificate in Server Certificate message. The server may also include a request for the consumer’s certificate. Depending on the negotiated key exchange algorithm, the server may send ServerKeyExchange message which includes, for instance, ephemeral Diffie-Hellman parameters. The server then sends ServerHelloDone. 4. If the client and server could agree on the TLS version and ciphersuite, the key exchange continues by the client sending, e.g., ephemeral Diffie-Hellman parameters in a ClientKeyExchange message. The key exchange aims to derive cryptographic keys on both client and server sides for the ciphering and integrity protection of data. Different TLS versions support different types of key exchange methods, but most methods rely on RSA and/or the Diffie-Hellman key exchanges. The client then sends ChangeCipherSpec and Finished messages to take the negotiated security parameters and key in use and to integrity protect the previous handshake messages. 5. The server verifies the Finished message from the client (a Message Authentication Code, MAC, is included) and processes the information received in the message. If everything works well, a ChangeCipherSpec and encrypted and integrity-protected Finished message are sent to the client. 6. The client decrypts the Finished message and verifies the MAC. This completes the TLS Handshake. Communication protected by TLS can now start. As mentioned before, TLS was designed to operate on top of a reliable transport protocol such as TCP. However, it has also been adapted to run over datagram protocols such as UDP. The Datagram Transport Layer Security (DTLS) version 1.2 protocol, defined in RFC 6347^[https://datatracker.ietf.org/doc/html/rfc6347], is based on TLS and can provide similar security properties but using a datagram transport. In [[Non-Terrestrial and Mobile Networks#5G Architecture|5G]], DTLS is supported by 3GPP in addition to IPSec for protecting the signaling on N2, that is, NGAP running over SCTP. Once the TLS Handshake is complete, the actual application data can be sent protected by the TLS layer. The TLS Record protocol takes care of this process, supporting a number of functionalities. For sending data, the TLS Record protocol: - Splits outgoing messages into manageable blocks (records), - Optionally compresses outgoing blocks, - Applies a Message Authentication Code (MAC) to outgoing messages, and - Encrypts the messages. ##### Is TLS invincible? No, it is not. There have been multiple cases of successful attacks on TLS throughout the years. Here are some notable examples: 1. **BEAST (Browser Exploit Against SSL/TLS)**: This attack, demonstrated in 2011, exploits a vulnerability in the implementation of SSL 3.0 and TLS 1.0. It allows an attacker to decrypt and obtain authentication tokens from HTTPS requests. 2. **CRIME (Compression Ratio Info-leak Made Easy)**: CRIME, discovered in 2012, targets the compression algorithms used in TLS and SSL to extract sensitive information such as session cookies from encrypted HTTPS traffic. 3. **Heartbleed**: Heartbleed, disclosed in 2014, wasn't an attack against TLS itself but rather a vulnerability in the OpenSSL cryptographic library which is widely used to implement TLS. It allowed an attacker to retrieve sensitive information from the memory of systems protected by vulnerable versions of OpenSSL. 4. **POODLE (Padding Oracle On Downgraded Legacy Encryption)**: In 2014, this attack exploited a vulnerability in SSL 3.0 that allowed an attacker to decrypt and extract information from HTTPS connections. 5. **DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)**: DROWN, disclosed in 2016, exploited weaknesses in SSLv2 to decrypt communications encrypted with TLS. 6. **ROBOT (Return Of Bleichenbacher's Oracle Threat)**: ROBOT, discovered in 2017, is a variant of the Bleichenbacher attack against RSA encryption. It allowed attackers to decrypt and extract data from HTTPS traffic encrypted with RSA. 7. **SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes)**: SLOTH, identified in 2015, exploited weaknesses in cryptographic hash functions used in TLS to perform various attacks, including signature forgery and key recovery. 8. **FREAK (Factoring RSA Export Keys)**: This vulnerability, disclosed in 2015, allowed attackers to force SSL/TLS clients to use weak encryption algorithms that could be easily cracked, thereby intercepting and decrypting supposedly secure communications. Being a widely adopted protocol, there is a lot of interest in TLS at all times. For instance, Bullrun (or BULLRUN) is the codename for a classified program run by the United States National Security Agency (NSA), whose purpose is to break encrypted communication by any means possible. According to the New York Times^[https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html], the NSA has about $250 million a year to spend on these activities. British GCHQ apparently has its own program for similar activities, codenamed Edgehill. TLS, being one of the major security protocols, is an obvious target of these programs. The public disclosure of Bullrun has caused many to view security standards development in a completely different light; how can we trust security standards if we don’t trust the people who design them? #### Securing Lower Layers I mean, sure, all good with TLS/SSL and the security they bring...at layer 6. TLS encrypts application data, which is carried within TCP segments (or UDP datagrams with DTLS) for transmission over the network. TCP itself is not responsible for the encryption; it simply carries the TLS-encrypted data. What happens, then, with the lower layers in a TCP/IP-based protocol stack? How do we secure the transport layer, the network layer, the data link layer, and the physical layer? These lower layers, still unencrypted, may reveal a good deal of information in headers and trailers including port numbers, sequence numbers, fragmentation information, and other things for an attacker to learn more about the data or the network. In RFC 9065^[https://datatracker.ietf.org/doc/rfc9065/] ("Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols"), the IETF tackles the dilemma of securing or not the transport layer. In said RFC, the IETF observes that transport protocols are being developed that encrypt some or all of the transport headers, in addition to the transport payload data. The QUIC transport protocol RFC9000^[https://datatracker.ietf.org/doc/html/rfc9000] is an example of such a protocol. Such transport header encryption makes it difficult to observe transport protocol behavior from the vantage point of the network. This document discusses some implications of transport header encryption for network operators and researchers who have previously observed transport headers, and it highlights some issues to consider for transport protocol designers. In RFC7258^[https://datatracker.ietf.org/doc/html/rfc7258], the IETF concludes that Pervasive Monitoring (PM) is an attack technique that needs to be mitigated in the design of IETF protocols. The RFC7258 states: "Making networks unable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered". The lower we go in the OSI model, the less sophisticated the means to secure data. As for how to secure data link layers, it greatly depends on what interface we are talking about. For wired Ethernet links, security measures like MAC address filtering can be implemented to control access and prevent unauthorized devices from connecting to the network. > [!Note] > Is header data, including port numbers and the like, sensitive? Opinions vary. A few reasons why TCP headers and ports are often considered less sensitive compared to the actual payload data includes: > 1. **Common Knowledge**: Much of the information in TCP headers, such as port numbers, is commonly known or easily discoverable. For example, web servers typically use port 80 for HTTP and port 443 for HTTPS. While this information can provide some insights into the network's configuration, it's not typically considered highly sensitive. > 2. **Limited Usefulness**: While an attacker can gain some insight into the network's configuration by analyzing TCP headers, this information alone may have limited usefulness without context or additional data. For example, knowing that a server is using port 22 for SSH doesn't necessarily reveal sensitive information about the data being transmitted over that connection. > 3. **Focus on Payload Data**: In many security scenarios, attackers are primarily interested in the actual payload data being transmitted over the network, rather than the metadata contained in TCP headers. Encrypting the payload data (which is typically done with protocols like TLS) provides a higher level of security and confidentiality. > >However, it's important to note that in certain contexts, such as targeted attacks or scenarios where network reconnaissance is critical, even seemingly innocuous information like TCP headers can be valuable to attackers. [[Security#Types of Attacks|Pervasive monitoring]] is now a clear threat to networks and therefore measures against PM must be put in place. For the physical layer, physical security measures must be implemented to protect the physical infrastructure of the network from [[Security#Side-Channel Analysis|side-channel analysis]], such as cables, routers, switches, and other networking equipment, from unauthorized access, tampering, or physical attacks. Measures may include physically securing networking equipment in locked cabinets or rooms, using tamper-evident seals, and employing surveillance or access control systems to monitor and restrict physical access to sensitive areas. ##### IPSec IPsec, short for Internet Protocol Security, is a suite of protocols and algorithms used to secure Internet Protocol (IP) communications at the network layer (layer 3). It provides cryptographic protection for IP datagrams, ensuring confidentiality, integrity, and authenticity of data transmitted over IP networks. IPsec is widely used to establish Virtual Private Networks (VPNs) and to secure communication between network devices, such as routers, gateways, and firewalls. Key aspects of IPsec are: 1. **Security Services:** - IPsec offers a range of security services to protect IP communications: - **Confidentiality:** It encrypts IP datagrams to prevent unauthorized parties from eavesdropping on the transmitted data. - **Integrity:** It ensures that data remains unchanged during transit by using cryptographic mechanisms to detect and prevent tampering or modification. - **Authenticity:** IPsec provides authentication mechanisms to verify the identities of communicating parties and prevent impersonation attacks. - **Anti-replay Protection:** IPsec includes mechanisms to prevent replay attacks, where an attacker captures and retransmits data packets to disrupt communication. 2. **Protocols and Components:** - IPsec consists of several protocols and components working together to provide security: - **Authentication Header (AH):** AH provides authentication and integrity protection for IP datagrams by including a hash-based Message Authentication Code (MAC) in each datagram header. - **Encapsulating Security Payload (ESP):** ESP provides confidentiality, integrity, and optionally authentication for IP datagrams through encryption and authentication mechanisms. - **Security Associations (SA):** SAs define the security parameters and cryptographic keys used to secure communication between two IPsec-enabled devices. - **Key Management:** IPsec relies on various key exchange protocols, such as Internet Key Exchange (IKE), to establish and manage cryptographic keys securely. 3. **Modes of Operation:** - IPsec operates in two primary modes: - **Transport Mode:** In transport mode, only the payload (upper-layer data) of the IP packet is encrypted and authenticated, leaving the IP header intact. Transport mode is typically used for end-to-end communication between hosts. - **Tunnel Mode:** In tunnel mode, the entire IP datagram, including the original IP datagram, is encapsulated within a new IP datagram with its own IPsec header. Tunnel mode is commonly used to create secure VPN connections between networks or gateways. 4. **Deployment Scenarios:** - IPsec is widely deployed in various scenarios, including: - **Site-to-Site VPNs:** IPsec is used to establish secure connections between geographically distributed networks, such as branch offices, data centers, or cloud environments. - **Remote Access VPNs:** It enables remote users to securely access corporate networks or resources over the Internet. - **Router-to-Router Communication:** IPsec secures communication between routers and gateways in large-scale network infrastructures, such as Internet Service Provider (ISP) networks. 5. **Interoperability and Standards:** - IPsec is standardized by the Internet Engineering Task Force (IETF) through a series of Request for Comments (RFC) documents. - It enjoys broad interoperability among different vendors and platforms, allowing organizations to deploy IPsec-based security solutions in heterogeneous environments. IPsec tunnel mode is used between two dedicated routers, with each router acting as one end of a virtual "tunnel" through a public network. In IPsec tunnel mode, the original IP header containing the final destination of the packet is encrypted, in addition to the packet payload. To tell intermediary routers where to forward the packets, IPsec adds a new IP header. At each end of the tunnel, the routers decrypt the IP headers to deliver the packets to their destinations. In transport mode, the payload of each packet is encrypted, but the original IP header is not. Intermediary routers are thus able to view the final destination of each packet — unless a separate tunneling protocol is used. To look at IPsec from the bottom up, we must first take a brief detour to revisit the IP Header itself, which carries all of the traffic we'll be considering. Note that we are not trying to provide comprehensive coverage to the IP header — there are other excellent resources for that (for instance, "Internetworking with TCP/IP" by Douglas Comer).  > [!Figure] > _IPv4 datagram carrying a TCP packet (source:http://www.unixwiz.net/techtips/iguide-ipsec.html)_ ###### Authentication Header (AH) In IPSec, AH is used to authenticate—but not encrypt—IP traffic, and this serves the treble purpose of ensuring that we're really talking to who we think we are, detecting alteration of data while in transit, and (optionally) to guard against replay by attackers who capture data from the wire and attempt to re-inject that data back onto the wire at a later date. _Authentication_ is performed by computing a cryptographic hash-based message authentication code over nearly all the fields of the IP packet (excluding those that might be modified in transit, such as TTL or the header checksum), storing this in a newly added AH header, and sent to the other end.  >[!Figure] >_AH Header (source: #ref/Friedl )_ The fields of the AH header are: - next hdr: This identifies the protocol type of the following payload, and it's the original packet type being encapsulated: this is how the IPsec header(s) are linked together. - AH len: This defines the length, in 32-bit words, of the whole AH header, minus two words (this "minus two words" proviso springs from the format of IPv6's [RFC 1883](http://rfc.net/rfc1883.html) Extension Headers, of which AH is one). - Reserved: This field is reserved for future use and must be zero. - Security Parameters Index: This is an opaque 32-bit identifier that helps the recipient select which of possibly many ongoing conversations this packet applies. Each AH-protected connection implies a hash algorithm (MD5, SHA-1, etc.), some kind of secret data, and a host of other parameters. The SPI can be thought of as an index into a table of these settings, allowing for easy association of packet with parameter. - Sequence Number: This is a monotonically increasing identifier that's used to assist in antireplay protection. This value is included in the authentication data, so modifications (intentional or otherwise) are detected. - Authentication Data: This is the Integrity Check Value calculated over the entire packet—including most of the headers—The recipient recomputes the same hash; Mismatched values mark the packet as either damaged in transit or not having the proper secret key. These are discarded. The easiest mode to understand is AH in _Transport Mode_, which is used to protect an end-to-end conversation between two hosts. This protection is either authentication or encryption (or both), but it is not a tunneling protocol. It has nothing to do with a traditional VPN: it's simply a secured IP connection.  >[!Figure] >_Authentication header in transport mode. Source: #ref/Friedl _ In AH Transport Mode, the IP packet is modified only slightly to include the new AH header between the IP header and the protocol payload, and there is a shuffling of the protocol code that links the various headers together. This protocol shuffling is required to allow the original IP packet to be reconstituted at the other end: after the IPsec headers have been validated upon receipt, they're stripped off, and the original protocol type (TCP, UDP, etc.) is stored back in the IP header. We'll see this chain of next header fields again and again as we examine IPsec. When the packet arrives at its destination and passes the authentication check, the AH header is removed and the `Proto=AH` field in the IP header is replaced with the saved "Next Protocol". This puts the IP datagram back to its original state, and it can be delivered to the waiting process. Tunnel Mode forms the more familiar VPN functionality, where entire IP packets are encapsulated inside another and delivered to the destination. Like Transport mode, the packet is sealed with an Integrity Check Value to authenticate the sender and prevent modification in transit. But unlike Transport mode, it encapsulates the _full IP header_ as well as the payload, and this allows the source and destination addresses to be different from those of the encompassing packet: This allows the formation of a tunnel.  > [!Figure] > IPSec in AH tunnel mode (source: #ref/Friedl )  > [!Figure] > *AH transport and tunnel mode (credit: Mpk1024 - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=97123608)* When a Tunnel-mode packet arrives at its destination, it goes through the same authentication check as any AH-type packet, and those passing the check have their entire IP and AH headers stripped off. This effectively reconstitutes the original IP datagram, which is then injected into the usual routing process. Most implementations treat the Tunnel-mode endpoint as a virtual network interface—just like an Ethernet interface or localhost—and the traffic entering or leaving it is subject to all the ordinary routing decisions. The reconstituted packet could be delivered to the local machine or routed elsewhere (according to the destination IP address found in the encapsulated packet), though in any case is no longer subject to the protections of IPsec. At this point, it's just a regular IP datagram. Though Transport mode is used strictly to secure an end-to-end connection between two computers, Tunnel mode is more typically used between gateways (routers, firewalls, or standalone VPN devices) to provide a Virtual Private Network (VPN). So, transport or tunnel? Curiously, there is no explicit "Mode" field in IPsec: what distinguishes Transport mode from Tunnel mode is the `next` header field in the AH header. When the next-header value is _IP_, it means that this packet encapsulates an entire IP datagram (including the independent source and destination IP addresses that allow separate routing after de-encapsulation). This is Tunnel mode. Any other value (TCP, UDP, ICMP, etc.) means that it's in Transport mode and is securing an endpoint-to-endpoint connection. The top level of the IP datagram is structured the same way regardless of mode, and intermediate routers treat all flavors of IPsec/AH traffic identically without deeper inspection. We'll note that a host—as opposed to a gateway—is required to support both Transport and Tunnel modes, but when creating a host-to-host connection, it seems a little superfluous to use Tunnel mode. Furthermore, a gateway (router, firewall, etc.) is only required to support Tunnel mode, though supporting Transport mode is useful only when creating an endpoint to the gateway itself, as in the case of network management functions. ###### Encapsulating Security Protocol (ESP) Adding encryption makes ESP a bit more complicated than AH because the encapsulation _surrounds_ the payload rather than _precedes_ it as with AH. ESP includes header and trailer fields to support the encryption and optional authentication. It also provides Tunnel and Transport modes which are used in by-now familiar ways. The IPsec RFCs don't insist upon any particular encryption algorithms, but DES, triple-DES, AES, and [Blowfish](http://www.schneier.com/paper-blowfish-fse.html) are in common use to shield the payload from prying eyes. The algorithm used for a particular connection is specified by the Security Association (covered in a later section), and this SA includes not only the algorithm, but the key used. Unlike AH, which provides a small header _before_ the payload, ESP _surrounds_ the payload it's protecting. The Security Parameters Index and Sequence Number serve the same purpose as in AH, but we find padding, the next header, and the optional Authentication Data at the end, in the ESP Trailer. It's possible to use ESP without any actual encryption (to use a NULL algorithm), which nonetheless structures the packet the same way. This provides no confidentiality, and it only makes sense if combined with ESP authentication. It's pointless to use ESP without either encryption or authentication (unless one is simply doing protocol testing). Padding is provided to allow block-oriented encryption algorithms room for multiples of their blocksize, and the length of that padding is provided in the pad len field. The next hdr field gives the type (IP, TCP, UDP, etc.) of the payload in the usual way, though it can be thought of as pointing "backwards" into the packet rather than forward as we've seen in AH.   > [!Figure] > ESP with and without authentication (source: #ref/Friedl ) In addition to encryption, ESP can also optionally provide authentication, with the same HMAC as found in AH. Unlike AH, however, this authentication is _only for the ESP header and encrypted payload_: it does not cover the full IP packet. Surprisingly, this does not substantially weaken the security of the authentication, but it does provide some important benefits. When an outsider examines an IP packet containing ESP data, it's essentially impossible to make any real guesses about what's inside save for the usual data found in the IP header (particularly the source and destination IP addresses). The attacker will certainly know that it's ESP data — that's also in the header — but the type of the payload is _encrypted with the payload_. Even the presence or absence of Authentication Data can't be determined by looking at the packet itself (this determination is made by using the Security Parameters Index to reference the preshared set of parameters and algorithms for this connection). However, it should be noted that sometimes _the envelope_ provides hints that the _payload_ does not. With more people sending VoIP inside ESP over the internet, the QoS taggings are in the outside header, and is fairly obvious what traffic is VoIP signaling (IP precedence 3) and what is RTP traffic (IP precedence 5). It's not a sure thing, but it might be enough of a clue to matter in some circumstances. In transport mode, just as with AH, ESP encapsulates just the datagram's payload and is designed strictly for host-to-host communications. The original IP header is left in place (except for the shuffled Protocol field), and it means that—among other things —the source and destination IP addresses are unchanged.  >[!Figure] >ESP in transport mode (source: #ref/Friedl ) In Tunnel mode, ESP encapsulates an entire IP datagram inside the encrypted shell:  > [!Figure] > ESP in tunnel mode (source: #ref/Friedl )  > [!Figure] > ESP in transport and tunnel mode (credit: Mpk1024 - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=97123608) Providing an encrypted Tunnel Mode connection is very close to the traditional VPN that springs to mind when most of us think about IPsec, but we have to add authentication of one type or another to complete the picture. Unlike AH, where an onlooker can easily tell whether traffic is in Tunnel or Transport mode, this information is unavailable here: the fact that this is Tunnel mode (via `next=IP`) is part of the encrypted payload and is simply not visible to one unable to decrypt the packet. > [!warning] > This section is under #development ###### Internet Key Exchange IPsec would be nearly useless without the cryptographic facilities of authentication and encryption, and these require the use of secret keys known to the participants but not to anyone else. The most obvious and straightforward way to establish these secrets is via manual configuration: one party generates a set of secrets and conveys them to all the partners. All parties install these secrets in their appropriate place. But this process does not scale well, nor is it always secure: the mere act of conveying the secrets to another entity may well expose them in transit. In a larger installation with many devices using the same preshared key, compromise of that key makes for a very disruptive re-deployment of new keys. IKE exists to allow two endpoints to properly set up their Security Associations, including the secrets to be used. IKE uses the ISAKMP (Internet Security Association Key Management Protocol) as a framework to support the establishment of a security association compatible with both ends. Multiple key exchange protocols themselves are supported, with Oakley being the most widely used. IPsec key exchange typically takes place over port 500/UDP. Most IPsec implementations consist of an IKE daemon and an IPsec stack in the kernel that processes the actual IP datagrams. > [!Note] User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys, and certificates, as required. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons. The IKE protocol generally requires 4–6 packets with 2–3 round trips to create a security association (SA) on both sides. The negotiated key material is then given to the IPsec stack. IKE operates in two phases: Phase 1 and Phase 2. Here's a brief description of the IKE protocol: **Phase 1: IKE SA Establishment** 1. **Initiation**: - The two parties (usually a client and a server) initiate communication. The initiator sends an IKE proposal containing cryptographic algorithms, key exchange methods, and other parameters to the responder. 2. **Response**: - The responder receives the IKE proposal and responds with its own IKE proposal, selecting compatible algorithms and parameters. This establishes the initial communication channel. 3. **Diffie-Hellman Key Exchange**: - The parties perform a Diffie-Hellman key exchange to establish a shared secret. This shared secret will be used to derive session keys for securing subsequent IKE communications. 4. **Authentication**: - The parties authenticate each other using digital signatures, pre-shared keys, or other authentication methods as defined in the IKE proposal. 5. **Agreement**: - Both parties agree on a set of parameters, including cryptographic algorithms, session lifetimes, and other security attributes, to be used for subsequent communication. 6. **IKE SA Establishment**: - Once the negotiation is complete and both parties agree on the parameters, an IKE Security Association (IKE SA) is established. This IKE SA will be used to protect subsequent IKE exchanges. **Phase 2: IPsec Security Association (SA) Establishment** 1. **Proposal Exchange**: - Once the IKE SA is established, the parties negotiate IPsec Security Associations (IPsec SAs) for protecting actual data traffic. This involves exchanging proposals for IPsec parameters such as encryption and authentication algorithms, as well as session lifetimes. 2. **Traffic Protection**: - Once the IPsec SA is established, data traffic can be securely transmitted between the parties using the agreed-upon encryption and authentication algorithms. 3. **Periodic Rekeying**: - To maintain security, IKE supports periodic rekeying of SAs. This involves renegotiating and refreshing cryptographic keys and parameters to prevent cryptographic attacks. 4. **SA Termination**: - SAs can be terminated manually or automatically based on predefined criteria such as session lifetimes or security policy changes. > [!warning] > This section is under #development ### Securing non-IP-based Protocols IP is so widely adopted that the amount of support and standardization just keeps growing. However, a question appears: What do we do if our data interface is not based on IP? Although IP can be theoretically encapsulated everywhere, it's not always practical to have IP datagrams since we also need an IP stack (what gives "life" to a protocol), and stacks take valuable resources, namely computing power and storage that we might not always have at hand as it is typical in resource-constrained embedded devices. When there is no IP-based communication, such as in non-IP-based protocols like [[Physical Layer#I2C|I2C]], [[Physical Layer#SPI|SPI]], or many others, securing communication must be done a bit differently. In such cases, the concept of TLS/SSL as discussed before doesn't directly apply because TLS/SSL operates at the transport layer, which assumes IP is down there. Of course, no IPSec is possible either. However, the need for security and privacy still exists in non-IP-based communication protocols. Here are some common approaches to secure communication in such scenarios: 1. **Encryption at the Application Layer**: Instead of relying on transport layer security like TLS/SSL, encryption and authentication mechanisms can be implemented at the application layer. This involves encrypting the payload data in "user space" before transmission. 2. **Encryption using IP cores**: If FPGAs are involved, an unencrypted data link can be secured using commercial cores that add encryption such as AES. 3. **Custom Security Protocols**: Designing custom security protocols tailored to the specific needs and constraints of the communication medium. These protocols may include encryption, authentication, and integrity checks appropriate for the protocol and the devices involved. 4. **Physical Security Measures**: In some cases, physical security measures such as restricting access to the communication medium or devices themselves can be employed to prevent unauthorized access or tampering. 5. **Key Exchange Mechanisms**: Implementing secure key exchange mechanisms, such as Diffie-Hellman key exchange, to establish shared secret keys between communicating parties. These keys can then be used for encryption and decryption of data. [[Security#Internet Key Exchange|Internet Key Exchange]] is one of these mechanisms. 6. **Authentication**: Implementing authentication mechanisms to verify the identity of the communicating parties. This can involve pre-shared keys, digital signatures, or other authentication methods suitable for the protocol. 7. **Integrity Checks**: Including mechanisms to detect tampering or modification of data during transmission. This can involve using cryptographic hash functions or message authentication codes (MACs) to ensure data integrity. 8. **Using Crypto Units**: Insecure data interfaces might be secured by using special hardware units located at both endpoints of a point-to-point link. Crypto units, also known as cryptographic units or cryptographic modules, are hardware components designed to perform cryptographic operations securely and can remain reasonably transparent from the application layer. It's important to note that securing communication in non-IP-based protocols often requires careful consideration of the unique characteristics and constraints of the communication medium involved. Additionally, security measures should be chosen based on the specific security requirements of the application and the potential threats it may face. > [!Note] > It is important to note that practically all the data interfaces we discuss [[Data Interfaces (Start Here)|here]] natively lack encryption. [[Physical Layer#I2C|I2C]], [[Physical Layer#SPI|SPI]], [[High-Speed Standard Serial Interfaces#PCI Express|PCIe]], [[High-Speed Standard Serial Interfaces#Ethernet|Ethernet]], [[Semiconductors#System-on-Chips#Advanced Microcontroller Bus Architecture (AMBA)|AMBA]], [[High-Speed Standard Serial Interfaces#Serial ATA|SATA]], and many others do not consider encryption as a "built-in" feature, and leave it to the implementer to add measures at the application level. This means that these interfaces are subject to confidentiality and replay vulnerabilities provided an attacker has the means to access the buses either physically or utilizing side-channel analysis. Goes to say that practically all complex digital systems out there are coupled through insecure data interfaces. Things are changing, though; there are growing efforts to add security "by design" to some of these widely adopted interfaces. For instance, the Integrity and Data Encryption (IDE^[https://pcisig.com/sites/default/files/files/PCIe%20Security%20Webinar_Aug%202020_PDF.pdf]) initiative in PCIe intends to provide confidentiality, integrity, and replay protection for PCIe Transaction Layer Packets (TLPs); PCIe is typically used for transferring memory content from kernel areas; an attack in a PCIe link could leak sensitive memory content. > Of course, adding security brings challenges as well, namely, key exchange and management. If every data interface on a given system requires a secret key, managing the establishment and storage of all these keys might not be an easy task. > [!warning] > This section is under #development [^1]: Sergei Skorobogatov and Christopher Woods. 2012. _Breakthrough silicon scanning discovers backdoor in military chip. In Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems_. Springer, 23– 40. [^2]: Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom. 2019. _Spectre attacks: Exploiting speculative execution. In Proceedings of the 40th IEEE Symposium on Security and Privacy_ (S&P’19). [^3]: Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. 2018. _Meltdown: Reading kernel memory from user space. In Proceedings of the 27th USENIX Security Symposium_ (USENIX Security’18).