Simply put, diversification is the process of having unique-looking transactions with every subsystem in your design. The biggest benefit of such an implementation is that anyone looking at your communication traffic (using physical probes attached to your board or using sniffers tools) cannot reverse-engineer your communication feasibly.
However, it is not sufficient that the transactions are unique just within the system – even external communications should be unique for every system. The one good thing about the external communications is that there are already standards in place for this. For example, bluetooth payload packets are encrypted. Similarly, any TLS link supports encrypted communications. But, it goes without saying that unless these links are established securely, the encrypted communications don’t really add to the system security. For example, a TLS handshake done using fixed keys (and stored unsecurely more often than not) is as good as not having a TLS link at all.
Without solid authentication and integrity checks in place BEFORE you establish the communication link, confidentiality (eg: encryption) does not elevate your system’s security score!
This is where diversification comes into play. If diversification is made a part of the DNA of the system design that is to say, you try to diversify everything – you end up taking care of a lot of implementation loopholes without really taking conscious steps in that direction. The simple way to explain this is that when you use unique keys for every system and for every communication session, you never allow the attacker to reach the critical mass of ciphertext that they would need to start reverse-engineering and “guessing” the keys (using software – NOT their memory of course!).
What can and can’t you do?
Let us get one thing clear.
You cannot diversify everything! For example – you cannot diversify the I2C link between a microcontroller talking to a sensor or an EEPROM or a data flash.
But do you need to? NO!
More often than not, data does not need protection – information does.
So what is it that you can do? You can (and should) protect links between the computing units of your system. For example, take a look at the below block diagram of a fuel dispenser application.
In the above system, the links circled in GREEN carry critical information that have an immediate impact on the security of the system. For example: if the fuel nozzle reports more fuel dispensed than the actual value, the motherboard will compute a higher value for the money to be charged. This is one of the most common ways of defrauding the client apart from fuel adulteration during transit in developing countries. However, there is not much you can do about the links in RED since these are non-intelligent components more often than not. But since, these just furnish raw data – tampering with these would lead to a bad display or a receipt with garbage data, etc.
But, how do you add diversification?
A very elegant approach is to add a MAC to the data that you transmit. A MAC is a Message Authentication Code that is like the fingerprint of that particular message that is being sent to the receiver. The receiver should first ensure that the data has not been tampered with by calculating the MAC of the payload on its own and comparing that to the MAC appended to the message. Unless both MACs are exactly the same, the data should not be used and should be discarded immediately.
In order to ensure that only genuine nodes are able to generate the MAC, the MAC should use a MAC-key that is stored securely within an HSM or a secure element and a unique number (generally the serial number of the HSM or the secure element on the data source). This way, only genuine nodes can participate in the communication. An additional step can be encrypting the payload along with sending the MAC. This encryption key should be generated using the MAC-key as a raw material. The below flowchart shows how a typical diversification can be implemented.
It is extremely important to have the MAC-key stored in a secure element or an HSM chip as it is the basis of all diversification.
If the MAC-key is stored inside the firmware instead of a secure element or an HSM chip, then you are still vulnerable to probing attacks. It is possible for someone to reverse-engineer the firmware and possibly generate the same messages with some trial and error.
I personally had a great experience with Microchip’s ATECC608 and TA100 chips for implementing strong authentication with diversification in a lot of systems.
Hope this post was useful!