FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation          FIPS 140‐2 Non‐Proprietary Security Policy      Symantec NetBackup Cryptographic Module   Software Version 1.0      Document Version 1.0    January 13, 2015    Prepared For:  Prepared By:      Symantec Corporation  SafeLogic Inc.   350 Ellis Street  530 Lytton Avenue, Suite 200  Mountain View, CA 9404  Palo Alto, CA 94301  www.symantec.com   www.safelogic.com   Document Version 1.0  © Symantec Corporation  Page 1 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation      Abstract   This document provides a non‐proprietary FIPS 140‐2 Security Policy for Symantec NetBackup  Cryptographic Module.  Document Version 1.0  © Symantec Corporation  Page 2 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  Table of Contents 1  Introduction .............................................................................................................................................. 5  About FIPS 140 .............................................................................................................................................    1.1  5 About this Document  ...................................................................................................................................    1.2  . 5 External Resources .......................................................................................................................................    1.3  5 Notices  .........................................................................................................................................................    1.4  . 5 Acronyms ......................................................................................................................................................    1.5  5 2  Symantec NetBackup Cryptographic Module .............................................................................................. 7  Cryptographic Module Specification ............................................................................................................    2.1  7 2.1.1  Validation Level Detail .............................................................................................................................    7 2.1.2  Approved Cryptographic Algorithms .......................................................................................................    7 2.1.3  Non‐Approved Cryptographic Algorithms .............................................................................................  0  1 2.2  Module Interfaces ......................................................................................................................................  1  1 2.3  Roles, Services, and Authentication ...........................................................................................................  2  1 2.3.1  Operator Services and Descriptions.......................................................................................................  2  1 2.3.2  Operator Authentication .......................................................................................................................  3  1 2.4  Physical Security .........................................................................................................................................  3 1 2.5  Operational Environment ...........................................................................................................................  4  1 2.6  Cryptographic Key Management ...............................................................................................................  4  1 2.6.1  Random Number Generation ................................................................................................................  6  1 2.6.2  Key/Critical Security Parameter (CSP) Authorized Access and Use by Role and Service/Function .......  6  1 2.6.3  Key/CSP Storage ....................................................................................................................................  6  1 2.6.4  Key/CSP Zeroization ...............................................................................................................................  6  1 2.7  Self‐Tests ....................................................................................................................................................  6  1 2.7.1  Power‐On Self‐Tests ..............................................................................................................................  7  1 2.7.2  Conditional Self‐Tests ............................................................................................................................  9  1 2.7.3  Cryptographic Function .........................................................................................................................  9  1 2.8  Mitigation of Other Attacks .......................................................................................................................  9  1 3  Guidance and Secure Operation ................................................................................................................  0  2 3.1  Crypto Officer Guidance .............................................................................................................................  0  2 3.1.1  Software Installation ..............................................................................................................................  0  2 3.1.2  Additional Rules of Operation ...............................................................................................................  0  2 3.2  User Guidance ............................................................................................................................................  0  2 3.2.1  General Guidance ..................................................................................................................................  0  2   Document Version 1.0  © Symantec Corporation  Page 3 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  List of Tables   Table 1 – Acronyms and Terms  .....................................................................................................................................    . 6 Table 2 – Validation Level by FIPS 140‐2 Section  ..........................................................................................................    . 7 Table 3 – FIPS‐Approved Algorithm Certificates ............................................................................................................    9 Table 4 – Logical Interface / Physical Interface Mapping ............................................................................................  2  1 Table 5 – Module Services, Roles, and Descriptions....................................................................................................  3  1 Table 6 – Module Keys/CSPs  .......................................................................................................................................  6  . 1 Table 7 – Power‐On Self‐Tests .....................................................................................................................................  8  1 Table 8 – Conditional Self‐Tests  ..................................................................................................................................  9  . 1   List of Figures   Figure 1 – Module Boundary and Interfaces Diagram .................................................................................................  1 1 Document Version 1.0  © Symantec Corporation  Page 4 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  1 Introduction 1.1 About FIPS 140 Federal Information Processing Standards Publication 140‐2 — Security Requirements for Cryptographic  Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but  Unclassified environment. The National Institute of Standards and Technology (NIST) and  Communications Security Establishment Canada (CSEC) Cryptographic Module Validation Program  (CMVP) run the FIPS 140 program. The NVLAP accredits independent testing labs to perform FIPS 140  testing; the CMVP validates modules meeting FIPS 140 validation. Validated is the term given to a  module that is documented and tested against the FIPS 140 criteria.  More information is available on the CMVP website at  http://csrc.nist.gov/groups/STM/cmvp/index.html.  1.2 About this Document This non‐proprietary Cryptographic Module Security Policy for the NetBackup Cryptographic Module  from Symantec provides an overview of the product and a high‐level description of how it meets the  security requirements of FIPS 140‐2. This document contains details on the module’s cryptographic keys  and critical security parameters. This Security Policy concludes with instructions and guidance on  running the module in a FIPS 140‐2 mode of operation.   Symantec NetBackup Cryptographic Module may also be referred to as the “module” in this document.   1.3 External Resources The Symantec website (www.symantec.com) contains information on Symantec services and products.  The Cryptographic Module Validation Program website contains links to the FIPS 140‐2 certificate and  Symantec contact information.  1.4 Notices This document may be freely reproduced and distributed in its entirety without modification.  1.5 Acronyms The following table defines acronyms found in this document:     Document Version 1.0  © Symantec Corporation  Page 5 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation    Acronym  Term  AES  Advanced Encryption Standard  ANSI  American National Standards Institute  API  Application Programming Interface  CMVP  Cryptographic Module Validation Program  CO  Crypto Officer  CSEC  Communications Security Establishment Canada  CSP  Critical Security Parameter  DES  Data Encryption Standard  DH  Diffie‐Hellman  DSA  Digital Signature Algorithm  EC  Elliptic Curve   EMC  Electromagnetic Compatibility   EMI  Electromagnetic Interference  FCC  Federal Communications Commission  FIPS  Federal Information Processing Standard  GPC  General Purpose Computer  GUI  Graphical User Interface  HMAC  (Keyed‐) Hash Message Authentication Code  KAT  Known Answer Test   MAC  Message Authentication Code  MD  Message Digest  NIST  National Institute of Standards and Technology  OS  Operating System  PKCS  Public‐Key Cryptography Standards  PRNG  Pseudo Random Number Generator  PSS  Probabilistic Signature Scheme  RNG  Random Number Generator  RSA  Rivest, Shamir, and Adleman  SHA  Secure Hash Algorithm  SSL  Secure Sockets Layer  Triple‐DES  Triple Data Encryption Algorithm  TLS  Transport Layer Security  USB  Universal Serial Bus  Table 1 – Acronyms and Terms      Document Version 1.0  © Symantec Corporation  Page 6 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  2 Symantec NetBackup Cryptographic Module 2.1 Cryptographic Module Specification The Symantec NetBackup Cryptographic Module provides cryptographic functions for Symantec  NetBackup.  The module's logical cryptographic boundary is the shared library files and their integrity check HMAC  files. The module is a multi‐chip standalone embodiment installed on a General Purpose Device.   All operations of the module occur via calls from host applications and their respective internal  daemons/processes. As such there are no untrusted services calling the services of the module.  2.1.1 Validation Level Detail The following table lists the level of validation for each area in FIPS 140‐2:  FIPS 140‐2 Section Title  Validation Level  Cryptographic Module Specification  1  Cryptographic Module Ports and Interfaces  1  Roles, Services, and Authentication  1  Finite State Model  1  Physical Security  N/A  Operational Environment  1  Cryptographic Key Management  1  Electromagnetic Interference / Electromagnetic Compatibility  1  Self‐Tests  1  Design Assurance  1  Mitigation of Other Attacks  N/A  Table 2 – Validation Level by FIPS 140‐2 Section  2.1.2 Approved Cryptographic Algorithms The module’s cryptographic algorithm implementations have received the following certificate numbers  from the Cryptographic Algorithm Validation Program:          Document Version 1.0  © Symantec Corporation  Page 7 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation    Algorithm  CAVP Certificate  AES  2273  HMAC‐SHA‐1, HMAC‐SHA‐224, HMAC‐SHA‐256, HMAC‐ SHA‐384, HMAC‐SHA‐512  1391  DSA, DSA 2  709  FIPS 186‐2  PQR Ver: Sig Ver‐ 1024‐bit    F186‐4  PQG Gen: 2048 & 3072 (using SHA‐2)  PQG Ver: 1024, 2048 & 3072 (using SHA‐1 and SHA‐2)  Key Pair: 2048‐bit & 3072‐bit  Sig Gen: 2048‐bit & 3072‐bit (using SHA‐2)  Sig Ver: 1024‐bit. 2048‐bit & 3072‐bit (using SHA‐1 & SHA‐2)  ECDSA, ECDSA2  368  FIPS 186‐2  PKG: Curves (P‐224, P‐256, P‐384, P‐521, K‐233, K‐283, K‐409, K‐571, B‐233, B‐409  & B‐571)  PKV: Curves All P, K & B    FIPS 186‐4  PKG: Curves (P‐224, P‐256, P‐384, P‐521, K‐233, K‐283, K‐409, K‐571, B‐283, B‐409  & B‐571)  PKV: Curves All P, K & B  Sig Gen: (P‐224, P‐256, P‐384, P‐521, K‐233, K‐283, K‐409, K‐571, B‐283, B‐409 & B‐ 571) (SHA‐2)  Sig Ver: Curves P‐192, P224, P‐256, P‐384, P‐521, K‐163, K‐233, K‐283, B‐163, B‐ 233, B‐283, B‐409 & B‐571 (any SHA size)  K‐409 & K‐571 (SHA‐1)  Document Version 1.0  © Symantec Corporation  Page 8 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  RSA (X9.31, PKCS #1.5, PSS)  1166  FIPS 186‐2  ANSIX9.31  Key Gen: 2048‐bit, 3072‐bit & 4096‐bit  Sig Gen: 2048‐bit, 3072‐bit & 4096 bit (any SHA size)  Sig Ver: 1024‐bit, 1536‐bit, 2048‐bit, 3072‐bit & 4096‐bit (any SHA size)    PKCS1 V1 5  Sig Gen: 2048‐bit, 3072‐bit & 4096‐bit (any SHA size)  Sig Ver: 1024‐bit, 1536‐bit, 2048‐bit, 3072‐bit & 4096‐bit (any SHA size)    PSS  Sig Gen: 2048‐bit, 3072‐bit & 4096‐bit (any SHA size)  Sig Ver: 1024‐bit, 1536‐bit, 2048‐bit, 3072‐bit & 4096‐bit (any SHA size)    FIPS 186‐4  ANSIX9.31  Sig Gen: 2048‐bit (using SHA‐2)  Sig Ver: 1024‐bit, 2048‐bit, & 3072‐bit (any SHA size)    PKCS1 V1 5  Sig Gen: 2048‐bit & 3072‐bit (using SHA‐2)  Sig Ver: 1024‐bit, 2048‐bit, & 3072‐bit (any SHA size)    PSS  Sig Gen: 2048‐bit & 3072‐bit (using SHA‐2)  Sig Ver: 1024‐bit, 2048‐bit, & 3072‐bit (any SHA size)  SHA‐1, SHA‐224, SHA‐256, SHA‐384, SHA‐512  1954  Triple‐DES  1420  Note: the use of two‐key Triple DES for encryption is restricted through December  31st, 2015: the total number of blocks of data encrypted with the same  cryptographic key shall not be greater than 2^20. After December 31, 2015, two‐ key Triple DES shall not be used for encryption.  RNG (ANSI X9.31)  1132  SP 800‐90 DRBG (Hash_DRBG, HMAC_DRBG, CTR_DRBG, Dual_EC_DRBG)  281  CVL (ECC CDH KAS)  44  Table 3 – FIPS‐Approved Algorithm Certificates  Document Version 1.0  © Symantec Corporation  Page 9 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  2.1.3 Non‐Approved Cryptographic Algorithms The module supports the following non‐FIPS 140‐2 approved but allowed algorithms:     RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of  encryption strength; non‐compliant less than 112 bits of encryption strength)   EC Diffie‐Hellman (key agreement; key establishment methodology provides between 112 and  256 bits of encryption strength; non‐compliant less than 112 bits of encryption strength)  The following algorithms are disallowed as of January 1, 2014 per the NIST SP 800‐131A algorithm  transitions:   FIPS 186‐2 DSA (using SHA‐1):    PQG Gen‐ 1024‐bit  Key Gen‐ 1024‐bit  Sig Gen‐ 1024‐bit   FIPS 186‐4 DSA    PQG Gen, 1024‐bit (any SHA size)  Key Gen, 1024‐bit  Sig Gen, 1024‐bit (any SHA size), 2048‐bit & 3072‐bit using SHA‐1   FIPS 186‐2 RSA    ANSIX9.31  Key Gen 1024 & 1536  ANSIX9.31  Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA‐1  PKCSI V1 5  Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA‐1  PSS  Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA‐1   FIPS 186‐4 RSA    ANSIX9.31  Sig Gen 1024 using SHA‐1  PKCSI V1 5  Sig Gen 1024 using SHA‐1  PSS  Sig Gen 1024 using SHA‐1      Document Version 1.0  © Symantec Corporation  Page 10 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation   FIPS 186‐2 ECDSA  PKG: Curves  P‐192, K‐163 & B‐163  Sig Gen Curves  All P, K & B   FIPS 196‐4 ECDSA  PKG: Curves  P‐192, K‐163 & B‐163  Sig Gen Curves  P‐224, P‐256, P‐384, P‐521, K‐233, K‐283, K‐409, K‐571,  B‐233, B‐283, B‐409 & B‐571) (using SHA‐1)  P‐192‐, K‐163 & B‐163 (any SHA size)  2.2 Module Interfaces The figure below shows the module’s physical and logical block diagram:    Figure 1 – Module Boundary and Interfaces Diagram    The interfaces (ports) for the physical boundary include the computer keyboard port, mouse port,  network port, USB ports, display and power plug. When operational, the module does not transmit any  information across these physical ports because it is a software cryptographic module. Therefore, the  Document Version 1.0  © Symantec Corporation  Page 11 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  module’s interfaces are purely logical and are provided through the Application Programming Interface  (API) that a calling daemon can operate. The logical interfaces expose services that applications directly  call, and the API provides functions that may be called by a referencing application (see Section 2.3 –  Roles, Services, and Authentication for the list of available functions). The module distinguishes between  logical interfaces by logically separating the information according to the defined API.  The API provided by the module is mapped onto the FIPS 140‐ 2 logical interfaces: data input, data  output, control input, and status output. Each of the FIPS 140‐ 2 logical interfaces relates to the  module’s callable interface, as follows:  FIPS 140‐2 Interface  Logical Interface  Module Physical Interface  Data Input   Input parameters of API function  Network Interface  calls  Data Output   Output parameters of API function  Network Interface  calls  Control Input   API function calls  Keyboard Interface, Mouse  Interface  Status Output   For FIPS mode, function calls  Display Controller  returning status information and  return codes provided by API  function calls.   Power   None  Power Supply  Table 4 – Logical Interface / Physical Interface Mapping  As shown in Figure 1 – Module Boundary and Interfaces Diagram and Table 5 – Module Services, Roles,  and Descriptions, the output data path is provided by the data interfaces and is logically disconnected  from processes performing key generation or zeroization. No key information will be output through the  data output interface when the module zeroizes keys.  2.3 Roles, Services, and Authentication The module supports a Crypto Officer and a User role. The module does not support a Maintenance  role.  The User and Crypto‐Officer roles are implicitly assumed by the entity accessing services  implemented by the Module.  2.3.1 Operator Services and Descriptions The module supports services that are available to users in the various roles. All of the services are  described in detail in the module’s user documentation. The following table shows the services available  to the various roles and the access to cryptographic keys and CSPs resulting from services:      Document Version 1.0  © Symantec Corporation  Page 12 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  Service  Roles  CSP / Algorithm   Permission  Module initialization  Crypto  None  CO:  execute  Officer  AES Key, Triple‐DES1 Key  Symmetric  User  User:  encryption/decryption  read/write/execute  Digital signature2*  User  RSA Private Key, DSA Private Key  User:  read/write/execute  Symmetric key  User  AES Key, Triple‐DES Key  User:  generation  read/write/execute  Asymmetric key  User  RSA Private Key, DSA Private Key  User:  generation  read/write/execute  Keyed Hash (HMAC)*  User  HMAC Key  User:  HMAC SHA‐1, HMAC SHA‐ 224, HMAC SHA‐ read/write/execute  256, HMAC SHA‐384, HMAC SHA‐512  Message digest (SHS)  User  SHA‐1, SHA‐224, SHA‐256, SHA‐384, SHA‐ User:  512  read/write/execute  Random number  User  PRNG Seed and Seed Key  User:  generation  read/write/execute  Show status  Crypto  None  User and CO:  execute  Officer  User  Self test  User  All CSPs  User:  read/execute  Zeroize  Crypto  All CSPs  CO:  read/write/execute  Officer  User  Table 5 – Module Services, Roles, and Descriptions  2.3.2 Operator Authentication As required by FIPS 140‐2, there are two roles (a Crypto Officer role and User role) in the module that  operators may assume. As allowed by Level 1, the module does not support authentication to access  services. As such, there are no applicable authentication policies. Access control policies are implicitly  defined by the services available to the roles as specified in Table 5 – Module Services, Roles, and  Descriptions.  2.4 Physical Security This section of requirements does not apply to this module. The module is a software‐only module and  does not implement any physical security mechanisms.                                                               1  Two‐key Triple‐DES is restricted and only available for legacy use in accordance with SP800‐131A.  2  Note that per SP800‐131A, issuing 1024‐bit signatures with SHA‐1 is disallowed as of the end of 2013.  * Indicates non‐Approved services if non‐Approved key sizes are utilized (<112 bits)  Document Version 1.0  © Symantec Corporation  Page 13 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  2.5 Operational Environment The module operates on a general purpose computer (GPC) running a general purpose operating system  (GPOS). For FIPS purposes, the module is running on this operating system in single user mode and does  not require any additional configuration to meet the FIPS requirements.  The module was tested on the following platforms:   Microsoft Windows Server 2008 R2 on a Dell Optiplex 755   Red Hat Enterprise Linux 6.3 on a Dell Optiplex 755   CentOS 6.3 on a Dell Optiplex 755   SUSE Linux Enterprise 11SP2 on a Dell Optiplex 755  The cryptographic module is also supported on the following operating environments for which  operational testing and algorithm testing was not performed:   HP‐UX IA64 11.31 Mar2010   AIX 5.3 TL12 SP2    Solaris 10.0 U4 Sparc & U2 x86_64   Compliance is maintained for other versions of the respective operating system family where the binary  is unchanged. No claim can be made as to the correct operation of the module or the security strengths  of the generated keys when ported to an operational environment which is not listed on the validation  certificate.   The GPC(s) used during testing met Federal Communications Commission (FCC) FCC Electromagnetic  Interference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined  by 47 Code of Federal Regulations, Part15, Subpart B. FIPS 140‐2 validation compliance is maintained  when the module is operated on other versions of the GPOS running in single user mode, assuming that  the requirements outlined in NIST IG G.5 are met.  2.6 Cryptographic Key Management The table below provides a complete list of Critical Security Parameters used within the module:  Storage  Storage  Input   Output  Keys and CSPs  Zeroization  Access  Locations  Method  Method  Method  AES Key  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  Document Version 1.0  © Symantec Corporation  Page 14 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  Storage  Storage  Input   Output  Keys and CSPs  Zeroization  Access  Locations  Method  Method  Method  Triple‐DES Key  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  RSA Public Key  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  RSA Private Key*  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  DSA Public Key  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  DSA Private Key*  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  HMAC Key*  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  PRNG Seed  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  PRNG Seed Key  RAM  Plaintext API call  None power cycle  CO: RWD parameter  cleanse()  U: RWD  Integrity Key  Module  Plaintext None None None CO: RWD Binary    U: RWD  EC DSA Private  RAM  Plaintext None None power cycle  CO: RWD Key  cleanse()  U: RWD  EC DSA Public  RAM  Plaintext None None power cycle  CO: RWD Key  cleanse()  U: RWD  EC DH Public  RAM  Plaintext None None power cycle  CO: RWD Components  cleanse()  U: RWD  EC DH Private  RAM  Plaintext None None power cycle  CO: RWD Components  cleanse()  U: RWD  EC DRBG Entropy  RAM  Plaintext None None power cycle  CO: RWD cleanse()  U: RWD  EC DRBG S Value  RAM  Plaintext None None power cycle  CO: RWD (Seed Length)  cleanse()  U: RWD  EC DRBG  RAM  Plaintext None None power cycle  CO: RWD init_seed  cleanse()  U: RWD  HMAC DRBG  RAM  Plaintext None None power cycle  CO: RWD Entropy  cleanse()  U: RWD  HMAC DRBG V  RAM  Plaintext None None power cycle  CO: RWD Value (Seed  cleanse()  U: RWD  Length)  HMAC DRBG Key  RAM  Plaintext None None power cycle  CO: RWD cleanse()  U: RWD  HMAC DRBG  RAM  Plaintext None None power cycle  CO: RWD init_seed  cleanse()  U: RWD  R = Read    W = Write    D = Delete  * Indicates non‐Approved services if non‐Approved key sizes are utilized (<112 bits)  Document Version 1.0  © Symantec Corporation  Page 15 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  Table 6 – Module Keys/CSPs  The application that uses the module is responsible for appropriate destruction and zeroization of the  key material. The module provides functions for key allocation and destruction which overwrite the  memory that is occupied by the key information with zeros before it is deallocated.  2.6.1 Random Number Generation The module uses ANSI X9.31 and DRBG for creation of asymmetric and symmetric keys.  The module accepts input from entropy sources external to the cryptographic boundary for use as seed  material for the module’s Approved RNGs. This external entropy source provides an estimated minimum  amount of 93 bits of entropy, which limits the strength of the generated key.  The module performs continual tests on the random numbers it uses to ensure that the seed and seed  key input to the Approved RNG do not have the same value. The module also performs continual tests  on the output of the approved RNG to ensure that consecutive random numbers do not repeat.  2.6.2 Key/Critical Security Parameter (CSP) Authorized Access and Use by Role and Service/Function An authorized application as user (the User role) has access to all key data generated during the  operation of the module.  2.6.3 Key/CSP Storage Public and private keys are provided to the module by the calling process and are destroyed when  released by the appropriate API function calls or during power cycle. The module does not perform  persistent storage of keys.  2.6.4 Key/CSP Zeroization The application is responsible for calling the appropriate destruction functions from the API. The  destruction functions then overwrite the memory occupied by keys with zeros and deallocates the  memory. This occurs during process termination / power cycle. Keys are immediately zeroized upon  deallocation, which sufficiently protects the CSPs from compromise.  2.7 Self‐Tests FIPS 140‐2 requires that the module perform self‐tests to ensure the integrity of the module and the  correctness of the cryptographic functionality at start up. In addition some functions require continuous  verification of function, such as the random number generator. All of these tests are listed and  described in this section.  In the event of a self‐test error, the module will log the error and will halt. The  module must be initialized into memory to resume function.   Document Version 1.0  © Symantec Corporation  Page 16 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  The following sections discuss the module’s self‐tests in more detail.  2.7.1 Power‐On Self‐Tests Power‐on self‐tests are executed automatically when the module is loaded into memory. The module  verifies the integrity of the runtime executable using a HMAC‐SHA1 digest computed at build time. If the  fingerprints match, the power‐up self‐tests are then performed. If the power‐up self‐test is successful, a  flag is set to place the module in FIPS mode.  Document Version 1.0  © Symantec Corporation  Page 17 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation    TYPE  DETAIL   Software Integrity Check  HMAC‐SHA1 on all module components   Known Answer Tests3  AES encrypt/decrypt   AES GCM   AES CCM   XTS‐AES   AES CMAC   Triple‐DES CMAC   ECDH   HMAC‐SHA1   HMAC‐SHA224   HMAC‐SHA256   HMAC‐SHA384   HMAC‐SHA512   RSA   SHA‐1   SHA‐224   SHA‐256   SHA‐384   SHA‐512   X9.31 RNG   SP 800‐90 DRBG (Hash_DRBG, HMAC_DRBG,  CTR_DRBG, Dual_EC_DRBG)   Triple‐DES encrypt/decrypt   ECC CDH   Pair‐wise Consistency Tests  DSA   RSA   ECDSA  Table 7 – Power‐On Self‐Tests  Input, output, and cryptographic functions cannot be performed while the Module is in a self‐test or  error state because the module is single‐threaded and will not return to the calling application until the  power‐up self‐tests are complete. If the power‐up self‐tests fail, subsequent calls to the module will also  fail ‐ thus no further cryptographic operations are possible.                                                               3  Note that all SHA‐X KATs are tested as part of the respective HMAC SHA‐X KAT. SHA‐1 is also tested  independently.   Document Version 1.0  © Symantec Corporation  Page 18 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation    2.7.2 Conditional Self‐Tests The module implements the following conditional self‐tests upon key generation, or random number  generation (respectively):  TYPE  DETAIL   Pair‐wise Consistency Tests  DSA   RSA   ECDSA   Continuous RNG Tests  Performed on all approved PRNGs  Table 8 – Conditional Self‐Tests  2.7.3 Cryptographic Function The module verifies the integrity of the runtime executable using a HMAC‐SHA1 digest which is  computed at build time. If this computed HMAC‐SHA1 digest matches the stored, known digest, then  the power‐up self‐test (consisting of the algorithm‐specific Pairwise Consistency and Known Answer  tests) is performed. If any component of the power‐up self‐test fails, an internal global error flag is set to  prevent subsequent invocation of any cryptographic function calls. Any such power‐up self‐test failure is  a hard error that can only be recovered by reinstalling the module4. The power‐up self‐tests may be  performed at any time by reloading the module.  No operator intervention is required during the running of the self‐tests.  2.8 Mitigation of Other Attacks The Module does not contain additional security mechanisms beyond the requirements for FIPS 140‐2  Level 1 cryptographic modules.                                                                 4  The initialization function could be re‐invoked but such re‐invocation does not provide a means from recovering  from an integrity test or known answer test failure  Document Version 1.0  © Symantec Corporation  Page 19 of 20  FIPS 140‐2 Non‐Proprietary Security Policy: NetBackup Cryptographic Module from Symantec  Corporation  3 Guidance and Secure Operation 3.1 Crypto Officer Guidance 3.1.1 Software Installation The module is provided directly to solution developers and is not available for direct download to the  general public. The module and its host application are to be installed on an operating system specified  in Section 2.5 or one where portability is maintained.  3.1.2 Additional Rules of Operation 1. The writable memory areas of the module (data and stack segments) are accessible only by the  application so that the operating system is in "single user" mode, i.e. only the application has  access to that instance of the module.  2. The operating system is responsible for multitasking operations so that other processes cannot  access the address space of the process containing the module.  3.2 User Guidance 3.2.1 General Guidance The module is not distributed as a standalone library and is only used in conjunction with the solution.   The end user of the operating system is also responsible for zeroizing CSPs via wipe/secure delete  procedures.  If the module power is lost and restored, the calling application can reset the IV to the last value used.  Document Version 1.0  © Symantec Corporation  Page 20 of 20