TEE 远程认证回退绕过

type Verifier interface {
Verify() error
GetSerialNumber() string
GetMeasure() string
}

type FallbackVerifier struct {
TestPurpose  string `json:"test_purpose"`
Measure      string `json:"measure"`
SerialNumber string `json:"serial_number"`
}

func (f *FallbackVerifier) Verify() error {
return nil
}

func (f *FallbackVerifier) GetSerialNumber() string {
return f.Measure
}

func (f *FallbackVerifier) GetMeasure() string {
return f.SerialNumber
}

func NewVerifier(compressedEvienceBase64 string) (Verifier, error) {
compressedEvidence, _ := base64.StdEncoding.DecodeString(compressedEvienceBase64)
r, _ := zlib.NewReader(bytes.NewReader(compressedEvidence))
evidenceBytes, _ := io.ReadAll(r)
var evidence map[string]any
json.Unmarshal(evidenceBytes, &evidence)
var verifier Verifier
if _, ok := evidence["test_purpose"]; ok {
verifier, err = NewFallbackVerifier(evidenceBytes)
} else {
verifier, err = csv.NewAttestation(string(evidenceBytes))
}
return verifier, err
}
The choice between "run hardware attestation" (csv.NewAttestation, which validates an actual AMD/Hygon confidential computing report) and "always succeed" (FallbackVerifier.Verify() unconditionally returns nil) is made purely by inspecting attacker-controlled JSON for a test_purpose key. There is no separate code path, build constraint, or config flag that restricts FallbackVerifier to test/CI builds; it ships live in the same binary an NHP server runs in production.