genuinity tests for entrusting remote systems

Genuinity Tests for Entrusting Genuinity Tests for Entrusting Remote SystemsRemote Systems

Rick Kennell & Leah H. JamiesonSchool of Electrical and Computer Engineering

Purdue University

Presentation to RE-TRUSTParis, France

March 20, 2007

2

MotivationMotivation● Someone far away, whom I've never met,

is granting to me the use of a computer.

● I want to run unobfuscated scientificapplications a la “grid” computing.

● How can I make sure:

– Applications will run reliably.

– Remote user cannot inspect data.

– Remote user cannot modify data.● Don't want to think about human trust relationships.

3

ObservationsObservations

● If I completely control the computer and OS, security is similar to conventional systems.

– Hardware will work deterministically.

– Software will work deterministically.

– Encrypt transport of information across network.● Three basic questions:

– When will hardware work deterministically?

– When will software work deterministically?

– How can I send a cryptographic key to a remote system?

4

1) When will hardware work 1) When will hardware work deterministically?deterministically?

● When it is real.– We take this for granted more than we should.

– “If it looks like a computer, it is a computer.”

● Pretending to be a computer is hard,but possible.– Simulation, emulation, virtualization, misdirection

● How can we test that a machine is real?● Great deal of complexity in modern CPUs.

– This makes simulation difficult.

5

2) When will software work 2) When will software work deterministically?deterministically?

● When the hardware is real.● When the software is running.

– Not enough to know that it's loaded.● Many kinds of misdirection attacks● Simulation● Privilege traps (as in virtualization)

● How can we test that a machine is real and the software that we expect is running?– We must do so simultaneously.

6

3) How can I send a cryptographic 3) How can I send a cryptographic key to a remote system?key to a remote system?

● Must avoid man-in-the-middle attacks.● Public key exchange has known weaknesses.

● We could send a key along with the “software” that is expected to be installed and running.– If we know the software is correct, the embedded

key is also correct.

7

Putting it all togetherPutting it all together

● We want a way to show that software and hardware are real.– Realness test

– Reality check?

– Genuineness evaluation?

– Use unique, archaic term: “genuinity” test.

● Create tests that:– Leverage detailed knowledge about CPUs.

– Have high implicit parallelism.

– Are slow to simulate.

8

OutlineOutline

● Development of a Genuinity Test● Network Protocol● Related Work● Potential Attacks● Evaluation● Future Work

9

Some terminologySome terminology● Suppose an Authority requests evidence

from a remote Entity that its software is as expected.

● A program's instructions are determined by the contents of its memory.– Closed-world assumption: only “text” segment.

– Calculate a checksum of the memory contents.

– A program checking itself might be fooled.

– Authority can ask for a checksum of a subrange using a challenge-response protocol and a known reference.

10

Pitfalls of ChecksumsPitfalls of Checksums

● How does the Authority know that the Entity was executing the code subjected to the checksum?– It could be a fake program that interrogates an in-

memory copy of the expected program.

● We resist this attack by coupling the checksum with an architecturally-sensitive test.– We must know that the test is running.

11

Architecturally-sensitive testsArchitecturally-sensitive tests

● We limit the scope of the decision to the CPU.● “Does a CPU conform to its specification?”

– We can evaluate this to any level of certainty.

● Turing: Any computer can simulate any another.● Simulators are slow (by orders of magnitude).● A program with carefully selected instrs will be

much harder to simulate than to run natively.– Goal: Show that execution environment is correct

and fast.

12

What is hard to simulate?What is hard to simulate?

● CPU operations:– that occur as side-effects of instructions.

– whose effects are deterministic and predictable.

– whose effects can be easily measured.

– that have a good deal of implicit parallelism.

● Example: data cache state updates.● Other elements of the memory hierarchy

make good discriminants.– TLBs, caches, miss counters, branch pred.

13

A Combined HW/SW TestA Combined HW/SW Test

● Combine a checksum algorithm with architecturally-sensitive meta-information.– Use pseudo-random memory traversal.

● LFSR-based walk of virtual memory.● Multiple virtual mappings to same page.● Bytes of memory are added to into checksum.

– Pseudo-random execution graph.

– Periodically sample CPU meta-information.● XOR the value with the checksum.

– Even with periodic sampling, attacking simulator must continually track state of architecture.

14

Testcase code blocksTestcase code blocks

S = S + *PP=LFSR(P)S=SÎTLBif (S&1)else

S = S + *PP=LFSR(P)S=S^BPif (S&3)else

S = S + *PP=LFSR(P)S=S^D$if (S&1)else

S = S + *PP=LFSR(P)S=SÎnstrif (S&1)else

S = S + *PP=LFSR(P)S=S^DTLBif (S^2)else

S = S + *PP=LFSR(P)

if (op(S))else

S = S + *PP=LFSR(P)S=SÎ$if (S>0)else

15

Large Virtual Memory Region

Smaller Physical Memory Region(One page injected into OS kernel)

Code Blocks

Public Key

16

Additional RequirementsAdditional Requirements● The Authority imposes a deadline.

– A timely correct checksum value indicates correct memory contents executed by a correct CPU (of a particular family/model/stepping).

● Execution environment must be insulated from outside influences for the duration of the test.– Interrupts must be disabled.

– Only for the duration of the test.

● Data that affects control-flow must be checked.– e.g. Interrupt vectors.

● Network delay must be << than test time.

17

OutlineOutline


18

A Supporting Network ProtocolA Supporting Network Protocol

● Goal: Allow an Entity to show its Genuinity and perform a key-exchange with the Authority.– Challenge-response protocol.

– Use efficient public-key cryptography.

– Entity generates random # to use as temporary ID.

– Leverage the checksum value to guard against "man-in-the-middle" attacks in doing key distribution.

19

CHALLENGE signed(key and code for chksum)

Kernel (key)

Illustration of Network ProtocolIllustration of Network Protocol

Entity

REQUEST (cpu type)

OFFER (initial memory map)

ACCEPT

QUALIFICATION or REJECTION

Execute

Key G

en

RESPONSE encrypted(result, random ID)

encrypted(new key, random ID)

Authority

20

Key PointsKey Points● Correct checksum calculation depends on the

Entity having correct keys.● Authority does not know identity of the Entity.● Random ID known only to Authority and Entity.● Attempts at denial-of-service are possible.

– Additional encryption and signing helps.

– Protocol is fail-stop.

● Genuine systems will not assist with attacks.

21

After the testAfter the test

● Entity can run a multiuser OS.● Authority must periodically ping Entity.

– Make sure it hasn't been subverted.

● If the Entity detects self-compromise, or network failure:– Erase secrets

– Shut down

● Helpful to have a quorum of co-located Entities.

22

OutlineOutline


23

Related WorkRelated Work

● Secure Coprocessors, Bootloaders, Smartcards, ABYSS, TCPA, LaGrande– Often provide excellent physical security.

– Identity-based schemes.

– Do they offer indication that the system is real?

● Reflection as a Mechanism for Software Integrity Verification, Diomidis Spinellis, ACM Transactions on Information & System Security, February, 2000

24

OutlineOutline


25

Threat ModelThreat Model● Assumptions:

– Not feasible to create hardware that looks like a real CPU, but doesn't always act that way.

– Not feasible to physically interrogate memory bus.● Rule out anything involving a soldering iron.

– Protocol is not useful for compromising Authority.● No useful data on the Entity for that either.

– Attacker must use a peripheral (network, keyboard) to exploit deficiencies in software.

● Attacks and defenses are well understood.

26

Potential AttacksPotential Attacks

● Virtualizing simulator:– Start with a virtual machine.

– When privileged instructions trap, compile handler and insert the code into the executable.

– Converge on an optimal form of the testcase.

● Hardware attacks:– Rogue CPU in an SMP system. (infeasible?)

– Hotkey/BIOS save-and-resume. (monitor it)

27

OutlineOutline


28

ImplementationImplementation● An Authority daemon:

– Generates 128-bit RSA key-pairs.

– Testcase code generator.

– Network server that exchanges UDP packets.

● Entity software:– Boot-time activation of Genuinity test in Linux-2.5.

● After setup, but before processes are created.– Key exchange used to establish IPsec session.

● Entity “liveness” is periodically checked.– NFS file system used to deliver executables, modules.

● Results and calculation times for tests were compared against results made on known-genuine systems.

29

Evaluation TargetEvaluation Target

● How can we evaluate this system?– Try to benchmark against an ideal.

● No sport in checking the Genuinity of a very fast target Entity.

● Used a 2.4GHz Pentium-4 simulation host to pretend to be a 133MHz Pentium “Classic.”

30

Testcase Meta-Information Testcase Meta-Information CollectionCollection

● Wide speed disparity between target and simulation host.

● Need lots of meta-information about target.– I/D TLB CAM cells

– Tag and replacement info for I/D caches

– One perf. counter counted "taken" branches.

– One perf. counter counted executed instructions.

● Tests were limited to what could be simulated.● The timestamp counter was occasionally

sampled to generate a random ID.

31

SimulatorsSimulators● Slightly modified Bochs 2.0

– Configured to ignore architectural queries.

– Couldn't generate the correct result.

– Just wanted to see how fast it would run.

● Ideal simulator– Specially designed program using a priori

knowledge of a generated testcase to simulate only the architectural nuances.

– Should not be possible to build such a simulator in a timely fashion without a priori knowledge.

● Generated a representative testcase to try via a conventional network.

32

ComparisonComparison

● Nota Bene:– Bochs had no concept of architectural meta-info.

– Ideal is speculative estimate of a simulator we don't know how to build.

– Many other testcase operations are possible.● It's just too hard to simulate them.

– Most CPUs are more complicated than P-133.

Native P-133 Bochs Ideal7.93 sec 18.53 sec 10.72 sec

33

SummarySummary

● Primary Contributions:– A way to determine that a system is Genuine.

– Via an unsecure network.

– With no trusted human intermediary.

– No special hardware required.

34

DownsidesDownsides

● It's hard to build test constructor.– Much easier if you don't have to simulate.

● Can't tell if someone is physicallysnooping the hardware.– Acceptable for some situations.

● A network is necessary.– Authority must remain in periodic contact with the

Entity after test.

– If the goal is distributed computation, this is no great burden.

35

Future WorkFuture Work

● Two things would make this task easy:– Execution fingerprinting built-in to the CPU.

● All the important architectural meta-info concentrated in one place.

– Encrypted interface to memory from CPU.● Physical security boundary around CPU.● Cryptographic engine between cache and memory.

36

Thank you Thank you for your for your

patience.patience.

genuinity tests for entrusting remote systems

Documents