I have similar issue with a topic that was locked GROUP_OUT_OF_DATE - what is the most recent microcode version? .
We are using Intel® NUC Kit NUC8i7BEH ，
Our BIOS version is BECFL357.86A.0078.2020.0309.1538 latest version that was released by Intel in 9th March.
Yet, our remote attestation result in GROUP_OUT_OF_DATE error.
---- Enclave Report Details ------------------------------------------------
cpu_svn = 0d0fffff018000000000000000000000
misc_select = 00000000
attributes = 07000000000000000700000000000000
mr_enclave = ee4234183e43c72bcc8ce5701b75529f6d9cd1b1e277eae9fec7e1c0ede2bb2e
mr_signer = bd71c6380ef77c5417e8b2d1ce2d4b6504b9f418e5049342440cfff2443d95bd
isv_prod_id = 0000
isv_svn = 0001
report_data = e64703564cd5a55a8004c7da8cfd23e68f2cef22ac32e250336f5a9f3d6f21610000000000000000000000000000000000000000000000000000000000000000
Decoding the PIB from IAS,
We have updated microcode to revision 0xd2, date = 2020-01-09 by retrieving the latest microcode from this repo: CPUMIcrocodes .
According to the replies from the last topic, we have no choice but to wait for BIOS updates from the OEM.
My questions are the followings:
1. What is the revision of microcode that CPUSVN: 0E0E02040180070000000000000000000B00 reflects? Is there any formula that defines the structure of this CPUSVN other than the first two bit?
2. Does that mean even Intel CPU could not satisfied the requirement of remote attestation?
3. Would we be able to pass remote attestation if we implement the remote attestation with DCAP server? Is there any thing else we miss to resolve this issue?
Unfortunately, there is nothing more you can do but request an updated BIOS with the latest microcode. Intel CPUs that support SGX can be remotely attested but they require BIOS support.
The CPUSVN is non-architectural and we do not define it. In other words, we cannot decode it either.
The CPU in that NUC does not have Flexible Launch Control which means it cannot use DCAP.
Intel Customer Support