Zusammenfassung

  • Muhammad Usama Sardar stellte am 27. Oktober bei RIPE 93 die frühe Attestierung im TLS-Handshake infrage. Eine eigene Warnung von Cocos AI beschreibt einen Intel-TDX-Testpfad, der einen wiederverwendeten oder abweichenden Sitzungswert annahm und danach Anwendungsdaten freigab.
  • Eine zweite Warnung betrifft AMD SEV-SNP: Fehlt der erwartete Wert beim Aufruf, kann ein fremder Beleg akzeptiert werden. Cocos wechselte mit Version 0.9.0 zur Attestierung nach dem Handshake; die IETF-SEAT-Charta verlangt Frische pro Verbindung.

Der Pförtner prüfte den Ausweis. Ob er zum Mantel des heutigen Gasts gehörte, prüfte er nicht. In der Intel-TDX-Warnung von Cocos AI ist diese fehlende Kontrolle eine konkrete Programmstelle: Der Prüfer erhielt den Wert für die aktuelle TLS-Sitzung, übernahm ihn aber im getesteten Pfad nicht in die Richtlinie für den Hardwarebericht. Ein externer Bericht mit abweichendem oder erneut verwendetem reportData wurde im lokalen Freigabetest akzeptiert. Nach dem Handshake flossen Anwendungsdaten.

Sardar sprach laut RIPE-93-Programm über die Risiken, wenn der Beleg bereits in den TLS-Handshake eingebaut wird. Sein Einwand richtet sich gegen zusätzliche Komplexität ohne belastbare Bindung. Die Herstellerwarnung macht daraus einen Prüfauftrag: Der Handshake ist erst ein guter Türsteher, wenn der Beleg auf genau diese Verbindung zeigt.

Die zweite Cocos-Warnung beschreibt eine andere Hardwarestrecke. Im AMD-SEV-SNP-Pfad der Version 0.8.2 wurde das erwartete ReportData nur gesetzt, wenn der Aufrufer einen nichtleeren Wert lieferte. Bei ausgelassenem Wert konnte ein Bericht ohne Bezug zur aktuellen Verbindung durchgehen. Ein vorhandener nichtleerer Wert wurde dagegen geprüft; Abweichungen wurden abgewiesen. Version 0.9.0 verlegte die Attestierung hinter den Handshake.

Auch Edgeless Systems dokumentierte für Contrast eine andere Identitätsverwechslung. Unter den in der Warnung genannten Bedingungen von Verkehrsabfang und Berichtsfälschung oder Geheimnisgewinnung konnte ein gültiger Bericht einer anderen Maschine genügen. Version 1.16.0 brachte Listen zugelassener Hardwarekennungen. Echtheit des Berichts, richtige Maschine und frische Verbindung verlangen jeweils eine eigene Prüfung.

Die Charta der IETF-Arbeitsgruppe SEAT fordert die Bindung des Belegs an die TLS-Verbindung, Frische pro Verbindung und formale Analyse während der Spezifikation. Man kann diese Forderungen testen: alter Bericht, fehlender Erwartungswert, anderer Rechner. Bleiben die Anwendungsdaten in allen drei Fällen hinter der Tür, hat das Gütesiegel eine überprüfbare Bedeutung.