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

[Laurence Lundblade <[e-mail]>]

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]> 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:
>  
> Level-1 – robustness against software attacks (self-certified)
> Level-2 –  (1+) Hardware attacks that can be launched with <$cost
> 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 <https://www.ietf.org/mailman/listinfo/eat>
>  
>  
> _______________________________________________
> EAT mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/eat <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 <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.