©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 1 of 14
Comtech Mobile Datacom Corporation
Cryptographic Library
libcmscrypto
(Version 1.2.2)
FIPS 140-2
Non-Proprietary Security Policy
Level 1 Validation
Document Version 1.7
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 2 of 14
Revision History
Revision Revision Date Description of the Changes
1.0 April 8, 2009 Initial document, all sections affected
1.1 May 1, 2009 Edits and format changes
1.2 May 21, 2009 Added block diagram of the module and a list of API
functions in table 4
1.3 June 3, 2009 Added AES CFB128 encryption/decryption. Triple-DES
CBC CTS listed as non FIPS approved mode
1.4 July 6, 2009 Various updates based on lab comments
1.5 August 3, 2019 Minor compiler warning changes for 5 year anniversary
FIPS certification resubmit.
1.6 August 28, 2019 Add to section 3.2 IG A.13 security guidance update per
Leidos
1.7 October 8, 2019 Update to fig1, footer update and added Leidos comments
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 3 of 14
Table of Contents
1 INTRODUCTION............................................................................................... 5
1.1 PURPOSE................................................................................................................. 5
1.2 REFERENCES........................................................................................................... 5
1.3 DOCUMENT ORGANIZATION................................................................................... 5
2 LIBCMSCRYPTO CRYPTOGRAPHIC LIBRARY...................................... 6
2.1 OVERVIEW.............................................................................................................. 6
2.2 MODULE SPECIFICATION ........................................................................................ 6
2.3 ROLES AND SERVICES............................................................................................. 8
2.3.1 Authentication Mechanism............................................................................ 10
2.4 PHYSICAL SECURITY ............................................................................................ 10
2.5 OPERATIONAL ENVIRONMENT.............................................................................. 10
2.6 CRYPTOGRAPHIC KEY MANAGEMENT.................................................................. 10
2.6.1 Key Generation............................................................................................. 11
2.6.2 Key Storage................................................................................................... 11
2.6.3 Key Entry and Output ................................................................................... 11
2.6.4 Key Zeroization............................................................................................. 11
2.7 SELF-TESTS .......................................................................................................... 12
2.8 DESIGN ASSURANCE............................................................................................. 12
2.9 MITIGATION OF OTHER ATTACKS ........................................................................ 12
3 SECURE OPERATION.................................................................................... 12
3.1 CRYPTO-OFFICER GUIDANCE ............................................................................... 12
3.1.1 Initial Setup................................................................................................... 13
3.2 USER GUIDANCE .................................................................................................. 13
4 ACRONYMS ..................................................................................................... 14
Figures
Figure 1: Block diagram of hardware and software components ....................................... 7
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 4 of 14
Tables
Table 1: Security Level per FIPS 140-2 Section………………………………………….8
Table 2: Physical and FIPS 140-2 Logical Interfaces Mapping…………………………..8
Table 3: Services Authorized for Roles…………………………………………………...9
Table 4: Access Rights within Services…………………………………………………...9
Table 5: List of Cryptographic Keys, Cryptographic Key Components, and CSPs……..11
Table 6: Acronyms used in this document……………………………………………….14
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 5 of 14
1 INTRODUCTION
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the Comtech Mobile
Datacom Corporation Cryptographic Library (libcmscrypto), which is predominantly
used for Comtech Mobile Messaging System (CMS) applications from Comtech Mobile
Datacom Corporation. This Security Policy describes how the libcmscrypto
Cryptographic Library meets the security requirements of Federal Information Processing
Standards (FIPS) 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 (Federal Information Processing Standards Publication 140-2 – Security
Requirements for Cryptographic Modules) 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/groups/STM/cmvp/
The libcmscrypto Cryptographic Library is referred to in this document as, the
Cryptographic Library, the cryptographic 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 Comtech website (http://www.comtechmobile.com) contains information on
the full line of products from Comtech.
• The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/) 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 Model
• Other supporting documentation as additional references
This Security Policy and the other validation submission documentation were produced
by Comtech Mobile Datacom Corporation. With the exception of this Non-Proprietary
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 6 of 14
Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Comtech and
is releasable only under appropriate non-disclosure agreements. For access to these
documents, please contact Comtech.
2 LIBCMSCRYPTO CRYPTOGRAPHIC LIBRARY
2.1 Overview
The Comtech Mobile Datacom Corporation Cryptographic Library (libcmscrypto) is a
generic module that contains Application Programming Interface (API) functions used to
provide support for cryptography for the CMS network applications. All encryption and
decryption in the CMS network applications is performed through the API of the
cryptographic module.
2.2 Module Specification
The cryptographic module is the “libcmscrypto.so” library version 1.2.2, generated from
a set of C++ language source files. The module was tested and validated on Red Hat
Enterprise Linux 6.3 on qemu-kvm-0.12.1.2-2 on Red Hat Enterprise Linux 6 running on
a Dell R900 with an Intel Xeon E7450.
Comtech affirms that the module can be run unaltered on any version of Red Hat
Enterprise Linux 6.3 or higher running on an Intel or AMD processor and maintain
compliance to FIPS 140-2. However, the CMVP makes no statement as to the correct
operation of the module or the security strengths of the generated keys when so ported if
the specific operational environment is not listed on the validation certificate.
The module provides an API for invocation of FIPS approved and non-approved
cryptographic functions from the calling applications. The module does not communicate
with anything other than the process that calls it. It makes no network or inter-process
connections and creates no files.
The module is classified as multi-chip standalone cryptographic module implemented
completely in software for FIPS-140-2 purposes. The physical boundary of the
libcmscrypto Cryptographic Library for CMS is defined by the enclosure of the computer
system on which it is executing. The logical cryptographic boundary of the module is the
libcmscrypto.so file itself.
The diagram below identifies all software and hardware components
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 7 of 14
ROM RAM
CPU Peripherals
Controller
libcmscrypto.so
Input Output
Cryptographic Boundary
Physical Cryptographic Boundry
Logical Cryptographic Boundary
Ethernet
Figure 1: Block diagram of hardware and software components
The cryptographic module boundary consists of the following components1
:
• DES symmetric block cipher that uses Data Encryption Algorithm (DES)
• Triple DES (TDES) symmetric block cipher module that uses Triple Data
Encryption Algorithm (TDEA)
• AES symmetric block cipher module that uses Advanced Encryption Standard
(AES)
• SHA1 module that uses Secure Hash Algorithm (SHA1)
• HMAC SHA1 module that uses Keyed-Hashing Message Authentication Code
(HMAC)
1
See section 2.6 for a listing of which algorithms are allowed in a FIPS mode of operation
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 8 of 14
The 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 N/A
6 Operational Environment 1
7 Cryptographic Key Management 1
8 Electromagnetic Interference (EMI)/
Electromagnetic Compatibility (EMC)
1
9 Self-tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A
2.3 Roles and Services
There are two roles in the module (as required by FIPS 140-2) that operators may
assume: a Crypto-Officer role and User role. They are the operators on the Linux
Operating System on which the module is validated. The operator implicitly assumes
either role based upon the services being performed. The Crypto-Officer is responsible
for installation, initialization of the module and configuring it to run in a FIPS approved
mode. After the switch to the FIPS approved mode of operation both the Crypto-Officer
and User will be able to utilize the functionality of the module. The various services
offered by the module are described below.
Table 2: Services Authorized for Roles
Role Authorized Services
User role All services except installation and initialization
Crypto Officer role All services including installation and initialization
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 9 of 14
Table 3: Access Rights within Services
Service Role Key/CSP API functions CSP Access
Symmetric
encryption/decryption
User, Crypto-
Officer
AES, Triple-
DES key
aes_encrypt
aes_decrypt
generate_aes_subkeys
aes_encrypt_CFB128
aes_decrypt_CFB128
aes_encrypt_CBC_CT
aes_decrypt_CBC_CT
DES_block
c_DES_block
generate_c_subkeys
c_triple_DES_block
tdes_encrypt_CBC_CT
tdes_decrypt_CBC_CT
read/write/execute
Keyed Hash MAC User, Crypto-
Officer
HMAC key hmac read/write/execute
Message digest User, Crypto-
Officer
none SHA1_Init
SHA1Update
SHA1_Final
N/A
Module initialization
and installation
Crypto-Officer none get_versions
get_fips_mode
fips_mode_set
N/A
Show status Crypto-Officer none get_fips_mode
fips_mode_set
errormsg
N/A
Self-test User, Crypto-
Officer
Integrity Key fips_mode_set
fips_selftests
fips_integrity_check
fips_selftest_aes
kat_selftest_tdes
fips_selftest_sha1
fips_selftest_hmac
execute
Zeroize User, Crypto-
Officer
AES, Triple-
DES, HMAC
key
zeroize N/A
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 10 of 14
2.3.1 Authentication Mechanisms
The module doesn’t support authentication mechanisms.
2.4 Physical Security
The module is implemented completely in software and physical security provided solely
by the host platform.
2.5 Operational Environment
The module was validated running on Red Hat Enterprise Linux 6.3 on qemu-kvm-
0.12.1.2-2 on Red Hat Enterprise Linux 6 running on a Dell R900 with an Intel Xeon
E7450; however, compliance can be maintained by running the unmodified module
binary on any version of Red Hat Enterprise Linux 6.3 or higher. However, the CMVP
makes no statement as to the correct operation of the module or the security strengths of
the generated keys when so ported if the specific operational environment is not listed on
the validation certificate. The Object Module functions are completely within the process
space of the application process which loads it. It does not communicate with any
processes other than the one that loads it and satisfies the FIPS 140- 2 requirement for a
single user mode of operation, so while cryptographic processing is in use, keys and
CSPs are protected by process separation.
2.6 Cryptographic Key Management
The following text lists the FIPS-approved and non-FIPS-approved algorithms supported
by the cryptographic module. Only the FIPS-approved algorithms may be used in the
FIPS Approved mode. Use of the non-approved algorithms will place the module into the
non-approved mode of operation.
The cryptographic module implements the following FIPS-approved algorithms:
• AES (Certificate #2355)
• Triple-DES (Certificate #1473)
• SHA-1 Byte oriented (Certificate #2029)
• HMAC SHA-1 (Certificate #1461)
The cryptographic module implements the following non-FIPS-approved algorithms:
• Data Encryption Standard (DES)
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 11 of 14
The module supports the following critical security parameters:
Table 4: List of Cryptographic Keys, Cryptographic Key Components, and CSPs
Key Key Type Generation
/ Input
Output Storage Zeroization Use
AES key Symmetric
AES (128,
192, 256)-bit
key
Generated
externally;
input in
plaintext
Never
output from
module
Stored in
RAM in
plaintext
Erasing from
RAM
Used by
external
application
to encrypt
and decrypt
data
Triple-
DES key
Symmetric
Triple-DES
192-bit key
Generated
externally;
input in
plaintext
Never
output from
module
Stored in
RAM in
plaintext
Erasing from
RAM
Used by
external
application
to encrypt
and decrypt
data
HMAC
key
Variable
length (min.
14-bytes
required in
FIPS mode)
Generated
externally;
input in
plaintext
Never
output from
module
Stored in
RAM in
plaintext
Erasing from
RAM
Used by
external
application
to perform
data
integrity
Integrity
Key
20-byte
HMAC Key
Hardcoded
in module
binary
Never
output from
module
Non-volatile
storage of
GPC in
plaintext
Removal
from non-
volatile
storage and
formatting
Used to
perform the
software
integrity test
2.6.1 Key Generation
The module does not generate any cryptographic keys internally.
2.6.2 Key Storage
The module does not provide any persistent key storage. All keys are entered the module
via API calls and stored in RAM in plaintext during API function execution.
2.6.3 Key Entry and Output
All keys and CSPs that are entered into the module are electronically entered in plaintext
via parameters of API functions. All keys never output from the module.
2.6.4 Key Zeroization
A user can perform key zeroization of AES, Triple-DES or DES keys by calling an API
function that erases keys from the RAM.
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 12 of 14
2.7 Self-Tests
The Module performs the following power-up self-tests to ensure correct operation:
• Software integrity check using HMAC SHA1
• Known Answer Tests (KATs)
o AES Encrypt and Decrypt KATs (CFB128 mode)
o Triple-DES Encrypt and Decrypt KATs
o SHA-1 KAT
o HMAC SHA1 KAT
Power-up tests are performed automatically when the module is loaded. The integrity of
the module is verified by calculating the SHA1 HMAC digest of the libcmscrypto.so file
and comparing it to the digest that was calculated and placed into libcmscrypto.hmac file
during the last module build-up and installation. The module notifies the operator of any
self-test failures through the return values of the module’s API. FIPS mode cryptographic
functionality will be available only after successful execution of all power-up tests.
The failure of any power-up self-tests causes the module to enter Error state (see Finite
State Model) and all cryptographic operations are disabled until the module is initialized
again with successful execution of self-tests.
2.8 Design Assurance
The source code is primarily written in C++. All source code and documentation is stored
in Borland StarTeam 2008 Release 2 which provides configuration management for the
libcmscrypto Cryptographic library’s FIPS documentation. This software provides access
control, versioning, and logging.
2.9 Mitigation of Other Attacks
The module does not mitigate other attacks.
3 SECURE OPERATION
The module meets Level 1 requirements for FIPS 140-2. The sections below describe
how to place and keep the module in FIPS-approved mode of operation.
3.1 Crypto-Officer Guidance
The Crypto-Officer is required to install and initialize the module to run in a FIPS mode
of operation. The FIPS mode initialization is performed when the application loads the
library and runs the initialization code that will run power-up self-tests. Successful
completion of the power-up self-tests ensures that module is operating in FIPS mode of
operation.
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 13 of 14
3.1.1 Initial Setup
The cryptographic module is the libcmscrypto.so object library, version 1.2.2 that is
installed on Linux operating system Red Hat Enterprise Linux 6.3 or higher2
. The
operating system segregates user processes into separate process spaces. Each process
space is an independent virtual memory area that is logically separated from all other
processes by the operating system software and hardware. The module functions entirely
within the process space of the CMS application process that invokes it and satisfies the
FIPS 140-2 requirement for a single user mode of operation. The module is installed in
the standard library path on the destination platform by copying it to the appropriate
location. The installation of the module (libcmsrypto.so) also includes a HMAC-SHA1
digest of the libcmscrypto.so module that is in the libcmscrypto.hmac file. The digest is
used to verify module integrity during startup.
3.2 User Guidance
The User does not have the ability to initialize and install the module. The User can use
the API to encrypt and decrypt data, calculate hash digests, or calculate HMAC values.
The user shall only use those algorithms approved for use in the FIPS mode of operation
(AES, Triple-DES, HMAC and SHA-1). Otherwise, the use of non-approved algorithms
will place the module into a non-approved mode of operation. When using HMAC, keys
shall be at least 112-bits in order to meet a minimum 112-bits of strength. As per IG
A.13, the User is responsible for ensuring that a single Triple-DES key is not used to
encrypt more than 2^16 64-bit data blocks.
2
FIPS 140-2 validation completed on Red Hat Enterprise Linux v6.3
Comtech Mobile Datacom Corporation October 8, 2019, Rev 1.7
FIPS 140-2 Non-Proprietary Security Policy
©2019 Comtech Mobile Datacom Corporation
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 14 of 14
4 ACRONYMS
The following table spells out the acronyms used in this document.
Table 5: Acronyms used in this document
Acronym Definition
AES Advanced Encryption Standard
API Application Programming Interface
CMVP Cryptographic Module Validation Program
CMS Comtech Mobile Messaging System
CSP Critical Security Parameter
DES Data Encryption Standard
FIPS Federal Information Processing Standard
GPC General Purpose Computer
HMAC (Keyed-) Hash Message Authentication Code
KAT Known Answer Test
NIST National Institute of Standards and Technology
OS Operating System
CPU Central Processing Unit
RAM Random-Access Memory
SHA Secure Hash Algorithm
TDEA Triple Data Encryption Algorithm
TDES Triple DES