Special | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ALL
D |
---|
Diffie-Hellman key agreement | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
The Diffie-Hellman (D-H) key agreement (often called “key exchange”) protocol is standardised in NIST SP 800-56A [BCR+18]. The protocol originated in the seminal 1976 paper by Whitfield Diffie and Martin Hellman [DH76], both recipients of the 2016 Turing Award (their contribution took 40 years to be recognised). Protocol between 👩 Alice and 🧔 Bob [KL21, CONSTRUCTION 11.2] in Fig. 1:
A necessary condition for preventing a probabilistic polynomial-time (PPT) eavesdropper from computing the session key is that the computational Diffie-Hellman (CDH) problem is hard: Definition 1: Computational Diffie-Hellman (CDH) problem [Gal12, Definition 20.2.1]
However, the hardness of the CDH problem is not sufficient. Just as indistinguishability plays an essential role in symmetric-key encryption, indistinguishability is key here: if the session key is indistinguishable from an element chosen uniformly at random from , then we have a sufficient condition for preventing a PPT eavesdropper from computing the session key [KL21, pp. 393-394]. The indistinguishability condition is equivalent to the assumption that the decisional Diffie-Hellman (DDH) problem is hard: Definition 2: Decisional Diffie-Hellman (DDH) problem [Gal12, Definition 20.2.3]
The DDH problem is readily reducible to the CDH problem, since any algorithm that solves the CDH can compute and compare it with ; implying the DDH problem is no harder than the CDH problem. In turn, the CDH problem is reducible to the discrete logarithm problem (DLP, see Definition 3), since any algorithm that solves the DLP can compute from , from , and hence ; implying the CDH problem is no harder than the DLP problem. Definition 3: Discrete logarithm problem (DLP) [Gal12, Definition 13.0.1]
In other words, the DDH problem can be reduced to the CDH problem, which in turn can be reduced to the DLP; solving the DLP breaks the D-H key agreement protocol. ⚠ There are multiplicative groups for which the DLP is easy, so it is critical that the right groups are used. A safe-prime group is a cyclic subgroup of the Galois field with prime order , where is called a safe prime; this subgroup has elements [BCR+18, Sec. 5.5.1.1]. NIST [BCR+18, Appendix D] refers to RFC 3526 and RFC 7919 for definitions of safe-prime groups. The D-H key agreement protocol is used in the Internet Key Exchange (IKE) protocol, which is currently at version 2 [KHN+14]. References
| ||||||||||||
E |
---|
Emotet | ||||||
---|---|---|---|---|---|---|
First identified in 2014 [ANY14], the Emotet malware evolved from a banking Trojan designed to steal sensitive information (including credentials) to a modular, polymorphic, multi-threat downloader for other, more destructive malware [MGB22]. References
| ||||||
Encapsulation Packet Protocol (EPP) | ||||
---|---|---|---|---|
The Encapsulation Packet Protocol (EPP) is used to transfer protocol data units (PDUs) recognised by CCSDS that are not directly transferred by the Space Data Link Protocols over an applicable ground-to-space, space-to-ground, or space-to-space communications link [CCS20b]. References
| ||||
F |
---|
Flow | ||
---|---|---|
H |
---|
Hardware Trojan | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
A hardware Trojan (see Definition 1) may control, modify, disable, or monitor the contents and communications of the device it is embedded in [RKK14, Sec. II]. Hardware that has been modified with a malicious functionality hidden from the user. Hardware Trojans provide a means to bypass traditional software and cryptographic-based protections, allowing a malicious actor to control or manipulate device/system software, 1️⃣ getting access to sensitive information, and/or 2️⃣ causing denial-of-service to legitimate users by causing device/system failures or simply by turning the device/system off [BDF+22]. Examples of hardware Trojans are aplenty within academia and outside of academia [HAT21].
👩🎓 Examples from within academia Smartphones often break, but replacing broken components provides an opportunity for malicious actors to implant hardware Trojans. One of the most frequently replaced components is the touchscreen; more than 50% of smartphone owners have damaged their screen at least once [SCSO17]. Steps of the “Shattered Trust” attack [SCSO17]:
Another frequently replaced component is the phone battery [LFH+18] 🎦. On a larger scale, computer peripherals can serve as hardware Trojans that exploit the vulnerabilities in Input-Output Memory Management Units (IOMMUs) [MRG+19].
Watch Christof Paar’s overview lecture:
👩💻 Examples from outside academia In 2018, Bloomberg Businessweek made the sensational claim entitled “The Big Hack” that China’s PLA launched a supply chain attack by implanting a tiny Trojan chip in motherboards made by Super Micro Computer Inc. (“Supermicro” for short) [MLP+20] 🎦.
Trojan detection is challenging because [RKK14, Sec. II]:
CountermeasuresFour main defence strategies can be identified [HAT21, Sec. 4]:
References
| ||||||||||||||||||||||||||||
Hash functions | |||
---|---|---|---|
See 👇 attachment or the latest source on Overleaf.
| |||
Homodyne vs heterodyne detection | ||||
---|---|---|---|---|
Homodyne detection = method of detecting a weak frequency-modulated signal through mixing with a strong reference frequency-modulated signal (so-called local oscillator). References
| ||||
I |
---|
Intrusion detection: an introduction | ||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NIST defines intrusion detection to be: Definition 1: Intrusion detection [SM07, Appendix A]
The process of monitoring the events occurring in a computer system or network and analysing them for signs of possible incidents. Intrusion prevention goes beyond intrusion detection, although “prevention” is strictly speaking an exaggeration: Definition 2: Intrusion prevention [SM07, Appendix A]
The process of monitoring the events occurring in a computer system or network, analysing them for signs of possible incidents, and attempting to stop detected possible incidents. In Definition 2, an “attempt” can be sending an alarm to the administrator(s), resetting a network connection, reconfiguring a firewall to block traffic from the source address, etc. Thus, “intrusion detection and prevention system” (IDPS) is synonymous with “intrusion prevention system” (IPS) [SM07, Appendix A], and is a bit of a redundant term. Fig. 1 shows an example of a high-end IPS appliance from Cisco. In the 1970s and the early 1980s, administrators had to print out system logs on papers and manually audit the printout [KV02]. The process was clearly 1️⃣ reliant on the auditors’ expertise, 2️⃣ time-consuming, and 3️⃣ too slow to detect attacks in progress. In the 1980s, storage became cheaper, and intrusion detection programs became available for analysing audit logs online, but the programs could only be run at night when the system’s user load was low [KV02]. Thus, detecting attacks in time remained a challenge. In the early 1990s, real-time intrusion detection systems (IDSs) that analysed audit logs as the logs were produced became available [KV02]. Since the inception of IDSs, the quality and quantity of audit logs have always been a challenge [KV02]:
An IDS is meant to detect [KV02]:
Accordingly, intrusion detection algorithms can be classified as [SM07; YT11, p. 2; BK14, p. 4; Led22; Pal22]:
Depending on its type, an IDS can comprise several types of components, as shown in Fig. 2: sensors/agents (which monitor and analyse network activities and may also perform preventive actions), management servers, database servers, user and administrator consoles, and management networks [SM07]. There is more than one way to classify IDSs. See the attachment for different classifications of IDSs. Watch the following LinkedIn Learning video for a quick summary of IDS: What is an IDS? from Protecting Your Network with Open Source Software by Jungwoo Ryoo References
| ||||||||||||||||||||||||||||||||||||||||||||||
Intrusion detection systems: classifications | |||
---|---|---|---|
See attachment 👇. | |||
J |
---|
JTAG | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The increasing usage of cutting-edge technologies in safety-critical applications leads to strict requirements on the detection of defects both at the end of manufacturing and in the field [VDSDN+19]. Besides scan chains, test access ports (TAPs) and associated protocols constitute the fundamental test mechanism [VDSDN+19]. Among the earliest standards for test access ports is IEEE Std 1149.1a-1993, first drafted by the Joint Test Action Group (JTAG) in the late 1980s, and then standardised by the IEEE in the early 1990s [IEEE13].
The TAP controller in Fig. 1 implements the 16-state finite state machine in Fig. 3. For example, Select-DR-Scan is a temporary controller state (i.e., the next rising edge of TCK makes the controller exit this state) in which all test data registers (DRs) selected by the current instruction retain their previous state [IEEE13, p. 26].
Operationally speaking, the most important consideration for a security analyst, when assessing the security of a device, is finding a JTAG interface. Standard tools such as the Bus Pirate, JTAGulator and Open On-Chip Debugger (OpenOCD) can then be used to probe the device through this interface. Watch the following tutorial on YouTube: References
| ||||||||||||||