The LFEDGE Secure Device Onboard(SDO) will soon be renamed as FIDO Device Onboard(FDO). Here FIDO is First Identity Online. For more details, you can check https://fidoalliance.org/. This blog will give you an idea of how the FDO protocols work. We will try to explain it using the FDO protocol reference implementation. The implementation can be built using this repository: https://github.com/secure-device-onboard/pri-fidoiot. The documentation can be found here: https://secure-device-onboard.github.io/docs-fidoiot/1.1.4/implementation-references/getting-started-guide/We assume that the reader is familiar with the basic protocols used in FDO. These are DI, TO0, TO1, and TO2. Here we will explain what happens in the background while these protocols are being implemented.
What is an Entity Attestation Token (EAT)?
An Entity Attestation Token (EAT) is a small blob of data containing cryptographically signed claims. The cryptographic signing secures the token so that the means to convey the token does not have to provide any security. For example, it can be transmitted by HyperText Transfer Protocol (HTTP), Constrained Application Protocol (COaP), or added into the extension fields of any protocol that supports extensions. EATs will often be conveyed in systems that use TLS for their own security needs, but TLS is not necessary for EAT. Typically, the Elliptic Curve Digital Signature Algorithm (ECDSA) is used for signing, and the token size is a few hundred bytes for the claims and signature. The claims contained in an EAT help the cloud-based service assess and decide whether to trust the device and its data. This “trust signal” could be used to decide whether to carry out a transaction the device is requesting.
Anatomy of an Entity Attestation Token:
The core of an EAT is the set of claims. The structure then surrounds the core to sign and secure the claims. Tokens can use CBOR or JSON format to express the claims (but not a mixture in one token). JSON is used widely in web services. CBOR is a binary size-efficient format.
Claims:
The claims section is a set of label-value pairs whereby each claim has a label and a value. In CBOR, the labels are typically simple small integers, and in JSON, they are strings. The claim values can be as simple as an integer or as complex as nested arrays with members of many types.
Signing Structure:
The standard signing formats of the modern COSE(CBOR Object Signing and Encryption) and JOSE(Javascript Object Signing and Encryption) are used. They can work with many different signing algorithms and key types. The headers identify the signing algorithm and, optionally, the signing key. This provides future proofing as signing algorithms, and key lengths change over time. The signature is at the end of the token and gives integrity protection to the claims. COSE is based on CBOR and is particularly size-efficient. For a 256-bit ECDSA signature, the headers and signature size are less than 90 bytes, most of which is the actual ECDSA signature.
