SanDisk Corporation TrustedFlash v1.0 – microSD (Firmware Version: 1.0; Hardware Versions: HermonS2TM 256MB, HermonS2TM 512MB, HermonS2TM 1GB, and HermonS2TM 2GB) FIPS 140-2 Non-Proprietary Security Policy Level 3 Validation Document Version 2.1 Prepared for: Prepared by: SanDisk Corporation Corsec Security, Inc. 601 McCarthy Boulevard 10340 Democracy Lane, Suite 201 Milpitas, CA 95035 Fairfax, VA 22030 Phone: (408) 801-1000 Phone: (703) 267-6050 Fax: (408) 801-8657 Fax: (703) 267-6810 http://www.sandisk.com http://www.corsec.com © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Revision History Version Modification Date Modified By Description of Changes 0.1 2005-05-31 Rumman Mahmud Initial draft. 0.2 2007-02-03 Xiaoyu Ruan New draft based on HermonS2T. 0.3 2007-07-25 Xiaoyu Ruan Updated Table 6. 0.4 2007-08-01 Xiaoyu Ruan Updated Table 6 and Section 2.6.4. 0.5 2007-08-09 Xiaoyu Ruan Updated Section 2.3. 0.6 2007-08-22 Xiaoyu Ruan Addressed Lab’s comments. 0.7 2007-08-24 Xiaoyu Ruan Addressed Lab’s comments. 0.8 2007-08-27 Xiaoyu Ruan Addressed Lab’s comments. 0.9 2007-09-04 Xiaoyu Ruan Addressed Lab’s comments. 1.0 2007-10-01 Xiaoyu Ruan Addressed Lab’s comments. 1.1 2007-11-15 Xiaoyu Ruan Addressed Lab’s comments. 1.2 2007-11-21 Xiaoyu Ruan Addressed Lab’s comments. 1.3 2007-11-25 Xiaoyu Ruan Minor changes. 1.4 2007-11-28 Xiaoyu Ruan Minor changes. 1.5 2007-11-30 Xiaoyu Ruan Release for CMVP. 1.6 2008-01-29 Xiaoyu Ruan Addressed CMVP comments. 1.7 2008-01-31 Xiaoyu Ruan Addressed CMVP comments. 1.8 2008-05-07 Xiaoyu Ruan Addressed CMVP comments. 1.9 2009-06-17 Darryl Johnson Updates to reflect changes in power-up self-test execution, zeroization mechanism and FIPS mode indicator 2.0 2009-07-02 Darryl Johnson Additional information regarding zeroization mechanism 2.1 2009-09-01 Darryl Johnson Final CMVP comments Page 2 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Table of Contents 1 INTRODUCTION ...............................................................................................................................................6 1.1 PURPOSE.........................................................................................................................................................6 1.2 DOCUMENT ORGANIZATION ...........................................................................................................................6 2 TRUSTEDFLASH V1.0 – MICROSD ...............................................................................................................7 2.1 OVERVIEW......................................................................................................................................................7 2.2 INTERFACE .....................................................................................................................................................8 2.3 ROLES AND SERVICES.....................................................................................................................................9 2.3.1 Authentication......................................................................................................................................10 2.3.2 Crypto-Officer Role .............................................................................................................................11 2.3.3 User Role .............................................................................................................................................15 2.3.4 Unauthenticated Services ....................................................................................................................16 2.4 PHYSICAL SECURITY ....................................................................................................................................17 2.5 OPERATIONAL ENVIRONMENT......................................................................................................................17 2.6 CRYPTOGRAPHIC KEY MANAGEMENT..........................................................................................................17 2.6.1 Key Generation ....................................................................................................................................19 2.6.2 Key Input/Output .................................................................................................................................19 2.6.3 Key Storage..........................................................................................................................................19 2.6.4 Key Zeroization....................................................................................................................................20 2.7 SELF-TESTS ..................................................................................................................................................20 3 SECURE OPERATION....................................................................................................................................21 3.1 INITIAL SETUP ..............................................................................................................................................21 3.1.1 Secure Delivery....................................................................................................................................21 3.1.2 Installing the Card Reader and Drivers ..............................................................................................21 3.1.3 Configuring the Card Reader and Drivers ..........................................................................................21 3.1.4 Installing the Card in a Card Reader ..................................................................................................21 3.2 MODULE INITIALIZATION AND CONFIGURATION ..........................................................................................21 3.3 CREATING TREES THAT ARE CONFIGURED TO OPERATE IN AN APPROVED MODE ........................................22 3.3.1 Sending TrustedFlash Commands to the Card to Create One or More Root AGPs ............................22 3.3.2 Sending TrustedFlash Commands to the Card to Prevent the Creation of New Trees ........................25 3.3.3 Sending TrustedFlash Commands to the Card to Create One or More Non-Root ACRs ....................25 3.4 FIPS MODE STATUS INDICATOR...................................................................................................................25 3.5 IDENTIFYING THE ERROR STATE...................................................................................................................25 3.5.1 Identifying Power-up Integrity Self-Test Errors ..................................................................................25 3.5.2 Identifying Power-up Cryptographic Algorithm KAT Errors ..............................................................25 3.5.3 Identifying Conditional Self-Test Errors..............................................................................................26 3.5.4 Recovering from FIPS Self-Test Errors ...............................................................................................26 3.6 MODULE ZEROIZATION ................................................................................................................................26 3.6.1 Zeroizing a Tree...................................................................................................................................26 3.7 COMMAND REFERENCE AND COMMUNICATION REQUIREMENTS..................................................................26 3.7.1 SD Command Compatibility ................................................................................................................26 3.7.2 SD Command Usage............................................................................................................................26 3.7.3 TrustedFlash Command Reference......................................................................................................26 4 REFERENCES ..................................................................................................................................................27 5 ACRONYMS......................................................................................................................................................28 Page 3 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Table of Figures FIGURE 1 – TRUSTEDFLASH FORM FACTOR ...................................................................................................................8 FIGURE 2 – PIN ASSIGNMENT ON THE CONTACT PAD .....................................................................................................8 FIGURE 3 – SAMPLE SSA COMMAND USING TRAILING DUMMY SECTORS ...................................................................10 FIGURE 4 – CRYPTO-OFFICER AND USER OPERATION ..................................................................................................21 Page 4 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION...................................................................................................7 TABLE 2 – PHYSICAL AND FIPS 140-2 INTERFACE MAPPINGS FOR SD MODE................................................................9 TABLE 3 – CRYPTO-OFFICER SERVICES........................................................................................................................11 TABLE 4 – USER SERVICES ...........................................................................................................................................16 TABLE 5 – UNAUTHENTICATED SERVICES....................................................................................................................16 TABLE 6 – LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS.....................................18 TABLE 7 – ACR LOGIN ALGORITHMS ..........................................................................................................................22 TABLE 8 – TREE AUTHENTICATION CAPABILITY BITMASK ..........................................................................................24 TABLE 9 – ACRONYMS .................................................................................................................................................28 Page 5 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 1 Introduction 1.1 Purpose This document is a non-proprietary Cryptographic Module Security Policy for the TrustedFlash v1.0 – microSD (firmware version: v1.0; hardware versions: HermonS2TM 256MB, HermonS2TM 512MB, HermonS2TM 1GB, and HermonS2TM 2GB) from SanDisk Corporation. This Security Policy describes how the TrustedFlash v1.0 – microSD meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 3 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 – Security Requirements for Cryptographic Modules) details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/cryptval/. In this document, the TrustedFlash v1.0 – microSD is referred to as the card or the module. 1.2 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: • Vendor evidence • Finite state machine • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to SanDisk. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to SanDisk and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact SanDisk. Page 6 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 2 TrustedFlash v1.0 – microSD 2.1 Overview SanDisk Corporation is the original inventor of flash storage cards and is the world’s largest supplier of flash data storage card products using its patented, high-density flash memory and controller technology. Announced on September 27, 2005, the TrustedFlash v1.0 – microSD is a mass-storage device developed and produced by SanDisk Corporation. The TrustedFlash is a new technology that enables consumers to buy premium music, movies, and games on flash memory cards for use interchangeably in mobile phones, laptop computers, Personal Digital Assistants (PDAs), and other portable devices. For example, with the TrustedFlash v1.0 – microSD, music producers and movie studios are able to release premium content on TrustedFlash products because they provide the superior security and digital rights management (DRM) solutions that are required by these providers. Consumers are able to download premium content from online digital music services through their mobile phones or personal computers. The TrustedFlash v1.0 – microSD empowers consumers to use their purchased content in a multitude of supported devices. This is in contrast with today’s closed, proprietary systems that bind content to a particular host device, such as a specific cell phone or MP3 player. The TrustedFlash technology empowers the card itself to be the manager of digital rights. It provides independence from the host, thus giving consumers the freedom to transfer the card and its content to other supported devices without compromising its content protection system. The TrustedFlash v1.0 – microSD also function as mass-storage devices in non-secure host devices. The cards with TrustedFlash v1.0 – microSD embedded are highly secure. This is due to an on-board processor, a high-performance cryptographic engine, and tamper-resistant technology. They are designed to provide a much higher level of security than has previously existed on memory cards and on most consumer electronics devices. Cards built on the TrustedFlash platform will provide full DRM capabilities and support industry security standards including both symmetric and asymmetric cryptographic algorithms. TrustedFlash cards can be customized to meet any Original Equipment Manufacturer (OEM) customer’s specific security and DRM solutions, including integrating their own chosen DRM solution and rights portability across many devices. TrustedFlash cards are available immediately to OEM customers in the miniSD, microSD, and Secure Digital (SD) card formats. The TrustedFlash v1.0 – microSD supports an Approved mode of operation and a non-Approved mode of operation. The TrustedFlash v1.0 – microSD is validated at the following FIPS 140-2 Section levels (when operating in the Approved mode of operation). Table 1 – Security Level per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 3 2 Cryptographic Module Ports and Interfaces 3 3 Roles, Services, and Authentication 3 4 Finite State Model 3 5 Physical Security 3 6 Operational Environment N/A 7 Cryptographic Key Management 3 8 EMI/EMC 3 9 Self-tests 3 Page 7 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Section Section Title Level 10 Design Assurance 3 11 Mitigation of Other Attacks N/A In Table 1, N/A indicates “Not Applicable”. EMC and EMI refer to Electromagnetic Compatibility and Electromagnetic Interference, respectively. 2.2 Interface The cryptographic boundary of each model of the TrustedFlash v1.0 – microSD is defined by its microSD compatible enclosure. The module is shipped in a TrustedFlash form factor as depicted in Figure 1. The cryptographic boundary is the whole microSD card. Figure 1 – TrustedFlash Form Factor The module’s physical interfaces are composed of a set of contact pins providing data input, output, power, and clock. No manual control interface is included in the module. The contact pad exposes eight pins as depicted in Figure 2. Figure 2 – Pin Assignment on the Contact Pad The SD and the Serial Peripheral Interface (SPI) are the two alternative communication protocols used by SD cards. Applications can choose either mode. Mode selection is transparent to the host. Pin assignments for the module are listed in Table 2 (for the SD mode). The contact pins, connected to the internal bond wires, can be mapped into the five FIPS 140-2 logical interfaces. The following is a list of the FIPS 140-2 logical interfaces implemented in the module: Page 8 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 1. Data Input 2. Data Output 3. Control Input 4. Status Output The rightmost columns of Table 2 map the physical interface of the module to the FIPS 140-2 interfaces. Table 2 – Physical and FIPS 140-2 Interface Mappings for SD Mode Pin Name Bond Wire Pin Assignment FIPS 140-2 Interface 1 DAT2 Data line [bit 2] Data input, data output 2 CD/DAT3 Card detect/Data line [bit 3] Data input, data output 3 CMD Command response Control input, status output 4 VDD Supply voltage Power 5 CLK Clock Control input 6 VSS Supply voltage ground Power 7 DAT0 Data line [bit 0] Data input, data output 8 DAT1 Data line [bit 1] Data input, data output All data is passed to the cryptographic module using standard write and read commands to a buffer. Therefore, from the host’s point of view, sending a command means writing data to a special file on the memory device, which is used as the buffer file. Getting information from the module is done via reading data from the buffer file. 2.3 Roles and Services The module supports two roles: a Crypto-Officer role and a User role. A Crypto-Officer as an operator can log into the system Access Control Records (ACRs) and/or root ACR Group (AGP) that can access all services. Any entity attempting to use the TrustedFlash commands is required to login to the TrustedFlash system through an ACR. An ACR can be considered a user account. Different ACRs may share common interests and privileges within the system, such as secured domains from which to read and write data. ACRs with attributes in common are grouped in ACR groups called AGPs. AGPs and the ACRs are organized in hierarchical trees. The AGP tree structure enables the module to handle multiple applications. This is where each application comprises a collection of identifiable entities represented as an ACR on the tree. Mutual exclusion between the applications is achieved by ensuring there is no cross-talk or cross-communication between the tree branches. A tree of the Approved mode is a tree with the root AGP configured with the authentication and key establishment method defined as one of the FIPS-Approved schemes shown in Table 7. New ACRs created on a tree of the Approved mode are also working in the Approved mode because the “Tree Authentication Restrictions” command has been executed to the tree during the tree creation process. See Section 3 “Secure Operation” of this document for more information. Non-Approved mode trees are not supported when the module has been configured to operate in the Approved mode of operation. After FIPS-Approved trees are created and configured according to security policy instructions, the module must then be locked to prevent any additional trees from being created. The procedures to create trees and to lock the card can be found below in Section 3 “Secure Operation” of this document. All services of the module are provided via TrustedFlash commands. The TrustedFlash commands are passed to the module using standard SD Write and Read commands. Therefore, from the host point of view, sending a TrustedFlash command means writing data to a special file on the memory device used as the buffer file. Getting Page 9 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 information from the module is done via reading data from the buffer file. Generally speaking, TrustedFlash commands are sent and received using SD messages as depicted in Figure 3 – Sample SSA Command Using Trailing Dummy Sectors. SSA means Security Storage Application. SSA Either Single Block or Mult BLK operation Dummy Dummy Dummy Dummy Dummy SD write ~200ms write ~200mswrite write write SSA write ~200ms Busy Busy Busy Figure 3 – Sample SSA Command Using Trailing Dummy Sectors In order to access the encrypted contents of the module, the Crypto-Officer or User has to authenticate to ACRs. Appropriate TrustedFlash commands have to be sent to the module in order to access desired encrypted contents. See [5] for details. 2.3.1 Authentication The module identifies individual operators using ACR identifiers as described in the previous section. The module authenticates individual operators using the authentication mechanism that has been configured for the ACR or AGP that the operator is attempting to log into, also as described in the previous section. A tree configured to the Approved mode of operation supports one of the following four authentication schemes. 1. One-way symmetric authentication. The module and the host own the same symmetric key, which is used to authenticate the host to the module. An optional Personal Identification Number (PIN) can be configured for use in this scheme. 2. Two-way symmetric authentication. The module and the host own the same symmetric key, which is used for mutual authentication. An optional PIN can be configured for use in this scheme. 3. One-way asymmetric authentication. The host presents its certificate to the module for authentication. The module has the host’s root certificate and uses it to verify the signature on host’s certificate. The module builds and verifies certificate paths using provided certificates. An optional PIN can be configured for use in this scheme. 4. Two-way asymmetric authentication. The host and the module present their certificates to each other for mutual authentication. The host and the module have each other’s root certificate for signature verification. The module builds and verifies certificate paths using provided certificates. An optional PIN can be configured for use in this scheme. While a TrustedFlash command is in progress, no other SD commands will be send by the Host, that the host application needs to lock device driver for duration of every TrustedFlash command in order to be able to communicate with the card, and that TrustedFlash commands need trailing dummy sectors, i.e. SD dummy writes performed after the SSA write. 200ms is required between SD writes, so assuming even just one dummy write, it would take 400ms for the host to send one command to the card. Since there will always be at least two commands, one to attempt to login, and one to determine if the operation was successful, one login attempt will take 800ms. If each attempt takes about one second, only roughly 75 attempts can be made in a one-minute period. Since the probability that a single random attempt will succeed is 1 in 280, which is less than 1 in 106, since the weakest authentication schemes provide 80 bits of security, the probability that during a 1 minute period a random attempt will succeed is 75 in 280, which is less than 1 in 105. Page 10 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 2.3.2 Crypto-Officer Role Table 3 shows the services for the Crypto-Officer role1. For details of the commands please refer to Section 4 of [5]. The purpose of each service is shown in the first column (“Service”), and the corresponding function is described in the second column (“Description”). CSP stands for Critical Security Parameter. User services defined in Table 5 are also available to a Crypto-Officer. Certain TrustedFlash commands can be called by Users if the ACR that they log into has been configured by a Crypto-Officer with the necessary permission. There are two types of permissions: ACR Management (ACAM) permissions and Domain permissions. See [5] for additional information about the Crypto-Officer services listed in the table below, including whether or not Crypto-Officers can grant a corresponding ACAM or Domain permission that would allow a User to execute the command. Table 3 – Crypto-Officer Services Keys/CSPs Service Description Input Output and Type of Access Password Provides password protection for an Tree name, AGP name, Status Password – Credentials ACR requiring a password during login ACR name, password, read command Symmetric Provides symmetric cryptography Tree name, AGP name, Status Symmetric Credentials protection for an ACR requiring a ACR name, key type, key, key – read symmetric key during login command Import RSA Imports RSA key pair from the host Tree name, AGP name, Status RSA key key pair application to the module for ACR name, Distinguished pair – write asymmetric authentication Encoding Rules (DER) structure size, DER structure, command Import Adds certificate credentials during Tree name, AGP name, Status RSA public Certificate ACR creation ACR name, certificate size, key – write certificate type, certificate, command Generate RSA Generates an RSA key pair Tree name, AGP name, RSA key RSA key key pair ACR name, RSA key size, pair, status pair – write command Root AGP Locks the root AGP so no additional Tree name, command Status None Creation Done ACRs may be created Disable Disables the create system ACR Command Status None System ACR feature Creation Set Root AGP Configures the root AGP creation One of following modes: Status None Creation Mode mode setting open, controlled, locked, command Disable Root Disables the change root AGP Command Status None AGP Change creation feature Mode Restrict Tree Defines which authentication A 4-byte value indicating Status None Authentication algorithms are restricted for use for all which algorithms are Capabilities ACRs which belong to the Tree allowed, command 1 The module enables access to the public partition through standard SD read and write commands or through the use of TrustedFlash commands. The module enables ACRs to create domains within the public partition and encrypt individual files. Accessing encrypted files within the public partition, as well as setting the access rights to the partitions, is accomplished using TrustedFlash system commands. Page 11 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Keys/CSPs Service Description Input Output and Type of Access Create ACR Creates ACRs and AGPs AGP name, ACR name, Status Password, authentication algorithm, Symmetric unblocked ACR name, key, RSA management permissions, public key – maximum number of write consecutive authentication failures allowed, command Create ACR Activates an ACR. The new ACR must Tree name, AGP name, Status None Done be a new (child) ACR of the AGP that ACR name, command the requesting ACR resides within. If a new ACR is created, it will be created as a child of the AGP that the requesting ACR resides within Delete ACR Deletes an ACR. Only sent by a Tree name, AGP name, Status Password, creator ACR to delete a new (child) ACR name, command Symmetric ACR it has created key, RSA public key – delete Unblock ACR Unblocks a specific ACR. Only sent by Tree name, AGP name, Status None an ACR that has explicit permission to ACR name, command unblock a specific ACR Create Creates a partition. Only sent by an New partition name, new Status None Partition ACR residing in a root AGP partition size, decreased partition name, command Update Only sent by an ACR residing in a root First partition name, new Status None Partition AGP. The command is limited to the partition size, second repartition of two adjacent partitions partition name, command only Delete Partition Deletes a partition. Only sent by an Deleted Partition Name, Status None ACR residing in a root AGP Increased partition name, command Restrict Public Restricts the regular read and write Restriction Code: one of Status None Partition commands to and from the public the following restrictions: Access partition, which is also known as the write, read, read_write, user area. This restriction applies to command read and write commands sent by the host and are not part of the TrustedFlash command protocol Create Domain Executes the Create Domain Domain name, domain Status Symmetric command only if it has the permission encryption type, source for key - write granted by ACAM_CREATE_DOMAIN domain Content Encryption Key (CEK), application identification (ID), domain CEK, command Delete Domain Only a domain owner may send the Domain name, command Status None Delete Domain command to delete a domain Export Domain Exports a domain key from the module Domain name, application 128-bit AES Symmetric Key to a host ID, command Domain CEK, key - read status Delegate Delegates Domain Permissions Domain name, tree name, Status None Domain AGP name, ACR name, Permissions permission type, command Delegate Delegates Partition Permissions Partition name, tree name, Status None Partition AGP name, ACR name, Permissions permission type, command Page 12 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Keys/CSPs Service Description Input Output and Type of Access Retract Retracts Domain Permissions Domain name, tree name, Status None Domain AGP name, ACR name, Permissions permission type, command Retract Retracts Partition Permissions Partition name, tree name, Status None Partition AGP name, ACR name, Permissions permission type System Login Issued when a host attempts to use Tree name, AGP name, Status None the module through one of the ACRs. ACR name, command The command starts the login/authentication process ACR Query Reads TrustedFlash information that Query type, group index, Session ID, None is within the scope of the currently command group index, logged-in ACR number of objects in the list, maximum number of objects in sector, object list, status. Open Stream Sets up the module for data stream Partition name, flash Tree name, None transfers to read or write data. This storage domain name, AGP name, command will determine the stream direction, transfer ACR name, characteristics of the data stream, and type, command error, stream whether to read or write data with or ID, status, without domain information along with status. other required data Close Stream Closes a stream Stream ID, command Status None Change ACR In the case of a root ACR name Tree name, AGP name, Status None Name change, the root ACR must be logged- Old ACR name, New ACR in and the name change accomplished name, command through the root ACR session. However, when a regular ACR name warrants a change, it must be made only by the creator (father) ACR System Query Outputs general module information Query type, group index, TrustedFlash None such as version support and current command version configuration regarding the visible number, Root ACRs and TrustedFlash Command applications size, number of objects in the list, maximum number of objects in sector, object list, status. Send Sends the actual ACR password to be Password, command Pass/Fail, Password - Password to verified by the TrustedFlash system status. read TrustedFlash located on the memory card. After Card sending the Command Status command, the host will be able to read the command status. Upon command completion, the host will also be able to read the PASS/FAIL status of the authentication process Page 13 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Keys/CSPs Service Description Input Output and Type of Access Get Challenge Acquires a symmetric challenge from Command Symmetric None from the card challenge, TrustedFlash status. Card Send Sends the host challenge to the card Symmetric challenge, Status None Challenge to command TrustedFlash Card Get Challenge Acquires card’s response to the host Command Card None Response from challenge response, TrustedFlash status. Card Send Sends the host response to the card Host response, command Status None Challenge challenge Response from TrustedFlash Card Get A step in the symmetric authentication Command Pre-Master None TrustedFlash protocol. This command reads the secret, status Pre-Master random number generated for the Secret session key by the module Send Host Pre- A step in the symmetric authentication Symmetric challenge, Status ACR Master Secret protocol. This command sends the command Symmetric to random number generated for the Credential – TrustedFlash session key by the host read Card Send Start Send “Start Session” string to host “Start Session” string, PIN, Status PIN – read Session command Message Get Get “Authentication Complete” phrase Command “Authenticati PIN – read Authentication from host on Complete” Complete phrase, ACR Message PIN, status Get Exports the ACR public key Command “E” and “N” RSA public Asymmetric values of the key – read Device Public RSA public Key key, key size, status Set Sends the host/application public key RSA public key, key size, Status RSA public Asymmetric to the module command key – write Host Public Key Set Sends the host/application challenge RSA key size, random Status None Asymmetric number to module for signing with the challenge, command Host Random ACRs private key Challenge Verify Commands the host/application to Command Signed RSA private Asymmetric read the module signed challenge to random key – read Device Public verify the ACR’s public key challenge, Key status Get Commands the host/application to Command RSA key None Asymmetric read the module challenge that will be size, random Device signed with its private key challenge, Random status Challenge Page 14 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Keys/CSPs Service Description Input Output and Type of Access Verify Host Host/application signs the module RSA key size, signed Pass/Fail, RSA public Public Key challenge data and returns it to the challenge, command status key – read module for verification Set The host/application sends the module RSA key size, host secret Status None Asymmetric a number signed by the host private number, command Host Secret key Number Get The module sends a number signed Command RSA key RSA private Asymmetric by its private key to the size, ACR key – read Device Secret host/application generated Number secret number, status Set Host The host sends a certificate chain to Certificate size, if this Status None Certificate the TrustedFlash card. The certificate certificate is the last in the Chain buffer will follow the command sector chain, certificates revoke list size, command Get Device The host reads the TrustedFlash card Certificate size, if this Status None Certificate certificate chain certificate is the last in the Chain chain, command Change Changes an ACR’s password Tree name, AGP name, Status Password – Password ACR name, old password, delete, write new password, command Change Changes an ACR’s symmetric key Tree name, AGP name, Status Symmetric Symmetric Key ACR name, symmetric key key – delete, type, symmetric key, write command Get Zeroizing Returns the name of the Zeroizing Command Entity name None Entity entity Set Zeroizing Sets the name of the Zeroizing entity Zeroizing entity name Status None Entity to the System ACR Zeroize Zeroizes the System ACR and all Command Status Zeroize TrustedFlash ACRs (and their objects) in the system System Write Evokes a write transfer stream from Stream ID, start Logical Status Session key the module to the host/device- Block Address (LBA), – read application. Data is sent after a write- sector count, data buffer stream has been opened pointer, command Read Evokes a read transfer stream from Stream ID, start LBA, Status Session key the module to the host/device- sector count, data buffer – read application. Data is sent after a read- pointer, command stream has been opened Write Public Write data to the public partition Command Status None Partition Read Public Read data from the public partition Command Status None Partition 2.3.3 User Role Table 5 shows the services for the User role. Similar to Table 3, the purpose of each service is shown in the first column (“Service”), and the corresponding function is described in the second column (“Description”). The only services defined for the User role are to logs in/out the module and obtain command status. For details of the commands please refer to Section 4 of [5]. Page 15 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Table 4 – User Services Keys/CSP Service Description Input Output and Type of Access System Login Issued when a host attempts to use the module Tree name, Status None through one of the ACRs. The command starts AGP name, the login/authentication process. ACR name, command. Get Login After sending the system login command, the Tree name, Tree name, AGP None Status host/device application is required to send the AGP name, name, ACR Get Login Status command and receive the ACR name, name, ACR login status of the login process along with the session command status, error ID. This command must follow the ACR login code, session ID, command to proceed with the login sequence. If status the host fails to send this command after the ACR login command the login sequence will fail and the host will need to restart it. System Logout Issued when a host attempts to terminate a Command Status None session. The command ends all activities in the session. After this command is issued, the host must restart the login process in order to be able to execute further actions with the module. Additional 1. TrustedFlash commands that require ACAM Command Status See Crypto- TrustedFlash permissions Officer role commands 2. TrustedFlash commands that require Domain service permissions descriptions 2.3.4 Unauthenticated Services The services listed in Table 5 – Unauthenticated Services are not authenticated and are not specific to either Crypto- Officer or User role. Table 5 – Unauthenticated Services Keys/CSP Service Description Input Output and Type of Access Vendor Enables the host to request vendor or product Command Vendor specific data, None Query information about the card that is housing the status TrustedFlash system Command Sent to the system to prompt a return status Command Last command, Session key Status message from the previously sent command. session ID, command – read status, ACR login status, application specific status, tree authentication capability, status. Get Login After sending the system login command, the Tree name, Tree name, AGP None Status host/device application is required to send the AGP name, name, ACR name, Get Login Status command and receive the ACR name, ACR login status, status of the login process along with the command error code, session session ID. This command must follow the ID, status ACR login command to proceed with the login sequence. If the host fails to send this command after the ACR login command the login sequence will fail and the host will need to restart it Page 16 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Keys/CSP Service Description Input Output and Type of Access SD SD write and read commands used to send See [4] See [4] None Commands TrustedFlash commands from the host to the card or access public partitions. SPI SPI write and read commands used to send See [4] See [4] None Commands TrustedFlash commands from the host to the card or access public partitions.. 2.4 Physical Security The TrustedFlash v1.0 – microSD cards are multi-chip embedded modules that use a tamper-evident enclosure as a physical security mechanism. The enclosure uses a tamper-evident epoxy covering and a tamper-evident microSD plastic enclosure as physical security mechanisms. All card models are constructed identically in terms of locations of types of components, including physical security mechanisms. There are two chips that are covered on one side by epoxy and on the other by substrate. A non-removable, tamper evident plastic cover that is compatible with microSD card readers surrounds the substrate underneath the chips and the epoxy on top of the chips. The plastic cover exposes two sets of contact pins. One set of contact pins is covered by epoxy. There are two separate epoxy coverings in other words. The epoxy that covers the otherwise exposed contact pins surrounds the pins. The plastic cover cannot be removed without damaging the epoxy that covers the otherwise exposed contact pins. The epoxy that covers the otherwise exposed contact pins must be inspected periodically to ensure that physical security is maintained. • The plastic cover on the same side as the covered pins must also be inspected periodically to determine if there is visible evidence of tampering or if the substrate underneath the two chips has been exposed to ensure that physical security is maintained. • The plastic cover on the opposite side must also be inspected periodically to determine if there is visible evidence of tampering or if the epoxy covering the top of the two chips has been exposed to ensure that physical security is maintained. All card modules have been tested for and meets applicable Federal Communications Commission (FCC) EMI and EMC requirements for home use as defined in Subpart B of FCC Part 15. 2.5 Operational Environment The operational environment of the module is non-modifiable. The firmware included in the module cannot be upgraded or modified after the card leaves the factory. The module is capable of executing only certain commands from host applications. The command set is stored within the module and cannot be modified. The FIPS 140-2 requirements for operational environment are not applicable to the TrustedFlash v1.0 – microSD. 2.6 Cryptographic Key Management The module implements the following Approved cryptographic algorithms: • Advanced Encryption Standard (AES) – 128-bit, Cipher-Block Chaining (CBC), and Electronic Codebook (ECB) modes (Certificate #643) • Triple Data Encryption Standard (Triple-DES) – 112- and 168-bits, CBC and ECB modes (Certificate #595) • RSA Public Key Cryptography Standards (PKCS) #1 v2.1 and v1.5 signature generation/verification – 1024- and 2048-bit (Certificate #294) • Secure Hash Algorithm -1 (SHA-1) (Certificate #678) Page 17 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 • American National Standards Institute (ANSI) X9.31 Appendix A.2.4 Random Number Generator (RNG) with 128-bit AES (Certificate #366) The module implements the following non-Approved cryptographic algorithms: • DES • A non-Approved RNG for seeding the ANSI X9.31 Appendix A.2.4 RNG • RSA PKCS#1 v2.1 and v1.5 (key wrapping; key establishment methodology provides 80 bits or 112 bits of encryption strength; non-compliant less than 80 bits of encryption strength) • AES CBC MAC (used in firmware integrity test) The following table gives a list all cryptographic keys, cryptographic key components, and CSPs used by the module in the Approved mode of operation. Table 6 – List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key/ Type Generation / Input Output Storage Zeroization Use Key Component Secret AES symmetric Generated and No Plaintext in Not zeroized Compute AES CryptoKey key (128 bits) installed during non-volatile CBC MAC for manufacturing memory on firmware controller chip integrity test Not a CSP of the module CEK AES symmetric 1. During ACR Ciphertext Plaintext in By “Zeroize Encrypt a key (128 bits) creation, input from encrypted flash memory TrustedFlash domain on the host in ciphertext with session System” flash memory encrypted with session key command key 2. Generated internally by ANSI X9.31 Appendix A.2.4 RNG ACR AES/Triple- During ACR creation, No Plaintext in By “Zeroize Authentication Symmetric DES symmetric input from host in flash memory TrustedFlash Credential keys ciphertext encrypted System” with session key command ACR RSA key pair 1. During ACR RSA public Plaintext in By “Zeroize Authentication Asymmetric creation, input from key is output flash memory TrustedFlash Credential host in ciphertext in plaintext System” encrypted with session or ciphertext command key encrypted 2. Generated internally with session by ANSI X9.31 key Appendix A.2.4 RNG Page 18 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Key/ Key Type Generation / Input Output Storage Zeroization Use Component PIN User PIN for 1. During ACR No Plaintext in By “Zeroize Two-factor two-factor creation, input from flash memory TrustedFlash authentication authentication host in ciphertext System” 2. During command authentication, input from host in ciphertext encrypted by Session Key Session Key AES/Triple- 1. Generated internally 1. RSA- Plaintext in When session Encrypt/decrypt 2 DES symmetric by ANSI RNG encryption volatile is over session 2 keys 2. Input from host in form memory transmissions encrypted form using 2. Not between host 3 3 the ACR Credential output and card ANSI X9.31 RNG seed Generated internally No Plaintext in When a Initialize ANSI Appendix (128 bits) by a hardware RNG volatile random X9.31 Appendix A.2.4 RNG memory number is A.2.4 RNG seed generated by ANSI X9.31 Appendix A.2.4 RNG ANSI X9.31 AES key (128 Generated internally No Plaintext in When a Initialize ANSI Appendix bits) by a hardware RNG volatile random X9.31 Appendix A.2.4 RNG memory number is A.2.4 RNG seed key generated by ANSI X9.31 Appendix A.2.4 RNG 2.6.1 Key Generation The module uses ANSI X9.31 Appendix A.2.4 RNG to generate cryptographic keys. This RNG is Approved as indicated by Annex C to FIPS PUB 140-2. The seeds of the ANSI X9.31 Appendix A.2.4 RNG are provided by a non-Approved hardware RNG, which collects system contexts from the card. This non-Approved hardware RNG is implemented in hardware and does not have an external interface. 2.6.2 Key Input/Output Host RSA public keys can be imported in plaintext. The module’s RSA public key can be exported to the host in plaintext. CEKs are input into or output from the card ciphertext encrypted with session keys. ACR credentials are input into the card in ciphertext encrypted with session keys. Other keys and CSPs are not input into or output from the module. 2.6.3 Key Storage There exists a special section of the flash memory called the Security Storage (SST). The SST is used for the storage of security-critical information such as user and device key-pairs, permanent symmetric keys, configuration 2 For the one-way asymmetric authentication. 3 For the one-way symmetric authentication, two-way symmetric authentication, and the two-way asymmetric authentication schemes. Page 19 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 information, PINs, root certificates, and a key table used to support the secure application data storage areas on the flash memory. 2.6.4 Key Zeroization A session key between the host and the module is stored only in the volatile memory and is zeroized when the session is over or when it is closed. The symmetric, asymmetric, or password credentials of an ACR are zeroized when their associated ACR is deleted. All key information of an ACR is AES-encrypted with a CEK. CEKs are stored in the SST. A CEK is zeroized when the domain it encrypts is deleted. The “Delete ACR” command, when called by the Crypto-Officer to delete the last ACR in the root AGP, will immediately zeroize all FIPS-Approved tree CEKs and ACR CSPs (keys, certificates, PINs) and associated encrypted content. Authorized Crypto-Officers can also use the “Zeroize System ACR” command, which will zeroize the System ACR and all other ACRs in the system. The Secret CryptoKey is not zeroized; however, physically destroying the card will effectively render the Secret CryptoKey unusable. See Section 3.6 of this document for details about key zeroization. 2.7 Self-Tests The card performs a firmware integrity self-test at power-up. The integrity self-test uses the 128-bit AES CBC Message Authentication Code (MAC) algorithm. The signing operation was done during manufacturing. The card performs the following cryptographic algorithm self-tests during power-up: • Known Answer Test (KAT) on Triple-DES. • KAT on AES. • KAT on SHA-1 (this test is performed as part of the RSA signature generation/verification KAT). • KAT on RSA encryption/decryption. • KAT on RSA signature generation/verification. • KAT on ANSI X9.31 Appendix A.2.4 RNG. Conditional self-tests are performed when an applicable security function or operation is invoked. The module implements three conditional self-tests. • Pair-wise consistency test for RSA keys. • Continuous RNG test for the non-Approved RNG that seeds the ANSI X9.31 Appendix A.2.4 RNG. • Continuous RNG test for the ANSI X9.31 Appendix A.2.4 RNG. If the power-up integrity self-test fails, neither SD/SPI commands nor TrustedFlash commands are accepted by the card. If either a power-up cryptographic algorithm KAT or conditional self-test fails, no TrustedFlash are accepted by the card, with the following exceptions: 1. “Get Login Status” command 2. “Command Status” command 3. “Vendor Query” command See Section 3.5 of this document for more information about how to identify FIPS self-test errors. Page 20 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 3 Secure Operation The TrustedFlash v1.0 – microSD cards meet Level 3 requirements of FIPS 140-2. The sections below describe how to install and configure cards such that they operate in the Approved mode of operation. 3.1 Initial Setup Setup described in Sections 3.1.2, 3.1.3, and 3.1.4 are required by either the Crypto-Officer or the User each time the card is used, regardless of Crypto-Officer configuration. 3.1.1 Secure Delivery The operator is not authenticated upon accessing the module for the first time. Secure delivery procedures are relied on to control access to the module before it is accessed by an operator for the first time. Trusted couriers are relied on to maintain the security of the module when distributing it to a Crypto-Officer’s site. 3.1.2 Installing the Card Reader and Drivers The module is accessed by what is called a “Host Controller” in SD terminology. Host Controller refers to either a computer or device that is interoperable with [4]. Host Controllers access the module using Host Drivers (OS- specific drivers for Host Controllers) and Card Drivers (OS drivers for the module). The module is compatible with microSD readers that are interoperable with [3]. 3.1.3 Configuring the Card Reader and Drivers All card models are accessed using compatible drivers and calling applications. Configuration of drivers and calling applications should be according instructions provided with compatible drivers and calling applications. Drivers and calling applications must be configured to support the following card requirements: • Voltage: 2.6 – 2.7 V or 1.65 – 1.95 V (requires a special Field-Programmable Gate Array (FPGA) for the low range) • Timeout: Initialization: 0 – 0xFFFF milliseconds. Write: 0 – 300,000 milliseconds. 0 means infinite. 3.1.4 Installing the Card in a Card Reader All card models must be physically installed into a compatible card reader in order to access card services. Cards may be first installed into compatible adapters to support a wider range of card reader types. 3.2 Module Initialization and Configuration All card models require initial setup by the Crypto-Officer. Each time cards are accessed after they have been installed into a reader, either a SD or SPI session must first be established before sending TrustedFlash commands to the card, regardless of whether Crypto-Officers or Users are accessing the cards as depicted in Figure 4 – Crypto- Officer and User Operation. See Section 3 of [5] for details. TrustedFlash SD Ciphertext and plaintext files TrustedFlash sent using SD Figure 4 – Crypto-Officer and User Operation Page 21 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 At the first time the card is used, the Crypto-Officer should send TrustedFlash commands to the card to create the system ACR and to configure access to the public partition. The first ACR created is the system ACR. The system ACR can be created by executing the “Create ACR” command. Several parameters, including Tree name, AGP name, ACR name, and login algorithm need to be configured for the “Create ACR” command. The system ACR is not removable or reconfigurable. 3.3 Creating Trees that are Configured to Operate in an Approved Mode Trees are configured as part of their creation using TrustedFlash commands. Trees (root AGPs) can only be created by Crypto-Officers during the card’s initial secure installation and configuration. See also Section 2.3 for a description of permission mechanisms. 3.3.1 Sending TrustedFlash Commands to the Card to Create One or More Root AGPs Section 3 of [5] gives detailed procedures of communicating with the module via standard SD interface and commands. The Crypto-Officer is able to create trees of either the Approved mode or the non-Approved mode. The following step-by-step instructions provide details of creating a tree in an Approved mode. See section 2.3.1 of this document for a list of the authentication configurations that are supported in the Approved mode of operation. 1. Creating the first root ACRs of the targeted tree by executing the “Create ACR” command. In the “Create ACR” command, the Crypto-Officer should set the AUTH_ALGORITHM argument to one of the values that represent FIPS-Approved login algorithms, which are marked with “Y” in the leftmost column of Table 7. Table 7 – ACR Login Algorithms FIPS Symbol Value Description N NONE 0 No authentication is required. The session is opened as soon as the “System Login” command is issued for this ACR. N PASSWORD 0x1 Password based authentication Y AES_HOST_AUTH 0x2 One-way symmetric authentication using AES. Card is authenticating the user. Y AES_HOST_AUTH_SEC 0x82 One-way symmetric authentication using AES. Card is authenticating the user. Secure channel is established and used for this ACR. Y AES_HOST_AUTH_SEC_PIN 0xC2 One-way symmetric authentication using AES. Card authenticates the user. Secure channel is established and used for this ACR. Authentication is completed after an additional PIN is provided. Y AES_MUTUAL_AUTH 0x22 Two-way symmetric authentication using AES. Card and host authenticate each other. Y AES_MUTUAL_AUTH_SEC 0xA2 Two-way symmetric authentication using AES. Card and host authenticate each other. Secure channel is established and used for this ACR. Y AES_MUTUAL_AUTH_SEC_PIN 0xE2 A two-factor authentication using AES. Card and host authenticate each other. Secure channel is established and used for this ACR. Authentication is complete after an additional PIN is provided. N DES_HOST_AUTH 0x3 One-way symmetric authentication using DES. Card is authenticating the user. N DES_HOST_AUTH_SEC 0x83 One-way symmetric authentication using DES. Card is authenticating the user. Secure channel is established and used for this ACR. Page 22 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 FIPS Symbol Value Description N DES_HOST_AUTH_SEC_PIN 0xC3 One-way symmetric authentication using DES. Card authenticates the user. Secure channel is established and used for this ACR. Authentication is completed after an additional PIN is provided. N DES_MUTUAL_AUTH 0x23 Two-way symmetric authentication using DES. Card and host authenticate each other. N DES_MUTUAL_AUTH_SEC 0xA3 Two-way symmetric authentication using DES. Card and host authenticate each other. Secure channel is established and used for this ACR. N DES_MUTUAL_AUTH_SEC_PIN 0xE3 A two-factor authentication using DES. Card and host authenticate each other. Secure channel is established and used for this ACR. Authentication is complete after an additional PIN is provided. Y Triple-DES_K2_HOST_ 0x4 One-way symmetric authentication using 2-key Triple-DES. Card is AUTH authenticating the user. Y Triple-DES_K2_HOST_ 0x84 One-way symmetric authentication using 2-key Triple-DES. Card is AUTH_SEC authenticating the user. Secure channel is established and used for this ACR. Y Triple-DES_K2_HOST_ 0xC4 One-way symmetric authentication using 2-key Triple-DES. Card AUTH_SEC_PIN authenticates the user. Secure channel is established and used for this ACR. Authentication is completed after an additional PIN is provided. Y Triple-DES_K2_ 0x24 Two-way symmetric authentication using 2-key Triple-DES. Card and MUTUAL_AUTH host authenticate each other. Y Triple-DES_K2_ 0xA4 Two-way symmetric authentication using 2-key Triple-DES. Card and MUTUAL_AUTH_SEC host authenticate each other. Secure channel is established and used for this ACR. Y Triple-DES_K2_ 0xE4 A two-factor authentication using 2-key Triple-DES. Card and host MUTUAL_AUTH_SEC_PIN authenticate each other. Secure channel is established and used for this ACR. Authentication is complete after an additional PIN is provided. Y Triple-DES_K3_HOST_ 0x5 One-way symmetric authentication using 3-key Triple-DES. Card is AUTH authenticating the user. Y Triple-DES_K3_HOST_ 0x85 One-way symmetric authentication using 3-key Triple-DES. Card is AUTH_SEC authenticating the user. Secure channel is established and used for this ACR. Y Triple-DES_K3_HOST_ 0xC5 One-way symmetric authentication using 3-key Triple-DES. Card AUTH_SEC_PIN authenticates the user. Secure channel is established and used for this ACR. Authentication is completed after an additional PIN is provided. Y Triple-DES_K3_ 0x25 Two-way symmetric authentication using 3-key Triple-DES. Card and MUTUAL_AUTH host authenticate each other. Y Triple-DES_K3_ 0xA5 Two-way symmetric authentication using 3-key Triple-DES. Card and MUTUAL_AUTH_SEC host authenticate each other. Secure channel is established and used for this ACR. Y Triple-DES_K3_ 0xE5 A two-factor authentication using 3-key Triple-DES. Card and host MUTUAL_AUTH_SEC_PIN authenticate each other. Secure channel is established and used for this ACR. Authentication is complete after an additional PIN is provided. N RSA_PRIM_MUTUAL_AUTH 0x06 Two-way asymmetric RSA primitives key exchange method. Page 23 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 FIPS Symbol Value Description Y RSA_V15_HOST_AUTH 0x66 PKCS#1_V1.5 One-way asymmetric authentication, TrustedFlash authenticates the user, using public key. Asymmetric authentication always uses a secure channel. Y RSA_V21_HOST_AUTH 0xA6 PKCS#1_V2.1 One-way asymmetric authentication, TrustedFlash authenticates the user, using public key. Asymmetric authentication always uses a secure channel. Y RSA_V15_HOST_AUTH_PIN 0x76 PKCS#1_V1.5 One-way asymmetric authentication, TrustedFlash authenticates the user, using public key. Asymmetric authentication always uses a secure channel with PIN option. Y RSA_V21_HOST_AUTH_PIN 0xB6 PKCS#1_V2.1 One-way asymmetric authentication, TrustedFlash authenticates the user, using public key. Asymmetric authentication always uses a secure channel with PIN option. Y RSA_V15_MUTUAL_AUTH 0x46 PKCS#1_V1.5 Two-way asymmetric RSA authentication method. Y RSA_V21_MUTUAL_AUTH 0x86 PKCS#1_V2.1 Two-way asymmetric RSA authentication method. Y RSA_V15_MUTUAL_AUTH_PIN 0x56 PKCS#1_V1.5 Two-way asymmetric RSA authentication method with PIN option. Y RSA_V21_MUTUAL_AUTH_PIN 0x96 PKCS#1_V2.1 Two-way asymmetric RSA authentication method with PIN option. 2. Restricting the algorithms that are allowed in the targeted tree by executing the “Restrict Tree Authentication Capabilities” command. The command specifies a tree and the authentication limitations applied to the tree. This command accepts a four-byte Tree Authentication Capability bitmask as an argument (see Table 8 for a breakdown of the bitmask). It is possible to restrict a combination of several algorithms by calculating a binary OR among the values in the second column. Table 8 – Tree Authentication Capability Bitmask FIPS Symbol Value Description N Enable all 0x00 None of the algorithms are disabled in the AGP N None 0x01 An ACR with no credentials is disabled for the AGP N Password 0x02 Password authentication is disabled for the AGP N DES 64 0x04 DES with key size of 64 bits is disabled for the AGP Y Triple-DES128 0x08 Triple-DES with key size of 128 bits is disabled for the AGP Y Triple-DES192 0x10 Triple-DES with key size of 192 bits is disabled for the AGP Y AES128 0x20 AES with key size of 128 bits is disabled for the AGP N RSA512 0x40 RSA with key size of up to 512 bits is disabled for the AGP Y RSA1024 0x80 RSA with key size of up to 1024 bits is disabled for the AGP Y RSA2048 0x100 RSA with key size of up to 2048 bits is disabled for the AGP N All other values Reserved Reserved modes for future use, must be disabled Only Approved algorithms (Triple-DES128, Triple-DES192, AES128, RSA1024, and RSA2048) shall be used. For details of how to set the bitmask argument so that the ACR uses Approved algorithms, please refer to Section 4 of [5]. An ACR that is created in a FIPS-Approved tree employs only Approved cryptographic algorithms and authentication mechanisms. See Section 2.3.1 of this document for a list of the authentication configurations that are supported in the Approved mode of operation. Page 24 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 3. Executing the “Create ACR Done” command for the first root ACR. A tree working in the Approved mode of operation has been created after the above three steps are successfully performed. 3.3.2 Sending TrustedFlash Commands to the Card to Prevent the Creation of New Trees To prevent the creation of any additional trees, the card must be configured to operate in “Disabled mode” (also called “Locked mode”) using the following TrustedFlash commands: 1. Configure root ACR creation for disabled mode using the “Set Root AGP Creation Mode” command, setting the mode to “LOCKED” (no root AGP may be created). 2. Disable the method configuration command using the “Disable Root AGP Change Mode” command. 3.3.3 Sending TrustedFlash Commands to the Card to Create One or More Non-Root ACRs To create an ACR on a tree working in the Approved mode of operation, in the “Create ACR” command, the Crypto-Officer shall set the AUTH_ALGORITHM argument to one of the values that represent Approved algorithms, which are marked with “Y” in the leftmost column of Table 7. Notice that setting the AUTH_ALGORITHM argument to values with marking “N” will result in error (TF_ERR_TREE_AUTH_RESTRICTION_CONFLICT) because the corresponding algorithms have been disabled by the “Restrict Tree Authentication Capabilities” command. Users are expected to protect their PINs, authentication credential, and exported CEKs. 3.4 FIPS Mode Status Indicator Operators can determine whether or not a card is operating in the Approved mode by accessing the Tree Authentication Capabilities bitmask. This is a four-byte bitmask in which each bit identifies the specific algorithms used by the module. When operating in FIPS mode, the non-Approved algorithms will be disabled. Thus, when operating in FIPS mode, the Tree Authentication Capability bitmask will read: “1000 0000 0000 0000 0000 0000 xx1x xx11” The bit positions marked with an “x” represent each of the Approved algorithms supported. When least one of those designated bit positions is set to “0”, this indicates that the module is running in its Approved mode and that the corresponding algorithm is enabled. In all other cases, the module is not considered to be in an Approved state Any operator can read the bitmask by calling the “Command Status” command. 3.5 Identifying the Error State 3.5.1 Identifying Power-up Integrity Self-Test Errors Power-up integrity self-test errors are identified by attempting to send SD commands. When the power-up integrity self-test fails, neither SD/SPI commands nor TrustedFlash commands are accepted by the card. For example, a typical card initialization sequence consists of issuing SD commands CMD0, CMD55, ACMD41, CMD2, and then CMD3. When the power-up integrity self-test fails, none of these commands will receive a response from the card. For example, SD command responses generally include response tokens that include bits used as error indicators. When the power-up integrity self-test fails, not even response tokens are sent by the card. 3.5.2 Identifying Power-up Cryptographic Algorithm KAT Errors Power-up cryptographic algorithm KAT errors are identified by TrustedFlash commands. The “Command Status” command must be used to figure out whether or not the card has entered its error state as the result of a power-up Page 25 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 cryptographic algorithm KAT error. When a power-up cryptographic algorithm KAT fails, error code 4121 will be returned. 3.5.3 Identifying Conditional Self-Test Errors Conditional self-test errors are identified by TrustedFlash commands. The “Command Status” and “Get Login Status” commands must be used to figure out whether or not the card has entered its error state as the result of a conditional cryptographic algorithm self-test error. When a conditional self-test error occurs during login, specifically when a continuous random number generator test fails during key establishment, error code 4107 will be returned by the “Get Login Status” command. When a conditional self-test error occurs during card operation after login, error code 4121 will be returned by the “Command Status” command. 3.5.4 Recovering from FIPS Self-Test Errors When a FIPS self-test error has occurred, the only way to attempt to recover is to reboot the module. This can be done by either cycling the power or sending a SD/SPI command (CMD0) to the card. 3.6 Module Zeroization Zeroizing the card requires two steps. First use TrustedFlash commands, and then use physical force to destroy the module. 3.6.1 Zeroizing a Tree All CSPs, including CEKs and authentication credentials of ACRs, involved in a tree can be zeroized by deleting the root AGP of the tree. Deleting the root AGP is done by deleting all ACRs (using the “Delete ACR” command) within the root AGP. Deleting an ACR zeroizes all CEKs and authentication credentials associate with the ACR and its child ACRs. Deleting a domain (using the “Delete Domain” command) zeroizes the CEK of the domain. 3.7 Command Reference and Communication Requirements 3.7.1 SD Command Compatibility TrustedFlash commands are sent using lower-level SD/SPI commands. The module is interoperable with host controllers that are compliant with [1] and [2]. 3.7.2 SD Command Usage Instructions about how to send TrustedFlash commands to the module using SD commands can be found in Section 3 “Communicating with the SSA System” in [5]. 3.7.3 TrustedFlash Command Reference Instructions about TrustedFlash command structures can be found in Section 4 “The TrustedFlash Commands – Command Structure” in [5]. Instructions about how to use TrustedFlash commands can be found in Section 4 “The TrustedFlash Commands – Command Sequences” in [5]. Complete TrustedFlash command descriptions can be found in Section 4 “The TrustedFlash Commands – Detailed Command Description” in [5]. TrustedFlash command error code information can be found in Section 4 “The TrustedFlash Commands – Detailed Command Description – Command Status” and in Section 4 “The TrustedFlash Commands – Detailed Command Description – Get Login Status” in [5]. Page 26 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 4 References [1] SD Association, “Physical Layer Specification”, version 1.00 [2] SD Association, “File System Specification”, version 1.01 [3] SD Association, “microSD Addendum”, version 1.10 [4] SD Association, “Host Controller Specification”, version 1.0 [5] SanDisk Corporation, “TrustedFlash – SD Product Reference Spec”, revision 1.0 Page 27 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 5 Acronyms Table 9 – Acronyms Acronym Definition ACAM ACR Management ACR Access Control Record AES Advanced Encryption Standard AGP ACR Group ANSI American National Standards Institute CBC Cipher-Block Chaining CEK Content Encryption Key CMVP Cryptographic Module Validation Program CSP Critical Security Parameter DER Distinguished Encoding Rules DES Data Encryption Standard DRM Digital Rights Management ECB Electronic Codebook EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard FPGA Field-Programmable Gate Array ID Identification KAT Known Answer Test LBA Logical Block Address MAC Message Authentication Code N/A Not Applicable NIST National Institute of Standards and Technology OEM Original Equipment Manufacturer OS Operating System PDA Personal Digital Assistant PIN Personal Identification Number PKCS Public Key Cryptography Standards RNG Random Number Generator RSA Rivest, Shamir, and Adleman SD Secure Digital SHA Secure Hash Algorithm SPI Serial Peripheral Interface Page 28 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, version 2.1 September 1, 2009 Acronym Definition SSA Security Storage Application SST Security Storage Page 29 of 29 TrustedFlash v1.0 – microSD © 2009 SanDisk Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice.