security review of Hardware spec

I've looked at the Hardware spec from a security point of view and have
the following comments/questions:

PLT.1.1 AdvancedTCA IPMI Support:
	This requirement doesn't specify a revision to the IPMI v1.5
spec., the most current of which is rev 1.1.
	Should this be 1.5 _or better_ (as specified in PMT.1.0)?

PLT.1.x:
	There should be a requirement that, for a system that supports
IPMI, that CGL require the user to enter an IPMI  username and password
either at installation time or first boot.  The defaults presented to
the user should be for MD5 authentication.  CGL should also set the IPMI
configuration, at installation time or first boot, to require
per-message authentication and user level authentication.

PLT.1.3 AdvancedTCA Latch-opening Event Handling:
	There should be a separate requirement added that specifies that
these events are logged securely.

FMW.1.1 Fast System Boot:
	There should be a separate requirement added that specifies that
if this option is used that this fact should be securely logged (as this
bypasses some checks that may have security implications).

HWM.1.1 CPU Throttle:
	This requirement should also specify that any
power/voltage/frequency settings are within the allowed range for the
hardware.

HWM.2.x
	There should be a requirement added that requires that, for a
system with a v1.1 TPM, the BIOS, BIOS boot block, etc. must conform to
the measurement requirements of sections 1.3.4 and 2.2 of the "TCG PC
Specific Implementation Specification", Version 1.1, August 18, 2003
(https://www.trustedcomputinggroup.org/downloads/TSS_Version__1.1.pdf).

HWM.2.1 Boot-loader Integrity Checking:
	This requirement, as I understand it, is really two
requirements:  1) that the boot-loader measures OS and configuration
data into a PCR and 2)  that the boot-loader make some type of check of
these values (presumably to record or deny if a variance is found).  If
so, it should be split into two requirements.

	Measuring an operating system, while being a "good thing" is
very difficult to do in a meaningful way.  There is research on this
(some specifically focused on Linux) but nothing that provides a
comprehensive set of measurements.  It would, however, be practical to
measure the kernel image, though this would not include dynamically
loaded modules.

	As to the boot-loader validating the measurements, this creates
the need for another requirement about how the acceptable configuration
values are securely entered and updated.  Such a requirement might be:
		OSDL CGL specifies that the boot-loader will provide a
user with a keystroke method for initiating an integrity configuration
mode during boot.  When entered, this mode will allow the user to manage
the set of allowed kernel integrity values.  The set of allowed kernel
integrity values must be sealed (by the TPM) to the system configuration
of the boot-loader before being persisted to storage.  The boot-loader
must unseal these values before it validates the measured configuration.
Should the boot-loader be unable to retrieve the sealed values or unable
to unseal the values, it should fail to continue the boot process and
should notify the user.
	Now in order to make the measurements most useful, a remote
system should attest to the system configuration after all of the
measurements have been made (or an attacker could simply replace the
validating boot-loader with one that does not perform any checks).  This
is probably best left as an add-on for administrators that wish to use
such a mechanism.

FMW.1.3 PXE Boot over IPv6:
	It should be specified that PXE boot should be disabled by
default.

Joseph Cihula
(Linux) Software Security Architect
Intel Corp.

*** These opinions are not necessarily those of my employer ***

_______________________________________________
cgl_discussion mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/cgl_discussion