1、JEDEC STANDARD Universal Flash Storage (UFS) Security Extension JESD225 NOVEMBER 2016 JEDEC SOLID STATE TECHNOLOGY ASSOCIATION NOTICE JEDEC standards and publications contain material that has been prepared, reviewed, and approved through the JEDEC Board of Directors level and subsequently reviewed
2、and approved by the JEDEC legal counsel. JEDEC standards and publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and ob
3、taining with minimum delay the proper product for use by those other than JEDEC members, whether the standard is to be used either domestically or internationally. JEDEC standards and publications are adopted without regard to whether or not their adoption may involve patents or articles, materials,
4、 or processes. By such action JEDEC does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the JEDEC standards or publications. The information included in JEDEC standards and publications represents a sound approach to product specification
5、 and application, principally from the solid state device manufacturer viewpoint. Within the JEDEC organization there are procedures whereby a JEDEC standard or publication may be further processed and ultimately become an ANSI standard. No claims to be in conformance with this standard may be made
6、unless all requirements stated in the standard are met. Inquiries, comments, and suggestions relative to the content of this JEDEC standard or publication should be addressed to JEDEC at the address below, or refer to www.jedec.org under Standards and Documents for alternative contact information. P
7、ublished by JEDEC Solid State Technology Association 2016 3103 North 10th Street Suite 240 South Arlington, VA 22201-2107 This document may be downloaded free of charge; however JEDEC retains the copyright on this material. By downloading this file the individual agrees not to charge for or resell t
8、he resulting material. PRICE: Contact JEDEC Printed in the U.S.A. All rights reserved PLEASE! DONT VIOLATE THE LAW! This document is copyrighted by JEDEC and may not be reproduced without permission. For information, contact: JEDEC Solid State Technology Association 3103 North 10th Street Suite 240
9、South Arlington, VA 22201-2107 or refer to www.jedec.org under Standards-Documents/Copyright Information. JEDEC Standard No. 225 -i- UNIVERSAL FLASH STORAGE (UFS) SECURITY EXTENSION Contents Foreword iii Introduction iii 1 Scope 1 2 Normative Reference . 1 3 Terms and Definitions 2 4 IEEE Functional
10、 Requirements 3 4.1 IEEE 1667 Overview . 3 4.2 IEEE 1667s split command structure . 3 4.3 IEEE 1667 structure . 4 4.4 Requirements for IEEE 1667 functionality in the UFS security extension . 4 5 TCG Storage Security Functional Requirements . 5 5.1 TCG Storage Security overview 5 5.2 Requirements for
11、 the TCG Storage Core in the UFS security specification 5 5.3 Requirements for the TCG Storage Opal SSC in the UFS security specification 5 5.3.1 Level 0 Discovery 6 5.3.2 Properties Requirements 10 5.4 Requirements for the TCG Storage DataStore Tables feature set in the UFS security specification .
12、 10 5.5 Requirements for the TCG Storage Support Single User Mode feature set in the UFS security specification . 12 5.6 Requirements for security characteristics for UFS devices that support the security extension 12 6 UFS Security Data Transport . 13 6.1 SECURITY PROTOCOL IN/OUT Commands 13 6.1.1
13、SECURITY PROTOCOL IN command 13 6.1.2 SECURITY PROTOCOL OUT command 14 6.2 Discovery of IEEE 1667 protocol support . 14 7 Security Interactions with UFS Operations . 15 7.1 Security Support Restrictions on Logical Unit 15 7.2 Authentication and Access Control Management on Logical Unit . 15 JEDEC St
14、andard No. 225 -ii- Contents (contd) 8 Error Handling . 15 8.1 IEEE 1667 errors (Informative) . 15 8.1.1 Command Out of Sequence . 15 8.1.2 Silo Index mismatch in SECURITY_PROTOCOL_IN, SECURITY_PROTOCOL_OUT 16 8.1.3 Transport Specific Error 16 8.2 UFS Transport Errors . 16 8.2.1 SECURITY PROTOCOL IN
15、/OUT Specific Error 16 8.2.2 Unauthorized Access . 16 9 Configuration . 17 9.1 SE Logical Unit Configuration 17 Tables Table 5-1: Level 0 Discovery - TPer Feature Descriptor 6 Table 5-2: Level 0 Discovery - Geometry Reporting Feature Descriptor . 8 Table 5-3: Level 0 Discovery - Opal SSC V2.01 Featu
16、re Descriptor . 9 Table 5-4: Property Requirements 10 Table 5-5: Level 0 Discovery - DataStore Table Feature Descriptor . 11 Table 6-1: SECURITY PROTOCOL IN Command Descriptor Block 13 Table 6-2: SECURITY PROTOCOL field value 13 Table 6-3: SECURITY PROTOCOL OUT Command Descriptor Block 14 Table 9-1:
17、 bLUWriteProtect parameter 17 JEDEC Standard No. 225 -iii- Foreword This UFS Security Extension Standard is an extension to the UFS Standards, JESD220. Introduction The UFS Standard, JESD220, defines a managed memory device capable of storing code and data. UFS devices are intended to offer the perf
18、ormance and features required by mobile devices while maintaining low power consumption. The UFS device contains features that support high throughput for large data transfers and performance for small random data accesses more commonly found in code usage. It also contains many desirable features f
19、or mobile applications. This document describes the requirements to implement security functionality described in IEEE1667, TCGCore, TCGOpal, TCGAddDST, TCGSUM and TCGSIIS in an UFS device. There are three external sets of requirements on the class of UFS device that support this security extension.
20、 These are IEEE 1667 layer requirements, the TCG layer requirements, and requirements related to UFS security data transport and interaction with UFS functionality. JEDEC Standard No. 225 -iv- JEDEC Standard No. 225 Page 1 UNIVERSAL FLASH STORAGE (UFS) SECURITY EXTENSION (From JEDEC Board Ballot JCB
21、-12-60, formulated under the cognizance of the JC-64.1 Subcommittee on Electrical Specifications and Command Protocols.) 1 Scope This document provides a comprehensive definition of the UFS security requirements for implementation of IEEE 1667 and TCG Opal security functionality. It also provides de
22、sign guidelines and defines a tool box of macro functions and algorithms intended to reduce design-in overhead. 2 Normative Reference The following normative documents contain provisions that through reference in this text, constitutes provisions of this standard. For dated references, subsequent am
23、endments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated. For undated references, the latest edition of the norma
24、tive document referred to applies. InterNational Committee on Information Technology Standards (INCITS), T10 Technical Committee SAM, SCSI 30 Architecture Model 5 (SAM5), Revision 05, 19 May 2010 InterNational Committee on Information Technology Standards (INCITS), T10 Technical Committee SPC, SCSI
25、Primary Commands 4 (SPC-4), Revision 27, 11 October 2010 InterNational Committee on Information Technology Standards (INCITS), T10 Technical Committee SBC, SCSI Block Commands 3 (SBC3), Revision 24, 05 August 2010 IEEE 1667, IEEE P1667 2015 Standard for Discovery, Authentication, and Authorization i
26、n Host Attachments of Storage Devices. Trusted Computing Group TCGCore, TCG Storage Architecture Core Specification, Version 2.01, Revision 1.00 Trusted Computing Group TCGOpal, TCG Storage Security Subsystem Class: Opal Specification, Version 2.01, Revision 1.00 Trusted Computing Group TCGAddDST, T
27、CG Storage Opal SSC Feature Set: Additional DataStore Tables Specification, Version 1.00, Revision 1.00 Trusted Computing Group TCGSUM, TCG Storage Opal SSC Feature Set: Single User Mode Specification, Version 1.00, Revision 2.00 Trusted Computing Group TCGSIIS, TCG Storage Interface Interactions Sp
28、ecification (SIIS), Version 1.05, Revision 1.00 JEDEC JESD220A UFS, Universal Flash Storage (UFS 2.0) JEDEC Standard No. 225 Page 2 3 Keywords and Abbreviations Keywords Several keywords are used to differentiate levels of requirements and options, as follow: can - A keyword used for statements of p
29、ossibility and capability, whether material, physical, or causal (can equals is able to). expected - A keyword used to describe the behavior of the hardware or software in the design models assumed by this standard. Other hardware and software design models may also be implemented. ignored - A keywo
30、rd that describes bits, bytes, quadlets, or fields whose values are not checked by the recipient. mandatory - A keyword that indicates items required to be implemented as defined by this standard. may - A keyword that indicates a course of action permissible within the limits of the standard (may eq
31、uals is permitted). must - The use of the word must is deprecated and shall not be used when stating mandatory 61 requirements; must is used only to describe unavoidable situations. optional - A keyword that describes features which are not required to be implemented by this standard. However, if an
32、y optional feature defined by the standard is implemented, it shall be implemented as defined by the standard. reserved - A keyword used to describe objectsbits, bytes, and fieldsor the code values assigned to these objects in cases where either the object or the code value is set aside for future s
33、tandardization. Usage and interpretation may be specified by future extensions to this or other standards. A reserved object shall be zeroed or, upon development of a future standard, set to a value specified by such a standard. The recipient of a reserved object shall not check its value. The recip
34、ient of a defined object shall check its value and reject reserved code values. shall - A keyword that indicates a mandatory requirement strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to). Designers are required to imple
35、ment all such mandatory requirements to assure interoperability with other products conforming to this standard. should - A keyword used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of actio
36、n is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that). will - The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in s
37、tatements of fact. JEDEC Standard No. 225 Page 3 3 Keywords and Abbreviations (contd) Abbreviations etc. - And so forth (Latin: et cetera) e.g. - For example (Latin: exempli gratia) i.e. - That is (Latin: id est) 4 IEEE 1667 Functional Requirements 4.1 IEEE 1667 Overview IEEE 1667 IEEE1667 was desig
38、ned to support native security protocols and tunneling of externally defined security protocols (e.g. TCG SWG and Smart Cards) across multiple transports (e.g., SCSI, USB, ATA). For a full description of IEEE 1667 see http:/ and http:/standards.ieee.org. 4.2 IEEE 1667s split command structure IEEE 1
39、667 uses an output and input transport specific command pair to execute a single IEEE 1667 command. This command pairing only affects the security protocols, and not the transports normal user data access commands. The output transport command consists of a transport specific command data block (CDB
40、) and an associated output payload. Together, these include the IEEE 1667 command, any IEEE 1667 output parameters and any tunneled command/data. This is followed by an input transport command with a transport specific CDB and an associated input payload. Together, these carry the same IEEE 1667 com
41、mand, any IEEE 1667 input parameters, an IEEE 1667 status response, any tunneled input data, and any tunneled status information. In this split command process, the command is not executed in the output phase, but is executed in the input phase (i.e., after receipt of the input transport command) wh
42、ere status can be reported in the command payload. This split command structure was designed to enable two desirable features: the transport status, the IEEE 1667 command status and the tunneled protocol status are reported such that each can be processed by the appropriate driver layer; and the hos
43、t OS can support a single security communication protocol that supports multiple transports and does not have to implement multiple security-application-specific protocols in multiple transport drivers. JEDEC Standard No. 225 Page 4 4.3 IEEE 1667 structure IEEE 1667 functionality is contained by a d
44、evice in one or more IEEE 1667 Addressable Command Targets (ACT). Each ACT consists of one or more addressable IEEE 1667 command processing blocks called silos. Each IEEE 1667 ACT is required to include one IEEE 1667 Probe silo which provides discovery of additional IEEE 1667 silos. Additional IEEE
45、1667 silos are optional in IEEE 1667. The IEEE 1667 TCG silo was designed to enable wrapping of the TCG Storage communications protocol within the IEEE 1667 communications protocol. The IEEE 1667 TCG silo provides an interface for capability discovery and communication with the underlying TCG Storag
46、e compliant security subsystem, a Trusted Peripheral (TPer). The IEEE 1667 TCG silo allows a host TCG application to communicate through any transport supported by IEEE 1667 to a TPer without requiring native support of the TCG Storage communication protocols in the transport driver. Note that the w
47、hile TPer typically contains cryptographic functionality, the IEEE 1667 TCG silo does not; the 1667 TCG silo is a conduit to TCG functionality. 4.4 Requirements for IEEE 1667 functionality in the UFS security extension An UFS device which supports the UFS Security Extension shall contain exactly one
48、 IEEE 1667 ACT which shall contain: exactly one IEEE 1667 Probe silo, exactly one IEEE 1667 TCG silo, and no additional IEEE 1667 silos The IEEE 1667 Probe silo of an UFS device which supports the UFS Security Extension shall return a status of Default Behavior upon successfully processing an IEEE 1
49、667 Probe command. The IEEE 1667 TCG silo of an UFS device which supports the UFS Security Extension shall support all defined commands and not only the Get Silo Capabilities commands. JEDEC Standard No. 225 Page 5 5 TCG Storage Security Functional Requirements 5.1 TCG Storage Security overview The TCG Storage Security specifications were defined to provide an architecture that puts storage devices under the policy control of a trusted platform host; The TCG Storage Core specification TCGCore provides a general
