Assignments for Trusted Computing Group

Transcription

1 Assignments for Trusted Computing Group Revision History: 0: Initial revision 1 Introduction To: T13 Technical Committee From: Jim Hatfield Seagate Technology (for the Trusted Computed Group) 389 Disc Drive Longmont, CO Phone: Fax: James.C.Hatfield@seagate.com Date: May 28, 2005 The purpose of this proposal is to specify the ATA equivalent of some commands introduced in T10 to support trusted computing. ATA opcodes for these commands have already been allocated as Reserved for Trusted Computing Group (TCG) by T13 proposal e04128r3, which was approved in xxxxx Please reference T10 proposal r1 SPC-3 Security Commands Proposal. 2 Proposal I propose that the following text be incorporated into ATA/ATAPI-8 ACS to describe the new commands reserved for the Trusted Send and Trusted Receive commands, and for some bit assignments in IDENTIFY DEVICE. These commands are intended for use by non-packet devices, because PACKET devices using this functionality are expected to support the optional SCSI commands: TRUSTED IN and TRUSTED OUT. Assignments for Trusted Computing Group Page 1 of 11

2 2.1 Command Descriptions IDENTIFY DEVICE ECh, PIO data-in This proposal requests that the editor assign two bits from a TBD word: bit A bit B The Trusted Computing feature set is supported The Trusted Computing feature set is enabled Page 2 of 11 June 6, 2005

3 2.1.2 TRUSTED RECEIVE 5Ch, PIO data-in Feature Set This command is optional for devices implementing the General feature set. This command is mandatory for devices implementing the Trusted Computing feature set. Description The TRUSTED RECEIVE command is used to retrieve trusted results from trusted actions that were sent in a previous TRUSTED SEND command. The device shall only return trusted results that were requested by a previous TRUSTED SEND command that: a) specified the same SPID value, and b) specified the same IPID and PROTECTION_TYPE value. A single TRUSTED RECEIVE command may return trusted results requested in one or more previous TRUSTED SEND commands. A TRUSTED RECEIVE command may also return partial trusted results requested in a previous TRUSTED SEND command. If the device has no trusted results to send (e.g., trusted results for a previously requested trusted action are not ready yet), the device shall return a trusted result indicating it has no data to return and the command shall end with Command Complete. The returned data is organized as one or more trusted results. For SPID cleared to zero, the returned data is a certificate. The format for this data is described in clause [Editor s Note: fill in clause number]. The format of the trusted results for other SPID values is reserved. The format is documented by the group that owns the associated SPID value (e.g., the data format for a value of 7h is documented by TCG). It is the host s responsibility to have an outstanding TRUSTED RECEIVE command whenever it believes there are trusted results pending in the device. The device shall retain trusted result data resulting from a TRUSTED SEND command awaiting retrieval by a TRUSTED RECEIVE command until one of the following events occurs: a) a matching TRUSTED RECEIVE command; b) any reset; c) loss of communication with the host that sent the TRUSTED SEND command; If the trusted result data is lost due to one of these events and the host still wants to perform the trusted action, the host is required to resend the trusted action in a new TRUSTED SEND command. device Inputs Word Name Description h Feature PKT_TYP SP_CTRL IPID PROTECTION_TYPE 01h Count TRANSFER_LENGTH [ 7:0] 02h LBA Low TRANSFER_LENGTH [15:8] 03h LBA Mid KEY_EXT Reserved SPID 04h LBA High KEY_IDENTIFIER 05h Command 5Ch A PKT_TYP (packet type) bit set to one indicates that multiple trusted results may be returned by the device. A PKT_TYP bit cleared to zero indicates that only one trusted result shall be returned. The SP_CTRL (Security Protocol Control) field provides security protocol specific control information. The meaning of these bits is defined by each security protocol. See Table 3. Page 3 of 11 June 6, 2005

4 The IPID (Integrity Protocol Identification) field identifies which integrity protocol is being used to protect the data. The meaning of the IPID values is described in Table 1. Table 1 IPID - Integrity Protocol ID field description Value Description 0 SHA-1. 1 SHA Reserved. 7 Vendor unique. The PROTECTION_TYPE field identifies the subtype of the protection protocol. The meaning of the PROTECTION_TYPE values is described in Table 2. If the PROTECTION_TYPE field is set to zero, the IPID field is ignored. Table 2 PROTECTION_TYPE field description Value Description 0 No protection 1 Hashed 2 Keyed Hashed (MAC) 3 Reserved The TRANSFER_LENGTH field contains the number of blocks ( sectors ) of data to be transferred. The block size for this command shall be 512 bytes regardless of the actual logical block size reported by the IDENTIFY DEVICE command. If the length is not sufficient to return all of the blocks the device has available to send, the device shall send as many complete trusted results as possible without exceeding the TRANSFER_LENGTH. The SPID (Security Protocol Identification) field identifies which security protocol is being used. This determines the format of the data that is transferred. The meaning of the SPID values is defined in Table 3. Table 3 SPID - Security Protocol ID field description Value 0h 01h 06h 07h 0Ch 0Dh 0Eh 0Fh Description Request for an X.509 certificate (see clause [Editor s Note: supply clause number] ) Reserved. Reserved for TCG. Reserved. Vendor unique. The KEY_IDENTIFIER field provides a pointer to the key used with the integrity protocol to validate the data Certificate descriptions Certificate header When the SPID field of the TRUSTED RECEIVE command specifies an X.509 certificate, a header and the certificate bytes shall be returned as shown in Table 4. Page 4 of 11 June 6, 2005

5 Table 4 X.509 header and certificate description Bit Byte 0 RESERVED 1 RESERVED 2 (MSB) CERTIFICATE LENGTH 3 4 N X.509 CERTIFICATE BYTES The CERTIFICATE LENGTH indicates the total length, in bytes, of the certificate(s). This length includes one or more certificates. If the device doesn t have a certificate to return, the certificate length is cleared to zero and only the 4 byte header is returned. If the device returns more than one certificate, the first one has to be the device credential defined in sections through Certificate overview The instantiation of a X.509 conformant credential is either through an X.509 Attribute Certificate or an X.509 Public Key Certificate depending on the capabilities of the device. A X.509 Attribute Certificate shall be issued for any device not capable of asymmetric key operations or any device for which the credential issuer does not want to include any public key information in the credential. A X.509 Public Key Certificate shall be issued for any device capable of asymmetric key operations and for which the certificate issuer wants to bind the public key to the device Public Key certificate description RFC 3280 defines the certificate syntax for certificates consistent with X.509v3 Public Key Certificate Specification. Table 5 describes the SCSI [Editor s Note: reference to SCSI] usage of the X.509 public key certificate fields and the relationship of that usage to the definitions of RFC (LSB) Table 5 SCSI usage of X.509 certificate values in RFC 3280 context Certificate Field [1] Details signaturealgorithm As described in RFC signaturevalue As described in RFC version Shall be version 3. serialnumber As described in RFC signature As described in RFC issuer As described in RFC 3280 with the added constraint that UTF8String encoding of DirectoryString shall be used. validity As described in RFC It is recommended to set Begin Date to the time of credential issuance and the Expiration Date to the Begin Date plus one hundred years if the intent is not to indicate an expiration date. subject As described in RFC Information contained in this field shall either be populated with a non-empty distinguished name identifying the device or a null value. subjectpublickeyinfo As described in RFC Page 5 of 11 June 6, 2005

6 subject Alternate Name Extension As described in RFC 3280, but may be ignored. This specification restricts the use to the following options only: othername; directoryname. One and only one of the following values is allowed for subjectaltname: The device serial number using directoryname; The device serial number using othername. If this field is used then subject field shall contain a null value. As described in RFC basicconstraints Extension crldistributionpoints As described in RFC Extension subjectdirectoryattributes Extension: protocols [1] Certificate field names are as described in RFC SEQUENCE OF OID Defines supported Security and Integrity Protocols Page 6 of 11 June 6, 2005

7 Attribute certificate description RFC 3281 defines the certificate syntax for certificates consistent with X.509v2 Attribute Certificate Specification. Certificates for SCSI [Editor s Note: reference to SCSI] may use the RFC 3281 certificate syntax. Table 6 describes the SCSI usage of the X.509 attribute certificate fields and the relationship of that usage to the definitions of RFC Table 6 SCSI usage of X.509 certificate values in RFC 3281 context Certificate Field [1] Details signaturealgorithm As described in RFC signaturevalue As described in RFC version Shall be version 2. holder issuer As described in RFC signature As described in RFC serialnumber As described in RFC attrcertvalidityperiod As described in RFC 3281 with the added constraint that entityname option be used in the Holder field containing one and only one of the of the following values: an URI using uniformresourceidentifier; the device serial number using directoryname or othername; a null value. As described in RFC It is recommended to set Begin Date to the time of credential issuance and the Expiration Date to the Begin Date plus one hundred years if the intent is not to indicate an expiration date. attributes: SEQUENCE OF OID protocols Defines supported Security and Integrity Protocols. basicattconstraints As described in RFC Extension crldistributionpoints As described in RFC Extension [1] Certificate field names are as described in RFC Normal outputs See Error! Reference source not found.. Error outputs The device shall return command aborted if the command is not supported. An unrecoverable error encountered during execution of this command results in the termination of the command. The amount of data transferred is indeterminate. See Error! Reference source not found.. Page 7 of 11 June 6, 2005

8 2.1.3 TRUSTED RECEIVE 5Dh, DMA data-in Feature Set This command is optional for devices implementing the General feature set. This command is optional for devices implementing the Trusted Computing feature set. Description See the TRUSTED RECEIVE (5Dh) command for the description of this command. Inputs Word Name Description h Feature PKT_TYP SP_CTRL IPID PROTECTION_TYPE 01h Count TRANSFER_LENGTH [ 7:0] 02h LBA Low TRANSFER_LENGTH [15:8] 03h LBA Mid KEY_EXT Reserved SPID 04h LBA High KEY_IDENTIFIER 05h Command 5Dh See the TRUSTED RECEIVE (5Ch) for parameter descriptions. Normal outputs See Error! Reference source not found.. Error outputs The device shall return command aborted if the command is not supported. An unrecoverable error encountered during execution of this command results in the termination of the command. The amount of data transferred is indeterminate. See Error! Reference source not found.. Page 8 of 11 June 6, 2005

9 2.1.4 TRUSTED SEND 5Eh, PIO data-out Feature Set This command is optional for devices implementing the General feature set. This command is mandatory for devices implementing the Trusted Computing feature set. Description The TRUSTED SEND command is used to send trusted data to the device. The data sent contains one or more trusted actions to be performed by the device. The host shall use TRUSTED RECEIVE command to retrieve any trusted results derived from the trusted actions. The device shall return Command Complete as soon as it determines the data has been correctly received. This does not indicate that the data has been parsed or that any trusted actions have been processed. These indications are only obtained by sending a TRUSTED RECEIVE command and receiving the results in the associated data transfer. The data is organized as one or more trusted actions. For SPID cleared to zero, The TRANSFER_LENGTH shall be zero and no data is transferred. In this case, if the TRANSFER_LENGTH is non-zero the command is aborted. The format of the trusted actions for other SPID values is reserved. The format is documented by the group that owns the associated SPID value (e.g., the data format for a value of 7h is documented by TCG). Inputs Word Name Description h Feature PKT_TYP SP_CTRL IPID PROTECTION_TYPE 01h Count TRANSFER_LENGTH [ 7:0] 02h LBA Low TRANSFER_LENGTH [15:8] 03h LBA Mid KEY_EXT Reserved SPID 04h LBA High KEY_IDENTIFIER 05h Command 5Eh A PKT_TYP (packet type) bit set to one indicates that multiple trusted actions may be sent in the payload. A PKT_TYP bit cleared to zero indicates that a single trusted action shall be sent. The SP_CTRL (Security Protocol Control) field provides security protocol specific control information. The meaning of these bits is defined by each security protocol. The IPID (Integrity Protocol Identification) field identifies which integrity protocol is being used to protect the data. The meaning of the IPID values is described in Table 1. The PROTECTION_TYPE field identifies the subtype of the protection protocol. The meaning of the PROTECTION_TYPE values is described in Table 2. If the PROTECTION_TYPE field is set to zero, the IPID field is ignored. The TRANSFER_LENGTH field contains the number of blocks ( sectors ) of data to be transferred. The block size for this command shall be 512 bytes regardless of the actual logical block size reported by the IDENTIFY DEVICE command. The KEY_EXT field indicates whether or not the KEY_IDENTIFIER contains the complete ID. If the value is set to one, then the KEY_IDENTIFIER field is not valid, and the data stream begins with a 1-byte length field, followed by the actual KEY_IDENTIFIER to be used. If KEY_EXT is cleared to zero, then the KEY_IDENTIFIER field is valid. Page 9 of 11 June 6, 2005

10 The SPID (Security Protocol Identification) field identifies which security protocol is being used. This determines the format of the data that is transferred. The meaning of the SPID values is described in Table 3. The KEY_IDENTIFIER field provides a pointer to the key used with the integrity protocol to validate the data. Normal outputs See Error! Reference source not found.. Error outputs The device shall return command aborted if the command is not supported. An unrecoverable error encountered during execution of this command results in the termination of the command. The amount of data transferred is indeterminate. See Error! Reference source not found.. Page 10 of 11 June 6, 2005

11 2.1.5 TRUSTED SEND 5Fh, DMA data-out Feature Set This command is optional for devices implementing the General feature set. This command is optional for devices implementing the Trusted Computing feature set. Description See the TRUSTED SEND (5Fh) command for the description of this command. Inputs Word Name Description h Feature PKT_TYP SP_CTRL IPID PROTECTION_TYPE 01h Count TRANSFER_LENGTH [ 7:0] 02h LBA Low TRANSFER_LENGTH [15:8] 03h LBA Mid KEY_EXT Reserved SPID 04h LBA High KEY_IDENTIFIER 05h Command 5Fh See the TRUSTED SEND (5Eh) command for description of the parameter fields. Normal outputs See Error! Reference source not found.. Error outputs The device shall return command aborted if the command is not supported. An unrecoverable error encountered during execution of this command results in the termination of the command. The amount of data transferred is indeterminate. See Error! Reference source not found.. Page 11 of 11 June 6, 2005