爪乃乇ᗪ丂ㄚ丂ㄒ

Why I Needed Both Tricks The main purpose of deriving a device-specific root key and binding the external Flash to the microcontroller is to close off a major attack vector, direct access to the key storage. Since the external Flash holds sensitive key material and can be physically removed from the PCB and read using tools like USB programmers, it becomes a weak link if left unprotected. By encrypting all data in Flash using a key that’s tied specifically to the MCU, any dumped contents become meaningless outside that device. Of course, this only holds if Initialization Vectors (IVs) are not reused; we’ll get into that risk shortly. Normally, this kind of protection is handled using a Hardware Unique Key (HUK), but since that wasn't available, I had to build my own mechanism for device binding. The STM32H563ZI used on the Nucleo-H563ZI development board doesn’t support a Hardware Unique Key (HUK). That feature is only available on certain STM32H5 series chips like the STM32H573 or...

Why I Built This? I've always been curious about how Cryptography works on real hardware, not just in code, but on actual devices that Store Keys and do Encryption securely. I’d seen examples of Software-based cryptography, but I wanted to build something more hands-on, a device that does cryptographic stuff on its own , without relying on a PC for any of it. That’s where TrustX started. I wanted to build my own simple Hardware Security Module using just a microcontroller, an STM32H5 in my case, and see how far I could go. The goal wasn’t to build a commercial or certified HSM, but something I could learn from, something that handles Keys securely, does Cryptography operations, and responds to Tamper events, all in hardware. What does this Device actually TrustX isn’t a full-scale enterprise HSM; it’s more like a secure, USB-connected crypto helper. The host PC sends commands, and the device takes care of the actual processing. It can: Encrypt and Decrypt data using AES-128 in C...