Encrypted programming possible?

Looking to be able to program e.g. Arduino mini pro (client) with a script to send some info to a master and have been wondering if there is a way for:

A) To make the extraction of the code impossible after programming it, meaning to make it impossible for a device to "pull out" that code from the mini.

And,

B) To only allow a certain master device to program the client, and have that particular master device to receive the info from the client.

I was thinking of any special chips perhaps that I would have to store the code in and then have that chip somehow transfer the code to the client, but would like to hear your thoughts.

Any ideas if the above is possible?

You might be interested in the ESP32 for this process.

The Non-volatile storage library API, Non-volatile Storage Library - ESP32 - — ESP-IDF Programming Guide latest documentation

The eFuse Manager eFuse Manager - ESP32 - — ESP-IDF Programming Guide latest documentation

Remember, setting eFuse bits is permanent.

Most microcontrollers with internal flash memory have the functionality to stop the average user from reading the program. Microchip/Atmel the manufacturer of your chip have been doing this for many years.

A) To make the extraction of the code impossible after programming it, meaning to make it impossible for a device to "pull out" that code from the mini.

No, you used the word impossible. This is just a question of determination, knowledge and resources. The manufacturers of the devices are constantly working on improving the protection and that should be enough for you. After all, if it costs too much money, the thief can hire a software developer to develop the code or he can just buy the software from you.

B) To only allow a certain master device to program the client, and have that particular master device to receive the info from the client.

What is your exact use case?

If you want to update the software, once the device is at your customer, you will need to meet a couple of requirements, which all cost money. e.g.
You need additional memory to hold an encrypted copy of your code.
You need to be able to decrypt the code efficiently e.g. special hardware in the chip.
If you want a robust update you need flash memory that can be erased in blocks, not just the entire chip. That way you can recover from a power out during the update.

There are many more things. Google "OTA over the air". Many chip manufacturers are working on this right now, because they need it for all the wireless products to provide security updates.

To make the extraction of the code impossible after programming it

As stated above, such a requirement is pointless. Do you really think your time, programming skills and intellectual effort are so valuable?

I believe that you could install a "secure bootloader", and set the fuses/protection bits such that that was the only way to install new code.
Such a bootloader would make your product incompatible with the arduino IDE, so you'd also have to distribute some sort of uploading tool.
Secure bootloaders frequently have licensing issues (ie, they cost money to use commercially.)

As far as I know, both of these methods should work:

Use a bootloader (eg, optiboot), but set the lockbits (specifically the bootloader lock bits) to not allow reading the application flash (LPM) from within the bootloader, and pass the -V flag to avrdude to disable verification (since you can't read the code back with the lockbits set to prevent reading). Note that you can't upload directly from the IDE now, since the IDE does not pass the -V and will complain that verification failed when it can't read back the contents of the flash.

Do not use a bootloader, set the lockbits to not allow programming or verification of the flash. This will not interfere with reprogramming it, since the chip erase command needed to erase the flash before writing the new .hex file also clears the lockbits (they will need to be set again in the command you use to write the new sketch). This will also not work for uploading via the IDE, because it does not know to set the lockbits.

Both of these options could be made to work with the IDE by providing a custom hardware package with a modified platform.txt to set these bits.

HOWEVER, none of these solutions prevents the user from examining the .hex file, which contains the data to be written to the flash (though it's not possible to turn the .hex back into readable c code - only to copy the .hex onto other parts, which they could do anyway) - you'd need to build a modified version of avrdude to decrypt the .hex file, but then they could either extract the key from your modified avrdude, or by snooping on the serial data as it goes over the wire.

To truly secure it, you'd need a bootloader that could handle the decryption of the code you send it, so it would never be present unencrypted anywhere other than the flash of the target microcontroller. Writing such a bootloader would be a significant undertaking, especially considering the limited flash and ram (most encryption algorithms require a large amount of ram and program memory to implement relative to the resources on small low end microcontrollers)

AFAIK, the ESP's are hopeless if you need code security, as the user could always take a heat-gun to the board, remove the metal RF shield (if present), and then the flash chip itself, and connect the flash chip to their own reader and dump the contents.

As noted above, there are few plausible cases whereby someone who needs to ask for help on how to prevent people from copying their code is going to be able to write code worth stealing.

Remember that it is not possible to turn a hex file back into readable c code (only "xerox" it onto another chip); if there is something truly magical on the flash that they desperately need (ex, an encryption key), a dedicated adversary with intimate knowledge of AVR instruction set could, with much effort, locate the necessary data in the hex and extract it. And against a sufficiently well-resourced adversary, all code protection efforts are futile - there are actually companies that specialize in breaking code protection and extracting the data, using tricks like glitching the clock and voltage, dissolving the case with fuming nitric acid directly interacting with the die, and so on. But the amount of effort involved is generally greater than the effort that would be required to reimplement the functionality of the sketch themselves (recall that people able to do that would also be true experts). Like all security measures, you can't make breaking the security impossible, only so hard it's not worth doing.

Thank you both!

Klaus_K here is a scenario; the end user has at hand 2 devices. A master and a client; I can access over the internet the master device to update or to debug. The master device runs a Linux version and certain software has been created for this device to run its tasks, to program the client to run its tasks and to communicate with the client to receive info from it (they are physically connected with each other). The master and client device arrives at the customer without any software loaded. The customer is provided with a micro SD card which after he inserts into a slot on the master device, runs a script that downloads the software needed, and installs it on the master's hard drive. That SD card is uniquely paired with that master device only (it doesn't do anything if inserted e.g. in a PC), it is also encrypted.

The goal (as you accurately pointed out) is to make it very difficult (not impossible) for either software (master and client and the between them communication) to be retrievable and read and if possible to develop a way that if foul play is detected, for the software to automatically be rendered useless. Another reason for that would be to void warranty should unauthorized access is detected.

While I was typing more people replied and I thank you all! @ jremington I do not believe that an honest question should receive such a response. Not looking for a reply.

superJj:
While I was typing more people replied and I thank you all! @ jremington I do not believe that an honest question should receive such a response. Not looking for a reply.

Any "unbreakable" code you write today will be cracked by a 14 year old hacker overnight and be posted online tomorrow.

Lookup the old Videocipher debacle story....

If you think the attacker could intercept the communication between the master and the client, you need to have at least a secure bootloader installed in the client. Otherwise you will not know whether the device is the client or another chip of the same type. As DrAzzy said the client needs to be able to run decryption algorithms. This way you send the code encrypted to the client.

But if you think the attacker will maybe just unsolder the chip once he knows the machine is working, you can just program the chip on the board. Use ball grid devices place all signals to inside layers of the pcb and make sure the master will only program the client once, then make sure the chip is protected and delete the client firmware image from the SD card.

As for physical attacks/foul play, it’s not easy to cover. There are virtually endless options. Some of the easy options are sensors to detect opening of the casing. This will usually stop the general population.

If the volumes and the stakes are high, I recommend you talk to some specialist from the device manufacturers. They can develop solutions with you together.

I do not believe that an honest question should receive such a response.

Then this is a very good time for you take a more realistic look at your question and the assumptions behind it.

If you think your efforts are that valuable, hire someone who knows what they are doing and be prepared to pay very well for the effort.

DO NOT post closed source, proprietary commercial product questions on the open source Arduino forum and expect to get expert help for free.

Klaus_K:
If the volumes and the stakes are high, I recommend you talk to some specialist from the device manufacturers. They can develop solutions with you together.

High stakes and a 60 cent microcontroller seem to be mutually exclusive.

jremington:
DO NOT post closed source, proprietary commercial product questions on the open source Arduino forum and expect to get expert help for free.

Honestly, I would have little to zero desire to assist someone in developing a closed source software package.