Page 3 of 4

Re: encryption is working on one device not other

Posted: Sat Oct 06, 2018 8:57 pm
by WiFive
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

Re: encryption is working on one device not other

Posted: Sun Oct 07, 2018 10:04 am
by snahmad75
ok, thanks. I will check on monday and let you know.

Re: encryption is working on one device not other

Posted: Mon Oct 08, 2018 5:50 am
by 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?

Re: encryption is working on one device not other

Posted: Mon Oct 08, 2018 11:34 am
by Grant.Bradley
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 9729 times
WROVER-B back view.jpg
WROVER-B back view
WROVER-B back view.jpg (218.37 KiB) Viewed 9729 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).

Re: encryption is working on one device not other

Posted: Mon Oct 08, 2018 8:58 pm
by 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)?

Re: encryption is working on one device not other

Posted: Fri Oct 12, 2018 5:26 am
by 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.
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.

Re: encryption is working on one device not other

Posted: Fri Oct 12, 2018 5:46 am
by WiFive
@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?

Re: encryption is working on one device not other

Posted: Fri Oct 12, 2018 5:58 am
by ESP_Angus
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).

Re: encryption is working on one device not other

Posted: Thu Oct 18, 2018 3:07 am
by 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.

Re: encryption is working on one device not other

Posted: Wed Dec 12, 2018 5:15 pm
by 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