Please enable JavaScript.

Coggle requires JavaScript to display documents.

ESS (ARM (Features (16 registers, that are all directly accessible (r0 to…

- - - - ARM (32 Bit)
        
        traditional instruction set
      - THUMB (16 Bit)
        
        for devices that provide limited memory space
      - processor can exchange instruction sets on the fly
      - both instruction sets may occur in one program
    - - instruction destination, source, source
      - e.g. ADD r0,r1,r2 => r0 = r1 + r2
    - - r0 - r3: function args and results (caller-save)
      - r4 - r11: register vars (callee-save)
      - r12: Intra Procedure Call Register
        (used for long jumps)
      - r13: Stack Pointer
      - r14: Link register (return address)
      - r15: Program counter
  - - - BL addr
        (Branch with Link)
        
        branches to addr
        
        stores the return address in the link register
        
        return address directly follows BL instruction
      - BLX addr|reg
        (Branch with Link and eXchange instruction set)
        
        branches to to addr|reg
        
        stores the return address in the link register
        
        allows exchange between ARM/THUML
        (LSB=1: ARM->THUMB)
    - - BX lr
        (Branch with eXchange instruction set)
        
        branches to the return address in the link register
        
        register based return for leaf functions
      - POP {pc}
        
        Pops top of the stack into the program counter
        
        stack based return for non-leaf functions
  - - - 1) Boot begins in Secure World supervisor mode (set access control)
      - 2) Copy code and keys from on-chip ROM to on-chip RAM
      - 3) Configure address controller (protect on-chip memory)
      - 4) Prepare for Normal World Boot (copy Boot Loader code into main memory)
      - 5) Jump to Normal World supervisor for traditional boot
      - 6) Set up trusted application execution
      - 7) Execute trusted application
- - - - Integrity measurements
        
        1) RTM measure entity E
        
        2) RTM creates event structure in event log
        
        Event Log
        
        contains Event Structures for all measurements extended to the SM (Security Module)
        
        can be stored on (untrusted) storage device
        
        Event Structure
        
        Extended Value (hash digest of E)
        
        Extended Data (information about E)
        
        3) RTM extends measurement value into SM registers
        
        4) RTM executes/passes control to entity E
      - Root of Trust for Measurement (RTM)
        
        Entity E0
        
        must be trusted, no mechanism to measure E0
        
        immutable portion of trusted platform's initialization code, executed on every platform boot
      - What is needed to trust the chain?
        
        identity of each entity in the chain
        
        identity = measurement (according to TCG), e.g. hash digest of the binary code of the entity
        
        generic flow: : Each Ei measures Ei+1 before passing control to it
    - - Entities E0,..,En
      - Goal is to gain trust in entity En
      - Transitive trust from E0 to E1 to E2 ...
      - Trusting E2 requires to trust E0 and E1, but trusting E0 does not imply that ones trusts E2
  - - - How to define "trustworthiness"?
      - How to determine/verify trustworthiness?
      - How could common computing platforms support such functionality?
    - - Increasing threats for IT systems
      - Inflexibility of traditional secure system
      - Improve security of existing IT systems and infrastructures
      - Enable new applications with sophisticated (security) requirements
    - - Secure
        
        System or component will not fail with respect to security goals
      - Trusted
        
        System or component whose failure can break the (security) policy (Trusted Computing Base, TCB)
      - Trustworthy
        
        Degree to which behavior of a component or system is demonstrably compliant with its stated functionality
    - - Improve security of (existing) computing platforms
      - Reuse existing modules (GUI, common OS,..)
      - Applicable to different operating systems (no monopoly, room for innovation)
      - Open architecture (use of open standards + OSS, trustworthiness, costs, reliability, compatibility)
      - Efficient portability
      - New applications/business models (providing security for underlying applications)
      - Avoid potential misuse of trusted computing
    - - Metric for code configuration/identity
        
        I/O behavior of machine determined by its code
        
        Example of simple metric: Hash value of binary code
      - Integrity verification (Attestation)
        
        Allows computing platform to export verifiable info about its properties (e.g. identity and initial state)
        
        Comes from the requirement of assuring the code config and execution environment of an application located on a remote computing platform
      - Secure storage
        
        Securely stores data on untrusted storage
        
        Encrypts data and assures that no other entity can decrypt it
      - Strong process isolation
        
        Assures process (memory space) separation
        
        Prevents a process from reading or modifying the memory used my another process
      - Secure I/O
        
        Allows applications to assure the endpoints of input and output operations
        
        Assures to the user that he securely interacts with the intended application
    - - hardware
        
        even a secure OS cannot verify its own integrity (another part is needed)
        
        secure storage (e.g. for keys)
        
        isolation of security-critical programs (e.g. by DMA control)
        
        hardware based random numbers (fundamental to crypto)
      - Software
        
        Hardening (still too large+complex TCB (Trusted Computing Base)
        
        Complete new design (compatibility problems, low market acceptance)
        
        Secure virtual machine monitors (allows reuse of legacy software)
  - - - Trusted Computing base (TCB) should be minimized
      - Compatibility of commodity systems
  - - - provides a set of immutable crypto and security functions
    - - issues low-level TPM requests and receives low-level TPM responses of behalf of higher-level applications
  - - - Trusted Platform P
        
        Host H (untrusted) (Firmware, OS,..)
        
        Attestor A (Trusted component, securely stores CH)
      - CH (initial configuration)
      - User / Adversary
      - Verifier V
        
        can decide whether CH violates its security requirements
        
        can bind/seal data D to a specific (probably secure) configuration/state o
      - Data D
        
        data to be revealed only if host H is in the (secure) config CH
    - - 1) User initializes P with CH (insecure channel)
      - 2) Attestor executes CH on Host
      - 3) Attest(Hash(CH)) from A to V (Verify system integrity)
      - 4) Bind(Hash(CH), D) from V to A (Access control depending on system config)
      - 5) A passes data D to H
- - - - Random Challenge from Verifier
      - Software Fingerprint (checksum of memory content of prover)
      - Compare with reference fingerprint
      - Did prover respond in time?
    - - Authentic channel between prover and verifier
        
        no crypto authentication due to compromise
        
        no hardware security module available
        
        no actual remote attestation
      - Hardware manipulation
        
        simple overclocking or memory upgrades can enable prover to forge checksum
      - Collusion attack to forge checksum
        
        prover can ask adversary to help computing checksum
  - - - prover identity is provided by unique PUF (PUF must be hard to copy/simulate, e.g. Controlled-PUF)
      - Hard to manipulate (No secure co-processor or secure key storage, only PUF, PUF can protect other components)
      - Limit network interface speed prevents collusion (in each iteration do more I/O between CPU/PUF than could have been transmitted via network)
    - - Physically uncloneable: It is infeasible to generate a physical copy of a PUF
      - Unpredictability: It is infeasible to predict PUF responses
      - Tamper-evidence: It is infeasible to physically analyze the PUF without modifying it
  - - - full control over software
      - no invasive hardware attacks
      - no side-channel attacks
    - - immutable memory (ROM)
      - memory (RAM) erased at reset
    - - Input
        
        LS (Start of attested code)
        
        LE (End of attested code)
        
        entry
        
        entry point to attested code
        
        flagX
        
        measured
        
        n
        
        nonce
      - Start SMART attestation
        Execution is non-interruptible (interrupts are disabled)
      - HMAC of code section and parameters (authenticated with key)
      - Check for valid key access: instruction pointer is in smart code? If false, reset system
      - Result (HASH) is written to RAM
      - Remove all intermediate values (to prevent information leakage)
      - Start execution of attested code
      - When attested code is finished re-enable interrupts and return to untrusted software
      - Send HASH value to verifier
    - - no bugs / no information leakage (static analysis)
      - atomic execution (attestation code and attested code)
      - entrance only at first address, exit only at last address (code reuse attack)
    - - Prove of Execution (execution of attested code is triggered after SMART)
      - minimal changes to CPU/MCU
    - - limited flexibility (attestation code not changeable/updateable)
      - non-interruptible execution / reset on violation
        (limits scope of measured code, limited runtime for measured code in real-time systems)
      - formal verification of SMART code required (not available yet)
  - - - Device key (shared with device owner)
      - memory mapped I/O for all peripheral access
      - TrustLite aware execution engine
    - - Secure Exception Handling
        
        Interruptible TrustLets with secure context saving
      - Secure Loading
        
        secure loading of Trustlets and setup of MPU
      - Inter Process Communication (IPC)
        
        secure ipc between mutually authenticated Trustlets with one-round handshake
      - Implementation and Evaluation
        
        hardware consumption comparison
        
        hardware cost scaling with protections region count
    - - Trustlet loader is started at boot time
        Loader is stored in immutable memory
      - TrustLet 1 is loaded into memory
      - Protection is activated for Trustlet 1
      - Further Trustlets are loaded and protected
        (Meta data saved in Trustlet Table, mapped into memory)
      - MPU configuration itself gets protected
        (immutable until system reboot)
      - Untrusted OS is started
    - - Interrupt while Trustlet is exeuted
      - State saved on Trustlet stack
      - Update Trustlet table
      - Load OS stack
      - load interrupt service routine
    - - Verifier send nonce to the device
      - Attestation trustlet calculates HASH over code region, the nonce and the key (only accessible by the Attest TL)
      - Result is send to verifier
    - - Flexible (interruptible, protection region freely configurable)
      - Update is possible
      - peripheral device access (access to hardware components can be limited to certain trustlets)
      - isolation of arbitrary code
    - - TCB contains Trustlet loader
      - static trustlet code region allocation required for IPC
    - - Free configurable protection regions (Trustlets)
      - no new/special CPU instructions
    - - full control over software
      - no invasive hardware attacks
      - no side-channel attacks
  - - - state is content of the memory
      - represented via HASH of the memory content
    - - Authentication of Prover
        
        Attestation must be done by trusted component of prover
        
        trusted component has exclusive access to key
      - Freshness of Attestation
        
        verifier challenges prover on every attestation to ensure freshness
      - Integrity of Attestation
        
        complete state must be attested
        
        state must not change will attestation
- - - - Attacking one row, by using upper and lower row as aggressor (more bit flips)
    - - Google's Native Client (NaCl) limits indirect jumps to target a 32-Bit aligned address inside the sandbox
      - Modifying jump register by rowhammer => unaligned jump
    - - Spray the memory with page table entries (PTE)
      - Launch rowhammer to corrupt a PTE
      - PTE corruption can allow privilege escalation
    - - Aggressor rows attack multiple rows at once (less bit flips)
  - - - Cached memory access
      - Non-temporal memory access (write combining buffers)
    - - increasing refresh rate has been shown to be ineffective (64ms -> 32ms)
      - Further increasing the refresh rate comes with additional cost (power, throughput)
    - - Limited effectiveness
    - - Utilize performance counters of the CPU to detect a high cache-miss rate
      - Find and refresh victim rows to prevent bit flips
      - Disadvantage:
        Heuristic-based approach, suffers from false positives
    - - Identify vulnerable memory cells and disable vulnerable rows at boot-time
      - Challenges
        
        Coverage
        
        Precision of rowhammer testing tool
        
        memory overhead for other systems than our test system unclear
    - - Implementation details
        
        Mapping physical pages to domains
        
        Tracking security domains
        
        Modifying the physical page allocator
      - separate security domains physically
        
        attacker can still flip bits, but only in their security domain
- - - - Minimal hardware extensions (e.g. SMART or TrustLite)
    - - minor hardware extension (TrustLite or TyTAN)
    - - co-processor based (TPM)
  - - - Availability
      - Low Overhead
      - Accountability
      - Upgradeability
      - Vehicle Binding
      - Backwards Compatibility
      - Anti-counterfeiting
      - Migratability
      - Extendability
    - - Device Identification
      - Device Authentication
      - Software Integrity
      - Hardware Integrity
      - Version Rollback Protection
      - Secure Storage
    - - Authentication of Prover / Report
        
        Attestation must come from correct prover
        
        Mechanism: Crypto (MAC/signature) 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 attestation record is generated correctly
        
        Mechanism: Isolated reporting component (e.g. TPM) or timing-based
  - - - Join Protocol
        
        Component Reuse
        
        Device and verifier have established a shared secret
        
        Device deletes its own secret key (and public keys and certs)
        
        Device will never be able to join again, unless new key pair and cert is issued for device
        
        Join of New Device
        
        Install new device
        
        Config (certified of device) send to verifier (config signed by manufacturer)
        
        Public key and certificates of public keys are exchanged
        (certs signed by manufacturer, both sides verify public key)
        
        Shared secret is created (e.g. with DH)
      - Public key exchange
      - code certificate exchange
      - shared secret
    - - Authenticated Communication
        
        Device authenticates message with session key (Hash(msg || S))
        
        Authenticated message is sent to other device
        
        Other device validates and processes the message if it is valid
      - Attestation Protocol
        
        Verifier sends attestation request (including a nonce)
        
        Device generated report (Hash(Nonce || memory state || ki))
        
        Device sends reports back to verifier
        
        Verifier checks reports
        
        If report for device is valid send session key to device (encrypted with shared key)
    - - devices are setup and certificates are issued
- - - - TCG Terminology
        
        integrity measurement
        
        platform characteristic = hash digest of the software to be executed
        
        process of obtaining metrics of platform characteristics that affect the integrity (measurement) of a platform and storing digests of these metrics in the TPM's PCRs
        
        platform configuration registers (PCR)
        
        shielded location to store integrity measurement values
        
        PCRs can only be extended: PCRi+1 = HASH(PCRi, Value)
        
        PCRs are reset only when the platform is rebooted
        
        integrity logging
        
        storing integrity metrics in a log for later use
        
        storing additional information about what has been measured (e.g. software manufacturer name, software name, version, ...)
      - TCG assumption and trust model
        
        unforgeability of measurements
        
        platform config cannot be forged after measurements have been taken
        
        However, today's OS can be (maliciously) modified
        
        hash digests of binaries express trustworthiness
        
        verifier can determine initial config from digests
        
        however, TCB of today's platforms are too complex
        
        secure channels can be established
        
        between HW components (TPM and CPU) since they have certified authentication keys provided by a PKI
        
        between machines running on the same platform (e.g. attestor and host) by using OS mechanisms (secure OS)
        
        protection against software attacks only
        
        unprotected communication link between TPM and CPU
        
        security issues of certain TPM aspects
        
        automated verification available
        
        integration of TPM in chipset may potentially be problematic
        
        engineering trade-off between security and technical evaluation
        
        TPM construction kit
        
        towards more security against hardware attacks
        
        currently
        
        TPMs have rudimentary hardware protection mechanisms
        (over/under voltage detection, low frequency sensor, reset filter,..)
        
        Some manufacturers started third-party certification
        (Common Criteria)
        
        CRTM is not tamper resistant (implemented in unprotected BIOS)
    - - Core Root of Trust for Measurement (CRTM)
        
        immutable portion of the host platform's init code that is executed upon a host platform reset
        
        trust in all measurements is based on the integrity of the CRTM
        
        ideally contained in hardware (TPM)
        
        implementation decisions may require the CRTM to be located in other firmware
        
        Possible implementations
        
        BIOS Boot Block
        
        BIOS is composed of BIOS Boot Block and POST BIOS
        
        each of these are independent components
        
        each can be updated independently
        
        POST BIOS is not part of CRTM but is measured by the chain of trust
        
        Entire BIOS
        
        BIOS is composed of a single atomic entity
        
        Entire BIOS is updated/modified/maintained as single component
    - - TPM identity
        
        represented as Endorsement Key
        
        Unique en-/decryption key pair
        
        private key does not leave TPM
        
        public key is privacy-sensitive
        (identifies TPM/platform)
        
        generated during manufacturing process of TPM
        
        either in TPM or externally and then embedded in TPM
        
        must be certified by EK-generating entity
        (e.g. by TPM manufacturer)
        
        can be deleted (revoked) and re-generated by a TPM user
        
        revocation must be enabled during creation of the EK
        
        deletion must be authorized by a secret defined during EK creation
        
        EK-recreation invalidates Endorsement Credential (EC)
        
        readable from TPM
      - Endorsement Credential (EC)
        
        digital certificate stating that EK has been properly created and embedded into a TPM
        
        issued by the entity who generated the EK
        (e.g. the TPM manufacturer)
        
        Includes
        
        TPM manufacturer name
        
        TPM model number
        
        TPM version
        
        Public EK (privacy sensitive)
      - Platform identity
        
        equivalent to TPM identity (EK)
        
        EK is unique identifier for a TOM
        
        TPM must be bound to only one platform
        (either physical or logical binding)
        
        Platform Credential asserts that a TPM has been correctly integrated into a platform
      - Platform credential
        
        state that an individual platform contains the TPM described in the EC
        
        issued by the platform manufacturer
        
        Includes
        
        Platform manufacturer name
        
        Platform model and version number
        
        References to (digests of) the corresponding Endorsement and Conformance Credential
      - TPM credentials
        
        may be distributed in the following ways
        
        platform distribution CD
        (impractical: every platform requires individual CD)
        
        partition on the platform's hard disk
        
        over TPM or platform manufacturer's web site
        
        in non-volatile storage are of TPM (most commonly used)
        
        reserved address space in non-volatile storage of TPM for TPM credentials
        
        Access to these credentials only allowed after TPM authentication
        
        current situation
        
        only one TPM manufacturer is known to provide EC
        
        no known TPM that comes with a Platform or Comformance Credential
      - Conformance Credential
        
        assert that a platform type fulfills the evaluation guidelines by the TCP
  - - - implementation of a checker:
        hardcode H (boot code) as reference value in checker (in firmware)?
    - - uses checker instead of measurer
  - - - third parties have no assurance that such a keys have been generated by a TPM (may not trust migratable keys)
    - - guaranteed to only reside in TPM protected locations
      - TPM can generate certificate stating that a key is non-migratable
    - - Storage Root Key
        
        root of key hierarchy
        
        secure storage is implemented as hierarchy of keys
        
        represents RTS
      - Attestation Identity Key
        
        used to attest to current platform config
        
        alias for TPM/Platform identity (Endorsement Key)
        
        should prevent tracking of TPM/platform
        
        Properties
        
        non-migratable
        
        generated by the TPM owner
        
        TPM/platform may have multiple AIKs
        
        requires certification that it comes from a TPM
        
        Certification by Trusted Third Party
        
        Certification via Direct Anonymous Attestation (DAA)
    - - Storage Key
        
        Protection of keys outside of TPM
        
        protection based on system configuration/properties (sealing)
        
        Properties
        
        Typically 2048-bit RSA en-/decryption key pair
        
        Generally allowed to be migrated to other TPMs
      - Signing Key
        
        Message authentication of arbitrary data external to TPM
        
        Authentic report of TPM-internal information
        
        Properties
        
        Typically 2048-bit RSA en-/decryption key pair
        
        Generally allowed to be migrated to other TPMs
      - Migrating Key
        
        Enable TPM to act as migration authority
        
        Used to encrypt migratable keys for secure transport from one TPM to another
        
        Properties
        
        Typically 2048-bit RSA en-/decryption key pair
        
        Generally allowed to be migrated to other TPMs
      - (Legacy Key)
      - ("Authchange" key)
      - Binding Key
        
        Protection of arbitrary data outside the TPM
        (binding=traditional asym. encryption)
        
        Properties
        
        Typically 2048-bit RSA en-/decryption key pair
        
        Migratable to other TPMs/Platform
        
        can only be used with binding commands
    - - migratable/non-migratable/certified migratable
      - whether key is allowed only to be used when the platform is in a specific (potentially secure) configuration
- - - - adversary model / assumptions
        
        Adversary can hijack control-flow (buffer overflow)
        
        Adversary knows the memory layout (memory disclosure)
        
        Adversary can construct gadgets
        
        Adversary can write ROP payload into the data area (stack/heap)
      - general idea
        
        use small instruction sequences instead of using whole functions
        (range from 2 to 5 instructions)
        
        all sequences end with return (POP{PC})
        
        instruction sequences are chained together to a gadget
        
        gadgets perform a particular task (e.g. load, store, xor ..)
        
        adversary enforces his desired actions by combining the attacks
      - gadget space on different architectures
        
        with memory alignment: small
        
        without memory alignment: big
        (overlapping memory parts)
      - Stack pivot
        
        Stack pointer acts as instruction pointer in ROP
        
        sets the stack pointer to point to the stack
    - - injecting env variable
      - corrupting control structure
      - Limitations
        
        no branching (e.g. no arbitrary code execution)
        
        critical functions can be eliminated or wrapped
    - - Code Randomization
        
        Advantages
        
        Low Performance Overhead
        
        Scales well to complex software (e.g. OS, browser)
        
        Disadvantages
        
        information disclosure hard to prevent
        
        high entropy required
        
        Fine-grained ASLR
        
        instruction reordering/substitution within a BBL
        
        Randomizing each instruction's location
        
        Permutation of BBLs
        
        Memory Leakage Problem
        
        Direct memory disclosure
        
        Just-In-Time-ROP
        
        leak of single address leading to leak of entire memory pages
        
        leaked address will reside in 4KB aligned memory page
        
        determine the page boundaries and disassemble the 4KB page
        
        disassembled page contains references to other pages
        
        Defenses
        
        Execute-Only-Memory (XoM)
        
        JIT-code attacks
        
        Same protection as for AOT code
        
        pointer leakage on code pages
        (e.g. direct call and jump instruction)
        
        Indirect memory disclosure
        
        Defenses
        
        Code-Pointer Hiding
        
        Trampoline
        
        Trampoline Reuse Attacks
        
        1 more item...
        
        Function reuse attacks
        
        Defenses
        
        Trampolines & Booby Traps
        
        pointer leakages on data pages such as stack/heap
        (e.g. return address, function pointer, pointer in vTables)
        
        Brute-Force attack on entropy
        
        Defenses
        
        Booby Traps terminate process
        
        make gadget locations unpredictable
        
        general idea is software diversity
      - Control-Flow Integrity (CFI)
        
        Advantages
        
        Formal Security
        (Explicit Control Flow Checks)
        
        Disadvantages
        
        Tradeoff: Performance & Security
        
        Challenging to integrate into complex software, coverage
        
        CFI Label Checking
        
        check if return of function A is label B
        
        Challenges
        
        Label Granularity
        
        Trade-Offs
        
        many checks if unique labels assigned per node
        
        Optimization step
        
        merge labels to allow single CFI check
        
        However, this allows for unintended control flow paths
        
        Label Problem for Returns
        
        Static CFI label checking leads to coarse-grained protection for returns
        
        Shadow stack allows for fine-grained return address protection but incurs higher overload
        
        Forward- vs. Backward-Edge
        
        some schemes only consider forward edge CFI
        
        Policies
        
        Call-Preceded Sequences
        
        returns need to target a call-preceded instruction
        
        Behavioral Based Heuristics
        
        prohibit chain of N short sequences each consisting of less than S instructions
        
        Hardware CFI
        
        HAFIX
        
        Objectives
        
        Backward- and Forward-Edge-CFI
        
        No burden on developer
        
        Security
        
        High performance
        
        Enabling technology
        
        Compatibility to legacy code
        
        Function return policy
        
        Control-flow enforcement technology
        
        Backward-Edge
        
        Shadow stack detects return-address manipulation
        
        Shadow stack protected, cannot be accessed by attacker
        
        new register ssp for shadow stack
        
        conventional move instruction cannot be used in shadow stack
        
        new instructions to operate on shadow stack
        
        Forward-Edge
        
        New instruction for indirect call/jump targets: branched
        
        Any indirect call/jump can target any valid indirect branch target!!!
        
        Could be combined with fine-grained compiler-based CFI
        
        Efficient CFI hardware implementation
        
        dedicated CFI instructions and memory
        
        Policies
        
        Function returns only allowed to target active call sites or the last active call site
        
        Functions calls need to target a valid function entry
        
        Limitations
        
        No policy enforcement for indirect jumps
        
        Coarse-grained policy for indirect calls
        
        For efficiency and security
        
        Why CFI processor support?
        
        dedicated CFI instructions
        
        avoids offline training phase
        
        instant attack detection
        
        CFI control state: Binding CFI data to CFI state and instructions
        
        Instructions to protect
        
        Returns
        
        Return to calling function
        
        Return address located on the stack
        
        Indirect Jumps
        
        switch tables, dispatch to library functions
        
        Target address taken from either processor register or memory
        
        Indirect calls
        
        call through function pointer, virtual table calls
        
        target address taken from either processor register or memory
      - Defense implementation approaches
        
        Binary instrumentation
        
        Binary analysis is limited
        
        => Defense will be incomplete
        
        Compiler extensions
        
        Requires recompilation of applications
        
        => Legacy applications remain vulnerable
        
        Code Annotations
        
        Developers are no security experts
        
        => Do everything "to make it work"
        
        New languages
        
        lack of trained developer
        
        => Will it still exist in 5-10 years
  - - - Data Execution Prevention (DEP)
- - - - features
        
        Secure storage
        
        Device key for insecure storage
        (in protected memory=
        
        Non-volatile memory
        (for rollback protection)
        
        Isolated execution
        
        TA code certificate (certified by manufacturer)
        (contains hash of TA code)
        
        Trusted Application (TA)
        
        TEE management
        (controls TA execution)
        (TEE entry from Rich Execution Environment)
        
        Device identification
        
        Identity certificate (certified by manufacturer)
        Base Identity + Assigned Identity (e.g. AIK)
        
        Base Identity
        (one fixed device id)
        
        Device authentication
        
        Device certificate
        Identity + Device public key
        
        Device key
        (used to protect/derive signature key)
        
        volatile memory
        (sign system state in remote attestation)
        
        External Trust Root
        
        Platform integrity
        "boot integrity"
        
        Boot code certificate (certified by manufacturer)
        (contains Boot Code Hash)
        
        volatile memory
        (stores measurements for authenticated boot)
        
        boot sequence
        (Launch boot code)
      - Hardware realization alternatives
        
        External Secure Element
        (e.g. TPM, smart card)
        
        Embedded Secure Element
        (e.g. smart card)
        
        Processor Secure Environment
        (TrustZone, M-Shield)
      - What is TEE?
        
        Trusted
        
        Isloated and Integrity protected
        from the normal execution environment
        
        Execution Environment
        
        Processor, memory, storage, peripherals
  - - - Authentication:
        Authentication Tokens & Secret
        Login Credentials
      - Download settings:
        Pairing instructions & User, Device info
      - Bluetooth-Pairing-Method
        TAP or Access Pin
      - Validation and Pairing message
        Data synchronization
        End-to-end encrypted channel
    - - all interfaces and devices including invasive physical attacks to tracker device
    - - Confidentiality
        
        Symmetric Key Encryption
        XTEA/AES/3DES
      - Integrity
        
        CRC/MD5/SHA/HMAC
      - Authenticity
        
        Privates AES/RSA keys
    - - Use of End-To-End data encryption
      - Data at rest encryption
      - Data in Transit encryption
      - Existence of proprietary encoding
      - Presence of data integrity check mechanisms
      - Use of SSL certificate pinning
- - - - Protects previous stack values (e.g. Return address)
      - Stack values of previous functions can not be corrupted
      - Low performance overhead
    - - Arbitrary reads and writes can corrupt the stack values
      - canaries can be leaked
      - corrupted values can be used before canary is checked
  - - - Protects code pointers on the safe stack
      - Low performance overhead
    - - Buffer overflows on the unsafe stack are still possible
      - some critical variables are pushed to the unsafe stack, which allows data-only attacks
      - safe stack location may be leaked through neglected pointers, thread-spraying and allocation oracles
    - - Thread Spraying
        (spawn as many threads as possible)
      - reduces the entropy of the safe stack
    - - arrays accessed with non-constant index
      - function arguments that are pointers
      - objects to which a pointer exists in memory
    - - Unsafe stack pointer: TLS (Thread Local Storage)
      - Guard pages preceding this region to catch buffer overflows