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

GROUP_OUT_OF_DATE - what is the most recent microcode version?

Ofir_W_
Beginner
4,033 Views

Hello,

 

I know this topic of GROUP_OUT_OF_DATE came up several times, and typically updating BIOS resolved it. Yes, I am aware of this post: https://software.intel.com/en-us/comment/1911344#comment-1911344.

I called "sgx_report_attestation_status" on the "platform information blob". I got error 0x4006 (SGX_ERROR_UPDATE_NEEDED).

Looking at the "sgx_update_info_bit_t*" I got back from "sgx_report_attestation_status"   I see: ucodeUpdate == 1; csmeFwUpdate == 0; pswUpdate == 0;

Which I assumed meant I need a microcode update (while the ME and the PSW are OK). I have a NUC machine NUC7i7BNH, and the most recent bios update is from recent November (2017). This brings me to ucode version 0x70:

Output of /proc/cpuinfo:

vendor_id : GenuineIntel

cpu family : 6

model : 142

model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz

stepping : 9

microcode : 0x70

 

I even tried manually updating the microcode version to 0x80, but I still get GROUP_OUT_OF_DATE error. I wonder if the ucode has to be updated by the BIOS for it to "count" for SGX.

 

Any hints? Can it be in any way related to my client-side certificates I am using to communicate with IAS?

Is there a new BIOS update for NUC7i7 with the spectre/meltdown patched ucode?

 

Thanks!

 

Ofir

0 Kudos
21 Replies
Ofir_W_
Beginner
3,721 Views

As an update (issue still UNRESOLVED): 

I did dist-upgrade to my Ubuntu server 16.04.

Output of /proc/cpuinfo:
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
stepping        : 9
microcode       : 0x80
 
I rebooted, reinstalled SDK and PSW versions 2.1.1, rebooted again. I still get the same output from "sgx_report_attestation_status" saying that I need to update my microcode, even though it is at the latest version: 0x80.
 
Thanks
0 Kudos
Elephant
Beginner
3,721 Views

Hi,

I just want to report the same issue as Ofir.  I am getting the same error (GROUP_OUT_OF_DATE) on all 3 machines (2 intel server block and a lenovo laptop) on which the remote attestation were working a week ago.  Was there an announcement from Intel on some IAS changes?

Thanks.

Kind Regards,
Elephant

0 Kudos
Dr__Greg
Super User
3,721 Views
Good morning, I hope the week is going well for everyone. We are working to respond to all of this. I've been on a disrupted travel schedule, here is the best background information we can provide at the current time. Intel is forcing a Trusted Computing Base (TCB) recovery, in order to ensure that all SGX platforms are running updated microcode and platform software to mitigate the Spectre class of vulnerabilities. Our SGX Spectre analysis post/paper, which can found at the following locations:

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status-analysis-and-remediations ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf Has background information that discusses what is going on. There is a high probability that Intel wants to make sure that SGX capable platforms have support for Indirect Branch Restricted Speculation (IBRS) and/or the other speculation fencing primitives that have been developed. It would be logical to assume that the ENCLU[EENTER] and ENCLU[EXIT] instructions are being modified to use IBRS to implement speculation fencing between untrusted and trusted (enclave) execution domains. The IAS development servers began generating 'GROUP_OUT_OF_DATE' enclave attestation responses on 2/6/2018 for platforms that have not been properly updated. The IAS production servers will begin reporting this condition on 3/20/2018. The security versions for the provisioning and quoting enclaves have also been incremented as part of this response. This is being used to indicate the enclaves have been updated to implement speculative fencing remediations. So, in order for remote attestation to work, the platform must have updated firmware/microcode as well as updated binary enclaves. Our concern, as noted by previous posts, is that the required update might be a firmware/BIOS level update, not just a userspace microcode injection update. Unless there is alternative guidance, this could mean that a lot of platforms will no longer be usable for SGX if remote attestation is a requirement. This is secondary to the well understood fact that a lot of commodity motherboard/platform manufacturers simply do not provide firmware upgrades for their platforms. If the previous posts are correct and the IAS development servers are reporting 'GROUP_OUT_OF_DATE' with BOTH updated userspace injected microcode and binary enclaves, there is a high probability that a vendor supplied firmware update is also required, if it will ever even be available. On the plus side this is the way that SGX was designed to operate. The intention of this technology is to provide a root of trust to guarantee the operational integrity of enclaves running on a platform. Providing that guarantee means that platforms must be implementing appropriate mitigations for known security vulnerabilities. On the negative side this collides rather dramatically with the notion of commodity computing platforms, which are largely abandoned after their initial release. Commodity platforms are going to be the only game in town when it comes to security. If a technology such as SGX is going to be of utility, there must be a time frame guarantee associated with firmware that is required in order to make the platform viable from a security perspective. All of this has the potential to provide a forum for some very interesting, and much needed, conversations. I haven't slept in 36 hours, once I recover from that we will see if we can find the cycles to implement more testing in our lab and possibly put together a formal guidance paper on all of this. Dr. Greg

0 Kudos
yu_d_
Beginner
3,721 Views

Hi Dr. Greg,

Thanks for your effort. But we still have problems and getting group out of date error no matter what the firmware is.

I have four testbeds: (1) Intel 8086k + Gigabyte Z370 AORUS, (2) Intel Xeon E3 1280v5 + Supermicro X11SSH-F, (3) Intel Xeon E3 1280v6 + Supermicro X11SSH-F and (4) Intel Compute Stick STK2M3W64CC.

This week I've updated all bios firmware of them by flashing the most recent bios firmware provided by Gigabyte/Intel/Supermicro and I'm 100% sure that they are the latest version (released after April 2018). And I have followed the instructions provided by Intel to upgrade the microcode to the latest version 20180703.

But I'm still getting GROUP_OUT_OF_DATE error in the report.

Is there anything I could do to get an OK? or could you please provide a combination of CPU+motherboard+BIOS firmware which satisfies the security requirement and get an OK in report? I feel desperate and struggling with my testbeds and cannot figure out anything. Definitely need your help.

Thanks,

Yu

 

Greg W. wrote:

Good morning, I hope the week is going well for everyone.

We are working to respond to all of this. I've been on a disrupted travel schedule, here is the best background information we can provide at the current time.

Intel is forcing a Trusted Computing Base (TCB) recovery, in order to ensure that all SGX platforms are running updated microcode and platform software to mitigate the Spectre class of vulnerabilities. Our SGX Spectre analysis post/paper, which can found at the following locations:

https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status...

ftp://ftp.idfusion.net/pub/sgx/sgx-spectre-meltdown.pdf

Has background information that discusses what is going on.

There is a high probability that Intel wants to make sure that SGX capable platforms have support for Indirect Branch Restricted Speculation (IBRS) and/or the other speculation fencing primitives that have been developed. It would be logical to assume that the ENCLU[EENTER] and ENCLU[EXIT] instructions are being modified to use IBRS to implement speculation fencing between untrusted and trusted (enclave) execution domains.

The IAS development servers began generating 'GROUP_OUT_OF_DATE' enclave attestation responses on 2/6/2018 for platforms that have not been properly updated. The IAS production servers will begin reporting this condition on 3/20/2018.

The security versions for the provisioning and quoting enclaves have also been incremented as part of this response. This is being used to indicate the enclaves have been updated to implement speculative fencing remediations. So, in order for remote attestation to work, the platform must have updated firmware/microcode as well as updated binary enclaves.

Our concern, as noted by previous posts, is that the required update might be a firmware/BIOS level update, not just a userspace microcode injection update. Unless there is alternative guidance, this could mean that a lot of platforms will no longer be usable for SGX if remote attestation is a requirement. This is secondary to the well understood fact that a lot of commodity motherboard/platform manufacturers simply do not provide firmware upgrades for their platforms.

If the previous posts are correct and the IAS development servers are reporting 'GROUP_OUT_OF_DATE' with BOTH updated userspace injected microcode and binary enclaves, there is a high probability that a vendor supplied firmware update is also required, if it will ever even be available.

On the plus side this is the way that SGX was designed to operate. The intention of this technology is to provide a root of trust to guarantee the operational integrity of enclaves running on a platform. Providing that guarantee means that platforms must be implementing appropriate mitigations for known security vulnerabilities.

On the negative side this collides rather dramatically with the notion of commodity computing platforms, which are largely abandoned after their initial release.

Commodity platforms are going to be the only game in town when it comes to security. If a technology such as SGX is going to be of utility, there must be a time frame guarantee associated with firmware that is required in order to make the platform viable from a security perspective.

All of this has the potential to provide a forum for some very interesting, and much needed, conversations.

I haven't slept in 36 hours, once I recover from that we will see if we can find the cycles to implement more testing in our lab and possibly put together a formal guidance paper on all of this.

Dr. Greg

0 Kudos
Dr__Greg
Super User
3,721 Views
Good morning to Yu and the group. We have done an independent implementation of a PSW to support our work with SGX on intelligent network endpoint devices, ie. IOT, SCADA etc. This includes all of the infrastructure needed to implement bilateral enclave<->enclave attestation. As a result our tooling offers a great deal of diagnostic information regarding attestation status. If the attestation quote status is GROUP_OUT_OF_DATE or GROUP_REVOKED the platformInfoBlob field provides information on why IAS feels the quoting platform does not have a Trusted Computing Base (TCB) which meets the minimum required security level. One of the elements of the platform_info structure is a two byte array (sgx_tcb_evaluation_flags) which contains a bitwise encoding of the IAS service has concluded the TCB is not uptodate. There are three issues commonly reported; the CPU security version and the security versions of the quoting (QE) and sealing (PCE) enclaves. The platform_info structure also contains a structure element that encodes the recommended CPU security version (SVN) as well as the security versions of the two enclaves. Here is an example of output of a quote generated by one of our lab machines that has not received a microcode update and is running old versions of the two enclaves: Platform Info Report: EPID group flags: 4 EPID group out of date. TCB evaluation flags: 7 CPU svn out of date. QE enclave out of date. PCE enclave out of date. Recommended platform status: CPU svn: 07070101010100000000000000000000 ISV svn: 5 Of interest in the report body is the current CPU security version reported by the platform that is as follows: cpusvn: 04040204ff0200000000000000000000 One of the platforms we work with in our development lab are the Intel ComputeSticks. I can confirm that upgrading a STK2MV64CC to the current firmware released by Intel results in IAS returning a report indicating that the CPU security version is valid. I'm running out of time now but I can get the CPUSVN off that platform if there is interest. I'm assuming you are running the latest version of the Intel PSW/SDK so your quoting and sealing enclaves meet TCB standards? The next question would be are you using the Intel test or production IAS services. There have been reports in this forum of having issues with certificates and the like on the test IAS services. If you have upgraded your platforms to the most current firmware levels the only remaining issues are the security status of the enclaves. Either that or IAS is getting confused on what is being presented. The AESM is very much a block box but if you could somehow capture the response from the REST request that comes back from IAS we could run it through out tooling and decode precisely what IAS is thinking about with respect to the platform TCB that is generating the quotes you are receiving. Our enclave<->enclave security model does a lot of attestations since we poll INED's for their platform security status that is maintained inside of an enclave. Each connection results in two attestations as the enclaves verify that the communication endpoints are secure. We use the production IAS services exclusively and we found it to be very solid, hence the question on which service you are using. Hopefully the above information is helpful. Have a good day. Dr. Greg
0 Kudos
yu_d_
Beginner
3,721 Views

Hey Dr. Greg, you're explanation is so much clear and we really appreciate your help.

I'm pretty much sure I'm using the up to date version of PSW (ubuntu linux desktop, v2.2), QE and PCE on my STK2MV64CC. They are the following:

libsgx_pce.signed.so, sha256:5f363cc4606495076881c3c321034114647b0420a0a5fda5c8f7b4dc260d8f07, metadata->enclave_css.body.isv_svn: 0x6

libsgx_qe.signed.so, sha256:dd09f9a9b6fedfcd988992067caa93627ad81167d8ae93b853644270a628013e, metadata->enclave_css.body.isv_svn: 0x7

CPU microcode version is dumped from `dmesg | grep microcode`   microcode: sig=0x406e3, pf=0x80, revision=0xc2

And I double confirmed the response from IAS report REST api says GROUP_OUT_OF_DATE.

And I found platformInfoBlob in the REST api and here are three of them I generated from the compute stick:

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE0D553EE5D73D166CE0173499FDA3FF48E8C3C13302E5A541231C3F77830E5DB0DB627BECE23F6453F671F299D1B09C6B871792F701D562CBDDFB0979FE8D93906

1502006504000100000505020401800000000000000000000007000006000000020000000000000AE06088795DD5A3F336ED6507799853FDF7A386AD88F2B0863A2DB1A56660B406BB1FE2B46FEB555D88C86A8C2E4B8D946BEA591DBD87D5A0CEC749B72AA86D710B

These Hexstrings are all 210 bytes long. The IAS specification says that this is base16 encoded. So the decoded platformInfo should be 105 bytes.

I looked through the SDK APIs and find that it should be decoded by sgx_report_attestation_status. However, the sgx_platform_info_t is only 101 bytes, not 105! I tried to send the first 101 bytes to sgx_report_attestation_status but it always returns SGX_ERROR_INVALID_PARAMETER.

Updated: Found the correct demonstration at the official intel sgx remote attestation sample here. I remove the 4-byte TSV header and now sgx_report_attestation_status works perfectly. The only thing matters is the second parameter: attestation_status. If I pass 0 to it, ucodeUpdate will equal to 0. If I pass anything other than 0, ucodeUpdate will equal to 1. 

This does not make sense. Whether or not the attestation succeed cannot affect the truth of ucodeUpdate. What's more, the microcode is upgraded to the latest version and I've got something like yours from the official sgx-ra sample which indicates that our CPU_SVN are the same!

---- Enclave Report Details ------------------------------------------------

cpu_svn     = 0707ffffff0100000000000000000000
misc_select = 00000000
attributes  = 07000000000000000700000000000000
mr_enclave  = e5907c86e38f81ac092dcf470c69c79080b89c9e3a09c9f946625a41d83c83df
mr_signer   = bd71c6380ef77c5417e8b2d1ce2d4b6504b9f418e5049342440cfff2443d95bd
isv_prod_id = 0000
isv_svn     = 0100
report_data = f26f74388c1861996e12e76025b7affb0026588d5a7fb7190d98010b34b858930000000000000000000000000000000000000000000000000000000000000000

Thank you very much!

Best,

Yu

Greg W. wrote:

Good morning to Yu and the group.

We have done an independent implementation of a PSW to support our work with SGX on intelligent network endpoint devices, ie. IOT, SCADA etc. This includes all of the infrastructure needed to implement bilateral enclave<->enclave attestation. As a result our tooling offers a great deal of diagnostic information regarding attestation status.

If the attestation quote status is GROUP_OUT_OF_DATE or GROUP_REVOKED the platformInfoBlob field provides information on why IAS feels the quoting platform does not have a Trusted Computing Base (TCB) which meets the minimum required security level.

One of the elements of the platform_info structure is a two byte array (sgx_tcb_evaluation_flags) which contains a bitwise encoding of the IAS service has concluded the TCB is not uptodate. There are three issues commonly reported; the CPU security version and the security versions of the quoting (QE) and sealing (PCE) enclaves. The platform_info structure also contains a structure element that encodes the recommended CPU security version (SVN) as well as the security versions of the two enclaves.

Here is an example of output of a quote generated by one of our lab machines that has not received a microcode update and is running old versions of the two enclaves:

Platform Info Report:

EPID group flags: 4

EPID group out of date.

TCB evaluation flags: 7

CPU svn out of date.

QE enclave out of date.

PCE enclave out of date.

Recommended platform status:

CPU svn: 07070101010100000000000000000000

ISV svn: 5

Of interest in the report body is the current CPU security version reported by the platform that is as follows:

cpusvn: 04040204ff0200000000000000000000

One of the platforms we work with in our development lab are the Intel ComputeSticks. I can confirm that upgrading a STK2MV64CC to the current firmware released by Intel results in IAS returning a report indicating that the CPU security version is valid. I'm running out of time now but I can get the CPUSVN off that platform if there is interest.

I'm assuming you are running the latest version of the Intel PSW/SDK so your quoting and sealing enclaves meet TCB standards?

The next question would be are you using the Intel test or production IAS services. There have been reports in this forum of having issues with certificates and the like on the test IAS services.

If you have upgraded your platforms to the most current firmware levels the only remaining issues are the security status of the enclaves. Either that or IAS is getting confused on what is being presented.

The AESM is very much a block box but if you could somehow capture the response from the REST request that comes back from IAS we could run it through out tooling and decode precisely what IAS is thinking about with respect to the platform TCB that is generating the quotes you are receiving.

Our enclave<->enclave security model does a lot of attestations since we poll INED's for their platform security status that is maintained inside of an enclave. Each connection results in two attestations as the enclaves verify that the communication endpoints are secure. We use the production IAS services exclusively and we found it to be very solid, hence the question on which service you are using.

Hopefully the above information is helpful.

Have a good day.

Dr. Greg

0 Kudos
Dr__Greg
Super User
3,721 Views

Hi Yu, I hope this note finds your day going well.

Thanks for forwarding along the diagnostic information.  It was helpful in better understanding the issue that you are running into.  At this point in time the most important information that would help clarify what is going on is whether you are using the test or production instances of IAS to generate the reports for the Compute Stick quotes?

We ran the Base16 encoded platformInfoBlobs from your ComputeStick quotes through our PIB decoding tool.  The IAS instance you are using is saying the same thing in all three instances, that security version of the CPU that generated the quotes was not consistent with the currently specified Trusted Computing Base (TCB) for the platform.

I'm attaching the output from the following command to this post:

./sgx-decode-pib -b 1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

As you can see in the output IAS indicates the CPU security version is out of date and recommends that the correct CPUSVN is as follows:

05050204018000000000000000000000

If I interpret your posting correctly the CPUSVN in your report is as follows:

0707ffffff0100000000000000000000

While the 128 bit field encoding is, to our knowledge, unspecified.  It has been our experience that the first couple of digits are linear with respect to higher, ie. more recent versions, of platform firmware.  That suggests that your ComputeStick is running something more recent then what the IAS is recommending as the correct CPUSVN TCB.

I'm attaching the output from a utility that we have in our PSW/SDK which generates an enclave report on the local host and submits that to IAS for verification.  I ran the utility on one of our STK2MV64CC ComputeSticks which is running the most current firmware as of early June.  As you can see in the log output production IAS indicates the CPUSVN TCB for the process is correct.  It is notable that your CPUSVN is roughly consistent with ours, at least in the leading digits which seems to roughly correlate with firmware version.

All of this takes us back to why we are asking about which IAS instance you are attesting against.  As I've noted previously our PSW/SDK follows a model where attestations are done by the enclaves themselves.  So the log is actually generated from inside of the enclave that generated the report.  Obviously we have OCALL's which implement the EPID loading and QE interactions since they cannot be done from inside of an enclave.  The OCALL's that execute the REST exchange with IAS are directed to the production IAS services.

If you look at the ISVSVN recommendation in your platform information report, ie. the quoting enclave security version, the instance of IAS you are using recommends 7.  If you look at the attachment that contains the debug output from our test attestation you will see that we receive a recommendation of 5.  There might be a possibility that Intel would recommend an alternate QE SVN depending on processor type but that seems highly unlikely given how they have set all of this up.

If we interpret your previous posts correctly you are seeing attestation failures across multiple platforms that you claim have all been upgraded to the latest firmware versions.  If whatever IAS instance you are using has its CPUSVN database out of kilter that would explain why you are seeing this issue across multiple platforms.  It would also explain why you are getting back a CPUSVN recommendation that seems entirely inconsistent with reality.

Intel sent out an SGX notification letter in late May indicating that a TCB upgrade would be conducted in order to address issues with their IPP cryptography and to reflect firmware upgrade requirements to address CVE-2018-3639 (Speculative Store Bypass).  Their policy seems to be to roll the TCB upgrade to their test IAS instance before their production IAS instance. If you are running against test and we are running against production that would further suggest why you are seeing issues and we are not.

So it would be extremely useful to the SGX community at large if you could confirm your IAS instance type.  It wouldn't be an unreasonable assumption, from a DEVOPS perspective, if they were to roll test to production in which case, in which case things would get ugly very quickly in SGX land..... :-)

Hopefully all of the above makes sense and is of further assistance, we will look forward to your response.

Have a good day.

Dr. Greg

Apologies for not doing a complete grammar/spelling review on my post, too tired... :-)

0 Kudos
yu_d_
Beginner
3,721 Views

Hi Dr. Greg,

Thanks so much for your time! We really appreciate your help and we're getting closer to the truth! Here are some facts which may be helpful:

(1) We are using the test-as server.

(2) We use Compute Stick STK2M3W64CC (the m3 stick instead of m5) with bios version v0057 (Intel says it's the latest one to the public) released on 5/16/2018, before the disclosure of CVE-2018-3639.

(3) We use linux-sgx-sdk v2.2 on ubuntu 16.04 desktop.

So here are my understandings, and please correct me if I'm wrong:

(1) the CPU microcode update of CVE-2018-3639 is required by the test-as IAS service. However, the corresponding BIOS/microcode update hasn't been released.

(2) the production IAS service does not require this update. So our platform "should" work well on the production IAS service (but we don't have access to production service).

Thanks again!

Best,

Yu

Greg W. wrote:

Hi Yu, I hope this note finds your day going well.

Thanks for forwarding along the diagnostic information.  It was helpful in better understanding the issue that you are running into.  At this point in time the most important information that would help clarify what is going on is whether you are using the test or production instances of IAS to generate the reports for the Compute Stick quotes?

We ran the Base16 encoded platformInfoBlobs from your ComputeStick quotes through our PIB decoding tool.  The IAS instance you are using is saying the same thing in all three instances, that security version of the CPU that generated the quotes was not consistent with the currently specified Trusted Computing Base (TCB) for the platform.

I'm attaching the output from the following command to this post:

./sgx-decode-pib -b 1502006504000100000505020401800000000000000000000007000006000000020000000000000AE066584E3E99C34056C7C566112BDCC13D4867E806A7FD7A79B10BF532ED07D5696FD4C5A45AD38A8FADBD43EDAA23114CBB3A5B397519DF84CBA644A7F2A8B3BD

As you can see in the output IAS indicates the CPU security version is out of date and recommends that the correct CPUSVN is as follows:

05050204018000000000000000000000

If I interpret your posting correctly the CPUSVN in your report is as follows:

0707ffffff0100000000000000000000

While the 128 bit field encoding is, to our knowledge, unspecified.  It has been our experience that the first couple of digits are linear with respect to higher, ie. more recent versions, of platform firmware.  That suggests that your ComputeStick is running something more recent then what the IAS is recommending as the correct CPUSVN TCB.

I'm attaching the output from a utility that we have in our PSW/SDK which generates an enclave report on the local host and submits that to IAS for verification.  I ran the utility on one of our STK2MV64CC ComputeSticks which is running the most current firmware as of early June.  As you can see in the log output production IAS indicates the CPUSVN TCB for the process is correct.  It is notable that your CPUSVN is roughly consistent with ours, at least in the leading digits which seems to roughly correlate with firmware version.

All of this takes us back to why we are asking about which IAS instance you are attesting against.  As I've noted previously our PSW/SDK follows a model where attestations are done by the enclaves themselves.  So the log is actually generated from inside of the enclave that generated the report.  Obviously we have OCALL's which implement the EPID loading and QE interactions since they cannot be done from inside of an enclave.  The OCALL's that execute the REST exchange with IAS are directed to the production IAS services.

If you look at the ISVSVN recommendation in your platform information report, ie. the quoting enclave security version, the instance of IAS you are using recommends 7.  If you look at the attachment that contains the debug output from our test attestation you will see that we receive a recommendation of 5.  There might be a possibility that Intel would recommend an alternate QE SVN depending on processor type but that seems highly unlikely given how they have set all of this up.

If we interpret your previous posts correctly you are seeing attestation failures across multiple platforms that you claim have all been upgraded to the latest firmware versions.  If whatever IAS instance you are using has its CPUSVN database out of kilter that would explain why you are seeing this issue across multiple platforms.  It would also explain why you are getting back a CPUSVN recommendation that seems entirely inconsistent with reality.

Intel sent out an SGX notification letter in late May indicating that a TCB upgrade would be conducted in order to address issues with their IPP cryptography and to reflect firmware upgrade requirements to address CVE-2018-3639 (Speculative Store Bypass).  Their policy seems to be to roll the TCB upgrade to their test IAS instance before their production IAS instance. If you are running against test and we are running against production that would further suggest why you are seeing issues and we are not.

So it would be extremely useful to the SGX community at large if you could confirm your IAS instance type.  It wouldn't be an unreasonable assumption, from a DEVOPS perspective, if they were to roll test to production in which case, in which case things would get ugly very quickly in SGX land..... :-)

Hopefully all of the above makes sense and is of further assistance, we will look forward to your response.

Have a good day.

Dr. Greg

Apologies for not doing a complete grammar/spelling review on my post, too tired... :-)

0 Kudos
Dr__Greg
Super User
3,721 Views

Hi Yu, I hope your day is going well.

Thanks for taking time to provide the feedback that you are using the test iAS instance.  We had anticipated that would be the case based on the results we are seeing.

If it would be possible, could you run an attestation report on quotes generated from two other different systems and capture the Base16 encoded Platform Information Report from the REST message, that will help confirm what we believe is happening.

With respect to the two questions you pose:

> (1) the CPU microcode update of CVE-2018-3639 is required by the test-as IAS service. However, the corresponding BIOS/microcode update hasn't been released.

> (2) the production IAS service does not require this update. So our platform "should" work well on the production IAS service (but we don't >have access to production service).

Based on the platform information reports from the ComputeStick, it doesn't appear the test IAS instance is returning a CPUSVN recommendation that makes any sense.  This suggests the test instance may be using at least a partially faulty CPU TCB database.  That is why it would be helpful to check the platform information reports generated by other hardware.

So I suspect your solution will work against the production IAS instance but to verify that we need to prove that the test IAS instance isn't working properly.  If our theories are correct and Intel is testing their planned TCB upgrade on the test IAS instance we need to figure out what is going wrong in order to prevent these possible anomalies from propagating to the production instance.

Hopefully all of the above is useful information.

We will look forward to any further feedback you have time to provide.

Dr. Greg

0 Kudos
Frieder1
Novice
3,721 Views

Hi Dr. Greg,

I'd like to revive this thread as we are experiencing the same problem: Running the remote attestation against test-as fails with a GROUP_OUT_OF_DATE error. It reports the following intel advisories: INTEL-SA-00220,INTEL-SA-00270,INTEL-SA-00293 (These are all advisories which have been addressed with the latest microcode released 2019/11/15)

The code is run on a OVH infra-1 server (Intel(R) Xeon(R) E-2274G CPU @ 4.00GHz) with latest microcode revision 0xca loaded early on runtime. (BIOS does not have this microcode)

running the sgx-ra-sample project; the client returns this message:

---- Enclave Trust Status from Service Provider ----------------------------
Enclave Trust is NOT TRUSTED and COMPLICATED. The client is out of date.
----------------------------------------------------------------------------

---- Platform Update Required ----------------------------------------------
The following Platform Update(s) are required to bring this
platform's Trusted Computing Base (TCB) back into compliance:

  * The CPU Microcode needs to be updated.  Contact your OEM for a platform

----------------------------------------------------------------------------

This is Msg4 from the Server:

---- Copy/Paste Msg4 Below to Client ---------------------------------------
0100000004000100000d0d02040180030000000000000000000a00000b000000020000000000000b54d9f5e4777b23fcd5385711113789940464d076e8e36eec9a06e71922f501775e1570b2f2c8e6272b36892bd9615291f720b7112e73530a479729d451e6ee7e67
----------------------------------------------------------------------------

I'm out of ideas. Does the microcode need to be passed to the cpu during BIOS initialization to be accepted by sgx?

Regards

 

0 Kudos
Frieder1
Novice
3,721 Views

Additional information:

sgx-ra-sample server outputs the enclave report details:

---- Enclave Report Details ------------------------------------------------
cpu_svn     = 060e0305ff8001000000000000000000
misc_select = 00000000
attributes  = 07000000000000000700000000000000
mr_enclave  = 194b7ca823afd276108c309f3e03f2341bc1b6d465f69c29ce9d3500265faa21
mr_signer   = bd71c6380ef77c5417e8b2d1ce2d4b6504b9f418e5049342440cfff2443d95bd
isv_prod_id = 0000
isv_svn     = 0001
report_data = c2d58984d2da10e66d51ad89b3070e786727f7e890fb00a7bb92a383753a24c20000000000000000000000000000000000000000000000000000000000000000

 

the cpu_svn of 060e0305ff8001000000000000000000 seems to be lower than the one recommended in the PiB (that is 0d0d0204018003000000000000000000). I've now disabled early loading the microcode by the linux kernel and have run the sgx-ra-sample again. The Enclave Report Details now report a slightly different cpu_svn (06060305ff8001000000000000000000). What does this mean? Am I correct to assume that if the cpu_svn has changed after upgrading the microcode then the microcode can be early loaded via the kernel and does not need to be provided by the BIOS to be accepted by sgx remote attestation?

Then this means, that IAS is reporting a wrong svn. Maybe there will be a new microcode patch release very soon?

Regards

0 Kudos
Dr__Greg
Super User
3,721 Views

Good morning Jay, I hope this note finds your morning starting well.  My apologies for the delay in responding, we have been dealing with microcode issues as well..... :-)

Your XEON 2274G processor will need to be at a security version (CPUSVN) that has a '0d' prefix in order to be in compliance with the Intel TCB specification that went into full production on 1/7/2019.  The recommendation from IAS that you are receiving in the Platform Information Report is correct.

The 128 bit CPUSVN is technically 'opaque' but higher versions in the first two hexadecimal characters have always been 'newer'.  As your experience suggests, the following digits probably represent a microcode 'errata' or patch level.  In your case allowing the early microcode load to occur causes the second two hexadecimal digits to advance from '06' to '0e'.

As the documentation that comes with the Intel microcode updates indicates, not all microcode patches are equal.  The microcode that gets loaded by early Linux system initialization is more or less a 'patch' that is used to implement 'fixes' to the microcode and doesn't represent a full microcode implementation for the processor, that has to come through a BIOS or firmware upgrade.

So pester your vendor for an update.

SGX is interesting in that it tends to demonstrate how woefully unprepared our industry is for addressing the implications of deploying fully secure and trusted platforms.  Our SRDE enforces full TCB compliance for enclave<->enclave communications and our experience has demonstrated that you have to be really on the ball in order to guarantee that systems in the field are capable of delivering on this mandate.

The other issue that all of this raises, that no one is even remotely talking about, is what all of this means with respect to the effective lifetime of secure platforms.  Since it appears that major or security sensitive firmware upgrades require platform BIOS updates, the security lifetime of systems is the length of time over which BIOS/firmware upgrades are available.

I could go on but I need to get at least a little sleep.

Just as an aside, if you do get updated firmware for the platform make sure that you look at the remote attestation sample code.  There is a function call that is commented out in the sample code that needs to be called in order to trigger AESM to re-provision the EPID to the platform.  A platform will report that it is out of date even after the security enclaves are upgraded and in the face of a compliant SVN if the EPID that is used to sign the quote is still bound to the previous Platform Information state.  The EPID needs to be re-provisioned in order to bind the platform to its new security state.

I hope the above information is helpful.

Have a good remainder of the week.

Dr. Greg

 

0 Kudos
Frieder1
Novice
3,721 Views

Hi Dr. Greg,

thanks for clarifying. With this information at least we do know now where we stand. Yes, indeed with all of these new hardware flaws being revealed we also need to think about whether or not it makes sense to actually build a product we can sell on top of SGX. I've read one of your threads during the L1TF revelation where Intel took 2 weeks to supply updates for their own hardware, where SGX production environements were not attesting correctly. That's a product one cannot sell...

Thanks for your help!

Regards

0 Kudos
Dr__Greg
Super User
3,721 Views

Hi Jay, I hope your weekend is going well, we are dealing with a blizzard up here in the Upper Midwest.

I know it tends to be frustrating. but don't throw SGX out with the bathwater.  Despite the micro-architectural problems, it is remarkable technology and nothing else out there provides the type of capabilities it can bring to the table.  Part of the challenge with having an attestable hardware platform revolves around the economics of security. rather then fundamental failings with respect to SGX as a technology.

In our case, a hardware vendor had the necessary microcode for months but had not elected to release a firmware upgrade.  That isn't something you can fault Intel. or the technology for.  It is more of a statement that hardware vendors don't feel compelled to deliver security updates in a timely fashion.  Fixing that problem requires addressing the general problem of the economics of security, an issue which our country hasn't even begun to understand.

For example, the metrics of all this would be radically different if there was legislation that required any SKU's, that were vended to taxpayer dollars, to have a guarantee of hardware security update availability. for say seven years, after the date of introduction of the hardware.  This surrounds the big question that SGX calls to the table, that no one is talking about, which is what is a reasonable expectation of the period of time over which security relevant updates should be available.  Currently. the economics of security. mean that vendors simply want to pitch hardware over the fence and forget about it, which means that a security industry or eco-system will never develop.

We are having conversations with senior levels of movers and shakers regarding what attestation and a statement about platform security means.  At the end of the day. the issue comes down to what the relying party is willing to accept, which by extension means, what liability constraints the relying party has with respect to making that decision.

In any event. the VO that is resuscitating me from an afternoon of moving snow, is beginning to hit me. so I should probably refrain from further commentary... :-)

Good luck with your security projects.

Dr. Greg

0 Kudos
Zavalyshyn__Igor
Beginner
3,721 Views

Hi,

This topic is exactly what I've been looking for. For some reason there is not much info out there on what can be done if you receive a "GROUP_OUT_OF_DATE" message from the IAS besides updating a BIOS and an SGX SDK versions. Now, I've done all of that and I, as an original author of this thread, still get that message when trying to run a remote attestation sample code from here

As Dr. Greg pointed out there might be an issue on the IAS side. More specifically on the non-production test (development) service which I'm using as well. As I understand it, IAS has a slightly different understanding of what my CPU firmware should be as compared to the one I'm using now with the latest intel-microcode Linux package, SGX SDK, PSW and driver, and, finally, BIOS.

The IAS report I'm getting is as follow

platformInfoBlob  = 1502006504000100000D0D02040101030000000000000000000A00000B000000020000000000000B70ADF8693B3B5632C018AB8D19C5306B813FF57D6C137F36D2746477FD9EEE01A37EFB0E1323B89617C3174E24925CF4638264A94789B468892FF6CE66CE4C4D5A

cpu_svn     = 090effffff0201000000000000000000

 

Now the main question I want to ask is if I can do something about it? I'm not sure how to decode the pib but maybe I can install the version of SDK, driver, BIOS that the IAS expects? Is there any way to solve this and have remote attestation working?

Any help is much appreciated. Thanks

P.S. I'm using Intel NUC machine NUC7i7BNH for my tests and it makes it even more irritating that Intel can't support the very own hardware they sell.

 

0 Kudos
li__congcong
Beginner
3,721 Views

What is the recommended value of CPU_SVN now? The value of CPU_SVN in our machine Dell XPS is 0d0effff028000000000000000000000. However, it still  reports an error of GROUP_OUT_OF_DATE.  I am sure I have got the latest bios update. What should I do? How to increase the value from 0d to 0e ?

PS:  PIB:04000f00000e0e02040180060000000000000000000b00000b000000020000000000000b8570b4f672c4fec106b9374419b6a8de2c00be29ec32c40b173ccb65d9d48c3246b01d6b7fdf1af9d413de44cd0cfc39a5fdcf2e36343fb034839b668755ee6fa8.

0 Kudos
JesusG_Intel
Moderator
3,721 Views

Hello Congcong,

The CPUSVN is dependent on the particular CPU. It seems that the uCode in your BIOS is out of date. Most CPUs recently got updated to SVN 0e, which your early load uCode (BIOS) is not at. Your code is at 0d. Please contact your OEM to deliver an updated BIOS that includes the latest uCode.

BTW, this also applies to Igor from the post above.

Regards,

Jesus

0 Kudos
li__congcong
Beginner
3,721 Views

Garcia, Jesus L (Intel) wrote:

Hello Congcong,

The CPUSVN is dependent on the particular CPU. It seems that the uCode in your BIOS is out of date. Most CPUs recently got updated to SVN 0e, which your early load uCode (BIOS) is not at. Your code is at 0d. Please contact your OEM to deliver an updated BIOS that includes the latest uCode.

BTW, this also applies to Igor from the post above.

Regards,

Jesus

 

Thanks for your timely reply.  Does that mean I  can do nothing but wait until my OEM delivers an update of BIOS? Are there any other possible solutions?

0 Kudos
JesusG_Intel
Moderator
3,721 Views

Hello Congcong,

The only thing you can do is contact your OEM and request a new BIOS with the latest security updates.

Regards,

Jesus

0 Kudos
li__congcong
Beginner
2,958 Views

Garcia, Jesus L (Intel) wrote:

Hello Congcong,

The only thing you can do is contact your OEM and request a new BIOS with the latest security updates.

Regards,

Jesus

Thanks very much for your reply. What is the meaning of the latest security updates.  I did not get any  IAS advisories in the report. What updates should I request from the OEM.

 

0 Kudos
Reply