To enforce additional security, some cryptographic algorithms may also specify a set of constant values that should not be disclosed from the device. These secret keys and secret values stored in the device that requires protection from unauthorized exposure are referred as 'secret keys' in series of articles.

The secret keys are stored inside the device, some even for the lifetime of the device. Hardware and software security measures implemented in the device must defeat unauthorized access attempts to retrieve these secret keys. Also, there are data such as the Root CA Certificate in the device that can be disclosed but should be prevented form unauthorized modification.

If the Root CA certificate could be modified, attackers could make the device to accept any certificate by substituting a fake root CA certificate thus defeating the purpose certificate and secure communication. It is therefore also important that the data such as Root CA Certificates in the device is not subjected to unauthorized modification.

The level of security within the device varies depending on the nature of the protected content. The need for device security is more in the case of device handling user restricted data like copy-protected* video than in the case of user's private data like personal files or bank transactions.

In the case of the user's private data, this usually occurs because the user will suffer the direct loss on compromising such data and as a result he/she becomes responsible for restricting physical access to the secret keys and other secured contents stored in the device.

Also, the general implementation of secure data transfer protocols recommends a unique secret key for each device. Therefore if the hardware security of any device is compromised, it doesn't affect the security of any other device in the network.

In the case of User restricted data, however, compromising the secret key of a single device results in the compromise of the security of all the copy-protected content handled by that device. One vulnerable device can thus result in helping an unauthorized device to access the copy-protected content, decrypt it and distribute countless copies of the same.

Secure SoC (System-on-Chip)
A secure SoC (Figure 4, below) can be designed that incorporates the hardware and software support required to enforce the security within the device and thereby defeating the physical attack that compromises the security of the device.

This Secure SoC provides physical protection to secret keys by keeping the components like Secure ROM, which is handling the secret keys, inside the chip. During execution time, the protected secure keys has to be loaded to the RAM in clear text and during that time the bus to the RAM can be monitored to access the secret keys.

This can be prevented by allocating buffers for secret keys or intermediate values of cryptographic operations involving secret keys in the Internal RAM of the Secure SoC. This prevents the protected keys being available to any bus outside the Secure SoC.

The Secure Bootloader in the Secure SoC ensures that the device boots up with the genuine OS or firmware with right process privileges. The MMU (Memory Management Unit) configured by the OS permits the access to the buffers in the Internal RAM that involves secret key operations only to the secure processes with special OS privileges.

In the case where the Secure ROM is limited or pre-programmed by the hardware manufacturer, the Secure ROM can be programmed with a master key. This master key can be used to encrypt and store the device secret keys in the internal ROM.

Figure 4. A Secure SoC provides physical protection to secret keys by keeping the components like Secure ROM, which is handling the secret keys, inside the chip.

In ideal case of a Secure SoC, there are several condidtions that must be satisfied :

1) Secure ROM cannot be physically accessed to retrieve the secret keys.

2) Buses inside the Secure SoC cannot be monitored to obtain protected data or keys.

3) Removal or replacement of any components in the Secure SoC should be impossible or should prevent the SoC from working.

The level of physical protection can vary depending on the value of the protected content. The protection can be merely tamper detection of SoC to zeroing of all stored content in the SoC when a physical access attempt is made.

Tamper detection protection method does not prevent an attacker from obtaining the data from the chip but will only makes it possible to know whether the chip has been tampered with or not. The zeroing requires special power supply and hardware support that makes the chip more expensive.

The NIST (National Institute of Standards and Technology) issued FIPS 140-2 [9] publication specifies different levels of hardware and software security requirements for device that involved in storage and transfer of sensitive information.

Now, let's go into a bit more detail on the role of each component in the Secure SoC: 1) ROM, 2) internal RAM and secure processes, 3) secure bootloader and code signing, 4) encryption/decryption engine, and 5) system timing " and how they contribute to ensuring secure storage of secret keys and other protected data.