Cryptographic Module Security Policy For Stealth MXP (Non-Proprietary) FIPS 140-2 Validation Copyright © 2007 by Memory Experts International Inc. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 1 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Table of Contents 1 GENERAL................................................................................................. 4 1.1 REVISION HISTORY ...................................................................................4 1.2 REFERENCES ...........................................................................................5 2 OVERVIEW .............................................................................................. 6 2.1 PURPOSE................................................................................................6 2.2 SCOPE ..................................................................................................6 3 INTRODUCTION ...................................................................................... 8 4 SECURITY LEVELS ................................................................................. 12 5 PORTS AND INTERFACES ...................................................................... 13 6 CRYPTOGRAPHIC KEY MANAGEMENT .................................................... 15 6.1 CRITICAL SECURITY PARAMETERS................................................................. 15 6.2 NON-CRITICAL SECURITY PARAMETERS .......................................................... 18 6.2.1 RSA PUBLIC KEYS ............................................................................... 18 7 IDENTIFICATION AND AUTHENTICATION POLICY ................................ 19 7.1 ROLES................................................................................................. 19 7.2 AUTHENTICATION DATA ............................................................................ 21 8 ACCESS CONTROL POLICY..................................................................... 22 8.1 SERVICES............................................................................................. 22 8.2 SUPPORTED CRYPTOGRAPHIC SERVICES ......................................................... 34 8.3 MODES OF OPERATION .............................................................................. 34 8.4 BYPASS SERVICES................................................................................... 34 9 FINITE STATE MODEL ........................................................................... 36 10 PHYSICAL SECURITY POLICY ............................................................. 37 10.1 PHYSICAL SECURITY MECHANISMS ............................................................. 37 10.2 INSPECTION BY OPERATORS..................................................................... 37 11 EMI/EMC............................................................................................ 38 12 SELF-TESTS ........................................................................................ 39 12.1 BOOTING SELF-TESTS ........................................................................... 39 12.2 ERROR STATES.................................................................................... 39 12.3 KNOWN ANSWER TESTS ......................................................................... 39 12.4 CONDITIONAL TESTS ............................................................................. 40 13 DESIGN ASSURANCE .......................................................................... 41 Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 2 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 13.1 DESIGN AND DEVELOPMENT..................................................................... 41 13.2 DELIVERY AND DISTRIBUTION .................................................................. 41 13.3 INITIALIZATION ................................................................................... 41 14 MITIGATION OF OTHER ATTACKS POLICY.......................................... 42 Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 3 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 1 General 1.1 Revision History Author Date Version Description of Change L. Hamid, D. Nov 14, 2005 1.0 Initial Draft Bouius L. Hamid Nov 16, 2005 1.1 Added some CSPs and made some minor clarifications D. Bouius Nov 29, 2005 1.2 Incorporated feedback from FIPS Lab D. Bouius Feb 22, 2006 1.3 Fixed some inconsistencies G Ainsley Jun 12, 2006 1.6 Clarification for FIPS G. Ainsley Aug 18, 2006 1.7 Removed OP_SETMANUFINFO from table Corrected keys descriptors for consistency G. Ainsley Aug 24, 2006 1.8 Fixes as per 20060824_Comments on Cryptographic Module Security Policy for Stealth MXP.doc G. Ainsley Aug 25, 2006 1.9 Corrected minor errors G. Ainsley Aug 29, 2006 1.10 Updated version number J. Sheehy Feb 13, 2007 1.11 Updated to reflect comments from NIST and CSE. J. Sheehy Mar 9, 2007 1.12 Updated to reflect comments from NIST and CSE. J. Sheehy Mar 16, 2007 1.13 Updated with new version numbers for the FIPS Change Letter J. Sheehy Apr 17, 2007 1.14 Added StealthMXP Passport J. Sheehy Apr 30, 2007 1.15 Added additional StealthMXP Passport references J. Sheehy July 3, 2007 1.16 Added Firmware version 4.19 J. Sheehy Aug 25, 2007 1.17 Updated for new plastic case J. Sheehy Oct 29, 2007 1.18 Updated for Firmware 4.20 and both case types (Plastic and metal) L. Hamid Dec 08, 2007 1.19 Updates for Firmware 4.21 L. Hamid Dec 12, 2007 1.20 Added Erase on Block description in 7.2 L. Hamid Dec 13, 2007 1.21 Updated 6.1.5 re: User Master Keys Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 4 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 1.2 References Reference Title Author P1 FS-MSW1023-01 Stealth MXP Functional Larry Hamid Specification P2 PKCS #5 v2.0 Password Based Cryptography RSA Standard. P3 FIPS PUB 140-2 Security Requirements for NIST Cryptographic Modules P4 X9.31 Digital Signatures using Reversible Public ANSI Key Cryptography for the Financial Services (rDSA) P5 MUS3045 Hardware Design Specification.doc Victor Moskalik Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 5 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 2 Overview 2.1 Purpose This document contains the Security Policy for Stealth MXP. It is meant for public consumption and was written to provide a specification of the cryptographic security that will allow individuals and organizations to determine whether a cryptographic module, as implemented, meets a stated security policy. It describes to individuals and organizations the capabilities, protection, and access rights provided by the cryptographic module, thereby allowing an assessment of whether the module will adequately serve the individual or organizational security requirements. 2.2 Scope This document is based on the requirements and expectations outlined in the FIPS 140-2 specification. This document applies specifically to Stealth MXP with the following versions: Hardware: · Version 4.0 StealthMXP 128MB · Version 4.0 StealthMXP 256MB · Version 4.0 StealthMXP 512MB · Version 4.0 StealthMXP 1GB · Version 4.0 StealthMXP 2GB · Version 4.0 StealthMXP 4GB · Version 4.1 StealthMXP 128MB · Version 4.1 StealthMXP 256MB · Version 4.1 StealthMXP 512MB · Version 4.1 StealthMXP 1GB · Version 4.1 StealthMXP 2GB · Version 4.1 StealthMXP 4GB · Version 4.1 StealthMXP Passport 128MB · Version 4.1 StealthMXP Passport 256MB · Version 4.1 StealthMXP Passport 512MB Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 6 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. · Version 4.1 StealthMXP Passport 1GB · Version 4.1 StealthMXP Passport 2GB · Version 4.1 StealthMXP Passport 4GB · Version 4.2 StealthMXP 128MB · Version 4.2 StealthMXP 256MB · Version 4.2 StealthMXP 512MB · Version 4.2 StealthMXP 1GB · Version 4.2 StealthMXP 2GB · Version 4.2 StealthMXP 4GB · Version 4.2 StealthMXP Passport 128MB · Version 4.2 StealthMXP Passport 256MB · Version 4.2 StealthMXP Passport 512MB · Version 4.2 StealthMXP Passport 1GB · Version 4.2 StealthMXP Passport 2GB · Version 4.2 StealthMXP Passport 4GB FPGA: Version 2.3 Boot loader: Version 2.0 Firmware: · Version 4.16 · Version 4.18 · Version 4.19 · Version 4.20 · Version 4.21 This document describes the identification and authentication policy, the access control policy, the physical security policy and a security policy for mitigation of other attacks. It also details the roles and services provided by Stealth MXP and the types of services each role may access. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 7 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 3 Introduction Stealth MXP is a multiple-chip standalone cryptographic module. Specifically, it is a USB mass storage device which implements hardware encryption dependent on user authentication. It provides not only secure encrypted storage, but management of digital identity credentials used for authentication and verification to enterprise and personal services. As a digital identity device, Stealth MXP is user bound via 2 factor authentication (biometric, password). Stealth MXP can also provide Portable Security Token Service (PSTS) for Web Services Trust Language (WS-Trust), storing up to 36 PSTS Credential Sets and capable of issuing Security Assertion Markup Language (SAML) tokens for an unlimited number of derived bindings to Target Services. These tokens are cached for later use as storage allows. Stealth MXP offers a host general purpose and industry standard cryptographic services including the following · Random number generation · Key generation with internal or external entropy · Symmetric encryption/decryption (AES) · Asymmetric signing and verification (RSA) · Asymmetric encryption and decryption (RSA) ­ Note: RSA encryption and decryption are non-FIPS approved services. · Open Authentication HMAC (keyed-hash message authentication code) · One Time Password (OATH HOTP) · Secure hash (SHA-1 and SHA-256) and · Compliance with industry standards such as ANSI X9.31, PKCS #1 (Public-Key Cryptography Standards) and SAML 1.1. Stealth MXP provides seamless encryption (AES 256) of flash memory storage up to 4GB in a "stick" footprint which is user bound via strong 2 factor authentication (biometric identification with verification and password). Stealth MXP supports the enrollment of 5 users and 6 fingerprints. The Stealth MXP makes use of a patent pending user-mode communication protocol providing true zero footprint mode ­ no software installation and no administrator rights required on the host PC. The Stealth MXP Passport does not have a fingerprint sensor and thus does not provide biometric authentication so users authenticate to the device using a Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 8 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. password. Except for the lack of Biometric operations, the Stealth MXP passport provides all the services of the Stealth MXP. Figure 1: Photo of Stealth MXP in Metal Case Figure 2: Photo of Stealth MXP Passport in Metal Case Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 9 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Figure 3: Photo of Stealth MXP in Plastic Case Figure 4: Photo of Stealth MXP Passport in Plastic Case Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 10 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. The Stealth MXP is designed to be a FIPS 140-2 Level 2 cryptographic module for the storage of user credentials and file systems. Unless performing non-FIPS approved functions, the device will remain in the "FIPS Approved" mode of operation. The enclosed diagram marked "StealthMXP" in the diagram below represents the device enclosure and all internal components. As a stand-alone system, the physical boundary of the device is the cryptographic boundary as outline by the red marking. The Stealth MXP Passport does not contain the swipe sensor or companion chip, but the cryptographic boundaries and all other components are the same as the Stealth MXP. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 11 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 4 Security Levels The Stealth MXP meets an overall security FIPS 140-2 Level 2. The FIPS 140-2 specification defines security requirements that are grouped into Security Requirement Areas. These areas are tested individually for a specific level of achievement. The table below defines the targeted level in each section for the Stealth MXP. Table 1 : FIPS 140-2 Security Requirement Levels FIPS 140-2 Security Requirement Section Target Level Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services and Authentication 3 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks 2 Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 12 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 5 Ports and Interfaces There are three physical ports on the Stealth MXP module: a High Speed Universal Serial Bus (USB 2.0) port, a UPEK TouchStrip Fingerprint swipe sensor, and status LEDs. The Stealth MXP Passport does not contain the UPEK TouchStrip Fingerprint swipe sensor so it has only two physical ports: a High Speed Universal Serial Bus (USB 2.0) port and status LEDs. A secure port (Secure Channel) is implemented by using an encrypted session between the device and the host. It uses AES encryption with a session key that is generated using random data by both the device and host, exchanged using public keys of the device and the host. This is used to protect data exchanged between host and device. Any command sent to the device can then be protected in the secure port by using the new session identifier. The secure port key exchange works as follows: 1) Random data is generated by the device (device-random). 32 bytes of data is generated on the device by reading from the device's hardware entropy generator. 2) Random data is generated by the host (host-random). 32 bytes of data is generated using the OpenSSL PRNG, running on the host machine. 3) Device-random is encrypted with the host's RSA public key and sent to the host 4) Host-random is encrypted with the device's RSA public key and sent to the device. 5) The host and the device each decrypt the exchanged random information 6) The host and the device each concatenate host-random and device-random and use the result to seed a PRNG. 7) The secure session key is derived by the host and device using the seeded PRNG. The following lists the mapping of FIPS 140-2 logical interfaces to physical ports on the Stealth MXP module. Table 2: Logical Interface Description Logical Interface Physical Ports Data Input USB Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 13 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. UPEK Swipe Sensor (Not available on the Stealth MXP Passport) Data Output USB Control Input USB Status Output USB LEDs Secure Channel Input (Wrapper of Data USB and Control) ­ Input to the device using Secure Channel to protect the communication channel Secure Channel Output (Wrapper of USB Data and Status) ­ Output from the device using Secure Channel to protect the communication channel Power USB (Bus powered from host or hub) Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 14 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 6 Cryptographic Key Management 6.1 Critical Security Parameters The Stealth MXP module contains the following Critical Security Parameters. These are referred to in the Identification and Authentication Policy and the Access Control Policy. Each parameter gives details about the relative generation, establishment, distribution, entry/output, storage and zeroization mechanisms. 6.1.1 Fingerprint Templates Stealth MXP stores enrolled fingerprint templates in non-volatile memory within a dedicated ASIC for fingerprint processing. There is no direct interface to this non-volatile memory. The templates are created in the ASIC during enrollment and never leave that device. Verification and identification operations are performed within that module. All templates associated with a user are deleted upon removal of that user. The Stealth MXP Passport device does not contain a biometric sensor, so no fingerprints templates are used on this device. 6.1.2 Passwords Passwords are injected upon creation from the external USB interface. A random salt is also injected as plain text through the USB interface and stored in EEPROM. The password is combined with the salt, then hashed using the SHA256 algorithm and stored in EEPROM associated with the user. The password is then deleted from memory. Password authentication and verification is done by comparing the hash of the trial password combined with the salt with the stored hash. The salt and the resulting hash are zeroized when the user is deleted from the device. 6.1.3 Random Numbers Stealth MXP contains a random number generator that uses an internal, unpredictable physical source of entropy that is outside of human control. This source of random numbers is also available as an external service for general use, separate from the internal service. Random numbers generated by this physical source are sometimes used as part of a seed value for the FIPS approved pseudo-random number generator (ANSI X9.31 Appendix A.2.4 Using AES). Each time a random number is used for any purpose, it is compared to the previously used value to ensure it is different and then stored until the next use. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 15 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 6.1.4 AES Device Master Key Stealth MXP stores one AES 256-bit Device Secret Key that is created upon initialization of the module. This key is used to encrypt the key storage area and the public storage area. The Device Master Key, which is generated using the FIPS-approved Random Number Generator, is stored in EEPROM, does not leave the device and is not available for external services. When the device is recycled, this key is zeroized and therefore the storage areas become invalid. Because the Master key is only used to encrypt keys for storage, it does not actually need to be zeroized because all keys secured with this key can be overwritten. A new master key is created at the end of the recycle operation. 6.1.5 AES User Master Keys Stealth MXP stores one AES Key, known as a User Master Key, for each operator that is defined on the device. This key is used for bulk encryption and decryption of the operator's mass storage partition, private store and any other keys belonging to that operator. AES User Master Keys are either injected onto the device (through the USB interface as plain text assuming that Secure Channel is not being used) from the host system or generated on the device. They can be 128, 192 or 256 bits long. This type of key is generated by the FIPS approved ANSI X9.31 pseudo-random number generator. AES User Master Keys are stored within the module and never leave the module. They are zeroized upon user deletion. Note that even though the AES User Master Keys are stored encrypted, they are considered to be stored as plain text keys according to FIPS 140-2 because the key used to encrypt them, the AES Device Master Key, is not generated by a FIPS approved method. 6.1.6 AES User Secret Keys Stealth MXP stores AES keys, known as User Secret Keys. Each operator may own zero or a few such keys and they can only be used by an authenticated operator. AES User Secret Keys are either injected onto the device (through the USB interface as plain text assuming that Secure Channel is not being used) from the host system or generated on the device by the FIPS approved ANSI X9.31 pseudo-random number generator algorithm. The keys can be 128, 192 or 256 bits long and never leave the module. They are encrypted with the AES User Master Key and stored on the flash memory. When a user is deleted, the AES User Master Key is zeroized and therefore the users AES User Secret Keys cannot be decrypted. 6.1.7 PSTS Services MXI and Microsoft are jointly developing an open standard called Portable Security Token Service (PSTS) that specifies how CardSpace can be managed on portable devices that are capable of issuing SAML tokens. The standard provides ability for a device to be able to support a sub set of WS-Trust standard. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 16 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. PSTS services of the device are non-FIPS Approved services and thus the following PSTS keys are not to be used in a FIPS-Approved mode of operation. 6.1.7.1 PSTS Credential Master Keys Credential Master Keys are seed keys (maximum size of 256 bytes) that are used to generate PSTS Private Keys. Each operator of the module may have 1 or more PSTS credential and using them requires authenticated access. There is one Credential Master Key bound to each PSTS credential. Unlike random number seeds Credential Master Keys are injected into the device (through the USB interface as plain text assuming that Secure Channel is not being used) from the host system and are not erased unless the associated credential is erased. They are stored in EEPROM and never leave the module. When the user is deleted, the Credential Master Keys belonging to that user are zeroized. 6.1.7.2 PSTS Private Keys PSTS Private Keys are 2048 bit RSA keys that are generated internally from Credential Master Keys following the X9.31 [P4] specification. There can be many PSTS Private Keys associated with each credential. Each different PSTS Private Key is bound to a Credential and a PSTS Target Service. PSTS Private Keys are stored on the flash memory, encrypted by the AES User Master Key, and never leave the module. When the user is deleted the AES User Master Key is deleted and therefore the PSTS Private Keys cannot be decrypted. 6.1.8 RSA Private Keys RSA Private Keys are the private portion of an RSA key pair. RSA key pairs that are used for X9.31 [P4] operations are generated internally following the ANSI X9.31 specification. RSA key pairs that are used for PKCS#1 operations are generated internally using the RSA key generation mechanism of OpenSSL. There are two types of RSA private keys: Device and User keys. The Device and User keys are to be set exclusively for general purpose encryption/decryption or else sign/verify purpose. Private keys can be 1024, 2048, or 3072 bits in length. They can either be generated on the device or injected (through the USB interface as plain text assuming that Secure Channel is not being used) and never leave the module. Each operator of the module may own 1 or more RSA User Private Keys and using them requires authenticated access. They are encrypted with the AES User Master Key and stored on the flash memory. When the user is deleted the AES User Master Key is deleted and therefore the RSA User Private Keys cannot be decrypted. RSA Device Private Keys are owned by the device. Device owned private keys require an authenticated user to be used as with any cryptographic operation. When the device is recycled, the RSA Device Private Key is deleted and a new one is generated. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 17 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. RSA general purpose encryption/decryption is not a FIPS approved service. 6.1.9 Critical Security Parameters Association Each user has a separate crypto store that is encrypted with his own User Master Key. Therefore a user cannot access another user's crypto store. Crypto store separation and encryption are the two mechanisms that link users and their own critical security parameters. 6.2 Non-critical Security Parameters 6.2.1 RSA Public Keys Public Keys are the public portion of an RSA key pair. RSA key pairs that are used for X9.31 [P4] operations are generated internally following the ANSI X9.31 specification. RSA key pairs that are used for PKCS#1 operations are generated internally using the RSA key generation mechanism of OpenSSL. There are two types of RSA public keys: Device and User keys. The Device and User keys are to be set exclusively for general purpose encryption/decryption or else sign/verify purpose. Public keys can be 1024, 2048, or 3072 bits in length. They can either be generated on the device or injected (through the USB interface as plain text assuming that Secure Channel is not being used) and never leave the module. Each operator of the module may own 1 or more RSA User Public Keys and using them requires authenticated access. They are encrypted with the AES User Master Key and stored on the flash memory. When the user is deleted the AES User Master Key is deleted and therefore the RSA User Public Keys cannot be decrypted. When the device is recycled the RSA Device Public Key is deleted and a new one is generated. RSA general purpose encryption/decryption is not a FIPS approved service. RSA public and private keys are internally stored as a single entity. When exporting a public key only the public portion of is extracted and output. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 18 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 7 Identification and Authentication Policy 7.1 Roles Stealth MXP performs identity based authentication. Device operators are identified by their user name and authenticated either by password hash comparison, fingerprint template, or both (two-factor). The role of an operator can be either General User, or Administrator. This is defined when the operator is created and may be changed by Administrators under privileged access. A new or recycled device is referred to be in the `Open' state. The Administrator role is the Crypto officer role as defined in the FIPS 140-2 specification [P3]. Administrators have access to management, security policy and configuration functions of the device and are responsible for the overall security of the module. The General User role is a User with limited privileges and access to limited services of the device. Stealth MXP can have up to 5 operators. At least one operator must be an Administrator. FIPS 140-2 authentication requirements are not met when an operator is authenticated to the module with the scan of a finger only. FIPS 140-2 authentication requirements are met when a password or a password combined with the scan of a finger are needed for the operator to authenticate to the Stealth MXP. The Stealth MXP Passport does not have a biometric sensor, so only password authentication is used on the Passport device. Table 3: Roles and Required Identification and Authentication Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 19 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Identification Role Type of Authentication Data Authentication User name Administrator Password or password or fingerprint Two Factor for the template and password Stealth MXP, for the Stealth MXP, Password only for password only for the the Stealth MXP Stealth MXP Passport Passport. User name General User Password or password or fingerprint Two Factor for the template and password Stealth MXP, for the Stealth MXP, password only for password only for the the Stealth MXP Stealth MXP Passport Passport Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 20 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 7.2 Authentication Data The operators/users of Stealth MXP can be authenticated by a fingerprint, password or the combination of them both (also known as two factor authentication). The Stealth MXP Passport supports password authentication only. The associated strength of each mode is shown in Table 4. FIPS 140-2 Security Level 3 authentication requirements are not met when an operator is authenticated to the module by a fingerprint only and not with a password or a password and fingerprint. Upon a failed password attempt, there is a delay of 500 milliseconds. Note that this delay also applies when a password verification operation is done. This delay allows a maximum of 120 tries per minute. Therefore the probability of a random authentication within a one minute period is 1: 650000. The number of failed password attempts allowed before blocking the user is configurable from 1 to 255, or unlimited. When a user becomes blocked, he/she cannot authenticate on the device until an Administrator unblocked him/her. There are two behaviors that can occur on blocking a user depending on a policy configuration. One behavior is to simply block the user and preserve all authentication data and AES User Master Key. In this mode an unblock operation will restore the user's access to all his data. The other policy is to erase all biometric templates, password data, and AES User Master Key. In this mode, all private data becomes inaccessible even after an unblock operation. In the case where there is only one user on the device with Administrator privileges and this user becomes blocked, then the device must be recycled. Table 4: Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Fingerprint Configurable False Match Ratio (FMR): 1 : 2 700 1 : 4 500 1 : 23 000 1 : 55 000 1 : 100 000 Password Minimum 4 characters of the printable ASCII set ~ 1 : 78 000 000 (94^4) Two Factor (Fingerprint and Password) Fingerprint x Password Strength Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 21 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 8 Access Control Policy 8.1 Services The following table enumerates the services on Stealth MXP. The roles and critical security parameters (CSP) have been defined in the previous sections. Note that in column "Authenticated Role Required" in the table below, Admin refers to the Administrator role and that General refers to General User role as defined in table 4. Note that the column `Authenticated Role Required' refers to device states. "Open" and "Locked" are not roles as such but indicate that no authenticated users are needed to carry out the operation. However we need to distinguish between "Open" and "Locked" since the set of operations are different between the two states. The device is "Locked" when there is at least one user with an authentication mechanism. The device is "Open" when there are no users or users without authentication mechanisms. All operations in the table are given explicit permissions to execute in either "Open", "Locked", "Admin" or "General". For example, when the device is in "Open" state, only operations that indicate "Open" can be executed. All operations are verified against the device state to execute. The "Open" state specifies that the device has not yet been initialized, which means that no users have yet been created with registered methods of authentication. Table 5: Services Authorized for Roles and Access Rights within Services Note: "FIPS Approved" means that the service may be used in a FIPS Approved mode of operation. Note: The Stealth MXP Passport device does not have a biometric sensor, so services related to biometric enrollment or biometric authentication are not supported on the Passport device. Service Description CSP Access FIPS Authorized to CSP Approved Role/State Bypass Service Execute a bulk Yes Open Mass Storage OP to Plain read or write to Locked Text LUN the public or read- Admin only mass storage General partition Mass Storage OP to Execute a bulk AES User Master Key Read Yes Admin Private LUN read or write to General the user's secure mass storage partition Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 22 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_BIOCALIBRATE Calibrates the Yes Open biometric sensor. Not available on the Stealth MXP Passport. OP_RESIZEREADONLY Changes the size Yes Open of the read-only partition OP_CREATEUSER Creates a new user Yes Open Admin OP_SETKEYS Injects an AES AES User Master Key Write Yes - Open encryption key for whenever a Admin a user plaintext key is entered from the host into the Stealth MXP, the host must not provide any network access during the operation OP_SETDEVINFO Changes Yes Open information about Admin the device OP_SETPARTINFO Sets partition Yes Open information Admin OP_SETPUBSTOR Writes information AES Device Master Key Read Yes Open to the public store Admin (store data is public ­ use of CSP is only internal to device) OP_DELETEUSER Removes a user User password Set to Yes Open FF Admin RSA Private Keys Set to FF User AES Secret Key Set to FF Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 23 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State User finger enrollments Set to FF PSTS Credential Master Set to Keys FF User PSTS Private Keys Set to FF OP_WRITEUSERINFO Updates user state Yes Open information Admin OP_MOVESECTOR Copy sectors from Yes Open one location to Admin another OP_SWITCH_READONLY Temporarily allows Yes Open write access to the Admin read-only partition OP_GETPRIVSTOR Retrieves AES User Master Key Read Yes Admin information from General the store of an authenticated user OP_SETPRIVSTOR Writes information AES User Master Key Read Yes Admin to the store of an General authenticated user OP_GETUNLOCKEDINFO Retrieves an Yes Admin application secret General payload OP_SETPWD Sets a new user User password Write Yes Open password Admin General (self) OP_ENROLLBIO Performs an User finger enrollment Write Yes Open enrollment of a Admin user's finger. Not General (self) available on the Stealth MXP Passport. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 24 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_DELBIO Removes a user's User finger enrollment Remove Yes Open finger enrollment. d Admin Not available on General (self) the Stealth MXP Passport. OP_CHGPWD Changes an User password Write Yes Open authenticated Admin user's password ­ General (self) note that the user and current password must be provided in the command so there is an implicit authentication even in open state OP_UPDATEFIRMWARE Upgrades firmware Yes Open to a new version Admin OP_READUSERINFO Queries Yes Open information about Locked a user Admin General OP_VERIFYPWD Verifies a User password Read Yes Open password without Locked affecting device Admin state ­ no users General are logged in after operations OP_AUTHPWD Verifies a User password Read Yes Open password for Locked authenticated Admin access General OP_AUTHPWDOTP Verifies a Encrypted User Read Yes Open password password Locked encrypted using Admin HOTP for General authenticated access OP_CHGMINPASSLEN Sets the required Yes Open minimum length of Admin a password (minimum of 4 characters) Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 25 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_LOGOUT Ends the login Yes Admin session for the General current authenticated user OP_SETPROPERTY Sets behavior Yes Open properties of the Admin device (CDROM/disk) OP_GETPROPERTY Retrieves behavior Yes Open properties of the Locked device Admin (CDROM/disk) General OP_GETPUB_RW_STOR Reads information AES Device Master Key Read Yes Open from the RW public Locked store. (store data Admin is public ­ use of General CSP is only internal to device) OP_SETPUB_RW_STOR Writes information AES Device Master Key Read Yes Open to the RW public Locked store (store data is Admin public ­ use of CSP General is only internal to device) OP_GETPUBSTOR Reads information Yes Open from the public Locked store Admin General OP_GETBIOINFO Retrieves status Yes Open about the current Locked fingerprint Admin operation. Not General available on the Stealth MXP Passport. OP_CANCELBIO Aborts a finger Yes Open enrollment Locked operation. Not Admin available on the General Stealth MXP Passport. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 26 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_VERIFYBIO Verifies a finger User finger enrollments Read Yes Open without affecting Locked device state - no Admin users are logged in General after operations. Not available on the Stealth MXP Passport. OP_AUTHBIO Verifies a finger for User finger enrollments Read Yes Open authenticated Locked access. Not Admin available on the General Stealth MXP Passport. OP_GETVERSIONSINFO Retrieves version Yes Open info from firmware Locked and hardware Admin components General OP_GETMANUFINFO Retrieves the USB Yes Open VID/PID, SCSI Locked strings and serial Admin number General OP_GETPARTINFO Retrieves partition Yes Open information Locked Admin General OP_GETDEVINFO Retrieves Yes Open information about Locked the device state Admin and configuration General OP_GETDISKSIZE Retrieves the full Yes Open capacity of the Locked drive Admin General OP_GETLOG Retrieves the Yes Open debug log Locked Admin General Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 27 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_SELFTEST Executes the Yes Open Cryptographic Locked known answer Admin tests. Note: this General does not execute the integrity test, to execute the integrity test, the device must be power cycled. OP_STACKREPORT Reports the stack Yes Open utilization Locked Admin General OP_REPORTCONFIG Reports the Yes Open configuration of Locked the hardware Admin General OP_SETRECYCLECODE Allows the Yes Open management code to be changed OP_RECYCLE Put the device into All passwords Set of Yes Open a new initialized FF Locked state Admin All RSA Private Keys Set of General FF All AES Keys Set of FF All finger enrollments deleted All credential master Set of keys FF OP_CONTINUE Test completed Yes Open status of a request Locked Admin General OP_GENRANDOM Generate Random Random Seed Read Yes Admin Number Write General Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 28 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_SEEDRANDOM Set the seed for Random Seed Write Yes Admin the external General random number service OP_GENKEY Generates an AES User Secret Key Write Yes Admin X9.31 key General Random seed Read Write OP_GENKEYPAIR Generates an RSA RSA Private Keys Write Yes Admin key pair General Random seed Read Write OP_HASH Hash data using Yes Admin SHA-1 or SHA-256 General OP_HASHINIT Start a SHA-1 or Yes Admin SHA-256 operation General OP_HASHUPDATE Continue a SHA-1 Yes Admin or SHA-256 General operation OP_HASHUPDATEKEY Change key for a Yes Admin SHA-1 or SHA-256 General operation OP_HASHFINAL Complete a SHA-1 Yes Admin or SHA-256 General operation OP_HASHKEY Returns the hash AES User Master Key Read Yes Admin of a stored key AES User Secret Key General using SHA-1 or SHA-256 Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 29 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_SIGN Signs data using RSA Private Keys Read Yes Admin the user's RSA key General OP_SIGNINIT Start Sign data RSA Private Keys Read Yes Admin using the user's General RSA key OP_SIGNUPDATE Continue Sign data RSA Private Keys Read Yes Admin using the user's General RSA key OP_SIGNFINAL Complete Sign RSA Private Keys Read Yes Admin data using the General user's RSA key OP_VERIFY Verify data using Read Yes Admin the user's RSA key General OP_VERIFYINIT Start Verify data Read Yes Admin using the user's General RSA key OP_VERIFYUPDATE Continue Verify Read Yes Admin data using the General user's RSA key OP_VERIFYFINAL Complete Verify Read Yes Admin data using the General user's RSA key OP_ENCRYPT Encrypts data with AES User Secret Key Read Yes Admin a user's AES key General Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 30 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP_DECRYPT Decrypts data with AES User Secret Key Read Yes Admin a user's AES key General OP_INJECTKEY Injects an AES AES User Secret Key Write Yes - Admin encryption key for whenever a General a user plaintext key is entered from the host into the Stealth MXP, the host must not provide any network access during the operation OP_INJECTKEYPAIR Injects a RSA RSA Private Keys Write Yes - Admin encryption key pair whenever a General for a user plaintext key is entered from the host into the Stealth MXP, the host must not provide any network access during the operation No if injecting key for RSA encryption/d ecryption OP_DELETEKEY Deletes an AES AES User Secret Key Zeroed Yes Admin encryption key for General a user OP_GETOTP Returns Hash Yes Admin based One Time General Password (HOTP) according to IETF specifications OP_GETKEYPROP Retrieve attributes Yes Admin of a specific key General Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 31 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State OP _RSAENCRYPT Encrypt data with Read No Admin User's RSA private General key OP_RSADECRYPT Decrypt data with RSA Private Keys Read No Admin User's RSA private General key OP_ENUMKEYS Retrieve listing of Yes Open available key types Locked Admin General OP_READPUBLICKEY Retrieves a device Yes Open RSA public key Locked Admin General OP_RESETDEVICE A soft reset is Yes Open applied to the Locked device. Device's Admin firmware executes General from the start. This also causes all the device power-up self tests to be run after the reset. OP_SC_CONNECT Establish a secure Yes Open channel connection Locked Admin General OP_SC_DISCONNECT Closes a secure Yes Open channel connection Locked Admin General OP_SC_WRAPPED When using secure Yes Open channel, all Locked commands are Admin `wrapped' (sent General encrypted) via this command. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 32 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. Service Description CSP Access FIPS Authorized to CSP Approved Role/State PSTS_VALIDATE Determines if the No Open device supports Locked PSTS Admin General PSTS_GET_CAPABILITY Retrieves PSTS No Open properties and Locked policies specific to Admin the device General PSTS_INJECT Injects an InfoCard PSTS Credential Master Write No Admin credential Key General PSTS_REMOVE Removes an PSTS Credential Master Zeroed No Admin InfoCard credential Key General PSTS Private Keys Zeroed PSTS_RST Retrieves a SAML PSTS Credential Master Read No Admin token asserting the Key General requested claims PSTS Private Key Read/W No rite PSTS_ENUM_CREDENTIA Retrieves a list of Open L credential meta- Locked data (any data No Admin specified by General application and not requiring protection) PSTS_UPDATE_CREDENT Updates No Admin IAL information to an General InfoCard credential PSTS_LOGIN Verifies a user for User password Read No Open authenticated Locked access Admin User finger enrollments Read No General PSTS_CANCEL Cancel any PSTS No Open operations in Locked progress Admin General PSTS_LOGOUT Ends the login No Admin session for the General current authenticated user Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 33 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 8.2 Supported Cryptographic Services Cryptographic services in Stealth MXP as detailed in table 5 support both FIPS approved and non-FIPS approved algorithms. The following provides details on both types. FIPS approved cryptographic algorithms · AES o Encrypt/Decrypt [128, 192, 256 bit keys] o Key Generation using X9.31 PRNG · PRNG o X9.31 A.2.4 PRNG using AES · HASH o SHA1 o SHA256 · X9.31 o RSA Key Generation [1024.2048,3072 bit keys] o RSA Sign/Verify [1024,2048,3072 bit keys] with SHA1 or SHA256 · PKCS #1 o RSA Key Generation [1024.2048,3072 bit keys] o RSA Sign/Verify [1024,2048,3072 bit keys] with SHA1 Non-FIPS approved cryptographic algorithms · RSA encrypt/decrypt [1024.2048,3072 bit keys] 8.3 Modes of operation If a command is not FIPS approved, the Stealth MXP will be in a non-FIPS approved mode of operation for the duration of the service. 8.4 Bypass Services StealthMXP provides bypass services. FIPS 140-2 rules governing bypass services on Stealth MXP are observed for service usage and service modifications. The following is a list of bypass services supported on Stealth MXP. 1. Mass Storage OP to Plain Text LUN a. Service activation verification: 2 independent actions are required to activate this service i. Configuring the public partition ii. Check sector offset and boundaries to ensure read and write fall within proper range b. Service modification verification: When service parameters are modified, a CRC is first performed on the master table that holds the Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 34 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. service parameters to insure its integrity. Modifications can only occur if integrity of the table is correct. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 35 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 9 Finite State Model The finite state model of Stealth MXP is proprietary and can be received upon request with a non disclosure agreement. Refer to document DD-MSW1023-01.doc in correspondence. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 36 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 10 Physical Security Policy This section details the physical security mechanisms that protect the cryptographic module, and the actions operators must take to ensure that physical security is maintained. 10.1 Physical Security Mechanisms 10.1.1 Tamper-Evident Enclosure Stealth MXP is secured physically by an opaque tamper-evident metal or plastic case. The openings for the USB plug, finger swipe and LEDS are tightly fitted around the connectors. The enclosure does not have any removable covers or ventilation slits. The photos in section 3 show these details of the Stealth MXP. The USB Type A plug is on the end of the device while the finger swipe and the LEDS are located in the middle recessed area. The device receives power and communicates through the USB connection to a USB host. Evidence of tampering is determined by visually inspecting the device. If the device is pried opened, the metal or plastic casing will break. To modify the device, someone would be required to cut or pry open the shell to access the electronics which would leave visible marks on the casing. 10.2 Inspection by Operators Table 6: Inspection of Physical Security Physical Security Recommended Inspection/Test Guidance Mechanisms Frequency of Details Inspection/Test Tamper-Evident Enclosure Each insertion Visually and tactilely examine enclosure for damage to the metal surface due to prying, cutting, grinding or welding of the material Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 37 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 11 EMI/EMC The Stealth MXP has been tested for and passes the following: · Certification FCC Part 15 Class B · CE EN55022 Class B (1998) for conducted and emissions Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 38 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 12 Self-Tests The Stealth MXP performs a variety of self tests during startup and on demand while conditional tests are executed on the occurrence of certain events. 12.1 Booting Self-Tests Initially the bootloader performs a sanity check on both internal and external RAM. This test writes an alternating pattern in memory and then verifies that the pattern has been written properly. In case of any memory errors the Stealth MXP will enter the Self Test Error State. Once the RAM test has passed, the bootloader checks if an upgrade is required, and if not it calculates a 16 bit CRC on the firmware image and compares it to the stored value. Upon verification the firmware image starts execution and upon failure enters the Error State described below. Booting self tests are always executed when the device starts up. Performing these tests on-demand requires a complete power cycle. 12.2 Error States In the case of a fatal error, the Stealth MXP will start blinking the red and blue light continuously. 12.3 Known Answer Tests The known answer tests are performed at power-on and on demand. The known answer tests are executed on all approved algorithms: AES CBC Mode (Key size: 256 bit) Encrypt and Decrypt HMAC Using SHA-1 (Key size: 256 bit) HMAC Using SHA-256 (Key size: 512 bit) RSA ANSI X9.31 Signature Generation (modulus 1024; SHA-1) RSA ANSI X9.31 Signature Verification (modulus 1024; SHA-1) RSA PKCS#1 Signature Generation (modulus 1024; SHA-1) RSA PKCS#1 Signature Verification (modulus 1024; SHA-1) RNG for ANSI X9.31 (256 bit AES) If the Known Answer Tests do not pass, the Firmware will enter the Error State described above. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 39 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 12.4 Conditional Tests 12.4.1 Software/Firmware Load Test The firmware on the module can be upgraded using an external application, most likely a PC application. The upload process performs RSA digital signature check on the new firmware image before the upgrade is allowed. If the signature is not verified, the upgrade process is aborted and an error is returned to the application. The public key used to verify a new firmware load is embedded in the currently loaded device firmware. 12.4.2 Pair-wise Consistency Test The module can generate private and public key pairs as well as perform the verification of digital signatures. The consistency of each new key pair is tested upon generation by signing static data and verifying the signature. If the verify does not pass, the device enters in error state. Pair-wise consistency test are done for the following: · RSA ANSI X9.31 Key Generation (modulus 1024, 2048, 3072; public key values 3, 17, 65536) · RSA PKCS #1 Key Generation (modulus 1024, 2048, 3072; public key values 3, 17, 65536). 12.4.3 Continuous Random Number Generator Test The module can generate random data from a hardware based entropy system. The data generated is stored for comparison to ensure that the next generated number is not the same as the previous. This test is also performed on the ANSI X9.31 pseudo-random number generator. The test consists in comparing each consecutive block of random data against the previous one. If the data is the same, the device enters in error state. 12.4.4 Bypass Test When the bypass service parameters are modified, a CRC is first performed on its master table that holds service parameters to insure its integrity. Modifications can only occur if integrity of the table is correct. In case of an error, an error code is returned to the user and the operation is aborted. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 40 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 13 Design Assurance The design of Stealth MXP was initiated by a functional specification. A high level language was used (C for the firmware and VHDL for the FPGA) in the creation of the module code to meet the functional specification. Use of low-level language (assembly) was only used in very isolated part of the firmware for performance reasons. The user and administration documents were created from the functional specification to give guidance about the specific tasks and functions of Stealth MXP. 13.1 Design and Development Each component of the Stealth MXP hardware and firmware design is under strict version control. The firmware is maintained with a CVS [Concurrent Version System] server and SmartCVS clients. Every release of firmware and hardware is specifically tagged with a build version number. The hardware version is labeled with the product number on the boards. The firmware version is available through a command in the user interface. During design, the product goes through quality control to confirm that it meets all aspects of the functional specification. Production utilities fully test each device through an automated test suite. 13.2 Delivery and Distribution There are no security risks during delivery to authorized operators. Devices are shipped from the factory in an open state with no users. The first user that is created is an Administrator and becomes the Crypto Officer. That officer can then perform all services as specified in the Access Control Policy section. The devices are shipped from the factory using a bonded courier directly to the purchaser. 13.3 Initialization When a new device is received by an organization or individual, the procedures outlined in the Quick Start Guide and the Administration manual should be followed. It is recommended to change the device management code from the default setting. The device is shipped in the `open' state with no users enrolled. The first user created becomes an Administrator. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 41 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety. 14 Mitigation of Other Attacks Policy The Stealth MXP provides additional mechanisms for mitigating attacks not specifically addressed by FIPS 140-2. The following table describes the mechanisms used. Table 7 : Mitigation of Other Attacks Other Attacks Mitigation Mechanism Specific Limitations Power Analysis The combination of hardware If the user participates in (Simple and and software mechanisms the power analysis by differential) makes it very difficult to unlocking the device for derive key information. the attacker and the Hardware mechanism attacker has a significant · Power supply filtering amount of time to send to limit the amount of and receive known data noise due to from the encrypted calculations of the partition, that user's key processor. may be made vulnerable to power analysis. Software mechanism · The device is multithreaded and tasks scheduling is in practice very difficult to guess · User key is only used when the device is unlocked. Cryptographic Module Security Policy for Stealth MXP Date: Dec 13, 2007 Copyright © 2007 MXI. Distribution of this document by the Cryptographic Module Validation Page 42 of 42 Program validation authorities, the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE), is allowed providing the document is copied or printed in its entirety.