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.