encryption is working on one device not other

WiFive
Posts: 1982
Joined: Tue Dec 01, 2015 7:35 am

Re: encryption is working on one device not other

Postby WiFive » Sat Oct 06, 2018 8:57 pm

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

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

snahmad75
Posts: 263
Joined: Wed Jan 24, 2018 6:32 pm

Re: encryption is working on one device not other

Postby snahmad75 » Sun Oct 07, 2018 10:04 am

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

ESP_Angus
Posts: 1225
Joined: Sun May 08, 2016 4:11 am

Re: encryption is working on one device not other

Postby ESP_Angus » Mon Oct 08, 2018 5:50 am

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
Posts: 6
Joined: Tue Sep 25, 2018 11:13 am

Re: encryption is working on one device not other

Postby Grant.Bradley » Mon Oct 08, 2018 11:34 am

The WROVER-B modules which we have from our distributor (Mouser) - actual photos:
WROVER-B front view.jpg
WROVER-B front view
WROVER-B front view.jpg (239.5 KiB) Viewed 161 times

WROVER-B back view.jpg
WROVER-B back view
WROVER-B back view.jpg (218.37 KiB) Viewed 161 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
Posts: 1982
Joined: Tue Dec 01, 2015 7:35 am

Re: encryption is working on one device not other

Postby WiFive » Mon Oct 08, 2018 8:58 pm

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
Posts: 1225
Joined: Sun May 08, 2016 4:11 am

Re: encryption is working on one device not other

Postby ESP_Angus » Fri Oct 12, 2018 5:26 am

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.

WiFive wrote: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.

WiFive wrote: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.

WiFive wrote: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.

WiFive wrote: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
Posts: 1982
Joined: Tue Dec 01, 2015 7:35 am

Re: encryption is working on one device not other

Postby WiFive » Fri Oct 12, 2018 5:46 am

@ESP_Angus thanks for the useful info

ESP_Angus wrote:
WiFive wrote: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
Posts: 1225
Joined: Sun May 08, 2016 4:11 am

Re: encryption is working on one device not other

Postby ESP_Angus » Fri Oct 12, 2018 5:58 am

WiFive wrote: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
Posts: 1225
Joined: Sun May 08, 2016 4:11 am

Re: encryption is working on one device not other

Postby ESP_Angus » Thu Oct 18, 2018 3:07 am

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.

Who is online

Users browsing this forum: No registered users and 18 guests