Vocera Communications, Inc.
Vocera Smartbadge Cryptographic Module
Firmware Version: 5.0
FIPS 140-2 Non-Proprietary Security Policy
FIPS Security Level: 1
Document Version: 0.9
Prepared for: Prepared by:
Vocera Communications, Inc. Corsec Security, Inc.
525 Race Street 13921 Park Center Road, Suite 460
San Jose, CA 95126 Herndon, VA 20171
United States of America United States of America
Phone: +1 408 882 5100 Phone: +1 703 267 6050
www.vocera.com www.corsec.com
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 2 of 24
Table of Contents
1. Introduction .........................................................................................................................................4
1.1 Purpose...................................................................................................................................................4
1.2 References ..............................................................................................................................................4
1.3 Document Organization..........................................................................................................................4
2. Smartbadge Cryptographic Module .......................................................................................................5
2.1 Overview.................................................................................................................................................5
2.2 Module Specification ..............................................................................................................................7
2.2.1 Physical Cryptographic Boundary ..............................................................................................7
2.2.2 Logical Cryptographic Boundary................................................................................................7
2.2.3 Algorithm Implementations.......................................................................................................8
2.2.4 Modes of Operation................................................................................................................ 10
2.3 Module Interfaces................................................................................................................................ 10
2.4 Roles, Services, and Authentication..................................................................................................... 12
2.4.1 Authorized Roles..................................................................................................................... 12
2.4.2 Operator Services ................................................................................................................... 12
2.4.3 Authentication ........................................................................................................................ 14
2.5 Physical Security................................................................................................................................... 14
2.6 Operational Environment .................................................................................................................... 14
2.7 Cryptographic Key Management ......................................................................................................... 14
2.8 EMI / EMC ............................................................................................................................................ 17
2.9 Self-Tests.............................................................................................................................................. 17
2.9.1 Power-Up Self-Tests................................................................................................................ 17
2.9.2 Conditional Self-Tests ............................................................................................................. 17
2.9.3 Critical Functions Self-Tests.................................................................................................... 17
2.9.4 Self-Test Failure Handling ....................................................................................................... 18
2.10 Mitigation of Other Attacks ................................................................................................................. 18
3. Secure Operation................................................................................................................................19
3.1 Secure Management............................................................................................................................ 19
3.1.1 Installation .............................................................................................................................. 19
3.1.2 Badge Configuration ............................................................................................................... 19
3.1.3 Initialization ............................................................................................................................ 20
3.2 Operator Guidance .............................................................................................................................. 20
3.2.1 Crypto Officer Guidance ......................................................................................................... 20
3.2.2 User Guidance......................................................................................................................... 21
3.2.3 General Operator Guidance.................................................................................................... 21
3.3 Additional Guidance and Usage Policies.............................................................................................. 21
4. Acronyms ...........................................................................................................................................22
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 3 of 24
List of Tables
Table 1 – Security Level per FIPS 140-2 Section.........................................................................................................6
Table 2 – FIPS-Approved Algorithms..........................................................................................................................9
Table 3 – Allowed Algorithms.................................................................................................................................. 10
Table 4 – Interface Mappings.................................................................................................................................. 11
Table 5 – Mapping of Operator Services to Inputs, Outputs, CSPs, and Type of Access ........................................ 12
Table 6 – Cryptographic Keys, Cryptographic Key Components, and CSPs............................................................. 15
Table 7 – Acronyms ................................................................................................................................................. 22
List of Figures
Figure 1 – Vocera V5000 Smartbadge........................................................................................................................5
Figure 2 – Vocera Data Aggregation Mapping ...........................................................................................................6
Figure 3 – VSCM Cryptographic Boundaries...............................................................................................................8
Figure 4 – Vocera V5000 Smartbadge Buttons........................................................................................................ 11
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 4 of 24
1. Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the Vocera Smartbadge Cryptographic Module
from Vocera Communications, Inc. (Vocera). This Security Policy describes how the Vocera Smartbadge
Cryptographic Module meets the security requirements of Federal Information Processing Standards (FIPS)
Publication 140-2, which 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) and the Canadian Centre for Cyber Security (CCCS) Cryptographic Module
Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp.
This document also describes how to run the module in a secure FIPS-Approved mode of operation. This policy
was prepared as part of the Level 1 FIPS 140-2 validation of the module. The Vocera Smartbadge Cryptographic
Module is referred to in this document as the VSCM or the module.
This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc.
under contract to Vocera.
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 (www.vocera.com) contains information on the full line of products from Vocera.
• The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-module-validation-
program/Validated-Modules/Search) can be used to locate and obtain vendor contact information for
technical or sales-related questions about the module.
1.3 Document Organization
The Security Policy document is organized into two (2) primary sections. Section 2 provides an overview of the
validated module. This includes a general description of the capabilities and the use of cryptography, as well as a
presentation of the validation level achieved in each applicable functional area of the FIPS standard. It also
provides high-level descriptions of how the module meets FIPS requirements in each functional area. Section 3
documents the guidance needed for the secure use of the module, including initial setup instructions and
management methods and policies.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 5 of 24
2. Smartbadge Cryptographic Module
2.1 Overview
The Vocera V5000 Smartbadge is a wearable communication device that enables clinician agility and accelerates
patient care. Small and lightweight (see Figure 1), the Smartbadge redefines healthcare communications by
bringing together voice calling, secure messaging, and alerts and alarms in a lightweight wearable.
Figure 1 – Vocera V5000 Smartbadge
Purpose-built for patient care, the Smartbadge is powered by the Vocera Platform, which enables data to be
aggregated from most clinical and operational systems used in hospitals today (see Figure 2). The Smartbadge
allows patient information from those systems to be presented in parallel with notifications to enable real-time
situational awareness and help reduce interruption fatigue.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 6 of 24
Figure 2 – Vocera Data Aggregation Mapping
The Vocera V5000 Smartbadge enables care team members to make/answer calls hands-free and to connect with
the right person by saying a name, role, or group name. It responds to more than 100 voice commands through
an optimized speech-recognition engine. In addition to voice activation, the touchscreen keyboard can be used to
find contacts quickly and send secure text messages. The Vocera V5000 Smartbadge also allows users to read
messages as easily as with a smartphone. Broadcast messages can easily be sent to rapid response groups, and
help can be summoned instantly via a dedicated panic button.
Communications are protected via industry-standard communications protocols including TLS1
, DTLS2
, EAP3
-TLS,
and PEAP4
. The Vocera Smartbadge Cryptographic Module is a firmware module that provides the cryptographic
primitives (including encryption/decryption, hashing, digital signature functions, and key derivation) needed to
support the secure communication services to the system. The cryptographic module is installed on the
Smartbadge, and various applications on the Smartbadge make use of the VSCM to establish secure connections
with the Vocera Server and with other Vocera communications devices.
The VSCM is validated at the FIPS 140-2 section levels shown in Table 1.
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 2
1 TLS – Transport Layer Security
2 DTLS – Datagram Transport Layer Security
3
EAP – Extensible Authentication Protocol
4 PEAP – Protected Extensible Authentication Protocol
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 7 of 24
Section Section Title Level
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A
7 Cryptographic Key Management 1
8 EMI5/EMC6 3
9 Self-Tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A7
2.2 Module Specification
The VSCM is a firmware cryptographic module with an overall security level of the module is 1. The module
consists of a firmware module based on the OpenSSL FIPS Object Module (FOM) 2.0.16 and an HMAC SHA-1 digest.
The module is compiled into object form (fipscanister.o) and then linked to an instance of the OpenSSL
cryptographic library at build-time. The larger library is then linked to the calling application. The HMAC SHA-1
digest is stored in fipscanister.o.sha1.
The module executes on a Vocera V5000 Smartbadge with an NXP i.MX 7D applications processor running Vocera’s
BadgeOS 5.0.
2.2.1 Physical Cryptographic Boundary
As a firmware cryptographic module, the module has no physical components. Physically, the module takes on
the characteristics of the host device, the V5000 Smartbadge. Thus, the physical cryptographic boundary is the
hard plastic badge enclosure, and the module is defined as having a multiple-chip standalone embodiment.
The V5000 includes an NXP i.MX 7D dual-core applications processor. This processor has two 1.2 GHz 8
ARM Cortex-A7 cores and an Arm Cortex-M4 co-processor core. The badge has 4KB9
EEPROM10
, 1GB11
of LPDDR312
SDRAM13
, and a 4GB eMMC14
.
2.2.2 Logical Cryptographic Boundary
The logical cryptographic boundary surrounds the firmware library and an HMAC SHA-1 digest. The module is
entirely contained within the physical cryptographic boundary described in Section 2.2.1. Figure 3 below shows
5 EMI – Electromagnetic Interference
6 EMC –Electromagnetic Compatibility
7 N/A – Not Applicable
8
GHz – Gigahertz
9 KB – Kilobyte
10 EEPROM – Electrically-Erasable Read-Only Memory
11 GB – Gigabyte
12 LPDDR3 – Low-Power Double Data Rate 3
13
SDRAM – Synchronous Dynamic Random Access Memory
14 eMMC – Embedded Multimedia Card
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 8 of 24
the logical block diagram of the module executing in memory and its interactions with surrounding firmware
components, as well as the module’s logical cryptographic boundary.
Figure 3 – VSCM Cryptographic Boundaries
2.2.3 Algorithm Implementations
The module implements the FIPS-Approved algorithms listed in Table 2 below.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 9 of 24
Table 2 – FIPS-Approved Algorithms
Certificate
Number Algorithm Standard Mode / Method
Key Lengths / Curves
/ Moduli
Use
C1765 AES15 FIPS PUB 197
NIST SP 800-38F
CBC16, ECB17 128, 192, 256 encryption/decryption
NIST SP 800-38B CMAC18 128, 192, 256 MAC generation/verification
NIST SP 800-38C CCM19 128, 192, 256 encryption/decryption
NIST SP 800-38D GCM20 128, 192, 256 encryption/decryption
A3124 CVL21 NIST SP 800-56Arev3 KAS-ECC CDH22
Component
B-233, B-283, B-409,
B-571, K-233, K-283,
K-409, K-571, P-224,
P-256, P-384, P-521
shared secret computation
primitive
C1765 CVL NIST SP 800-135rev1 TLS 1.2 - key derivation
No parts of the TLS protocol, other
than the KDF23, have been tested by
the CAVP or CMVP.
C1765 HMAC24 FIPS PUB 198-1 SHA-125, SHA2-256,
SHA2-384, SHA2-512
- message authentication
C1765 KTS26 NIST SP 800-38D AES-GCM 128, 192, 256 key wrapping
FIPS PUB 197
NIST SP 800-38F
FIPS PUB 198-1
AES with HMAC 128, 192, 256 key wrapping
C1765 RSA27 FIPS PUB 186-2 PKCS1.528 1024, 1536, 2048,
3072, 4096
digital signature verification
FIPS PUB 186-4 PKCS1.5 2048, 3072 digital signature verification
C1765 SHS29 FIPS PUB 180-4 SHA-1, SHA2-256,
SHA2-384, SHA2-512
- message digest
*The module does not utilize non-56Arev3-compliant functionality in the Approved mode of operation.
The module implements the non-Approved but allowed algorithms shown in Table 3.
15
AES – Advance Encryption Standard
16 CBC – Cipher Block Chaining
17 ECB – Electronic Codebook
18 CMAC – Cipher-based Message Authentication Code
19
CCM – Counter with CBC-MAC
20 GCM – Galois/Counter Mode
21 CVL – Component Validation List
22 KAS-ECC CDH – Key Agreement Scheme - Elliptic Curve Cryptography Cofactor Diffie-Hellman
23
KDF – Key Derivation Function
24 HMAC – (keyed-) Hashed Message Authentication Code
25 SHA – Secure Hash Algorithm
26 KTS – Key Transport Scheme
27 RSA – Rivest Shamir Adleman
28
PKCS – Public Key Cryptography Standard
29 SHS – Secure Hash Standard
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 10 of 24
Table 3 – Allowed Algorithms
Algorithm Caveat Use
RSA key establishment methodology provides
between 112 and 152 bits of encryption
strength
key encryption and decryption
The RSA algorithm may be used by the calling
application for encryption or decryption of keys. No
claim is made for NIST SP 800-56Brev2 compliance,
and no CSPs are established into or exported out of
the module using these services.
2.2.4 Modes of Operation
Upon successful completion of the module’s power-up self-tests, the module operates in the Approved mode of
operation. Further, when following all installation, configuration, and initialization guidance provided in this
Security Policy, the module does not support a non-Approved mode of operation.
2.3 Module Interfaces
The module interfaces exist at the module’s logical cryptographic boundary. Thus, while included here for
completeness, the Vocera V5000 Communications Badge is not within the logical boundary of the cryptographic
module, and the module’s interfaces are not implemented at this boundary. Only the components within the
logical boundary illustrated in Figure 3 above comprise the module, and it is at this boundary where the module’s
interfaces are implemented.
The module’s physical boundary features the physical interfaces of a host badge. Those interfaces are as follows:
• 2.4-inch touchscreen
• Buttons (see Figure 4 below)
• Speaker
• Microphone array
• LEDs30
• USB-C headset/charging port
• Bluetooth/WLAN31
unit
30
LED – Light-Emitting Diode
31 WLAN – Wireless Local Area Network
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 11 of 24
Up
Volume
Button
Down
Volume
Button
DND/Hold
Button
Panic
button
(inset)
Call
Button
Figure 4 – Vocera V5000 Smartbadge Buttons
The badge’s physical interfaces (manual controls, physical indicators, and physical ports) map to logical interfaces
supported by the module. The module’s logical interfaces are at a low level in the firmware. The module isolates
communications to logical interfaces that are defined in the firmware as an API32
. The API is mapped to the
following four logical interfaces:
• Data Input
• Data Output
• Control Input
• Status Output
Table 4 below provides a mapping of the physical (i.e. badge) and logical (i.e. module) interfaces to the appropriate
interface category.
Table 4 – Interface Mappings
Interface Category Physical Interface Logical Interfaces
Data Input Touchscreen, Microphone array, USB-C
Headset/charging port, Bluetooth/WLAN unit
Function calls that accept, as their arguments,
data to be used or processed by the module.
Data Output Touchscreen, Speaker, USB-C Headset/charging
port, Bluetooth/WLAN unit
Arguments for a function that specify where the
result of the function is stored or returned as a
return value.
32 API – Application Programming Interface
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 12 of 24
Interface Category Physical Interface Logical Interfaces
Control Input Touchscreen, Call button, Hold/DND button
(Hold to power-off), Up/Down volume buttons,
USB-C Headset/charging port, Panic button
Function calls utilized to initiate the module and
the function calls used to control the operation of
the module.
Status Output Touchscreen, LED, USB-C Headset/charging
port
Return values for function calls
Power Input USB-C headset/charging port N/A
2.4 Roles, Services, and Authentication
The sections below describe the module’s authorized roles, services, and operator authentication methods.
2.4.1 Authorized Roles
The module is a library that provides cryptographic functions to calling applications, and the applications that link
to the module are considered the module “operators”. There are two roles supported the module that operators
may assume: a Crypto-Officer (CO) role and a User role. The module supports role-based authentication, and roles
are assumed explicitly based on the login credentials.
As a shared library, the module provides cryptographic functions to multiple calling applications simultaneously,
all executing as different processes under different process IDs assigned by the operating system. The module
can service multiple processes; however, the module only allows one operator per process at any given time.
Separation of roles and services across multiple processes is maintained via the process and memory management
functions of the underlying operating system.
2.4.2 Operator Services
Descriptions of the services available are provided in Table 5 below. Please note that the keys and Critical Security
Parameters (CSPs) listed in the table indicate the type of access required using the following notation:
• R – Read: The CSP is read.
• W – Write: The CSP is established, generated, modified, or zeroized.
• X – Execute: The CSP is used within an Approved or Allowed security function or authentication
mechanism.
Table 5 – Mapping of Operator Services to Inputs, Outputs, CSPs, and Type of Access
Service
Operator
Description Input Output CSP and Type of Access
CO User
Initialize   Perform initialization of
the module
API call
parameters
Status CO-AD digest – RX
User-AD digest – RX
Run self-test on-
demand
  Perform power-up self-
tests
API call
parameters
Status None
Show status   Return the current
mode of the module
API call
parameters
Status None
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 13 of 24
Service
Operator
Description Input Output CSP and Type of Access
CO User
Zeroize   Zeroize and de-allocate
memory containing
sensitive data
Power cycle;
unload module
None AES key – W
AES CMAC key –W
AES GCM key – W
AES GCM IV – W
HMAC key – W
RSA public key – W
RSA private key – W
Import random
value
  Retrieve and return the
specified number of
random bits from
external source
API call
parameters
Status,
random bits
None
Generate
message digest
  Compute and return a
message digest using
SHS algorithms
API call
parameters,
message
Status, hash None
Generate keyed
hash (HMAC)
  Compute and return a
message authentication
code
API call
parameters, key,
message
Status, hash HMAC key – RX
Generate
symmetric digest
(CMAC)
  Compute and return a
cipher message
authentication code
API call
parameters, key,
message
Status, hash AES CMAC key – RX
Perform
symmetric
encryption
  Encrypt plaintext using
supplied AES key
API call
parameters, key,
plaintext
Status,
ciphertext
AES key – RX
Perform
symmetric
decryption
  Decrypt ciphertext
using supplied AES key
API call
parameters, key,
ciphertext
Status,
plaintext
AES key – RX
Perform
authenticated
symmetric
encryption
  Encrypt plaintext using
supplied AES GCM key
and IV
API call
parameters, key,
plaintext
Status,
ciphertext
AES GCM key – RX
AES GCM IV – RX
Perform
authenticated
symmetric
decryption
  Decrypt ciphertext
using supplied AES
GCM key and IV
API call
parameters, key,
ciphertext
Status,
plaintext
AES GCM key – RX
AES GCM IV – RX
Get asymmetric
key pair
  Retrieve and return
random values to be
used as an RSA key pair
API call
parameters
Status, key
pair
RSA public key – W
RSA private key – W
Calculate key
agreement
primitive
  Calculate ECC CDH key
agreement primitive
API call
parameter
Status, key
components
ECC CDH public component – WRX
ECC CDH private component – WRX
Perform public
key encryption
  Perform asymmetric
encryption
API call
parameter
Status,
ciphertext
RSA public key – RX
Perform private
key decryption
  Perform asymmetric
decryption
API call
parameter
Status,
plaintext
RSA private key – RX
Verify signature   Verify a digital
signature
API call
parameters, key,
signature,
message
Status RSA public key – RX
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 14 of 24
Service
Operator
Description Input Output CSP and Type of Access
CO User
Establish TLS
master secret
  Establish and return TLS
master secret
API call
parameters, pre-
master secret
Status, TLS
keys
TLS pre-master secret – RX
TLS master secret – W
Establish TLS keys   Establish and return TLS
session and integrity
keys
API call
parameters,
master secret
Status, TLS
keys
TLS master secret – RX
TLS session key – W
TLS integrity key – W
NOTE: The module itself does not generate random numbers. Rather, the module fulfills such requests from calling applications by importing random numbers
generated by a DRBG and entropy source on the NXP i.MX 7D processor (both of which are outside the module’s logical boundary).
2.4.3 Authentication
The module supports role-based authentication. As the module’s only operator, the calling application explicitly
assumes the CO or User role by passing the appropriate password to the FIPS_module_mode_set() function.
The password values are specified at build-time and have a minimum length of 16 characters. Any attempt to
authenticate with an invalid password will result in an immediate and permanent failure condition, rendering the
module unable to enter the FIPS mode of operation, even with subsequent use of a correct password.
Authentication data is loaded into the module during the module build process and otherwise cannot be accessed.
The minimum password length is 16 characters, and each character can be any one of the 256 characters in the
ASCII character set. For each attempt to use the authentication mechanism, the probability of a random successful
attempt will succeed or a false acceptance will occur is 1/256^16, which is less than 1/10^6. The module
permanently disables further authentication attempts after a single failure.
2.5 Physical Security
The VSCM is a multiple-chip standalone firmware module. The module runs on a Vocera V5000 Smartbadge
consisting of production-grade components that include standard passivation techniques. The module is entirely
contained within the hard plastic badge enclosure, which blocks physical access to the module.
2.6 Operational Environment
The module does not provide a general-purpose OS to the user. The module executes on a Vocera V5000
Smartbadge running Vocera’s BadgeOS 5.0 (based on Linux kernel version 4.9.11).
The module is not intended to operate on any platform other than the Vocera V5000 Smartbadge, and the module
does not provide operators with any means to modify software/firmware components or to load and execute
software/firmware that was not included as part of the validation of the module. This constitutes a non-modifiable
operational environment.
2.7 Cryptographic Key Management
The module supports the CSPs listed below in Table 6.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 15 of 24
Table 6 – Cryptographic Keys, Cryptographic Key Components, and CSPs
CSP CSP Type Generation / Input Output Storage Zeroization Use
AES key 128, 192, 256-bit AES key Input via API call
parameter
Never exits the module Not persistently stored Unload module; Remove
power
Encryption and
decryption
AES CMAC key 128-bit AES CMAC key Input via API call
parameter
Never exits the module Not persistently stored Unload module; Remove
power
MAC generation and
verification
AES GCM key 128, 192, 256-bit AES GCM
key
Input via API call
parameter
Never exits the module Not persistently stored Unload module; Remove
power
Encryption and
decryption
AES GCM IV33 96-bit value Generated internally,
deterministically in
compliance with TLS 1.2
GCM Cipher Suites for
TLS and Section 8.2.1 of
NIST SP 800-38D
Never exits the module Not persistently stored Unload module; Remove
power
Initialization vector for
AES GCM
HMAC key 160, 224, 256, 384, or 512-
bit HMAC key
Input via API call
parameter
Never exits the module Not persistently stored Unload module; Remove
power
Message authentication
with SHA
RSA private Key 2048, 3072, 4096-bit RSA
key
Input via API call
parameter
Output in plaintext Not persistently stored Unload module; Remove
power
Decryption
RSA public key 2048, 3072, 4096-bit RSA
key
Input via API call
parameter
Output in plaintext Not persistently stored Unload module; Remove
power
Encryption
1024, 1536, 2048, 3072,
4096-bit RSA key
Input via API call
parameter
Output in plaintext Not persistently stored Unload module; Remove
power
Signature verification
ECC CDH private
component
All FIPS-Approved P/B/K-
curves
Input via API call
parameter
Output in plaintext Not persistently stored Unload module; Remove
power
Shared secret generation
ECC CDH public
component
All FIPS-Approved P/B/K-
curves
Input via API call
parameter
Output in plaintext Not persistently stored Unload module; Remove
power
Shared secret generation
TLS pre-master secret 384-bit random value Input via API call
parameter
Never exits the module Not persistently stored Unload module; Remove
power
Derivation of the TLS
master secret
TLS master secret 384-bit shared secret Derived internally using
the TLS pre-master
secret via TLS KDF
Output in plaintext Not persistently stored Unload module; Remove
power
Derivation of the TLS
session key and TLS
authentication key
TLS session key 128-bit AES key Derived internally using
the TLS master secret via
TLS KDF
Output in plaintext Not persistently stored Unload module; Remove
power
Encryption and
decryption of TLS session
packets
33 IV – Initialization Vector
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 16 of 24
CSP CSP Type Generation / Input Output Storage Zeroization Use
TLS integrity key 160-bit (minimum) HMAC
key
Derived internally using
the TLS master secret via
TLS KDF
Output in plaintext Not persistently stored Unload module; Remove
power
Authentication of TLS
session packets
CO-AD digest 20 bytes based on the 16-
character (minimum) string
Pre-calculated HMAC
SHA-1 digest used for
Crypto Offcer role
authentication, loaded
into the module during
the module build process
Never exits the module Not persistently stored Not needed since it is
protected stored by an
Approved Algorithm
(#C1765).
Crypto Officer
authentication
User-AD digest 20 bytes based on the 16-
character (minimum) string
Pre-calculated HMAC
SHA-1 digest used for
User role authentication,
loaded into the module
during the module build
process
Never exits the module Not persistently stored Not needed since it is
protected stored by an
Approved Algorithm
(#C1765).
User authentication
The module provides AES-GCM services to a calling application in support of TLS 1.2 communications and supports acceptable GCM cipher suites from section
3.3.1 of NIST SP 800-52rev2.
The module follows the TLS 1.2 protocol GCM IV generation method from section A.5 of the FIPS 140-2 Implementation Guidance. In compliance with RFC 5288,
the 96-bit AES-GCM IV consists of 32-bit name field and a 64-bit counter field. If the counter field exhausts the maximum number of possible values for a given
key, then the calling application must trigger a new handshake to establish a new encryption key.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 17 of 24
2.8 EMI / EMC
The module is a firmware module whose target platform is a Vocera V5000 Smartbadge, which is considered a
radio device. The Vocera V5000 Smartbadge was independently tested by Intertek Testing Services NA, Inc.
(accredited by the A2LA under certificate number 1455.01) and was awarded FCC ID QGZV5000.
Additionally, the badge has been tested and found to comply with the limits for a Class B digital device, pursuant
to Part 15 of the FCC rules.
2.9 Self-Tests
Cryptographic self-tests are performed automatically by the module when the module is first powered up and
loaded into memory. Additionally, these tests can be performed on demand via removal and re-insertion of the
Smartbadge battery or by unloading and reloading the module for execution. The following sections list the self-
tests performed by the module, their expected error status, and error resolutions.
2.9.1 Power-Up Self-Tests
The module performs the following FIPS-required self-tests automatically at module power-up:
• Firmware Integrity Check using HMAC SHA-1
• Known Answer Tests (KATs)
o AES CBC encrypt and decrypt KATs
o AES ECB encrypt and decrypt KATs
o AES CMAC KAT
o AES-CCM encrypt and decrypt KATs
o AES-GCM encrypt and decrypt KATs
o HMAC KATs for SHA2-256, SHA2-384, and SHA2-512
o RSA signature verification KAT
o ECC CDH Primitive “Z” Computation KAT
The SHA-1 implementation is fully tested by the module’s HMAC SHA-1 power-up integrity test. The SHA2-256,
SHA2-384, and SHA2-512 implementations are fully tested by the module’s HMAC SHA2-256, HMAC SHA2-384,
and HMAC SHA2-512 power-up KATs. Thus, as allowed per section 9.2 of the Implementation Guidance for FIPS
PUB 140-2 and the CMVP, no independent KATs are needed for the module’s SHA implementations
2.9.2 Conditional Self-Tests
The module requires no conditional self-tests.
2.9.3 Critical Functions Self-Tests
The module includes no critical functions self-tests.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 18 of 24
2.9.4 Self-Test Failure Handling
If any self-test fails during module power-up, the module will enter a critical error state. An internal global error
flag FIPS_selftest_fail is set and subsequently tested to prevent the invocation of any cryptographic
function calls. The module can only recover from the critical error state by unloading and reloading the module or
power-cycling the Smartbadge and passing all power-up self-tests.
If this recovery method does not result in the successful execution of the power-up self-tests, then the module
will not be able to resume normal operations, and the CO should contact Vocera Communications, Inc. for
assistance.
If a power-up self-test fails when performed on-demand via API call, the module will enter a soft error state and
provide a failure status indication to the calling application. Provision of the status indicator will automatically
clear the error state. It is the responsibility of the calling application to take proper action in response to the status
indication.
2.10 Mitigation of Other Attacks
This section is not applicable. The modules do not claim to mitigate any attacks beyond the FIPS 140-2 Level 1
requirements for this validation.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 19 of 24
3. Secure Operation
The sections below describe how to ensure that the module is operating in its validated configuration. Operating
the module without following the guidance herein (including the use of undocumented services) will result in
non-compliant behavior and is outside the scope of this Security Policy.
Please note that the Vocera Smartbadge Cryptographic Module is not delivered to end-users as a standalone
offering. Rather, it is an integrated component of the Vocera V5000 Smartbadge application firmware. The
application firmware is pre-installed onto the Smartbadge at the factory hardware prior to delivery to end-users.
Vocera does not provide end-users with any mechanisms to directly access the module or its APIs.
3.1 Secure Management
The following paragraphs describe the steps necessary to ensure that the Vocera Smartbadge Cryptographic
Module is running in its validated configuration.
3.1.1 Installation
The module is part of a product application package that is factory-installed. Thus, the module has no independent
installation steps that end-users must follow.
3.1.2 Badge Configuration
While the module requires no configuration, the Smartbadge must be configured to support the use of the module.
The CO must enable FIPS support on the Vocera V5000 Smartbadge by updating a badge configuration file called
“badge.properties”. This update is accomplished using the following utilities:
• Badge Properties Editor (BPE) – for settting values for badge properties so the Vocera badges can
connect to the wireless network. .
• Badge Configuration Utility (BCU) – for downloading the badge properties, as well as any firmware
upgrades, to Vocera badges.
These utilities are installed on Vocera Voice Servers and on standalone configuration computers. To enable FIPS
support on the V5000 Smartbadge, the CO shall perform the following tasks (if performing initial badge
configuration, use the BPE on the configuration computer):
1. Locate and double-click the Vocera BPE Launcher icon on the desktop the first time. For subsequent logins,
access the Vocera BPE Launcher using the URL http://127.0.0.1:8011/#!/, where 127.0.0.1 is the local
host, and 8011 is the Voice Server IP port for BPE.
2. The BPE user interface appears.
3. Select V5000, under “Badges”.
4. Select the Security Settings on the V5000 configuration page and check the Enable FIPS checkbox.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 20 of 24
5. Click one of the following:
a. Submit – Allows you to submit the changes.
b. Discard Changes – Allows you to discard the changes and re-enter the badge properties.
6. The Badge Properties Editor creates a badge.properties text file under \vocera\config. Badge properties
can now be uploaded to the Smartbadge.
7. Restart the server or BCU. The badge.properties file will be automatically updated upon server restart.
The badge operator must use the “FIPS” submenu on the “Badge Settings => Badge Information => Security”
screen to see the status of the FIPS Mode. At this point, “FIPS Mode Status” should display that it is set to “On”
without operator intervention. The version will display as “Vocera Smartbadge Cryptographic Module 5.0”.
3.1.3 Initialization
The module has a defined default entry point (DEP) containing code that the OS loader executes automatically
when the library is loaded into memory for execution (but prior to the calling application assuming process control
over the library). When the badge is configured to enable FIPS operation, the module will begin initialization with
the verification of the operator’s password. The calling application passes the CO or User password to the module
via the FIPS_module_mode_set() function.
If the operator successfully authenticates, the module then immediately runs the power-up self-tests. Execution
of these self-tests requires no action from the operator. 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.”
Failure of any of the initialization actions will result in a failure of the module to load for execution.
Note that once the “Enable FIPS” checkbox is selected, the selectable options for several other security settings
will be limited to only those that are supported by the FIPS-Approved cryptographic methods. Further information
regarding badge configuration and the badge.properties file is available in the Vocera Device Configuration Guide
on Vocera’s online Support Portal.
3.2 Operator Guidance
The following sections provide guidance to module operators for the correct and secure operation of the module.
As it relates to this module, the calling application (acting as the module’s sole authorized operator) takes on the
role of both Crypto Officer and User.
3.2.1 Crypto Officer Guidance
Subsequent to the module’s successful initialization into FIPS Approved mode of operation, no further
management activities are required to ensure that the module runs securely; once initialized, the module only
executes in a FIPS-Approved mode of operation. However, if any irregular activity is noticed or the module is
consistently reporting errors, then the CO should contact Vocera Customer Support (support@vocera.com or 1-
888-9-VOCERA) for further assistance.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 21 of 24
3.2.2 User Guidance
The User does not have any ability to modify the configuration of the module. However, if any irregular activity is
noticed or the module is consistently reporting errors, then Vocera Customer Support should be contacted.
Users are not responsible for the badge’s configuration; this is the responsibility of the CO. Users employ the
secure communications services provided by the module. For guidance on using the Vocera V5000 Smartbadge,
please refer to the Vocera Badge User Guide. The document can be found in Vocera’s online Support Portal.
3.2.3 General Operator Guidance
The following provide further guidance for the general operation of the module:
• As a firmware module offering no physical storage media within the logical boundary, the module does
not store CSPs persistently (beyond the lifetime of an API call). When the API call is complete, zeroization
of any temporarily-stored CSPs is performed automatically by the API call itself. Additionally, any CSPs in
volatile memory can be zeroized by removing the Smartbadge’s battery or unloading the module from
memory. Any persistent key storage occurs outside the module’s logical boundary.
• To determine the module’s operational status, the FIPS_mode() API can be used. A non-zero return
value indicates that the module is running in its FIPS-Approved mode.
• To execute the module’s power-up self-tests on-demand, the module can be unloaded and reloaded into
memory, which will trigger the initiation of the self-tests. Power-cycling the Smartbadge by removing and
re-inserting the battery will also restart the module and initiate the power-up self-tests.
Additionally, the calling application can invoke the fips_selftests() API to execute the power-up
tests on-demand. A return value of “1” indicates that all self-tests completed successfully; a “0” indicates
a test failure. Upon receiving a failure indication, the calling application shall unload and reload the
module to trigger a full re-initialization of the module.
3.3 Additional Guidance and Usage Policies
The notes below provide additional guidance and policies that must be followed by the calling application (acting
as the module’s sole authorized operator):
• As the module does not persistently store keys, the calling application is responsible for the storage and
zeroization of keys and CSPs passed into and out of the module.
• In the event that power to the module is lost and subsequently restored, the calling application must
ensure that any AES-GCM keys used for encryption or decryption are re-distributed.
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 22 of 24
4. Acronyms
Table 7 provides definitions for the acronyms used in this document.
Table 7 – Acronyms
Acronym Definition
AES Advanced Encryption Standard
API Application Programming Interface
CBC Cipher Block Chaining
CCCS Canadian Centre for Cyber Security
CCM Counter with Cipher Block Chaining – Message Authentication Code
CFR Code of Federal Regulations
CMAC Cipher-based Message Authentication Code
CMVP Cryptographic Module Validation Program
CO Crypto Officer
CSP Critical Security Parameter
CVL Component Validation List
DTLS Datagram Transport Layer Security
DND Do Not Disturb
DRBG Deterministic Random Bit Generator
EAP Extensible Authentication Protocol
EAPOL Extensible Authentication Protocol over Local Area Network
ECB Electronic Code Book
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
eMMC Embedded Multimedia Card
FCC Federal Communications Commission
FIPS Federal Information Processing Standard
FOM FIPS Object Module
GCM Galois/Counter Mode
HMAC Hash-based Message Authentication Code
IP Internet Protocol
KAT Known Answer Test
KDF Key Derivation Function
LAN Local Area Network
N/A Not Applicable
FIPS 140-2 Non-Proprietary Security Policy, Version 0.9 December 19, 2022
Vocera Smartbadge Cryptographic Module
©2022 Vocera Communications, Inc.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 23 of 24
Acronym Definition
NDRNG Non-Deterministic Random Number Generator
NIST National Institute of Standards and Technology
OS Operating System
PBX Private Branch Exchange
PEAP Protected Extensible Authentication Protocol
PKCS Public Key Cryptography Standard
RFC Request for Comment
RSA Rivest, Shamir, Adleman
SDRAM Synchronous Dynamic Random Access Memory
SHA Secure Hash Algorithm
SP Special Publication
TLS Transport Layer Security
VSCM Vocera Smartbadge Cryptographic Module
WLAN Wireless Local Area Network
Prepared by:
Corsec Security, Inc.
13921 Park Center Road, Suite 460
Herndon, VA 20171
United States of America
Phone: +1 703 267 6050
Email: info@corsec.com
http://www.corsec.com