1 / 27

SWATT - PowerPoint PPT Presentation

  • Updated On :

SWATT. A software-based attestation method for embedded devices Arvind Seshadri, Adrian Perrig, Leendert van Doorn, Pradeep Khosla. Tomer shani Topics in Information Security. Lecture outline. Introduction Problem definition, assumptions & model SWATT Future work. Introduction.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'SWATT' - Rita

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Swatt l.jpg


A software-based attestation method for embedded devices

Arvind Seshadri, Adrian Perrig, Leendert van Doorn, Pradeep Khosla

Tomer shani

Topics in Information Security

Lecture outline l.jpg
Lecture outline

  • Introduction

  • Problem definition, assumptions & model


  • Future work

Introduction l.jpg

Attestation!! Is that English?

  • Attestation is the ability to affirm to be correct, true, or genuine

  • We would like to provide the ability to verify the memory content of a device we are about to interact with

  • This is one way to establish the absence of malware (viruses worms, trojan horses…)

Introduction4 l.jpg

Computers have been around for a long time, why do we need this ability now?

  • It is expected that embedded devices will surround us in the not too far future:

    • Furniture, clothing & appliances, for automated checkout, inventory control…

    • Sensor networks deployed for monitoring the environment , agriculture, military applications…

  • This large scale deployment, means devices cannot be physically secured & may often be in a hostile surrounding

Introduction5 l.jpg

OK, but what’s so special about embedded


  • Cost is a major issue, even a small increase in device cost leads to a significant increase in high volume production

  • Hardware solutions may be expensive (NGSCB, TCG)

  • Devices will typically have no virtual memory.(Kennel & Jamieson method)

Introduction6 l.jpg

So I’m convinced attestation is needed,

but what does SWATT do?

  • Software based attestation method (can be used on legacy devices, no need for special hardware)

  • Attests the device code, static data & configuration settings

  • The verifier does not require direct (hardware) access to device memory

Introduction7 l.jpg

Challenge (+ Attestation Routine)

Challenge Result


How SWATT works:

A challenge response protocol

Generate Random challenge

Precompute result






Compare results

Measure response time

Introduction8 l.jpg


  • Gas pumps – MOIT performs regular checkups, in which the mechanical properties of the pump are tested, currently impossible to attest software

  • Network printers – could be a significant breach in corporate security (eavesdropping, active attack ), administrator can use SWATT to attest code & configuration

  • Voting machines – there have been cases where software not certified by the state was used by electronic voting machines

  • Smart cards used to hold passwords – before entrusting passwords user could use SWATT to verify code

Lecture outline9 l.jpg
Lecture outline

  • Introduction

  • Problem definition, assumptions & model


  • Future work

Definitions l.jpg

Naïve attempt:

  • Verifier sends a challenge, device uses challenge as MAC key & computes MAC on memory, result is returned to verifier

  • Replay attack

  • Pre-computation

  • Malware can cheat – empty memory content can be used to store malware & skipped during the MAC computation. Malware code could also move original code to another device which will be used for MAC computation

Definitions11 l.jpg

  • MAC is not good enough, can we find an effective verification procedure?

  • What’s effective?If the memory contents of the device is the same as the value expected by the verifier the checksum will always be correct & verification will be successfulVerification will fail with high probability if the memory contents of the device differs from the expected content

Assumptions l.jpg

  • Verification procedure exists on the device (or downloaded prior to verification)

  • Verifier knows the expected memory layout

  • Verifier is intimately familiar with device HW

    • Clock speed

    • Memory architecture

    • Memory size

    • Instruction set (ISA)

Threat model l.jpg
Threat model

  • Attacker has full control over the device memory

  • Attacker does not modify the device HW

    • Increase memory size

    • Change memory access timing

    • Increase CPU clock speed

  • Attacker does not tamper with bios

Lecture outline14 l.jpg
Lecture outline

  • Introduction

  • Problem definition, assumptions & model


  • Future work

Swatt15 l.jpg

General concept:

  • The random challenge is used to seed the pseudorandom number generator

  • Number are used to traverse memory & update MAC

  • Malware cannot predict which memory will be requested next (altered memory or original memory)

  • An extra if statement must be added to divert load operations from the altered memory

  • The increase in running time will be noticeable

Swatt16 l.jpg

Desired verification process properties

  • The PRG should be optimized for CPU architecture (rc4 for 8bit, Helix for32 bit)

  • Resistance to replay & pre-computation attacks is achieved by seeding the PRG with a random challenge

  • High probability of detecting changes

    • Every memory location must be accessedCoupon collector problem shows that we need to make O(nln(n)), where n is the memory size

    • MAC should reflect changes to a single byte

Swatt17 l.jpg

Desired properties – Cont.

  • Small code size – an ‘if’ statement translates to a compare instruction + a conditional branch i.e. ~2-3 CPU cycles. If this is to be noticeable the verification procedure should take few tens of CPU cycles (not inc. init & epilogue)

  • Optimized implementation – if attacker can find a more optimized implementation of the verification procedure it will be possible to conceal the extra ‘if’

Swatt18 l.jpg

Desired properties – Cont.

  • Non parallelizable – To prevent multiple devices from performing distributed computation, to solve this the actual memory access is based on the RNG & the current checksum value

Swatt19 l.jpg


  • Architecture:

    • Atmel AT-MEGA163L microcontroller

    • 8-bit Harvard Architecture

    • 16K of program memory and 1K of data memory

    • RISC ISA

  • PRG:RC4 - first 256 bytes dropped to avoid known attacks8 RC4 bits are concatenated with current checksum value (for 16 bit address)

Swatt20 l.jpg

Implementation– cont.

  • Design Goals:

    • Fast FastFast !!! (No mac optimized for 8 bit)

    • reduce collision probability ( 64 bit checksum )

    • Avalanche effect - a changed memory location should perturb all fields of the checksum.

    • Non parallelizable

  • Algorithm: Verify(m) //in: iterations, out:Memory checksum //C = checksum vector, j = index in checksum vectorfor i ← 1 to m do //Construct address for memory read Ai ← (RC4i ≪ 8) + C((j−1) mod 8) //Update checksum byteCj ← Cj + (Mem[Ai] ⊕ C((j−2) mod 8) + RC4i−1)Cj ← rotate left one bit(Cj) //Update checksum index j ← (j + 1) mod 8return C

Swatt21 l.jpg

Implementation – Cont.

  • Assembly

    Generate ith member of random sequence using RC4

    zh← 2 ldizh, 0x02

    r15← *(x++) ld r15, x+

    yl← yl + r15 add yl, r15

    zl← *y ld zl, y

    *y← r15 st y, r15

    *x← r16 st x, r16

    zl← zl + r15 add zl, r15

    zh← *z ld zh, z

    Generate 16-bit memory address

    zl← r6 movzl, r6

    Load byte from memory and compute transformation

    r0 ←*z lpm r0, z

    r0 ←r0 ⊕ r13 xor r0, r13

    r0 ←r0 + r4 add r0, r4

    Incorporate output of transformation into checksum

    r7 ←r7 + r0 add r7, r0

    r7 ←r7 << 1 lsl r7

    r7 ←r7 + carry bit adc r7, r5

    r4 ←zhmov r4, zh

  • Manually optimized

  • 16 instructions, 23 machine cycles.

  • If statement (compare + branch) = 3 cycles -> 13 % overhead

  • No mathematical argument that further optimization is impossible

Swatt22 l.jpg

Implementation summary

  • Optimization

    • Optimized PRG (RC4)

    • Optimized checksum (proprietary)

  • Resistant to replay & pre-computation

    • RNG seeded from verifier

  • High probability of detecting changes

    • Coupon collector

    • 64 bit checksum

    • Avalanche effect

  • Small code size

    • Additional if will present an overhead of 13 %

  • Non parallelizable

    • Address is derived from RNG & memory content

  • Optimized implementation

Swatt23 l.jpg

Experimental results

  • Genuine software

  • Attacker’s version

    • Single byte of modified code

    • Single ‘if’ statement in the verification procedure

Swatt24 l.jpg

Considerations for practical use:

  • Number of iterations

  • Architecture:

    • Harvard: only program memory (code + static) needs to be verified. Different read latencies can be serve an attacker

    • Von – Neumann: code & data share memory. How do we handle the data section (stack, sensor readings…)

      • Software must be designed to have checkpoints where data state is predictable

      • Verifier can download data section

  • Empty memory regions:

    • should be filled with a random pattern (so that an attacker cannot suppress the read operation & save time)

Lecture outline25 l.jpg
Lecture outline

  • Introduction

  • Problem definition, assumptions & model


  • Future work

Future work l.jpg
Future work

  • Checksum / RNG

    • Will vary between platforms

  • Code Optimization

    • Theoretical framework to proof maximum optimization

  • How to perform device attestation remotely

    • Untrusted network

    • Unpredictable networking latencies

  • Devices with sophisticated architecture

    • Vitrual Memory

    • Branch prediction

Swatt27 l.jpg