Zařízení má doložit, co v něm běželo. IETF na to vydal formát, kam CoSWID nedosáhne

Vzdálené doložení stavu zařízení stojí na jednoduché myšlence: zařízení protistraně pošle podepsané tvrzení o tom, co v něm běželo, a protistrana se podle toho rozhodne, jestli mu něco svěří. Rámec, ve kterém se taková tvrzení posílají, se jmenuje Entity Attestation Token a popisuje ho RFC 9711. Uvnitř tokenu je mimo jiné údaj nazvaný Measurement – místo pro popis, výčet nebo měření softwaru, který na zařízení je.

Do téhle kolonky se dosud dal vložit jediný formát: značky CoSWID typu „evidence“. A tady byla mezera. CoSWID popisuje software tak, jak je nainstalovaný – s odkazem na soubory. Jenže část toho, co se na zařízení měří, žádné soubory nemá: kus firmwaru natažený do paměti při startu, průběžná kontrola integrity za běhu, hodnota v registru procesoru. Tam se CoSWID podle vlastního textu nového dokumentu nehodí.

Co se o měřené části zapisuje

RFC 10013 zavádí pojem měřené komponenty – objektu v prostředí zařízení, jehož stav se dá odebrat a obvykle prohnat kryptografickou hašovací funkcí. Dokument je na dráze internetových standardů a vyšel v červenci 2026; podepsáni jsou pod ním Simon Frost z firmy Arm, Thomas Fossati z Linara, Hannes Tschofenig z Univerzity Bundeswehru v Mnichově a Henk Birkholz z institutu Fraunhofer SIT.

Popis jedné měřené části má pět položek. Povinné jsou dvě: jméno komponenty a hodnota – buď surová, nebo v podobě otisku. Když je hodnota otisk, přibývá třetí povinná položka, totiž použitý hašovací algoritmus; u surové hodnoty se neuvádí. Volitelně se doplňuje verze (doporučuje se sémantické verzování) a autority, tedy jeden nebo víc subjektů, které umějí měřenou část závazně identifikovat.

U jména je jeden požadavek navíc, a stojí za pozornost: má zůstat stejné napříč vydáními. Bez toho se nedá sledovat táž měřená část přes aktualizace a protistrana nepozná, že mluví o témž kusu softwaru jako minule.

Dva zápisy téhož a dvě čísla v registru

Dokument záměrně odděluje informační model od zápisu. Informační model říká, co se zaznamenává; zápis říká, jak. Zápisy jsou dva, v JSON a v CBOR, a ke každému patří vlastní typ obsahu: application/measured-component+json a application/measured-component+cbor. Oba už jsou zapsané v registru typů médií u IANA. Pro protokol CoAP, který se používá na zařízeních s málo pamětí a pomalou linkou, dostaly navíc krátká číselná označení: 295 pro variantu v CBOR a 296 pro variantu v JSON.

Rozdělení na model a zápis není samoúčelné. Autoři počítají s tím, že se model použije i pro jiné zápisy – v textu jmenují ASN.1 –, aniž by se muselo znovu domlouvat, co se vlastně zaznamenává.

Protože zápis tokenu a zápis měřené komponenty nemusí být tentýž, popisuje dokument dvě podoby vložení. „Homogenní“ je ta, kde token i komponenta používají totéž – třeba obojí CBOR. „Tunelová“ je ta, kde se liší a jeden zápis se do druhého zabalí; v tokenu v JSON se pak komponenta v CBOR nese jako řetězec kódovaný do base64url.

Kde si dokument protiřečí sám se sebou

Nejzajímavější odstavce nejsou v popisu formátu, ale v úvahách o bezpečnosti a soukromí. Jméno a verze komponenty dávají útočníkovi podrobnou představu o tom, jaký software na zařízení běží a jak je nastavené – a to je, řečeno slovy dokumentu, cenný vhled. Textová pole se navíc musí před uložením do databáze nebo zobrazením člověku ošetřit, jinak se z nich stane vstupní brána; odkaz vede na RFC 9839.

A pak přijde věta, kterou by se dal článek začít i skončit: požadavek na stálost jména může umožnit sledování. Táž vlastnost, bez které se přes aktualizace nepozná, že jde o tutéž součástku, dělá ze zařízení něco, co jde napříč relacemi rozpoznat. Dokument to neschovává a neřeší – konstatuje to a jde dál. Jméno a verze podle něj navíc můžou samy o sobě prozradit soukromé údaje o zařízení a jeho majiteli.

Naše hodnocení: je to poctivější přístup než mlčení, ale řešení to nenabízí. Kdo bude formát nasazovat, musí si sám rozmyslet, komu doklad o stavu zařízení pošle – protože jednou odeslaný seznam měřených částí je zároveň otiskem, podle kterého se zařízení pozná příště.

Registr ještě nedohnal vydání

Drobnost, která je vidět jen při srovnání pramenů: v registru typů médií u IANA stojí u obou nových typů odkaz na RFC-ietf-rats-eat-measured-component-12, tedy na dvanáctou verzi pracovního návrhu, ne na hotové RFC 10013. Je to běžný stav, do kterého registr po vydání dokumentu na chvíli spadne, a časem se přepíše. Do té doby se z registru samotného nedá poznat, že norma už vyšla – což je při ověřování druhým pramenem dobré vědět.

Komu to je k čemu

Formát míří na výrobce zařízení a na provozovatele služeb, které si před vydáním dat ověřují, s čím mluví: průmyslová technika, síťové prvky, čipy s bezpečným startem. Pro běžného uživatele je to neviditelná vrstva – projeví se leda tím, že aktualizace firmwaru začne mít viditelnou stopu, na kterou se dá ukázat. Papírem to nezůstalo: v poděkování dokument uvádí, že Ken Takayama dodal implementaci téhle specifikace do balíčku veraison/eat. Praktický dopad ale bude záviset na tom, jestli formát převezmou profily EAT používané v jednotlivých odvětvích; dokument sám na ně v několika místech odkazuje a část významů nechává na nich.

Zdroje

• RFC 10013 — Entity Attestation Token (EAT) Measured Component, plné znění, IETF, červenec 2026
• IANA: Media Types – záznam obou nových typů
• RFC 9711 — The Entity Attestation Token (EAT)
• RFC 9393 — Concise Software Identification Tags