HP Integrated Lights-Out Security, 7th edition

20
AES encryption
iLO 2 v1.30 and iLO 3 can restrict ciphers to AES/3DES using browser settings (through the Global
Settings page), XML scripting, or SM CLI.
The following is a complete list of communication operations that can employ AES encryption:
• Web browser (UI) – The current Mozilla browser, Firefox 2, supports AES Encryption. Internet
Explorer 7 is the first Microsoft browser that supports AES encryption.
• LOCFG/XML –A command line switch that lets you select AES encryption and the cipher strength.
• SSH – You can initiate AES sessions with OpenSSH in Linux or PuTTY.
• LDAP– An outbound method of communication where iLO provides client-side communication and
the LDAP server provides server-side communication.
The web browser, XML, and SSH support popular AES cipher strengths.
Remote console and virtual serial port data encryption
iLO uses the RC4 streaming cipher algorithm to encrypt remote console and virtual serial port
sessions. Unlike a block cipher that encrypts several bytes of data at a time, a streaming cipher
encrypts individual bytes, using a different key for each. For more information on RC4 and other
encryption algorithms, visit the website at
http://www.rsa.com/glossary/default.asp?id=1043
When a user requests either a remote console or a virtual serial port web page, iLO responds by
using the MD5 hash algorithm to create a pair of random 128-bit keys (the “pre-master secrets”) and
a time-stamped session ID (Figure 12). These are the same session ID and MD5 hash values discussed
in “
.
Login process for remote console and virtual serial port.” One key encrypts data from the client to
the server; the other encrypts data from the server to the client. The time-stamped session ID is part of
an array entry that identifies the telnet session. When the client browser tries to start an encrypted
data session, it identifies itself with this session ID. The browser passes the128-bit keys and the session
ID to the client using JavaScript files that ensure encryption of the security keys and IDs.
Next, the client generates the RC4 encryption data by combining the pre-master secrets with a set of
zero bytes. This creates the new 128-bit keys used to initiate the RC4 encryption cipher. The client
stores the new keys with the pre-master secrets in its dynamic memory space. The client does not write
the keys to disk. The RC4 cipher algorithm generates a random stream of bytes and combines it with
the remote console/VSP data in a Boolean XOR operation. This creates the encrypted data.
The client then sends the server a “connect” message containing a “start encryption now” signal and
the session ID. After that, the client sends encrypted data. The server uses the session ID to find the
correct telnet session and then begins decrypting the data using the RC4 cipher. The server performs
another Boolean XOR operation on the encrypted data to recover the original data.