Prevent extraction of secret keys

[artemist]

Currently, the ECC keys calculated with the HMAC of the secret and the handle are extractable by recording the I2C traffic between the EFM8UB1 and the ATECC508A. The code that calculates and transfers the handle-specific private key is here:

u2f-zero/firmware/src/u2f_atecc.c

Lines 300 to 321 in 36c9f9e

	int8_t u2f_load_key(uint8_t * handle, uint8_t * appid)
	{
	uint8_t private_key[36];
	int i;
	watchdog();
	SHA_HMAC_KEY = U2F_MASTER_KEY_SLOT;
	SHA_FLAGS = ATECC_SHA_HMACSTART;
	u2f_sha256_start();
	u2f_sha256_update(appid,32);
	u2f_sha256_update(handle,4);
	SHA_FLAGS = ATECC_SHA_HMACEND;
	u2f_sha256_finish();
	memset(private_key,0,4);
	memmove(private_key+4, res_digest.buf, 32);
	for (i=4; i<36; i++)
	{
	private_key[i] ^= RMASK[i];
	}
	return atecc_privwrite(U2F_TEMP_KEY_SLOT, private_key, WMASK, handle+4);
	}

There are a few options to fix this:

• Change the ATECC508A configuration in order to to disallow the results of the HMAC from being sent to the microcontroller. I am not sure if this is possible, since I don't have the datasheet, as it is under NDA.
• If that is not possible, use a compatible chip from the ATECC line which is able to. I do not know if this exists, again because of the NDA issue.
• Change the Readme to make this more clear. An attack would require knowing the app and handle ID, which requires login credentials, and physical possession of the key along with a SOIC clip and logic analyzer. This is outside many user's threat models.

I would recommend changing the readme for now, and preventing this attack later. I will attempt to get the datasheet for the ATECC508A to see if it is possible.

[darconeous]

I would be surprised if the ATECC508A is capable of generating a private key from the output from an internal HMAC operation without the private key material making a round trip. (I must admit I'm puzzled as to why the industry insists on all parts like this have the data sheets released only under NDA, but I digress)

The fact that most (all?) of these devices are not even encapsulated makes it possible for this attack to be performed without physically damaging the token.

I would recommend changing the readme for now, and preventing this attack later.

+1

[conorpp]

The HMAC response (ATECC -> EFM8) is XOR'd with a 32-byte key (by the ATECC) that is generated at programming time and it known to both devices. It is unmasked at line 318 of your code snippet.

atecc_privwrite will similarly wrap it with a different 32-byte key and the ATECC will unwrap it.

So an adversary can only observe R ^ K on the I2C bus, where R is a fixed random number and K is a secret key. I believe this is fine but I appreciate any feedback.

[conorpp]

@darconeous Security IC manufacturers usually have implicit NDA and commercial requirements for who can use the ICs because if someone finds a flaw, it's really expensive to fix. I guess red tape can prolong the discovery of a flaw. Infineon is dealing with this right now.

[artemist]

Oh, I did not realize that RMASK and WMASK were generated per-device. I can't think of any attacks that would allow you to use K ^ R and K ^ W to get private keys assuming that HMAC is a PRF and the ECDLP holds. However, this does reduce the security to an attacker's inability to read from the MCU flash. I'll look into the documentation to see if there are any ways past the EFM8 flask lock.

Alternatively, the MCU could keep only the first 4 bytes of RMASK and WMASK, which is all that is necessary to format the key, from what I can understand. The rest of the key would be HMAC ^ RMASK ^ WMASK, so the private key would be different than just taking the HMAC, but the MCU would not need to know what it is.

[darconeous]

Ah, I remember that mechanism now from when I was reviewing the algorithm. It seemed sufficient to me at the time. I'm embarrassed I forgot about that.

Security IC manufacturers usually have implicit NDA and commercial requirements for who can use the ICs because if someone finds a flaw, it's really expensive to fix. I guess red tape can prolong the discovery of a flaw. Infineon is dealing with this right now.

Of course, by prolonging the discovery of the flaw, they made it much more expensive than it would have been to fix otherwise.

Off topic, but my gut feeling is that there are two additional reasons:

• Pressure from governments for these companies to keep track of who knows how to use these chips effectively.
• Desire to avoid sharing detailed chip capabilities with competitors.

[szszszsz]

Hi! Is this still valid? Masking with random rkey/wkey seems to be enough to protect from originally reported issue (extracting secrets via eavesdropping the I2C).

[darconeous]

Resolved to my satisfaction. For what it's worth.

As long as there is no way for an attacker to control or guess the bits that are being wrapped with the XOR, then it seems safe.

[conorpp]

Closing, thanks!