Adding the ATA Security eXtension BIOS to AMIBIOS (Asus P5KC)

I’ve just purchased an Intel 520 SSD drive, which does hardware-based AES encryption of the whole disk, and is clever enough to encrypt the AES passphrase with the ATA / HDD password. This encryption implementation was my primary reason for getting this specific SSD. Many modern SSDs also employ hardware-based AES encryption for randomisation and for fast secure erase (they just reset the AES key!), but do NOT use the ATA password to encrypt the keys, so the encryption is far less effective at protecting your precious data. As far as my current information goes, the Intel 320, 520 and 710 drives do it correctly, as does the Samsung SSD 840 Pro and the Kingston SSDNow 200V+.

However, the AMI-BIOS in the Asus P5KC motherboard in my workstation does not support the ATA Security Mode Feature Set, and hence does not allow me to set the ATA password, or to enter the set ATA password at bootup so that the SSD can be unlocked. Enter the ATA Security eXtension BIOS, or ATASX, a piece of ROM BIOS code that you can add to your system or network ROM in various ways, that then gives you the required ATA Security Mode Feature Set components.

This post documents the exact steps I took to patch the AMI-BIOS of my Asus P5KC motherboard. If you follow these instructions, you do so entirely at your own risk. 

I made use of method 2 for the AMI-BIOS, that is to integrate the ATASX as a PCI extension ROM, targeted at the boot room on the built-in network card, into a BIOS ROM image, which I could then flash on the motherboard using the built-in EZ-Flash tool.

  1. The ATASX.ROM needs to be configured with the network and vendor id of your network card. Under Linux, I used “lspci -nn”, which returned “02:00.0 Ethernet controller [0200]: Atheros Communications Inc. Attansic L1 Gigabit Ethernet [1969:1048] (rev b0)” for the ethernet card. At the very end, you can see that the vendor id is 1969 and the device id is 1048.
  2. Using bromcfg.exe (part of the ATASX download) in a dosbox (it’s a dos utility, and I only have Windows 7 64bit on my laptop, which can’t run dos EXEs) I loaded ATASX.ROM and entered the correct vendor and device IDs. I left the default passwords blank, and the default Ctrl-S delay at 1 second.
  3. Downloaded the latest Asus P5KC .ROM file from the Asus support site.
  4. Downloaded mmtool.exe, loaded the Asus P5KC.ROM file, selected the PCI Option ROM with the vendor and device ID extracted in step 1 in the RunLoc column, and then used the replace tab to replace it with the BROMCFG configured ATASX.ROM, see below for screenshot. Saved the new .ROM file.

    Replacing the network card’s PCI Option ROM with ATASX.
  5. Burn the mmtool-saved ROM with ASUS EZ Flash (Alt-F2 at boot). It should look like this:

    Flashing your new AMI-BIOS.
  6. After rebooting, make sure you have Enabled the “LAN Option ROM” in the BIOS, under Advanced | Onboard Devices Configuration, else ATASX.ROM will never get a chance to start!

At your next boot, you should see the ATASX CTRL+S message:

Press CTRL+S to enter the ATASX setup!

If you press Control-S on time, you should be greeted with the ATASX drive selection screen (the Intel 520 SSD is not installed yet, you’re seeing my Barracuda only):

Press CTRL+S to enter the ATASX setup!

From which you can select a drive and then configure various ATA Security related variables, such as the master and user HDD passwords, which is exactly what we were after:

ATASX drive detail screen, on which the HDD passwords can be set.

Update on 2012-12-23

I’ve discovered one more caveat: ATASX unfortunately does not support drives in AHCI mode. AHCI mode can be faster than IDE mode, especially for multi-threaded disk access.

Update on 2012-12-01

I now have this working with an Intel 520 SSD. There is one caveat though: If your machine suspends to RAM (S3), the drive goes into its locked state. At resume, there is no secure way to supply the drive password, and so it remains locked. In many cases this means that S3 suspend-to-ram is not usable for password protected drives. This seems to be a common problem with desktops and also some laptops, as can be seen here on askubuntu, here on the intel communities, here on the ATASX forums, and here in the German C’T magazine.