Why Should I Trust Your Code

Why Should I Trust Your Code

link

https://github.com/microsoft/ccf

https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/

Conclusion

Future

Parallels HTTPS rollout—standards + user pressure drive adoption

Adoption

Requires collaboration across developers, CSPs, auditors

Auditability

CTS enables post-hoc investigations (like certificate transparency)

Implementation & Standardization

CTS Prototype

- Performance: 1.5K claims/sec; 5.1K receipts/sec/thread.

- SGX enclaves; 3.5K LoC (C++) + 3K LoC (Python).

- Built on CCF (Confidential Consortium Framework).

SCITT (IETF)

Standardizes claim formats

Threat Analysis & Mitigations

Accountability

- Bad issuers caught via signed claims. - CTS corruption detectable through ledger replay.

TEE Compromise Risks

Software-level attacks：Trojan code/bugs → Auditable via CTS ledger

Hardware-level attacks：Rogue attestations → Mitigated via whitelisting/blacklisting

solution：Code Transparency Service (CTS) Architecture

example：Supermarket pork with a QR code → Scan to see farm & inspection details

Workflow

3. Users verify attestation + receipts before trusting service.

2. CSP deploys TEEs with attested code.

1. Providers sign claims → Register at CTS.

Components

Policies

Receipts

Claims

Core Idea

Public, append-only ledger for tracking code/provenance

Problem：Challenges in Trusting Code

User Dilemma

Modern reliance on cloud platforms (scalability vs. security).

Frequent updates (e.g., weekly patches)

Non-reproducible builds

Trust requires reviewing all source code, dependencies, and tools too much

Introduction to Confidential Computing (CC)

Example：AI cloud service handling sensitive conversations (health, finances)

Key goal：Treat cloud infrastructure as part of the adversary (like encrypted storage/networking).

Definition：Protects data in use via hardware-isolated TEEs (Trusted Execution Environments)