Using cheap microcontrollers for important tasks makes me nervous, and PLCs with quality assurances are expensive.

What I am thinking could help to bridge this gap would be a cheap and simple 'authentication' IC that could sit between the microcontroller and the load. The authentication IC would need an appropriately formed cryptographic message to turn on or off the load. Depending on how the system would be setup, this could make it absolutely impossible for a malfunctioning microcontroller to activate the load, for instance in the case where the key material resides not on the microcontroller itself, but rather on a remote machine.

Sure, it could be possible to achieve higher levels of assurance just by using multiple cheap MCs in conjunction with each other, but this adds a level of complexity at each load. In a system with many loads, if there is just one MC + secure chip at each load, there could be just one central point of control from which all control commands would need to originate from.


There are various kinds of authentication ICs out there, but as far as I am aware, most of them are quite complex to the point of having their own firmware. I am imaging something simpler than that. Furthermore, it would defeat the purpose of the IC merely just gave a reply to the MC that authentication had occurred. My need is for the secure IC to directly be able to switch the load (or relay, more likely).

Does anyone know an IC like this exists? Or if not, does anyone have thoughts on if this would be a useful thing to have? I am considering designing it myself.

 

I cannot imagine a purpose for such a device. Maybe the guys who put electronics in aluminum suitcases might be interested.

 

Here are points to consider:

1) The cost of the MCU (microcontroller unit) or PLC does not correlate with its reliability or performance.

2) The heart of a PLC is an MCU.

3) There are mission critical applications of MCUs, electronics and technology in general. Perhaps you can learn what strategies are used and how such equipment are develop, tested and deployed.

 

Hi Corey,
Have you seen this link?
E
https://www.microchip.com/en-us/products/security/security-ics

 

If you are requiring a remote crytographically secured signal from some command console to have the authentication IC turn on or off the load, then what purpose is the MCU serving in the first place?

 

Using cheap microcontrollers for important tasks makes me nervous, and PLCs with quality assurances are expensive.

What I am thinking could help to bridge this gap would be a cheap and simple 'authentication' IC that could sit between the microcontroller and the load. The authentication IC would need an appropriately formed cryptographic message to turn on or off the load. Depending on how the system would be setup, this could make it absolutely impossible for a malfunctioning microcontroller to activate the load, for instance in the case where the key material resides not on the microcontroller itself, but rather on a remote machine.

Sure, it could be possible to achieve higher levels of assurance just by using multiple cheap MCs in conjunction with each other, but this adds a level of complexity at each load. In a system with many loads, if there is just one MC + secure chip at each load, there could be just one central point of control from which all control commands would need to originate from.


There are various kinds of authentication ICs out there, but as far as I am aware, most of them are quite complex to the point of having their own firmware. I am imaging something simpler than that. Furthermore, it would defeat the purpose of the IC merely just gave a reply to the MC that authentication had occurred. My need is for the secure IC to directly be able to switch the load (or relay, more likely).

Does anyone know an IC like this exists? Or if not, does anyone have thoughts on if this would be a useful thing to have? I am considering designing it myself.

These sorts of problems are better solved by self-checking hardware working with software in the controller.
https://www.microchip.com/en-us/solutions/consumer/home-appliances/class-b-safety-software
https://www.microchip.com/en-us/solutions/functional-safety

 

If you are requiring a remote crytographically secured signal from some command console to have the authentication IC turn on or off the load, then what purpose is the MCU serving in the first place?

Good question. The MCU would be handling communication with the command console, can could also collect and report metrics on the state of the load or environment. It could possibly even have more fine-grained control over the load within the boundaries authorized by the secured signal (depending on the design of the IC). The reason I see to separate the functions is because the IC would simple, and thus easy to validate the design, and inexpensive to manufacture at the highest levels of quality control, whereas the MCU has a large 'attack surface' and as a complex device, has many more possible failure modes with unknown results. It would also be far more expensive to manufacture at the highest levels of quality control.

 

...impossible for a malfunctioning microcontroller to activate the load....

You assume that the malfunction in the MCU doesn't cause it to send the correct key to the authenticator.
What prevents the authenticator malfunctioning and triggering the load without a request?
Or a failure of the load driver that triggers the load all by itself?

"Cheap" microcontrollers are not in any way unreliable by themselves, and complexity of processor design has little bearing on reliability these days. The major flaw in all of these systems is the software.

 

Welcome to AAC.

I must admit that I am not understanding what this scheme is protecting against. It just seems to add complexity without benefit. I am sure I must be missing something, could you describe a scenario where this would protect the system against… whatever it is you are protecting against?

If you have a really critical function you need to protect against failure, no matter what, redundancy is the only way to really improve the odds. Three voting MCUs with independent sensors and power supplies would make things much more reliable—but is there a proven reason to do this outside your “nervousness”?

Do you have any reason to believe that your nervousness about “cheap MCUs” has a foundation in fact? Do you have any examples of failures this scheme would protect against? It seems to me (no insult intended) you’ve had an emotional response and rather than using your reason to evaluate the legitimacy of that impulse you are applying it to satisfy the unease it causes you.

I would expect that if this idea has any legs it has already been worked on by others and solutions to whatever problems you are trying to solve exist—at least in principle. It may be the case that you could improve the cost part of the equation by using less expensive parts but… well, l guess I have to wait for your scenario(s) to understand what you are trying to accomplish—I readily admit I am on the edge of baffled at this point.

 

You assume that the malfunction in the MCU doesn't cause it to send the correct key to the authenticator.
What prevents the authenticator malfunctioning and triggering the load without a request?
Or a failure of the load driver that triggers the load all by itself?

"Cheap" microcontrollers are not in any way unreliable by themselves, and complexity of processor design has little bearing on reliability these days. The major flaw in all of these systems is the software.

The key wouldn't live on the MCU, but rather on a central control system with redundancy and safeguards against unintended authorization. So the MCU itself would be incapable of triggering the load, regardless of malfunction type.

The design of the authenticator would be simple (no firmware), and everything about it would be made with the explicit goal of never triggering without valid message.

Agreed the load driver, relay, etc. is its own risk factor.

I'm interested in the idea that cheap MCU are 'reliable'. I've been using a number of ESP8266s for years for data collection, and yes, for the most part they are reliable. But per my understanding, nothing about their design is validated for any kind of critical application where there could be serious consequences of unintended operation. Regardless of my software, couldn't the thing lockup for one reason or another and leave an output high? Or toggling back and forth? I mean for $2 I wouldn't expect guarantees that that wouldn't happen.

 

If you are looking at absolute reliability at every level, I think that having anything 'Made in China' in your supply chain is a poor design choice.

 

Welcome to AAC.

I must admit that I am not understanding what this scheme is protecting against. It just seems to add complexity without benefit. I am sure I must be missing something, could you describe a scenario where this would protect the system against… whatever it is you are protecting against?

If you have a really critical function you need to protect against failure, no matter what, redundancy is the only way to really improve the odds. Three voting MCUs with independent sensors and power supplies would make things much more reliable—but is there a proven reason to do this outside your “nervousness”?

Do you have any reason to believe that your nervousness about “cheap MCUs” has a foundation in fact? Do you have any examples of failures this scheme would protect against? It seems to me (no insult intended) you’ve had an emotional response and rather than using your reason to evaluate the legitimacy of that impulse you are applying it to satisfy the unease it causes you.

I would expect that if this idea has any legs it has already been worked on by others and solutions to whatever problems you are trying to solve exist—at least in principle. It may be the case that you could improve the cost part of the equation by using less expensive parts but… well, l guess I have to wait for your scenario(s) to understand what you are trying to accomplish—I readily admit I am on the edge of baffled at this point.

Any value my idea has is premised on the concept that the authentication chip, due to its simplicity, could be made to have a hardware caused false-trigger rate that was orders of magnitude lower than a cheap MCU. I am also assuming that the authentication IC, being simple enough to not need firmware, would have an overall reliability rate that is also orders of magnitude greater than an MCU. And not just because of its simplicity per-se, but because such simplicity would allow for more robust manufacturing (ie automotive grade) while still remaining inexpensive.


Let's say I am a farmer, and I have 20 different water pumps on the farm that I would like to automate under a common control program. Assume the control system is secure. In this scenario, a pump not turning on when commanded is a nuisance, but pumps turning on uncommanded could be a disaster. They could cause flooding, or the could run dry and burn out. Or if the MCU glitched out in some strange oscillating way, the pump could be potentially be started and stopped 20 times a minute, putting stress on it to the point of failure. And in this scenario, the pumps are $10,000 each.

I agree there are already ways to solve this - having three MCUs voting as you said, or other kinds of redundancy. But that adds cost and complexity. So you are right, this isn't about being able to do something that otherwise can't be done, but rather to do it in the least expensive simplest way possible.

 

Any value my idea has is premised on the concept that the authentication chip, due to its simplicity, could be made to have a hardware caused false-trigger rate that was orders of magnitude lower than a cheap MCU.

What is the false trigger rate of cheap MCUs?

 

Let's say I am a farmer, and I have 20 different water pumps on the farm that I would like to automate under a common control program. Assume the control system is secure. In this scenario, a pump not turning on when commanded is a nuisance, but pumps turning on uncommanded could be a disaster. They could cause flooding, or the could run dry and burn out. Or if the MCU glitched out in some strange oscillating way, the pump could be potentially be started and stopped 20 times a minute, putting stress on it to the point of failure. And in this scenario, the pumps are $10,000 each.

I'd want a local controller for each pump. It would accept commands from the common control and report it's pump status
back to the common control. In addition it would monitor the status of the pump: (temperature, voltage?, current?, phases?,
on & off times) and could override (rather refuse commands) when they weren't reasonable.

This local control would be part MCU and part hardware logic (extreme over temp, over current, under/over voltage,
no water?, short cycling). The hardware logic would not be overridable by the local (or common) MCU.

At $10K/pump a few sensors and MCU+logic (need motor controller anyway) doesn't sound unreasonable.

 

The key wouldn't live on the MCU, but rather on a central control system with redundancy and safeguards against unintended authorization. So the MCU itself would be incapable of triggering the load, regardless of malfunction type.

The design of the authenticator would be simple (no firmware), and everything about it would be made with the explicit goal of never triggering without valid message.

Agreed the load driver, relay, etc. is its own risk factor.

I'm interested in the idea that cheap MCU are 'reliable'. I've been using a number of ESP8266s for years for data collection, and yes, for the most part they are reliable. But per my understanding, nothing about their design is validated for any kind of critical application where there could be serious consequences of unintended operation. Regardless of my software, couldn't the thing lockup for one reason or another and leave an output high? Or toggling back and forth? I mean for $2 I wouldn't expect guarantees that that wouldn't happen.

There are 'cheap' controllers that are certified class-B safety but you're right, the ESP8266 is not one of them.
https://www.st.com/content/st_com/en/ecosystems/functionalsafety.html
https://www.renesas.com/us/en/appli...nics/appliances/iecul-60730-functional-safety
https://www.nxp.com/applications/en...-standard-for-household-appliances:APIEC60730
https://www.mouser.com/pdfDocs/Microchip_Functional_Safety.pdf

 

What is the false trigger rate of cheap MCUs?

This is the essence of the question. MCUs are available for little, and the hardware failure rate compared to all the other system components must be almost zero.

"....a hardware caused false-trigger rate that was orders of magnitude lower than a cheap MCU" is probably unattainable. Of all the components in your system, that must be the least likely to fail. However, if hardware failure in the MCU is the concern, then (as Ya'akov suggests above) a parallel three-system voting check is probably the most realistic answer. I think that is what the space shuttle used to cater for possible MCU error.

 

.....but rather to do it in the least expensive simplest way possible.

Having been in just the situation you describe with rogue pumps causing unacceptable water loss on a farm, the simplest, cheapest system (and reliable enough to let me sleep at night) was a completely separate system that monitored the behaviour of the pumps and switched them off if it detected anomalies eg excessive or inappropriate pumping time, no pumping when line pressure down etc.

So catastrophic failure of the system requires multiple failures in several independent processes.

 

Good suggestions.
Thanks everyone.