Overview
TinyPilot devices ordered between January 4th, 2021 and February 17th, 2021 contained an insecure CA certificate.
Users who purchased a TinyPilot device during this period and added the TinyPilot CA certificate to their computers should remove this certificate and update their TinyPilot software.
Who is affected?
This issue affects you only if both of the following are true:
-
You purchased a TinyPilot Voyager or TinyPilot Hobbyist Kit between January 4th and February 17th, 2021
- Order numbers 1371 through 1684
- You installed the TinyPilot CA certificate on your computer (per the instructions here)
What is the fix?
- Remove the TinyPilot CA certificate from any computers where you installed it.
- (optional) Update to the latest version of TinyPilot.
-
(optional) Install the newly generated CA certificate.
- You can verify that the new certificate is unique to your device, as it will have an "Issue Date" that matches the date you performed the software update.
What are the risks to you?
The practical risk of this issue is low.
For an attacker to exploit this vulnerability, they would have to intercept your network traffic. That requires the attacker to compromise a device on your local network or at your ISP. The attacker would also need to have purchased the same model of TinyPilot that you did in the six weeks that this vulnerability existed. If all of those things occurred, this vulnerability would allow the attacker to decrypt your HTTPS traffic or impersonate legitimate websites.
This vulnerability does not enable an attacker to gain unauthorized access to your TinyPilot device or your computer. If you have not installed the TinyPilot CA certificate, this vulnerability has no impact on you.
I discovered this issue through an internal review. There is no evidence of anyone exploiting this vulnerability in practice.
Nevertheless, it's good security hygiene to clear insecure certificates from your keystore, so I recommend that you remove the stale TinyPilot CA certificate, per the instructions above.
Detailed explanation
For your browser to establish a secure HTTPS connection with the TinyPilot, it needs to trust TinyPilot's TLS certificate. Normally, a third-party certificate authority (CA) would sign the TLS certificate to verify its authenticity. Because customers deploy TinyPilot within internal networks, an external CA can't sign the TLS certificate.
As an alternative to a third-party CA, each TinyPilot device acts as its own CA. The first time you boot your TinyPilot, it generates a secure private CA key, unique to your device. It uses this key to sign the TLS certificate and allows your browser to establish a secure connection. For this to work, your system must include the TinyPilot CA certificate in its trusted root store.
On January 5th, 2021, I unintentionally introduced a bug into the software I use to build TinyPilot microSD images. It caused CA key generation to fail. Instead of generating a new, secure CA key on its first boot, TinyPilot devices kept the temporary CA key I use when building the TinyPilot microSD images.
As a result of this error, TinyPilot devices ordered between January 4th and February 17th, 2021 all used identical, temporary CA keys. These keys were not secure, as all TinyPilot customers who purchased the same device model had access to the same private keys.
I discovered the vulnerability on February 18th, 2021. The same day, I created a new TinyPilot microSD image with the fix and switched all new orders to that image.
How will TinyPilot prevent this in the future?
I have updated my internal processes in several ways to fix this vulnerability and prevent similar recurrences in the future.
Fix key cycling
My top priority was to fix TinyPilot's microSD image-building script to ensure that it successfully regenerates unique CA and TLS keys on the device's first boot. All TinyPilot devices ordered February 18th, 2021 and after include this fix.
If you update TinyPilot, the updater will detect temporary certificates related to this vulnerability and automatically replace them with securely-generated ones.
Remove temporary security keys from base image
One of the contributing factors to this vulnerability was poor validation of the certificate generation process. When TinyPilot's certificate generation failed, the boot process silently failed over to the insecure temporary keys in the base image.
To mitigate silent failures like this in the future, I added a step at the end of the microSD build process to remove temporary keys and certificates from the TinyPilot base image.
If there is ever a similar bug that prevents key regeneration on the first boot, TinyPilot will fail loudly due to missing keys rather than failing open with insecure keys.
Explicit verification of distinct keys
I've added a manual step to my image release process to verify that TinyPilot devices generate unique security keys on their first boot.
