XCP firmware signed images
By Bob Hueston on Nov 02, 2007
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 2100).
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.