Hardware-Roots of Trust : Felsenfest verankert (1) : Relevanz hardwarebasierter „Roots of Trust“ (HBRT) für regulatorische Anforderungen und aufkommende Technologie

Typische Aufgaben eines hardwarebasierten Root of Trust umfassen:

• sicheres/gemessenes Booten: Überprüfung der Integrität und Authentizität von Firmware (vgl. [6,7]) sowie Messung und Attestierung der Plattformintegrität
• Fernattestierung: Erzeugung überprüfbarer Nachweise der Plattformintegrität
• authentifizierte Updates und Schutz vor Rollback: Verhinderung der Ausführung unautorisierter oder veralteter Firmware
• Identitäts- und Lebenszyklusmanagement: hardwareverankerte Geräteidentität und kontrollierte Außerbetriebnahme
• kryptografische Schlüsselverwaltung: sichere Erzeugung, Speicherung und Nutzung kryptografischer Schlüssel
• echte Zufallszahlengenerierung: hardwarebasierte Entropiequelle zur Initialisierung kryptografischer Operationen

Hochsichere HBRTs erfordern dazu eine minimale, vertrauenswürdige Codebasis, Schutz gegen physische und Seitenkanalangriffe sowie eine überprüfbare Designabsicherung (siehe etwa [1]).

Die Standardisierung von HBRT umfasst mehrere sich ergänzende Ansätze verschiedener Organisationen, die interoperable, messbare und überprüfbare Vertrauensanker über verschiedene Computer-Ökosysteme hinweg schaffen wollen:

• Trusted Computing Group (TCG): pflegt die Spezifikationen für Trusted-Platform-Modules (TPMs, [8]) sowie Device-Identifier-Composition-Engines (DICE, [9]) und eine eigene RoT-Definition [10],
• National Institute of Standards and Technology (NIST): definiert unter anderem in NIST SP  800-193 „Platform Firmware Resiliency Guidelines“ [6] Richtlinien zum Schutz und zur Wiederherstellung von Firmware sowie in NIST SP 800-164 „Guidelines on Hardware Rooted Security in Mobile Devices“ [2] ein konzeptionelles Modell und die Beziehungen zwischen Hardware-, Firmware- und Software-RoT in mobilen und eingebetteten Geräten.
• GlobalPlatform: definiert unter anderem in „Root of Trust Definitions and Requirements (GP_REQ_025)“ [11] gerätebezogene Anforderungen an einen RoT, seine Schnittstellen und Beziehungen zum „Trusted Execution Environment“ (TEE) sowie anderen sicheren Subsystemen
• International Organization for Standardization (ISO): standardisiert mit der Normenreihe ISO/ IEC  11889-x „Information technology — Trusted platform module library“ die TPM-Architektur und definiert den RoT für Messung (Measurement), Speicherung (Storage) sowie Berichterstattung (Reporting)
• European Telecommunications Standards Institute (ETSI): entwickelt derzeit unter anderem mit ETSI TS 104 875 „Cyber Security; Hardware-Based Root of Trust Specification“ eine technische Spezifikation zu HBRT einschließlich Anwendungsfällen und Beschreibungen von Sicherheitsfunktionen
• Open Compute Project / Project Cerberus: demonstriert den Einsatz von HBRT in Rechenzentrums- und Serverplattformen (siehe https://github.com/opencomputeproject/Project_Olympus/tree/master/Project_Cerbeus sowie https://learn.microsoft.com/azure/security/fundamentals/project-cerberus).

Entwicklungsstränge

Die HBRT-Landschaft spiegelt im Wesentlichen zwei sich ergänzende Entwicklungen wider: Während die akademische Forschung den Schwerpunkt auf formale Absicherung und architektonischen Minimalismus legt, setzen industrielle Implementierungen die Priorität auf Skalierbarkeit, Zertifizierungsbereitschaft und Absicherung der Lieferkette. Die zunehmende Zusammenarbeit zwischen diesen beiden Gemeinschaften fördert transparente, messbare und interoperable Vertrauensanker.

Akademische Entwicklungen

Die akademische Arbeit der letzten zehn Jahre hat sich von konzeptionellen Entwürfen hin zu überprüfbaren Implementierungen und Hardware-Software-Co-Designs entwickelt. Wichtige Themen sind:

• Minimale und überprüfbare Architekturen: Die SMART-Architektur [12] hat gezeigt, dass eine kleine, verifizierte Codebasis einen dynamischen RoT auf eingeschränkten Geräten implementieren kann. Nachfolgende Forschungen erweiterten diesen Ansatz durch formal verifizierte Bootloader, sichere Mikrocontroller und verifizierte Hardwarebeschreibungssprachmodelle (HDL).
• Komponierbarkeit und formale Methoden: Da RoTs mit TEEs und komplexen SoCs integriert werden, sind eine zusammensetzbare Verifikation und schichtübergreifende Absicherung unerlässlich (siehe auch [5]). Um die Isolation zwischen sicheren und unsicheren Welten nachzuweisen, kommen zunehmend formale Methoden zum Einsatz.
• Post-Quanten- (PQ) und KI-bewusste Modelle: Die Forschung untersucht quantenresistente und quantenfähige Hardware-Vertrauensanker – einschließlich aufkommender Quantum-Hardware-Security-Modules (QHSMs), die PQC-Algorithmen integrieren – und setzt KI-gestützte Seitenkanalerkennung ein, um die Hardware-Resilienz zu stärken.

All diese Bemühungen haben überprüfbare, anpassungsfähige und kontextbewusste RoTs vorangebracht, die eine messbare Absicherung über verschiedene Gerätekategorien hinweg ermöglichen.

Implementierung und Praxis in der Industrie Die RoT-Implementierung ist in den Bereichen Unterhaltungselektronik, Automobilindustrie und CloudInfrastruktur mittlerweile zu einem integralen Bestandteil moderner Sicherheitsstrategien geworden. Die großen Prozessorhersteller haben längst verschiedene Angebote zu Hardware-Isolation, Schutz von Enklaven, Fernattestierung sowie TEEs in ihre Plattformen integriert.

Offene und transparente HBRTs konzentrieren sich auf die Sicherstellung der Lieferkette durch prüfbare und reproduzierbare Designs. Neben den bereits angesprochenen Projekten Cerberus und OpenTitan liefert beispielsweise Caliptra 2.1 ein komplettes RoT-Subsystem mit quantenresistenter Kryptografie, verbesserter Hardware-Schlüsselverwaltung sowie Defense-in-DepthFähigkeiten und verankert eine vertrauenswürdige Hardwarekette für Schutz, Erkennung und Wiederherstellung (vgl. https://chipsalliance.github.io/caliptra-web/).

Zur Firmware-Resilienz und Integrität der Lieferkette existieren mit NIST SP  800-193 [6] und TCG DICE [9] formalisierte Mechanismen für Measured Boot, Wiederherstellung und geschichtete Geräteidentitäten. Im Übrigen orientieren sich Implementierungen zunehmend an den Spezifikationen von ETSI TC CYBER, TCG und GlobalPlatform, um interoperable Zertifizierungen zu ermöglichen.

Wechselwirkung zwischen Forschung und Industrie

Kollaborative Initiativen wie OpenTitan (Google, lowRISC und ETH Zürich), Capability Hardware Enhanced RISC Instructions (CHERI) der Universität Cambridge und Arm (https://cheri.cst.cam.ac.uk) sowie das Open Compute Project (www.opencompute.org) demonstrieren erfolgreiche gemeinsame Entwicklungen von Forschung und Industrie. Die Industrie unterstützt inzwischen regelmäßig akademische Verifikations- und Side-ChannelEvaluierungsinitiativen, während sich die Wissenschaft zunehmend an den Rahmenwerken von TCG, NIST und ETSI orientiert, um methodische Konsistenz und Interoperabilität sicherzustellen (vgl. [7,9]). Diese wechselseitige Beziehung beschleunigt den Übergang von theoretischer Absicherung hin zu einsatzfähigen und zertifizierbaren Hardware-Trust-Ankern.

Die aktuelle HBRT-Landschaft zeigt damit eine deutliche Konvergenz hin zu offenen, überprüfbaren und zertifizierbaren HBRT, die Firmware-Resilienz, PostQuantum-Bereitschaft und harmonisierte globale Standards integrieren. Akademische Verifikationsmethoden und industrielle Zertifizierungspraktiken verschmelzen allmählich und schaffen die Grundlage für eine einheitliche, messbare Absicherung über verschiedene Anwendungsbereiche hinweg.

Herausforderungen

Die Implementierung und Absicherung von Roots of Trust steht vor mehreren anhaltenden Herausforderungen: Diese ergeben sich aus der zunehmenden Komplexität moderner SoCs, sich entwickelnden Angriffsflächen und einem fragmentierten globalen Zertifizierungsökosystem. Obwohl viele dieser Probleme bei HBRT am deutlichsten sichtbar sind, betreffen ähnliche Schwierigkeiten auch firmware- und softwarebasierte Designs.

Komplexität und Verifikation

Die kontinuierliche Integration neuer Funktionen in Systems-on-a-Chip (SoC) erweitert die Trusted-Computing-Base (TCB), was die formale Verifikation erschwert und das Risiko nicht-verifizierter Abhängigkeiten erhöht. Geschütztes geistiges Eigentum und proprietäre Hardware-Beschreibungssprachen begrenzen die Prüfbarkeit und erschweren die Validierung durch Dritte (siehe auch [5]) – Projekte wie OpenTitan und CHERI demonstrieren demgegenüber die Vorteile offener Verifizierungsansätze. Trotzdem bleibt industrielle Skalierbarkeit eine zentrale Limitation – gerade angesichts der Kosten für formale Methoden und den Bedarf an sicheren Werkzeugketten (Toolchains).

Lieferkettenintegrität und Firmware-Authentifizierung

Globalisierte Hardware-Lieferketten setzen Komponenten Risiken wie dem Austausch durch Fälschungen sowie von unautorisierten Modifikationen und FirmwareImplantaten aus. Standards wie NIST SP 800-193 sowie Initiativen von ETSI und TCG fördern Mechanismen wie „Measured Boot and Attestation“ als Werkzeuge zur Sicherstellung der Integrität der Lieferkette.

Die Umsetzung durchgängiger Rückverfolgbarkeit über Ökosysteme mit mehreren Anbietern hinweg bleibt jedoch schwierig: Um kontinuierliches Vertrauen aufrechtzuerhalten, sind Herkunftsnachweise für Hardware und verifizierbare Fertigungsnachweise notwendig – allem voran für kritische Infrastrukturen und Verteidigungssysteme. Darüber hinaus bietet ISO/IEC 20243-1 „Open Trusted Technology Provider Standard (O-TTPS) – Part 1: Requirements and recommendations for mitigating maliciously tainted and counterfeit products“ Leitlinien auf Governance-Ebene zur Minderung von Risiken in der Lieferkette und zum Umgang mit gefälschten Komponenten.

Aktualisierbarkeit und Lebenszyklusmanagement

Moderne Geräte haben lange Betriebszeiten, die sichere Firmware-Updates, kryptografische Schlüsselrotation und Widerrufsmechanismen erfordern. Geräte mit unveränderlicher Firmware, besonders im IoT- und Industrie-Steuerungssystembereich, müssen vertrauenswürdige Versionsverfolgung und einen Schutz vor Rollbacks implementieren (siehe auch [6]). Die Einführung von Lebenszyklusmanagement-Prozessen (CLM) mindert zwar Überalterung und kryptografische Abweichungen, bedeutet jedoch auch einen zusätzlichen betrieblichen Aufwand. Dennoch bleibt die Etablierung einheitlicher UpdateRichtlinien und sicherer Werkzeuge für die Lieferkette eine Voraussetzung für die langfristige Vertrauenswürdigkeit von RoTs.

Fragmentierung von Standards und Zertifizierung

Eine Vielfalt von Standards und Zertifizierungsrahmen wie TCG TPM, GlobalPlatform RoT, ETSI HBRT, FIDO2, Common Criteria (CC) und FIPS 140- 3 führen zu Interoperabilitätsproblemen und doppelten Bewertungen. Bemühungen von ETSI, TCG und GlobalPlatform sind im Gange, um Absicherungsniveaus, Terminologie und Bewertungsprozesse abzugleichen und die Harmonisierung zu verbessern. Die damit verbundene Arbeit der Internet Engineering Taskforce (IETF) für eine Remote ATtestation procedureS (RATS) Architecture (RFC 9334, [13]) unterstützt die Interoperabilität von Attestierungsnachweisen über verschiedene Rahmenwerke hinweg. Das Fehlen einer allgemein anerkannten Taxonomie von RoT-Absicherungsniveaus behindert jedoch weiterhin die Wiederverwendbarkeit von Zertifizierungen und die gegenseitige Anerkennung zwischen Systemen.

Neue Bedrohungen: KI und Quantencomputer

Künstliche Intelligenz (KI) bringt sowohl Chancen als auch Risiken im Kontext von RoT mit sich: KI-gesteuerte Seitenkanalanalyse und automatisierte Fehlerinjektion können subtile Hardware-Leakage-Muster ausnutzen, was den Bedarf an adaptiven, selbstüberwachenden Abwehrmechanismen erhöht. Gleichzeitig stellt das Quantencomputing eine grundlegende Bedrohung für die aktuelle asymmetrische Kryptografie dar. Die Auswahl von Kyber und Dilithium als Postquantum-Standards durch das NIST unterstreicht die Dringlichkeit, PQCBereitschaft in zukünftige RoT-Designs zu integrieren. Hardware-Krypto-Agilität, die es ermöglicht, Algorithmen ohne Redesign zu aktualisieren, wird voraussichtlich zu einer Standardanforderung.

Physische und Seitenkanalangriffe

Physische und Seitenkanalangriffe – einschließlich Differential Power-Analysis (DPA), elektromagnetischer (EM) Analyse und Fehlerinjektion – bleiben kritische Bedrohungen für die Integrität von HBRT. Gegenmaßnahmen wie Manipulationssensoren, redundante Logik und kryptografische Operationen mit konstanter Laufzeit verbessern die Resilienz, erhöhen jedoch die Designkomplexität und die Herstellungskosten.

Darüber hinaus können selbst Hardware-Implementierungen, einschließlich solcher, die von Arm TrustZone inspiriert sind, Timing-Leakage-Schwachstellen aufweisen, wenn sie auf FPGA-Prototypen realisiert werden. Folglich ist eine Zertifizierung (z.B. nach CC oder FIPS 140-3) eine praktische Anforderung für die Absicherungsbewertung, obwohl sie keine Sicherheit garantiert.

Manipulations- und Fertigungssicherheit

Der physische Schutz bleibt ein Eckpfeiler von HBRT. Secure Elements und TPMs integrieren Mesh-Sensoren, aktive Schutzschilde und Umgebungserkennung, um invasives Probing und Fehlerinjektion zu widerstehen (vgl. [1,8,11]). Trotz jahrzehntelanger Fortschritte ist echte Manipulationssicherheit aber probabilistischer Natur und daher bleibt eine physische Extraktion mit fortgeschrittenen Werkzeugen realisierbar.

Auch die Fertigung bringt Risiken mit sich – etwa nicht-vertrauenswürdige Produktionsstätten oder Verpackungsstufen, die Hardware-Trojaner oder Backdoors auf Mikroebene ermöglichen können (vgl. ISO/IEC 20243- 1:2023). Neuere RoT-Frameworks betonen verifizierte Lieferketten und nachvollziehbare Herkunftsnachweise, um diesen Bedrohungen entgegenzuwirken; dennoch bleibt eine vollständige End-to-End-Absicherung aufgrund der globalisierten Halbleiterproduktion eine offene Herausforderung.

Hardware-Zertifizierung und Evaluierungsaufwand

HBRT müssen zertifiziert werden, um Vertrauen im Ökosystem zu gewinnen. Die damit verbundenen Prozesse erfordern aber eine umfangreiche Offenlegung des Designs, Penetrationstests sowie Bewertung der Fehlertoleranz, was erheblichen Zeit- und Kostenaufwand bedeutet. Während Standardisierungsbemühungen wie TPM  2.0 wiederverwendbare Absicherungsrahmen bieten, stehen Hersteller weiterhin vor der Herausforderung einer Rezertifizierung bei Aktualisierungen von Chiprevisionen oder Firmware – das führt zu einem Spannungsfeld zwischen Innovation und Zertifizierungsfrequenz: Evaluierungszyklen hinken der schnellen Entwicklung hinterher und verzögern die Einführung neuer sichererer Hardwaretechnologie.

Kosten und Skalierbarkeitsbeschränkungen

Design, Produktion und Zertifizierung von HBRT sind ressourcenintensiv – manipulationsresistente Fertigung, Hardwarebewertung und sichere Testeinrichtungen erhöhen die Kosten erheblich. Der Übergang zu PQC wird die Rechen- und Speicheranforderungen für eingebettete und energieeffiziente Systeme noch weiter erhöhen. Offene und modulare HBRT-Designs wie OpenTitan können Kostenbarrieren durch Code-Wiederverwendung, Transparenz und gemeinschaftliche Verifikation allerdings senken.

Fehlende Hardware-Isolation und unveränderliche Vertrauensanker

Rein softwarebasierte RoTs besitzen keine unveränderlichen Anker und keine Hardware-Isolation, wodurch das Vertrauen letztlich von einem veränderbaren Software-Stack abhängt. Auch hardwaregestützte Isolationstechnologien wie Intel SGX und AMD SEV bieten zwar Enklaven- oder VM-Isolation, sind jedoch weiterhin auf Firmware- und Mikrocodelagen angewiesen, die aktualisiert und potenziell kompromittiert werden können. Anders als TPMs oder diskrete SEs, können diese Architekturen keine echte Unveränderlichkeit garantieren, da ihre Root-Keys und Messlogiken in rekonfigurierbaren Schaltkreisen liegen; das begrenzt die Absicherung und erschwert die langfristige Glaubwürdigkeit der Attestierung über Firmware-Versionen hinweg (vgl. [7,13]).

Laufzeitkompromittierung und Betriebssystemabhängigkeit

Softwaregestützte Vertrauensketten bleiben Laufzeitkompromittierungen ausgesetzt: RoTs, die innerhalb allgemeiner Betriebssysteme arbeiten, sind inhärent abhängig vom Host-Kernel, Scheduler und Hypervisor, was ihre Isolationsgarantien untergraben kann. Frühere Forschungen (z.B. Pioneer [4] oder HYDRA [5]) haben gezeigt, dass unkontrollierte OS-Kontrolle die Ausführungszeit oder den Zustand manipulieren kann, um Attestierungen zu fälschen oder sensible Daten zu leaken. Selbst moderne Enklavensysteme sind für das Ressourcenmanagement auf privilegierte Software angewiesen, was Angriffsflächen außerhalb der Enklavengrenze schafft. Aktuelle Gegenmaßnahmen wie „Measured Launch“, Mikrocode-Attestierung und „Hardware-Root-Sealing“ reduzieren diese Abhängigkeit, beseitigen sie aber nicht.

Schwacher Schlüsselschutz und Attestierungskredibilität

Software-RoTs müssen kryptografische Schlüssel schützen und glaubwürdige Attestierungsnachweise erzeugen. In Systemen ohne dedizierten Schlüsselspeicher können Speicherexposition oder Rollback-Angriffe versiegelte Schlüssel offenlegen und somit das RoT untergraben. Während TPM-2.0- und DICE-Architekturen hardwarebasierte Schlüsselableitung und Messhierarchien durchsetzen, bleiben virtualisierte oder Enklaven-basierte Systeme wie SEV anfällig für unsachgemäße Schlüssel-Lebenszyklusverwaltung. Die Glaubwürdigkeit von Attestierungsketten, wie sie in NIST SP 800-155 [7] oder IETF RFC 9334 [13] definiert sind, hängt von ununterbrochenen Messpfaden von unveränderlicher Hardware bis zu verifizierter Software ab – Abweichungen in der Integrität von Firmware oder Mikrocodes gefährden diese Grundlage.

Patch-Management und Versionskontrollrisiken

Das Aufrechterhalten der Vertrauenswürdigkeit von Software-RoTs erfordert sichere Update- und RollbackVerhinderungsmechanismen. Firmware- und Mikrocode-Patches müssen authentifiziert und gemessen werden, wie in NIST SP 800-193 [6] und SP 800-155 [7] betont wird. Unterschiedliche Anbieter-Ökosysteme und LebenszyklusPolitiken fragmentieren jedoch die Update-Absicherung: Unvollständige Versionskontrollen können Attestierungsabweichungen verursachen oder Downgrade-Angriffe ermöglichen, besonders in „Measured Boot“-Frameworks.

Hardware-RoTs wie TPMs helfen, die Herkunft der Firmware zu protokollieren und zu verifizieren, aber Software-RoTs bleiben verwundbar, wenn die Patch-Orchestrierung auf potenziell kompromittierten Betriebssystemen beruht. Um ein kontinuierliches Vertrauen zu erreichen, sind daher kryptografisch durchgesetzte Update-Pipelines mit attestierten Versionsbaselines erforderlich.

Felix Körner ist Senior Consultant, Michael Aulhorn und Dr. Samim Ahmadi sind Senior Manager im Technology Consulting, Dr. Srdan Dzombeta ist Partner im Technology Consulting und verantwortet den Bereich Cybersecurity bei der EY Consulting GmbH.

Fortsetzung folgt in der nächsten <kes>.

Literatur

^{[1] GlobalPlatform, Secure Element Protection Profile and extensions, Version 2.0 (GPC_SPE_174), Juli 2025, https://globalplatform.org/specs-library/secure-elementprotection-profile (Registrierung erforderlich)}

^{[2] Lily Chen, Joshua Franklin, Andrew Regenscheid, Guidelines on Hardware Rooted Security in Mobile Devices, NIST Special Publication SP 800-164 (Initial Public Draft), Oktober 2012 (Weiterentwicklung eingestellt im März 2023), https://csrc.nist.gov/pubs/sp/800/164/ipd}  

^{[3] Microsoft Learn, Trusted Boot (Secure Boot + Measured Boot), November 2025, https://learn.microsoft.com/en-us/windows/security/book/operating-system-security-system-security}   

^{[4] Arvind Seshadri, Mark Luk, Elaine Shi, Adrian Perrig, Leendert van Doorn, Pradeep Khosla, Pioneer: Verifying Code Integrity and Enforcing Untampered Code Execution on Legacy Systems, in: Proceedings of the 20th ACM Symposium on Operating Systems Principles (SOSP) 2005, Oktober 2005, ISBN  978- 1-59593-079-8, online verfügbar über https://doi.org/10.1145/1095810.1095812}  

^{[5] Karim Eldefrawy, Norrathep Rattanavipanon, Gene Tsudik, HYDRA: hybrid design for remote attestation (using a formally verified microkernel), in: Proceedings of the 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), Juli 2017, ISBN 978-1-4503-5084-6, online verfügbar über https://doi.org/10.1145/3098243.3098261}

^{[6] Andrew Regenscheid, Platform Firmware Resiliency Guidelines, NIST Special Publication SP 800-193, Mai 2018, https://csrc.nist.gov/pubs/sp/800/193/final}

^{[7] Andrew Regenscheid, Karen Scarfone, BIOS Integrity Measurement Guidelines, NIST SP 800-155 (Initial Public Draft), Dezember 2011 (Weiterentwicklung eingestellt im Oktober 2024), https://csrc.nist.gov/pubs/sp/800/155/ipd}

^{[8] Trusted Computing Group (TCG), TPM 2.0 Library, März 2026, https://trustedcomputinggroup.org/resource/tpm-library-specification/}

^{[9] Trusted Computing Group (TCG), Device Identifier Composition Engine (DICE), Workgroup Homepage, undatiert, https://trustedcomputinggroup.org/work-groups/dice-architectures/}

 ^{[10] Trusted Computing Group (TCG), TCG Roots of Trust Specification, Draft, Juli 2018, https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_ Trust_Specification_v0p20_PUBLIC_REVIEW.pdf}

^{[11] GlobalPlatform, Root of Trust Definitions and Requirements, Version 1.1.1 (GP_REQ_025), August 2022, https://globalplatform.org/specs-library/root-oftrust-definitions-and-requirements-v1-1-gp-req_025/ (Registrierung erforderlich)}

^{[12] Karim Eldefrawy, Aurélien Francillon, Daniele Perito, Gene Tsudik, SMART: Secure and Minimal Architecture for (Establishing a Dynamic) Root of Trust, Januar 2012, www.researchgate.net/publication/266178170_SMART_Secure_and_Minimal_Architecture_for_Establishing_a_Dynamic_Root_of_Trust}

^{[13] Henk Birkholz, Dave Thaler, Michael Richardson, Ned Smith, Wei Pan, Remote ATtestation procedureS (RATS) Architecture, Internet Engineering Task Force (IETF) RFC 9334, Januar 2023, https://datatracker.ietf.org/doc/rfc9334/}