Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.
1485 Discussions

Error 0x4006, NUC 7i7BNH and all the non-existing solutions

X99
New Contributor I
1,573 Views

Hi everyone.

I've been facing a very common issue with Remote Attestation: error 0x4006, also known as "GROUP_OUT_OF_DATE" or even "your stack's not up to date".

There are dozens of topics here talking about this issue, some of them even face the issue with the exact same setup as mine.

I, of course, read all of them to find a solution. I took these steps:

  • Upgrade to latest BIOS
  • Upgrade CPU's microcode, even if previous BIOS upgrade should do it
  • Upgrade to the latest SDK/PSW/everything containing SGX

None of them fixed anything, I'm still facing the same issue. To be precise, I get these advisoryIDs:

  • INTEL-SA-00161
  • INTEL-SA-00219
  • INTEL-SA-00289
  • INTEL-SA-00381
  • INTEL-SA-00389
  • INTEL-SA-00320
  • INTEL-SA-00329

What bothers me is that many of these advise you to update BIOS (381, 289, 161...) or SGX stack (219...).

As I did all of what's advised, all I'm left with is Intel's lack of support for their own products. The platform I'm using was advertised as Intel's recommendation for SGX-related work, and now I'm in a situation where my platform cannot be trusted nor updated and is thus rendered useless for anything involving a remote attestation.

So I'm opening this thread to ask once for all, in the name of all the people left in the attestation ditch like me, for a decent support for Intel in the form of BIOS/microcode update that addresses all these issues. And by the way thank people like @Dr__Greg and @JesusG_Intel for their dedication.

Thanks a lot in advance.

0 Kudos
1 Solution
JesusG_Intel
Moderator
1,538 Views

Hello X99,


I'm sorry I do not have a better answer for you. You need a BIOS update with all of the right mitigations. Unfortunately, some SAs cannot be mitigated because the BIOS does not expose the functionality necessary, e.g. disabling integrated graphics.


How you parse the attestation report from IAS, detect the received SAs, and take action upon them is up to you as the ISV. Your description sounds reasonable.


Sincerely,

Jesus G.

Intel Customer Support


View solution in original post

5 Replies
JesusG_Intel
Moderator
1,560 Views

Hello X99,

 

We have guidance on SAs 161, 219, and 289 in Receiving ISV Enclave Trust Status as "Enclave NOT TRUSTED - Reason: CONFIGURATION_AND_SW_HARDENING_NEEDED" During Remote Attestation

 

The other SAs, SA-00381, SA-00389, SA-00320, and SA-00329, will require a BIOS update for your NUC. We are working with the BIOS team on this. Unfortunately, I cannot provide a timeframe on when a BIOS with the mitigations will be available.

 

IMPORTANT:

Whether the relying party should trust a quote with TCB issues is a policy decision. Security patches and recommended BIOS configurations harden the system against known vulnerabilities, and only the service provider can determine how much of a risk such a system presents. These decisions typically take the workload into account, as not all workloads are sensitive to specific vulnerabilities. For example, we have some customers that choose to keep Hyperthreading enabled although they get SA-00161.


Sincerely,

Jesus G.

Intel Customer Support


X99
New Contributor I
1,554 Views

Hi Jesus, thank you for these informations.

About the mentionned SAs:

  • 161: I disabled HT, but still having the issued. Microcode update didn't helped.
  • 219: Integrated GPU cannot be disabled from BIOS on NUC7i7BNH
  • 289: latest BIOS update did not solve the issue

About the "other SAs": this is the answer I was expecting, and I really hope we get this update one day. We have 40 of these NUCs, none of them can be updated.

Lat but certainly not least, about whether or not the TCB should be trusted or not. From what I read from this article, I understand that (as you said), it is up to the ISV RA server to determine if the ISV app and its enclave can be trusted or not. But how exactly? Should the ISV server parse the SAs list and, based on its content, simply choose to ignore msg4.status? I mean: what is the best practice to determine, in the non trusted/complicated case, whether or not to trust the platform?

 

0 Kudos
JesusG_Intel
Moderator
1,539 Views

Hello X99,


I'm sorry I do not have a better answer for you. You need a BIOS update with all of the right mitigations. Unfortunately, some SAs cannot be mitigated because the BIOS does not expose the functionality necessary, e.g. disabling integrated graphics.


How you parse the attestation report from IAS, detect the received SAs, and take action upon them is up to you as the ISV. Your description sounds reasonable.


Sincerely,

Jesus G.

Intel Customer Support


JesusG_Intel
Moderator
1,534 Views

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.


0 Kudos
X99
New Contributor I
1,534 Views

I will wait for a BIOS/microcode update, kudos to the BIOS team for the time they will take to address these issues.

About the trusting policy: that was what I was expecting, but I'm glad to hear it from someone at Intel

Thank you again for your time, your patience, and your devotion to the community.

Reply