Re: [EAT] Security Levels (seclevel): why "restricted"

[Marcus Streets <[e-mail]>]

While it is right we should have high level broad brush level, for security the devil is always in the detail.
Even if 99% of reliers can make sensible decisions based on the three levels – the remaining 1% will need to drill down into the specific. However, if we really believe that there will be Trillions of IOT devices, that 1% is still Billions of devices.

I think the key is to have a basic attestation – but also allow the relying party to ask for more detailed reports if they require it.

The problem is that the details get messy fairly quickly – but provided everything is organized  logically reliers only need to be able to parse those details they are interested in and do not need to know how to process other branches.

For example if ACME having realized that there is a market for Avian detectors builds a unit.
Mr Coyote buys one and adds it to his system.
The console wants to verify the endpoint.
It needs attestation of the GPS system, time system and the avian detector but ignores the accelerometer.

So Coyote know where Roadrunner is, but is unaware of the falling rocks caused by the earthquake.

Next time he adds a seismometer – that needs to know about the accelerometer, but not the avian subsystem.

Either the report contains details of every subsystem and the relier ignores the bits they do not care about.
Or the initial attention lists the subsystems and the relier then asks for attestation of the details of those  subsystems they are actually interested in, potentially recursively as it works down a tree




From: EAT <[e-mail]> On Behalf Of Jeremy O'Donoghue
Sent: Friday, July 6, 2018 10:11 AM
To: Laurence Lundblade <[e-mail]>
Cc: Suresh Marisetty <[e-mail]>; [e-mail]
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"

I think we are on the correct track here. I also agree that we do not want to tie the levels to Common Criteria style attack potential in the EAT standard as this can change significantly over time, and is generally defined by processed that are not fully open.

The three proposed names (Unrestricted, Restricted and Hardware) are OK although I slightly prefer "Tamper Resistant" to "Hardware" (not enough to object strongly though).

It may be that some use-cases for the standard mandate specific security certification, but it would be better for these to have use-case specific claims, probably defined in different standards (not necessarily by IETF), for those certifications.

Here are some suggested examples - I think some explanatory text is required for them to make sense.

Wearable Activity Tracker: In this example, a wearable activity tracker has a micro controller running am operating system with a privileged kernel and various activity tracking applications running in user-space. An EAT is implemented as a user-space application using software cryptography. An EAT generated by such a device would have "Unrestricted" security level.

Desktop PC: In this example, a desktop PC has a certified hardware TPM, and the TPM implements the security functionality for an EAT. An EAT generated by such a device would have a "Hardware" (or "Tamper Resistant") security level.

Home IoT Hub: In this example, a home IoT hub runs Linux on an SoC which has ARM CPU with TrustZone. The EAT support is implemented in a Trusted Execution Environment which has been securely booted, and which contains at least a Root of Trust for Reporting (RTR). An EAT generated by such a device would have a "Restricted" security level.

Smart Refrigerator: In this example, a smart refrigerator runs Windows on an Intel device with SGX. The EAT support is implemented in under SGX. An EAT generated by such a device would have a "Restricted" security level.

Water Meter: In this example, a water meter was a low-power micro controller running on an RTOS and a Secure Element which provides security functionality including support for EAT. An EAT produced by such a device would have a "Hardware" security level.

I should note that there is some interesting discussion on Roots of Trust and suitable definitions of a Trusted Execution Environment  architecture taking place at the moment on the Teep mailing list. These might be useful background reading for those unfamiliar with GlobalPlatform terminology, which is the usual reference in this area. I should note that Teep has yet another slightly different view on Attestation which is limited essentially to the TEE itself.

Roots of Trust: https://www.ietf.org/mail-archive/web/teep/current/msg00326.html
TEE Architecture: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/

Jeremy

On 5 Jul 2018, at 19:21, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

So it seems there is some consensus about Unrestricted and Restricted and we do have the FIDO document to reference as reasonable criteria for that distinction. We also know there must be at least one level better than Restricted.

Since we are just going for coarse security levels here to avoid the rat hole, I’m going to suggest we stick to three. The HW level is something like this:

To claim HW level security the EAT implementation should implement most of the following:
 - Defend against circuit probing, at least a the PCB level and preferably at the chip level
 - Defend against RF and power analysis side channel attacks
 - Defend against clock and power glitching

So the three levels line up with common security technologies:
Unrestricted - Linux, Windows, MacOS…
Restricted - TrustZone, SGX, Microsoft VBS...
Hardware - SmartCard, SecureElement, TPM...

A good next step would be to create a big list of examples: phones, this IoT device, that IoT device, desktops, tablets, control units, fitbits, refrigerator, (physical) security camera…

LL


Here’s more info on what FIDO which does have more than 3 levels.

FIDO certification distinguishes HW level security by Common Criteria AVA_VAN rating, which relates to Common Criteria attack potential calculation, but I don’t think we want to do that here. It is very heavy and complex and it is for security certification, which I do not think we should go into here.

In more practical terms, the FIDO distinction can be described as chip-level attacks versus PCB-level attacks. An example of a PCB-level attack might be the removal of potting from the circuit board or drilling and probing embedded circuit board traces — attacks that can be carried out with equipment from Fry’s or Radio Shack. An example of a chip-level attack is the removal of the cap of the chip and using a laser to inject faults, which requires much more sophisticated equipment.






On Jun 29, 2018, at 11:12 AM, Suresh Marisetty <[e-mail]<mailto:[e-mail]>> wrote:

How about this:

Level 1 / Unrestricted
This is everything that doesn’t qualify for the other more secure levels.

Level 2 / Restricted
This uses an isolated environment to defend against network-originated SW-based large scale attacks

Level 3 / Simple Hardware
This uses simple hardware mechanisms to defend against captured devices

Level 3 / Advanced Hardware
This uses advanced hardware mechanisms to defend against captured devices

Simple and Advanced would be subjective, but anything above and beyond-2 is (3) .

Thanks
Suresh Marisetty


From: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Sent: Friday, June 29, 2018 10:36 AM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Cc: Suresh Marisetty <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"

Differences between level 2 and level 3 that I can think of.


  *   Level 2 should be resilient against remote attackers. Level 3 should be resilient against attackers with physical access to the EAT.
  *   Level 3 needs to be highly robust against local side channel attacks.

Typical evaluation practice looks at both the effort to identify an attack and the effort to usefully exploit it. We probably need to make some statement which addresses this, because the security problem is somewhat different for identification and exploitation, but I can't immediately think of any simple way to address that.

Jeremy



On 29 Jun 2018, at 18:24, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

I think an EAT claim for security level is probably only going to work as a rough characterization, a coarse classification into a small number of buckets.

If we try to have any fine-grained characterization we’re going to end up in long hair-splitting discussion — rat holes as they say.  Security characterization isn’t really linear as some use cases will be concerned about some types of attacks, others will be concerned about different attacks. Each vendor is going to have their own agenda.

I think formal security certification is a good way to characterize security, but I don’t think it belongs in IETF EAT documents that focus on bits-on-the-wire and interoperability. I would like to see EAT implementation certified at some point in the future, but by organizations like Global Platform, not IETF.

I don’t think it can be based on the cost of attacks, because that is difficult and expensive to measure. Common Criteria Attack Potential Calculation is a means to do exactly that and it can take months and tens or hundreds of thousands of dollars to measure it for an implementation.


So how to define our coarse levels?

Conceptually I propose something like this:

Level 1 / Unrestricted
This is everything that doesn’t qualify for the other more secure levels.

Level 2 / Restricted
This uses an isolated environment to defend against network-originated SW-based large scale attacks

Level 3 / Hardware
This uses hardware mechanisms to defend against captured devices

I believe we have a concrete definition of Restricted in the FIDO definition of a Restricted Operating Environment<https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-restricted-operating-environments-list_20170524.pdf>.  Anything that meets that criteria gets to claim Level 2 / Restricted. If it doesn’t meet that, then it’s Level 1 / Unrestricted. I don’t have such a handy definition for the distinction between Level 2 and Level 3, but I think we can come up with one.

LL





On Jun 27, 2018, at 11:31 AM, Suresh Marisetty <[e-mail]<mailto:[e-mail]>> wrote:

My proposal is  to have multiple security level claims and here is a thinking for three levels of security:


  1.  Level-1 – robustness against software attacks (self-certified)
  2.  Level-2 –  (1+) Hardware attacks that can be launched with <$cost
  3.  Level-3 – (2+) Hardware attacked launched with >$cost

I assume this is what the basic, substantial and high means below.  Unless we define what these mean, there can be various interpretations of it.

Thanks
Suresh Marisetty


From: EAT <[e-mail]<mailto:[e-mail]>> On Behalf Of Laurence Lundblade
Sent: Wednesday, June 27, 2018 10:44 AM
To: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"

I could agree on three.

That means things like the WiFi subsystem, the audio / video DSP and such on an SoC are lumped in with the high-level OS security level because they are not security-oriented. I think the security-orientation distinction is important for things like TEEs, SGX and such and wouldn’t want to lose it by lumping things like WiFi in with them.

The other thing I like about three and only three coarse levels is that it short-circuits detailed debates about one being slightly more secure than another and dragging us to 5, 6, 7… levels.

Although, after watching this (long but good) Project Zero presentation<https://www.err.ee/836236/video-google-0-projekti-tarkvarainseneri-ettekanne-cyconil> that discusses complexity of chips and their fabrication, I am tempted to add a fourth chip-only only level. The fourth level would always identify the chip based on a HW-only implementation of EAT.

LL





On Jun 27, 2018, at 2:12 AM, Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>> wrote:

I'm open to discussion on names. The main argument I am making is that we currently have four claims levels and three seems better aligned with industry practice - i.e. we should not distinguish between "restricted" and "restricted secure".

Jeremy




On 22 Jun 2018, at 17:05, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

Also, here’s<https://developer.android.com/training/articles/security-key-attestation#certificate_schema_securitylevel> Android’s security level distinction for Android attestation. They call their levels “Software” and “TrustedEnvironment”. This lines up with Unrestricted and Restricted.

LL





On Jun 21, 2018, at 2:22 AM, Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>> wrote:

I have been thinking about the seclevel claim, and while I agree that the claim is not related to security certification as such, the more I consider the semantics, the more I struggle with the difference between "Unrestricted" and "Restricted" security, since it seem to me that there is no practical difference in the security level that can legitimately be claimed between these cases - anecdotal evidence of security breaches in many devices which would meet the "Restricted" definition.

My suggestion, therefore, would be to remove "restricted" and perhaps to replace the claim names:

- "Basic" to replace "Unrestricted";
- "Substantial" to replace "Secure Restricted";
- "High" to replace "Hardware".

This also seems to align with emerging views on describing security (FIDO, eIDAS for example) which is trending towards describing security at one of three levels, which are generally couched in terms such as "basic", "substantial", "high".

Jeremy
_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat


_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.