laanwj / k210-sdk-stuff

Kendryte K210 / MaixGo stuff
ISC License
145 stars 31 forks source link

Security features on K210 #18

Open odudex opened 1 month ago

odudex commented 1 month ago

Hi, I'm the current maintainer of a K210-based Bitcoin signer project called Krux To enhance security and introduce an anti-tamper feature, I’ve started researching K210 firmware encryption and got surprised when came across this repository. Although the K230 is now available, I believe there's still a lot of untapped potential in the K210 chip. Starting with the original M5StickV, I ported Krux to six other devices with various shapes and UIs. While Sipeed has stopped manufacturing K210 devices like the Amigo, we now have alternatives from vendors such as Yahboom and Hiwonder. However, my knowledge is somewhat limited, so I would appreciate any advice regarding the K210’s capabilities. Specifically, do you think it’s possible to enhance the security of K210-based devices, particularly in terms of anti-tamper solutions? Could we perhaps leverage its OTP memory or firmware encryption for this purpose?

laanwj commented 1 month ago

Hi, I'm the current maintainer of a K210-based Bitcoin signer project called Krux

That's cool!

Specifically, do you think it’s possible to enhance the security of K210-based devices, particularly in terms of anti-tamper solutions? Could we perhaps leverage its OTP memory or firmware encryption for this purpose?

Not entirely sure. The OTP and firmware encryption stuff is very spottily documented, and it's been a while since i looked at the reverse engineering.

i do know at least the AES256 engine (maybe others) can use a key from the OTP without exposing it to the firmware. This is used for firmware decryption. There are also some flags in OTP that can be used to disable ROM features on startup.

Firmware encryption itself probably isn't that useful for an open source project. There's no special sauce to hide, after all. Although it might help with tampering in the sense that someone can't just flash a different firmware, because it wouldn't get decrypted correctly.

laanwj commented 1 month ago

Cool project BTW, don't know why i only learn of this now 😄 i had the same idea with K210 back in the day, but ended up in the reverse engineering rabbit hole, then in trying to get Linux to run on the device (don't if you value your sanity), then lost motivation due to outside reasons.

odudex commented 1 month ago

The lack of documentation on the K210 presents a real challenge. However, even today, it remains such a powerful chip that reverse engineering its capabilities is worth the effort! With Embit, it makes an excellent signer, and its video processing capabilities extend beyond just QR code scanning. It can handle features like scanning and instantly loading TinySeed Metal backups or estimating entropy from a camera feed in real time.

The K210 and the Krux project have many rabbit holes to explore 😄. While I'm not the original creator, I started exploring it almost three years ago and continue to do so.

On secure boot, I later found a paper quoting your investigation, which mentioned that boards shipped by Sipeed have OTP writing locked by a flag. They reverse-engineered a Maix Bit board using an NSA tool called Ghidra.

For Linux, the K230 seems like a good option. Recently, a few K230 boards targeting Linux were launched, booting from an SD card. However, for a signer, I would prefer a board with a small, soldered flash running more minimalist software.

I'm currently exploring a different approach for a simple tamper detection mechanism.This method involves hashing the entire flash content together with a PIN and the chip's unique ID to create a "fingerprint" of the flash.

However, there’s a potential vulnerability: with enough free space on the flash, malicious code could occupy areas that should be empty and, being alongside the original content, could manipulate the hash to mimic the original flash's content. To counter this, my latest idea is to fill the empty areas of the flash with random entropy from the camera, creating an "unmockable" flash. It can be getting too messy, and I would love to have something neater, but maybe it's the only possible solution.