swatt l.
Skip this Video
Loading SlideShow in 5 Seconds..
SWATT PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 27

SWATT - PowerPoint PPT Presentation

  • Uploaded 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


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


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
Lecture outline
  • Introduction
  • Problem definition, assumptions & model
  • Future work

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…)

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

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)

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

Challenge (+ Attestation Routine)

Challenge Result


How SWATT works:

A challenge response protocol

Generate Random challenge

Precompute result






Compare results

Measure response time



  • 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
Lecture outline
  • Introduction
  • Problem definition, assumptions & model
  • Future work

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
  • 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
  • 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
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
Lecture outline
  • Introduction
  • Problem definition, assumptions & model
  • Future work

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

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

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’

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


  • 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)

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

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

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

Experimental results

  • Genuine software
  • Attacker’s version
    • Single byte of modified code
    • Single ‘if’ statement in the verification procedure

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
Lecture outline
  • Introduction
  • Problem definition, assumptions & model
  • Future work
future work
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