https://github.com/solokeys/solo#solo-for-hackers
Solo Hacker can be converted to a secure version, but normal Solo cannot be converted to a Hacker version.
Can you please give a command line how to do this?
I have managed to install solo python (also was able to update a regular key) but since the German retailers have run out of regular key I need to lock this hacker key.
Hi,
I have managed to install solo python (also was able to update a regular key) ...
How did you do that? I tried different things and now I have two Solo Keys stucked in bootloader mode (blinking yellowisch in different speeds). I have no glue to reset them back to normal mode under Windows 10.
Update: I got it running by using the provided tools on another computer.
I got also the hacker version.
When I follow the instruction "Updating a Hacker to a Secure Solo" https://docs.solokeys.io/solo/programming/
Procedure
Boot into DFU mode.
# Enter Solo bootloader
solo program aux enter-bootloader# Enter DFU
solo program aux enter-dfuThe device should be turned off.
Program the device
solo program dfu
Double check you programmed it with bootloader + application (or just bootloader). If you messed it up, simply don't do the next step and repeat this step correctly.
Boot the device
Once Solo boots a secure build, it will lock the flash permantly from debugger access. Also the bootloader will only accept signed firmware updates.
solo program aux leave-dfu
I still ended up with
$ solo key verify
Please press the button on your Solo key
Register valid
Solo Hacker firmware.
but all credentials and the pin are erased.
Any ideas?
The one thing you can't get when converting is our attestation key (which proves the key is an actual solo secure and not a converted hacker). This is because we need to keep it secret (for precisely that reason).
Are you using latest version of the solo CLI tool? It should report the key is locked.
@conorpp
$ solo version
0.0.20
Did you make your own build or use the provided bundle-secure-non-solokeys.hex?
@conorpp I use
sha256sum bundle-secure-non-solokeys-3.0.1.hex
7d1be39dda2f2a35fecb6f687ad1b9bebd785278e657100200a800834722bdaf bundle-secure-non-solokeys-3.0.1.hex
from the release section.
Sorry I destroyed the key.
@conorpp @nickray could you please remove the text 'can be converted'. At least it was misleading for me. [1]
Check out solokeys.com, for options on where to buy Solo. Solo Hacker _can be converted_ to a secure version, but normal Solo cannot be converted to a Hacker version.
@nickray @conorpp could you please update your documentation (https://docs.solokeys.io/solo/programming/#updating-a-hacker-to-a-secure-solo) in that way, that it should state very clearly, if you want to convert your solo / somu key from hacker to secure version, you _HAVE_ to use the bundle-secure-non-solokeys (disregarding own firmware builds)! Otherwise the SoloKey get's useless because of InvalidSignature errors. I would really appreciate that. The fact, that you don't deliver your attestation keys with the official firmware should also be state very, very clear in the documentation. It's OK, but one should know about that fact before trying to fiddle with the firmware.
I got (for whatever reason) my crowd supply triple pack of the SomuKeys with the Hacker Firmware which I didn't wanted nor ordered as far as I can remember. My intention was to get three secure SomuKeys. Anyway, at my end, I have a now a SomuKey with a running Secure Firmware (but it's useless because of Signature Errors) because I installed the secure bootloader and after that I updated the firmware successfully to version 3.0.1. See #346
It is very possible to use your own firmware builds. The bundle-secure-non-solokeys build is reproducible using our Docker build even, it's only provided for convenience if people have trouble building.
Note that the attestation key is in the "bundle" and not the bootloader or application. If you programmed the bootloader, and then updated with the application, then you have no attestation key loaded. Please refer to here for more info.
I reviewed our docs and made this more clear.
Before:
You need to use a firmware file that has the combined bootloader and application (or at the very least just the bootloader). This means using the bundle-*.hex file or the bundle.hex from your build. If you overwrite the Solo flash with a missing bootloader, it will be bricked.
Now:
You need to use a firmware file that has the combined bootloader, application, and attestation key pair (bootloader + firmware + key). This means using the bundle-*.hex file or the bundle.hex from your build.
Warning
- If you overwrite the Solo flash with a missing bootloader, it will be bricked.
- If you program bootloader and firmware with no attestation, you will run into FIDO registration issues.
Appreciate the feedback -- definitely understand how this (or at the very least just the bootloader) comment in the docs was misleading. Note all keys from the CrowdSupply campaign were hackers, and this was detailed in the campaign. You can reach out to [email protected] for customer support / key replacements.
@nickray
The one thing you can't get when converting is our attestation key (which proves the key is an actual solo secure and not a converted hacker). This is because we need to keep it secret (for precisely that reason).
So do the releases not contain your attestation key and there is no way a hacker device will ever show up as a secure device? If so, once a person has flashed a hacker device to secure mode, how can someone verify that it's been converted and locked down?
I'd just like to confirm what I am seeing is normal and expected. If so, it would be an opportunity to improve the documentation to indicate that this is expected, so others do not get confused in the future.
I've successfully flashed this file from https://github.com/solokeys/solo/releases:
7d1be39dda2f2a35fecb6f687ad1b9bebd785278e657100200a800834722bdaf bundle-secure-non-solokeys-3.0.1.hex
After doing so, my Somu still shows "Solo Hacker firmware" and I'm no longer able to enter DFU mode with the Somu.
E.g.
$ solo key verify
Please press the button on your Solo key
Register valid
Solo Hacker firmware.
$ solo program aux enter-bootloader
Solo rebooted. Reconnecting...
Not using FIDO2 interface.
$ lsusb | grep STM
Bus 001 Device 046: ID 0483:a2ca STMicroelectronics USB2.0 Hub
Lights flash quickly.
$ solo program aux enter-dfu
Not using FIDO2 interface.
Please powercycle the device (pull out, plug in again)
Lights continue to flash quickly. I cycle the power and it comes back with a green light.
$ lsusb | grep STM
Bus 001 Device 046: ID 0483:a2ca STMicroelectronics USB2.0 Hub
However, if I use an unmodified Somu, to perform the following:
$ solo program aux enter-bootloader
Solo rebooted. Reconnecting...
Not using FIDO2 interface.
$ lsusb | grep STM
Bus 001 Device 051: ID 0483:a2ca STMicroelectronics USB2.0 Hub
Lights flash, but not as quickly as the other Somu.
$ solo program aux enter-dfu
Not using FIDO2 interface.
Please powercycle the device (pull out, plug in again)
Lights go out.
I cycle the power and run:
$ lsusb | grep STM
Bus 001 Device 052: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
I am able to make it to DFU mode.
Thank you for your time!
You should be able to tell by running
solo key version
Sorry to be obtuse. This is what I'm seeing:
$ solo key version
3.0.1 unlocked
What does "unlocked" here mean?
Thanks again!
There was an issue with our posted 3.0.1 bundle, and has been fixed with 3.1.0, please see https://github.com/solokeys/solo/issues/360 for more info.
I just released a patch (3.1.1) that adds a command that will force lock the flash. You can fix the "badly" converted keys by doing the following.
# update to 3.1.1
solo key update
# Trigger the new flash lock command
python3 -c "import solo ; d = solo.client.find() ; d.send_data_hid(0x99 ^ 0x80,'')"
And then reboot the key.
@conorpp thank you! The converted key is now showing 3.1.1 locked