Unable to encrypt esp32 - invalid memory address

General
1

I am trying to encrypt esp32 by following the steps in
https://mongoose-os.com/docs/mongoose-os/userguide/security.md

When I do
mos -X esp32-gen-key flash_encryption_key fe.key --esp32-enable-flash-encryption --dry-run=false

Iam getting an error
Using port COM4
Opening COM4 @ 115200…
Connecting to ESP32 ROM, attempt 1 of 10…
Connecting to ESP32 ROM, attempt 2 of 10…
Connected, chip: ESP32D0WDQ6 R1
Device MAC address: b4:e6:2d:b5:b3:f1
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x18 pc=0xa25c1d]

goroutine 1 [running, locked to thread]:
github.com/mongoose-os/mos/mos/flash/esp32.(*Fuse).IsWritable(0x0, 0x1467e220)
/go/src/github.com/mongoose-os/mos/mos/flash/esp32/efuses.go:237 +0x1d
github.com/mongoose-os/mos/mos/flash/esp32.(*Fuse).SetValue(0x0, 0x1467e230, 0x1467e230, 0x12)
/go/src/github.com/mongoose-os/mos/mos/flash/esp32/efuses.go:302 +0x2f
main.esp32GenKey(0xefe4c0, 0x14442130, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/mongoose-os/mos/mos/esp32_gen_key.go:122 +0x641
main.run(0x14678100, 0xefe4c0, 0x14442130, 0x0, 0x0, 0x0, 0x13fa033)
/go/src/github.com/mongoose-os/mos/mos/main.go:195 +0x78
main.main()
/go/src/github.com/mongoose-os/mos/mos/main.go:297 +0x50b

I have tried for 2 esp32 with the same result.

2

I also tried this today with 3 different ESP32 WROOM boards and had the same result.

The Mongoose OS command line tool
Version: 2.14.0
Build ID: 20190522-131204/2.14.0-g71e2991
Update channel: release

> mos esp32-gen-key flash_encryption_key fe.key --esp32-enable-flash-encryption --dry-run=false
Using port COM7
Opening COM7 @ 115200...
Connecting to ESP32 ROM, attempt 1 of 10...
  Connected, chip: ESP32D0WDQ6 R1
Device MAC address: 30:ae:a4:xx:xx:xx
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x18 pc=0xa25c1d]

goroutine 1 [running, locked to thread]:
github.com/mongoose-os/mos/mos/flash/esp32.(*Fuse).IsWritable(0x0, 0x14734540)
        /go/src/github.com/mongoose-os/mos/mos/flash/esp32/efuses.go:237 +0x1d
github.com/mongoose-os/mos/mos/flash/esp32.(*Fuse).SetValue(0x0, 0x14734550, 0x14734550, 0x12)
        /go/src/github.com/mongoose-os/mos/mos/flash/esp32/efuses.go:302 +0x2f
main.esp32GenKey(0xefe4c0, 0x1452e0e8, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/mongoose-os/mos/mos/esp32_gen_key.go:122 +0x641
main.run(0x1472a100, 0xefe4c0, 0x1452e0e8, 0x0, 0x0, 0x0, 0x13fa033)
        /go/src/github.com/mongoose-os/mos/mos/main.go:195 +0x78
main.main()
        /go/src/github.com/mongoose-os/mos/mos/main.go:297 +0x50b
3

Same result with mos latest.

The Mongoose OS command line tool
Version: 201906170646
Build ID: 20190623-171227/2.14.0-12-g934af90-master
Update channel: latest

4

I tried the same command, but I omitted the argument “–esp32-enable-flash-encryption” and the eFuse was burned successfully.

I have the flash encryption key eFuse set, but the image isn’t encrypted and the other eFuses are not set (disabled JTAG, etc).

I think these are the fuses to set, if doing it manually (copied from mos tool source code):

    {"flash_crypt_cnt", 1},
    {"flash_crypt_cnt.WD", 1}, // write-protect the counter so encryption cannot be disabled.
    {"JTAG_disable", 1},
    {"download_dis_encrypt", 1},
    {"download_dis_decrypt", 1},
    {"download_dis_cache", 1},
    {"flash_crypt_config", 0xf},

For example, run:
mos esp32-efuse-set flash_crypt_cnt=1 JTAG_disable=1 download_dis_encrypt=1 download_dis_decrypt=1 download_dis_cache=1 flash_crypt_config=0xF flash_crypt_cnt.WD=1 --dry-run=false

To allow development changes to the flash_crypt_cnt, run:
mos esp32-efuse-set flash_crypt_cnt=1 JTAG_disable=1 download_dis_encrypt=1 download_dis_decrypt=1 download_dis_cache=1 flash_crypt_config=0xF --dry-run=false

Then every time you flash the device, run:
mos flash --esp32-encryption-key-file fe.key

After setting all the fuses and flashing a simple image with the specified key file, I have verified the flash is now encrypted and running as expected.

5

I’ve had exactly the same problem. Bug in the encryption routine in the latest version?