Secure communication comes down to a matter of trust. An authenticated message from an authenticated source can be used accordingly based upon the confidence level of the source. A source trusted to provide embedded-system updates can send new program code while an unknown source may not even be able to query a device.
Encryption is typically employed to authenticate a communication partner. The sender creates a message and digitally signs the message using its encryption key. The signature is encrypted information. The idea behind this is that the signature can only be created using the key. Keep the key secret and everything at the sender's end remains secure.
The receiver authenticates the message using its key. Public key systems utilize a different but matching key at the receiver's end (see the figure). The same process can be used to exchange encrypted messages. In this case, the keys help encrypt an entire message instead of just the signature.
Public key systems can provide a hierarchy of authentication relationships. This can differ from trust relationships set up between entities. The latter usually use authentication relationships to authenticate entities.
A public key infrastructure (PKI) employs a root certificate authority (CA). It authorizes other CAs by providing a signed certificate and a set of keys, in the case of a public-key-encryption system. An entity can uniquely identify another entity if they both share a common CA. Sometimes a CA server is a provider of public keys so that entities can obtain these keys from an authenticated source. This approach can prevent the "man in the middle" type attacks where attackers would try to provide their key in place of a legitimate one, allowing any attacker to examine intercepted communication between entities.
Hierarchies such as these tend to be used where keys are dynamically created and exchanged on a regular basis as on the Internet, where e-mail and Web browsing are common. They can also be employed in embedded devices that need to authenticate communication using standards-based protocols.
The hierarchies aren't necessarily needed for other embedded applications where there's control over both ends of a link. For example, a company that creates a set of master/slave devices that communicate over the Internet can place the necessary keys in the devices and forego using certificates from a CA.
Embedded devices that employ a number of different keys can store them in a secure embedded device that may also be part of the microprocessor or microcontroller. In fact, most devices that provide this kind of service have an embedded microcontroller along with encryption hardware acceleration. These types of devices don't need large amounts of storage because they can store keys used to decrypt other data.
CAPTION Public key encryption can employ an infrastructure like the one presented here. A CA signs certificates using its private key. These certificates can be authenticated using the CA's public key. Private keys must be kept secret. Secure devices are provided with secret or authenticated public keys, and these must be kept in a secure location. An embedded security device can be used to store some information, but this tends to be limited. Secure information hindered only by external storage can be secured using encryption, with the encryption key being stored in the secure device. Typically, the secure embedded device features hardware encryption support.
