encryption is working on one device not other

[WiFive]

Well first wrover-b is labeled on shield so you should be able to identify it 100%.


Board1 has adc 2-point cal with 3/4 coding
Board 2 has adc vref with no coding

[snahmad75]

ok, thanks. I will check on monday and let you know.

[ESP_Angus]

Manufacturing confirms that apart from some engineering samples (not offered for sale), no ESP-WROVER-B modules were produced with 3/4 Coding Scheme.

snahmad75, I'm not sure how your distributor is showing you a ESP-WROVER-B module with CODING_SCHEME efuse value 1 (3/4 Coding Scheme). Maybe the modules got mixed up?

[Grant.Bradley]

The WROVER-B modules which we have from our distributor (Mouser) - actual photos:

WROVER-B front view

WROVER-B front view.jpg (239.5 KiB) Viewed 11080 times

WROVER-B back view

WROVER-B back view.jpg (218.37 KiB) Viewed 11080 times

Reading out the e-fuses on these wrover-b shows CODING_SCHEME = 1....


FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
BLK1 Flash encryption key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK2 Secure boot key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3 Variable Block 3
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 ee fe 86 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Efuse fuses:
WR_DIS Efuse write disable mask = 0 R/W (0x0)
RD_DIS Efuse read disablemask = 0 R/W (0x0)
CODING_SCHEME Efuse variable block length scheme = 1 R/W (0x1)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)

Identity fuses:
MAC MAC Address
= 30:ae:a4:cc:13:ac (CRC 86 OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1)
CHIP_VERSION Reserved for future chip versions = 2 R/W (0x2)
CHIP_PACKAGE Chip package identifier = 1 R/W (0x1)

Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 1 R/W (0x1)
ADC_VREF Voltage reference calibration = 1121 R/W (0x3)
ADC1_TP_LOW ADC1 150mV reading = 302 R/W (0x6)
ADC1_TP_HIGH ADC1 850mV reading = 3253 R/W (0x1fd)
ADC2_TP_LOW ADC2 150mV reading = 349 R/W (0x6e)
ADC2_TP_HIGH ADC2 850mV reading = 3314 R/W (0x1e9)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

[WiFive]

Yikes! Well there definitely needs to be fully documented and supported 3/4 coding scheme ASAP then.

Hopefully @ESP_Angus can answer: why does BLK3_PART_RESERVE auto select 3/4? How does the encryption engine handle the 192bit key? Will all 2 point Cal modules ship with this configuration? Is this an isolated batch and what are the dates/Mac ranges? how can we know when buying from a distributor what config we are getting (vref vs 2 pt)?

[ESP_Angus]

Hi Grant,

Apologies, it seems manufacturing team gave me wrong info. They're re-checking the production batches where the coding scheme was changed. Will update ASAP.

Support for 3/4 Coding Scheme is in review now, and should be merged to master branch next week.

It will be released as part of ESP-IDF V3.1.2, planned for November.

why does BLK3_PART_RESERVE auto select 3/4?

There's no technical reason for this. The two changes are unrelated apart from the fact they were applied at the same time, and have been removed at the same time.

How does the encryption engine handle the 192bit key?

The hardware algorithm is always AES-256. With 3/4 coding scheme, the key is extended (bits 64-127 are repeated) in order to make a 256 bit key. Full details are in the change which is currently being reviewed.

Will all 2 point Cal modules ship with this configuration?

Currently all modules with 2 point calibration have BLK3_PART_RESERVE=1 and CODING_SCHEME=1 both set, yes.

Newer modules have neither of these things, but they all have VRef calibration.

Is this an isolated batch and what are the dates/Mac ranges? how can we know when buying from a distributor what config we are getting (vref vs 2 pt)?

As mentioned above, there'll be a statement on this soon.

[WiFive]

@ESP_Angus thanks for the useful info

why does BLK3_PART_RESERVE auto select 3/4?

There's no technical reason for this. The two changes are unrelated apart from the fact they were applied at the same time, and have been removed at the same time.

Well the TRM says

When the value of BLK3_part_reserve is 0, coding_scheme, BLOCK1, BLOCK2, and BLOCK3 can be set to any
value.
When the value of BLK3_part_reserve is 1, coding_schemeBLOCK1BLOCK2 and BLOCK3 are controlled by
3/4 coding scheme

So is this a hardware bug or a design choice?

[ESP_Angus]

Well the TRM says

When the value of BLK3_part_reserve is 0, coding_scheme, BLOCK1, BLOCK2, and BLOCK3 can be set to any
value.
When the value of BLK3_part_reserve is 1, coding_schemeBLOCK1BLOCK2 and BLOCK3 are controlled by
3/4 coding scheme

So is this a hardware bug or a design choice?

I see. This is a design choice that's been written into the TRM. I don't think there's any technical reason why there couldn't be a chip with BLK3_PART_RESERVE=1 and CODING_SCHEME=0, but no such device is produced (or planned).

[ESP_Angus]

Thanks everyone for your patience. 3/4 Coding Scheme support is now available in the ESP-IDF master branch, as of this commit.

Manufacturing has provided more detailed information showing there were some ESP32-WROVER, ESP32-WROVER-I and ESP32-WROVER-B modules produced with this coding scheme, although since August all modules have used the "None" coding scheme again. Espressif plans to provide a complete statement about this soon.

[snahmad75]

Hi Angus,

We are currently in production and bought about 1000 units from your sales department
ESP-WROVER-B with efuse CODING_SCHEME=0. We are happy that encryption is working for us.

Can you guarantee that we will get supply of ESP-WROVER-B with efuse CODING_SCHEME=0 in future.

Now I believe ESP32 SDK supports 3/4 coding scheme which is efuse CODING_SCHEME=1.

Is this backward compatible. for example. we release firmware with coding scheme= 0 PCB and then we compile using new SDK which also support both coding scheme 0 and 1. I am using latest master branch which is two weeks old.

Can OTA still work for device with both coding scheme 0 and 1.

Kindly verify this for us as asap.

Can anyone reply please.


Thanks,
Naeem