3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
1 / 35
Non-proprietarySecurity Policy
WavenceMicrowaveradio cryptoModule
Nokia XHAUL
9500 Microwave Packet Radio (MPR)
Author Nathalie Denizet
Owner Nathalie Denizet
Organization X-Haul Product Line
Approver Michel Peruyero
Tom Loper
Document Type Specification
Document ID 3DB225000009DSZZA
Document Location PDM
Change History
Version Status Date Author Owner Reviewed by Reviewed
date
Approver Approval
date
Description of changes
0.1 Draft 14-02-2018 Nathalie Denizet Nathalie Denizet PCT 15-02-2018 Xavier Gaillard 15-02-2018 First Draft
0.2 Draft 15-07-2019 Nathalie Denizet Nathalie Denizet PCT 17-07-2019 Michel Peruyero 15-02-2018 Rework after first Workshop
0.3 Draft 22-06-2020 Nathalie Denizet Nathalie Denizet PCT 22-06-2020 Michel Peruyero 22-02-2018 Rework to align
0.4 Draft 21-09-2021 Nathalie Denizet Nathalie Denizet PMT 21-07-2021 Michel Peruyero 21-07-2021 Rework to alignevolutions
0.5 Draft 04-08-2021 Nathalie Denizet Nathalie Denizet PMT Post testing review update
Version number update
1.0 Released 18-12-2021 Nathalie Denizet Nathalie Denizet PMT 20-12-2021 Fabien Mulot 20-12-2021 Final release
2.0 Released 27-09-2022 Nathalie Denizet Nathalie Denizet PMT 27-09-2022 Loper Tom 28-09-2022 Updated versionfor validation
2.1 Released 29-11-2022 Nathalie Denizet Nathalie Denizet PMT 30-11-2022 Loper Tom 30-11-2022 New Updated version for validation
2.2 Released 04-01-2023 Nathalie Denizet Nathalie Denizet PMT 04-01-2023 Loper Tom 04-01-2023 New Updated version forvalidation
2.3 Released 18-01-2023 Nathalie Denizet Nathalie Denizet PMT 18-01-2023 Loper Tom 18-01-2023 Updated listing of firmwarecomponents.
2.4 Released 07-02-2023 Nathalie Denizet Nathalie Denizet PMT 08-02-2023 Loper Tom 31-01-2023 Fixed missing image in Figure 9anddevice
part numbers. Updatedescriptionof chas-
sis.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
2 / 35
Contents
1 Introduction .......................................................................................................................6
1.1 Overview......................................................................................................................6
1.2 Identification ...............................................................................................................6
1.3 Purpose .......................................................................................................................8
1.4 Document Organization ............................................................................................8
1.5 Document Terminology ............................................................................................9
1.6 Document References...............................................................................................9
2 Wavence Cryptographic Module ..................................................................................11
2.1 Cryptographic Module Specification ....................................................................11
2.1.1 Cryptographic Boundary...............................................................................................................................11
2.1.2 Required External Component....................................................................................................................13
2.1.3 Mode of operation...........................................................................................................................................14
2.1.4 Cryptographic Module Overview.................................................................................................................14
2.1.5 Cryptographic Algorithms..............................................................................................................................14
2.2 Cryptographic port and interface ..........................................................................16
2.3 Roles, Service and Authentication........................................................................18
2.3.1 Authorized Roles.............................................................................................................................................18
2.3.2 Authentication mechanisms.........................................................................................................................19
2.3.3 Services............................................................................................................................................................20
2.4 Physical Security .....................................................................................................23
2.5 Operational Environment........................................................................................26
2.6 Cryptographic Key Management...........................................................................26
2.6.1 Random Number Generators.......................................................................................................................27
2.6.2 Key Generation...............................................................................................................................................28
2.6.3 Key Entry/Output.............................................................................................................................................28
2.6.4 Zeroization procedure....................................................................................................................................28
2.7 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC) ....28
2.8 Self-Tests ..................................................................................................................28
2.8.1 Power-up Self-Tests.......................................................................................................................................29
2.8.2 Conditional Self-test.......................................................................................................................................29
2.8.3 Self-test error handling..................................................................................................................................29
2.9 Design Assurance....................................................................................................30
2.9.1 Design and Development..............................................................................................................................30
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
3 / 35
2.9.2 Configuration Management..........................................................................................................................30
2.9.3 Guidance documents.....................................................................................................................................31
2.10 Delivery......................................................................................................................31
2.10.1 SW elements delivery...............................................................................................................................31
2.10.2 Product Release and SWP identification..............................................................................................32
2.10.3 Secure mode solution delivery................................................................................................................32
2.11 Mitigation of Other Attacks Policy ........................................................................33
3 Configuring the MPT-HLC for Secure Operation.......................................................34
3.1 Installation.................................................................................................................34
3.2 Initialization...............................................................................................................35
3.3 Initialization of encryption keys.............................................................................35
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
4 / 35
Index of figures
Figure 1: MPT-HLC module: exploded view .......................................................................... 11
Figure 2: Chassis with two MPT-HLC modules inserted ....................................................... 12
Figure 3: Front of the chassis with one MPT-HLC module inserted while the other slot is
covered with a blanking plate.................................................................................................. 13
Figure 4: Front of the chassis with two MPT-HLC modules inserted....................................13
Figure 5: Rear view of the chassis.......................................................................................... 13
Figure 6: MPT-HLC ports and interfaces on front plane........................................................ 17
Figure 7: MPT-HLC ports and interfaces on Backplane........................................................ 17
Figure 8: Two MPT-HLC modules inserted into the chassis................................................. 23
Figure 9: Anti-tampering label placement at the front-side of the cryptographic module (left:
one MPT-HLC module and blanking plate on empty slot; right: two MPT-HLC modules)...24
Figure 10: Anti-tampering label placement at the back-side of the cryptographic module
(top view and underside) ......................................................................................................... 24
Figure 11: Tamper-evident label: intact.................................................................................. 24
Figure 12: Tamper-evident label: broken (normal view) ........................................................ 25
Figure 13: Tamper-evident label: broken (close-up view) ..................................................... 25
Figure 14: Anti-tampering label design................................................................................... 25
Figure 15: Cover on the rear side of the chassis for opacity of the digital board and
protection of the back panel board ......................................................................................... 26
Figure 16: Example of the returned data for the ipseckey generate command ................... 34
Index of tables
Table 1: Cryptographic module components ...........................................................................7
Table 2: Validated configurations of the cryptographic module ..............................................8
Table 3: Acronym table..............................................................................................................9
Table 4: Reference document table........................................................................................ 10
Table 5: Security Level Per FIPS 140-2 Section....................................................................14
Table 6: Approved cryptographic algorithms.......................................................................... 16
Table 7: Non-compliant but allowed cryptographic algorithms ............................................. 16
Table 8: Module interfaces ......................................................................................................18
Table 9: Roles and required identification and authentication .............................................. 19
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
5 / 35
Table 10: Strengths of authentication mechanisms............................................................... 19
Table 11: Services authorized for roles and access rights within services .......................... 23
Table 12: Cryptographic keys and CSPs ............................................................................... 27
Table 13: Power-up self-tests .................................................................................................29
Table 14: Conditional self-tests............................................................................................... 29
Table 15: Replacement kits.....................................................................................................32
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
6 / 35
1 Introduction
1.1 Overview
The NokiaWavence product familyincludesa range of Microwave Packet Transport units (abbrevi-
ated as MPT inthis document).These MPTs are integratedin the Nokia NetworkServicesPlatform
to enable consistentoperationsacross end-to-endpacketmicrowave networks.
Anothercomponent of this overall systemis the Wavence Microwave Service Switch (abbreviated
as MSS in this document) which acts as a trafficaggregator, managing any kind of incoming traffic
to be transported on any kind of microwave uplink.
The cryptographic module definedinthisdocument isthe MPT Wavence Microwave radio crypto-
Module in version1.0 by NokiaXHAUL (abbreviatedas MPT-HLC inthis document or referredto as
cryptographic module).The cryptographic module isintendedto establishan encryptedcommuni-
cation linkover-the-airto another MPT-HLC. The encryption functionalityisimplementedina ded-
icated FPGA as part of the cryptographic module.
On both sides,the MPT-HLC is connected to the MSS, which performs managementfunctionsof
the cryptographic module.Both MSSs are connectedto a key serverprovidingkeysfor the over-
the-airencryption.The communication betweenthe MSS and the cryptographic module ispro-
tected by an IPsec channel (AES encryptionand HMAC).
The cryptographic module isa MPT unit for long-haul applicationsand full-indoorconfiguration.
To support long-distance,high-capacity,mission-critical applications,the cryptographic module
comes in differentconfigurationstoofferflexibility,scalability,andreliability.
1.2 Identification
The cryptographic module consistsof the followingcomponents:
Type Name Version Part Number Additional Information
Hardware MPT-HLC 1.0 See codes in
Table 2
N/A
Hardware MPT-HLC Sub-
Rack
01 3EM22618AC Chassis ableto embed up to two MPT-
HLC modules.
Hardware MPT-HLC Sub-
RackBlank
Filler Panel
04 3EM22616AA Blanking plate, used when only one
MPT-HLC is inserted into thesub-rack.
Hardware MPT-HLC Sub-
RackMA-
Cover
01 3DB76330AA Installed at the rearof theMPT-HLC
sub-rack to provide opacity.
Tamper-evi-
dent seals
Anti-Tamper-
ing Labels
N/A 3DB76375AA See Section 2.4 for details.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
7 / 35
Type Name Version Part Number Additional Information
Firmware BOMPT V05.04.00 N/A Firmwareused during the boot process.
Firmware SWMPT V25.02.41 N/A Firmwareexecuted on the CPU for man-
agement services.
Firmware FARPH V06.05.07 N/A Firmwareexecuted on the FPGA for
trafficencryption/decryption.
Firmware FM620 V01.06.64 N/A Modem firmware.
Firmware C2620 V00.09.00 N/A Configuration file for the modem (con-
figuration parameters).
Firmware P2H24 V00.04.05 N/A Configuration file for the modem (mo-
dem profiles).
Firmware FLPAR V01.00.12 N/A Configuration file for the radio shifters.
Firmware HASH0 V01.00.00 N/A Signed hash file listing thefirmware
components.
Table 1: Cryptographic module components
The cryptographic module isvery flexible andvariousfrequencyboards (analogboards) may be
assembledinthe MPT-HLC along with the digital boards definedbelow. The differentproductvari-
ants are all covered by thisvalidationas they differonlyinterms of excludedcomponents.The
firmware and hardware implementingthe securityfunctionalityistherefore identical forall prod-
uct variants listedinTable 2 below.
Code ICS Designation Frequency
(GHz)
Transmitter Con-
figuration
Receiver configu-
ration
3DB76123AA 3 TRANSCEIVER U4 GHz without DIVERSITY 4U Standard Standard
3DB76123BA 3 TRANSCEIVER U4 GHz with DIVERSITY 4U Standard With Diversity
3DB19060AA 9 MPT-HL 6L RT CUBIC STD 6L Standard Standard
3DB19060BA 9 MPT-HL 6L RT CUBIC SD 6L Standard With Diversity
3DB19060CA 4 TRANSCEIVER L6 GHz HP WITHOUT DIVERSITY 6L High Power Standard
3DB19060DA 4 TRANSCEIVER L6 GHz HP WITH DIVERSITY 6L High Power With Diversity
3DB19060EA 1 L6 MPT-HLC PLUS HIGH GAIN WITHOUT COMBIN 6L PLUS HIGH GAIN Standard
3DB19060FA 1 L6 MPT-HLC PLUS HIGH GAIN WITH COMBINER 6L PLUS HIGH GAIN With Diversity
3DB19060GA 1 L6 MPT-HLC PLUS STD WITHOUT COMBINER 6L PLUS Standard Standard
3DB19060HA 1 L6 MPT-HLC PLUS STD WITH COMBINER 6L PLUS Standard With Diversity
3DB76047AA 9 MPT-HL 6U RT CUBIC STD 6U Standard Standard
3DB76047BA 9 MPT-HL 6U RT CUBIC SD 6U Standard With Diversity
3DB76047CA 4 TRANSCEIVER U6 GHz HP WITHOUT DIVERSITY 6U High Power Standard
3DB76047DA 4 TRANSCEIVER U6 GHz HP WITH DIVERSITY 6U High Power With Diversity
3DB76047EA 1 U6 MPT-HLC PLUS HIGH GAIN WITHOUT COMBINER 6U PLUS HIGH GAIN Standard
3DB76047FA 1 U6 MPT-HLC PLUS HIGH GAIN WITH COMBINER 6U PLUS HIGH GAIN With Diversity
3DB76047GA 1 U6 MPT-HLC PLUS STD WITHOUT COMBINER 6U PLUS Standard Standard
3DB76047HA 1 U6 MPT-HLC PLUS STD WITH COMBINER 6U PLUS Standard With Diversity
3DB76048AA 8 MPT-HL 7Ghz RT CUBIC STD 7 Standard Standard
3DB76048BA 8 MPT-HL 7Ghz RT CUBIC SD 7 Standard With Diversity
3DB76048CA 4 TRANSCEIVER 7 GHz HP WITHOUT DIVERSITY 7 High Power Standard
3DB76048DA 4 TRANSCEIVER 7 GHz HP WITH DIVERSITY 7 High Power With Diversity
3DB76049AA 8 MPT-HL 8Ghz RT CUBIC STD 8 Standard Standard
3DB76049BA 8 MPT-HL 8Ghz RT CUBIC SD 8 Standard With Diversity
3DB76049CA 4 TRANSCEIVER 8 GHz HP WITHOUT DIVERSITY 8 High Power Standard
3DB76049DA 4 TRANSCEIVER 8 GHz HP WITH DIVERSITY 8 High Power With Diversity
3DB76078AA 4 TRANSCEIVER 10.5 GHz WITHOUT DIVERSITY 10.5 Standard Standard
3DB76078BA 4 TRANSCEIVER 10.5 GHz WITH DIVERSITY 10.5 Standard With Diversity
3DB76050AA 4 MPT-HL 11 GHz RT CUBIC STD 11 Standard Standard
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
8 / 35
Code ICS Designation Frequency
(GHz)
Transmitter Con-
figuration
Receiver configu-
ration
3DB76050BA 4 MPT-HL 11 GHz RT CUBIC SD 11 Standard With Diversity
3DB76050CB 1 MPT-HLC High Power XCVR 11 GHz 11 High Power Standard
3DB76050DB 1 MPT-HLC High Power XCVR 11 GHz (with Combiner) 11 High Power With Diversity
3DB76050GA 1 MPT-HLC Plus XCVR 11GHz 11 PLUS Standard Standard
3DB76050HA 1 MPT-HLC Plus XCVR 11GHz with Combiner 11 PLUS Standard With Diversity
Table 2: Validated configurations ofthe cryptographic module
The module’sfirmware components are deliveredas part of a combined package for the MSS and
the MPTs of the overall system.The package containingthe certifiedmodule isV08.09.1N. Please
note that only the components listedin Table 1 are part of the validatedmodule.
Customers can confirm they are running a validatedconfigurationof the MPT-HLC by checking the
followinginformation:
 Comparing the part number of the MPT-HLC product identified ona label gluedto the me-
chanical cover of the cryptographic module.The PNs and their correspondingMPT-HLC var-
iants listedin Table 2 are coveredby this validation.Note that the PN is identifiedin Table
2 as “Code”.
 Comparing the hash value of the MPT parts of the overall firmware package (as listedinthe
HASH0 firmware component file) that isshown in the WebCT user interface of the MSS
withthe reference value reportedin this document.The correct SHA-256 hash value for
the of the validated module is:
MPT SWP SHA-2 Hash
Hash: 88A4D379598B3A9D97A5DB0EB1D5B9E75469797DFECD543182430EC7D2AF1D76
Alternatively, the versionsof the individual firmware components(called“units”), which
are reported inthe WebCT userinterface,can be compared withthe versions reported in
Table 1.
See Section 2.10 for furtherdetails.
1.3 Purpose
This document covers the secure operationof the cryptographic module (i.e.the MPT-HLC) includ-
ing initialization,roles,andresponsibilitiesof operatingthe product ina secure,FIPS 140-2 compli-
ant manner.
1.4 Document Organization
This SecurityPolicydocument is one part of the FIPS 140‐2 SubmissionPackage. This document
outlinesthe functionalityprovidedbythe module and giveshigh‐level detailsonthe means by
which the module satisfiesFIPS140‐2 requirements.
The various sectionsof thisdocument map directlyonto the sections of the FIPS 140‐2 standard
and describe how the module satisfiesthe requirementsof that standard.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
9 / 35
1.5 Document Terminology
Term Description
AES Advanced Encryptions Standard
API Application Programming Interface
CAVP Cryptographic Algorithm ValidationProgram
CMVP Cryptographic Module Validation Program
CSP Critical Security Parameters
DRBG DeterministicRandom Bit Generator
FIPS Federal Information Processing Standard
GUI GraphicalUser Interface
KAT Known Answer Test
MPT MicrowavePacket Transport
MSS Microwave/Multi Service Switch
OTA Over-the-air
POST Power-On Self-Test
RSA An algorithm for public‐key cryptography. Named after Rivest, Shamir and Adleman who first
publicly described it.
RNG Random Number Generator
SHA Secure Hash Algorithm
SP Security Policy
TCP/IP Transmission Control Protocol/Internet Protocol
WebCT Web Craft Terminal
WKAT Well Known Answer Test
XPIC Cross Polarization InterferenceCancellation
Table 3: Acronym table
1.6 Document References
Reference Description
[FIPS 140-2] FIPS PUB 140-2, Security Requirementsfor CryptographicModules, May25, 2001,
CHANGE NOTICES (12-03-2002). http://csrc.nist.gov/publications/fips/fips140-
2/fips1402.pdf
[FIPS 140-2 DTR] Derived Test Requirements for FIPS PUB 140-2, Security Re-
quirements for Cryptographic Modules, January 4, 2011 Draft.
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-
2/fips1402DTR.pdf
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
10 / 35
Reference Description
[FIPS 140-2 IG] NIST, ImplementationGuidance for FIPS PUB 140-2 and theCryptographic Module
Validation Program, last updated November 5, 2021
[FIPS 197] FIPS PUB 197, Advanced Encryption Standard(AES), FIPS Publication 197, November
26, 2001.
[PKCS#1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002
[SP 800-90Ar1] NIST Special Publication 800-90A Revision 1, Recommendationfor theRandom Num-
ber GenerationUsing Deterministic RandomBit Generators(Revised), June 2015
[SP 800-90B] NIST Special Publication 800-90B, Recommendation for the Entropy Sources Used for
Random Bit Generation, January 2018
[FIPS 180-4] FIPS PUB 180-4, Secure Hash Standard, FIPS Publication 180-4, August 2015
[SP 800-38A] NIST Special Publication 800-38A, Recommendationfor Block Cipher Modes of Opera-
tion (December 2001)
[FIPS 186-4] FIPS PUB 186-4, DigitalSignatureStandard (DSS), FIPS Publication 186-4, July, 2013
[FIPS 198-1] FIPS PUB 198-1, The Keyed-Hash MessageAuthentication Code (HMAC). July 2008
[SP 800-107r1] NIST Special Publication 800-107 Revision 1, Recommendationfor Applications Using
Approved Hash Algorithms, August 2012
[SP 800-77r1] NIST Special Publication 800-77 Revision 1, Guide to IPsec VPN, June 2020
[RFC3602] The AES-CBC Cipher Algorithm and ItsUse withIPsec (sept 2003)
[RFC4301] Security Architecturefor the Internet (2005) Protocol (V2 implementation)
[SP 800-133r2] NIST, Recommendationfor Cryptographic Key Generation(June 2020)
Table 4: Reference document table
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
11 / 35
2 WavenceCryptographicModule
2.1 Cryptographic Module Specification
2.1.1 Cryptographic Boundary
The cryptographic module (MPT-HLC) is shown in Figure 1 and is a multiple-chip embedded hard-
ware cryptographic module that is covered with a commercial-grade chassis that includes compo-
nentsequippedforphysical security and assurance of opacity. It belongsto the cryptographic mod-
ule in the sense of FIPS 140-2 and is located withinthe cryptographic boundary and contributes to
the physical securityof the module.
Figure 1: MPT-HLC module: exploded view
The MPT-HLC consistsof the followingcomponents:
 One digital board named Tesla(frequencyindependent);
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
12 / 35
 One RF (Radio Frequency) board named Aurelianusforthe main Transmitter and Receiver
(frequencydependent);
 One RF board namedGeminus for the diversityreceiver (RxDiv) (frequencydependentand
optional);
 One Interconnection board for connectionsbetweenthe digital and RF boards (frequency
independent);
 One powersupplyboard named Juppiter(frequencyindependent).
All boards composing the MPT-HLC are containedin a suitable sheetmetal enclosure.RF boards
are additionallyprotectedby a die cast metallicenclosure.
The RF board Aurelianus,the RxDivboard Geminus and the power supply Juppiterare excluded
components.
The cryptographic boundary isdepictedin Figure 2 and includesthe followingitems:
 the chassis (i.e.the sub-rack),
 a cover installedatthe back of the chassis,
 one or two MPT-HLC modulescontainedin the chassis, and
 a blankingplate coveringthe empty slotof the chassis in case onlyone MPT-HLC is con-
tainedin the chassis.
The chassis physicallyhoststhe transceivers(MPT-HLC modules) and providesfrom its rear side
the RF connections. Also, a back-panel board is presenton the rear side of the chassis. It hosts the
connector for the HSB switch and makes some connections betweenthe two transceiversin the
chassis.
The followingfiguresshowthe physical boundary inmore detail.
Figure 2: Chassis with two MPT-HLC modules inserted
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
13 / 35
Figure 3: Front of the chassis with one MPT-HLC module inserted while the other slot is covered with a blanking plate
Figure 4: Front of the chassis with two MPT-HLC modules inserted
Figure 5: Rear view ofthe chassis
2.1.2 Required External Component
The cryptographic module isintendedto be operatedas part of a NokiaNetworkServicesPlatform
solution.Thisinvolvesthe usage of a MSS as an operator of the cryptographic module.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
14 / 35
In order to operate the cryptographic module,differentMSS configurationsare available which
are beyondthis security policy.
The cryptographic module supports radio redundancy.Here, two MPT-HLC modulesare inserted
to the chassis while onlyone MPT-HLC module performsthe cryptographic operationsas specified
in thisdocument. The other MPT-HLC module acts as a transparent radio transceiver.
2.1.3 Mode of operation
The module onlyimplementsthe approved mode of operation.
There are other firmware configurationsavailable,however,only incase the firmware as identi-
fiedinthis document is runningon the cryptographic module,the FIPS 140-2 requirementsare
satisfied.
2.1.4 Cryptographic Module Overview
The cryptographic module meetsthe overall requirementsapplicable toLevel 2 security of
FIPS 140-2.
Section Section title Security level
1 Cryptographic Module Specification 2
2 Cryptographic Module Ports and Interfaces 2
3 Roles, Services, and Authentication 2
4 Finite StateModel 2
5 Physical Security 2
6 Operational Environment N/A
7 Cryptographic Key Management 2
8 EMI/EMC 2
9 Self-Tests 2
10 Design Assurance 2
11 Mitigationof Other Attacks N/A
Table 5: Security Level Per FIPS 140-2 Section
2.1.5 Cryptographic Algorithms
The followingtable providesdetailsof the approved algorithmsthat are includedwithinthe mod-
ule.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
15 / 35
Algorithm CAVP cer-
tificate
Use Notes
HMAC-SHA-512 #A2009 Within IPsec for management plane.
[FIPS 198-1] for HMAC and [FIPS 180-4] for
SHA. (Key length is 512 bits)
Firmware implementation.
Note with referenceto IG
A.8: The module imple-
ments the HMAC-SHA-512
algorithmbut truncates the
output to 256 bits.
AES-256 CBC #A2009 Within IPsec for management plane
[FIPS 197] Advanced Encryption Standard al-
gorithm
[SP 800-38A] for CBC mode
[RFC3602] for CBC in IPsec
The Module supports 256-bit key lengths CBC
encrypt/decrypt modes.
Firmwareimplementation.
SHA-512 #A2009 - For SW/FW IntegrityTest and SW/FW Load
Test
- For Password storage
- For Databaseintegritycheck
- Conditioning component of the imple-
mented ENT (NP)
[FIPS 180-4] Secure Hash Standardcompliant
one-way (hash) algorithms. The cryptographic
module supports the SHA-2 (512-bit)
Firmwareimplementation.
RSA 4096 #A2009 - SW/FW Load Test (signature)
[FIPS 186-4] [PKCS#1] v1.5 and PSS RSA algo-
rithms.
- Signature verification using 4096-bit keys.
Note that RSA-PKCS#1 1.54096 verification
and RSA-PKCS#1 PSS 4096 verification are
available. RSA-PKCS#1 1.5is present for leg-
acy use only.
Firmwareimplementation.
AES-256 CTR #A2009 Payload encryption for data plane.
[FIPS 197] Advanced Encryption Standard al-
gorithm. The Module supports 256-bit key
lengths CTR encrypt/decrypt modes.
FPGA implementation.
CTR_DRBG #A2009 IPsec IVand key generation(management
plane).
[SP 800-90Ar1] DeterministicRandom Bits
Generator(CTR_DRBG basedon AES-256 with
256 bits of security strength, no derivation
function is used)
Firmwareimplementation.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
16 / 35
Algorithm CAVP cer-
tificate
Use Notes
CKG Vendor af-
firmed
Generationof AES-256 and HMAC keys.
Please note that the implementation uses the
‘direct generation’ of symmetric keys speci‐
fied in [SP 800-133r2].
With respect to Sec. 4 of [SP 800-133r2], the
cryptographicmodule uses the output of the
CTR_DRBG directlyfor key generation, i.e. no
XOR is implemented.
Firmware implementation.
KTS #A2009 IPsec-based Key Transport Scheme using a
combination of AES-256 in the CBC mode and
HMAC-SHA-512 providing 256 bits of encryp-
tion strength:
KTS (AES Cert. #A2009and HMACCert.
#2009).
Firmwareimplementation.
ENT (NP) N/A [SP 800-90B]
Entropy source providing 512 bits of entropy.
Firmwareimplementation.
Table 6: Approved cryptographic algorithms
Non-compliantbut allowedalgorithmswithno security claim:
Algorithm Use
PBKDF Used to derive a key from a string. This key is used to encrypt the IPsec keys for persistent
storage with AES-256-CBC.
This implementation is not compliant with [SP 800-132].
From a security perspective, IPsec keys are stored in the cryptographicmodule in plaintext.
Table 7: Non-compliant but allowed cryptographic algorithms
Non-FIPSapprovedalgorithm not to be used inFIPS mode: none.
2.2 Cryptographic port and interface
The device can come withone or two MPT-HLC modulesmounted.The description belowrefersto
the case of having a single cryptographic module available.
The cryptographic module providesa number of physical and logical interfacesto the device,and
the physical interfacesprovidedby the cryptographic module are mapped to four FIPS 140-2-de-
finedlogical interfaces:data input, data output, control input,and status output. The logical inter-
faces and their mappingare describedinthe followingtables.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
17 / 35
Figure 6: MPT-HLC ports and interfaces on front plane
Figure 7: MPT-HLC ports and interfaces on Backplane
FIPS Interface Physical Interface
Data Input Ethernetuser port
EthernetcouplingPort
RF portfromAntenna (Rx)
RF portfromAntenna (Rx-div)
RF portfrommateXPIC RF port
Data Output Ethernetuser port
Ethernetcouplingport
RF portto antenna (Tx)
Power am-
plifier
switch
Ethernet
user port
Ethernet
coupling
port
RF to
mate ra-
dio for
XPIC
RSL for an-
tenna
pointing
Debug
port (for
lab only)
Standby LED
for 1+1 oper-
ation
LED to indicate
radio is trans-
mitting
Power supply
Ethernet
port LEDs
RF coax from
antenna (Rx-
div)
RF coax from an-
tenna (Rx)
RF coax to
antenna
(Tx)
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
18 / 35
FIPS Interface Physical Interface
RF portto mate XPIC RF port
Control Input Ethernetuser port
Debugport(for labonly)
Status Output Ethernetuser port
EthernetportLEDs
Standby LED for 1+1 operation
LED to indicateradioistransmitting
RSL for antennapointing
Power interface Power amplifier switch
Power supply port
Table 8: Module interfaces
2.3 Roles,Service and Authentication
The followingsectionsprovide detailsabout the rolessupportedby the module,how they are au-
thenticated,and which servicesthey are authorized to access.
2.3.1 AuthorizedRoles
The encryptionmodule supports two roles,the Crypto Officer and the User role. Some servicesare
also available withoutauthentication(see Table 11). Configurationof the module occurs over a
single interface, to whicha single entitycan be connected ina point-to-pointmanner.
The module has two phases:
 The personalization phase (firstcommissioning),where akey generationrequestcan be sent
from a PC over Telnetusingthe “key_admin” user account. Logging into this account requires a
role-basedauthentication.Aftersuccessful authentication,the “key_admin” operator assumes
the Crypto Office role.
 The operational phase,where module managementis performed via the MSS, which acts as
the operator. Aftera role-basedauthentication usingIPsec,the MSS has the complete access
to configure and manage the module and simultaneously assumesthe followingtworoles:
o The Crypto Officerrole for all activitiesrelative tothe key duringoperational life of the
product.
o The User role to configure and manage the module and establish the remote peersecure
connection.
Afterstart-up and MSS authentication,itis the MSS’s responsibilitytocheck the type and version
of the cryptographic module.
Table 9 provides more informationfor the roles available ineach of the two phases.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
19 / 35
Phase Operator Type of Authentica-
tion
Type of Authentica-
tion
Authentication Data
Personalization key_admin Crypto Officer Role-based Password (via Telnet)
Operational MSS Crypto Officer and
User
Role-based IPsec datagramwithHMAC
Table 9: Roles and required identification and authentication
2.3.2 Authentication mechanisms
The module supports role-basedauthentication inthe personalization andthe operational phase.
Module operators must authenticate to the module before beingallowedaccess to services,which
require the assumptionof an authorized role.The module employsthe authenticationmethods
describedin the table below:
Operator Authentication
Mechanism
Strengthof Mechanism
MSS
(Crypto Officer
and User role)
Keys The IPsec keys are generatedusing the DRBG, whichprovides 256 bits
of entropy (full entropy). A correct authenticationrelies on the HMAC
key as well as on the usage of the correct encryption key.
Therefore, both need to matchwhich leads to 2^(2*256) combinations
for a single authentication attempt. Theprobability of a successful sin-
gle random authenticationattempt is one in 2^(2*256)=1.341E154
which is meeting the requirement (< 1 in 1,000,000).
For the probability of a successful authenticationwith random at-
tempts in one minute, 6 attemptsper minute are possible. Therefore,
the probability of a successful authenticationis 1-(1-1/(2^512))^6
which corresponds to one in 2.23463E153which is meeting the re-
quirement (less than one in 100,000).
key_admin
(Crypto Officer
role)
Password The password shall be changed during initialization.
The password lengthis 8 up to 25 characters(allalpha numerical up-
per/lower case sensitive w/o 'space'). Therefore, 26 lowercase charac-
ters +26 uppercase characters+10digits +31 special charactersare
available for each character.
In case of a password lengthof 8 charactersonly, the probability of a
successful single random authenticationattempt is one in 93^8 =
5.595E15which is meeting the requirement (< 1 in 1,000,000).
The probability of a successful authentication withrandom attemptsin
a one-minute period shall be less than1 in 100,000. Here, the number
of authenticationattemptsis limited to three in one minute. There-
fore, theprobability of a successful authenticationis 1-(1-1/(93^8))^3
which corresponds to one in 1.865E15which also meets the require-
ment (less than one in 100,000).
Table 10: Strengths ofauthentication mechanisms
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
20 / 35
2.3.3 Services
The approved servicesthat require operators to assume an authorized role (Crypto Officeror
User) as well asunauthenticatedservicesare listedin the table below. The cryptographic module
does not implementnon-approvedservices. Please note thatthe keysand Critical SecurityParam-
eters(CSPs) listedbelowuse the followingindicatorsto show the type of access performedby the
respective service:
 R (Read): The CSP is read.
 W (Write):The CSP is established,generated,ormodified.
 Z (Zeroize):The CSP is zeroized.
Service Operator Role Description Input Output Key/CSP Access
Connect to
key_admin
key_ad-
min
Unauthenti-
cated
Open a Telnet console
to authenticate as
key_admin and per-
form the key_admin
services. Change the
default password for
the key_admin account
at first connection or
the default account
Commands:
Open a Telnet
console with
telnet telnet-
init
Then type :
>Connect to
key-admin +
pwd
Prompt in the
key_admin
space
key_admin Pwd
(R)
Or
key_admin Pwd
(R/W) at first
connection
Change
key_admin
password
key_ad-
min
Crypto Officer Change the password
for the key_admin ac-
count after authentica-
tion
CLI Command:
>Password
Change
Command re-
sponse: Suc-
cess/fail
key_admin Pwd
(R/W)
Logout from
key_admin
key_ad-
min
Crypto Officer Exit from the key_ad-
min CLI
CLI command:
>Exit
None None
Generate IP-
sec keys
key_ad-
min
Crypto Officer Generate IPsec keys
(one for authentication
and one for encryption)
to use for IPsec
CLI Command:
>ipseckey gen-
erate
The crypto-
graphic module
outputs the
generated IP-
sec keys via the
control output
interface ofthe
physical user
Ethernet inter-
face to the ex-
ternal Telnet
client PC in
plaintext.
IPsec AES key
(W/R)
IPsec HMAC
key (W/R)
DRBG entropy
input (R)
DRBG key (R)
DRBG V (R)
Module re-
start
key_ad-
min
Crypto Officer Restart the module CLI Shell com-
mand:
>Restart Cold
Restart ofthe
module zero-
izes the OTA
encryption keys
stored in the
FPGA.
Restart of the
module
OTA AES key
A/B (Z)
DRBG entropy
input (Z)
DRBG key (Z)
DRBG V (Z)
MSS User Restart the module Proprietary no-
tification mes-
sage via MSS
Restart ofthe
module zero-
izes the OTA
encryption keys
Restart ofthe
module
Cold reset only:
OTA AES key
A/B (Z)
Warm and cold
reset:
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
21 / 35
Service Operator Role Description Input Output Key/CSP Access
stored in the
FPGA.
The MSS can
call a cold reset
or a warm re-
set. In case ofa
warm reset,
the FPGA oper-
ation is not
stopped and
OTA AES keys
are not zero-
ized.
DRBG entropy
input (Z)
DRBG key (Z)
DRBG V (Z)
Perform self-
tests on de-
mand
- Unauthenti-
cated
Used to initiate on de-
mand self-tests via
power-cycle.
Manual power
cycle operation
Restart of the
module
None
Equipment
start
MSS Unauthenti-
cated
When the module
starts, MSS needs to re-
cover some infor-
mation to properly
start the module.
Proprietary Te-
lemetry mes-
sage via MSS
Command re-
sponses:
MPT type, firm-
ware version,
remote inven-
tory,
Map ver-
sion(protocol)
None
Get start-up
self-test sta-
tus
MSS Unauthenti-
cated
Provide the readiness
of the module to go for
authentication mode
with self-test results.
Proprietary Te-
lemetry mes-
sage via MSS
Self-test results None
Configure
module
MSS User Configure the module,
radio parameters,
Ethernet parameters,
alarm notifications as
well as monitor the
performance ofthe
module.
Proprietary tel-
ecommand
message via
MSS
Commands re-
sponse
IPsec AES key
(R)
IPsec HMAC
key (R)
Enable over-
the-air pay-
load encryp-
tion
MSS Crypto Officer Although only a Crypto
Officer may configure a
secure data link, they
may enable and disable
encryption.
Proprietary tel-
ecommand
message via
MSS
Commands re-
sponse
IPsec AES key
(R)
IPsec HMAC
key (R)
Disable over-
the-air pay-
load encryp-
tion
MSS Crypto Officer Although only a Crypto
Officer may configure a
secure data link, they
may enable and disable
encryption.
Proprietary tel-
ecommand
message via
MSS
Commands re-
sponse
IPsec AES key
(R)
IPsec HMAC
key (R)
OTA AES key
A/B (Z)
Set over-the-
air encryption
keys
MSS Crypto Officer MSS is propagating
keys to the module to
use for the link encryp-
tion.
Afterwards, the keys
can be used when the
command “Switch
over-the-air AES key” is
received.
Keys are imported to
the cryptographic mod-
ule via an IPsec tunnel,
Proprietary tel-
ecommand
message via
MSS
Commands re-
sponse
OTA AES key
A/B (W)
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
22 / 35
Service Operator Role Description Input Output Key/CSP Access
i.e. in an encrypted and
authenticated manner.
Switch over-
the-air AES
key
MSS Crypto Officer The MSS instructs the
module to activate the
newly set OTA encryp-
tion key used for over-
the-air encryption.
Proprietary tel-
ecommand
message via
MSS
Commands re-
sponse
OTA AES key
A/B (R)
Transmit/re-
ceive data
MSS User Encrypt/Decrypt data
(AES-CTR) passing
through the module
(FPGA).
Data Encrypted/de-
crypted data
OTA AES key
A/B (R)
MSS identifi-
cation using
IPsec
MSS Unauthenti-
cated
Crypto Officer authenti-
cated locally by the
module. Crypto Officer
authenticated permits
the MSS to manage
crypto services. Each
request/command
IPsec datagram
from MSS con-
taining the au-
thentication di-
gest
Success/fail
IPsec secure
tunnel set-up
success or fail-
ure
IPsec AES key
(R)
IPsec HMAC
key (R)
IPsec keys ze-
roization
MSS Crypto Officer Delete the IPsec keys
and key_admin Pwd
CSPs from the module.
Proprietary tel-
ecommand
message via
MSS
IPsec keys and
key_admin
password are
removed from
the crypto-
graphic mod-
ule.
IPsec AES key
(Z)
IPsec HMAC
key (Z)
key_admin Pwd
(Z)
Change IPsec
keys
MSS Crypto Officer Request the crypto-
graphic module to gen-
erate new IPsec keys
and change them. MSS
recovers these keys
through the on-going
IPsec tunnel.
Proprietary tel-
ecommand
message via
MSS
Generate new
IPsec keys,
send them to
MSS. Reboot
and re-setup
IPsec session
with the new
IPsec keys, Old
Keys are zero-
ized using ser-
vice IPsec keys
zeroization.
IPsec AES key
(R/W/Z)
IPsec HMAC
key (R/W/Z)
Firmware up-
grade
MSS User Upgrade the firmware
of the module. Ifthe
firmware loading is suc-
cessful, loads thenew
firmware units into
module and reboots
the module to allow
the new firmware to
become operational. If
the firmware upgrade
fails, then the new
firmware is not loaded
to the module the
Proprietary tel-
ecommand
message via
MSS
Success/Fail
The crypto-
graphic module
is running the
new SwP ifthe
proof of origin
is passed.
No new SwP is
downloaded to
the crypto-
graphic module
if the proofof
origin fails.
None
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
23 / 35
Service Operator Role Description Input Output Key/CSP Access
module remains opera-
tional with the old firm-
ware.
Activation hap-
pens only on
successful firm-
ware download
Table 11: Services authorized for roles and access rights within services
Please note that the firmware update service results ina newversionof the cryptographic mod-
ule.The firmware update shouldonly be performedwith FIPS validated firmware images.
The cryptographic module implementsthe WKAT mechanism,which automaticallychecks if OTA
keysare identical onboth ends of the communication channel.This is implementedasa known-
answer test.Both keysare synchronizedby transmitting the generatedWKAT ciphertextviathe
encryptionline.In case of a mismatch, the MSS triggers the generationand establishmentof a
newset of keys.The WKAT mechanismis not considereda security service and the WKAT plaintext
or ciphertextare not consideredCSPs.
The cryptographic module doesnot support bypass functionality.
2.4 Physical Security
The module is entirelyencasedbya thick steel chassis (calledsub-rack). The back of the chassis
has vent holesto allowair to flowacross componentswithinthe module to provide coolingand
preventoverheating. Internally,ithas a backplane into whichup to two MPT-HLC modules may be
inserted.
Figure 8 shows the chassis withtwo MPT-HLC modulesinserted.Incase the second MPT-HLC is
missing, the corresponding slotin the chassis shall be coveredby a blankingplate (part number:
3EM22616AA; see Figure 3).
Figure 8: Two MPT-HLC modules inserted into the chassis
For the module to operate in the FIPS-approvedmode of operation, a total of eightanti-tampering
labelsshall be appliedto the MPT-HLC module(s), the MPT-HLC Sub-Rack MA-Cover,and, if appli-
cable,the blankingplate,such that for each itemthat borders the chassis there is a label joining
the itemto the chassis. Figure 9 shows the placementof the four front-side labelsdependingon
whetherone or two MPT-HLC modulesare inserted intothe chassis. Two labels shall be usedper
inserted item.The four back-side labels shall be installedas shownin Figure 10. Before deliveryto
the customer, the ordered MPT-HLC module(s),the MPT-HLC Sub-Rack MA-Cover, and, if applica-
ble,the blankingplate are mounted inthe chassis at the factory and an initial setof anti-tamper-
ing labels isapplied as specifiedabove.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
24 / 35
Figure 9: Anti-tampering label placement at the front-side of the cryptographic module (left: one MPT-HLC module and blanking
plate on empty slot; right: two MPT-HLC modules)
Figure 10: Anti-tampering label placement at the back-side ofthe cryptographic module (top view and underside)
The followinggraphicsillustrate the tamper-evidentlabels.Figure 11 illustratesa tamper-evident
label withno evidence of tampering.
Figure 11: Tamper-evident label: intact
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
25 / 35
Figure 12 illustratesa tamper-evidentlabel thatshowssigns of tampering. Figure 13 is a magnified
viewof the broken label.
Figure 12: Tamper-evident label: broken (normal view)
Figure 13: Tamper-evident label: broken (close-up view)
Anti-tampering labels
Anti-tamperinglabels(partnumber: 3DB76375AA) are adhesive sealsbeingdestroyedin case of
any attempt of removal.
Each label is serializedina unique mode not permittingany unwanted replacement
Figure 14: Anti-tampering label design
YY and WW are respectively the yearand weekof label production,while the five-digitnumeric
fieldgetsa sequential value from00001 to 99999. It resetsat any year/weekchange.
Apply Labels
When applyingAnti-Tamperlabels,ensure that:
 The surface temperature to be sealedis at minimum+10°C
 The surface to be sealedisdry. Moisture of any kindcan cause a problem.Wipe the area
witha clean paper towel.
 Cleanthe surface with 100% isopropyl alcohol (*).Wipe the area with a cloth or paper
towel alcohol dry withclean dry cloth or paper towel
 Wait 48 hours for the adhesive to cure
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
26 / 35
When an anti-tamperinglabel must be removed:
 peel itout
 remove the label residualscleaningthe area witha cloth or paper towel soaked with100%
isopropyl alcohol (*)
 Note (*): Avoid usingrubbing alcohol;it can leave an oilycoating that will interfere with
adhesionof the label.
Inspect labels
The Crypto Officeris also responsible forinspectingthe anti-tamperinglabels on the shelvesat
leasteverythree months. If any evidence of tamperingis observedon the tamper-evidentseals,
the module shall be considered as beingin a non-compliantstate. Upon such discovery,the Admin
shall decommissionthe module and return to the vendor.
Opacity
The chassis has vent holesat the back. In correspondence to the digital board, the ventholesare
coveredby a dedicatedcover (part number: 3DB76330AA) that prevents line of sight viewof any
internal components (see Figure 15). The cover alsomakes the back-panel board inaccessible ex-
cept for its HSB switchconnector.
Figure 15: Cover on the rear side of the chassis for opacity ofthe digital board and protection ofthe back panel board
2.5 Operational Environment
Section4.6.1 of the FIPS140-2 standard is not applicable.The module isa hardware module witha
limitedmodifiable operational environment embedded firmware.
2.6 Cryptographic Key Management
For an algorithm implementationtobe listedon a cryptographic module validationcertificate as
an Approved securityfunction,the algorithmimplementationshall meetall the requirementsof
FIPS 140-2 and shall successfullycomplete the cryptographic algorithm validation process.
The followingtable identifieseachof the CSPs associatedwith the cryptographic module.For each
CSP, the followinginformationisprovided:
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
27 / 35
 The name of the CSP/Key
 The type of CSP and associatedlength
 A descriptionof the CSP/Key
 Storage of the CSP/Key
 The zeroizationfor the CSP/Key
Please note that the public RSA keysused for the SW/FW integritytest are not consideredas CSPs.
The same appliesto other keysused onlyfor self-testingpurposes andthe keysderivedusingthe
non-compliantPBKDF implementation.
Key/CSP Size Description Storage Generated/Entry/Output Zeroization
DRBG entropy input 384 bits This is the entropy following
[SP 800-90B] for the CTR-
DRNG following [SP 800-
90Ar1].
RAM Generated using entropy
source validated per [SP 800-
90B].
Module restart
DRBG key 256 bits DRBG key for the
CTR_DRBG as defined in [SP
800-90Ar1] for AES256.
RAM Generated as part of the
CTR_DRBG instantiation as
specified in [SP 800-90Ar1]
Sec. 12.2.1.3.
Module restart
DRBG V 128 bits Internal V value used as
part of the DRBG following
[SP 800-90Ar1].
RAM Instantiated/updated based
on the DRBG’s entropy input.
Module restart
IPsec HMAC key 512 bits HMAC-SHA 512. It authenti-
cates the IPsec packet.
EEPROM Generated at commissioning
or at renewal request.
Zeroization service
and overwritten after
renewal
IPsec AES key 256 bits This is the CO configured
key used to protect trans-
mission of session keys. Al-
gorithm used is AES-CBC.
EEPROM Generated at commissioning
or at renewal request.
Output in plaintext as the re-
sponse to the IPsec key gen-
eration process initiated by
the key_admin operator.
Output via the IPsec KTS as
the response to the IPsec key
generation process initiated
by the MSS operator.
Zeroization service
and overwritten after
renewal
OTA AES key A/B 256 bits Key used to encrypt and de-
crypt data traffic. Algorithm
used is AES-CTR.
Two alternative keys A and
B can be configured, but
only one key is active.
Stored in
write-only de-
vice registers
in FPGA
Imported across encrypted
IPsec link from MSS.
Module restart and
“Disable over-the-air
payload encryption”
service.
key_admin Pwd Password with 8
to 25 characters
(see Sec. 2.3.2)
Password for key_admin au-
thentication.
Flash Imported across encrypted
IPsec link from MSS.
Never exits the module.
Zeroization service
Table 12: Cryptographic keys and CSPs
As stated inSection 2.3.3, the WKAT plaintextforkeysynchronizationbetweenboth endsof the
OTA communication channel are not consideredCSPs.
2.6.1 Random Number Generators
The module contains an approved SP 800‐90Ar1 CTR_DRBG seededbya non-physical entropy
source ENT (NP) compliantto [SP800-90B]. The entropysource providesan output of 512 bits
containingfull entropy. Thisentropy pool isused for seedingthe CTR_DRBG.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
28 / 35
2.6.2 KeyGeneration
The module generates symmetric keysfor IPsec tunnel incompliance withrequirementsof FIPS
140-2 standard usingoutput of the FIPS approvedSP 800-90Ar1 DRBG. Please see Table 12 for de-
tails. The cryptographic module implementsthe directgenerationof symmetrickeys as specified
in [SP 800-133r2].
2.6.3 KeyEntry/Output
Please see Table 12 for details.All keysare entered into or output from the module in a secure
manner. Besidesthe key inputand output listedin Table 12, no key input or output is imple-
mented.
The Cryptographic module receivesthe over-the-airAES keysin encrypted form via the IPsec chan-
nel establishedwiththe MSS. This corresponds to a keytransport scheme with a security strength
of 256 bits.
2.6.4 Zeroizationprocedure
Please see Table 12 for details.
IPsec keysas well as the key_adminpassword can be zeroizedusingthe keyzeroizationservice.
This is a Crypto Officerservice requiringCrypto Officer authentication.
Over-the-airAESkeys as well as DRBG CSPsare zeroizedbyperforminga power cycle.
The Over-the-airAES keyscan be also zeroizedusingthe “Disable over-the-airpayloadencryption”
service.
2.7 Electromagnetic Interference /ElectromagneticCompatibility(EMI/EMC)
The module is classifiedasintentional radiators.It is conforming to FCC part 101.
2.8 Self-Tests
Self-testsare healthchecks that ensure that the cryptographic algorithmswithinthe module are
operatingcorrectly. The self-testsidentifiedinFIPS140-2 fall withintwo categories:
1. Power-upSelf-Tests
2. Conditional Self-Tests
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
29 / 35
2.8.1 Power-upSelf-Tests
The cryptographic module performsknown answertests and critical functionstests at powerup
withoutany furtheruser interaction.See table:
Self-test performed in Algorithm Description
CPU (warm and cold re-
set)
DRBG KATs of the instantiate, generate, andreseed
functions.
RepetitionCount Test and
Adaptive Proportion Test
As per [SP 800-90B] for 1024 samples.
HMAC KAT (512-bit key)
AES-CBC Encrypt and decrypt KAT (256-bit key)
RSASSA-PKCSS1-v1.5
RSA-PSS
Signature verification KAT
Firmwareintegrity test RSA signatureverification for firmware pack-
ageproof of origin and integrity.
FPGA (cold reset only) AES-CTR Encrypt KAT (256-bit key)
Table 13: Power-up self-tests
2.8.2 Conditional Self-test
The cryptographic module performsthe followingconditional self-tests:
Test Description
Firmwareload test Integrityand RSAsignature verification.
Condition: Firmware loading
Repetitioncount test and adaptive
proportion test from [SP 800-90B]
For FIPS approved noise source.
Condition: Continuous health testing of the noise source.
Table 14: Conditional self-tests
As per IG 9.8, the CTR_DRBG and the ENT (NP) do not implementacontinuous random-number
generator test (CRNGT) as specifiedinAS.07.04 and AS.09.41 of the FIPS 140-2 standard.
2.8.3 Self-testerrorhandling
If any of the identifiedPOSTs (Power-OnSelf-Test) fail,the module will notenteran operational
state and will insteadprovide an error message.The module will thenbe placedin an error state.
If the SW/FW Load Test fails,the new firmware is not loaded.In thiscase, the module does not en-
ter an error state, it but goesback to operation.
If eitherof the RBG health testfails,the module raises an alarm to warn about the lack of random-
nessof the DRBG, an error message is providedand the module performs a power cycle,which in-
cludesfull self-testing.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
30 / 35
Please note that the cryptographic module implementsacold reset and a warm reset (see service
Module restart in Section 2.3.3). In case of the cold reset,the complete module is reset(CPU and
FPGA). In case of a warm reset,onlythe CPU-part is resetwhile the FPGA keepsrunning. Self-tests
executedas part of a partial module restart resultingfrom a warm resetdo not preventFPGA out-
put as the FPGA isconsideredto remain in a self-testedstate.A warm reset also doesnot triggera
self-testof the FPGA. Both duringexecutionof the self-tests(exceptinthe aforementionedcondi-
tions) and while inan error state, data output is inhibited.
2.9 DesignAssurance
Nokiaemploysindustry standard best practices in the design& development,configurationMan-
agement, documentation, and delivery of the Wavence products, includingthe Encryption mod-
ule.
Nokiahas a TL 9000 Certified QualityManagement System.
2.9.1 Designand Development
The designand developmentof the cryptographic module is basedon the “Nokia MN CREATE”
product Life Cycle (PLC).
The PLC consists of Phasesseparated by Program Milestones.A Program Milestone isthe synchro-
nizationpoint between all stakeholders.Ata Program Milestone,the resultsof the preceding
phase and the conditionsto proceed to the nextphase are assessed,and the decisionismade
whetherto approve successful completionof the precedingphase and to proceedto the next
phase.A Program Milestone ensuresalignmentwithbusinessstrategy and portfoliomanagement
process and requiresmanagement approval.DecisionReviewsensure visibilityof product/project
status across the corporation.
For each newproduct or solutiondevelopment,adedicatedmulti-competencesteamiscreated to
manage the Program calleda Program Management Team (PMT). The PMT is responsible forthe
proper implementationof the PLC.
2.9.2 ConfigurationManagement
The purpose of ConfigurationManagement (CM) is to establishand preserve the integrityof all
work products throughout theirlife cycle.
Work products are uniquelyidentified,theirversionandstatus are maintained,changes to re-
leasedwork products are formallycontrolled,dependenciesbetweenworkproducts are main-
tained,and problemsare registeredand traced to their solution.
The ConfigurationManagement process identifiesthe itemsthatform the configurationthat will
be developedforthe project, baselinesthese items,andmanages changes to the items.
This CM process is implementedinthe Product Data Management database (“PDM”).
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
31 / 35
Other dedicatedtoolsare usedto manage Requirements,Tests,fault Reports,Change requests.
2.9.3 Guidance documents
This encompassesall the manuals neededfor the end users to install,commission,andoperate
the Wavence product family.
The inputsare providedby the persons in the developmentactivitieshavingthe bestknowledge of
each subject to be addressed in the manuals. These inputs are providedto the Customer Docu-
mentationTeam whoinserts themin the user manualsin the most appropriate format and at the
right place.
Reviewsare performedto check and validate the evolutionsbefore publishing.
For the Wavence radio secure mode,the guidance documents are made of:
 The standard setof Wavence user manuals,associated to the firmware package (see Sec-
tion 1.2).
 The specificsecure mode user manual. Guidance appropriate to an operator’s role is pro-
videdwiththe module and providesall of the necessary assistance to enable the secure
operationof the module by an operator, includingthe approvedsecurity functionsof the
module.
2.10 Delivery
The cryptographic module isprotected withsecurity labelsas shown inSection 2.4 above.These
labelsshall be checkedby the Crypto Officerbefore performinginitializationtasks.
Additionally,toidentifyavalidatedproduct, users shall check the part number printedon a sticker
gluedto the enclosure.Besidesthat, the hash or the versioninformationof the installed firmware
unitsas part of the firmware package shall be checked. Please see Section 1.2 for details.
2.10.1 SW elementsdelivery.
The SW streamingstrategy is organizedaround a single Mainstream, avoidingfeature branches.
This simple streamingstrategy reliesonthe ContinuousIntegration (CI) chain to guaranty the
Qualityof the Mainstream.
The featuresdevelopmentisiterative andincremental.
Each iterationallowsmoving forward on feature developmentaddingnew functionality ontop of
existingonesuntil the full feature is complete and deliveredforthe final tests.
Then, as part of the CI chain, Non-Regression Tests(NRT) are executed.
If no issuesare observed,the SW is promotedto Release Candidate status with:
1. SW Package versionand date of creation,
2. List of componentsand componentversionsmaking up the SW package delivery.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
32 / 35
2.10.2 Product Release and SWP identification
The Secure mode is supportedby the Product Release Wavence 20A (Commercial Naming).
A Revisionnumberis usedwhen maintenance versionsare published.The firstpublicationis Rev
01.
The SWP associated to the Product Release is identifiedbya SW Package version.
The listof the SW components in the SW package versionwith theiridentificationsandversionsis
displayedinthe CustomerRelease Note (CRN).
This listcan be verified inthe Cryptographic Module via the Craft Terminal.
There isa specificWavence 20A secure mode SW package.
A µSD master image is then created and archived inthe technical database (PDM) under a dedi-
cated code.
2.10.3 Secure mode solutiondelivery
The Secure Mode SWP isloadedin the station viaa µSD memory: The Secure Mode SWP µSD mas-
ter image isretrievedby the factory from the PDM database.
Then the factory:
 Assemblesthe complete stationin a rack, includingthe cryptographic module shelf and the
Microwave Service Switch shelf fullyequipped,
 Powersup the station. During thisprocess, the secure mode SW is downloaded tothe cryp-
tographic module.
 Runs the station commissioningprocess.
 Runs the station tests.
 When all the station tests are done and OK, the MPT-HLC Sub-Rack MA-Cover is installed
and all requiredanti-tamperinglabelsare applied.
Deliveryof the complete station, includingthe cryptographic module and some replacementanti-
tampering labels,tocustomers from the vendor is done via thirdparty forwarders.
Customers can order the followingreplacementkits:
Name Part number Contents (see Table 1)
HLC sub-rack anti-
tampering kit
3DB76333AA 1 MPT-HLC Sub-Rack MA-Cover (part number: 3DB76330AA)
8 Anti-Tampering Labels (part number: 3DB76375AA)
FIPS maintenance
kit
3DB19786AA 1 MPT-HLC Sub-Rack Blank Filler Panel (part number: 3EM22616AA)
8 Anti-Tampering Labels (part number: 3DB76375AA)
Table 15: Replacement kits
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
33 / 35
2.11 Mitigation of OtherAttacks Policy
The module does not claim to mitigate any other attacks beyondthose specifiedinFIPS140-2.
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
34 / 35
3 Configuringthe MPT-HLCfor SecureOperation
The followingstepsare requiredto put the Module intoa FIPSapproved mode of operation.
3.1 Installation
The MPT-HLC isa subsystembelongingto the Wavence product. It cannot operate in a standalone
manner in thisconfiguration.
To run in FIPSmode of operation,MPT-HLC is deliveredwitha FIPS flag hard codedin the firm-
ware version.
The MSS acting as the master sub-systemshall drive the MPT-HLC into the FIPS mode operation.
MSS is alsodelivered torun ina securedmode of operationfrom factory.
The Crypto Officermust verifyat installation thatthe MPT-HLCs tamper-evidentsealshave not
beenaltered.
1) Connect MPT-HLC with PC in 192.168.100.XXX VLAN 4080 through RJ45 / optical converter
to user access MPT-HLC 192.168.100.1
2) Powerup the MPT-HLC
3) Open a Telnetconsole with followingcredential telnettelnet-init
4) Connect to key_admin shell withfollowing command:
 connect to key-admin
then enterthe defaultpassword: key_admin
5) Afterauthenticationwith the defaultpassword,a newkey_admin password shall be en-
tered
6) To generate CSP keystype the followingcommand:
 ipseckeygenerate
The cryptographic module thenreturns the AuthenticationKeyand Encryption Key
as shown in the followingfigure:
Figure 16: Example of the returned data for the ipseckey generate command
7) Copy/Paste the 2 linesof parameters
8) Type “exit” to exitthe shell
9) Unplug the PC from MPT-HLC
10) Powerthe MSS
3DB225000009DSZZA v2.4 © 2023 Nokia
May be reproduced only in its original entirety
35 / 35
11) Login as administrator with WebCT to configure the MPT-HLC on the MSS. (see user’s man‐
ual for details)
12) Login as Crypto OfficerwithWebCT (MPT-HLC alreadydefinedinMSS).
13) Configure the MPT-HLC IPsec parameters previouslycopiedon WebCT MPT-HLC radio
panel associated to the MPT-HLC
14) Connect the MPT-HLC to the MSS with the Ethernet cable as definedinthe WebCT user’s
manual.
15) Powercycle the MPT-HLC
Important:
The Crypto Officer shall make sure the generated IPsec keys shown on screen shall be kept confi-
dential. In addition, the Crypto Officer should make sure that key values do not remain in the PCs
clipboard as keysare enteredto the MSS usingcopy & paste.
3.2 Initialization
When MPT-HLC and MSS start the communication, the IPsec stack isinitialized withthe keysen-
teredat commissioning(installationphase). MSSis authenticatedinto MPT-HLC automatically
based on the IPsecauthenticationcapability.
In case provisioningwas not properlydone,alarms are displayed tothe operator.
The IPsec Keyscan be updated using the WebCT configurator of MSS.
MPT-HLC will regenerate anew set of IPsec parameter that will be exchangedon the secure link.
Then the IPsecconnection will be closed,key zeroized,and reinitialized withthe newsetof param-
eters.
The use of the MSS in “secure mode” locks out the use of non‐approvedalgorithmson MPT-HLC
and performs all the authenticationneededfor the MSS/MPT-HLC communication.
3.3 Initializationof encryptionkeys
Wavence usesAdvanced Encryption Standard (AES)-256 keys to encrypt clienttraffic overthe ra-
dio link.Encryptionkeys are zeroizedby any of the followingactions,resultingina loss of traffic:
Zeroization of cryptographic keys isdetailedin Table 11.
Disablingencryptionfor a radio direction.Thisaction zeroizesthe encryptionkey for the MPT-HLC.
Decommissioningthe system.This action zeroizesall encryptionkeys on the system.
Restarting the system or the MPT-HLC sub system.