Software House iSTAR eX Controller (Hardware Version: STAREX004W-64 Firmware Version: 4.1.1.12045) FIPS 140-2 Non-Proprietary Security Policy Level 2 Validation Document Version 0.7 Prepared for: Prepared by: Software House Corsec Security, Inc. 70 Westview Street 10340 Democracy Lane, Suite 201 Lexington, MA 02421 Fairfax, VA 22030 Phone: (781) 466-6660 Phone: (703) 267-6050 Fax: (781)466-9550 Fax: (703) 267-6810 http://www.swhouse.com http://www.corsec.com © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Revision History Version Modification Date Modified By Description of Changes 0.1 2006-11-24 Cas Stulberger Initial draft. 0.2 2007-03-12 Cas Stulberger Updated Security Policy to address lab questions. 0.3 2007-03-26 Darryl H. Johnson Updated Security Policy to address lab questions. 0.4 2007-09-04 Darryl H. Johnson Updated to address CMVP comments. 0.5 2007-10-30 Darryl H. Johnson Updated to address CMVP comments regarding roles and services. 0.6 2007-12-14 Darryl H. Johnson Updated to address CMVP comments regarding the definition of roles, inclusion of clusters, and use of RSA. 0.7 2008-01-04 Darryl H. Johnson Updated to address CMVP comments regarding the power-up integrity test. Software House iSTAR eX Controller Page 2 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Table of Contents 1 INTRODUCTION ...............................................................................................................................................5 1.1 PURPOSE .....................................................................................................................................................5 1.2 REFERENCES ...............................................................................................................................................5 1.3 DOCUMENT ORGANIZATION ........................................................................................................................5 2 ISTAR EX CONTROLLER ...............................................................................................................................6 2.1 OVERVIEW ..................................................................................................................................................6 2.1.1 Module Components ......................................................................................................................6 2.1.2 Deployment ....................................................................................................................................7 2.2 MODULE INTERFACES ...............................................................................................................................10 2.3 ROLES AND SERVICES ...............................................................................................................................12 2.3.1 Crypto Officer Role......................................................................................................................12 2.3.2 User Role .....................................................................................................................................14 2.3.3 Cluster Member Role ...................................................................................................................15 2.3.4 Non-FIPS Services .......................................................................................................................16 2.4 PHYSICAL SECURITY .................................................................................................................................16 2.5 OPERATIONAL ENVIRONMENT ..................................................................................................................16 2.6 CRYPTOGRAPHIC KEY MANAGEMENT ......................................................................................................17 2.6.1 Approved Algorithms ...................................................................................................................17 2.6.2 Non-Approved Algorithms ...........................................................................................................17 2.7 SELF-TESTS ...............................................................................................................................................20 2.8 DESIGN ASSURANCE .................................................................................................................................20 2.9 MITIGATION OF OTHER ATTACKS .............................................................................................................21 3 SECURE OPERATION....................................................................................................................................22 3.1 INSTALLATION ..........................................................................................................................................22 3.2 INITIAL SETUP ...........................................................................................................................................22 3.2.1 Putting the iSTAR eX in FIPS 140-2 Mode of Operation.............................................................23 3.2.2 Setting up a Custom Certificate for FIPS Mode ..........................................................................23 3.2.3 Verifying FIPS Mode of Operation ..............................................................................................24 3.3 CRYPTO OFFICER GUIDANCE ....................................................................................................................24 3.3.1 Initialization.................................................................................................................................25 3.3.2 Management.................................................................................................................................25 3.3.3 Zeroization ...................................................................................................................................25 3.4 USER GUIDANCE .......................................................................................................................................26 4 ACRONYMS......................................................................................................................................................27 Table of Figures FIGURE 1 ­ ISTAR EX CONTROLLER LOGICAL DIAGRAM ..............................................................................................7 FIGURE 2 ­ NETWORK TOPOLOGY ..................................................................................................................................8 FIGURE 3 ­ SINGLE AND ALTERNATE MASTER CONFIGURATIONS ..................................................................................9 FIGURE 4 ­ CLUSTER MEMBER COMMUNICATION PATHS ............................................................................................10 FIGURE 5 ­ MULTI TECHNOLOGY CARD READERS .......................................................................................................11 FIGURE 6 ­ RM READERS .............................................................................................................................................11 FIGURE 7 ­ WIEGAND READERS ...................................................................................................................................12 FIGURE 8 ­ KEY MANAGEMENT POLICY SCREEN .........................................................................................................23 Software House iSTAR eX Controller Page 3 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 FIGURE 9 ­ FIPS MODE REPORT ..................................................................................................................................24 List of Tables TABLE 1 ­ SECURITY LEVEL PER FIPS 140-2 SECTION ..................................................................................................8 TABLE 2 ­ FIPS 140-2 LOGICAL INTERFACES ..............................................................................................................12 TABLE 3 ­ MAPPING OF CRYPTO OFFICER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ......14 TABLE 4 ­ MAPPING OF USER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS .........................15 TABLE 5 ­ MAPPING OF CLUSTER MEMBER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ....16 TABLE 6 ­ LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS .....................................18 TABLE 7 ­ ACRONYMS .................................................................................................................................................27 Software House iSTAR eX Controller Page 4 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the iSTAR eX Controller from Software House. This Security Policy describes how the iSTAR eX Controller meets the security requirements of FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 2 FIPS 140- 2 validation of the module. FIPS 140-2 details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/cryptval/. The iSTAR eX Controller is referred to in this document as the iSTAR eX, the Master Controller, Cluster member, or the module. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 Cryptographic Module Security Policy. More information is available on the module from the following sources: · The Software House website (http://www.swhouse.com) contains information on the full line of products from Software House. · The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: · Vendor Evidence document · Finite State Machine · Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Software House. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Software House and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Software House. Software House iSTAR eX Controller Page 5 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 2 iSTAR eX Controller 2.1 Overview The iSTAR eX Controller is a hardware module developed by Software House. The iSTAR eX Controller is a door controller which is connected to at least one card reader and a door. After a card is swiped through a connected card reader, the information contained on the card about the person to whom the card is assigned is transmitted to the iSTAR eX. The iSTAR eX then consults its database and determines whether to allow access to the person by opening the door. The iSTAR eX will then send a message to open the door if access is allowed. If access is not allowed, then the door will not open and the user is denied entry. 2.1.1 Module Components The iSTAR eX Controller is composed of the following hardware components (pictured below in Figure 1): · iSTAR eX General Control Module (GCM) board · Power Management Board (PMB) · LCD Display · 12V DC Power Supply · Battery Software House iSTAR eX Controller Page 6 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Figure 1 ­ iSTAR eX Controller Logical Diagram There is one processor located inside the iSTAR eX and it is located on the GCM board. The PMB contains a microcontroller which is responsible for managing power distribution within the iSTAR eX and controlling power to all peripheral modules and card readers. The GCM board contains a 400 MHz PXA255 Microprocessor, a member of the Intel XScale family of ARM processors that runs Microsoft Windows CE 5.0. The GCM board controls the input and output to and from the card readers connected to the GCM board and the PMB board. The PMB board contains an Atmel ATMEGA32 Microcontroller, which communicates with the GCM via the Serial Peripheral Interface (SPI) bus. The PMB microcontroller manages the power system and backup facility of the iSTAR eX. The PMB microcontroller charges the battery, detects power loss, restores main power, and manages switching between main and battery power, as well as supplying power to the GCM board. The LCD Display is an internal display that is used during setup and configuration of the iSTAR eX to monitor the status of the device and the self tests. The 12V DC Power Supply is connected to the PMB and supplies the power to the iSTAR eX. The battery is a 17.2 Ah lead acid battery. If the voltage drops below 12 volts, battery power will be supplied to all iSTAR eX circuit boards, peripherals, and readers, which enables the system to be fully functional under battery power. The battery will keep a typical system operational for a minimum of 4 hours. The battery will be fully recharged in 24 hours or less. 2.1.2 Deployment The iSTAR eX Controller provides for secure communications in a network environment for enterprise-wide access control. Multiple iSTAR eX appliances can be networked into user-defined, logical groups called clusters. Clusters contain up to 16 iSTAR eX controllers. A host can be connected to several clusters (see Figure 2). Each cluster has one controller that serves as the master; other controllers in the cluster are cluster members. The master controller handles the communication of all event and cardholder data between the cluster and a CCURE 800/8000 host. The cluster members communicate through the master to the other controllers in the cluster to link events and share cardholder status and location to mitigate the occurrence of such activities as "tailgating" (following another cardholder into a secured area without presenting a separate badge) and "passback" (passing back a card to another person to use) in the area secured by this cluster of controllers. NOTE: FIPS mode is set at the cluster level; thus, every controller in the cluster will reflect the same FIPS status. For this validation, however, it is critical to note that a cluster can consist of a single controller. Thus, any discussion in this document referencing "clusters" (except where multi-controller configurations are expressly stated) refers to a single-controller cluster, which represents the module. Software House iSTAR eX Controller Page 7 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Figure 2 ­ Network Topology The following table details the security level achieved by the iSTAR eX Controller in each of the eleven sections of FIPS 140-2. Table 1 ­ Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 2 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment N/A 7 Cryptographic Key Management 2 8 EMI/EMC 2 9 Self-tests 2 10 Design Assurance 2 11 Mitigation of Other Attacks N/A To ensure continuous connectivity, an iSTAR eX cluster can be configured with multiple communication paths to the CCURE 800/8000. These paths can be set up using either a single master controller or two alternative master Software House iSTAR eX Controller Page 8 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 controllers. The single master configuration employs one cluster member as the master controller, providing a "primary" and "secondary" connection to the network. The alternate master configuration employs two cluster members to act as "primary" and "secondary" master controllers, with each having a single connection to the network. Figure 3 shows primary and secondary communication lines using a single master (left) and alternate master (right). Figure 3 ­ Single and Alternate Master Configurations Figure 4 below consists of two diagrams illustrating how communications occur (1) between a cluster member and the CCURE 800/8000 Host Server and (2) between two cluster members. The diagram on the left of the figure shows how cluster member A communicates with the host via the master. The diagram on the right of the figure shows how cluster member A communicates with cluster member B via the master. The numbered arrows in the diagrams illustrate the order and direction of the communications path between the various network nodes. Software House iSTAR eX Controller Page 9 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Figure 4 ­ Cluster Member Communication Paths 2.2 Module Interfaces The iSTAR eX Controller is a multi-chip standalone module that meets overall level 2 FIPS 140-2 requirements. The cryptographic boundary of the iSTAR eX Controller is defined by the module's steel case enclosure. Each iSTAR eX Controller has the following interfaces: · Power plug/adapter · RS-485 port · 2 RJ-45 Ethernet ports · 4 Direct Wiegand Reader ports · Reader Bus The power plug/adapter provides power to the iSTAR eX. The RS-485 port is used to communicate with card readers. The Ethernet ports are used for establishing Transport Layer Security (TLS) communications with other iSTAR eXs and the CCURE 800/8000 host server. The four Direct Wiegand Reader ports and the Reader bus are used for connecting card readers to the iSTAR eX. Figure 5 below shows pictures of some of the types of card readers that can be connected to the iSTAR eX. Software House iSTAR eX Controller Page 10 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Figure 5 ­ Multi Technology Card Readers Figure 6 ­ RM Readers Software House iSTAR eX Controller Page 11 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Figure 7 ­ Wiegand Readers All of these physical interfaces are separated into logical interfaces defined by FIPS 140-2, as described in the following table: Table 2 ­ FIPS 140-2 Logical Interfaces FIPS 140-2 Logical Interface iSTAR eX Controller Port/Interface Data Input RS-485 port, 2 Ethernet ports, 4 Direct Wiegand Reader ports, Reader Bus Data Output RS-485 port, 2 Ethernet ports, 4 Open Collectors Control Input 2 Ethernet ports Status Output 2 Ethernet ports Power Power plug/adapter 2.3 Roles and Services The module supports role-based authentication. There are three roles in the module that operators may assume: a Crypto Officer role, a User role, and a Cluster Member role. These roles are described in the paragraphs that follow. The module can only be accessed through well-defined commands and interfaces. All operators accessing these commands are assuming their roles and are authorized. 2.3.1 Crypto Officer Role The Crypto Officer role is responsible for the initialization and management of the cryptographic functions provided by the module. This role is generally assumed by module's management applications (acting on behalf of a human operator): the iSTAR Configuration Utility (ICU) and the CCURE 800/8000 host server. The ICU provides Software House iSTAR eX Controller Page 12 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 iSTAR eX configuration, diagnostic, and troubleshooting options. The ICU is used to designate the master controller, define master IP addresses, and define the IP address of the host server. Other configuration information is defined and downloaded from the CCURE 800/8000 host server. To ensure correct configuration, the information that is entered in the ICU must match the information that is entered in the CCURE 800/8000 Administration Application. The module receives configuration information via the control input interface, and any status resulting from the input is communicated via the module's status output interface. Information-passing via these interfaces occurs via secured TLS sessions. The module uses RSA for the verification of host server. The Crypto Officer is authenticated by providing a digital certificate containing it RSA public key to the module during the TLS handshake. Descriptions of the services available to the Crypto Officer role are provided in the table below. Software House iSTAR eX Controller Page 13 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Table 3 ­ Mapping of Crypto Officer Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access Configure the module Configure the module IP data via None None using the required IP management address and application connection data. Configure the module Configure the module FIPS selection from None None for FIPS-approved for FIPS-approved the configuration mode of operation mode of operation. screen Create database of Create database of User names and None None access card rights access card rights applicable authorization data Reboot the module Command the module Reboot command Module reboots (and, None to reboot and restart. if configured for FIPS mode, initiates power up self-tests) Generate new RSA Generate new RSA Message from the New RSA key pair RSA key ­ Read / key pairs and key pairs and CCURE 800/8000 and certificate Write certificate certificate. Server to generate generated PRNG seed ­ Read new RSA key pair Establish a secure Establish a secure Digital certificate Secure connection AES key ­ Read TLS session TLS session with a established RSA key ­ Read CCURE 800/8000 PRNG seed ­ Read Server. Encrypt data for Encrypt data for Plaintext data to be Encrypted data AES key ­ Read transmission. transmission. transmitted RSA key ­ Read PRNG seed ­ Read Decrypt received Decrypt received Ciphertext data Decrypted data AES key ­ Read data. data. received RSA key ­ Read Terminate a secure Terminate a secure None Secure connection None TLS session TLS session. terminated Show status Display module status Selection of the Status window is None information. appropriate menu displayed on the item on the CCURE CCURE 800/8000 800/8000 Server Server. Perform self-tests Initiate and run all Reboot command Module reboots and AES key ­ Write power-up self-tests. initiates power up PRNG seed ­ Read self-tests 2.3.2 User Role The User role performs general security services and has access to the module's general security functionality. The User is a human with an access control card. The User initiates the access request process by sliding the card through a card reader that is hard-wired to the module. The sliding of the card sends a request to the controller, which contains the access control database created by the Crypto Officer via the host server and uploaded into the module. Software House iSTAR eX Controller Page 14 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 The module receives access request data from the User via the data input interface, and any data to be sent back is communicated via the module's data output interface. The User role is implicitly assumed by swiping the access card through the attached card reader. Descriptions of these services available to the User role are provided in the table below. Table 4 ­ Mapping of User Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access Initiates access Request access to Access rights Opened door for None request process controlled area. information (via card approved access swipe on card reader) request Receive access Receive a response Access request Access approval or None request response to the access request denial 2.3.3 Cluster Member Role The Cluster Member role is another user-type role that is assumed by a networked controller in a single- or multi- controller environment. In the multi-controller environment, the module is designated as the master controller; as such, all other controllers in its cluster can communicate with it, but can only communicate with each other by first relay the information through the module (refer to Figure 4 above). The Cluster Member role is responsible for establishing the TLS session with the module and for the encryption and transmission of access control data to the module. The module receives access event data and access requests from the Cluster Member role via the data input interface, and any data to be sent back is communicated via the module's data output interface. The module uses RSA for the verification of Cluster Member credentials and the exchange of encryption keys. The Cluster Member is authenticated by providing a digital certificate containing its RSA public key to the module during the TLS handshake. Descriptions of the services available to the Cluster Member role are provided in the table below. Software House iSTAR eX Controller Page 15 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Table 5 ­ Mapping of Cluster Member Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access Initiate a secure TLS Initiate a secure TLS Digital certificate Secure connection AES key ­ Read session session with a established RSA keys ­ Read module. Encrypt data for Encrypt data for Plaintext data to be Encrypted data AES key ­ Read transmission. transmission. transmitted Determine access Check access card Access rights Access approval or None rights rights database information denial Decrypt received Decrypt received Ciphertext data Decrypted data AES key ­ Read data. data. received Terminate a secure Terminate a secure None Secure connection None TLS session TLS session. terminated 2.3.4 Non-FIPS Services When the iSTAR eX is running in FIPS mode, it goes Dark (i.e., it functions as a black box) and inhibits the following services: · ICU broadcast messages · ICU configuration · Simple Network Management Protocol · NanView - a Software House development tool · iSTAR web page When the iSTAR eX is running in non-FIPS mode, these services are normally allowed. However, they must be disabled when running in FIPS mode. The disabling of these services is discussed in Section 3 of this document. 2.4 Physical Security The iSTAR eX Controller is a multi-chip standalone cryptographic module. The GCM, PMB, LCD, power supply, and battery of the iSTAR eX Controller are entirely contained within a steel case enclosure. When punch-outs are removed to make necessary power and network connections, the gaps in those punch-out holes must be properly secured to resist probing. When properly installed, and after all open punch-out holes are properly secured, the module's enclosure is resistant to probing and is opaque within the visible spectrum. The iSTAR eX Controller has a door on the front which contains a lock. The door is protected with tamper-evident seals in order to reveal tampering with the door. The iSTAR eX Controller has punch-out holes for Ethernet and power cables. Unused punch-out holes are covered with tamper-evident seals to prevent tampering. See Secure Operation in Section 3 below for instructions on how to affix the tamper-evident seals. 2.5 Operational Environment The module does not provide a modifiable general-purpose operating system to the user. The module does not offer any method for an operator to load new software on the module. The operating system is stored on the module's flash and executes the code on the processor chip. Software House iSTAR eX Controller Page 16 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 2.6 Cryptographic Key Management The module employs a system-wide Key Management mode that the host and all iSTAR eX controllers in the same cluster must use. In FIPS mode of operation, the use of specific key management modes is required; custom certificates must be either generated by the controller (Custom Controller Management mode) or the host (Custom Host Management mode). 2.6.1 Approved Algorithms The iSTAR eX implements the following FIPS-approved algorithms: · Advanced Encryption Standard (AES) CBC 1 mode 256-bit ­ FIPS 197 (certificate #433) · Deterministic Random Number Generator (RNG) ­ Appendix A.2.4 of ANSI X9.31 (certificate #283) · SHA-1 ­ FIPS 180-2 (certificate #575) · RSA 2 1024-bit key used for signature generation/verification (certificate #219) 2.6.2 Non-Approved Algorithms The iSTAR eX implements the following non-FIPS-approved algorithms: · RSA 1024-bit key (key wrapping methodology provides 80 bits of encryption strength) · Pseudo-Random Number Generator (PRNG) ­ hardware implementation 1 CBC ­ Cipher Block Chaining 2 RSA ­ Rivest Shamir and Adleman Software House iSTAR eX Controller Page 17 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 The module supports the following critical security parameters: Table 6 ­ List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Output Storage Zeroization Use Session Key 256-bit AES Generated internally Never output Stored in RAM for Deleted after session Encrypting data symmetric key duration of the is over transferred during session TLS with the server CCURE 800/8000 1024-bit RSA public Input during TLS Never output Stored in volatile Deleted after session Used along with RSA public key key negotiations memory is over certificate to authenticate the CCURE 800/8000 host server. iSTAR eX RSA public 1024-bit RSA public a) Generated Transmitted during Stored in non-volatile When a new RSA key Used along with key key internally (when in TLS session memory pair is generated. certificate to Custom Controller negotiation; sent to authenticate the Key Management CCURE 800/8000 iSTAR eX. mode) for signature. b) Generated by the CCURE 800/8000 host server and downloaded to module (when in Custom Host Key Management mode) Software House iSTAR eX Controller Page 18 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 Key Key Type Generation / Input Output Storage Zeroization Use iSTAR eX RSA 1024-bit RSA private a) Generated Never output Stored in non-volatile When a new RSA key Encrypting AES private key key internally (when in memory pair is generated. symmetric key. Custom Controller Key Management mode) b) Generated by the CCURE 800/8000 host server and downloaded to the module (when in Custom Host Key Management mode) PRNG seed 160 bits of seed value Internally generated Never output Stored in Flash Upon restart of the Generating pseudo by the non-FIPS memory iSTAR eX random numbers for approved RNG generation of RSA and AES keys Software House iSTAR eX Controller Page 19 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 2.6.2.1 Key Generation The AES Symmetric Key is used to encrypt communications from the module to the CCURE 800/8000 host server (and a master controller when the module is used in a multi-controller cluster environment). This key is generated during the TLS session as allowed per FIPS 140-2 Implementation Guidance 7.1 (updated June 26, 2007). 2.6.2.2 Key Input and Output The RSA public/private key pair used for the TLS sessions is generated internally, and the RSA private key is never output from the module. 2.6.2.3 Key Storage and Zeroization AES Symmetric keys and PRNG seeds are stored in volatile memory in plaintext and zeroized after use or on reboot. The RSA public/private key pair generated by the module is also stored in the Flash memory in plaintext. The RSA public/private key pair can be zeroized by creating a new key pair. 2.7 Self-Tests The iSTAR eX Controller performs the following self-tests at power-up: · Firmware integrity test · Cryptographic algorithm tests o Known Answer Tests (KATs) AES KAT SHA-1 KAT RSA KAT ANSI X9.31 Appendix A.2.4 PRNG KAT The iSTAR eX Controller performs the following conditional self-tests: · Continuous RNG test for FIPS-Approved PRNG · Continuous RNG test for non-FIPS-approved hardware PRNG · Pairwise consistency test for RSA If one of the KATs or the firmware integrity test fails, then the iSTAR eX will not boot into FIPS mode. The iSTAR eX will try again to boot into FIPS mode. If the device cannot boot into FIPS mode, the problem may need to be diagnosed by the Crypto Officer. If one of the conditional self tests fails, TLS communications will not occur. If the continuous RNG test fails, the RNG will generate another number until it does not equal the previous number. 2.8 Design Assurance Software House's source code, user manuals, and procedures are all maintained in Rational ClearCase. The version of Software House's code and documents are labeled in ClearCase to uniquely identify the code associated with that version. The user manuals are tailored for each specific customer and are updated with each version of the iSTAR eX. Additionally, Microsoft Visual SourceSafe (VSS) version 6.0 is used to provide configuration management for the iSTAR eX Controller's FIPS documentation. This software provides access control, versioning, and logging. Software House iSTAR eX Controller Page 20 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 The modules are distributed in cartons sealed by Software House. The iSTAR eX GCM, PMB, and power supply each have their own unique serial number printed on them. These are then scanned and assigned to the iSTAR eX assembly serial number, which is printed on a label on the outside of the box. Software House ships the modules using recognized package delivery companies. The Crypto Officer receives the module from Software House via this secure delivery mechanism. Upon receipt of the module, the end-user must examine the package for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the packaging. Since the modules do not enforce an access control mechanism before the module is initialized, the end-user must maintain control of the module at all times until the iSTAR eX Controller has been installed and sealed with tamper- evident stickers. 2.9 Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 level 2 requirements for this validation. Software House iSTAR eX Controller Page 21 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 3 Secure Operation The iSTAR eX Controller meets Level 2 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-approved mode of operation. 3.1 Installation It is the responsibility of the end-user to ensure that the module is properly mounted, and that the power and Ethernet cables are properly connected. The iSTAR eX hardware does not include mounting hardware for an installation. Mounting hardware depends upon the site and must be approved by a structural engineer or other certified professional. All installation activities not performed directly by the end-user (including the removal of punch-out holes from the module and the securing of punch-out openings after connections are made) must be performed by a certified professional under the end-user's direct supervision. 3.2 Initial Setup When the iSTAR eX is running in FIPS mode, it goes Dark (i.e., it functions as a black box) and inhibits the following services: · ICU broadcast messages · ICU configuration · Simple Network Management Protocol · NanView - a Software House development tool · iSTAR web page When iSTAR eX is running in non-FIPS mode, these services are normally allowed. If the iSTAR eX is instructed to change from non-FIPS mode to FIPS mode, a new set of public/private keys is downloaded to the controller (Custom Host Key Management mode) or generated by the controller (Custom Controller Key Management mode) before the change occurs. For maximum protection, these services must be dynamically inhibited to prevent the private key from being accessed. The host sends a "Go Dark" message to instruct the iSTAR eX to prepare for the public/private key download or generation. A controller running in FIPS mode can be set to run in non-FIPS mode through one of three ways: · Reset the controller with clear-memory switch set. After reboot, this controller can be treated as a new controller. · On the cluster configuration screen, turn off FIPS mode. This will cause all the on-line iSTAR eX controllers within the cluster to reboot. After reboot, they will run in non-FIPS mode. · (In multi-controller cluster environments) Remove the controller from the FIPS cluster. The controller will then operate in non-FIPS mode. When entering FIPS mode, the driver notifies the iSTAR eX to "Go Dark" and to prepare to accept the private key or certificate file download. Changing from non-FIPS mode to FIPS mode or from FIPS mode to non-FIPS mode will cause all of the connected iSTAR eX controllers to reboot. Upon successful reboot, the changes will take effect. Upon booting into FIPS mode, the system will check for custom certificates. If the system does not detect a custom certificate, the system displays an error message. The cluster configuration screen stays open after selecting the button and displays the error message. Software House iSTAR eX Controller Page 22 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 3.2.1 Putting the iSTAR eX in FIPS 140-2 Mode of Operation FIPS mode can only be activated if the CCURE system is set to use custom certificates to enforce maximum security. 1. Turn on FIPS mode via the Cluster Configuration screen by selecting FIPS, then selecting OK. 2. All the on-line iSTAR eX controllers in the cluster will reboot and reconnect back to the host. 3.2.2 Setting up a Custom Certificate for FIPS Mode In FIPS mode of operation, the use of specific key management modes is required; custom certificates must be either generated by the controller (Custom Controller Management mode) or the CCURE host (Custom Host Management mode). See Figure 8 below. Figure 8 ­ Key Management Policy Screen 2.2.3.1 Setting up a Custom Controller Certificate To set up a custom controller certificate: 1. Generate CA and host certificate at the module. 2. On the "System Variable => Key Management Policy" screen of the Admin program, select the Custom Controller Certificates option. 3. The system will automatically copy and download the new custom certificates to the host. 4. Send the signing request to a designated monitoring station. 5. All communicating iSTAR eX controllers will reboot and come back using the new certificates. 6. For each cluster, change its encryption mode to FIPS. 7. The system automatically tells the controllers to run in FIPS mode. 8. Stunnel service running on the CCURE host restarts. 9. All communicating controllers reboot and come back in FIPS mode 2.2.3.2 Setting up a Custom Host Certificate To set up a custom controller certificate: Software House iSTAR eX Controller Page 23 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 1. Generate CA, host, and controller certificate. 2. On the "System Variable => Key Management Policy" screen of the Admin program, select the Custom Host Certificates option. 3. The system will automatically copy and download the new custom certificates to the host and to the controllers. 4. All communicating iSTAR eX controllers will reboot and come back using the new certificates. 5. For each cluster, change its encryption mode to FIPS. 6. The system automatically tells the controllers to run in FIPS mode. 7. Stunnel service running on the CCURE host restarts. 8. All communicating controllers reboot and come back in FIPS mode 3.2.3 Verifying FIPS Mode of Operation To see if you are operating in FIPS mode, go to Report => Hardware => iSTAR Cluster in the CCURE 800/8000 host server, and it will generate a report for you. There is a column in the generated report which will indicate in what mode the cluster is running. It will either say "non-FIPS" or "FIPS 140-" (see in Figure 9 below). Figure 9 ­ FIPS Mode Report 3.3 Crypto Officer Guidance The Crypto Officer is the person responsible for setting up, configuring, and administrating the iSTAR eX. Software House iSTAR eX Controller Page 24 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 3.3.1 Initialization The Crypto Officer must ensure that the module is properly mounted, and that the power and Ethernet cables are properly connected. All installation activities not performed by the Crypto Officer (including the removal of punch- out holes from the module and the securing of punch-out openings after connections are made) must be performed by a certified professional under the direct supervision of the Crypto Officer. Before the iSTAR eX is installed the following must be performed: · Check equipment (hardware, software, power supply, and wiring). Verify that the contents of the shipped boxes match the packing lists. Contact Software House if any items are missing or damaged. · Check power, wiring, equipment clearances and code compliance at the site. · Ensure proper tools for mounting and wiring the iSTAR eX are available. The iSTAR eX hardware does not include mounting hardware for installation. Mounting hardware depends upon the site and must be approved by a Structural Engineer or other certified professional. Software House recommends anchoring systems to a structure capable of sustaining a 75 lb. (34.1 kg) load. The iSTAR eX will need to be mounted and the power and Ethernet connected before the tamper evidence labels can be applied. The tamper-evident labels are applied across all unused punch-out holes and across the door on the front of the iSTAR eX. The following steps detail application of the labels for the iSTAR eX. 1. Ensure the system is unplugged. 2. Clean the areas to which the tamper-evident labels will be applied to remove any grease, dirt, etc. Rubbing alcohol can be used for this purpose. 3. Apply a tamper-evident label across any unused punch out holes on the sides, top, and bottom of the iSTAR eX. Make sure that about half the label is not on the punch out hole so that the label must be removed in order to punch out the hole from the casing. 4. Apply a tamper-evident label perpendicular to the seam between the door and the rest of the enclosure along the top, bottom, and side of the case. 5. Log the serial numbers of the applied labels. 6. Allow a minimum of 24 hours for the labels to cure. The Crypto Officer must periodically check the module for evidence of tampering (including unusual dents, scrapes, or damage to tamper-evident labels) and verify the tamper-evident labels still have the proper serial numbers. Additionally, the Crypto Officer should monitor logs and alerts for the module for strange activity. If indications of suspicious activity are found, the Crypto Officer should immediately take the module offline and investigate. 3.3.2 Management Management of the iSTAR eX is handled through the CCURE 800/8000 host server and the ICU. The ICU is a diagnostic tool for setting parameters on the iSTAR eX - IP address, host IP address, etc. - and it can download new firmware to the iSTAR eX. The ICU, however, is disabled in the FIPS mode of operation, so all management while in the FIPS mode of operation occurs through the CCURE 800/8000. The CCURE 800/8000 is the access control system. This is where you have a database of the personnel, doors, iSTAR eXs, panels, etc. The CCURE 800/8000 is used to set-up the rules governing access & actions. Those rules are then downloaded as a database file to the iSTAR eX so it can make its own decisions. 3.3.3 Zeroization The AES symmetric key is a temporary key and is automatically zeroized after the TLS session is terminated. The iSTAR eX's public/private RSA key pair is deleted and overwritten when a new RSA key pair is generated. Software House iSTAR eX Controller Page 25 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 3.4 User Guidance 19B The User is a human with an access control card requesting access to a controller-secured area. The User accesses the module's cryptographic functionalities. Although the User does not have any ability to modify the configuration of the module, they should check that the host application is enabled and providing cryptographic protection. Software House iSTAR eX Controller Page 26 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.7 January 4, 2008 4 Acronyms 3B Table 7 ­ Acronyms Acronym Definition AES Advanced Encryption Standard CA Certificate Authority CBC Cipher Block Chaining CMVP Cryptographic Module Validation Program CSP Critical Security Parameter EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GCM General Controller Module ICU iSTAR Configuration Utility IP Internet Protocol KAT Known Answer Test LCD Liquid Crystal Display NIST National Institute of Standards and Technology PCMCIA Personal Computer Memory Card International Association PC Personal Computer PMB Power Management Board PRNG Pseudo Random Number Generator RAM Random Access Memory RNG Random Number Generator RSA Rivest Shamir and Adleman SHA Secure Hash Algorithm SPI Serial Peripheral Interface TLS Transport Layer Security VSS Visual SourceSafe Software House iSTAR eX Controller Page 27 of 27 © 2008 Software House This document may be freely reproduced and distributed whole and intact including this copyright notice.