Skip navigation

Intro to Drive Encryption

Posted by jgardner Mar 9, 2011

     There are many different flavors of drive encryption on the market today. Just what is drive encryption you say? Your hard drive (rotational or solid state) stores application and OS executable files as well as your user data. As more of our personal and business data resides in electronic form we need a way of “locking your desk” to keep prying eyes from our files. The most common way of doing that today is with username and passwords to keep people from viewing our information through the OS. You can also apply a hard drive password for more protection to your data. However, as in the case of your desk being locked, an enterprising person could use some common handyman tools to dismantle your desk to get to your paper files, an enterprising person could use other common tools to dismantle your hard drive and get to your electronic files. In our paper files example, all our files could be encoded so that only you could read what was on the paper. In much the same way, you can encrypt your electronic files so that only you can read what is on the hard drive. Your data can be encoded and only decoded if you supply the proper key in the form of a password or passphrase.


     What this means is that we need a mechanism to encode this data that can only be decoded with the proper key and this has to happen in real time while you’re working with your data. This real time encryption can either be done by software or by the hardware in your hard drive. Most hard drives do not have this ability but more and more drives are being made that conform to an “Opal” standard that hard drive manufacturers can follow to provide hard drive encryption. Seagate had a format called “Drive Trust” a few years ago but it has been folded into the “Opal” standard. Hardware based Full Disk Encryption (FDE) has the ability to be much faster than software based solutions but they still need software to configure the drive. This software will setup what is called a Pre Boot Authentication (PBA) area that will boot before any OS and ask for your encryption credentials. You will be asked for these credentials anytime the hard drive is powered up. Soft reboots do not normally require that you re-enter your credentials.


     For non FDE hard drives you can use one of a number of software solutions to encrypt and decrypt your hard drive data in real time. These do not perform as well as a hardware based solution but have the advantage of working on almost any computer and hard drive. Windows 7 and Vista in their Enterprise and Ultimate version can use the built-in BitLocker to encrypt partitions and full volumes except for the boot volume. For systems that don’t support BitLocker you can use a commercial product from PGP which can encrypt partitions, volumes, and individual files. There is also an Open Source project called True Crypt which will also encrypt partitions, volumes, and individual files.


     With the data on your hard drive encrypted and being protected from prying eyes, it will also be protected from utilities that are used to repair the hard drive outside of the native operating system. Using hardware based encryption you will have the ability to enter a passphrase during the boot to allow access to the hard drive utility and the encrypt/decrypt occurs on drive itself so no other software is required for encryption. Software based encryption will require that the hard drive utility either run in the native OS or load encrypt/decrypt drivers for the particular encryption method. Most of these solutions offer tools for the enterprise to centrally manage the encryption of clients and support methods to recover or reset forgotten passphrases. You need to review the needs of your environment when choosing which encryption method to use.

Knowing that Intel AMT exists in your environment has been possible for several years now.   Knowing exactly what version of Intel AMT, current configuration, network settings of the management engine (i.e. FQDN, IP address, etc), whether or not certain interfaces or features are enabled, and even more – this is very desirable.


A few years ago, Will Ditto at HP wrote a handy utility – iAMT SCAN.  A gap still existed.  Where was the Intel generated, publicly available utility that works even on the latest generation of Intel AMT systems?    In addition, a utility that worked even if the Intel AMT drivers were not loaded or Intel AMT had been disabled within the BIOS.


This is the summary of what SystemDiscovery allows with the introduction of the SCS_Discovery utility.  SCS_Discovery is a standalone component of the new Intel SCS 7.x application.   SystemDiscovery is the common command used by both utilities – SCS_Discovery and SCS 7.x.   It can be used to locally detect and collect over 60 data points of Intel AMT 2.x or higher systems.


Gathering this information locally on the client via XML file or Microsoft Windows registry enables the information to be collected via a custom inventory solution to a central database.   Having a central inventory of all Intel AMT systems provides a tremendous capability in making decisions to help realize the success of the technology.


To utilize this feature:

  • Obtain from ISN's Manageability and Security community.
  • Copy files to a target client (SCSDiscovery.exe, xerces-c_2_7.dll)
  • Run the command “SCSDiscovery SystemDiscovery”
  • View the data collected in the newly created XML file in the same directory (i.e. <fqdn>.xml)
  • View the data collection in the Microsoft Windows Registry
    • 32-bit Windows - HKLM\SOFTWARE\Intel\SCS7.0\System_Discovery
    • 64-bit Windows - HKLM\SOFTWARE\Wow6432Node\Intel\SCS7.0\System_Discovery


For a best case scenario in collecting all data regardless of the Intel AMT version, stopping the Intel AMT Local Management Service is recommended.


The above steps would be modified as follows:

  • Net stop lms
  • SCS_Discovery systemdiscovery
  • Net start lms


The following image excerpts provide a visual preview:

  • Example of data collected in to XML file

          SystemDiscovery XML.png

  • Example of data collected into registry

SystemDiscovery registry.png


Examples how this data could be used:

  • Determining key data points about the platform: whether AMT is supported, whether KVM remote control is support\enabled, exact versions of firmware and drivers, current configuration state, and so forth.
  • Troubleshooting assistance by knowing certain values within the management engine firmware: current IP address of the management engine (wired and wireless), current hostname and domain of both the operating system and management engine, what mode of configuration, and so forth.
  • Custom inventory collection to a central management database.   Once collected centrally, able to search across multiple systems, define custom collections, and so forth.


More information is available in the PDF file included with SCS_Discovery.

Filter Blog

By date: By tag: