White Papers

New Security Features in the Integrated Dell Remote Access Controller 7
6
Credential vault
Without too much trouble it is possible to find businesses that will de-solder industry standard flash
memory devices from printed circuit boards and provide a copy of the contents of the device. IDRAC7
deals with this threat in a cost-effective and well accepted way. As the name suggests, the Credential
Vault is a new feature in iDRAC7 to encrypt sensitive data before it is put into the iDRAC7 flash
memory. Private keys are a good example of the kind of sensitive data that the Credential Vault holds
and will expand to hold in future versions.
Protected storage
The cryptographic community uses the term “Protected Storage” to mean a storage facility that resists
unauthorized attempts to read data contained within. A few well known examples of Protected Storage
facilities are: smart cards, the “PStore” facility in Microsoft
®
Windows
®
2003 and Windows XP, the
BitLocker
®
facility in more recent Windows versions, and the TPM v1.2.
iDRAC7 uses the HRK mentioned previously, to encrypt sensitive information that iDRAC7 stores, such
as the private keys associated with a user-generated SSL certificate. (iDRAC7, as well as previous iDRAC
generations, supports generating Certificate Signing Requests (CSRs) that can be given to a certificate
authority (CA). For a nominal fee a CA will generate an SSL certificate using the CSR. The resulting SSL
certificate can then be uploaded to iDRAC7.)
Someone trying to steal a credential from iDRAC7, by either de-soldering the flash memory chip or by
installing a rogue firmware on iDRAC7 (assuming the attacker figures out a way to get around the
firmware verification feature in iDRAC7), would be thwarted trying to read the credentials, because
they are encrypted.
Field Service Debug authorization facility
As with many devices that incorporate embedded firmware, iDRAC7 has a number of built-in debugging
features. Generally, these debug capabilities are only turned on and used during product development.
On rare occasions, it may be necessary to debug iDRAC7 once it is out of the development
environment. The typical alternatives of:
• Not allowing substantive debugging after the product has shipped, or
• Having a mechanism where the manufacturer can access the debug features via an
undocumented mechanism
are both problematic. iDRAC7 solves these problems by implementing a mechanism in which both the
customer and Dell explicitly authorize debugging on a particular iDRAC7 and explicitly authorize
debugging starting and ending at specific times.
Benefits
This innovation gives the customer control over their system. It protects the customer from having a
back door into their system, which anyone with the right knowledge could exploit. By design, Field
Service Debugging requires that each iDRAC7 is separately authorized. Consequently, if the token that
enables debug on a particular system were stolen, other iDRAC7s are not vulnerable. Further, tokens
expire so a stolen or lost token only remains a threat until its expiration date. (Additionally, placing a
token on an iDRAC7 requires the “diagnose” privilege.)