SPARC Enterprise M-class Servers The Secrets of Olympus

The Sun SPARC Enterprise M-class service processors excel in the area of security. Out of the box, all network services are disabled, and customesr can decide which secure services, like https and ssh, to enable. There are no "well known" password accounts. And when users are given access, they are assigned privileges which range from domain operator (able to power on/off a single domain but not change the configuration) to platform administrator (able to set-up and reconfigure the platform). But even platform administrators can't change their own privileges; that's reserved for users with user administrator privileges only. All this combines to ensure that the service processor is as secure as the Solaris domain. After all, if the service processor is compromised, the domains would be immanently at risk. In order for the server to be secure, the service processor must be secure.

But when you upgrade the firmware on the service processor, how do you know it hasn't already been compromised? Perhaps the image you thought you were downloading from sun.com was really a spoof. Or perhaps someone modified the image after it was downloaded to insert a Trojan Horse that would give them unrestricted access to the service processor. Even checking MD5 checksums isn't very reliable, since you typically download those from the same place you get the image, so they are equally suspect.

The XCP1050 release of the M-class service processor firmware introduced signed images. When Sun produces a service processor image, it adds to it a signature based on a private key known only to a select few people at Sun (I wrote the software, and even I don't have access to the private key). Then when you attempt to update the firmware, the flashupdate command will check the signature in the XCP image. If the check fails, flashupdate will prevent the install.

The getflashimage command will also check the signature when you initially download the image to the service processor. (Also, as inferred on my posting about getflashimage back on 04-Jun-2007, I modified getflashimage to print the MD5SUM of the image after it was downloaded, so you can verify that the download was successful without any corruption.) However, note that getflashimage just warns you if the signature check fails; it's flashupdate that enforces the signature check.

So how does this prevent hackers from inserting a trojan horse? The signature of the XCP image is checked against the public key already stored on the service processor. In other words, it's the public key that was contained in the previous XCP image. Without access to the private key used to create XCP version N-1, it's virtually impossible to create a new XCP image version N with a valid signature. Even if you knew the public key (you could, for example, disassemble the service processor hardware and read the bytes in the Flash PROMs using a PROM programmer to discover the public key), it's still unlikely that you could sign an image correctly ("unlikely" as in a probability less than 1 in 2¹⁰⁰).

In case you're wondering, yes, we did allow for changing the private/public key pair on a regular basis, and we also ensured that customers when customers upgrade non-sequencially (for example, from XCP1050 to XCP2010) they would not have to upgrade to every intermediate release. How? Well, let's just keep that a secret for now.