Can Information From Embedded Systems Be Trusted ?

Hello friends,

Below is a link to an article where I discuss the question of trust in embedded systems. Please take a moment to leave me your comments and thoughts on it.

Article Text:

Can we trust information from embedded systems

Previous articles in this series discussed security management areas, described how the security management areas work together, and a little bit about the ecosystem for critical infrastructure. In this article we will look a little bit more in detail at trust and how we determine that individual systems generating information within a critical infrastructure network can be trusted. These systems are distributed all across the grid, they connect electromechanical devices that provide content relating to the status of the electrical grid and also provide command and control capability. But what are these devices exactly?
If we look at them closely and try to discern their similarities, they are all embedded devices which contain computer controlled operations. However, they operate on a smaller scale than a desktop PC machine. They are often more comparable to systems you would find in your microwave or coffee pot. They have limited capability that they often do not run an operating system and do not have a user which provides decision making input to operations. So if the user doesn’t initiate the operations, where did the information originate? With no user how do we hold anybody accountable for the data? Who do we blame if something is wrong with the data? Can we always just inexplicably trust the data that comes from a systems?
Trusting embedded systems
A little while back I caught the movie Judge Dredd starring Sylvester Stallone on a primetime movie presentation. A portion of this movie struck me as an interesting explanation for the trust model of embedded systems. In the movie Judge Dredd played by Stallone was accused of murdering a celebrity. During his trial for murder the sole evidence which was used to convict him was the sidearm of the judges. The prosecuting attorney pulled confidential files which showed that every time a bullet was fired from this sidearm the users DNA was sampled from the handgrip and stamped on each bullet that was fired. Since the bullets recovered from the body were stamped with Dredds DNA there was no possible way that anyone else could have killed the celebrity other than Judge Dredd.
Trusting firmware programming
Although the movie went on to show the judge Dredd had a twin brother with exactly the same DNA which actually committed the murder. I would like to look at the concept of the embedded system within this firearm being able to be used to totally prove the DNA stamped on the bullet. How can we be sure it is 100% accurate? Though it seems intuitive can we really assume that the firmware or software on the firearm was accurate and did not contain malware affecting the DNA sampling or stamping on the bullet? If you had to prove guilt beyond a shadow of a doubt judge Dredd’s attorney should have asked for a few more details. It would be important to start with records showing how long ago firmware was loaded on the firearm and details about when any updates were made. Dredds attorney would want the prosecution to prove that the firmware accurately made the transition of DNA from sample to bullet.
Trusting data transfer
In order to have proof of the firmware installation and /or updates it would require some kind of connection capability to an outside system. Since no embedded system operates in a vacuum there would have to at least be a method to programming it initially from an external system. Thinking in terms of a modern age where the “internet of things” would most likely exist, chances are this device would be on a continuous network and always be in communication with the justice department. In order to trust the communication between the sidearm and the external system, some other details would have to be proven by the prosecution. They would need to prove that communications were not replaced, removed, or entirely fabricated by a malicious party as firmware passed in transit through an external system across a network into the sidearm or back to the Justice Department for verification. The prosecuting attorney would also have to prove that any IT systems involved in the programming and communication environment from the software development repository through network was trusted. Prosecution should be asked to prove that the network was not only authenticated and trusted at some time prior to use, but that it was trusted during the exact period of time in which the sidearm transferred the incriminating information or any time its firmware was updated. The trusted state of the network would show whether anyone had the opportunity to interfere with the network during the data transfer.
In many cases such minimal systems would have limited or no storage capability. Thus communications become an even bigger portion as each time the embedded system would fire a round it would have to transfer the information regarding that individual event over this network to a backend IT systems server. This limited capability machine would have only a few event transactions stored on the machine which would be overwritten as the queue filled up. The trust of the network transferring the data for the time the event occurred would need to be proved to trust data at all, because there would be no record of the event persisted on the firearm itself.
Trusted system operation
If the prosecution could not prove a trusted state for all networks during data transfer or programming process, they would be unable to prove trusted operation of the sidearm during the same time period. In addition any questionable times of trust before and after should be investigated as they these disturbances would be times when tampering of the firearm could occur. If the firearm were to go out of communication each evening and come back online in the morning what assurance is there of its continued operations.

Can such a system pick back up where it left off and be trusted to prove guilt?
The existence of a programming interface with connection capability to the sidearm brings up another area of dispute. Could someone else have used this connection to change the firmware? If someone else could have changed the firmware, could they not have also changed it back after the incriminating actions were taken? Anyone clever enough to make this update would probably be clever enough to cover their tracks as well. In many cases adding malicious code to firmware requires adding a one line jump command somewhere in the operating code which jumps to an added block of code at the end of existing programming memory (yes it could be that simple). In this case Dredds attorney should have asked about boot verification on the sidearm to prevent unauthorized firmware from operating. Each time an embedded system goes through its startup process, it runs a boot sequence that processes code from unchangeable ROM. This ROM code then starts the more complex operating software. At this level systems can force the operation of authorized software only. However, there is one more portion of this equation and that is the fact that any software authorization process needs a baseline in which to compares against. For such a comparison there must exist something at the base of this microprocessor system which stores an individualized secret that would be unknown to someone trying to make false firmware.
Trusting operating secrets integrity
Now for the final area of questioning Dredd’s attorney should ask the prosecution to prove that the individual secret within Judge Dredd’s firearm was not changed by someone in order to allow falsified firmware to operate. The prosecuting attorney would need to prove that the secret storage location was intact with the programmed secret and the boot up sequence operated correctly. This should be asked to prove that the secret could not have been extracted or bypassed during the process. To prove this secret was intact and operated as expected the firearm should have included a signature on the data which was sent in real time to the justice department (much like the DNA stamp on the bullet). This signature would provide a mathematical (cryptographic) stamp on the data which included the time-stamp of the data as well as an integrity checksum to prove the data was un-tampered. If required the communication could be encrypted using portion of the root secret as cryptographic key. In this case the only one that could decrypt the message would be the justice department.
Trusting the ecosystem which supplied the system
Looking at that the bigger picture proving the internal base secret on a machine requires understanding the entire ecosystem which handled the secrets. Dredds attorney should ask the prosecution to prove the firearms base secret was protected throughout the development, manufacturing, and supply chain of the companies that produce and handled these firearms. Could someone have learned the secrets from any of the handling vendors at anywhere in the ecosystem of this product? Could such an interested party have been able to produce firmware software that would operate and successfully pass the checks done by the protected boot feature? Also if the distributed secrets of each system are in a central secure server at the justice department for use when communicating individually to all the firearms on the network, how were these secrets handled and who had access to them?
Relating to Critical Infrastructure
Using this analogy applied to embedded systems which would be found in critical infrastructure networks, we can see that there’s a bit more involved than just looking at a data items which come across a network and assuming that we can trust it 100%. Unfortunately, to maintain safety required for electromechanical operations we have to be able to trust data received and sent to critical infrastructure at or as close to 100% as possible. Let’s look at all the items we discussed which would need to be proved in order to trust data from an embedded system enough to get a conviction based on its contents.

• Prove that the firmware accurately made the transition of DNA from sample to bullet
• Prove the network was trusted while transferring firmware for programming and verification
• Prove that any IT systems involved in the programming, storage, or communication of firmware was trusted and intact anytime they handled firmware
• Prove the network connecting the embedded system to IT storage systems was trusted while transferring the event data for the specific time interval surrounding the time the data transfer occurred
• Prove the software development environment repository and all IT systems/network handling firmware are trusted
• Prove the that boot verification would prevent unauthorized firmware from operating on the embedded system
• Prove that the individual secret within the embedded system were not changed by someone in order to allow falsified firmware to operate
• Prove that the event data received from the system contained a cryptographic signature stamped on the data which included a time-stamp of the data as well as an integrity checksum
• Prove the firearms base secret was protected throughout development, manufacturing, and supply chain, and operations.
• Prove that use of secrets during operations such as communications, or production of firmware certificates are handled securely by all the organizations which had access to the secrets.

Thinking in these terms how far away is critical infrastructure from the point where we can trust data to the level where we can assure safety of operations on electromechanical equipment while they are cross-connected with IT networks?
Traditionally the trust model of critical infrastructure networks has been the isolation of the networks by physically controlling access to both control stations and end node systems. The trust in the device supply chain, firmware operating on systems, the device programming process, and commands sent across networks were provided by locked doors, fences, and guards with guns. Making the connection between IT networks and embedded critical infrastructure networks will require closing the gap between these two different types of networks by addressing the entire ecosystem as well as focusing on the gateway that connects the two.
In the next article we will talk about setting up trust for embedded devices and cascading trust across distributed networks of embedded systems. Later articles will describe the operation of the entire ecosystem for security in these microcontroller network environment. Setting up and maintain such operational trust will be essential in the future world which will relying on data from these networks.

Cheers,

Christopher