SGX_ERROR_MAC_MISMATCH after mainboard change

[brenzi]

On a multiplatform mainboard we had a single CPU and our service was running properly and has sealed very important data. For sealing, we used the MRSIGNER policy. 

Due to a damage, our cloud provider exchanged the motherboard, but the CPU is still the same. I would expect the new setup should be capable of unsealing the previously sealed data.

In the (fresh) BIOS I activated SGX and tried to run our enclave and unseal the data. I got SGX_ERROR_MAC_MISMATCH

When I simply try to start our service from scratch, the enclave throws: SGX_QL_NO_PLATFORM_CERT_DATA. Therefore, my suspicion is that I need to re-register the platform, but the AESMD doesn't seem to do that for me automatically.

In the BIOS I found a knobs "SGX factory reset (disabled)" and "SGX auto MP registration (disabled)". I didn't dare to enable the reset becasue I want to be really sure we can recover our sealed data this way - and not lose it forever. I guess I should do this reset because the platform changed. As we used MRSIGNER policy, I'd expect that I can factory-reset and then register the platform and then unseal our data. Is that correct?

How can we recover from this situation?

Our System (OVH scale-i1):
* mainboard SPC741D8QM3-NL-E

* CPU XEON gold 6526Y
* ubuntu-22.04

[Scott_R_Intel · Accepted solution]

Hello brenzi.

Even though you were running a mainboard with only one Xeon Scalable CPU, the SGX key generation processes still apply as if there were multiple CPUs.  This means that the sealing keys you were using were technically platform sealing keys. These are random and per-platform.  If you had performed an SGX Factory Reset (that you mentioned) on the old mainboard, you would have reset these random platform keys, causing the same situation as this move to the new mainboard.

Unfortunately, unless you or your CSP have back-ups of the keyblobs that were stored in the NVRAM of the previous motherboard, I'm afraid there will be no way to recover your previously sealed data.  And, even if you had those keyblobs, there are other platform inputs to SGX key derivation, ie. OWNER_EPOCH, etc. that may mean they wouldn't work anyway.

There is lots of information on this topic in this doc: Remote Attestation for Multi-Package Platforms using Intel® SGX Datacenter Attestation Primitives (DCAP)

Also, aesmd isn't responsible for platform registration.  You (or your CSP) would need to do that manually or use our Multi-package registration Agent tool to register the platform.  That MPA tool, once installed, is told to try to automatically register the platform by enabling the "SGX auto MP registration" BIOS setting that you mentioned.  And as you suspected, you always have to register the platform before trying to download a PCK Cert, which is frequently the cause of the SGX_QL_NO_PLATFORM_CERT_DATA error.

There is more info about platform registration in this doc: Infrastructure Setup - Intel® TDX Enabling Guide