I'm planning on releasing a project that involves an ESP8266 connecting to a realtime database in Firebase. People will build the project, upload the code to their ESP8266 and download a Flutter Android App as a remote control for the whole project with Firebase as the backend.

The API key, database URL as well as the username and password will get sent to the ESP8266 from a Flutter app, so people can upload the code to their own ESP8266 without knowing the API key and database URL.

The problem here is that it would be a very simple hack to retrieve this data from the ESP8266 and create huge amounts of traffic in the database ending in a big bill at my end. There is a new thing called Firebase App Check but since the ESP8266 isn't an app it's useless. How can I prevent this? Is there a different approach of doing this that I haven't thought of? Or is this not really a threat worth concidering?

CodePudding user response：

The question is how to securely store credentials on an ESP8266. I wish more people would consider this kind of question.

Unfortunately, the answer is that you can't. The ESP8266 lacks the hardware needed to securely store data. An attacker with physical access to it will be able to read its flash memory which the chip has no ability to encrypt.

Consider upgrading to the ESP32. The ESP32 includes a number of security features, allowing you to permanently program it with an unreadable encryption key so that it will only run signed firmware, and to encrypt flash memory where credentials would be stored. These features let you prevent the CPU from executing firmware which has been tampered with and keep sensitive configuration information secret even from attackers with physical access to the CPU.

Note that some of the security features are irreversible. They're set by changing "efuses" inside the chip, which can only be changed once. For instance, if you set a key to verify signed firmware the chip will from then on only ever be able to run signed firmware verified by that key and you will not be able to change the key or allow it to run unsigned firmware.

If you're going to be providing end users with processors you'll be able to enforce the security measures. If you're not and the users are providing their own hardware and running your firmware, you'll be able in the firmware to detect whether hardware security was enabled... but a malicious end user would be able to tamper with the firmware to not require hardware security.

Sticking with the ESP8266, you can make it more difficult for a casual attacker to retrieve credentials by encrypting them but you still have to store the encryption key. In this case an attacker wouldn't just find the credentials by searching the firmware for strings that resemble credentials, and they would have to decompile the firmware to find how to decrypt the credentials and locate the key. This is not strong security by any means; it's merely increasing the effort of a successful attack.

Ultimately only you can decide what your risks are. How many people will be getting these devices? How trusted are they? While one would be enough, the likelihood someone will attack one increases with the number. Only you can model the group of people with access to the devices, and their behavior.

You may also be able to limit your exposure by carefully adjusting permissions on the backend, setting up rate limiting (even if Firebase does't support this you could go through your own proxy which did) or using other back-end mechanisms.