Vulnerabilità · 87 giorni fa

L’attestation non basta a provare dove gira il codice

Il punto debole non è un bug di un singolo TEE. È il modello di fiducia: attested TLS può confermare l’integrità del software senza dimostrare che il server sia la macchina giusta, o che il codice stia girando sullo stack fisico atteso. Se la decisione è “attestare e poi rilasciare segreti”, quella prova può restare insufficiente anche quando l’attestation riesce.

Una ricerca verificata in modo indipendente mostra diversion attack contro due protocolli attested TLS di ultima generazione, e in un lavoro successivo contro sette modi diversi di legare l’evidenza alla connessione. I casi citati includono Intel TDX, Google Cloud Confidential Computing e, a monte, i management engine di Intel e AMD; il riferimento di contesto è CVE-2026-33697. In pratica, una connessione può essere deviata verso un’altra macchina che esegue lo stesso software, senza che il client se ne accorga.

Per chi costruisce trust decision basate su confidential computing, la conseguenza è netta: l’attestation non prova in modo affidabile la localizzazione o la sovranità del carico, solo che il codice sembra integro. Le promesse di data sovereignty legate ai TEE restano quindi più deboli di quanto il playbook standard lasci intendere.

Cronologia

• 4 lug Segnalato da The Register Security

Fonti

1 fonte che coprono questa storia

• The Register Security 4 lug

  Confidential computing's core trust mechanism is broken. The fix may not exist

  Attested TLS: the handshake that can't prove who's on the other end

• The Register Security 4 lug

  Confidential computing's trust mechanism is broken. The fix may not exist

  Attested TLS: the handshake that can't prove who's on the other end

Entità

• CVE-2026-33697

Part of the PlainSec briefing for 2026-07-05

Editions

• Briefing for 2026-07-05
• Briefing for 2026-07-04