Subject: [Secdispatch] First pass compare / contrast of EAT, RATS, NEA...

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Jul 2018 17:11:33 -0700

Please take this as a first pass frame up that needs a lot of confirmation and fill in for the various protocols mentioned here. I’m no where near up to speed on all of these to fill in other than guesses. Apologies in advance for the EAT bias.

Hopefully this is somewhat useful as taxonomy. I’m sure it will be useful for starting discussion. :-)

LL

The Data / Claims about the Entity / Device
(which of these are used varies widely by use case)

Proof entity is not a fake
The server sends a nonce to the device. The returns it “securely” either by signing or in a secured transport proving it has the key material that proves the device is not an emulator, made by some other manufacturer. [All - EAT, BRSKI, NEA, TPM, Zerotouch, RATS]

Unique Device Identifier
Identifies a unique individual device instance, for example a serial number. [EAT]

Entity Measurement
The device computes hashes running SW on the device and sends it to the server so server knows exactly what the device is doing. The measurement may be only at boot or may be periodic. [TPM, NEA]

Entity State 
Whether secure boot was enabled and debug is disabled. [EAT]

Manufacturer, Author and Version Information
Describes who made the HW and who authored the SW. Gives model and version information and HW and SW. [EAT, Android Key Store]

Application Information
Identifies the specific application the server is communicating with. For example which Android Application or which TA (Trusted Application). [EAT]

GNSS Position
The geographic position of the device. [EAT, FIDO]

Key Establishment / Provisioning
Additional keys for individual application / use cases. Usually by generating a key pair on device and sending its public key as a claim. [EAT, Android Key Store, FIDO]

Other
An implementation can allow extensions and/or app-specific data. [EAT, FIDO]

Syntax for Representing the Claims

CBOR/CDDL — EAT

XML — NEA, BRSKI via YANG, RATS via YANG

JSON — BRSKI via YANG, RATS via YANG

ASN.1 — Android Key Store via X.509 certificates

TLV — NEA

Custom — FIDO Packed Attestation

Securing and Transmitting the Claims To the Server
In all cases there is some sort key material provisioned to the entity during manufacturing. Usually it is a key pair. For example BRSKI can use IEEE IDevID and Intel uses ECDAA with EPID.

This Key material is used with some protocol to authenticate the claims sent to the server. Here’s a list of some of the protocols. They are not mutually exclusive and sometimes more than one is used. They are either independent blob signing protocols (COSE and S/MIME) or network transport securing protocols (TLS or DTLS), 

COSE Signing and Encryption — EAT, ZeroTouch

S/MIME (PKCS 7) - BRSKI

DTLS - Zerotouch

TLS - BRSKI

End-End Protocol
Protocols like BRSKI and NEA describe a relatively complete end-end protocol to a particular end like end IoT device provisioning.

EAT does not. It is intended to be carried in a wide range of other protocols. It is also self-secured so it doesn’t need any security services from those protocols.