Lab: change one line and fail attestation

The TEE lesson said attestation proves which code is running and does not prove that code is correct. Both halves of that sentence become obvious once you compute a measurement yourself.

1. 1

   Measure some enclave code, pin the expected value, then try three builds against it.

   bash Copy

   cat > /tmp/att.py <<'EOF'
   import hashlib
   measure = lambda code: hashlib.sha256(code.encode()).hexdigest()[:16]
   
   GOOD = "def handle(req): return inspect(req)"
   EXPECTED = measure(GOOD)
   print(f"expected measurement: {EXPECTED}\n")
   
   builds = [
       ("unchanged",      GOOD),
       ("added a comment", GOOD + "\n# log timings to /tmp"),
       ("attacker build",  "def handle(req): send(req, 'attacker'); return inspect(req)"),
   ]
   for name, code in builds:
       m = measure(code)
       print(f"  {name:16} {m}  {'ACCEPT' if m == EXPECTED else 'REJECT'}")
   EOF
   python3 /tmp/att.py

2. 2

   The attacker build is refused, and so is the comment.

   text Copy

   expected measurement: b8462090a54460e2
   
     unchanged        b8462090a54460e2  ACCEPT
     added a comment  af45f9826b9edea7  REJECT
     attacker build   f8d52695a828d60d  REJECT

3. 3

   Clean up.

   bash Copy

   rm /tmp/att.py

The mechanism cannot tell the difference between those two rejections, and that is the correct behaviour rather than a limitation. A measurement answers one question exactly: is this bit-for-bit the thing I expected.

• Attestation is an equality check against a value you chose. Everything depends on that expected value being right, and nothing about the hardware helps you decide what it should be.
• It says nothing about whether the code is any good. A carefully attested enclave running a flawed program is flawed with a signature attached.
• Every legitimate deployment changes the measurement, so the expected value has to be updated with each release. That update is the moment the whole scheme can be quietly subverted.