FIPS 140-2 Level 2 Security Policy for FlagStone Core (Versions V2.0.1.1, V2.0.1.2, V2.0.1.3, V2.0.2.1, V2.0.2.2, V2.0.2.3, V2.0.3.3, V2.0.3.4, V2.0.4.5, V2.0.5.3, V2.0.5.4, V2.0.5.5) Issue: 2.0 This document may be freely reproduced and distributed only in its entirety without revision. © ViaSat UK Limited www.viasat.uk.com Contents 1 Introduction 7 1.1 Scope 7 1.2 Security Level 8 1.3 Related Documents 8 2 Cryptographic Module Specification 9 2.1 Overview 9 2.2 Modes of Operation 12 3 Module Ports and Interfaces 13 4 Roles, Services, and Authentication 15 4.1 Roles 15 4.2 Services 21 4.3 Authentication 29 5 Finite State Model 33 6 Physical Security 34 7 Operational Environment 35 8 Cryptographic Key Management 36 8.1 Critical Security Parameters 36 8.2 Access Privileges to FIPS 140-2 Critical Security Parameters 38 8.3 Random Number Generator 44 8.4 Key Derivation 44 8.5 Key Generation 44 8.6 Key Entry and Output 44 8.7 Initialization Vector Generation 44 8.8 Key Storage 45 9 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC) 46 10 Self-Tests 47 10.1 Power On Self-Tests 48 10.2 Conditional Self-Tests 48 11 Design Assurance 49 11.1 Configuration Management 49 11.2 Delivery and Operation 49 11.3 Development 49 11.4 Guidance Documents 49 12 Mitigation of Other Attacks Policy 50 Figures Figure 1 - Eclypt Internal (Parallel ATA) 7 Figure 2 - Eclypt Internal (Serial ATA) 7 Figure 3 - Eclypt Freedom 7 Figure 4 - Eclypt Nano 7 Figure 5 - FlagStone Core V2.0.1.1, V2.0.2.1 9 Figure 6 - FlagStone Core V2.0.1.2, V2.0.2.2 9 Figure 7 - FlagStone Core V2.0.1.3, V2.0.2.3, V2.0.3.3, V2.0.5.3 9 Figure 8 - FlagStone Core V2.0.3.4, V2.0.5.4 9 Figure 9 - FlagStone Core V2.0.4.5, V2.0.5.5 9 Figure 10 - FlagStone Core Simplified Block Diagram 10 Figure 11 - Session Model (FIPS 140-2 Mode of Operation) 18 Figure 12 - Authentication Mechanism 30 FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 2 of 50 Tables Table 1 Security Levels 8 Table 2 Physical Ports 13 Table 3 Logical Interfaces 14 Table 4 Service Handler Roles 16 Table 5 Datapath Roles 17 Table 6 Accounts 20 Table 7 Service Handler Services 21 Table 8 Datapath Services 28 Table 9 Service Handler and Datapath Roles Authenticated by Operator Login 30 Table 10 Probability of False Accept 32 Table 11 Critical Security Parameters 36 Table 12 CSP Access Types 38 Table 13 Role Privileges Rights to CSPs 39 Table 14 Service Access Privileges to CSPs 40 Table 15 Power On Self Test Status 47 Table 16 Power On Self Tests 48 Table 17 Conditional Self Tests 48 Glossary A-A Auto Authentication Acct Account AES Advanced Encryption Standard ANSI American National Standards Institute Auth Authentication Auto Automatic ATA AT Attachment C-I Crypto-Initiator C-M Crypto-Migrate CO Crypto Officer CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CDI Connected Drive Interface CIRNG Crypto-Initiator’s Random Number Generator CISAV Crypto-Initiator’s Secondary Authentication Value CIWK Crypto-Initiator’s Wrapping Key COTS Commercial Off The Shelf CSEC Communications Security Establishment Canada CSP Critical Security Parameter DEK Data Encryption Key DES Data Encryption Standard DP Datapath ECB Electronic Code Book EECA Externally Executed Control Application EHI External Host Interface EMC Electro Magnetic Compatibility EMI Electro Magnetic Interference FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 3 of 50 FCC Federal Communications Commission FIPS Federal Information Processing Standards FPGA Field Programmable Gate Array HDD Hard Disk Drive ISO International Standards Organization IV Initialization Vector KAT Known Answer Test L-U User – ordinary user with limited management capability MGR Manager N/A Not Applicable N-R No Role NIST National Institute of Standards and Technology NV Non Volatile OAVK Operator Authentication Validation Key OHP Operator Host Authentication Parameter OKAP Operator Key Port Authentication Parameter OOB Out Of Band OP Operator/Operational OPNCISAV Operational Non Crypto-Initiator’s Secondary Authentication Value OPRNG Operational Random Number Generator OPWK Operational Wrapping Key PAE Pre-Authentication Environment PAEK PAE Key PAE-U PAE Update PATA Parallel ATA PC Personal Computer POST Power on Self-Test(s) PUB Publication RNG Random Number Generator SDA Secure Drive Access SH Service Handler SHS Secure Hash Standard SI System Integrator SSD Solid State Device XOR eXclusive OR (i.e. bit-wise modulo 2 addition) FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 4 of 50 Revision History Issue Description Date Author 1.0 Initial Release to Test House 04/12/08 Tim D. Stone 1.1 Minor updates requested by Test House 19/12/08 Tim D. Stone 1.2 Updated following NIST/CSEC review 22/04/09 Tim D. Stone New Stonewood Group branding adopted 1.3 Added Versions V2.0.2.1, V2.0.2.2 & V2.0.2.3 08/05/09 Tim D. Stone 1.4 Added Versions V2.0.3.3 & V2.0.3.4 12/11/09 Tim D. Stone 1.5 Added Versions V2.0.4.5, V2.0.5.3, V2.0.5.4 & V2.0.5.5 04/02/11 Tim D. Stone 1.6 Updated ANSI X9.31 RNG status 28/03/11 Tim D. Stone 1.7 Removed Versions V2.0.4.5 & V2.0.5.5 14/06/11 Tim D. Stone 1.8 Added Versions V2.0.4.5 & V2.0.5.5 15/06/11 Tim D. Stone 1.9 Updated following NIST/CSEC review 20/09/11 Tim D. Stone ViaSat branding adopted 2.0 Updated following NIST/CSEC review 18/10/11 Tim D. Stone FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 5 of 50 References [1] FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899-8900 [2] FIPS PUB 197, Specification for the Advanced Encryption Standard (AES), Information Technology Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899-8900 [3] NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4. Using the 3-Key Triple DES and AES Algorithms, January 31, 2005, Sharon S. Keller [4] AES Key Wrap Specification (Draft), 16 November 2001, National Institute of Standards and Technology [5] AT Attachment with Packet Interface – 7, Volume 1 – Register Delivered Command Set, Logical Register Set, ANSI NCITS 397-2005 (Vol. 1), American National Standards Institute, Inc., 25 West 43rd Street, New York, NY 10036, USA [6] FlagStone Core V2.0.1.x/V2.0.2.x/V2.0.3.x/V2.0.4.x/V2.0.5.x Architecture Specification, ViaSat UK Document Number 3650-RS033 [7] FlagStone (FIPS 140-2) Hardware Design Description (for FlagStone Core V2.0.1.x/V2.0.2.x/V2.0.3.x/V2.0.4.x/V2.0.5.x), ViaSat UK Document Number 3650- DD110 [8] Eclypt (FIPS 140-2) User Guide(s) [9] Eclypt Freedom (FIPS 140-2) User Guide(s) [10] Eclypt Nano (FIPS 140-2) User Guide(s) [11] QP200 Product Development, ViaSat UK Quality Process [12] QP500 Customer Interface, ViaSat UK Quality Process FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 6 of 50 1 Introduction 1.1 Scope This security policy applies to the FIPS 140-2 validated cryptographic module deployed within Eclypt Drives referred to as the FlagStone Core. This document has been written based on the requirements specified in Ref. [1]. Whilst the FlagStone Core is provided as twelve physical embodiments, V2.0.1.1, V2.0.1.2, V2.0.1.3, V2.0.2.1, V2.0.2.2, V2.0.2.3, V2.0.3.3, V2.0.3.4, V2.0.4.5, V2.0.5.3, V2.0.5.4 & V2.0.5.5, the security functionality is identical for all twelve. The following table indicates which embodiment is used in each Eclypt Drive. FlagStone Core Drive V2.0.1.1, V2.0.2.1 Eclypt Internal (Parallel ATA Interface) V2.0.1.2, V2.0.2.2, V2.0.3.4, V2.0.5.4 Eclypt Internal (Serial ATA Interface) V2.0.1.3, V2.0.2.3, V2.0.3.3, V2.0.5.3 Eclypt Freedom V2.0.4.5, V2.0.5.5 Eclypt Nano The following are images of Eclypt Drives containing the FIPS 140-2 validated FlagStone Core. Further information on the Eclypt Range can be found on www.eclypt.com Figure 1 - Eclypt Internal (Parallel ATA) Figure 2 - Eclypt Internal (Serial ATA) Figure 3 - Eclypt Freedom Figure 4 - Eclypt Nano FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 7 of 50 1.2 Security Level Security Requirements Section Level Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services, and Authentication 3 Finite State Model 2 Physical Security 3 Operational Environment N/A Cryptographic Key Management 2 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A Table 1 Security Levels 1.3 Related Documents Finite State Model, Ref. [6] • Cryptographic Boundary, Ref. [7] • FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 8 of 50 2 Cryptographic Module Specification 2.1 Overview The FlagStone Core is a multi-chip embedded cryptographic module used within the Eclypt and the Eclypt Freedom Drives. Figure 5 - FlagStone Core V2.0.1.1, V2.0.2.1 Figure 6 - FlagStone Core V2.0.1.2, V2.0.2.2 Figure 7 - FlagStone Core V2.0.1.3, V2.0.2.3, Figure 8 - FlagStone Core V2.0.3.4, V2.0.5.4 V2.0.3.3, V2.0.5.3 Figure 9 - FlagStone Core V2.0.4.5, V2.0.5.5 Figure 10 - FlagStone Core Simplified Block Diagram provides a pictorial representation of the FlagStone Core’s interfaces and functional blocks. The FlagStone Core consists of two service provision blocks, the Datapath and the Service Handler. Overall control is provided by the Control block, and non-volatile parameter storage (including CSPs) is provided by the NV Store. Since the FlagStone Core is an embedded cryptographic FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 9 of 50 module, the cryptographic boundary highlighted is not representative of the entire Eclypt device. FlagStone Core Power ATA Bus On EHI Reset CDI Reset ATA Device Control ATA Device ATA Host Control/Status Status PATA Bus Datapath (Plain text) PATA Bus ATA Host ATA Device (Cipher) Status Control Data Data ATA Links/ Purge EECA Bus Power Status Control Only made available Service outside the FIPS 140-2 Key Port Bus Handler Cryptographic NV FIPS 140-2 Key Port Status Boundary for V2.0.1.3, Store Cryptographic V2.0.2.3, V2.0.3.3 & Boundary V2.0.5.3 Figure 10 - FlagStone Core Simplified Block Diagram The PATA Bus (Cipher) provides communication to/from a connected drive, whereas the PATA Bus (Plain Text) provides communication to/from a Host System, e.g. Desktop PC, Laptop. 2.1.1 Datapath The Datapath of the FlagStone Core, and subsequently the Eclypt Drives utilizing the FlagStone Core, provide data encryption/decryption services to protect the data stored on a connected drive. The connected drive can be any COTS storage device that supports the ATA command protocol, including HDDs (Hard Disk Drives) and SSDs (Solid State Drives). All accessible sectors on a drive connected to a FlagStone Core are encrypted. These services and security functions can only be accessed through the use of ATA disk reads and ATA disk writes. In the appropriate Datapath roles, data can be read and written to the connected drive just like a normal drive. Data written to the connected drive is automatically encrypted prior to writing the data to the connected drive; data read from the connected drive is automatically decrypted prior to returning the data to the host. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 10 of 50 To provide non-volatile storage for an external application (Section 2.1.3), the Datapath splits the connected drive into two regions. The PAE (Pre-Authentication Environment) region provides storage for the external application, whereas the non- PAE region provides the normal drive data storage region, typically containing the operating system, applications and data. The Datapath ensures that only one of these regions is made available. Following successful POST, the PAE region is made available. Once an operator has successfully authenticated and booted, the non-PAE region is made available. 2.1.2 Service Handler The Service Handler of the FlagStone Core provides authentication, purge, RNG and management services, including key management, account management, policy management, system control and datapath control. The Service Handler services can be accessed from the PATA Bus (Plain Text), i.e. the Host, through both the use of ATA Vendor specific commands and the use of ATA disk reads and ATA disk writes targeted to specific sector addresses. 2.1.3 External Applications With the exception of non-PAE region connected drive access, it is expected that most operators will use an external application to communicate with the FlagStone Core’s PATA (Plain Text) interface in order to perform Service Handler and Datapath services. To avoid the need for users to write their own applications, FlagStone applications are provided with the Eclypt Drives. These FlagStone applications are provided on Optical Media, embedded in hardware within the Eclypt Drives, and/or stored encrypted in the PAE region of the connected drive. Since these applications are not part of the FlagStone Core, they are not covered by this document. Details of these applications can be found in the user guide for the relevant Eclypt Drive. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 11 of 50 2.2 Modes of Operation The FlagStone Core can operate in both FIPS 140-2 approved and non-approved modes of operation. The FlagStone Core implements the following FIPS-approved algorithms: 256-bit AES CBC Mode, Cert #922 • 256-bit AES ECB Mode, Cert #923 • ANSI X9.31 AES 256 bit RNG, Cert #531 • 256-bit AES Key Wrap • The FlagStone Core does not implement any non FIPS approved cryptographic algorithms. The ANSI X9.31 RNG is deprecated (i.e. allowed for use, but the user must accept some risk) from 2011 until 2015, and disallowed after 2015. In accordance with best practice, directly following any crypto initialization, ViaSat recommends that a Crypto Officer ensures that the FlagStone Core is configured in an approved FIPS 140-2 mode of operation. 2.2.1 Approved FIPS 140-2 Mode of Operation To operate in an approved FIPS 140-2 mode of operation, a Crypto Officer must ensure that the FlagStone Core is configured as follows. IV Diversification must be switched off • There must be no auto authentication account • The FlagStone Core is supplied from ViaSat with IV Diversification switched off. The IV Diversification process, when switched on, ensures that the IV for every sector on the Drive is unique. The Get Status – Core service returns the current setting of IV Diversification and indicates whether or not the auto authentication account is present. Should the auto authentication account be present this can be removed by purging the FlagStone Core. Further information relating to the use of ViaSat supplied external applications to control the FlagStone Core can be found in the Eclypt User Guides, Refs. [8], [9] & [10]. In accordance with best practice, directly following any crypto initialization, ViaSat recommends that a Crypto Officer ensures that the FlagStone Core is configured in an approved FIPS 140-2 mode of operation. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 12 of 50 3 Module Ports and Interfaces Table 2 provides a brief description of the physical interfaces to the FlagStone Core. The interfaces specified can be seen in Figure 10 - FlagStone Core Simplified Block Diagram. Further details on these interfaces can be found in Ref. [7]. Physical Interface Description PATA Bus (Plain text) The primary interface for the reception of ATA commands, plaintext data and service requests from the external host ATA controller, and the primary interface for the transmission of data, status information and ATA transfer requests to the external host ATA controller. PATA Bus (Cipher) The primary interface for the transmission of ATA commands and enciphered data to the connected drive and the primary interface for the reception of ATA transfer requests and enciphered data from the connected drive. Power Interface Provides power to the FlagStone Core. Power Status Provides a control signal from the local power supply to indicate the imminent loss of power. ATA Bus On Provides a status signal to indicate when the FlagStone Core PATA Bus (Plain text) is available for use. EHI Reset Provides a status signal to indicate when the FlagStone Core is performing a reset of its PATA Bus (Plain text) interface. CDI Reset Provides a status signal to indicate when the FlagStone Core is performing a reset of its PATA Bus (Cipher) interface. ATA Links/Purge Provided to allow configuration of the ATA interface within the FlagStone Core including master/slave and cable select options present on Parallel ATA Drives. This interface also provides an external purge input to the FlagStone Core. Key Port Bus To support dual port, two factor authentication, this read only interface is provided to allow a token to be read directly by the FlagStone Core. Since dual port, two factor authentication is only available on V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3, this interface is only made available outside the FIPS 140-2 cryptographic boundary for V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3. Key Port Status To support dual port, two factor authentication, this interface provides two status signals to indicate status of the Key Port. Since dual port, two factor authentication is only available on V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3, this interface is only made available outside the FIPS 140-2 cryptographic boundary for V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3. EECA Bus Provides the interface to the read only EECA Store. The EECA Store contains the Eclypt Drive Identify Device information and External Applications that can be executed on the host. Table 2 Physical Ports FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 13 of 50 Table 3 details the mapping of the physical interfaces summarized above to the FIPS 140-2 Logical Interfaces. FIPS 140-2 Logical Physical Interface Interfaces Data Input PATA Bus (Plain text), PATA Bus (Cipher), Key Port Bus (for V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3 only) Data Output PATA Bus (Plain text), PATA Bus (Cipher) Control Input PATA Bus (Plain text), PATA Bus (Cipher), Power Status, ATA Links/Purge, Key Port Bus (for V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3 only), EECA Bus Status Output PATA Bus (Plain text), PATA Bus (Cipher), ATA Bus On, EHI Reset, CDI Reset, Key Port Bus (for V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3 only), Key Port Status (for V2.0.1.3, V2.0.2.3 & V2.0.3.3 & V2.0.5.3 only), EECA Bus Power Power Interface Table 3 Logical Interfaces The PATA Bus (Plain text) provides logical separation between its Data Input, Data Output, Control Input and Status Output interfaces through the use of the ATA Protocol and the Flagstone Core’s Finite State Machine. The PATA Bus (Cipher) provides logical separation between its Data Input, Data Output, Control Input and Status Output interfaces through the use of the ATA Protocol. The Key Port Bus provides logical separation between its Data Input, Control Input and Status Output interfaces through the use of its serial data protocol. The EECA Bus provides logical separation between its Control Input and Status Output interfaces through the use of its serial data protocol. A description of the ATA command set supported by the FlagStone Core is detailed in Ref. [6]. Details of the ATA protocol can be found in Ref. [5]. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 14 of 50 4 Roles, Services, and Authentication The FlagStone Core uses identity-based authentication. There is an account associated with each individual identity (i.e. operator). To facilitate initialization, every FlagStone Core has a single Crypto-Initiator account. 4.1 Roles The FlagStone Core roles permit authorized access to either Service Handler services or Datapath services, and hence are known as either Service Handler roles or Datapath roles. The FlagStone Core supports concurrent sessions; however, the maximum number of concurrent sessions is two, and then only when one session has assumed a Service Handler role and the other session has assumed a Datapath role; further details can be found in Section 4.1.3. An unauthenticated operator cannot assume a Datapath role directly; they must initially assume an appropriate Service Handler role and then assume a Datapath role. In the event that the FlagStone Core has been unit purged, i.e. all CSPs have been purged, no role (Service Handler or Datapath) can be assumed. When no operator is assuming an authorized Service Handler role, the Service Handler is deemed to be in No Role. Similarily, when no operator is assuming an authorized Datapath role, the Datapath is deemed to be in No Role. Under normal operation, the FlagStone Core’s Datapath is assuming the SDA role, whilst the Service Handler is not assuming any role (i.e. No Role). 4.1.1 Service Handler Roles The FlagStone Core’s Service Handler supports four roles. The Service Handler only supports a single session; therefore only one of the roles may be active at any given point. To assume a Service Handler role the operator must successfully authenticate to an account using identity based authentication. The Crypto Officer, Manager or User roles can be assumed using any operator account whose policy allows the specified role to be assumed, whereas the Crypto-Initiator role can only be assumed by the Crypto-Initiator account. When no operator accounts exist, only the Crypto-Initiator role can be assumed. However, when 1 or more operator accounts exist, the Crypto-Initiator role cannot be assumed. An operator that has assumed the Crypto-Initiator role cannot assume a Datapath role. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 15 of 50 Furthermore, once the Service Handler has assumed a role, it must stop assuming this role before a different Service Handler role can be assumed. Table 4 details the Service Handler roles that can be assumed as a result of a successful authentication. Role Description The Crypto-Initiator role allows the FlagStone Core to be initialized. This role allows the operator to: Crypto-Initiator • Initialize for Operational use (C-I) • Get Random Numbers • Logout The Crypto Officer role allows the operator to: • Change the C-I account authentication parameters • Perform key management • Enable migrate access to non-PAE region of the connected drive • Perform operator account management including Creation/Deletion Crypto Officer • Enable write access to the PAE region of the connected drive (CO) • Configure the FlagStone Core’s Drive Policy • Purge the current Operational CSPs • Purge the entire unit (i.e. Unit Purge) • Boot • Get Random Numbers • Logout The Manager role allows the operator to: • Perform limited management of operator accounts that cannot assume the Crypto Officer role, namely Modify Account Status and Manager Change Authentication Parameters (MGR) • Purge the current Operational CSPs • Boot • Get Random Numbers • Logout The User role allows the operator to: • Boot User • Change their own Authentication Parameters (L-U) • Get Random Numbers • Logout Table 4 Service Handler Roles FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 16 of 50 4.1.2 Datapath Roles The FlagStone Core’s Datapath supports three roles. When operating in a FIPS 140-2 approved mode of operation, Datapath roles can only be assumed by a operator who is a assuming an appropriate Service Handler role; such an operator can assume the Datapath role without the need for further authentication. The Datapath’s Crypto-Migrate and Pre-Authentication Environment Update roles can only be assumed by an operator who is assuming the Service Handler’s Crypto Officer role, whereas the Datapath’s Secure Drive Access role can be assumed from any Service Handler role except the Crypto-Initiator role. Furthermore, once the Datapath has assumed a role, it must stop assuming this role before a different Datapath role can be assumed. Table 5 details the Datapath roles that can be assumed. Role Description The Secure Drive Access role provides the operator with read/write access to the non-PAE Region of the connected drive. The Secure Drive Access role Secure Drive allows the operator to: Access • Encrypt and write data to the connected drive (non PAE region) (SDA) • Read and decrypt data from the connected drive (non PAE region) • Logout Whilst in the Crypto-Migrate role, the Datapath is configured to decrypt with the old DEK and to encrypt with the new DEK. This role provides the operator with read/write access to the non-PAE Region of the connected drive, allowing an external application to read then write from / to every non-PAE Crypto-Migrate region sector of the connected drive, thereby re-encrypting the non-PAE (C-M) region of the connected drive with the new DEK. This role allows the operator to: • Encrypt and write data to the connected drive (non PAE region) • Read and decrypt data from the connected drive (non PAE region) • Logout The Pre-Authentication Environment Update Role provides the operator with Pre- read/write access to the PAE Region of the connected drive. This role allows Authentication the operator to: Environment • Encrypt and write to the connected drive (PAE region) Update • Read and decrypt from the connected drive (PAE region) (PAE-U) • Logout Table 5 Datapath Roles Notes: 1. When the Datapath is not assuming a role, the Datapath may provide read only access to the connected drive’s PAE region. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 17 of 50 4.1.3 Session Model Figure 11 summarizes the session model when operating in an approved FIPS 140-2 mode of operation. At power up or following a restart, both the Service Handler (SH) and the Datapath (DP) will not be assuming a role. When there are no operator accounts, only the Crypto-Initiator can log in using the Log In (C-I) service. Once logged in, the Crypto-Initiator can initialize the FlagStone Core and create a single (Initial) Crypto Officer account, but the Crypto-Initiator cannot assume a Datapath role. Providing there is at least one operator account, an operator can log in using the Log In (OP) service. Once the operator has completed their activities they can • simply log out of the Service Handler • simultaneously assume a Datapath role and stop assuming the Service Handler role (using the Boot service) • assume a Datapath role whilst continuing to assume the Service Handler role (using the Boot service) • for the CO role only, continue to assume the Service Handler role and assume a Datapath role (using the Migrate New DEK or Unlock PAE services) SH role : No Role DP role : No Role Datapath and Service Handler Logout Service Log In Service Handler (C-I) Log In Handler Logout (OP) Logout SH role : C-I SH role : CO, MGR or L-U DP role : No Role DP role : No Role Datapath CO Role Only: Boot Logout Migrate New DEK (Logout SH) or Unlock PAE Boot (Leave SH role : No Role SH Datapath DP role : SDA, C-M or PAE-U Logged Logout Service In) Handler Logout Log In (OP) SH role : CO, MGR or L-U DP role : SDA, C-M or PAE-U Figure 11 - Session Model (FIPS 140-2 Mode of Operation) FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 18 of 50 When an authenticated operator has stopped assuming a Service Handler role but has assumed a Datapath role, this authenticated operator or another unauthenticated operator can log in and assume a Service Handler role using the Log In (OP) service. When an operator is assuming a Datapath role and this operator or another operator is assuming a Service Handler role, no further logins can be performed until the operator assuming the Service Handler role stops assuming this role. An operator assuming a Service Handler role will stop assuming that role whenever: • A service that performs a Service Handler log out is invoked • A FlagStone Core error event occurs An operator assuming a Datapath role will stop assuming that role whenever: • A service that performs a Datapath log out is invoked • A FlagStone Core error event occurs Notes: 1. Auto authentication must not be used when operating in a FIPS 140-2 approved mode of operation (see Section 2.2.1); it allows the Datapath’s Secure Drive Access role to be assumed without the need for an operator to assume a Service Handler role, i.e. without the need for the operator to supply any authentication parameters. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 19 of 50 4.1.4 Accounts In addition to the Crypto-Initiator’s account, the FlagStone Core supports up to 128 operator accounts. When an account is created for an operator, the Service Handler roles available to that operator are specified through the use of the account type. Table 6 summarizes the accounts and the Service Handler role(s) that the operator can assume. Service Handler Role Account Type Account Description C-I CO MGR L-U This is the default account. There is only one C-I Crypto- account. It is only available when there are no  Initiator operator accounts available. This account type supports the Crypto-Initiator. This account type supports the operators that can assume the Crypto Officer role. Operators using this account type must select the Service Handler Role Crypto they wish to assume as part of the Log In process.    Officer Having assumed a particular Service Handler role, the operator must logout then re-authenticate to assume a different Service Handler role. This account type provides all of the functionality available to the CO account type. Initial It differs from a CO account type in that it is the only Crypto    account that the Crypto-Initiator can create. Officer Operator The FlagStone Core only supports a single Initial Crypto Officer account type. This account type supports the operators that can assume the Manager role. Operators using this account type must select the Service Handler Role they wish to assume as part of the Log In process. Manager   Having assumed a particular Service Handler role, the operator must logout then re-authenticate to assume a different Service Handler role. This account type supports the operators that can User  only assume the Service Handler’s User role. Table 6 Accounts Notes: 1. To support Auto authentication, the FlagStone Core provides a single A-A account. However, auto authentication must not be used when operating in a FIPS 140-2 approved mode of operation (see Section 2.2.1); it allows the Datapath’s Secure Drive Access role to be assumed without the need for an operator to assume a Service Handler role, i.e. without the need for the operator to supply any authentication parameters. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 20 of 50 4.2 Services The FlagStone Core services are provided by the Service Handler (Section 4.2.1) and the Datapath (Section 4.2.2). Further information relating to the services can be found in the Flagstone User Guides (Refs. [8], [9] & [10]). 4.2.1 Service Handler Services Unless explicitly stated otherwise within the service descriptions, the Service Handler services are invoked from the PATA Bus (Plain Text), i.e. the Host, through both the use of ATA Vendor specific commands and the use of ATA disk reads and ATA disk writes targeted to specific sector addresses. Table 7 details the Service Handler services and the Service Handler roles that can invoke them. For completeness, the table indicates which services can be invoked when the Service Handler is not assuming a role, i.e. No Role (N-R). Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U System Control Service Group This service is invoked either as a result of a change in Power Status, or is invoked by another service. The Flagstone Core enters the Shutdown State, power consumption is minimized and the Primary (Shutdown)      sanitization is performed. The Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically logged out. (See note 1) Clears the Alarm, then, depending on the supplied parameter, the FlagStone Core is Clear Alarm returned to its ready state, or the Restart service is  invoked or the Primary (Shutdown) service is invoked. Clears the Error, then, depending on the supplied Clear Error parameter, either the Restart service is invoked or  the Primary (Shutdown) service is invoked. Force Shutdown The Primary (Shutdown) service is invoked.  The FlagStone Core is restarted. The Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically Restart logged out. (See note 1)  This service is equivalent to powering off then back on the FlagStone Core; as a consequence the Power On Self Tests are invoked. When the response blocker is active and the Clear Response blocker timeout has expired, this service clears  Blocker the response blocker thereby permitting other services, e.g. Log In, to be invoked. Status Service Group Returns the status of the FlagStone Core, Get Status – Core including self test results, error status, operator      identity & role assumed, & service request status. Returns the status of the FlagStone Drive, as Get Status - Drive      reported by the ATA Command, Identify Device. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 21 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U EECA Service Group This service is only available when the connected Drive’s PAE is not available. This service returns the external application stored Get EECA      in the EECA store. In the event that this external application is not available, the Service Handler returns the FlagStone Core’s default external application. C-I Account Service Group Returns account information for the C-I account. Get Acct Info (C-I)    Uses the supplied authentication parameter to log into the C-I account. Only if the Log In (C-I)  authentication is successful will the Service Handler assume the C-I role. Logs out the C-I; the Service Handler assumes No Role. Log Out (C-I)  This service configures the FlagStone Core for operational use and then automatically logs out the C-I. The configuration involves the import of the Initialize Operational operational RNG key (OPRNG), the creation of  (Generate) & Logout the initial CO account (using the authentication parameters supplied – see note 2) and the generation of the associated CSPs, including the PAEK. This service configures the FlagStone Core for operational use and then automatically logs out the C-I. The configuration involves the import of the Initialize Operational operational RNG key (OPRNG) and the  (Import) & Logout operational wrapping key (OPWK), the creation of the initial CO account (using the authentication parameters supplied – see note 2) and the generation of the associated CSPs, including the PAEK. Operational Account Service Group Returns account information for the operator accounts. Get Acct Info If the Service Handler has assumed No Role only     (Operator) the public information is returned. However, if the Service Handler has assumed a role both the public and the private information is returned. Changes the default acct record stored within Set Default Acct Info the FlagStone Core.  Returns the default acct record stored within the Get Default Acct Info FlagStone Core.  FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 22 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U Operational Account Service Group – continued Providing the specified operator account exists and it is permitted to assume the specified role, this service uses the supplied authentication Log In (OP) parameters (see note 2) to log into the specified  operator account. Only if the authentication is successful will the Service Handler assume the specified role. Logs out the operator currently logged into the Service Handler; the Service Handler assumes No Log Out (OP)    Role. Providing there is no account open, this service opens the specified operator account for Open Acct   creation/ modification. Providing there is an account open, this service unconditionally closes the account; any Discard Acct   modifications to the account will be lost. Providing there is an account open, this service closes the account and updates the account’s Save and Close Acct   entry within the NV Store if it has been modified. Providing there is an empty account open, this service uses the supplied account information Create Acct and authentication parameters (see note 2) to  create an operator account. Providing an operator account is open, this service deletes the open account. Delete Acct Note: To complete the deletion, the operator  must invoke the Save and Close Acct service. Providing there is a non-empty account open, Modify Acct Policy this service updates the account’s policy fields.  Providing there is a non-empty account open, Modify Acct Status this service updates the account’s status fields.   Providing there is a non-empty operator account Change Auth open, this service updates the operator account   Parameters using the supplied authentication parameters (see note 2). Providing there is no account open, this service updates the Service Handler’s currently logged in operator’s account using the supplied Change Own Auth authentication parameters (see note 2).    Parameters Note: This change takes immediate effect; it does not require the Save and Close Account service to complete the update. This service updates the C-I account using the supplied authentication parameter. Change C-I Auth Note: This change takes immediate effect; it  Parameters does not require the Save and Close Account service to complete the update. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 23 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U OPWK Management Service Group This service imports a new operational wrapping key (NewOPWK), and then uses the new OPWK to re-wrap all accessible OPWK protected CSPs. If the operator specified that all accounts are to adopt the new OPWK, the NewOPWK is wrapped Import New OPWK using the old OPWK and placed into the NV  Store. This enables accounts using the old OPWK to adopt the new OPWK at the next successful account login. This service generates a new operational wrapping key (NewOPWK), and then uses the new OPWK to re-wrap all accessible OPWK protected CSPs. If the operator specified that all accounts are to Generate New OPWK adopt the new OPWK, the NewOPWK is wrapped  using the old OPWK and placed into the NV Store. This enables accounts using the old OPWK to adopt the new OPWK at the next successful account login. RNG Management Service Group This service, imports the operational RNG key (OPRNG), overwriting any existing OPRNG. Import New OPRNG  Generates 128-bits of random data and stores the data temporarily within the FlagStone Core. Generate Random To retrieve the random data the operator must     Data use the Get Random Data service. Providing the Generate Random Data service has been performed prior to this service, this service will return the random data produced by Get Random Data     the last Generate Random Data service. DEK Management Service Group This service imports a new DEK, wraps the new DEK using the operational wrapping key (OPWK), Import New DEK and then places the wrapped new DEK and into  the NV Store. This service generates a new DEK, wraps the new DEK using the operational wrapping key (OPWK), and then places the wrapped new DEK and into Generate New DEK  the NV Store. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 24 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U DEK Management Service Group - continued Providing the Datapath has assumed No Role, this service configures the Datapath for DEK migration. The current DEK is loaded into the Datapath's decrypt path and the new DEK is loaded into the Datapath’s encrypt path. The current DEK is replaced with the new DEK, thereby making the new DEK the operational Migrate New DEK  DEK. The wrapped DEKs within the NV Store are updated accordingly. Finally, the Datapath assumes the Crypto- Migrate role and the Service Handler remains in the CO role, i.e. the operator is logged into the Datapath and remains logged into the Service Handler. This service replaces the current DEK with the new DEK, thereby making the new DEK the Promote New DEK operational DEK. The wrapped DEKs within the  NV Store are updated accordingly. This service updates the FlagStone Core status to indicate that the New DEK is no longer present. Remove New DEK The wrapped DEKs within the NV Store are  updated accordingly. Datapath Control Service Group Providing the Datapath has assumed No Role and the connected drive is present and good, this service configures the Datapath for Secure Drive Access, loading the DEK in the process. The Datapath assumes the Secure Drive Access Boot role and, depending whether the supplied    parameter indicates logout Service Handler, the Service Handler either assumes No Role (for logout SH) or remains in current role (for no logout SH) , i.e. the operator is logged into the Datapath and may be logged out of the Service Handler. Providing the Datapath is assuming either the SDA or the C-M role, this service forces the Datapath to assume No Role, i.e. the operator Log Out (Datapath)      logged into the Datapath is logged out. (The Service Handler role is not changed.) Providing the connected drive is present and good, and providing the Datapath has assumed No Role and the PAEK is available, this service enables write access to the PAE region on the connected drive. Unlock PAE  The Datapath assumes the Pre-Authentication Environment Update role and the Service Handler remains in the CO role, i.e. the operator is logged into the Datapath and remains logged into the Service Handler. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 25 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U Datapath Control Service Group – continued Providing the Datapath has assumed the Pre- Authentication Environment Update role, this service disables write access to the PAE region Lock PAE on the connected drive and results in the  Datapath assuming No Role, i.e. the operator is logged out of the Datapath but remains logged into the Service Handler. FlagStone Drive Policy Management Service Group Locks the FlagStone Drive Policy. Any pending Lock Drive Policy  modifications are discarded. Unlocks the FlagStone Drive Policy for Unlock Drive Policy  modification. This service verifies the received FlagStone Drive Policy modifications are in accordance with the current FlagStone Drive Policy. Modify Drive Policy  If the verification is successful, a temporary copy of the FlagStone Drive Policy is updated, and modifications are deemed to be pending. Providing the FlagStone Drive Policy is unlocked and a modification is pending and the drive policy is valid, then this service writes the modified FlagStone Drive Policy to the NV Store and then automatically invokes the Log Out (OP) service. However, if the FlagStone Drive Policy is Save Drive Policy & locked or has not been modified or it is invalid,  Logout an Error is generated (which automatically locks the FlagStone Drive Policy). Note: as soon as the logout has successfully completed, the modified FlagStone Drive Policy comes into effect. Purge Service Group When permitted by FlagStone Drive Policy, this service is invoked as a result of a change on the ATA Links/Purge interface. This service purges all copies of the DEK and the operational RNG key (OPRNG), erases the Purge OOB (ATA operator accounts and the auto authentication      Links) account, and logs out all operators. Both the Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically logged out. When permitted by FlagStone Drive Policy, this service purges all copies of the DEK and the operational RNG key (OPRNG), erases the operator accounts and the auto authentication account, and logs out all operators. Purge – Core    Both the Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically logged out. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 26 of 50 Table 7 Service Handler Services Service Service Handler Role Description N-R C-I CO MGR L-U Decommissioning Service Group When permitted by FlagStone Drive Policy, this service purges all of the FlagStone Core’s CSPs and deletes all accounts. Thereafter, no-one can log into the FlagStone Core. Purge Unit – Core   Both the Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically logged out. Notes: 1. When the FlagStone Core is in the Shutdown state, only the Purge OOB (ATA Links) service is available. 2. For all operator accounts, should both the FlagStone Drive Policy and the Operator’s Account Policy indicate that one of the authentication parameters is sourced from the Key Port, the service will read an authentication parameter from the token connected to the Key port. (The C-I account does not permit authentication parameters to be sourced from the Key Port). 4.2.2 Datapath Services The Datapath services are invoked through the use of ATA disk reads and ATA disk writes. Table 8 details the Datapath services and the Datapath roles that can invoke them. For completeness, the table indicates which services can be invoked when the Datapath is not assuming a role, i.e. No Role (N-R). FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 27 of 50 Table 8 Datapath Services Service Datapath Role Description N-R SDA C-M PAE-U ATA Service Group This service processes the set of ATA commands that are supported by the FlagStone Core but are not associated with FlagStone Core services, Supported ATA e.g. the ATA Set Features command. These Commands – Non     commands are processed in accordance with FlagStone Core the ATA standards. The responses given are those that would be expected for a standard ATA drive. This service handles the set of ATA commands Unsupported ATA that the FlagStone Core does NOT support. In     Commands accordance with the ATA Standards, these commands are aborted. This service sets the PATA (Plain Text) Bus’s ATA Set ATA Device Device Number. Any change to the ATA Device  Number number is only recognized during POST. Secure Drive Access/Crypto-Migrate Service Group This service returns plaintext by reading the data from the connected drive’s non-PAE region and Read & Decrypt Data   decrypting the data using the DEK loaded when the Datapath role was assumed. This service encrypts the supplied data using the DEK loaded when the Datapath role was Encrypt & Write Data   assumed. The resulting cipher text is then written to the connected drive’s non-PAE region. Pre-Authentication Environment Service Group Read Pre- This service returns plaintext by reading the PAE Authentication data from the connected drive’s PAE region and   Environment decrypting the PAE data using the PAEK. Write Pre- This service encrypts the supplied PAE data using Authentication the PAEK. The resulting cipher text is then written  Environment to the connected drive’s PAE region. Monitor Service Group When permitted by Drive Policy, this service Log Out (Datapath) forces the Datapath to assume No Role.   (Monitor) (The Service Handler role is not changed.) When permitted by FlagStone Drive Policy, this service purges all copies of the DEK and the operational RNG key (OPRNG), erases the operator accounts and the auto authentication Purge OOB (Monitor)  account, and logs out all operators. Both the Service Handler and the Datapath assume No Role, i.e. any logged in operators are automatically logged out. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 28 of 50 4.3 Authentication The FlagStone Core module uses identity-based authentication to facilitate access to cryptographic services. 4.3.1 Mechanism FlagStone Core V2.0.1.1, V2.0.1.2, V2.0.2.1, V2.0.2.2, V2.0.3.4, V2.0.4.5, V2.0.5.4 & V2.0.5.5 only provide single port authentication, whereas FlagStone Core V2.0.1.3, V2.0.2.3, V2.0.3.3 & V2.0.5.3 can be configured to operate using single or dual port authentication. Both single and dual port authentication requires the operator to supply a 256 bit authentication value with the service request. Dual port authentication requires the operator to provide a second 256 bit authentication value via the Key Port. Note: The authentication values described in this document are those received by the FlagStone Core. It is expected that most users will use an external application to capture and collate these parameters. The FlagStone Range provides a selection of external applications that users may use to facilitate capture of these parameters. Further details can be found in the Eclypt User Guides (Refs. [8], [9] & [10]). The authentication mechanism for all roles is as follows: 1. IF this account is configured for dual port authentication, THEN XOR the two 256 bit values together to produce a 256 bit Account Validation Key ELSE Use the supplied authentication value as the 256 bit Account Validation Key 2. Use the 256 bit Account Validation Key to unwrap the account’s Wrapping Key using the AES Key Wrap Algorithm. If the AES Key unwrap’s 64 bit check vector fails to validate, then the authentication has failed. 3. Use the account’s 256 bit wrapping key (unwrapped in step 2) to unwrap the 256 bit Secondary Authentication Value. If the AES Key unwrap’s 64 bit check vector successfully validates, then the authentication has been successful, otherwise the authentication has failed. Figure 12 provides a pictorial representation of the authentication mechanism. To successfully authenticate, the authentication mechanism must successfully perform two AES Key unwrap validations using two different wrapping keys. Re-authentication is required following a power cycle or restart of the FlagStone Core and following operator logout. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 29 of 50 Account’s Wrapped from Wrapping Key 256 bit Auth NV Singe Port Auth from Parameter Store Host Account Port AES Key Validation 256 bit Auth KEY Unwrap from Key Parameter XOR Key Port Dual Port Auth Is 64 bit Yes No Check Vector Valid? Wrapped Secondary from Auth Value NV Store Wrapping Key AES Key KEY Unwrap Is 64 bit No Check Vector Valid? Auth Failed Yes Auth Successful Figure 12 - Authentication Mechanism 4.3.2 Roles Authenticated Whenever an operator successfully authenticates, they always assume a Service Handler role and they have authenticated the right to assume certain Datapath roles at a later time. The Datapath roles that may be assumed are summarized in Table 9. Service Handler Datapath Roles authenticated for assumption at a later time Role assumed SDA C-M PAE-U C-I CO    MGR  L-U  Table 9 Service Handler and Datapath Roles Authenticated by Operator Login FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 30 of 50 4.3.3 Probability of False Accept The authentication mechanism is described in Section 4.3.1 and Figure 12. In order to achieve a false accept the authentication value(s) must be guessed and the guess must either be correct or cause the authentication mechanism to deem them to be correct. For single port authentication the probability of correctly guessing the 256 bit authentication value is 1 in 1.16 x 1077. For dual port authentication, the two 256 bit authentication values are XORed to form a single 256 bit Account Validation Key; as a consequence, whilst two 256 authentication values need to be guessed, the guess need only find a pair that produces the correct Account Validation Key. Since the Account Validation Key is 256 bits, the probability of guessing a suitable pair of authentication values is 1 in 1.16 x 1077. The AES Key Wrap Algorithm uses a 64 bit check vector to validate the AES Key unwrap; therefore the probability of a AES Key unwrap validating using an incorrect key is 1 in 1.84 x 1019. The authentication mechanism performs two AES Key unwrap validations using two different wrapping keys; consequently the probability of a single false accept is: (1 in 1.84 x 1019) x (1 in 1.84 x 1019) = 1 in 3.40 x 1038 Since the probability of guessing the authentication value for single port authentication is the same as the probability of guessing a valid pair of authentication values for dual port authentication, the probability of a false accept is the same for both single port and dual port authentication. Since the authentication mechanism’s probability of a single false accept is many orders of magnitude more likely that the probability of guessing the authentication value(s), the probability of guessing the correct authentication value(s) can be ignored. As a consequence, the probability of a single false accept is 1 in 3.40 x 1038. Crypto Officers can limit the number of consecutive failed authentication attempts on each operator account. Furthermore, the FlagStone Core’s response blocker can slow down the rate at which authentication requests are processed. Crypto Officers can configure the FlagStone Core to permit up to 640 failed authentication requests to be processed before the response blocker slows down the rate at which authentication requests are processed. In the worst case, the number of authentication attempts that can be performed in one minute is 648. Consequently, the probability of a false accept within one minute is: 648 in 3.40 x 1038 = 1 in 5.25 x 1035 FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 31 of 50 Table 10 summarizes the probability of a false accept against specific criteria. Criteria Probability Single False Accept 1 in 3.40 x 1038 Within 1 minute 1 in 5.25 x 1035 Table 10 Probability of False Accept FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 32 of 50 5 Finite State Model The Finite State Model for the FlagStone Core is specified in Ref. [6]. All states required for a FIPS 140-2 validation, including Power On/Off states, Crypto Officer states, CSP Entry states, User states, Self-Test states and Error states have been included in the Finite State Model. The FlagStone Core’s Finite State Model has no Bypass States and no Maintenance States. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 33 of 50 6 Physical Security The FlagStone Core is a multi-chip embedded cryptographic module that meets FIPS 140-2 Level 3 for physical security. The FlagStone Core is potted with a hard epoxy resin that is opaque within the visible spectrum. The FIPS 140-2 validation testing was performed at 25°C; no assurance is provided for Level 3 hardness conformance at any other temperature. There are no physical access interfaces to the FlagStone Core and no maintenance services. Damage to the epoxy resin is indicative of a potential violation of the physical security of the FlagStone Core. Damage to the FlagStone Core may be recognized as serious scratching, filing or drilling into the epoxy resin. Visibility of the circuit-board or any chips within the potted boundary may also be indicative of an unauthorized attempt at physical access or a unit not suitable for use. Use of the epoxy resin ensures that attempts to penetrate the FlagStone Core will cause serious damage to the module and it will cease to function correctly; therefore an unauthorized attempt at physical access may also be determined if the module begins functioning abnormally, Power On Self-Tests fail, any Continuous Self-Test fails or it is Unusable. ViaSat recommends that customers ensure themselves that the Eclypt Drive has not been tampered with when they first receive it. If the Eclypt Drive is received embedded within a host (e.g. a laptop or PC) the user is recommended to remove the Eclypt Drive and inspect it prior to first use. Furthermore, ViaSat recommends that customers inspect the Eclypt Drive if it is suspected that it may have been in the possession of an unauthorized individual, e.g. if the Eclypt Drive is lost and subsequently found. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 34 of 50 7 Operational Environment The FlagStone Core module does not contain a modifiable operational environment and thus the Operational Environment requirements of FIPS PUB 140-2 (Ref. [1]) are not applicable. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 35 of 50 8 Cryptographic Key Management 8.1 Critical Security Parameters The Flagstone Core does not allow the export/output of CSPs. Table 11 details the CSPs provided to support FIPS 140-2 approved mode of operation. Table 11 Critical Security Parameters CSP Type Generation/ Storage Erasure Use Input (note 5) Datapath CSPs OPDEK Datapath • Imported from Transient within Sanitize, Datapath’s Operational DEK host; or Operational DEK – FPGA Purge used for read/write access to 256 bit AES Key • Generated & Purge Unit the non-PAE region of the internally using connected drive. FIPS 140-2 RNG. Stored AES Key Purge Wrapped (as & Purge Unit wDEK) within NV Store NewDEK Datapath NewDEK • Imported from Transient within Sanitize, Datapath’s New DEK used for host; or – 256 bit AES Key FPGA Purge write access to the non-PAE • Generated & Purge Unit region of the connected internally using drive. Stored AES Key Migrate/ FIPS 140-2 RNG. Wrapped (as Promote/ wNewDEK) Remove New within NV Store DEK services, Purge & Purge Unit PAEK Datapath PAE Key • Generated Transient within Sanitize, Datapath’s Encryption/ – 256 bit AES Key internally using FPGA Purge Decryption Key for the PAE FIPS 140-2 RNG & Purge Unit region of the connected drive. Stored in plain Purge text within & Purge Unit NV Store RNG CSPs CIRNG RNG_Key • Injected during Transient within Sanitize, Crypto-Initiator’s RNG – 256 bit AES KEY manufacture FPGA Purge, parameters. (see note 2) Purge Unit Stored in plain Purge Unit text within NV Store RNG_Seed • Injected during Transient within Sanitize, – 128-bit manufacture FPGA Purge, (see note 2) Purge Unit • Updated Stored in plain Purge Unit following each text within RNG use. NV Store OPRNG RNG_Key • Imported from Transient within Sanitize, Operational RNG parameters. – 256 bit AES Key host. FPGA Purge & Purge Unit Stored AES Key Purge & Wrapped (as Purge Unit wRNG_Key) within NV Store RNG_Seed • Imported from Transient within Sanitize, – 128-bit host. FPGA Purge & • Updated Purge Unit following each Stored in plain Purge & RNG use. text within Purge Unit NV Store FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 36 of 50 Table 11 Critical Security Parameters CSP Type Generation/ Storage Erasure Use Input (note 5) Operator CSPs OHP[Acct] Operator’s Host • Input supplied Transient within Overwritten Mandatory Operator Auth Parameter by operator (on FPGA by next Authentication Parameter for – 256 bits PATA Bus (Plain service the specified operator Text)) request account. & Sanitize OKAP[Acct] Operator’s Key • Input supplied Transient within Sanitize, Optional Operator Port Auth by operator (on FPGA Purge Authentication Parameter for Parameter Key Port Bus) & Purge Unit the specified operator – 256 bits account. OAVK[Acct] Operator’s Auth • Internal copy of Transient within Sanitize, Key for the first stage of OHP[Acct]; or Validation Key FPGA Purge operator authentication for – 256 bit Wrapping • The XOR of & Purge Unit the specified operator Key OHP[Acct] & account. OKAP[Acct] OPWK Operational • Imported from Transient within Sanitize, Wrapping Key for OPDEK, host; or Wrapping Key FPGA Purge NewDEK, OPRNG and - 256 bit Wrapping • Generated & Purge Unit NewOPWK, and the key for Key internally using the second stage of operator Stored AES Key Acct FIPS 140-2 RNG. authentication for operator Wrapped (as deleting accounts. wOPWK[Acct]) services The wrapped version of this within NV Store (note 6), CSP is unwrapped during (one for each Purge operator authentication (for operator acct & Purge Unit operator accounts that have that has not not been migrated to the been migrated NewOPWK). to NewOPWK) OPNCISAV Operational • Generated Transient within Sanitize, Never used – discarded Non C-I internally using FPGA Purge output from the second stage Secondary FIPS 140-2 RNG. & Purge Unit of operator authentication for Auth Value operator accounts. Stored AES Key Purge - 256 bit Wrapped (as & Purge Unit wOPNCISAV) within NV Store NewOPWK New Operational • Imported from Transient within Sanitize, New Wrapping Key for host; or Wrapping Key FPGA Purge OPDEK, NewDEK and OPRNG, - 256 bit Wrapping • Generated & Purge Unit and the key for the second Key internally using stage of operator Stored AES Key Login (Op) FIPS 140-2 RNG. authentication for operator Wrapped (as service, accounts that have already wNewOPWK) Import/ been migrated to the within NV Store Generate NewOPWK. NewOPWK services, The wrapped version of this Purge CSP is unwrapped during & Purge Unit operator authentication (for Stored AES Key Acct operator accounts that are Wrapped (as deleting being migrated to or already wOPWK[Acct]) services have been migrated to the within NV Store (note 6), NewOPWK). (one for each Purge operator acct & Purge Unit already using NewOPWK) Crypto-Initiator CSPs OHP[C-I] C-I’s Host Auth • Input supplied Transient within Overwritten Mandatory Operator Parameter by operator (on FPGA by next Authentication Parameter for – 256 bits PATA Bus (Plain service the C-I account Text)) request & Sanitize OAVK[C-I] C-I’s Auth • Internal copy of Transient within Sanitize, The key for the first stage of Validation Key OHP[C-I] FPGA Purge operator authentication for – 256 bit Wrapping & Purge Unit the C-I account. Key FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 37 of 50 Table 11 Critical Security Parameters CSP Type Generation/ Storage Erasure Use Input (note 5) Crypto-Initiator CSPs (continued) CIWK C-I Wrapping Key • Injected Transient within Sanitize, The key for the second stage - 256 bit Wrapping wrapped during FPGA Purge of operator authentication for Key manufacture & Purge Unit the C-I account. (see note 3) Stored AES Key Purge Unit • Imported from The wrapped version of this Wrapped (as host when C-I CSP is unwrapped during wCIWK) within auth parameter Crypto-Initiator NV Store is changed authentication CISAV C-I Secondary • Injected Transient within Sanitize, Never used – discarded Auth Value wrapped during FPGA Purge output from the second stage - 256 bit manufacture & Purge Unit of operator authentication for (see note 4) the C-I account. Stored AES Key Purge Unit • Generated Wrapped (as internally using wCISAV) within FIPS 140-2 RNG NV Store when C-I auth parameter is changed Notes: 1. The prefix “w” on a parameter within the NV Store indicates that it is AES Key Wrapped, i.e. it is encrypted. 2. Prior to injection during manufacture, both the RNG_Key and the RNG_Seed for CIRNG are generated using a CAVP validated SHS based RNG from FIPS 186-2. 3. Prior to injection during manufacture, the CIWK is generated using a CAVP validated SHS based RNG from FIPS 186-2 and is then AES Key Wrapped, using the factory determined OAVK[C-I] as the key, to form wCIWK. 4. Prior to injection during manufacture, the CISAV is generated using a CAVP validated SHS based RNG from FIPS 186-2 and is then AES Key Wrapped, using the CIWK generated in note 3 above as the key, to form wCISAV. 5. When the number of active operator accounts falls to zero, a Purge is automatically invoked. 6. Remember, since it is the Save and Close Account service that completes the account deletion, it is this service that performs the erasure. 8.2 Access Privileges to FIPS 140-2 Critical Security Parameters Table 12 details the four types of access to the CSPs. Access Description Type R – Read This access type can read the CSP value, but cannot change the CSP value. W- Write This access type can change the CSP value, but cannot read the CSP value. S – Sanitize This access type positively erases this CSP’s transient storage within the FPGA. E – Erase This access type positively erases this CSP’s non-volatile storage within the NV Store. Table 12 CSP Access Types FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 38 of 50 8.2.1 Role Access Privileges to CSPs When operating in an approved FIPS 140-2 mode of operation, Table 13 details the access privileges to the FIPS140-2 CSPs for the Service Handler roles and the Datapath roles. Service Handler Role Datapath Role Critical Security Parameter N-R C-I CO MGR L-U N-R SDA C-M PAE-U OPDEK SE RWSE RSE RSE RSE RS NewDEK SE RWSE SE SE SE RS PAEK SE RWSE SE SE SE R SE R RNG_Key SE RS RSE S CIRNG RNG_Seed SE RWS RWSE S RNG_Key SE RWSE RWSE RSE RSE SE OPRNG RNG_Seed SE RWSE RWSE RWSE RWSE SE (Own account only) RWS RWS RWS RWS (Accounts that cannot assume CO role) RWS RWS RWS OHP[Acct] S (Accounts that can assume CO role) RWS RWS (Initial CO account during initialization) RWS (Own account only) RWS RWS RWS RWS (Accounts that cannot assume CO role) RWS RWS RWS OKAP[Acct] S (Accounts that can assume CO role) RWS RWS (Initial CO account during initialization) RWS (Own account only) RWS RWS RWS RWS (Accounts that cannot assume CO role) RWS RWS RWS OAVK[Acct] S (Accounts that can assume CO role) RWS RWS (Initial CO account during initialization) RWS OPWK RSE RWSE RWSE RWSE RWSE SE OPNCISAV RSE RWSE RWSE SE SE SE NewOPWK RSE RWSE RSE RSE SE OHP[C-I] RWS S RWS S OAVK[C-I] RWS S RWS S CIWK RSE S RWSE S CISAV RSE S RWSE S Table 13 Role Privileges Rights to CSPs FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 39 of 50 8.2.2 Service Access Privileges to CSPs When operating in an approved FIPS 140-2 mode of operation, Table 14 lists the access privileges to the FIPS140-2 CSPs for the Service Handler services and the Datapath services. Table 14 Service Access Privileges to CSPs RNG CSPs Datapath CSPs Operator CSPs Crypto-Initiator CSPs CIRNG OPRNG OAVK[Acct] OKAP[Acct] Service - Conditions NewOPWK OHP[Acct] RNG_Seed RNG_Seed OPNCISAV OAVK[C-I] RNG_Key RNG_Key OHP[C-I] NewDEK OPDEK OPWK CISAV CIWK PAEK Service Handler Services (Table 7) – no error occurred Primary (Shutdown) S S S S S S S S S S S S S S S S S Clear Alarm – Shutdown selected S S S S S S S S S S S S S S S S S Clear Alarm – Restart selected S S S S S S S S S S S S S S S S S Clear Alarm – Return to Ready selected Clear Error – Shutdown selected S S S S S S S S S S S S S S S S S Clear Error – Restart selected S S S S S S S S S S S S S S S S S Force Shutdown S S S S S S S S S S S S S S S S S Restart S S S S S S S S S S S S S S S S S Clear Response Blocker Get Status – Core Get Status – Drive Get EECA Get Acct Info (C-I) Log In (C-I) RW RW R R Log Out (C-I) S S S S S S Initialize Operational (Generate) & Logout RW S S RWS RWS RWS RWS RWS RWS RWS S S S S - Initial Crypto Officer Account Only Initialize Operational (Import) & Logout RW S S RWS RWS RWS RWS RWS RWS RWS S S S S - Initial Crypto Officer Account Only Get Acct Info (Operator) Set Default Acct Info FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 40 of 50 Table 14 Service Access Privileges to CSPs RNG CSPs Datapath CSPs Operator CSPs Crypto-Initiator CSPs CIRNG OPRNG OAVK[Acct] OKAP[Acct] Service - Conditions NewOPWK OHP[Acct] RNG_Seed RNG_Seed OPNCISAV OAVK[C-I] RNG_Key RNG_Key OHP[C-I] NewDEK OPDEK OPWK CISAV CIWK PAEK Service Handler Services (Table 7) – no error occurred– (continued) Get Default Acct Info Log In (OP) - Active operator accts remain present RW RW RW RW R RE See note 1 Log In (OP) SE SE SE E E RWS RWS RWS RSE RSE RSE - Number of active operator accts falls to zero Log Out (OP) - Service Handler Role is CO S S S S S S S S S S S S S S Log Out (OP) - Service Handler Role is MGR or L-U S S S S S S S S Open Acct Discard Acct Save and Close Acct - Active operator accts remain present Save and Close Acct - Service Handler Role is CO SE SE SE S S SE SE S S S SE SE SE S S S S & Number of active operator accts falls to zero Save and Close Acct - Service Handler Role is MGR SE SE SE SE SE S S S SE SE SE & Number of active operator accts falls to zero Create Acct RW RW RW R R Delete Acct Modify Acct Policy Modify Acct Status Change Auth Parameters RW RW RW R R – Acct currently open only Change Own Auth Parameters RW RW RW R R – Acct logged into Service Handler Change C-I Auth Parameters R RW RW RW RW RW Import New OPWK – OPWK migration completed R R RW R RW RW RWE Import New OPWK – allow further OPWK migration R R RW R R RW RW Generate New OPWK – OPWK migration completed R R RW R RW RW RWE Generate New OPWK– allow further OPWK migration R R RW R R RW RW Import New OPRNG RW W R R Generate Random Data R RW - Service Handler Role is C-I FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 41 of 50 Table 14 Service Access Privileges to CSPs RNG CSPs Datapath CSPs Operator CSPs Crypto-Initiator CSPs CIRNG OPRNG OAVK[Acct] OKAP[Acct] Service - Conditions NewOPWK OHP[Acct] RNG_Seed RNG_Seed OPNCISAV OAVK[C-I] RNG_Key RNG_Key OHP[C-I] NewDEK OPDEK OPWK CISAV CIWK PAEK Service Handler Services (Table 7) – no error occurred– (continued) Generate Random Data R RW R R - Service Handler Role is CO, MGR or L-U Get Random Data Import New DEK RW R R Generate New DEK RW R RW R R Migrate New DEK RW RE R R Promote New DEK W RE Remove New DEK E Boot – Service Handler remains logged in R R R Boot – Service Handler logs out CO role R S S S S S S S RS S RS S S S S Boot – Service Handler logs out MGR or L-U role R S S S S S RS S RS Log Out (Datapath) S S Unlock PAE Lock PAE Lock Drive Policy Unlock Drive Policy Modify Drive Policy Save Drive Policy and Logout S S S S S S S S S S S S S S Purge OOB (ATA Links) SE SE SE S S SE SE S S S SE SE SE S S S S Purge – Core SE SE SE S S SE SE S S S SE SE SE S S S S Purge Unit – Core SE SE SE SE SE SE SE S S S SE SE SE S S SE SE Service Handler Services (Table 7) – error occurred Any Service – Service Handler Role is C-I S S S S S S S S S S S S S Any Service – Service Handler Role is CO S S S S S S S S S S S S S S & Active operator accts remain present Any Service – Service Handler Role is MGR or L-U S S S S S S S S & Active operator accts remain present Any Service – Service Handler Role is N-R S S S S S S & Active operator accts remain present Any Service SE SE SE S S SE SE S S S SE SE SE S S S S – Number of active operator accts falls to zero FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 42 of 50 Table 14 Service Access Privileges to CSPs RNG CSPs Datapath CSPs Operator CSPs Crypto-Initiator CSPs CIRNG OPRNG OAVK[Acct] OKAP[Acct] Service - Conditions NewOPWK OHP[Acct] RNG_Seed RNG_Seed OPNCISAV OAVK[C-I] RNG_Key RNG_Key OHP[C-I] NewDEK OPDEK OPWK CISAV CIWK PAEK Datapath Services (Table 8) Supported ATA Commands – Non FlagStone Core Unsupported ATA Commands Set ATA Device Number Read & Decrypt Data R Encrypt & Write Data R – Datapath Role is SDA and no errors Encrypt & Write Data R – Datapath Role is C-M and no errors Encrypt & Write Data RS S S S S S S S S S S S S S S – Datapath Role is SDA and error occurred Encrypt & Write Data S RS S S S S S S S S S S S S S S – Datapath Role is C-M and error occurred Read Pre-Authentication Environment R Write Pre-Authentication Environment R Log Out (Datapath) (Monitor) S S Purge OOB (Monitor) SE SE SE S S SE SE S S S SE SE SE S S S S Notes: 1. The Write access to the OPWK and the Erase access to NewOPWK can only occur after the operator has been successfully authenticated. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 43 of 50 8.3 Random Number Generator The FlagStone Core contains a FIPS approved Deterministic Random Number Generator based on ANSI X9.31 Appendix A.2.4 Using the AES 256 bit Algorithm, Ref. [3]. The RNG can operate from two different sets of Seed Key and Seed, depending on the Service Handler role adopted. RNG Key and RNG Seed used to support the Service Handler’s Crypto-Initiator role are held secret and are never released from the FlagStone Core. RNG Key and RNG Seed used to support the Service Handler’s Crypto Officer, Manager and User roles are imported in plain text; however they cannot be exported from the FlagStone Core. ViaSat recommends that the RNG Keys and Seeds that are imported into the FlagStone Core are generated or established using a FIPS 140-2 approved or a FIPS 140-2 allowed method. At the time of import of an RNG Key and an RNG Seed, the host shall not be connected to a network. 8.4 Key Derivation There are no Key Derivation techniques employed by the FlagStone Core. 8.5 Key Generation The FlagStone Core uses a FIPS 140-2 approved internal key generation technique to generate keys using the random number generator detailed in Section 8.3. 8.6 Key Entry and Output Keys cannot be exported from the FlagStone Core in any form. During manufacture, both plain text and AES key wrapped keys are injected into the FlagStone Core. Once manufacturing has been completed, the FlagStone Core only permits the entry of plain text keys. It does not permit the entry of encrypted keys or key components. ViaSat recommends that all such keys that are imported into the FlagStone Core are generated or established using a FIPS 140-2 approved or a FIPS 140-2 allowed method. At the time of import of a key, the host shall not be connected to a network. 8.7 Initialization Vector Generation The Initialization Vector is injected into the FlagStone Core during manufacture; this Initialization Vector is generated using a CAVP validated SHS based RNG from FIPS 186-2. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 44 of 50 A replacement Initialization Vector can be imported in plain text. ViaSat recommends that all replacement Initialization Vectors that are imported into the FlagStone Core are generated or established using a FIPS 140-2 approved or a FIPS 140-2 allowed method. 8.8 Key Storage The FlagStone Core stores the following keys and RNG seeds in plain text: • CIRNG - RNG_Key and RNG_Seed • OPRNG - RNG_Seed • PAEK For all other keys, the FlagStone Core uses a FIPS 140-2 approved key wrapping technique, AES Key Wrap (Ref. [4]) to encrypt the keys prior to storage. In order to state that the keys are FIPS 140-2 encrypted, FIPS 140-2 requires that the key used for the AES Key Wrap Algorithm is generated or established using a FIPS 140-2 approved or a FIPS 140-2 allowed method. ViaSat recommends that all keys that are imported into the FlagStone Core are generated or established using a FIPS 140-2 approved or a FIPS 140-2 allowed method. At the time of import of a key, the host shall not be connected to a network. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 45 of 50 9 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC) The FlagStone Core has been tested and meets applicable Federal Communications Commission (FCC) Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) requirements as defined in Subpart B of FCC Part 15, (Class B for home use). FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 46 of 50 10 Self-Tests The FlagStone Core performs self-tests to ensure all security critical functions are functioning correctly. Two types are implemented: • Power On Self-Tests (Section 10.1), which are automatically performed when the FlagStone Core is powered up and can be performed again at the request of an Operator. • Conditional Self-Tests (Section 10.2), which are performed whenever the relevant security function is invoked. The status of Self-Tests can be retrieved, via the status output interface, using the Get Status – Core service. This service returns the overall Power On Self Test status, and the results of individual tests. The overall Power On Self Test status can indicate one of two values as detailed in Table 15. Value Description Passed The Power On Self Tests have been completed and none of them have failed Failed The Power On Self Tests have been completed and one or more of the Power On Self Tests have failed Table 15 Power On Self Test Status In addition to the Self-Test results, the Get Status service will return the general boolean flags, “Error” and “Alarm”. The “Error” flag is set whenever an error has occurred, including any self test failures. The “Alarm” flag is set whenever an alarm has occurred; an alarm is any event that results in a purge being performed. If an external application supplied with the Eclypt/Eclypt Freedom Drive is being used, then retrieval of the Self-Test results using the Get Status service is performed automatically. When an error is detected the external application will display an error message with the appropriate error code (refer to the relevant User Guides, Refs. [8], [9] & [10], for further information). FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 47 of 50 10.1 Power On Self-Tests Table 16 details the tests performed by the FlagStone Core during the power-on sequence. The Power On Self-Tests can be initiated on demand through the use of the Restart, Clear Error and Clear Alarm services. Power On Self-Test Description ATA Bus On Control Test Ensures that the ATA Bus On signal can be controlled correctly. NV Store Integrity Test Ensures that communication can occur between the FlagStone Core and the NV-Store device by verifying that all data regions pass their relevant checksum tests. EECA integrity Test Ensures that communication can occur between the FlagStone Core and the EECA device by performing a CRC-32 based KAT. Connected Drive Ensures that communication can occur between the FlagStone Integrity Test Core and the Connected Drive. In the event the connected drive is not present, this test will pass indicating that the connected drive is not present. Service Handler Crypto Performs known answer tests (KATs) to verify the following Service Function Test Handler Cryptographic Functions are operating correctly. • AES Wrap • AES Unwrap • RNG Datapath Crypto Performs known answer tests (KATs) to verify the following Datapath Function Test Cryptographic Functions are operating correctly. • Encrypt Path of the AES Algorithm • Decrypt Path of the AES Algorithm Datapath Key Store Ensures that the key storage can be zeroized and controlled Integrity Test correctly. Table 16 Power On Self Tests 10.2 Conditional Self-Tests Table 17 details the conditional tests performed by the FlagStone Core; the associated test is performed each time the security function is invoked. Conditional Description Self-Test Continuous This conditional Self-Test ensures that the RNG security function RNG Test does not generate two identical numbers in succession. Table 17 Conditional Self Tests FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 48 of 50 11 Design Assurance 11.1 Configuration Management All elements of the FlagStone Core, including hardware, FPGA code and documentation, are revision controlled according to ViaSat UK ISO 9001:2000 accredited quality management systems. All documents are assigned unique document numbers and subsequently version controlled using issue numbers of the form: 4560-TN123 Issue 1.0. Document numbers are formed by the project code, followed by the document type and a unique one-up value for the remainder of the document number. All hardware components are assigned individual part numbers and issue characters of the form: LF123456-P78 Issue A. All FPGA images are assigned individual part numbers and issue characters of the form: 876543-P21 Issue B. FlagStone Cores are assigned a Version Number of the form: Vu.w.y.x, where u is the major version number, w is the minor version number, y is the FPGA variant number and x is the hardware variant number. Details of the ViaSat UK Quality Process for product development are documented in Ref. [11]. 11.2 Delivery and Operation The FlagStone Core is manufactured and integrated into Eclypt Drives within the same secure environment and does not leave the secure environment prior to the FlagStone Core being potted in the hard opaque epoxy resin. Once integrated into the Eclypt Drive, it will be shipped via courier. The delivery process is detailed in the ViaSat UK ISO 9001:2008 accredited Quality Management System and documented in Ref. [12]. 11.3 Development All elements of the FlagStone Core are developed in accordance with the ViaSat UK ISO 9001:2000 accredited Quality Management System and documented in Ref. [11]. All documentation required for the FIPS validation of the FlagStone Core has been submitted, including PCB layouts, schematics, source code and specifications. Ref. [6] provides the functional specification of the FlagStone Core. All FPGA code has been written in a high-level description language. 11.4 Guidance Documents A combination of the relevant User Guides (Ref. [8] for Eclypt, Ref. [9] for Eclypt Freedom and Ref. [10] for Eclypt Nano) and this document provide all the guidance for the management and usage of the FlagStone Core. This Security Policy and the relevant user guides will be supplied on the CD supplied with the end-product. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 49 of 50 12 Mitigation of Other Attacks Policy The FlagStone Core does not mitigate against other attacks beyond the scope of the FIPS 140-2 requirements. FlagStone Core FIPS 140-2 Security Policy 3650-SP034 Issue 2.0 © ViaSat UK Limited 50 of 50