The New World Order!

In the last edition Much Ado About Nothing we talked about the first principles of security viz. Integrity, Confidentiality, Authenticity & Access Control.

While that is still true, the New World Order which has been in the making for quite some time began to materialize over the last decade & and brought three significant changes to the world of computing, these being

• The phenomenon of “Always On Always Connected”
• Edge device started generating data to be consumed by the backend &
• The quest for extra-ordinary user experience

These heterogeneous edge devices of varying security capabilities are normally connected with each other via some or other mechanism to allow for a better user experience. This specific evolution opened up never seen before 24x7 access path for attackers.

Security engineers started building new security frameworks to fight back against? 24x7 highways available to hackers. These frameworks primarily rely on the principles of deny by default and the principle of least privilege (PoLP) more generically or (fondly!) known as Zero Trust Architecture.

Roughly speaking for hardware/software-based systems this Zero Trust Architecture translates into the requestor being able to prove to the requestee

• Its own unimpeachable identity
• The authenticity of the request &
• Ability to prove the truthfulness of current request… that it's not being replayed upon

Well-designed architecture balancing all security properties & and usability could provide reasonable security assurance to the requestee about the genuineness of the incoming request.

Let's take a couple of examples of how this zero trust architecture plays out at the hardware level & role of various security properties we talked about so far.

Say a SoC/Device/Cloud vendor has monetized services like changing HW configuration or allowing access to specific data/applications/capabilities based on the health of the device (its HW and SW configuration). Or think of an everyday example like a pool water quality monitoring device that would allow user access to his/her pool water data & and appropriate mitigations only if the subscription is active.

Every incoming request to the cloud or such pool service provider should prove the following claims in column A, these claims in turn are helped by security property in column B:

Trusted Identity

This is still an evolving concept. There are a few standards helping the industry work it out in an interoperable way, but I don’t believe the final word is out yet – again partly because we are yet to comprehend it fully as to mapping various scenarios/circumstances when such as identity matters & ways the device can identify itself. But a few methods & and standards worth mentioning:

Internet Engineering Task Force (IETF) Standard RFC 4122

This RFC4122 specification for A Universally Unique IDentifier (UUID) URN Namespace is specified at https://datatracker.ietf.org/doc/html/rfc4122

This standard provides the ability to generate a unique identifier for a device that is guaranteed to be unique in time and space. As it stands if all device/SoC makers follow this, identifiers generated out of this scheme will not collide with each other, no matter how many device/SoC makers use it now, used it in the past & and will use it in the future.

The limitation of this scheme is though it does not have an in-built mechanism to detect attacker tampering identifiers in transit, it would need to rely on additional cryptographic primitives to achieve unimpeachability.

Institute of Electrical and Electronics Engineers (IEEE) 802.1AR

Specifications for Secure Device Identity are specified at IEEE documentation https://standards.ieee.org/ieee/802.1AR/6995/

As specified Secure Device Identifier (DevID) is cryptographically bound to a device and supports authentication of the device's identity.

This method relies on Public Key Infrastructure (PKI) more commonly known as asymmetric cryptography to provide identity as well as the ability to furnish that identity in an unimpeachable way, thus overcoming the limitation of the previous method.

On the other hand, this method relies on some other primitives like a True Random Number Generator (TRNG) or Physically Unclonable Function (PUF) to get such an identity, if the underlying TRNG/PUF is not good enough, this method by itself can not guarantee uniqueness of these identifiers.

Direct Anonymous Attestation (DAA)

Trusted Computing Group (TCG) adopted Direct Anonymous Attestation(DAA) referred to at? https://trustedcomputinggroup.org/resource/direct-anonymous-attestation/

This standard or method has the unique property that while on the one hand it provides a Secure Device Identifier cryptographically bound to a device and supports authentication of the device’s identity, on the other hand, it does so while addressing privacy concerns or loss of Internet anonymity.

In the previous two methods, the verifier can identify the specific SoC/device by looking at the identifier embedded in the incoming request, but when using DAA all that the verifier can infer is that the request originated at one or other genuine SoC/device of the pool of SoCs/devices managed by DAA instance, but not to the specifics of the SoC/device. The requestor is hence genuine but anonymous.

Needless to say, this method has its own limitations. The previous two methods do not necessarily need an external SoC/device entity to generate its own identity, whereas DAA does require DAA capable backend because of its very peculiar cryptographic protocol (leaving it to y’all to find its specifics).

Some examples of DAA are ISO/IEC 20008 as well as Intel's Enhanced Privacy ID (EPID) 2.0.

Trusted Time

Trusted time on the other hand would require an additional electronic circuitry on the SoC/device commonly known as Real Time Clock (RTC). Some reference on what is it & and how it work is here https://en.wikipedia.org/wiki/Real-time_clock

Typical power sources for an RTC module are coin cells or capacitors. Such RTC can be interfaced externally or be on the die of the SoC itself. Its usability varies depending on how exposed it is to attackers.

Its time count keeps moving forward, one of the properties being it can not be adjusted once it starts running. Removing power sources resets the clock thus indicating something has gone wrong.

When such circuitry is under appropriate access control and used by SoC/device to inject time stamps in the outgoing requests or compare time stamps from incoming requests, it is typically referred to as Secured Real Time Clock (SRTC).

So far so good, but how does a SoC/device get this trusted identity & and trusted time? Embedding a trusted identity and trusted time to SoC/device trustfully, even so, more for the entire new generation of evolving architecture is a topic of discussion & and debate if not contention, and the bigwigs of the industry including some of my colleagues like Kathir (Nathan) Nadarajah Hemaprabhu Jayanna & Alex Branover are invested in this. Topic by itself altogether & and perhaps our next conversation. Till then see y’all!