Skip to main content

D3 Prior Art

In this section we describe the pre-existing data sources that can be used as part of the D3 system

Each of the following corresponds to a different dimension of the security analysis that could be subsumed into a D3 representations.

Type Identities​

The following mechanism all provide some method of either device type identity or user identity.

They have been categorised as weak or strong, depending on how hard they are to spoof (the trustworthiness of the statement)

In addition each method can be analysed in terms of its granularity

MAC address​

Weak type identity

It is possible to weakly infer the manufacture from the observed MAC address.

The first three sets of two hexadecimal numbers in a MAC Address identifies the card manufacturer.

This number is called OUI (organizationally unique identifier).

Mobilefish.com - MAC address lookup or manufacturer lookup

This is a very coarse grained, device type: manufacturer only.

There may be information pertaining to the model number in the manufacturers specific part of the MAC address, but this is of coarse highly variable.

A MAC address can be spoofed with relative ease.

MUD declaration (DHCP)​

Weak type identity

A MUD document can contain information relating to manufacturer and model number

https://datatracker.ietf.org/doc/html/rfc8520.

Specifically the following fields, provide information relating to device type data.

  • mfg-name
  • software-rev
  • model-name
  • firmware-rev

These fields are defined in the associated YANG specification https://datatracker.ietf.org/doc/html/rfc8348.

Each field is currently specified as a string.

MUD documents are referred to by the endpoint device using a number of methods

  • DHCP - this is weak in that an end point can easily spoof this reference. (i.e. impersonate another device)
  • An X.509 constraint https://1.ieee802.org/security/802-1ar/
  • Link Layer Discovery Protocol (LLDP) frame

The last two methods are more reliable.

Weak type identity 3: Delegated​

Weak type identity

As a general method the primary router could rely on information provided, by another router. This is essentially a delegated method, with no prescribed protocol. As such this comes with weak confidence

Strong type identify: MATTER certificate​

Strong type identity

The Matter specification https://csa-iot.org/all-solutions/matter/ provides a method for identifying type using an Device attestation certificate.

External

Links to external specification

Strong type identify: FIDO certificate​

Strong type identity

The FIDO IoT specification https://fidoalliance.org/specs/fidoiot/FIDO-IoT-spec-v1.0-wd-20200730.html provides a method of identifying type using an Entity Attestation Token, and specifically the OVDeviceInfo attribute

Strong type identify: iDevID certificate​

Strong type identity

https://1.ieee802.org/security/802-1ar/

https://ieeexplore.ieee.org/document/8423794

External

Details on external specification

Vulnerabilities​

There are many online databases of device vulnerabilities

https://cve.mitre.org/ and https://nvd.nist.gov/ provides a central and mostly definitive list and an API.

Behaviours​

External

Details on external specification

Firmware and software dependencies​

External

Details on external specification