---
title: Embedded System Security
---

| # | Slideset | # Slides | done |
| --- | --------------------------------- | -------- | ---- |
| 0 | Organization | 14 | yes |
| 1 | Intro to Security | 26 | yes |
| 2 | Intro to Embedded Systems | 42 | yes |
| 3 | Embedded Security Architectures | 51 | yes |
| 4 | Attestation Architecture | 34 | yes |
| 5 | PUFs | 54 | yes |
| 6 | HW-based Mobile Platform Security | 80 | yes |
| 7 | Runtime Attacks | 160 | yes |
| 8 | IoT-Malware | 110 | yes |
| 10 | Zigbee | 85 | yes |
| | Total Slides | 656 | |

[toc]

# 1. Intro to Security: Definitions
## Definitions

### Security
Security is about protection of assets. **Assets** and their **values** must be known $\rightarrow$ Risk analysis. Rough classification of protective measures:
- Prevention
- Detection
- Reaction

### Computer Security
> _Computer security deals with the prevention and detection of unauthorized actions by users of a computer system._

It is about controlling access to **information**. Because this is very hard to grasp, we use the goal of controlling access to **data**.

- **Data:** Physical phenomena chosen by convention to represent certain aspects of our conceptual and real world. Can be used to store, transmit or derive new information (the latter using formal rules)
- **Information:** The meanings we assign to data. Information is the subjective interpretation of data.

### Security vs Reliability and Safety
- **Reliability:** Related to (accidental) failures in the system
- **Safety:** Related to the impact of system failures on their environment, which also deal with situations where the system has to perform properly in adverse conditions
- **Security:** Deals with prevention and detection of unauthorized actions in the system

The term **Dependability** unites them all: Security, reliability, integrity, and availability can be treated as aspects of dependability.

> _Dependability is the property of a computer system such that reliance can justifiably be placed on the service it delivers._ (Selected definition)

### Classical security targets
- **Confidentiality:** Prevention of unauthorized disclosure of information
- **Integrity**: Prevention of unauthorized modification of information
- **Availability:** Prevention of unauthorized withholding of information or resources

#### Other security targets
- **Authenticity:** Integrity of a message content and origin, and possibly of some other information, such as the time of emission.
- **Accountability (Zurechenbarkeit):** Availability and integrity of the identity of the subject who performed an operation. (In practice through data origin authentication [verifying the source of transmitted data] or entity authentication [verifying the identity of an entity]).
- **Non-repudiation (Verbindlichkeit):** Availability and integrity of the identity of the sender of a message (nonrepudiation of the origin) or, of the receiver (non-repudiation of reception) together with the ability to prove this to (honest) third parties.

#### Privacy targets
- **Privacy:** Confidentiality with respect to personal data, which can be either "information" or "metainformation".
- **Anonymity:** Confidentiality of the identity of the person, for instance, who invoked an operation. Alternatively: the state of being not identifiable within a set of subjects.
- **Untraceability:** Related to anonymity.
- **Unlinkability:** Different transactions are not linkable.
- **Unobservability:** The state of items of interest (IOI), for example subjects, messages or events is beeing indistinguishable from any IOI (of the same type) at all.

### The dimensions of computer security
_The design space for computer security._

**Subject:** An active identity (e.g. a process) that can launch several subprocesses associated with multiple subjects within the same login session.
**Object:** A passive identity (e.g. file, database-record, printer-device)


On the vertical axis only the **Hardware** and Operating System are trusted. Everything above, the **Software**, is outside of the security perimeter.

Security measures can be **physical**, **organizational** or **technical**.

### Physical security
**Physical security** forms a barrier placed around a computer system to deter unauthorized physical access to the computing system itself. It is becoming more important. It is complementary to **logical security**, mechanisms by which the OS and other software prevent access to data and **environmental secuirty** (cameras, guards, access policies, etc.).

Physical security should ensure low probability of success, in the event of an attack, and high probability of detection. Some physical security methods are:
- **Tamper-resistant systems:** Thick steel or robust materials slow down the attack, making it require lots of effort to breach. Complexity or tiny size can also count to this category. The weight and bulk can be a problem or benefit, depending of the application.
- **Tamper-responding systems:** Burglar alarm approach. The defense is the detection of the intrusion, followed by a response to protect the asset. Response can be e.g. alarm or deletion of encrypted data. Good for portable systems where bulk is a disadvantage.
- **Tamper-evident systems:** If a break occurs, evidence is left behind. They don't prevent the attack. Somebody has to check for the evidence. Example: Tamper-evident tape.

# 2. Intro to Embedded Systems

## Embedded Systems Definition
> An integrated (into a higher level system) computing system performing a limited set of well defined control, regulation, and data processing tasks.

- **Constraints:** Because they perform specific tasks, they come with a limited battery, memory, etc.
- **Requirements:** Based on deployment scenario. May include:
- Acting deterministically (exactly the same each time)
- Acting in real time
- Being fault tolerant (flying drones should land in any case)

### Example: Smart Card
Used to provide authorization or identify the cardholder.

_Main Components: CPU, Coprocessors, MMU, Memory._

- **CPU:** Has many important properties to look at. RISC vs. CISC / Architecture (ARM, x86, ...) / Bit-width / Processing power
- **Coprocessors:** Smartcard-coprocessor performs mainly public- and secret-key crypto and has a RNG.
- **MMU:** Performs virtual to physical address mapping and memory isolation. Using the IP it performs memory access control. **MPU** (... protection unit) is a trimmed down version and only performs the access control part.
- **ROM:** Content is immutable and the same for each chip of the same production batch. Can only be set at manufacturing time.
- **PROM:** Can be programmed only once after manufacturing time. Made e.g. using fuses (=Sicherung).
- A fuse melts when a high current flows through it.
- **Flash or EEPROM:** Is non volatile and can be reprogrammed many times.

### Issuing a smart card

#### Production phase
During the manufacturing process the **bootloader** is burned into the ROM as well as some **general-purpose kernel routines**. ROM cells are smaller than EEPROM and permit a bigger memory capacity while being cheaper. Therefore the **operating system** is split to ROM and EEPROM.

#### Card preparation phase
After the manufacturing the smart card issuer (e.g. bank) loads the rest of the **operating system** into the EEPROM as well as **application data**. This does not include user-specific data.

#### Application preparation phase
Then only individual user data (such as user secret keys or PINs) are loaded onto the card's EEPROM.

## Integrity verification
Integrity is a prerequisite for further security goals. Therefore it has to be ensured that the system is in the required state (state = memory contents). Two options:
- Making memmory immutable
- Checking memory contents

### Secure boot
Ensures the system is started into the expected state. Every element **measures & verifies** the next component before loading and executing it. If a component fails the verification step, the boot process is aborted. The trust in secure boot is based on the trust in the RTM. The RTM cannot be verified.


### Authenticated boot
Works similar to secure boot, but **only measures** the system state. An external verifier decides on the system integrity. The checksums of all components represent the system state right after the boot process. The typical use case combines with **remote attestation**.

#### Remote attestation
_Trust Model: Small Trust Anchor & Software-Only attacks_

The state is represented via a hash of some memory region. Requirements are:
- **Authentication of Prover:** Only the trusted component has access to the Prover's key and can perform the attestation.
- **Freshness of Attestation:** Verifier has to chellange the Prover to ensure freshness.
- **Integrity of Attestation:** The complete state has to be attested + the state may not change during the attestation.

# 3. Embedded Security Architectures
The above architecture for Remote Attestation suffers from
- **TOCTOU**-Problem (Time of Check, Time of Use)

What if the Prover gets a malware infection just after it has proven its integrity?

## SMART
**SMART:** **S**ecure **M**inimal **A**rchitecture for (Establishing a Dynamic) **R**oot of **T**rust.
It aims at attacking the TOCTOU problem.

**Adversary Model:**
- Full control over software
- No invasive hardware attacks
- No side-channel attacks

**System assumptions:**
- Immutable memory
- RAM erased at reset

### The attestation
Assumptions:
- Shared key between Prover and Verifier
- Key only accessible from attestation code
- Attestation code:
- No bugs / no information leakage
- Atomic execution
- Entrance only at first address, exit at last address


1. Verifier sends attestation request`AR = [I_s, I_e, entry, flagx, nonce]`
- `[I_s, I_e]`: The code to be attested.
- `entry`: IP to be jumped to when flagx is set.
- `flagx`: Execute code after attestation?

2. RAM takes request and forwards to ROM
3. ROM disables interrupts
- Ensures code is unchaged during attestation
4. ROM computes `HASH(AR || key)`
- Only RTM has access to `key`
- MPU checks if IP only points to SMART code (so no other code gets acceess to `key`)
- Yes: Allow access to `key`
- No: Reset CPU
5. Output `HASH` to RAM and if `flagx` was set, jump to `entry`.
6. After execution of SMART code finished, enable interrupts again and send `HASH` value to verifier.

**Pros:**
- Proof of Execution
- Minimal changes to CPU/MPU

**Cons:**
- _Flexibility:_ Attestation code not updateable
- _Non interruptible execution:_ Limits scope of code to be measured. Especially in real-time systems.

## TrustLite: Security Architecture for tiny embedded devices



**Adversary Model:**
- Full control over software (except loader)
- No hardware attacks
- No hardware side-channel attacks

**System model:**
- Device Key (K~N~, shared with device owner)
- Memory-Mapped I/O for all peripheral access
- TrustLite aware Exception Engine

**Features:**
- _Generalization of Execution-Aware Memory Protection Unit (EA-MPU):_
- AC not based on privilege level. MPU knows IP and therefore directly associates data & code regions with access rights.
- Free configurable protection for memory-regions (**Trustlets**).
- No new / special CPU instructions.
- _Secure Exception Handling:_
Interruptible Trustlets with secure context saving.
- _Secure Loading:_
Secure loading of Trustlets and setup of MPU.
- _Inter Process Communication:_
Secure communication between mutually authenticated Trustlets.

### Trustlet Loading
1. **Secure Loader**, residing in the PROM, is started up.
2. Loader copies a **Trustlet** from flash memory to RAM.
3. The **Trustlet Table**, managed on the chip, is updated with the Trustlet's code start end and as well as a stack pointer.
4. Trustlet Table is mapped to memory.
5. **Repeat** step 2 - 4 for all other Trustlets. **MPU checks** that Trustlets are only loaded in permitted memory regions.
6. **MPU locks itself** into read-only mode, Trustlet Table is unmodifiable from now on.
7. **Load OS**.


### Trustlet Exception Handling
1. During Trustlet execution, **interrupt comes in**.
2. **Save state** on Trustlet Stack and **update Trustlet Table**. The context save (and following erasure) protects from malicious ISRs.
3. **Load OS Stack** Pointer.
4. **Load ISR** (Interrupt Service Routine). = Change IP to point to ISR


### Trustlet Attestation
1. **Verifer sends nonce** and the code region to verify $[C_s, C_e]$ to the device.
2. Attestation **Trustlet calculates HASH** of code region, nonce and key K~N~ $\texttt{HASH}(C_s, C_e, \textit{nonce, key})$. The key is mapped to the Trustlet but only accessible by Trustlet.
3. **Result is sent** back to Verifier.


### Pros / Cons
**Pros:**
- Flexible
- Trustlet execution is interruptible
- Protection regions freely configurable
- Update is possible
- Peripheral devices access
- Access to hardware component can be limited to certain Trustlets
- Isolation of arbitrary code

**Cons:**
- Trustlet Loader is trusted (part of TCB)
- Static allocation of code regions required for IPC (inter process communication)
- Number of allowed rules in the MPU is fixed at manufacturing time

## Comparison of Attestation Solutions

### Authentication of Prover
**SMART**
- key access exclusive to ROM-Code
- one specific execution aware MPU rule

**TrustLite**
- Key access exclusive to Attest Trustlet
- Key access restricted via IOMM (I/O memory map)
- General EA-MPU rule

### Freshness of Attestation
In SMART and Trustlite both, the Verifier challenges the Prover with a nonce.

### Integrity of Attestation
**SMART**
- On entry of ROM-code interrupts are disabled
- Platform reset on (non-maskable) interrupt

**TrustLite**
- Option 1: Interrupts disabled while Attest Trustlet executes
- Option 2: Attest Trustlet is interruptible
- Attest Trustlet state does not leak confidential information due to exception handling
- Attestation target must be immutable until attestation is complete, e.g., set MPU rules for attested code to read-only

## Misusing attestation
Since the Verifier does not have to authenticate himself, a malicous device can impose the Verifier. It can then send lots of attestation requests, resulting in **DoS**. A possible mitigation is a real-time clock in the embedded device.

# 4. Attestation architecture
Presented on the example of an Automotive Platform.

## ReCap: The Jeep Hack
1. Hackers **crack the WLAN password** because it was stupidly chosen.
2. They **find an open port** used for IPC. It didn't require authentication. Using this port they can **inject IPC messages** to control: the radio, GPS, some other systems.
3. By using specially crafted IPC messages they **reflash the CAN controller** with modified firmware.
4. Sending arbitrary CAN messages to entire car now possible.
*[CAN]: Controller Area Network

## The Attestation
**System model:**
Attestation is a protocol between a prover **P** and a verifier **V**, where P proves the integrity of its software to V.
- The verifier is a central unit and can be integrated into an existing unit (e.g. an immobilizer)
- Prover can be any embedded automotive controller. Three classes exist:
Central Computer, Control Unit, Sensor.

**Functional requirements:**
- _Availability:_ Attestation may not require too much time or resources.
- _Upgradeability_
- ...

**Security requirements:**
- _Device Identification and Authentification:_
It should be infeasible for an adversary to
- copy or forge existing device identifiers
- impersonate a genuine automotive controller

**Attestation requirements:**
- _Authentication of Prover_
- Attestation must come from the correct prover
- Mechanism: Cryptography or physical proximity
- _Freshness of Attestation_
- Attestation must reflect the current state of the prover
- Mechanism: Challenge-response with verifier chosen nonce
- _Integrity of Attestation_
- Ensure that the attestation report is generated correctly
- Mechanism: Isolated reporting component (e.g., TPM) or timing-based

**What kind of attestation do we take?**
| Attestation | Pros | Cons |
| ------------------------------------------------ | -------------------------------------- | ----------------------------------------- |
| **Software-based** | No hardware-extensions needed | Strong assumptions must hold |
| **Hardware-assisted (co-processor based, e.g. TPM)** | High flexibility | High relative cost for low-end devices |
| **Hardware-assisted (minimal security hardware)** | Strong security guarantees at low cost | Requires changes to hardware architecture |


**Protocol overview:**
1. _Device production:_ Devices are setup and certificates issued.
2. _Device integration / join:_ Exchange of public keys, shared secrets, code certificates.
3. _Device attestation:_ Attestation, session key distribution.


### Join Protocol: New device joins
A new device comes along with the following information:
- $pk_i / sk_i$: Public and Secret key pair of device $i$
- $\sigma_M(pk_i)$: Certificate of device $i$, signed by manufacturer
- $pk_M, \sigma_M(c_i)$: Public key of the manufacturer and the certified configuration $c_i$, signed by the manufacturer

Analogously the central computer has $pk_V, sk_V, \sigma_M(pk_V), pk_M$.

1. A device $D_i$ is installed.
2. $D_i$'s certified configuration $\sigma_M(c_i)$ is sent to $V$
3. Public keys and corresponding certificates are exchanged.
4. A shared secret is derived from own secret key and opposite public key.


**Component reuse:** After the shared secret is established, **$D_i$ deletes its own secret and public key pair**. It will never be able to join another car again unless it gets another pair of credentials issued by the manufacturer.

### Attestation Protocol
1. Verifier sends attestation request including a nonce $N$
2. Device $D_i$ generates a report $r_i = \texttt{HASH}(N||\textit{memory state}||k_i)$
3. Device sends back the report $r_i$ and $V$ checks the report.
4. If $r_i$ is valid, send a session key $S$ to the device, encrypted with $k_i$ $\rightarrow Enc_{k_i}(S)$

**Note:** If an attestation is done on $D_i$ and $D_j$ is in between $D_i$ and $V$, it also has to go through the protocol and receives a session key $S$.


### Authenticated Communication
1. $D_i$ creates an authenticated message ussing the session key $S$ $Auth_S(msg)=\left(\textit{msg}, \ \texttt{HASH}\left(\textit{msg }||\ S\right)\right)$
2. This message $Auth_S(msg)$ is sent to $D_j$
3. $D_j$ validates the authenticity of the message. It is only processed if it is authentic. Otherwise it's ignored.

### Conclusion
System architectures for embedded device need hardware support, TrustLite for small devices, Co-processor for high-end devices.

The attestation protocol comprises of two parts:
- Join protocol uses asymmetric cryptography $\rightarrow$ High flexibility
- Attest protocol uses symmetric cryptography $\rightarrow$ High performance

# 5. Physically Unclonable Functions (PUFs)

## Motivation
Cryptographic protocols require a) cryptographic primitives (which may be slow and cause overhead) as well as b) secure and permanent storage of the secret key. If the storage is permanent however, it may be hard to secure against physical invasive attacks.

**Case 1:** Can we eliminate the need for non-volatile storage of crypto keys? And replace it through an on-demand, instance-specific key generation scheme?

**Case 2:** Can we replace the required Crypto & key with a lightweight instance-specific function?

## PUFs
Yes we can! PUFs take an input (challenge) and generate an output (response) based on the physical characteristics of the embedding integrated circuit (IC). Behavior is **instance-specific** since it leverages process variations during ICs manufacturing. It is a **noisy function**, affected by operating conditions (i.e. supply voltage, ambient temperature).

### Properties of ideal PUFs

**Reproducibility:** With high probability, evaluating the same challenge on the same PUF instance should lead to a similar result. Reproducibility can be measured by Hamming distance $HD_{intra}(R,R')=0$

**Uniqueness:** With high probability, responses resulting from evaluating the same challenge on different PUF instances should be dissimilar. Uniqueness can also be measured by Hamming distance $HD_{inter}(R_{PUF i}, R_{PUF j})=50\%$

**Reproducibility + Uniqueness $\rightarrow$ Identifiability** This means a PUF can be identified based on its challenge-response behavior.

**Unpredictability:** Observing some responses does not give any advantage on how to guess further responses

**Physical Unclonability:** It should be infeasible to create two PUFs that exhibit similar challenge-response behavior.

**Mathematical Unclonability:** Assuming an adversary with unlimited access to a PUF instance and its CRPs (challenge-response pairs) within a _timeframe_, a PUF exhibits mathematical unclonability if it is unpredictable.
_This property extends Unpredictability to an adversary with unlimited access to a PUFs CRPs._

**Physical + Mathematical Unclonability $\rightarrow$ True Unclonability**

**Tamper Evidence:** Tampering is used to obtain information about sensitive internal values and parameters. Some PUF classes, which rely on sensitive measurements of random physical features, cannot be physically tampered with without significantly changing their challenge-response behavior.

### Case 1: Secret Key Generation & Storage
Since PUFs are **noisy** functions, they are combined with **Fuzzy Extractors**. Those consist of two components:
- **a secure sketch** that maps noisy responses (of the smame challenge) to the same value
- **a randomness extractor** to get a full-entropy string from PUF responses


During **Enrollment Phase** the PUF is challenged and its response generated. This is fowarded to the Fuzzy Extractor _FEGen_, that computes an error correction code or helper data $h$ and a uniformly distributed bitstring $K$, later to be used as key. $(c,h)$ are stored in a database for later use.

During the **Online-Phase** the Prover is deployed into the field. The Fuzzy Extractor FERep uses the previously generated helper data $h$ as well as the PUFs response $r'$ to generate a key $K$.


### Case 2: Lightweight Authentication Protocols

**Enrollment Phase** happens by a Trusted Third Party before deployment. CRPs (Challene-Response Pairs) are collected (each CRP several times) and stored to a database, which is later provided to the Verifier. A _Threshold_ is defined for when to accept the response as valid.

**Online-Phase:**
1. Verifier picks a CRP from database and sends $C_1$ it to Prover
2. PUF instance computes response $R_1=PUF_j(C_1)$ and sends it back.
3. Verifier decides: Is the response $R_1$ and the reference value $R$ within the defined threshold?
4. Verifier discards this CRP to never use it again ($\rightarrow$ Replay Attacks)


### PUF Classification

#### Based on underlying circuit

**Memory based PUFs:** Output is based on the state of memory cells after a power-cycle. _E.g.: SRAM PUF, Flip-Flop PUF, DRAM PUF._

**Delay based PUFs:** Output is determined by the faster path. _E.g.: Arbiter PUF, Feed-Forward A-PUF, XOR A-PUF, Lightweight PUF._

#### Based on Input Space
**Strong PUFS** have a very large Input-Output Space (# of different CRPs), exponential in some parameter. They are suitable for **Authentication Protocols**. Example: Arbiter PUF with $n$ swtiches has $2^n$ CRPs.

Only a few CRPs can be extracted from **Weak PUFs** (polynomial in some construction paramter). They are suitable for **Key Generation Schemes**. Example: SRAM PUF with location of memory cell as challenge and power up state as response.

### Arbiter PUF
Consists of 2 pairs of identically designed wires with the same delay except for minimal process variations. When the challenge bit is $c=0$, the impulse goes straight, otherwise it crosses alongside the switch. Those process variations decide which path is slightly shorter to travel through.



At the end there is a D-FlipFlop. **To generate an $m$-bit response**, we
- apply a single challenge to $m$ different arbiter PUF circuits.
- apply m challenges to a single arbiter PUF circuit.

**Attacks on arbiter PUFs** include
- Physical attacks (semi-invaisve / side channel). Required CRPs $\approx 10^2$
- Modeling attacks (Machine Learning). Required CRPs $\approx 10^3 - 10^6$

### SRAM based PUF
An SRAM-cell consists of two cross-coupled inverters. Before an initialization state 0 and 1 are equi-probable. Through process variations **most cells are biased** towards 1 or 0. Some cells remain meta-stable (thus take 0 or 1 with equal probability). The position of certain cell can be taken as challenge.


# 6. HW-based Mobile Platform Security
## Platform Security Architecture
**A Trusted Execution Environment (TEE)** is a secure area inside a main processor. It runs in an environment isolated from the rest of the platform environment, the **Rich Execution Environment (REE)**. It guarantees that the code and data loaded in the TEE are protected with respect to **confidentiality and integrity**.

## Mobile platform TCB
The TCB of a mobile platform is quite large. Not every part plays a role in every TEE scenario though:

- **Verification Root:** Acts as hardware Trust Anchor and contains the device manufacturer's public key.
- **Cryptographic mechanisms:** Belongs to the Code-Part of the Trust Anchor and has e.g. encryption and signature verification algorithms.
- **Volatile memory**
- **Boot sequence:** The softare to be started during the boot process.

## Scenarios possible with a TEE
1. **Platform integrity ("boot integrity"):** The hash of the boot code is verified cryptographically using the **verification root**. The measurements for authenticated boot are stored in volatile memory. The **boot sequence** part starts the boot code then.
2. **Secure Storage:** A device key (stored within TCB) is used to be able to en- and decrypt a "secure storage" on an insecure medium.
3. **Isolated Execution:** We want to execute an application (**TA = Trusted Application**) in this trusted environment. Before doing that the TA's code hash is checked against a reference value using the key in **verification root**. The TEE management contols the TA execution.
4. **Device Identification:** A device has one **base entity** and possibly more **assigned identity**s (assigned by manufacturer).
5. **Device Authentication** (and Remote Attestation): A device certificate, issued by the manufacturer, exists that can be used for remote attestation and authentication. The system state is stored in volatile memory for this and then checked by a Verifier.


Real systems with single or multiple TEEs are e.g. ARM TrustZone or Intel SGX.

The extent of integration of a TEE into the processor can vary from technology to technology. While **TPM**s or **SmartCard**s are a form of external TEE, systems like ARM TrustZone are tightly integrated, even into the peripherals.


## ARM TrustZone
In ARM TrustZone every memory controller in the chip has prepended **access control hardware**. A **Trusted OS** controls the **TA**s in the Secure World (SW). Since the SW mirrors the Normal World (NW), User mode and Privileged mode both exist in the SW.

### TrustZone Example
1. **Boot begins** in SW Supervisor mode.
2. **Copy code and keys** from on-chip ROM to on-chip RAM.
3. Configure the access controller to **protect on chip memory** (making ROM not accessible, neither to SW nor to NW)
4. Prepare for NW boot (**load bootloader into off-chip RAM**)
5. **Switch to NW Supervisor** for traditional boot
6. **Set up TA execution** (isolated from normal execution)
7. **Execute TA** by switching to SW. The TA has access to (insecure) off-chip RAM and (secure) on-chip RAM.

> Eventuelles TODO: Go through summaries and Strg+F for TEE

# 7. Run-time Attacks and Defenses
Problem roots are:
1. A programming error leads to a program-flow deviation
2. Missing bounds-checking (in languages like C, C++ or assembler)

## Basics
Code consists of **Basic Blocks (BBL)**. Every BBL has an entry and an exit. An adversary may try to inject code into the program and change a code pointer to point to this malicious code. This doesn't work in today's systems because of **Data Execution Prevention (DEP)**. What works is to change code pointers such that code is executed that is already marked as executable.

**Code-injection vs. code-reuse:** In code-injection attacks the adversary adds a new node to the CFG, thereby being able to execute arbitrary code. In code-reuse attacks the adversary is limited to the nodes that exist in the CFG. He can, however, change the execution flow between those nodes. it requires reverse-engineering and static analysis of the code base of the program.

## Return-into-libc
That's what it started with. Aim is to redirect execution to functions in shared libraries, e.g. system("/bin/sh"), exit(). How it works:

1. Set environment variable $SHELL, that contains e.g. "/bin/sh"-String.
2. Produce buffer overflow that overwrites:
- local parameters and %ebp: with anything
- the return adress: with the address of `system()`-function
- thereafter: address of `exit()`-function.
- thereafter: address of $SHELL to give as parameter to `system()`
To sum it up:
gets replaced by
3. Current function jumps back to `system()` because it should be the return address. It executes system() and therefore saves the current %ebp where the pointer to `system()` was. The current function looks for parameters - as always - on the stack at `%ebp - 8`, where it finds the address of $SHELL. (We overwrote the base pointer. Within the current function a trash ebp is popped. Luckily we start system directly. At the beginning of system _push %ebp_ and then _mov %ebp, %esp_ is done. This produces a working %ebp).
4. After doing in the called shell what we want, the program jumps to `exit()`, terminating our exploit cleanly without a segfault.

**Limitations:**
- No branching possible: No execution of arbitrary code
- Critical functions can be eliminated or wrapped

## Return Oriented Programming
To mitigate the limitations we generalize the return-to-libc attack. We use _small instruction sequences_ with a length of 2-5. All sequences _end with a return instruction or an indirect jump/call_. Instruction sequences are chained together as gadgets, which perform a particular task like load/store xor or branch. Attacks are launched by combining gadgets. ROP has been shown to be Turing-complete.
- `%esp` acts like the instruction pointer
- Since every gadget ends with `ret`, the control flow looks up on the stack what the return address is, where we find the address of our next gadget.
- In this case we write code a little differently, using `pop` to pass arguments into registers and just writing return addresses along with values on the stack as _"code"_.


## Defenses
**Protection Techniques:**
1. Memory is either writeable **or** executable (DEP)
2. Opaque memory layout (ASLR)

However they can be circumvented (Disclose readable memory, manipulate writeable memory, computing engine).

**Main Defenses** against Code-reuse attacks are
1. Code Randomization
2. Control-Flow Integrity (CFI)

| Randomization | CFI |
| ---------------------------------------- | ----------------------------------------------------- |
| + Low performance overhead | + Formal security (Explicit Control Flow Checks) |
| + Scales well to complex software | - Tradeoff: Perforamance & Security |
| - Information Disclosure hard to prevent | - Challenging to integrate in complex software |

**How to implement the defenses?**
- **Binary instrumentation:** Defense might be incomplete because binary analysis is limited.
- **Compiler extensions:** Requires recompilation of applications (legacy ones stay vulnerable)
- **Code annotations:** Developers are no security experts. They might hack around it or not use them.
- **New languages:** Lack of trained developers. Will they still exist in 5-10 years?

### Code Randomization
Idea: Make gadget locations unpredictable.

Different approaches on **how fine-grained to make the ASLR** exist:
- Instruction reordering/substitution within a basic block
- Randomizing **each** instruction‘s location
- Permutation of basic blocks

However the **Memory Leakage Problem** is not to be underestimated. The memory layout can be guessed from direct leaks (pointer leakage on code-pages, e.g. unconditional jump instruction) and indirect leaks (pointer leakage on data-pages, e.g. return addresses, function pointers, ...).

Once one pointer leaks, the borders of the 4KB aligned page can be found. This page can be disassembled and then searched for more references to other pages.


#### Attack timeline

1. **Return-to-libc attack:** As explained before.
**Mitigation:** (Fine-grained) ASLR.
2. **Just in time (JIT) ROP:** Create mapping of memory on the fly while just in time compiling shellcode using found gadgets.
**Mitigation:** Execute Only Memory (XOM). Memory that can be executed but not fetched to be read.
3. **Isomeron attack:** Using indirect memory disclosure: Exploit the code pointers that are stored on the stack and heap to perform a JIT ROP attack.
**Mitigation:** Code-pointer hiding. Only pointers to jump trampolines may be leaked. Their content however is randomized.
>4. **Trampoline Reuse Attack**: Attacker tries with Trial-Errors to get correct address from Trampoline
>=> **Mitigation**: Register Randomization (still researched)
>5. **Function Reuse Attacks** e.g Counterfeit Object Oriented Programming Attack (COOP)
>=> **Mitigation**: `Trampolines & Booty Traps` with virtual Return Address.
> - Booby Trap in `X-Virtual Table` catches Attacker
> - Paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.718.1439&rep=rep1&type=pdf
> [name=Bi]
...
> Rest of attack history left out for time reasons (Slide 96 - 117)

### Control-Flow Integrity
The **Original CFI Label Checking** follows the approach to define labels for every branch and remember which labels should follow which instruction. At every jump instruction those flows are checked. If jump address differs, abort.

**Which instructions to protect?**
- **Returns:** Because return address is located on stack.
- **Indirect jumps/calls:** Because target address to jump/call is taken from processor register or memory.

The biggest challenges are **Performance** and **CFG Analysis and Coverage**.

**Label Granularity** is not trivial to chose. If every Basic Block gets its own label, lots of labels are needed. Labels can therefore be merged. This may allow for unintended control-flow paths though.

#### Problems with Returns
It is hard to handle labels for return statements since it's not decidable by label where control flow should jump back to.


This can be solved using a **shadow-stack**. This stack keeps track of the address that was jumped from (while traversing the CFG). The only con is: higher overhead.

Some CFI schmes only consider **forward-edge CFI** and assume that **backward-edge CFI** is guaranteed through stack protection mechanisms. This is not always the case though. Using a shadow-stack guarantees backward-edge protection.

#### Detecting Runtime Attacks
Detecting runtime attacks cannot be achieved by static attestation alone. An attestation should caputure and report the dynamic state of a program.

An approach is called **C-FLAT**. In the **Offline-Phase** the Verifier computes a CFG of the application and measures every allowed path, aggregating measurements in a hash chain. In the **Online-Phase**, initiated by the Verifier, the Prover measurees its Path through the CFG and transmits this hash. This is compared by the Verifier against all legitimate values.

# 8. IoT Malware
IoT Malware propagates itself by infecting reachable (nearby) devices. Through bluetooth e.g. this may even apply to devices that are not connected to the internet. The propagation may thus be exponential. DDoS attacks are dangerous using large botnets because of their large bandwidth.

**Why does malware target IoT?**
- Security vulnerabilities
- Weak credentials. No enforcement of credential change.
- Poor network management
- Always online

**Attack structure and Motivation.** 4 Typical Attack stages exist:
1. Scanning for vulnerable IoT devices
2. Infecting the vulnerable devices
3. Standby. Meanwhile goto 1.
4. Monetization. Potential aims are:
- Sell botnets for a fee
- Create threats and sell security solutions
- Attack competitors

## The Mirai Botnet
A botnet that infected typical IoT devices by actively scanning the network and propagating to any vulnerable devices it found. It was used in the largest DDoS attack in history. It has **two phases**: **Infection** and **Attack**.

### The infection process
1. Already infected device scans for vulnerable device
2. If found, it reports a vulnerable IP to the **report server**
3. **Report server** contacts the **loader server** which then loads the malware onto the found device. Afterwards the device is recruited.
4. Recruited devices wait for a command from the **CNC server** until they act and attack a target. The attacker commands the CNC server.


- It infected devices by trying a list of default credentials.
- After the infection, the open port was closed to prevent access of other Mirai instance or other malware.
- The upload itself was possible using three different methods: echo / wget / tftp.

### Mirai variants
- **Hajime**. Used a decentralized infrastructure to distribute commands via peer-to-peer network.
- **Persirai**. Attacked IP cameras using 3 CVEs. Did not need to know / brute-force credentials.
- **BrickerBot**. Uses Tor to hide the attacker IP. Makes device unusable. Same attack vector as Mirai (standard credentials)

## Defense mechanisms
**Mitigation:**
- Limit exposure to external adversaries
- Use of Firewalls and NAT
- Close not needed ports
- Ensure proper security configurations
- No standard credentials
- Apply security patches

**Detection:**
IDS = Intrusion Detection System. Different types of IDS are available. **Signature-based IDS** monitor system behavior and look for known attack patterns. It is reliable but can only detect already know attacks. It also has significant delays because of the large signature database. **Anomaly-based IDS** look out for behavior that deviates from normal behavior and can therefore also detect unknown attacks. However it has also more false positives because of this.

**Recovery:**
- **Network Isolation** is applied. The device is separated from the rest of the network to prevent further infections (through traffic filtering rules e.g.).
- A **Device Reset** is then conducted to remove the malware. A software patch is needed to ensure the removal.

### Anomaly based IDS for IoT
Models are trained to recognize "normal" behavior. A frontier is then chosen. Every behavior lying outside of that frontier is categorized as anormal behavior.


Examples for **normal behavior** are:
- Connect to the vendor server
- Access via app
- Access via web interface

whereas **anormal behavior** is:
- Connect to the attacker
- Scan other devices
- Perform a DDoS attack

The **features for distiguishing** both forms are:
- Packet properties: protocols, port types, length
- Packet sequence
- Traffic rate and intervals between packets

### Device-type specific anomaly detection DIoT
Works on the **assumption** that before an adversary infected a device it was shipped with a working installation. Therefore we try to detect the behavioral change of the IoT device.


1. **Local Fingerprinting** of a well-functioning device, just after installation by a security gateway.
2. Send the fingerprint to an IoT Security Service Provider that identifies the device.
3. The provider returns a **device-type specific profile** which is basically a RNN trained for this device.
4. The local gateway performs **local anomaly-checks using the returned data**

**RNNs (Recurrent Neural Networks):**
- Example use cases: Text prediction and correction
- Idea: Network packet sequences are nothing else

1. Model is trained with training data: A normal packet sequence.
2. Model is used to categorize packet sequences as normal or deviating behavior


# 10.1 Security of communication protocols used by Embedded Systems
Lots of IoT don't use WiFi because it consumes too much energy and they do not generate that much traffic.

## ZigBee Overview
Is a communication standard for sensor wireless personal area networks (sensor WPANs) that uses IEEE 802.15.4 and is low-cost, low-power and low-bandwidth. Some data:
- 10 - 100m range
- Bands: 2 bands around 900MHz and the 2.4GHz band
- Device roles: Coordinator / Router / End Device
- Topologies: Star / Mesh / Tree
- Different (Energy) profiles: Home automation, light link, green power

**Architecture:**
- PHY: Modulation / Demodulation
- MAC: reliable point to point transmission using CSMA with transmitting beacons
- NWS: Routing, network setup, device (dis-)connection, peer-to-peer multihop
- APS: Services and addressing objects
- SSP: Key management generation
- ZDO: device discovery, network management


**The Roles**
- **Coordinator:** Exactly one, sets up network, defines TrustCenter (key distributor), always awake
- **Router:** Forwards packets, can include/exclude devices, can double as End Device, always awake
- **End Device:** Application runs on this device (e.g. data collecting sensor), can sleep

Different **topologies** are possible but all quite intuitive:


## ZigBee Security
Different profiles have different security specifications which means a **power - security trade off**. Ultra-low power devices cannot receive packets $\rightarrow$ no challenge response or key agreement possible.

For **Confidentiality and Integrity** AES-CTR 128bit is used. The ciphertext is sent along with a MIC (message integirty code) with is essentially a CBC-MAC. Different **security levels** exist that define the length of the MIC as well if encryption has to be used. The security levels also depend on the used profile.

### Key types
Depending on the profile, different key types exist. A central key is the **Network Key**. It is identical for all devices and exchanged at network initialization time. Key exchange schemes as well as pre-defined keys exist.

> Specific key types as well as the key exchange have been omitted

**Firmware updates** can be protected cryptographically but are not part of the specification and therefore manufacturer specific.

## ZigBee in practical Applications
- Some pre-shared keys are shared among manufacturers for interoperability reasons. **Problem:** When using key-exchange, the PSK is a single point of failure.
- TouchLink tries to mitigate this by exchanging keys only with reduced power
- If the PSK key of **any** device is leaked, an attacker can listen to **every** key exchange.

### Attack scenarios
- **Malicious firmware updates:** On devices that use non integrity-protected firmware updates, a malicous update can read information and change the device's behavior.
- The **key exchange using default keys** can be exploited by sniffing and decryption. Therefore anyone can join in such networks.
- **Hardware attacks** are possible on chips without memory protection bit set (memory can be dumped over debug interface).
- **Side-channel attacks** are possible on chips without special protection against it.

While some vendors do a good job when it comes to security (e.g. disable debug access to the EEPROM where the keys are stored: Philips), some just don't care and don't even use the provided measures: Osram, Innr, Ikea, Wemo. Real world attacks include e.g.
- Reconstructing a PSK using power analysis. Using this key to flash the firmware.

**So why do manufacturers use PSKs?**
Because it is convenient - for the user and for the manufacturer. A right balance has to be found. Key management is challenging!

# 10.2 Security in real world embedded System implementations
on the example of a fitness tracker.

A typical fitness tracker has lots of sensors:
Relative Humidity, **Temperature**, User button, Accelerometer, Gyroscope, Light Sensor, Pressure Sensor.

Those sensor collect lots of data that **can be misused** in different cases:
- Hiring/firing decitions
- Legal evidence
- Website customer profiling

A **typtical fitness tracker system** consists of a wearable, a companion app and a cloud service. They communicate using a low power protocol on the frontend (that uses link-level encryption).


## Attacks
What if the device owner is the adversary?

_The device owner could open a MITM proxy to analyse and modify data in transit between app and cloud service._

Using the MITM proxy the protocol was reverse engineered. Afterwards **Impersonation attacks** are possible (where the MITM exchanges the device-id for another) as well as **Fake activity data updates** (where the MITM exchanges data values).

Remote checksums may be computed by the adversary though. They might have to match for the faka data update to work.

**Hardware attacks** are also thinkable. In the slides the device was opened and searched for debug ports. In the end they could attack a JTAG bus, retrieve the encryption key and change the memory.

###### tags: `2019` `Zusammenfassung` `ESS` `recap` `embedded` `security` `TU Darmstadt`

_Proud author of this recap: B.M._