## Trusted Execution

### Intel SGX
- Intel Software Guard Extensions
	- Extension of x86 instruction set (Skylake architecture)
	- Allows isolation of code (*enclave*)
	- Used to isolate sensitive code
	- Requires trust Intel and the CPU
- Use Cases
	- Developer does not trust system provider
		- e.g., server host
		- Store keys/personal data inside enclave
	- Remote party does not trust me
		- Software hiding secrets
		- Rights management
		- e.g., use feature X k times
- Features
	- Trusted execution
	- Memory encryption
	- Integrity checks
	- Change attacker model (towards physical attacker)

#### Architecture
- *Enclave*
	- Part of normal application (less privileged)
	- All memory is encrypted
	- Integrity is verified
	- Run in user-space (create in kernel-space)
	- No system calls allowed
	- No direct communication with enclave (use well-defined end-points, i.e., ecalls/ocalls)
- *Enclave Page Cache* (EPC)
	- Integrity protected using hash tree
		- Root hash inside CPU package
		- Every access checks tree
	- Swapping possible
		- Requires EPC table for information of swapped tables
		- Can be recursive
		- High cost
- *Enclave Page Cache Map* (EPCM)
	- Keeps track of all pages in EPC
	- Only one
	- EPCM size determines EPC (EPCM has all pages)
	- 188 MiB
	- Information:
		- Permissions of page
		- Page type
		- Is page mapped?
- *SGX Enclave Control Structure* (SECS)
	- One per enclave
	- Hold enclave metadata (e.g., size, hash)
	- Only accessible from CPU itself
	- Immutable
- *Thread Control Structure* (TCS)
	- Describe entry point into enclave
	- One TCS per enclave thread
	- Inaccessible from outside
	- Immutable
	- References at least one State Save Area
- *State Save Area* (SSA)
	- Save processor state (during interrupts)
	- At least one per TCS required (multiple interrupts mean multiple SSAs)
	- Write on interrupt
	- Read on resume
- Stack/Heap
	- SGX does not enforce enclave stack/head (**but recommended**)
- Code/data
	- Encrypted after enclave creation (but integrity checked)
	- Inject secrets later (enclave has not secrets at startup)

![](images/sgx-epcm.png)
#### Attestation & Sealing

##### Enclave Measurement
- Use for integrity protection
- Enclave has unique hash (comprised of pages and their layout)
- Identical measurements iff enclaves identical
- `MRENCLAVE` call

![](images/sgx-measurement.png)
##### Attestation
- Purpose: Prove that they are *the* enclaves
- Allowing for secure communication
- Types
	- Local: Between two enclaves
	- Remove: Between enclave and remote party
- Local attestation
	- Scenario: Enclave A and B want to identify identity to each other
	- Report
		- Enclave can generate report with HMAC from processor (`EREPORT`)
		- Generated for specific target enclave
		- May have payload (e.g., nonce, public key)
	- Result: *Secure channel between enclaves* **Is this a result???**
	- Example
		- Alice sends MRENCLAVE to Bob
		- Bob creates report with Alice's MRENCLAVE
		- Bob sends report to Alice
		- Alice verifies receive report (with EGETKEY)
		- Repeat 
- Remote attestation
	- *Quoting enclave*: 
		- Special enclave
		- Signed by Intel
		- Generates a *quote* from a report
	- Workflow
		- Alice does local attestation with QE
			- Send MRENCLAVE
			- QE generates report
			- QE sends quote to Alice
		- Alice sends quote to Bob
		- Bob asks Intel Attestation Service (IAS) for verirication
	- Result: *Secure channel between enclave and remote party* **Is this a result???**

![](images/sgx-local.png)
![](images/sgx-remote.png)
##### Sealing
- Store data securely and persistently
- Workflow
	- Enclave generates key
		- Depends on platform
		- `EGETKEY`:
			- `MRENCLAVE`: Key tied to enclave memory structure
			- `MRSIGNET`: Key tied to enclave signing key (allows for enclave updates)
	- Encrypt data
	- Give data to untrusted system to store (contradictory)

#### Development
- Instruction set overview:
	- Kernel-mode:
		- `ECREATE`: Start creation
		- `EADD`: Add page during creation
		- `EEXTEND`: Calculate hash sum of added page
		- `EINIT`: Finalize creation
	- User-mode:
		- `EENTER`
		- `EEXIT`
		- `ERESUME`
- Compilation
	- Enclave must be self-contained
		- Statically linked
		- Non system calls (use compiler flags)
	- Requires `SIGSTRUCT` and `EINITTOKEN` (signed by processor)
	- Use SGX
- Interrupts
	- Transparent to enclave
	- Generate *Asynchronous Enclave Exits* (AEX)
	- Register an *asynchronous exit handler* (AEP) (on enter)
		- Call AEP every AEX (same on exceptions/faults)
		- AEP decides whether to resume or not
- SDK
	- Library for enclaves
	- SDK has simulation mode
	- Defne ECALLs and OCALLs

![](images/sgx-ssa.png)
![](images/sgx-edl.png)
![](images/sgx-call.png)


#### Attacks
- Against SGX
	- Rollback attack against swapped pages: NO (EPC version is tracked)
	- Rowhammer on EPC:
		- Rowhammer: Periodically swap memory to change nearby bits due to electrical fields
		- NO: Pages are hashed
		- YES: *SGX-Bomb: Lock processor down*
	- Bugs in SGX specification: MAYBE
	- Bugs in SGX implementation: MAYBE/YES
	- Break Management Engine: MAYBE (not proven)
- Against Enclave
	- Rollback attack against sealed data: YES/MAYBE (enclave provides backwards compatibility, use legacy data)
	- Iago attack: MAYBE/YES (depends on app)
	- TOCTTOU attack: MAYBE/YES (depends on app)
- Against SDK
	- TOCTTOU attack: NO/MAYBE
		- SGX copies arguments
		- Does not deep-copy structures
- Side channel against SGX/SDK
	- *Side-channel attack*: Exploit physical implementation of crypto system
	- Spectre: Read virtual memory by exploiting execution order
	- Foreshadow: Extract keys
	- ZombieLoad: Read virtual memory from other processes running on the same core
	- Plundervolt: Control voltage and frequency to corrupt SGX integrity
- Side channel against Enclave
	- Depends on implementation
	- AsyncShock: Exploit synchronization bugs
	- Controlled-Channel attack
	- Steal page tables
	- Infer control flow


### AMD SME/SEV
- Problem Cloud computing:
	- Applications are usually VMs
	- Hypervisor as access to all sensitive data
	- Hypervisor isolation can have faults
	- User must trust cloud provider
- Attacks
	- Admin reads memory of VM data
	- Admin injects code into VM
	- User steals data using hypervisor bug
	- Install malicious hardware
	- Freeze and steal RAM
	- Steal non-volatile RAM
- Components
	- Hardware encryption module
	- Secure processor
- Summary
	- Easy full-memory encryption
	- Guard against physical attacks
	- SEV does not protect against malicious hypervisor

#### Hardware encryption module
- AES engine
- Part of memory controller
- Key located inside CPU (isolated)
- Encrypt DRAM
- Minimal performance overhead

#### Secure processor
- Dedicated security subsystem (SoC)
- Non-volatile storage
	- Off-chip
	- Secure
	- Stores firmware + data
- Provide key generation
- Enables secure boot (chain/root of trust)

#### Secure Memory Encryption (SME)
- Simple and efficient encryption
- Defend against physical memory attacks
- Use single key for encryption
- OS/Hypervisor choose pages to encrypt

#### Secure Encrypted Virtualization (SEV)
- Provide secure, encrypted virtual machines
- Combine SME and AMD-V virtualization
- Protect VMs/Containers from each other and untrusted hypervisors
- Keys
	- One for Hypervisor
	- One per VM
	- Cryptographically isolates hypervisor from guest VM
- Requires AMV-V technology
- Key management (launch guest VM)
	- Hypervisor load BIOS/OS into DRAM (not encrypted)
	- Hypervisor and user exchange keys (DH, AMD Secure processor)
	- Hypervisor prepares BIOS/OS image
		- Allocate address space identified (ASID)
		- Generate encryption key
		- Firmware encrypts image
	- Hypervisor creates Control Block for VM
	- Hypervisor sends authentication information to user 
	- User supplies disk decryption key to guest VM via secure channel
- Details
	- ASID determines encryption key
	- DMA must occur to shared pages

![](images/sev.png)
#### SME/SEV Interaction
- Host mode (ASID=0): Host C-bit determine encryption status of page
- Guest mode, non-SEV guest: NPT determines encryption status
- Guest mode, SEV guest: Consult guest and NPT

![](images/sme-sev.png)
#### Software
- AMD
	- Currently developing
	- Secure Processor code not public
	- Linux driver for Hypervisor and AMD Secure processor communication is open source
	- Linux kernel supports SME/SEV
	- AMD Secure Processor driver:
		- Marshal between Hypervisor and processor interface
- Linux changes for SME
	- Setup: Boot unencrypted, encrypt kernel, enable encryption
	- Runtime: Set C-bit on all new pages
	- Exceptions: ???
- Linux changes for SEV
	- Pages are encrypted by default
	- ???