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

[Jeremy O'Donoghue <[e-mail]>]

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