ACS-3 Reporting Security Compliance

ACS-3 Reporting Security Compliance

October 5, 2010

Revision 2

Page 2 of 8 ACS-3 Reporting Security Compliance

Document Status

Revision History

Rev Date Description

0 Dec. 1, 2009 1) Initial Revision 1 July 14, 2010 1) Complete rewrite

2 October 5, 2010 1) Added FIPS 140 status indicator 2) Added FIPS 197 status indicator

1 Introduction

As the embedded security market matures, more vendors will affirm conformance with various security

standards. It is becoming important that devices be able to indicate to a host compliance with security standards. This proposal adds this capability.

2 Scope

Security compliance reporting may be applicable on devices that support advanced security interfaces like IEEE 1667 or TCG. Even devices that only support the ATA security feature set may have certifications.

This proposal creates the ability to provide security compliance information to the host.

3 Overview

These changes are being proposed:

a) add references for some FIPS standards: e.g. FIPS 140-2, FIPS 140-3, and FIPS 197 b) define a data structure containing security compliance information

c) return that data structure via a new function of TRUSTED RECEIVE, for Security Protocol 00h

4 Changes to ACS-2

[editors note: add these to 2.4 Other References]

For these FIPS Publications, contact NIST at http://www.nist.gov

a) FIPS PUB 140-2, SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES, May 25, 2001 b) FIPS PUB 140-3 (Revised DRAFT 09/11/09) , SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC

MODULES, 09/11/09

c) FIPS PUB 197, Advanced Encryption Standard (AES), Nov. 26, 2001

4.1 Changes to Clause 7 - Command Descriptions

Page 4 of 8 ACS-3 Reporting Security Compliance

4.2 TRUSTED RECEIVE - 5Ch, PIO Data-In (section 7.59)

This 28-bit command is mandatory for devices implementing the Trusted Computing feature set. 4.2.2 Description

<no changes requested> 4.2.3 Inputs

4.2.3.1 Overview

4.2.3.2 Security Protocol <no changes requested> 4.2.3.3 SP Specific <no changes requested> 4.2.3.4 Transfer Length <no changes requested> 4.2.4 Normal outputs <no changes requested> 4.2.5 Error outputs <no changes requested>

4.2.6 Security Protocol 00h Description 4.2.6.1 Overview

The purpose of Security Protocol 00h is to return basic information about the device. A TRUSTED RECEIVE using Security Protocol field set to 00h is not linked to an earlier TRUSTED SEND command.

Name Description

Feature Security Protocol (see 4.2.3.2) Count Transfer Length (7:0) - See 4.2.3.4

LBA

Bit Description 27:24 Reserved

23:8 SP Specific - Security Protocol Specific (word) (see 4.2.3.3) 7:0 Transfer Length (15:8) - See 4.2.3.4

Device

Bit Description 7 Obsolete 6 N/A 5 Obsolete

4 Transport Dependent - See 6.2.12 3:0 Reserved

The Transfer Length field contains the number of 512-byte blocks of data to be transferred (e.g., one means 512 bytes, two means 1 024 bytes). A transfer length of zero is invalid.

The total data length shall conform to the Transfer Length field requirements (e.g., the total data length shall be a multiple of 512). Pad bytes shall be added as needed to meet this requirement. Pad bytes shall have a value of 00h.

If the length of the TRUSTED RECEIVE parameter data is greater than the Transfer Length, then the device shall return the TRUSTED RECEIVE parameter data truncated to the requested Transfer Length.

When the Security Protocol field is set to 00h, the SP Specific field is shown in table 1.

If the SP Specific field is set to a reserved value, then the command shall be aborted.

Each time a TRUSTED RECEIVE command with Security Protocol field set to 00h is received, the device shall transfer the data starting with byte 0.

4.2.6.2 Supported security protocols list description <no changes requested>

4.2.6.3 Certificate data description <no changes requested>

Table 1 — Security Protocol 00h - SP Specific field descriptions for Protocol 00h

SP Specific Description Support

0000h Return supported security protocol list (see 4.2.6.2) Mandatory 0001h Return a certificate (see 4.2.6.3) Mandatory 0002h Return security compliance reporting data (see

4.2.6.4)

Optional 0003h

0002h-FFFFh

Page 6 of 8 ACS-3 Reporting Security Compliance

4.2.6.4 Security compliance reporting

4.2.6.4.1 Security compliance reporting overview

The security compliance reporting data lists information about security-related standards that the device claims compliance to.

Table 2 defines the security compliance data. The security compliance data is a variable length, unsorted list of security compliance descriptors. The amount of data returned is one or more 512-byte data blocks, with pad bytes after the Compliance descriptor. at the end of the last data block returned. Pad bytes shall have the value 00h.

4.2.6.4.1.1 Compliance Descriptor Length

The length of the Compliance descriptors fieldThe number of bytes (including the 8-byte header) that are available to be transferred.

4.2.6.4.1.2 Compliance Descriptor Bytes

This field shall contain zero or more compliance descriptors. The format of each descriptor varies according to type. The header of each descriptor contains a type identifier. Table 3 defines the compliance descriptor types. There may be more than one compliance descriptor with the same compliance descriptor type. Compliance descriptors may be placed in any order.

Table 2 — TRUSTED RECEIVE parameter data for SP Specific=0002h Bit

Byte 7 6 5 4 3 2 1 0

0 Reserved

1 Reserved

2 (MSB)

Compliance Descriptor Length (M - 3)

3 (LSB)

4

Compliance descriptor bytes

M

M+1

Pad bytes (if any) (1 less

than

Table 3 — Compliance Descriptor Type

Compliance

Descriptor

Type

Description

Reference

Compliance

Descriptor

0000h

Reserved

0001h

FIPS 140-2, FIPS 140-3

4.2.6.4.2

0002h

FIPS 197

4.2.6.4.3

0003h..

FFFFh

4.2.6.4.2 FIPS 140 Compliance Descriptor

4.2.6.4.2.1 Revision

For FIPS 140-2, the Revision shall be ‘2’. For FIPS 140-3, the Revision shall be ‘3’.

4.2.6.4.2.2 Overall security level

For FIPS 140-2, the Overall security level shall be ‘1’, ‘2’, ‘3’ or ‘4’. For FIPS 140-3, the Overall security level shall be ‘1’, ‘2’, ‘3’ or ‘4’.

4.2.6.4.2.3 Status Indicator

If bit 0 is set to one, then the device is operating in an approved FIPS 140 mode. If bit 0 is cleared to zero, then the device is not operating in an approved FIPS mode.

If bit 1 is set to one, then the device has failed a FIPS 140 self-test. If bit 0 is cleared to zero, then the device has not failed a FIPS 140 self-test.

4.2.6.4.2.4 Hardware version

The Hardware version field shall contain the version number of the hardware in the module (if appropriate).

4.2.6.4.2.5 Software/Firmware version

The Software/Firmware version field shall contain the version number of the software/firmware in the module (if appropriate).

4.2.6.4.2.6 Module name

The Module name field shall contain the name or identifier of the cryptographic module. Table 4 — FIPS 140 Compliance Descriptor

Byte Offset Type Length Description

0..1 Word 2 Compliance Descriptor Type (0001h) (see table 3) 2..3 Word 2 Number of bytes of compliance descriptor data that follow

4 ATA String

1 Revision (e.g., 2-3) 5 ATA

String

1 Overall security level (e.g., 1-4) 6 Byte 1 Status Indicators

Bit Description 7:2 Reserved 1 Self-test failed

0 Operating in approved FIPS 140 mode

7 Byte 1 Reserved 8..39 ATA String 32 Hardware version 40..71 ATA String 32 Software/Firmware version 72..327 ATA String 256 Module name

Page 8 of 8 ACS-3 Reporting Security Compliance 4.2.6.4.3 FIPS 197 Compliance Descriptor

4.2.6.4.3.1 Revision

For FIPS 197, the Revision shall be ‘TBD’.

Table 5 — FIPS 197 Compliance Descriptor

Byte Offset Type Length Description

0..1 Word 2 Compliance Descriptor Type (0002h) (see table 3) 2..3 Word 2 Number of bytes of compliance descriptor data that follow

4 ATA String