Feature branch to enable secure-boot

[1-21gigasats]

I created a feature branch to enable secure boot optionally, as i think it is recommended to have it enabled if you plan to use the device in production.

Maybe you want to integrate it (currently only developed and tested for ttgo):

https://github.com/1-21gigasats/jade-diy/tree/feature/secure-boot

[epiccurious]

@1-21gigasats thanks for working on this. I'll review your changes and get back to you.

[1-21gigasats]

Thanks. Some ideas for futher improvements.

The user dialog promting for secure-boot / upgrade could be a little bit confusing. If you select Upgrade on a secure-boot disabled device things will probably go wrong and even maybe brick the device (did not try):

echo "  y - Yes (enable Secure Boot)"
echo "  n - No (do not enable Secure Boot or upgrade Secure Boot disabled device)"
echo "  u - Upgrade (upgrade existing Secure Boot enabled device)"

Maybe it would be better to have 2 choices:

1. secure boot: yes or no
2. ota upgrade: yes or no

Also the user experience would probaby better if this questions are asked at the beginning, not in the middle of the flashing process

[epiccurious]

There are downsides to adding a secure boot feature. I agree that it's a more secure way to go, but it's not very noob friendly.

• Like you mentioned, there's a risk that some bug in the code could brick people's hardware.

• Another risk is that if a noob enables secure boot then loses his key, that firmware becomes permanent and won't receive any future security updates. So ironically secure boot could lead to a less secure device.

So far I haven't found a clean way to incorporate it in a way that benefits noobs.

Plus, the benefits of Secure Boot may be overrated. An attacker could more easily swap a user's DIY Jade with a new decoy device, rather than plugging the user's Jade into a computer and re-flashing.

Telling users to secure access in a safe seems to be a better solution for noobs.

[epiccurious]

That being said, I like the idea of adding it as an optional feature during the installation process.

We just need to find a clean UX.

[1-21gigasats]

I agree with the UX and the physical attack part.

But one thing i find problematically is that the device could be reflashed with a malicious firmware just by plugging into a computer (remote attack). This would make the device somehow useless, because its not protecting for what it was build for (using a wallet on a compromised computer securely).

So i think the are more benefits from enabling it than keep it disabled

[epiccurious]

By remote attack, do you mean the risk for users who connect via USB to their computer for during use? Such as using the Green desktop application.

I agree secure boot would benefit them to prevent a malicious flash.

[epiccurious]

In flash_your_device, after they select the device, we could add a step asking if they'd like to enable secure boot. Would that be the best place to put it?

Or should we keep it out of the main scripts UI and instead require that advanced users run the script with --secureboot?

Is there a way we can automatically detect if the device plugged in has already set up secure boot?

[1-21gigasats]

By remote attack, do you mean the risk for users who connect via USB to their computer for during use? Such as using the Green desktop application.

I agree secure boot would benefit them to prevent a malicious flash.

Yes exactly. Or if used with the sparrow wallet or any other wired connection.

If only used with bluetooth or even airgapped with the optional camera, secure boot isnt really that much needed, i agree

[1-21gigasats]

In flash_your_device, after they select the device, we could add a step asking if they'd like to enable secure boot. Would that be the best place to put it?

Or should we keep it out of the main scripts UI and instead require that advanced users run the script with --secureboot?

I can offer to improve the UX dialog in the ttgo script as far i can get it. This will be the version i will use soon in workshops to keep it simple. If everything works, maybe you can port it to the other versions, too.

Is there a way we can automatically detect if the device plugged in has already set up secure boot?

As far as i can tell the device will completely lock down after enabling secure boot. You cannot get into monitor mode, if you try to flash it again with the normal idf flash command it will timeout, so you have to go over the ota update script.

Maybe there is a way to detect it within the ota script, as there must be some communication happening. relying just on the timeout to detect the secure boot state seems a little bit unreliable. I will try to find it out

[1-21gigasats]

So i found one way of detecting secure boot state with the included python JadeAPI. This could be embedded within the flash scripts. We can also get other nice information.

#!/usr/bin/env python

import sys
from jadepy import JadeAPI

create_jade_fn = JadeAPI.create_serial
kwargs = {'device': None, 'timeout': 10}

with create_jade_fn(**kwargs) as jade:
    verinfo = jade.get_version_info()

if 'SB' in verinfo['JADE_FEATURES']:
    print('Secure-boot is enabled')
    sys.exit(0)
else:
    print('Secure-boot is disabled')
    sys.exit(1)

Other information provided:

{'BATTERY_STATUS': 0,
 'BOARD_TYPE': 'TTGO_TDISPLAY',
 'CHIP_FEATURES': '32000000',
 'EFUSEMAC': '...',
 'IDF_VERSION': 'v5.1.2',
 'JADE_CONFIG': 'BLE',
 'JADE_FEATURES': 'SB',
 'JADE_HAS_PIN': False,
 'JADE_NETWORKS': 'ALL',
 'JADE_OTA_MAX_CHUNK': 4096,
 'JADE_STATE': 'UNINIT',
 'JADE_VERSION': '1.0.29'}

[1-21gigasats]

Here is a flow chart draft how a new UX could look like:

[epiccurious]

I like the flow chart. Been busy but should be able to test your solution in the next 2 weeks

How did the workshop go?

What percentage of users do you think would use Jade via USB rather than Bluetooth? If it's less than 5%, should it be an optional argument like -s/--secure-boot instead of always on by default?

[epiccurious]

This could be embedded within the flash scripts.

Wow, I had no idea about JadeAPI. Looks useful.

We could add a checkjade.py that runs this and prints the output to a temp file then exit 0 back into the flash script.

Update - this would work.

if 'SB' in verinfo['JADE_FEATURES']:
    print('Secure-boot is enabled')
    sys.exit(0)
else:
    print('Secure-boot is disabled')
    sys.exit(1)

[1-21gigasats]

I opened a pull request in the other repo with a draft for a secure boot feature. I think with the secure boot detection we dont need a --secure-boot flag. this would also be harder to use in a docker environment.

The workshop is planned for middle of next month, so there is enough time to fix everything

[1-21gigasats]

What percentage of users do you think would use Jade via USB rather than Bluetooth? If it's less than 5%, should it be an optional argument like -s/--secure-boot instead of always on by default?

I think it depends on the knowledge of the people. With more experience it is more likely that they want to have it enabled for maximum security and will use a desktop wallet like sparrow. Additionally i would expect that more people will use a cabled connection because they need a cable anyway, as the diy jade has no builtin battery. But i will ask the attendees in the in the workshop how they are planning to use the device