-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security features on K210 #18
Comments
That's cool!
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. |
Cool project BTW, don't know why i only learn of this now 😄 |
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. |
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?
The text was updated successfully, but these errors were encountered: