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

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 21 Jun 2018 09:22:40 +0000

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 21 Jun 2018 13:57:51 -0700

Are you proposing just a terminology change? Would the definitions be the same?

Whatever names we use, I think the definitions could and should be improved. It is still a first draft.

I think the distinction between restricted and unrestricted is fairly well developed and documented in FIDO’s definition of an Allowed Restricted Operating Environment. The reference is here <https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-restricted-operating-environments-list_20170524.pdf>. I have duplicated some of the key text below.  Note that FIDO kind of has two scales for security, one used in the FIDO meta data service and one used for certification. FIDO Certification just distinguishes between restricted and unrestricted.

To me the security industry in the largest sense has roughly coalesced on three main security levels. Millions, maybe billions have been put into these three.

Unrestricted — high level OS’s like MacOS, Android, Linux, Windows.

Restricted — this primarily TEE’s and hypervisor based environments. There is very clear heavy investment in these as distinct from the unrestricted environments. Examples include TrustZone, Intel SGX and Microsoft VBS.

Hardware — there is huge investment in Secure Elements. At this point we all carry a few in our wallet. Apple Pay uses one. We also understand that TEE’s and such cannot achieve the same security levels as Secure Elements. They can’t have CPU performance level they have and the high security at the same time.

EAT is intended to work at all these levels and help a relying party know which they are interacting with.

LL

FIDO Authenticator Allowed Restricted Operating Environments List

FIDO Alliance 24 May 2017 

4. Requirements for Restricted Operating Environment to be Allowed
The AROE security configuration must be controlled by the vendor of the commercial device or its delegates or its suppliers.
The AROE must protect itself from modifications degrading its security. This includes modifications when powered-off. It hence requires a secure boot process of the AROE.
The AROE must provide full isolation from any rich OS or external devices or operating environments it connects with except for conveyance of protocol messages intended for communication with the rich OS and external devices or operating environments. As a consequence, it must not be possible for SW or HW on the same device but outside the AROE to modify any state, registers, memory or storage inside the operating environment.
The AROE should be security-oriented with the bulk of the functionality it hosts and provides being focused primarily on security (e.g., not large graphics engines, signal processors, general purpose app hosting, network stacks and such).
The apps hosted by the AROE should be primarily security-oriented (e.g., does not host thousands of downloadable games, complex productivity apps like word processors, or large scale network apps like web browsers).
A security oriented SW engineering practice should be followed 
Code is reviewed by security experts
A security patch system is in place
Security incidents are tracked
Security coding practice is followed System documentation is produced 

> On Jun 21, 2018, at 2:22 AM, Jeremy O'Donoghue <[email-masked]> wrote:
> 
> _______________________________________________
> EAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eat
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Jun 2018 09:05:19 -0700

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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 27 Jun 2018 09:12:18 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 27 Jun 2018 10:43:48 -0700

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 <[email-masked]> wrote:
> 
>> On 22 Jun 2018, at 17:05, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Jun 21, 2018, at 2:22 AM, Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
>>> 
>> 
>

---

From: Suresh Marisetty <[email-masked]>
Date: Wed, 27 Jun 2018 18:31:51 +0000

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 <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Wednesday, June 27, 2018 10:44 AM
To: Jeremy O'Donoghue <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"

I could agree on three.

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 <[email-masked]<mailto:[email-masked]>> wrote:

Jeremy

LL

Jeremy

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.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 29 Jun 2018 10:24:32 -0700

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 <[email-masked]> wrote:
> 
> 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
>  
> From: EAT <[email-masked] <mailto:[email-masked]>> On Behalf Of Laurence Lundblade
> To: Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Jun 27, 2018, at 2:12 AM, Jeremy O'Donoghue <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 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

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 29 Jun 2018 17:35:58 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Level 1 / Unrestricted

Level 2 / Restricted

Level 3 / Hardware

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 <[email-masked]<mailto:[email-masked]>> wrote:

Thanks
Suresh Marisetty

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

I could agree on three.

LL

Jeremy

LL

Jeremy

---

From: Suresh Marisetty <[email-masked]>
Date: Fri, 29 Jun 2018 18:12:41 +0000

How about this:

Level 1 / Unrestricted

Level 2 / Restricted

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 <[email-masked]>
Sent: Friday, June 29, 2018 10:36 AM
To: Laurence Lundblade <[email-masked]>
Cc: Suresh Marisetty <[email-masked]>; [email-masked]
Subject: Re: [EAT] Security Levels (seclevel): why "restricted"

Jeremy

Level 1 / Unrestricted

Level 2 / Restricted

Level 3 / Hardware

LL

Thanks
Suresh Marisetty

I could agree on three.

LL

Jeremy

LL

Jeremy