FIPS 140-2 Level 2 Security Policy
for
Mojo AirTight Sensor
June 2018
339 N Bernardo Avenue, Suite 200
Mountain View, CA 94043
www.mojonetworks.com
© 2018 Mojo Networks, Inc.
This is non-proprietary document. It may be freely reproduced and distributed in whole without any modification.
Table Of Contents
Table Of Contents 2
1. Introduction 3
2. Module Specification 3
a) Ports and Interfaces 5
b) Logical Interfaces 5
c) Modes of Operation 7
d) Compliance with FIPS Requirements 8
3. Security Functions 9
a) Roles, Authentication, Services 9
a.1) User 9
a.2) Crypto Officer 10
b) Controlling Access to the Module for the First time 16
c) Encryption/Decryption 16
c.1) Communication with Server 16
Derivation and Transport of Session Key 16
Derivation of Message Authentication and Encryption Keys 17
Shared Secret Key Management 17
Use of TLS 1.2 for Communication with Server 17
c.2) SSH Server 18
c.3) Firmware Upgrade 18
d) Summary of Passwords, Keys and Critical Security Parameters (CSPs) 18
d.1) Passwords, Keys and CSPs 18
d.2) Public Keys 24
e) Summary of Cryptographic Algorithms 25
4. Self Tests 28
5. Physical Security 29
Tamper Evident Labels 29
6. Mitigation of Other Attacks 31
2
1. Introduction
This document describes security policy for the Mojo AirTight Sensor cryptographic
module from Mojo Networks, Inc. The security policy specifies the rules for operation of
the module to meet Federal Information Processing Standard (FIPS) 140-2 Level 2
requirements.
FIPS 140-2, ​Security Requirements for Cryptographic Modules, describes the requirements
for cryptographic modules. For more information about the FIPS 140-2 standard and the
cryptographic module validation process see
http://csrc.nist.gov/groups/STM/cmvp/index.html​.
2. Module Specification
Mojo AirTight Sensor is a multi-chip standalone firmware cryptographic module. It is
referred to as a “Module” throughout this document.
● Firmware Version 8.2.1.
The Module consists of Linux OS version 3.4.103, device drivers, sensor application, Crypto
Core, CLI application, and utilities. Crypto Core performs cryptographic functions of the
Module such as encryption, decryption, digital signature, key establishment, key derivation,
hashing, random number generation etc. The Module is operated in a limited operational
environment. Access to the operating system operations is restricted.
The Module has been tested for FIPS compliance on two different operational
environments, namely, C-120 appliance and C-130 appliance. Figure 1 shows physical
embodiment of the appliances. They have identical enclosures. The appliances contain the
following hardware components: System Processor, Wireless Subsystem, RAM, Flash
Memory, Ethernet Network Interface which is PoE (Power over Ethernet) capable, Console
Interface, LED Interface, Power Inlet, USB Port, and Pinhole Reset Button. The wireless
subsystem of C-120 appliance contains two radio modules, whereas that of C-130
appliance contains three radio modules.
Figure 2 shows the cryptographic boundary for the Module and the paths of data, control
and status information flow across the cryptographic boundary.
3
Figure 1: Appliance (C-120, C-130)
Figure 2: Cryptographic Boundary
4
In its operation, the Module scans wireless signals. The Module also sniffs traffic on the
wired network to perform correlation between wired and wireless traffic. The Module
transmits wireless signals to perform functions such as probing wireless devices and to
disable undesirable wireless communications. The Module also transmits probing packets
and packets to disable undesirable communications over the wired network. The Module
reports wireless scanning and wired sniffing information to the management server
(Server) and is also able to accept commands from the Server for its operation. By virtue of
these operations, the Module ensures that wireless communication activity in its proximity
complies with the specified security rules.
a) Ports and Interfaces
Table 1 shows physical ports on the Module and their mapping to FIPS 140-2 logical
interfaces.
Physical Port Logical Port FIPS 140-2 Logical Interface
Network
Interface
Sensor
Application
Data input, data output, control input, status
output, power (PoE).
Console
Interface
CLI Application Data output, control input, status output.
Power Inlet Device Driver DC power enters via power inlet. It can also enter
via the Network Interface which is PoE (Power
Over Ethernet) capable.
LEDs Device Driver Status output.
Antennas Device Driver Data input, data output.
Pin-hole Reset
Button
Device Driver Control input.
USB Port NA Disabled, NA
Table 1: Ports and Interfaces
b) Logical Interfaces
Logical interfaces on the Module are described in Table 2.
5
Data Input Data enters the Module via the Antennas. This data represents
wireless transmissions detected in the radio proximity of the
Antennas.
Data enters the Module via the Network Interface. This data
represents subset of packets traversing the subnet(s) to which
the Module's Network Interface is connected.
Data Output Data exits the Module via the Antennas. This data represents one
or more of (i) wireless-side probing information, and (ii)
transmissions used to disable certain wireless communications.
Data exits the Module via the Network Interface. This data
represents one or more of (i) reports about the wireless
transmissions detected in the wireless neighborhood of
the antennas, (ii) reports about the devices detected on
the subnet(s) to which the Module's Network Interface is
connected, (iii) wire-side probing information, (iv)
transmissions used to block certain communications
associated with devices on the subnet(s) where the
Network Interface is connected.
Data also exits the Module via the Console Interface. This
data represents (i) reports about the wireless
transmissions detected in the wireless neighborhood of
the antennas, (ii) reports about the devices detected on
the subnet(s) to which the Module's Network Interface is
connected.
Control Input Control input enters the Module via the Network Interface
or the Console Interface. This input comprises of
information such as network settings, Server discovery
settings, status requests, password change, key change,
mode change, configuration for wireless scanning,
instructions to take actions on specific devices such as
6
probing, disabling etc.
Control input to reset the Module to factory settings can
also enter via the Pin-Hole Reset Button.
Status Output Status output exits the Module via the Network Interface
or the Console Interface. This output comprises of
information such as network settings, version number,
operation logs, results of self tests, mode of operation,
and status of other configuration parameters.
Status output can also exit the Sensor via the LED
Interface. This Status output consists of information such
as whether the Module is powered up, status of the
Module's connectivity to the Server, status of the Wireless
Subsystem etc.
Table 2: Logical Interfaces
On a physical port, output (data and status) is logically separated from input (data and
control) by way of direction of information flow. Data output is logically separated from
status output by way of networking protocols and application level identifiers. Data input is
logically separated from control input by way of networking protocols and application level
identifiers.
c) Modes of Operation
The Module is able to operate in FIPS and non-FIPS modes. Factory default setting is
non-FIPS mode. The Module can be switched to FIPS mode using following steps:
● User logs into the Module over CLI (Command Line Interface). CLI login can be over
console cable or SSH.
● User runs “set FIPS mode” command to invoke “change mode” service. After this
command is run, the Module reboots. The User can confirm that the Module has
booted in FIPS mode by running the “get FIPS mode” command.
● When the Module is turned to FIPS mode, the user password and the shared secret
key (K) used for secure communication with the Server are set to factory default.
7
● User sets custom password using “passwd” command.
● User manually enters the new key K using “set communication key” command and
permits the module to connect to the Server.
Steps to switch the Module from FIPS mode to non-FIPS mode are:
● User logs into the Module over CLI, either via console cable or SSH.
● User runs “set FIPS mode” command to invoke “change mode” service. After this
command is run, the Module reboots. The User can confirm that the Module has
booted in non-FIPS mode by running the “get FIPS mode” command.
● When the module turned to non-FIPS mode, user password and key K are reset to
factory default.
● User sets custom password using “passwd” command.
● User manually enters the new key K using “set communication key” command and
permits the Module to connect to the Server.
The same security functions and services are provided in both modes. The same
cryptographic algorithms are used in FIPS and non-FIPS modes, with the exception of
upgrade bundle verification. In FIPS mode, RSA digital signature is used for upgrade bundle
verification, while in non-FIPS mode HMAC-SHA-1 is used for the same purpose.
Keys/CSPs are not shared between FIPS and non-FIPS modes.
d) Compliance with FIPS Requirements
The Module meets FIPS 140-2 security requirements as shown in Table 3.
Security Requirements Section Level
Cryptographic Module Specification 2
Cryptographic Module Ports and Interfaces 2
Roles, Services, and Authentication 2
Finite State Model 2
Physical Security 2
Operational Environment N/A
Cryptographic Key Management 2
Electromagnetic Interference/Electromagnetic Compatibility 2
Self Tests 2
8
Design Assurance 2
Mitigation of Other Attacks Not applicable
Table 3: FIPS Security Requirements
3. Security Functions
The various security functions incorporated in the Module are described below.
a) Roles, Authentication, Services
The Module supports two roles: User and Crypto Officer. The User can access the Module
over the Console Interface or the Network Interface. The Crypto Officer role is assumed by
the Server when the Module connects to the Server.
a.1) User
The User accesses the Module over the Console Interface (using console cable) or the
Network Interface. Information flowing over the console wire is plaintext. Access over the
Network Interface is via SSH. User is authenticated to the Module using a password.
Password should be at least 6 characters in length. The maximum password length is
limited to 32 characters. This results in at least 308,915,776 combinations for the password
(computed as 26 raised to the power 6). Thus, the possibility of correctly guessing the
password is less than 1 in 1,000,000.
The login attempt rate of the User is limited to 1 attempt every 3 seconds. In other words,
there can be at most 20 login attempts per minute. This, along with the number of possible
combinations of the password, ensures that repeated attempts to use the authentication
mechanism during a one-minute period have a probability of success less than one in
100,000.
Crypto Officer can change User password when the Module is properly connected to the
Server.
When the Module is power-cycled, the User will have to re-authenticate. That is, the
authentication state is forgotten after power cycle. When the Module is reset to factory
9
default, the password for the User defaults to factory setting. The User password is also
reset to factory default setting upon entering or exiting FIPS mode.
a.2) Crypto Officer
Server assumes the role of Crypto Officer when the Module connects to it. The Crypto
Officer accesses the Module over the 128 bit AES-CBC encrypted tunnel. The Crypto
Officer authenticates to the Module using the shared secret key (K) which is 128 bit in
length. Since there are 2​128​
combinations for the key, the possibility of correctly guessing
the key is less than 1 in 1,000,000.
The authentication between the Module and the Server is mutual authentication using
challenge/response procedure. Each side sends a random challenge to the other. The other
side encrypts the challenge with key K using AES-CBC encryption, and sends the
encrypted response to the issuing side. The issuing side decrypts the response to verify
that the originally issued challenge is found therein. The authentication attempt rate is
limited to 1 attempt every 2 minutes. This, along with the number of possible combinations
of the key, ensures that repeated attempts to use the authentication mechanism during a
one-minute period have a probability of success less than one in 100,000.
Key K is manually entered by User when turning the Module to FIPS mode as described
above. Crypto Officer can change the key K when the Module is properly connected to the
Server. The new key K is sent from Crypto Officer to the Module in a message that is
protected by 128 bit AES-CBC encryption and HMAC-SHA1 authentication.
When the Module is power cycled, the Crypto Officer will have to re-authenticate. That is,
the authentication state is forgotten after power cycle. When the Module is reset to factory
default, the shared secret key K defaults to factory setting. It will also be reset to factory
default (zeroized) upon entering and exiting the FIPS mode of operation for the Module.
Table 4 summarizes strength of authentication for User and Crypto Officer roles.
Role Auth.
Credentials
Minimum
Length
Maximum
Length
Strength per
Attempt
Strength per
Minute
User Password 6 characters 32
characters
Probability of
success less
Probability of
success less
10
than 1 in
308,915,776
than 1 in
15,445,788
Crypto
Officer
Key 128 bits 128 bits Probability of
success is 1 in
2​128
Probability of
success is 1 in
2​128
Table 4: Authentication
Table 5 shows services available to the User and Crypto Officer.
Service User Crypto
Officer
Description CSP Access
U: User, CO: Crypto Officer
W: Write, E: Execute, R: Read
Login Yes No Log into the
Module to
access CLI
(Command Line
Interface).
All Cases:
User Password: U (E)
Via SSH:
SSH-RSA-PRK: U (E)
SSH-DH-PRK, Outbound and
Inbound SSH-MAK and SSH-MEK: U
(W), U (E)
Connect to
Server
Yes No Configure
settings to
establish
connection with
Server
Server connection over UDP or TLS:
SPT-SK: U (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: U (W), U (E)
Server connection over TLS:
TLS-ECDH-PRK, TLS-PMK, TLS-MK,
TLS-MAK, TLS-MEK: U (W), U (E)
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
11
Operational
settings
Yes Yes Configure
operational
settings such as
network
settings,
wireless
settings etc.
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Change mode Yes No Change mode
of operation of
the Module
between FIPS
and non-FIPS.
All Cases:
User Password, Shared Secret Key
(K), SPT-SK, Outbound and Inbound
SPT-MAK and SPT-MEK,
TLS-RSA-PRK, TLS-ECDH-PRK,
TLS-PMK, TLS-MK, Outbound and
Inbound TLS-MAK and TLS-MEK,
SSH-RSA-PRK, SSH-DH-PRK,
Outbound and Inbound SSH-MAK
and SSH-MEK, Seed for DRBG and V
and Key, Preserved State of LRNG,
UBK: U (W)
Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
Change shared
secret key (K)
Yes Yes Change shared
secret key (K)
used between
the Module and
the Server.
All Cases:
Shared Secret Key (K), SPT-SK,
Outbound and Inbound SPT-MAK
and SPT-MEK: U (W), CO (W)
User Via SSH:
12
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Change User
password
Yes Yes Change
password used
to authenticate
the User.
All Cases:
User Password: U (W), CO (W)
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
View self test
result
Yes No Check result of
self tests.
Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
Perform
on-demand
self test (same
as Reboot)
Yes Yes Perform self
tests/reboot the
Module.
All Cases:
SSH-DH-PRK, Outbound and
Inbound SSH-MAK and SSH-MEK: U
(W), CO (W)
TLS-ECDH-PRK, TLS-PMK, TLS-MK,
Outbound and Inbound TLS-MAK
and TLS-MEK: U (W), CO (W)
13
SPT-SK, Outbound and Inbound
SPT-MAK and SPT-MEK: U (W), CO
(W)
Seed for DRBG and V and Key: U
(W), CO (W)
Preserved State of LRNG: U (W), U
(R), CO (W), CO (R)
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Reset factory
defaults (same
as Zeroize)
Yes No Restore the
Module to
factory default
state.
All Cases:
User Password, Shared Secret Key
(K), SPT-SK, Outbound and Inbound
SPT-MAK and SPT-MEK,
TLS-RSA-PRK, TLS-ECDH-PRK,
TLS-PMK, TLS-MK, Outbound and
Inbound TLS-MAK and TLS-MEK,
SSH-RSA-PRK, SSH-DH-PRK,
Outbound and Inbound SSH-MAK
and SSH-MEK, Seed for DRBG and V
and Key, Preserved State of LRNG,
UBK: U (W)
Via SSH:
14
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
Show status Yes Yes View status of
operation of the
Module.
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Change
upgrade
bundle
decryption key
(UBK)
Yes Yes Change key
(UBK) used to
decrypt
upgrade bundle.
All Cases:
UBK: U (W), CO (W)
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Upgrade
firmware
Yes Yes Upgrade
firmware of
Module.
All Cases:
UBK: U (E), CO (E)
User Via SSH:
Outbound and Inbound SSH-MAK
and SSH-MEK: U (E)
CO Via SpectraTalk/TLS:
15
Outbound and Inbound TLS-MAK
and TLS-MEK: CO (E)
Outbound and Inbound SPT-MAK
and SPT-MEK: CO (E)
Table 5: Services
b) Controlling Access to the Module for the First time
Upon switching the Module to FIPS mode, the User is required to:
● Change the User password from its factory default value
● Change the shared secret key (K) from its factory default value
● Put tamper evident labels on the GPC/platform, that the Module runs on, before
installation
● Permit the Module to connect to the Server
c) Encryption/Decryption
The Module performs the following encryption/decryption functions.
c.1) Communication with Server
The Module communicates with the Server over UDP protocol. Optionally, it can connect
to the server over TCP using TLS version 1.2. Messages exchanged between the Module
and the Server correspond to data output egressing the Network Interface of the Module
and directed to the Server. They also correspond to the control input from Server (Server
commands) and the status output from the Module to the Server. These messages are
referred herein as SpectraTalk messages. The SpectraTalk messages, whether carried over
UDP or within TLS, are afforded cryptographic protection of their own via HMAC-SHA-1
authentication and AES encryption as described below.
Derivation and Transport of Session Key
After successful mutual authentication, the Server randomly generates a session key
(SPT-SK) and transports it to the Module. The shared secret key K encrypts the message
16
carrying SPT-SK from the Server to the Module using AES-CBC encryption and
authenticates it using HMAC-SHA-1. The session key is 128 bits in length.
Derivation of Message Authentication and Encryption Keys
The message authentication key (SPT-MAK) and message encryption key (SPT-MEK) are
derived via HMAC-SHA-1 of predetermined text using the session key SPT-SK as the secret
key. The the SPT-MAK is 160 bits in length and SPT-MEK is 128 bits in length. The SPT-MAK
is used for per-message HMAC-SHA-1 authentication and the SPT-MEK is used for
per-message AES-CBC encryption between the Module and the Server. There is different
pair of (SPT-MAK, SPT-MEK) in each direction – Module to Server and Server to Module.
These key derivation procedures are in compliance with NIST Special Publication 800-108,
Recommendation for Key Derivation Using Pseudorandom Functions, October 2009.
Shared Secret Key Management
Upon switching the Module to FIPS mode, the User is required to change the K from its
factory default value. The key K resets to factory default (zeroized) upon entering or exiting
the FIPS mode. The User has to manually input the new value of key K in the Module.
When the Module is properly connected to the Server, the Server can electronically
change the shared secret key (K). The new key travels from the Server to the Module within
a message that is protected via AES encryption and HMAC-SHA-1 authentication with the
key SPT-SK. The User is required to zeroize the shared secret key either by resetting the
module to factory default or by exiting the FIPS mode when the Module is to be discarded.
The plaintext key K is never outputted from the Module.
Use of TLS 1.2 for Communication with Server
When using TLS over TCP transport between the Module and the Server, a TLS tunnel is
first established by the Module with the Server and the SpectraTalk messages are carried
inside the TLS tunnel. In this case, there are two layers of cryptographic protections - first
is by virtue of cryptographic protection of SpectraTalk messages themselves as described
above and the other by virtue of cryptographic protection of the TLS tunnel. For the
establishment of the TLS tunnel, the Module acts as TLS client. It supports
17
ECDHE_RSA_WITH_AES_256_CBC_SHA384, with RSA key size of 2048 bits, SHA-2 for
digital signature, secp256r1 curve (also known as P-256 curve) for ECDHE.
c.2) SSH Server
SSH server in the Module is used to support remote access for the User role. The RSA
public and private key pair (2048 bits) for host authentication is randomly generated when
the Module is first booted upon entering/exiting FIPS mode and reset to factory defaults. At
the time of establishing SSH session, Diffie-Hellman key exchange
(diffie-hellman-group14-sha1, public key size 2048 bits) is performed to establish shared
secret. Message authentication key (160 bits) and message encryption key (128 bits) are
derived from the shared secret using SSH KDF. The message authentication key is used for
HMAC-SHA-1 integrity protection and the message encryption key is used for AES-CBC
encryption within the SSH session.
c.3) Firmware Upgrade
The integrity of upgrade bundle is established via its SHA-256 hash created at build time.
This hash is signed with RSA 2048 bits private key of Mojo development environment. The
Module upon downloading the upgrade bundle verifies the signed hash value using RSA
2048 bits public key of the Mojo development environment.
The upgrade bundle is also encrypted using AES-CBC with 128 bit key (UBK). The Module
decrypts the bundle after downloading using UBK.
d) Summary of Passwords, Keys and Critical Security
Parameters (CSPs)
d.1) Passwords, Keys and CSPs
Passwords, keys and CSPs used in the Module are summarized in Table 6. None of the
passwords, keys and CSPs are shared between FIPS and non-FIPS modes. Also, they are
never output from the module.
Password/
Key/
CSP
Description Generation Input/Output Storage Zeroization
18
User
Password
Used to
authenticate
the User.
Password
should be at
least 6
characters in
length.
NA Manually
entered in
plain text by
User from
GPC (General
Purpose
Computer)
keyboard.
Electronically
input by
Crypto
Officer in
message
protected
with
encryption
and
authenticatio
n.
SHA-1 hash
with salting in
non-volatile
memory.
Overwritten
with factory
default value
upon change
mode and
reset factory
defaults.
Overwritten
with new
value upon
change
password.
Shared Secret
Key (K)
Used for
HMAC-SHA-1
mutual
authenticatio
n with the
Server and
AES
encryption of
message
transporting
SPT-SK to the
Module. This
key is 128 bits
in length.
NA Manually
entered in
plain text by
User from
GPC (General
Purpose
Computer)
keyboard.
Electronically
input by
Crypto
Officer in
message
protected
with
encryption
and
authenticatio
n.
Plain Text in
non-volatile
memory.
Overwritten
with zeros
and then
replaced with
default value
upon change
mode and
reset factory
defaults.
Overwritten
with new
value upon
change key.
SpectraTalk
Session key
(SPT-SK)
Used to
derive
authenticatio
n and
encryption
key pairs
(SPT-MAK,
SPT-MEK) for
communicati
on between
the Module
and the
Server. The
Generated
externally by
the Server.
Electronically
input by
Crypto
Officer in
message
protected
with
encryption
and
authenticatio
n by key K.
Plaintext in
volatile
memory.
Overwritten
with zeros
upon
termination of
session
between the
Module and
the Server.
19
key SPT-SK is
128 bits in
length.
Outbound
and Inbound
Message
Authenticatio
n Keys
(SPT-MAK)
and Message
Encryption
Keys
(SPT-MEK)
SPT-MAK and
SPT-MEK are
used for
HMAC-SHA-1
authenticatio
n and AES
encryption of
messages
between the
Module and
the Server.
There are
separate
SPT-MAK and
SPT-MEK in
outbound
and inbound
directions.
Each key
SPT-MAK is
160 bits in
length and
SPT-MEK is
128 bits in
length.
Derived from
SPT-SK.
NA
Plaintext in
volatile
memory.
Overwritten
with zeros
upon
termination of
session
between the
Module and
the Server.
Elliptic Curve
Diffie-Hellma
n Private Key
in TLS Client
(TLS-ECDH-P
RK)
This is the
private key
component
of the Elliptic
Curve
Diffie-Hellma
n (ECDH) key
pair which is
used for key
agreement at
the time of
establishment
of TLS
session with
the Server.
The
TLS-ECDH-P
RK is 256 bits
in length. The
key
establishment
methodology
provides 128
bits of
Generated
internally.
NA Plaintext in
volatile
memory.
Overwritten
with zeros
upon
derivation of
master
secret.
20
encryption
strength.
Premaster
Secret in TLS
Client
(TLS-PMK)
Premaster
secret is
agreed
between the
Module and
the Server at
the time of
establishment
of the TLS
session. It is
established
via ECDH
exchange.
The
premaster
secret is
used to
establish
master
secrets for
TLS
connections.
It is 256 bits
in length.
EC
Diffie-Hellma
n key
establishment
.
NA Plaintext in
volatile
memory.
Overwritten
with zeros
upon
derivation of
master
secret.
Master Secret
(TLS-MK),
and
Outbound
and Inbound
Message
Authenticatio
n (TLS-MAK)
and
Encryption
(TLS-MEK)
keys in TLS
Client
Master secret
(of size 48
bytes) is
generated for
each TLS
connection
within the
TLS session
with the
Server, using
the premaster
secret for the
TLS session.
The master
secret is used
to derive
HMAC-SHA-
384 message
authenticatio
n key (384
bits) and AES
message
encryption
key (256 bits).
There are
separate
Derived from
pre-master
secret.
NA Plaintext in
volatile
memory.
Overwritten
with zeros
upon
termination of
TLS session
between the
Module and
the Server.
21
authenticatio
n and
encryption
keys in each
direction
(outbound
and inbound).
RSA Private
Key for SSH
Server
(SSH-RSA-PR
K)
This is the
private key
component
of the RSA
key pair
which is used
for host
authenticatio
n in SSH. The
RSA private
key is 2048
bits in length.
It is
generated
when the
Module first
boots up.
Generated
internally.
NA
Plaintext in
non-volatile
memory.
Overwritten
with zeros
upon change
mode and
reset factory
defaults.
Diffie-Hellma
n Private Key
for SSH
Server
(SSH-DH-PR
K)
This is the
private key
component
of the
Diffie-Hellma
n key pair
which is used
for key
agreement at
the time of
establishment
of SSH
session. The
Diffie-Hellma
n private key
is at least 224
bits in length.
The key
establishment
methodology
provides 112
bits of
encryption
strength.
Generated
internally.
NA Plaintext in
volatile
memory.
Overwritten
with zeros
upon
termination of
SSH session.
SSH
Per-session
Outbound
and Inbound
There is one
160-bit key
for
HMAC-SHA-1
Diffie
Hellman key
establishment
.
NA Plaintext in
volatile
memory.
Overwritten
with fixed
pattern upon
22
Message
Authenticatio
n (SSH-MAK)
and
Encryption
(SSH-MEK)
Keys
message
authenticatio
n and one
128-bit key
for AES
message
encryption in
each
direction in
the SSH
session.
These keys
are generated
at the time of
SSH session
establishment
.
termination of
SSH session.
Seed for
DRBG
(Deterministic
Random Bit
Generator)
and V and
Key values
DRBG is
seeded with
random
256-bit AES
key and
random
128-bit Nonce
(V). These
values are
obtained by
reading bytes
from the
/dev/random
device and
feeding them
directly to
DRBG.
Generated
internally.
NA Plaintext in
volatile
memory.
Overwritten
with zeros
upon
instantiation
of DRBG.
Preserved
State of LRNG
(Linux
Random
Number
Generator)
During
system
shutdown,
the Module
extracts 512
bytes from
LRNG output
pool and
stores them
in
non-volatile
memory in
plaintext.
During
system start,
the stored 512
bytes are
mixed into
Generated
internally.
NA Plaintext in
non-volatile
memory.
Overwritten
with zeros
upon change
mode and
reset to
factory
default.
Overwritten
with new
value upon
reboot.
23
the output
pools.
Firmware
Upgrade
Decryption
Key (UBK)
This is 128 bit
AES key that
is used for
decryption of
upgrade
bundle.
NA Manually
input in plain
text by User
from GPC
(General
Purpose
Computer)
keyboard.
Electronically
input by
Crypto
Officer in
message
protected via
encryption
and
authenticatio
n.
Plain text in
non-volatile
memory.
Overwritten
with zeros
upon change
mode and
reset to
factory
default.
Table 6: Passwords, Keys, CSPs
d.2) Public Keys
The following public keys are used in the Module in FIPS mode:
o RSA Public Key for SSH Server (2048 bits):​ ​It is the public key counterpart of the
private key used for host authentication in SSH. It cannot be shared between
non-FIPS and FIPS modes. This key is stored in plaintext in non-volatile memory.
The RSA key pair is generated when the Module is first booted, and thereafter on
entering or exiting FIPS mode, or on reset to factory default. It is output from the
Module to the SSH client, when the client attempts connection to the SSH server in
the Module.
o Diffie-Hellman Public Key for SSH Server (2048 bits): It is the public key
component of the private key used for key agreement during SSH session
establishment. It cannot be shared between non-FIPS and FIPS modes. This key is
stored in plaintext in volatile memory. It is deleted upon termination of the SSH
session. Power cycle, reboot, entering and exiting FIPS mode, and reset to factory
default result in termination of the SSH session and hence deletion of this key. It is
24
output from the Module to the SSH client, when the client connects to the SSH
server in the Module.
o ECDH Public Key for TLS Client (256 bits): It is the public key component of the
private key used for key agreement during TLS session establishment. It cannot be
shared between non-FIPS and FIPS modes. This key is stored in plaintext in volatile
memory. It is deleted upon termination of the TLS session. Power cycle, reboot,
entering and exiting FIPS mode, and reset to factory default result in termination of
TLS session and hence deletion of this key. It is output from the Module to the
Server, when the Module connects to the Server over TLS.
The following public keys do not belong to the Module, but are stored in the module and
are used in the FIPS mode:
o RSA Public key of certificate authority (CA) for Server certificate validation (2048
bits): It is the public key counterpart of the private key used for signing the Server
certificate. This key is input into the Module by the User. It is stored in plaintext in
non-volatile memory and it is not output from the module.
o RSA Public key for firmware upgrade bundle signature verification (2048 bits): It is
the public key counterpart of the private key used for signing the upgrade bundle at
build time. The RSA key pair is generated during the build process and the public
key to be used for verification of the next upgrade bundle is included in the current
firmware version. This key is stored in plaintext in non-volatile memory. The public
key is not output from the module. The key is overwritten during the firmware
upgrade with a new RSA public key that is to be used for verification of the next
upgrade bundle. The new key may be the same as or different from the present
key.
e) Summary of Cryptographic Algorithms
The Module implements FIPS approved algorithms described in Table 7.
Algorithm CAVP
Certificate
Standard Mode/Method Key Length or
Moduli
Use
AES-CBC AES #5158 FIPS 197 CBC 128 bits,
256 bits
Encryption/d
ecryption
25
SHA-1 SHS #4165 FIPS 180-4 Message
digest and
key
derivation
(SSH)
SHA-256 SHS #4165 FIPS 180-4 Message
digest (TLS)
SHA-384 SHS #4165 FIPS 180-4 Key
Derivation(TL
S)
HMAC-SHA
-1
HMAC #3419 FIPS 198 128 bits, 160
bits
Message
integrity
(SpectraTalk,
SSH); key
derivation
(SpectraTalk)
HMAC-SHA
-384
HMAC #3419 FIPS 198 384 bits Message
integrity (TLS)
RSA RSA #2774 FIPS 186-4 PKCS#1 v1.5 2048 bits Key
generation
(SSH), sign
(SSH), verify
(TLS)
DRBG DRBG #1936 SP
800-90AR1
AES-CTR 256 bits Random
number
generation
KBKDF KBKDF #174 SP 800-108 Counter,
HMAC-SHA1
Key
derivation
(SpectraTalk)
SSH** KDF CVL #1672 SP 800-135 Key
derivation for
SSH
per-session
message
authenticatio
n and
encryption
keys
TLS** KDF CVL #1672 SP 800-135 Key
derivation for
TLS
per-session
26
message
authenticatio
n and
encryption
keys
ECC CDH
Primitive
CVL #1673 SP 800-56A P-256 Pre-master
secret
establishmen
t (TLS)
KTS AES #5158
and HMAC
#3419
SP 800-38F 128 bit AES
and 160 bit
HMAC
Key transport
through SSH
and
SpectraTalk
Vendor
affirmed
CKG* SP 800-133 Key
generation
Table 7: Approved Algorithms
(Note*: Key generation using unmodified output from an approved DRBG as the random
seed of FIPS 186-4 key generation).
(Note**: No parts of the SSH and TLS protocols, other than the KDF, have been tested by
the CAVP or CMVP).
The Module implements FIPS allowed algorithms described in Table 8.
Algorithm Caveat Use
Diffie-Hellman Provides 112 bits (Oakley group 14) Key Establishment in SSH
EC
Diffie-Hellman
Provides 128 bits (P-256) of
encryption
strength
Key Establishment in TLS
MD5 Used for firmware integrity test Integrity Test
NDRNG Linux /dev/random device which
provides 384 bits of entropy
Seeding for DRBG
Table 8: Allowed Algorithms
27
4. Self Tests
The Module always reboots when FIPS mode is entered. At boot time, firmware integrity
check is done using MD5 checksum of the firmware.
If the firmware integrity test passes, the Module performs power-up self tests shown in
Table 9.
Algorithm Test
AES-CBC Encrypt KAT and Decrypt KAT
RSA Sign KAT and Verify KAT
DRBG KAT for Instantiate, Reseed and Generate
SHA-1 KAT
SHA-256 KAT
HMAC-SHA-1 KAT
HMAC-SHA-384 KAT
ECC CDH KAT (IG 9.6)
KBKDF (SP 800-108) KAT
Table 9: Power-up Self Tests
If any of the above tests fails, the Module goes to the Error State.
During operation, the module performs conditional self tests shown in Table 10.
Algorithm/Service Test
RSA Pairwise Consistency
DRBG Continuous
NDRNG (/dev/random) Continuous
Upgrade Firmware Firmware Load (RSA 2048 SigVer)
Table 10: Conditional Self Tests
If conditional test for RSA, DRBG, or NDRNG fails, the Module enters the Error State.
At the time of updating the Module to the new firmware, firmware load test (using RSA
2048 bits digital signature) is performed. If the firmware load test fails, the new firmware
28
image is not loaded onto the Module and the Module continues operation with the existing
firmware image. If the test succeeds, the old firmware is replaced with the new firmware.
In the Error State, the Module does not output any data on the Data Output interface. The
results of the above tests can be viewed by the User by accessing the Module over the
Console Interface.
When the User attempts changing the shared secret key (K) or upgrade bundle decryption
key (UBK), manual key entry test is performed. If the test succeeds, new key is accepted.
Else, new key is rejected.
It is also possible to perform on-demand self test by rebooting the Module.
5. Physical Security
The appliances containing the Module is made from production-grade components, which
are encased within an opaque, hard, production-grade enclosure. The appliances meet
commercial-grade specifications for power, temperature, reliability, shock and vibration.
Tamper Evident Labels
Two tamper evident labels shall be applied to appliance by the User to operate the Module
in FIPS approved mode. The locations for applying these labels are shown in Figures 3(A)
and 3(B). Before applying the labels, the receiver surface of the appliance must be cleaned
with dry cloth or tissue paper. Tamper evident labels can be ordered from Mojo Networks
(part number C-TPL-A).
Per FIPS 140-2 Implementation Guidance (IG 14.4), the User is responsible for securing and
having control at all times of any unused labels. The user is also responsible for the direct
control and observation of any changes to the Module such as reconfigurations where the
tamper evident labels or security appliances are removed or installed to ensure the
security of the Module is maintained during such changes and the module is returned to a
FIPS approved mode.
The User is also required to periodically inspect the Module for evidence of tampering at
intervals defined by the organization’s security policy. The inspection must include visual
examination of tamper evident labels for tears, rips, dissolved adhesive, and other signs of
29
malice. It must also include visual inspection of any enclosure defects such as broken
screws, bends, depressions, scratches, and other questionable markings. If evidence of
tampering is observed, the User must alert incident response team at the organization.
Upon gathering of the evidence, the User must zeroize the Module.
Figure 3(A)
Figure 3(B)
30
6. Mitigation of Other Attacks
In operation, the Module acts as wireless intrusion detection and prevention sensor. This
functionality is beyond the scope of FIPS 140-2 validation.
31