Vocera Communications, Inc. Vocera Cryptographic Module Hardware Version: 88W8686 Software Version: 1.0 Firmware Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 2.0 Prepared for: Prepared by: Vocera Communications, Inc. Corsec Security, Inc. 525 Race Street 10340 Democracy Lane, Suite 201 San Jose, CA 95126 Fairfax, VA 22030 Phone: (408) 882-5100 Phone: (703) 267-6050 Fax: (408) 882-5101 Fax: (703) 267-6810 http://www.vocera.com http://www.corsec.com © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Table of Contents 1 INTRODUCTION ...............................................................................................................................................3 1.1 PURPOSE .....................................................................................................................................................3 1.2 REFERENCES ...............................................................................................................................................3 1.3 DOCUMENT ORGANIZATION ........................................................................................................................3 2 VOCERA CRYPTOGRAPHIC MODULE ......................................................................................................4 2.1 OVERVIEW ..................................................................................................................................................4 2.2 MODULE INTERFACES .................................................................................................................................6 2.3 ROLES AND SERVICES .................................................................................................................................8 2.3.1 Crypto-Officer Role .......................................................................................................................8 2.3.2 User Role .......................................................................................................................................8 2.4 PHYSICAL SECURITY ...................................................................................................................................9 2.5 OPERATIONAL ENVIRONMENT .................................................................................................................. 10 2.6 CRYPTOGRAPHIC KEY MANAGEMENT ...................................................................................................... 10 2.7 SELF-TESTS ............................................................................................................................................... 13 2.8 MITIGATION OF OTHER ATTACKS ............................................................................................................. 13 3 SECURE OPERATION .................................................................................................................................... 14 3.1 INITIAL SETUP ........................................................................................................................................... 14 3.2 CRYPTO-OFFICER GUIDANCE .................................................................................................................... 15 3.2.1 Management................................................................................................................................. 15 3.2.2 Zeroization ................................................................................................................................... 16 3.3 USER GUIDANCE ....................................................................................................................................... 16 4 ACRONYMS...................................................................................................................................................... 17 Table of Figures FIGURE 1 ­ TYPICAL VOCERA COMMUNICATIONS SYSTEM DEPLOYMENT .....................................................................4 FIGURE 2 ­ VOCERA B2000 COMMUNICATIONS BADGE .................................................................................................5 FIGURE 3 ­ LOGICAL CRYPTOGRAPHIC BOUNDARY .......................................................................................................6 FIGURE 4 ­ PHYSICAL FEATURES OF THE VOCERA B2000 BADGE..................................................................................7 FIGURE 5 ­ PHYSICAL BLOCK DIAGRAM OF THE MODULES TARGET DEVICE ............................................................. 10 FIGURE 6 ­ CONFIGURING THE BADGE PROPERTY FILE FOR FIPS SUPPORT ................................................................. 15 List of Tables TABLE 1 ­ SECURITY LEVEL PER FIPS 140-2 SECTION...................................................................................................5 TABLE 2 ­ INTERFACE MAPPINGS ...................................................................................................................................7 TABLE 3 ­ MAPPING OF CRYPTO-OFFICER ROLES SERVICES TO TYPE OF CSP ACCESS ................................................8 TABLE 4 ­ MAPPING OF USER ROLES SERVICES TO TYPE OF CSP ACCESS ...................................................................8 TABLE 5 ­ ALGORITHM CERTIFICATE NUMBERS FOR CRYPTOGRAPHIC LIBRARIES ..................................................... 10 TABLE 6 ­ NON-FIPS-APPROVED FUNCTIONS ............................................................................................................. 11 TABLE 7 ­ LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS..................................... 12 TABLE 8 ­ ACRONYMS ................................................................................................................................................. 17 Vocera Cryptographic Module Page 2 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Vocera Cryptographic Module from Vocera Communications, Inc.. This Security Policy describes how the Vocera Cryptographic Module meets the security requirements of Federal Information Processing Standard (FIPS) Publication 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 details the U.S. and Canadian government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/groups/STM/index.html. The Vocera Cryptographic Module is referred to in this document as cryptographic module, hybrid module, 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 Vocera website (http://www.vocera.com) contains information on the full line of products from Vocera. The CMVP website (http://csrc.nist.gov/groups/STM/index.html) 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 Executive Summary Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Vocera. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Vocera and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Vocera. Vocera Cryptographic Module Page 3 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 2 Vocera Cryptographic Module 2.1 Overview The Voceraź Communications System is a breakthrough wireless platform that provides hands-free voice communications throughout an 802.11b/g-networked building or campus. The Vocera Communications System consists of two key components: The Vocera System Software, which runs on a standard Windows server, controls and manages call activity. The Vocera B2000 Communications Badge allows users to converse over a Wireless Local Area Network (WLAN). A typical Vocera system deployment is shown in Figure 1 below. Figure 1 ­ Typical Vocera Communications System Deployment The Vocera B2000 Communications Badge (see Figure 2) is a small, virtually hands-free wireless device that acts as the interface to the Vocera Communications System. The wearable badge is controlled using voice commands, and enables instant two-way voice conversation, text messaging, and alerts. The badge communicates with other Vocera communications devices or with the Vocera System Software server (typically referred to as the Vocera Server) securely over a protected channel. With optional Vocera telephony solution software, the badge can also make and receive telephone calls through the Vocera Server via a private branch exchange (PBX). The badge employs a high- performance antenna for improved transmit and receive sensitivity. Vocera Cryptographic Module Page 4 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Figure 2 ­ Vocera B2000 Communications Badge Communications are protected via industry-standard secure wireless communications protocols. The security functionality is provided by the Vocera Cryptographic Module (VCM) embedded in the badge. Various applications on the Vocera badge make use of the VCM to establish a secure connection with the Vocera Server and with other Vocera communications devices. All cryptographic services needed by the badge are provided by the VCM. For FIPS purposes, the VCM has been evaluated as a hybrid cryptographic module. A hybrid module is a special type of software/firmware module that makes use of specialized hardware components within the physical boundary of the target device. In this case, the VCM is composed of software libraries running on a Texas Instruments (TI) applications processor (OMAP5912), firmware running on a high-performance Marvell WLAN chip (part number 88W8686), and all of the required components are contained within the Vocera badge. The hybrid module software was tested on a Vocera B2000 badge using Vocera Embedded Linux Version 1.0 running on a Texas Instruments OMAP5912 (single-user mode). Versioning for the modules components is as follows: Hardware: 88W8686 Software: 1.0 Firmware: 1.0 The Vocera Cryptographic Module is validated at the following FIPS 140-2 Section levels: Table 1 ­ Security Level per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security 1 6 Operational Environment 1 7 Cryptographic Key Management 1 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 1 EMI/EMC ­ Electromagnetic Interference / Electromagnetic Compatibility Vocera Cryptographic Module Page 5 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Section Section Title Level 2 11 Mitigation of Other Attacks N/A 14 Cryptographic Module Security Policy 1 2.2 Module Interfaces The Vocera Cryptographic Module is a hybrid module that meets overall Level 1 FIPS 140-2 requirements. All of the modules components are entirely encapsulated by the logical cryptographic boundary as shown in Figure 3 below. Figure 3 below shows that the hybrid module includes software libraries running on the applications processor and firmware running on the WLAN chip all residing inside the logical cryptographic boundary. SDRAM Badge Applications TI OMAP5912 Other Hardware Applications Processor (w/ Software Libraries) Marvell 88W8686 WLAN Chip (w/ Firmware) Vocera Badge Logical Cryptographic Boundary KEY: Control/Status Data SDRAM ­ Synchronous Dynamic Random Plaintext Data Access Memory Ciphertext Data Figure 3 ­ Logical Cryptographic Boundary As is required by the FIPS 140-2 Implementation Guidance, the modules interfaces are provided only via the software component of the module. Thus, the hybrid modules interfaces consist solely of the available APIs. The APIs are grouped into four logically distinct FIPS 140-2 categories: Data Input Data Output Control Input Status Output The target platform for the module is a Vocera Communications B2000 Badge. As such, the VCMs logical interfaces described above map to the physical ports and interfaces provided by the badge. Those ports and interfaces are: Badge display Buttons (Call button, hold/DND3 button, and menu buttons) 2 N/A ­ Not applicable 3 DND ­ Do Not Disturb Vocera Cryptographic Module Page 6 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Speaker Microphone Indicator light Headset jack Wireless Local Area Network (WLAN) interface (not exposed on the badge cover) Contact pins NOTE: While included here for completeness, the entire Vocera B2000 Badge is not within the boundary of the cryptographic module described in this policy document. Only the components as illustrated in Figure 3 comprise the module. The physical features of the badge are also shown in Figure 4 below. Figure 4 ­ Physical Features of the Vocera B2000 Badge The data and control inputs made via the badge microphone, WLAN, and buttons are translated into the logical data and control inputs made via the API calls to the hybrid module. Likewise, the data and status outputs made via API call returns from the hybrid module are translated into the data and status outputs made to the WLAN, badge display, speaker, and indicators. Table 2 below provides a mapping of the physical (i.e. badge) and logical (i.e. module) interfaces to the appropriate interface category. Table 2 ­ Interface Mappings Interface Category Physical Interface Logical Interface Data Input WLAN, Microphone, headset Jack Function calls that accept, as their arguments, data to be used or processed by the module. Data Output WLAN, Headset Jack, Speaker (i) Arguments for a function that specify where the result of the function is stored or (ii) returned as a return value. Vocera Cryptographic Module Page 7 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Interface Category Physical Interface Logical Interface Control Input WLAN (for roaming), Call Button, Function calls utilized to initiate the DND Button (Hold to power-off), module and the function calls used Select Button, and Contact Pins to control the operation of the (power to the module) module. Status Output Badge Display Screen Return values for function calls 2.3 Roles and Services The module does not support authentication of operators. There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto-Officer (CO) role and User role. The module does not require an operator to authenticate; role of the operator is implicitly assumed. 2.3.1 Crypto-Officer Role The Crypto-Officer role has the ability to manage the module and monitor the status. Descriptions of the services available to the Crypto-Officer role are provided in the table below. Table 3 also lists the Critical Security Parameters (CSPs) that are accessed by the services, as well as the module component that provides the service. Table 3 ­ Mapping of Crypto-Officer Role's Services to Type of CSP Access Service Description Type of CSP Access Provided By Perform Self-test Run self-tests at power-up or None Software libraries on-demand Show status Monitor status None Software libraries 2.3.2 User Role The User role is used to secure communication services. Descriptions of the services available to the User role are provided in Table 4. The table also lists the CSPs that are accessed by the services, as well as the module component that provides the service. Table 4 ­ Mapping of User Role's Services to Type of CSP Access Service Description Type of CSP Access Provided By Initiate crypto operation Creates an environment to None Software libraries carry out cryptographic operation Generate random number Generate random bytes ANSI X9.31 PRNG seed ­ Software libraries 4 based on ANSI X9.31 Read, write, execute Appendix A.2.4. ANSI X9.31 PRNG key ­ Read, execute 5 EAPOL -Key Message Format EAPOL-Key 802.11i Pairwise Master Key Software libraries operations message (PMK) ­ Read, execute 6 EAPOL operation Transmit and receive EAP 802.11i PMK ­ Read, write, Software libraries messages using EAPOL execute 4 ANSI ­ American National Standards Institute 5 EAPOL ­ Extensible Authentication Protocol Over LAN (Local Area Network) 6 EAP ­ Extensible Authentication Protocol Vocera Cryptographic Module Page 8 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Service Description Type of CSP Access Provided By Four-way handshake Process four-way 802.11i PMK ­ Read, execute Software libraries handshake 802.11i Temporal Key ­ Write, execute 7 HMAC operation Generate HMAC value HMAC key ­ Read, execute Software libraries Protected EAP (PEAP) Perform PEAP operation RSA public key ­ Read, Software libraries operation execute 8 TLS Authentication Key ­ Execute TLS Session Key ­ Execute 802.11i PMK ­ Read, write, execute ANSI X9.31 PRNG seed ­ Execute ANSI X9.31 PRNG key ­ Execute Hashing operation Generate SHA-1 digest None Software libraries TLS operation Perform TLS operation TLS Authentication Key ­ Software libraries Write, execute TLS Session Key ­ Write, execute Zeroization Zeroize keys utilized by the RSA Public Key - Execute Software libraries module TLS Authentication Key - Execute TLS Session Key - Execute 802.11i PMK - Execute 802.11i Temporal Key - Execute HMAC Key - Execute AES Key - Execute ANSI X9.31 PRNG Seed - Execute ANSI X9.31 PRNG Key - Execute 2.4 Physical Security The Vocera Cryptographic Module is a hybrid module, which in FIPS terminology is a multi-chip standalone embodiment. The module consists of production-grade components that include standard passivation techniques, meeting Level 1 requirements. Further, while the module has no enclosure of its own, it is intended to run on the Vocera Communications B2000 Badge. Thus, while the badge case is not a part of the module, the module is also protected by the hard plastic cover of the Vocera badge, which surrounds all the modules hardware, software, and firmware components. A physical block diagram of the target device is shown in Figure 5 below. 7 HMAC ­ (Keyed-) Hash Message Authentication Code 8 TLS ­ Transport Layer Security Vocera Cryptographic Module Page 9 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Battery Contact pin Power management RTC WLAN chip Key matrix (5 keys) Display board Applications processor connector SDRAM Amplifier Audio CODEC MIC connector FLASH External speaker Headset jack connector Badge Enclosure KEY: Control Input / Status Output CODEC ­ Coder/Decoder MIC - Microphone Plaintext Data RTC ­ Real-Time Clock Ciphertext Data Figure 5 ­ Physical Block Diagram of the Module's Target Device 2.5 Operational Environment The module is intended for use on a Vocera B2000 badge using Vocera Embedded Linux Version 1.0 running on a Texas Instruments OMAP5912. For FIPS 140-2 compliance, this is considered to be a single-user operational environment due to the fact that only one operator can be in possession of a given Vocera badge (which hosts the module) at any given time. The module is not intended to operate on any platform other than the Vocera badge. As such, all keys, intermediate values, and other CSPs remain only in the process space of the operator using the module. The operating system uses its native memory management mechanisms to ensure that outside processes cannot access the process space used by the module. 2.6 Cryptographic Key Management The Vocera Cryptographic Module implements the following FIPS-Approved or allowed algorithms listed in Table 5. Table 5 ­ Algorithm Certificate Numbers for Cryptographic Libraries Approved or Allowed Security Function Certificate Number AES 128-, 192-, 256-bit in Cipher-Block Chaining (CBC) 980 9 10 AES 128-bit in ECB and CCM 835 SHA-1 950 HMAC using SHA-1 551 9 ECB ­ Electronic Code Book 10 CCM ­ Counter with Cipher Block Chaining-Message Authentication Code Vocera Cryptographic Module Page 10 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Approved or Allowed Security Function Certificate Number ANSI X9.31 Appendix A.2.4 PRNG 556 11 RSA 1024-, 1536-, 2048-bit encryption/decryption for key transport N/A The module also implements the following non-FIPS-Approved algorithms listed below. Note that these algorithms are used only as underlying algorithms within the TLS communications protocol, and as such, are allowed for use per FIPS Implementation Guidance D.2. Table 6 ­ Non-FIPS-Approved Functions Non-FIPS-Approved Function Certificate Number HMAC Message Digest 5 (MD5) N/A MD5 N/A The module supports the critical security parameters listed in Table 7: 11 Caveat: key wrapping; key establishment methodology provides between 80 and 112 bits of encryption strength. Vocera Cryptographic Module Page 11 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Table 7 ­ List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Output Storage Zeroization Use HMAC Integrity HMAC SHA-1 key Hard-coded in the Never exits the Hard-coded in the Replacing the HMAC SHA-1-based Test Key module module module in plaintext software libraries module self-integrity test RSA Public Key RSA 1024-, 1536-, Externally generated; Never exits the Reside on volatile Power cycle or after Key transport during TLS 2048-bit public key automatically sent to module memory only in the TLS session is handshake for PEAP the module plaintext closed phase 1 TLS Authentication HMAC SHA-1 key Internally generated Encrypted during TLS Reside on volatile Power cycle or after Data authentication for Key handshake memory only in the TLS session is TLS sessions for PEAP plaintext closed phase 2 TLS Session Key AES 128-bit key Internally generated Encrypted during TLS Reside on volatile Power cycle or after TLS session handshake memory only in the TLS session is Encryption/Decryption of plaintext closed authentication related messages in PEAP phase 2 802.11i Pairwise 256-bit shared For Pre-shared: Never exits the Reside on volatile Power cycle or after Partial input to construct Master Key secret externally generated; module memory only in the 802.11i session 802.11i Temporal Key enters the module in plaintext is closed used in 802.11i protocol plaintext For PEAP: internally generated 802.11i Temporal AES 128-bit key Internally generated Never exits the Reside on volatile Power cycle or after Used to create secure Key module memory only in the 802.11i session tunnel for wireless data plaintext is closed transmission. HMAC Key HMAC SHA-1 key Internally generated Never exits the Reside on volatile Power cycle or after Used for Keyed-Hash module memory only in the API service is Message Authentication in plaintext terminated the module ANSI X9.31 PRNG 128-bytes of seed Internally generated Never exits the Reside on volatile Power cycle or after FIPS-Approved random Seed value module memory only in the API service is number generation plaintext terminated ANSI X9.31 PRNG AES 128-bit key Hard-coded in the Never exits the Hard-coded in the Replacing the FIPS-Approved random Key module module module in plaintext software libraries number generation Vocera Cryptographic Module Page 12 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 2.7 Self-Tests The Vocera Cryptographic Module performs the following self-tests at power-up: Software Integrity Check using HMAC SHA-1 Firmware Integrity Check using HMAC SHA-1 Known Answer Tests (KATs) o AES ECB and CCM mode KAT o AES CBC mode KAT o ANSI X9.31 Appendix A.2.4 PRNG KAT o HMAC SHA-1 (known answer test performed as part of power-up integrity test) o SHA-1 (known answer test performed as part of HMAC SHA-1 known answer test) The Vocera Cryptographic Module performs the following conditional self-tests: Continuous PRNG test (CRNGT) for FIPS-Approved random number generator The module is capable of performing on-demand self-tests via power cycle, which restarts the module. If any error occurs during the power-up self-test execution, the module enters an error state and outputs the error over the modules status output interface. If the module encounters an error during a conditional self-test, it will transition to a soft error state and attempt to clear the error on its own. Failing to clear the soft error leads the module to an error state and operator intervention is required at that point. An operator may attempt to clear a power-up or conditional self-test error by restarting the module (which requires power-cycling the host badge); however, if the error does not clear, then the Badge must be sent to Vocera for service. 2.8 Mitigation of Other Attacks The module does not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. Vocera Cryptographic Module Page 13 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 3 Secure Operation The Vocera Cryptographic Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in a FIPS-Approved mode of operation. 3.1 Initial Setup The module operates on a Vocera B2000 Badge, and uses both a general-purpose and a proprietary OS. The module inherently operates in single-user mode due to the fact that only one operator can be in possession of the Vocera badge hosting the module at any given time. While the module itself operates only in a FIPS-Approved mode of operation, the Vocera badge must be configured to support the use of the module. The Crypto-Officer is responsible for configuring the Vocera badge to make proper use of the module. The CO must enable FIPS support on the badge properties via the Vocera Software System. Instructions to manage the Vocera badge via the Vocera Software System are provided in the Vocera Badge Configuration Guide document available to the Crypto-Officer via Voceras website (http://vocera.com/documentation/default.aspx). Vocera Software System provides user-friendly utility tools and a web-based administrator console to configure and manage the entire Vocera system. Vocera badges are configured to make use of the Vocera Cryptographic Module by updating a badge configuration file called "badge.properties". This update is accomplished via a utility called the Badge Properties Editor. Instructions on updating the badge.properties file to employ the module are as follows: 1. From the Windows Start menu, choose Programs > Vocera > Badge Utilities > Badge Properties Editor. The Badge Properties Editor will appear. 2. From the Badge Type drop-down menu, choose "B2000". 3. Select the Security tab (shown in Figure 6 below) and do the following: Check the "Enable FIPS" checkbox. From the Authentication drop-down menu, select "WPA-PSK" or "WPA-PEAP". From the Encryption drop-down menu, select "AES-CCMP" Vocera Cryptographic Module Page 14 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Figure 6 ­ Configuring the Badge Property File for FIPS Support 4. Press "OK" or "Apply" to save any changes. 5. Restart the Vocera Server from the web-based administrator console as instructed in the Vocera Administration Guide. The document can be found in Voceras website (http://vocera.com/documentation/default.aspx). The badges.properties file on any connected badges will be automatically updated upon Server restart. The badge operator must use the Info Menu on the badge to see the status of FIPS Mode. At this point, FIPS Mode should display that it is set to "on" without operator intervention. The version will show "1.0". 3.2 Crypto-Officer Guidance While the Vocera badge must be configured to use the module, the module itself requires no set-up, as it only executes in a FIPS-Approved mode of operation. When the module is powered up, it runs the power-up self-tests. If the power-up self-tests complete successfully, the module is deemed to be operating in a FIPS-Approved mode of operation. Successful power-up self-tests displays the following message on the badge display screen. "Power On Self Tests successful." 3.2.1 Management The CO is also responsible for monitoring that the Vocera badges FIPS configuration is maintained by using only FIPS-Approved functions. To maintain the FIPS configuration, the CO must ensure that ,,ssh services are disabled and that only those algorithms mentioned in Section 2.6 (Cryptographic Key Management) of this document are in use. Cisco Centralized Key Management (CCKM) is also disabled in the Vocera badge by default. The CO must not enable the protocol when running the badge in its FIPS configuration. Vocera Cryptographic Module Page 15 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 NOTE: The ,,Vocera Only option from the badge menu must not be used when running the badge in its FIPS configuration. 3.2.2 Zeroization Since none of the cryptographic keys are stored persistently, they can be zeroized from SDRAM by simply powering off the Vocera badge. The only exception is the seed key which is hard-coded inside the module. In order to remove this key, the modules binaries must be replaced by re-applying the badge image. The CO can accomplish badge image re-application by selecting the ,,Factory Reset option from the Vocera Badge menu. Selection of this option will result in the application the badges factory image (thus zeroizing the hard-coded seed key). At this point, the badge operator will need to follow the steps provided in both the "Restoring Factory Settings" section of the Vocera Badge Configuration Guide and Section 3.1 of this Security Policy to ensure that the module is operating in its FIPS-Approved manner. 3.3 User Guidance Users employ the secure communications services provided by the module (listed in Table 4). Users are not responsible for the modules configuration. There is no specific guidance for Users, as the module always operates in a FIPS-Approved mode of operation. Vocera Cryptographic Module Page 16 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 4 Acronyms Table 8 ­ Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface CBC Cipher Block Chaining CCKM Cisco Centralized Key Management CCM Counter Mode with Cipher Block Chaining - Message Authentication Code CCMP CCM Protocol CMVP Cryptographic Module Validation Program CO Crypto-Officer CODEC Coder/Decoder CRNGT Continuous Random Number Generator Test CSP Critical Security Parameter DND Do Not Disturb EAP Extensible Authentication Protocol EAPOL Extensible Authentication Protocol Over LAN ECB Electronic Code Book EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard HMAC (Keyed-) Hash Message Authentication Code KAT Known Answer Test LAN Local Area Network MD Message Digest MIC Microphone N/A Not applicable NIST National Institute of Standards and Technology OS Operating System PBX Private Branch Exchange PEAP Protected Extensible Authentication Protocol PMK Pairwise Master Key PRNG Pseudo Random Number Generator RSA Rivest, Shamir, and Adleman RTC Real-Time Clock SDRAM Synchronous Dynamic Random Access Memory TI Texas Instruments Vocera Cryptographic Module Page 17 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 2.0 March 17, 2010 Acronym Definition TLS Transport Layer Security VCM Vocera Cryptographic Module WLAN Wireless Local Area Network Vocera Cryptographic Module Page 18 of 18 © 2010 Vocera Communications, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice.