I have HP Server at home. My hobby is information security and given that of course, for my sanity, devices are encrypted using VeraCrypt. The choice of VeraCrypt over say Bitlocker is that i ultimately dont trust delegating 'key management problem' to 3rd vendor hardware or TPM or etc as it was proven again and again to be leaky bucket and there exists practices to pull out the keys. The cryptography is strong but it always boils down on how do you keep your keys. I was thinking recently for myself on how do i delegate this problem to my arduino, so in a way i have full control over how does it happen in software and i can add some fool-proof mechanisms to destroy the keys too. My idea is to generate strong-random key on the first run and keep it/pipe it to my HP Server over whatever means so that the Server machine decrypts disks inside it and i dont have to know what the key even looks like! But here the catch and ultimately my question: How do i physically protect my arduino to be reasonably (in terms of time/cost) hard to get keys out and what are the best EE' practices to destroy chip, Atmega say by high currency? I was thinking on the idea that if the adversary breaks integrity of a server (pulling out disk, the usb honeypot or displace it) so to send a signal to destroy keys in arduino both software and physically wise. i am not hardware person
What secrets on an Arduino are worth protecting? Some home plant waterer? Your source code to it? Carefully define what you want your security goals are.
I guess the most of it is if a WiFi-connected Arduino has the WiFi credentials saved.
Fundamentally, you need a microcontroller that supports things like:
- true random number generator (TRNG), as the basis for any cryptographic algorithm
- secure boot (so that only firmwares signed by your private key will run)
- flash encryption / readout protection (so that secrets are stored safely even when they can desolder the flash chip or the microcontroller physically)
The ESP32 is e.g. such a microcontroller that has that, but since Arduino is very hoby oriented, I have not seen the possibility to do secure boot and flash encryption in the Arduino IDE.
On the physical side, you'll also have to worry about hardening against side channel attacks and fault injection attacks, as those routinely bypass any security. The first versions of the ESP32 "secure" bootloader were hacked that way, until a silicon fix was deployed. The same way the RP2350 "secure" boot was hacked.
- Assuming an ATmega chip, the keys can be stored in flash memory and then the chip locked so they are *difficult to extract. The locking is by means of setting "fuse" bits described in the data sheet.
- Initiating a reprogramming of a "locked" ATmega causes the contents of the flash memory to be destroyed. Maybe some deliberate electrical overload (if that is what you were suggesting) could successfully also destroy the flash memory contents but I have never heard of this as a security solution.
EDIT
- difficult but not impossible: Crack MCU ATTINY85V Eeprom - IC Crack Service | MCU Crack Service | Microcontroller Unlock Service Provider
You can voltage glitch an ATmega328 very nicely so that is skips a few instructions or an if() check. If that check is if ( lockpadPasswordCorrect) { openDoor(); }, the attacker will thank you.
https://hackaday.com/2024/06/03/glitching-an-atmega328p-has-never-been-simpler/
I would take the simple approach and place it on an external EEPROM Place a bunch of fake keys and only one good one, you will know the address for that. Then just remove the EEPROM, then it is not accessible to anybody. When you need it Connect the EEPROM and read the key and then remove it. You could use the Arduino to display the EEPROM and do the initial write to EEPROM.
I am sorry for not being specific, so i try to paint a whole picture of the problem and where does Arduino possibly sits in it. I am not hardware person and the problem prone to heavy debate so there will be assumptions.
Imagine you have a PC that serves as storage. How do you protect disks content?
It is assumed that keeping disks content not recoverable is infinitely better than have a chance to restore it.
This assumption is important because it paves a way to make system more prone to destroy keys if diverted from normal flow.
It is assumed that arduino based on AVR is better because:
(1) cheaper to experiment
(2) modularity
(3) simplicity as to code and to destroy i assume
It is agreed upon that informational security business is a huge mess, and it is not possible to cover everything so creating an reasonable solution that works 99% of the time is better than thinking up ways to make 99.9%.
The first idea that comes to mind is to use Microsoft Bitlocker.
Why? It relives you, in some instances, from typing your keys by delegating storage of keys to USB or TPM and it does have blessings from a big company.
But it leaves your adversary a ways to get keys by
(1) if using TPM by sniffing keys out (Sniff, there leaks my BitLocker key | WithSecure™ Labs)
(2) getting hold of USB dongle or written text (Back Up Your BitLocker Recovery Key - Microsoft Support)
(3) kindly asking you to provide keys (Key disclosure law - Wikipedia)
(4) not so kindly asking (Rubber-Hose Cryptanalysis - Schneier on Security)
(5) while the system is running by dumping RAM content and extracting keys from there (Live System Analysis: Extracting BitLocker Keys | ElcomSoft blog)
(6) as the software is closed it may leave some backdoor to weaken the security (https://opensource.stackexchange.com/questions/207/how-is-open-source-encryption-safe)
(7) the software assumes to make keys backup to cloud storage (Bitlocker automatically activated on private windows computers - Microsoft Q&A)
Ok, lets use VeraCrypt now. Is it in terms of cryptography better than Bitlocker? No. The same guts. But it is open source and delegates key management problem solely to you, so what adversary can do now is:
(1) kindly asking you to provide keys
(2) not so kindly asking
(3) getting hold of USB dongle or written text
(4) while the system is running by dumping RAM content and extracting keys from there
How do we deal with two problems left? Here comes Arduino to help by:
(1/2/3) Generating and keeping keys for disk decryption, so you cant know how it is even looks like
(4) By creating safeguards on the hardware side and be symbiotic with some software in PC against this very problem
What set up looks like:
(1) Arduino
(2) Battery
(3) Set of buttons
(4) Set of sensors
(5) External system X to try to implode damage to the AVR chip
(6) Cable to PC to emulate keyboard
(7) Software on PC that communicates with arduino (can tip off to let hell lose)
What software does is monitors not desirable USB connections/access to veracrypt openhandle process/use of RAM dumping kernel drivers/software etc.
How do i envision workflow of arduino here:
(1) Press button GENERATE to generate key inside arduino
(2) Press button SEND_KEY to emulate keyboard and write key in the field to encrypt disk
(3) Set up software in PC, whatever it checks it essentially now says READY to arduino
(4) Setup sensors to prevent disk pull up or PC Dislocation or case opening
(5) Press button ARM so the hardware guards are ready and internal timers/hook for signals is deployed
Now if we restart the PC system runs normally and the software tries to mount disk, it send signal ASKING to arduino, arduino sends key to PC
after sending ASKING it will not send the key anymore until receiving RESTART from PC software or PC hardware restart button
If the arduino sensors is broken (one of the N) or software in PC sends signal DESTROY it destroys key programmatically and physically
In case to fix PC so to say, there is button DISARM that turns off hardware sensors in arduino
If there is no POWER to PC for N number of time and DISARM was not activated it destroys keys inside (that why the battery)
it is super raw and i was never explored that question before and there is need to mule over and draw how it works many times, but i think you have got the general sense what it is all about? Kind of deadhand. its really bothers me, and the idea to destroy chip initially was because i am not proficient in different types of memories and its implication in arduino and how do i can destroy the keys for good
Keep the Arduino out of your opponents' hands. They aren't going to sneak in remotely, via a zero day vulnerability in the non-existent OS.
As you are aware, central to establishing cybersecurity protocols is first, realistically assess the threat level.
And if the « Harduino (c)» 
(hardened Arduino) falls in the wrong hands you’ need an extra layer of protection maybe ?
For example, the Arduino Uno WiFi Rev2 comes with a Microchip ATECC608A secure element (an HSM module) that can generate and store private keys outside the microcontroller’s direct access. It supports hardware-based authentication and cryptographic operations such as ECC and SHA-256. The ATECC608A is designed for general-purpose security applications and provides a high level of security but is not certified to Common Criteria or FIPS standards.
The Arduino Portenta H7 includes an NXP SE050C2 secure element certified to Common Criteria EAL 6+ and compliant with FIPS 140-2. This provides a much higher assurance level, enabling secure identity management, encrypted communication, and trusted key storage directly on the hardware.
So this would rely on the battery not giving out to protect the keys?
Let's hope you don't forget to press DISARM before going on holiday....
What prevents someone from spoofing the PC and send the ASKING signal to the Arduino and to receive the decryption key? Or to sniff the UART or USB signals to capture the transmission of the decryption key between the Arduino and the PC? They don't have an authenticated and encrypted tunnel between them.