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

["Wheeler, David M" <[e-mail]>]

With this “write down” approach, then, I would expect a minimal set of “requirements” that must be met.
For example, if there is any possible side-channel does that mean you cannot claim restricted?
Is one of the goals to create such a list of “basic requirements” for each level?

Dave W

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

With one Tamper/Hardware level your (4) and (5) would be lumped together. You pick your level like this:
- If you have enough security to meet characteristics for Hardware/Tamper, then claim that; if not…
- If you have enough security to meet characteristics for Restricted, then claim that; if not…
- Since you can’t claim anything else, claim unrestricted.

No claim at all means you are not claiming anything, not something less than the defined levels. Device security could be really good or not.

LL



On Jul 6, 2018, at 12:04 PM, Suresh Marisetty <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

Tamper resistant through hardware has multiple levels.  Take the following adversary model as an example.  The security levels should be enough to support or map to the adversary models:

The following is the full set of adversary categories:
1.       Remote Software Adversary/Hacker – maps to Restricted
2.       Network Adversary (MiM attacks on packet spoofing, injection, replay) – maps to Restricted
3.       Insider Adversary (Si Manufacturer, OEM, ODM) – maps to Restricted
4.       Simple Hardware Adversary (uses USB Dongles, Debug Port, Voltmeter, Port Scanner, IREM: simple side channel  etc) – maps to Tamper Resistant/Hardware
5.       Advanced Hardware or Invasive attack Adversary (Mill down, Focused Ion-Beam litho, Microscopy Probing) - ????

  1.  Others

Most devices cover 1-4 and, but (5) is a bit more complex.

When we say Tamper/Hardware: Are we covering (4) and (5) or just (4).

Thanks
Suresh Marisetty


From: Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 6, 2018 2:11 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"

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