O(1) TEE Registration Invalidations
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- solidity
- Domain
- blockchain, security
Research direction
Start with FlashtestationRegistry.sol at invalidateAttestations and review the Automata verifyAndAttestOnChain call it currently requires. Then trace BlockBuilderPolicy:isAllowedPolicy and determine how vulnerable TCB information should be checked and used for cheap invalidation. Done means the flashtestations and Automata changes are defined and the invalidation path no longer requires verifying every full attestation on-chain.
Written by the indexing model from the issue text.
Description
Context
In the event of a TCB Recovery , all of the TEE registrations that use that vulnerable TCB will need to be invalidated. If we don't do this, then those registered TDX devices could be used to put out fake but verifiable attestations and subvert the systems that use them
Problem
Our current process for invalidating these TEE registrations is costly; it requires calling invalidateAttestations all existing TEE registrations, which might be 10's of them since we plan to deploy a new TDX device every week. This operation is costly because it requires calling the Automata verifyAndAttestOnChain function and verifying the whole attestation onchain. This is also operationally a burdensome.
Potential Solution
We still need to nail down exactly what code within flashtestations and automata needs to change, but it's clear it's possible for each call to BlockBuilderPolicy:isAllowedPolicy to check if the workload's TEE registration is using a vulnerable TCB, and then use that information to invalidate the registration cheaply.
- Dominant language
- Solidity
- Stars
- 4
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from flashbots/flashtestations
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
flashbots/flashtestations#58 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
flashbots/flashtestations#57 ·
-
v2
Difficulty 4/5 3-5 days Newbie friendliness 38/100
flashbots/flashtestations#52 ·
-
v2
Difficulty 5/5 Over a week Newbie friendliness 35/100
flashbots/flashtestations#49 ·
-
v2
Difficulty 5/5 Over a week Newbie friendliness 25/100
flashbots/flashtestations#48 ·
All issues in flashbots/flashtestations
Similar issues
-
removeToken
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
cowprotocol/token-lists#1514 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
MystenLabs/sui#28056 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
filecoin-project/solstice#76 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
CypherBoxLLC/Cypher-Box#283 ·