Entrust Security Kernel 7.0
FIPS 140-1 Validation Security Policy
Author: Pierre Boucher
Document Issue: Release 1.2
Issue Date: January 2003
Abstract: This document describes the Entrust Security Kernel 7.0 Cryptographic
Module Security Policy submitted for validation, in accordance with the FIPS publication
140-1, level 2.
 2002 Entrust. All rights reserved.
Page 2 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
This document may be copied without the author’s permission provided that it is
copied in it’s entirety without any modification.
Entrust is a trademark or a registered trademark of Entrust, Inc. in certain
countries. All Entrust product names and logos are trademarks or registered
trademarks of Entrust, Inc. in certain countries. All other company and product
names and logos are trademarks or registered trademarks of their respective
owners in certain countries.
Page 3 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
1 Contents
1 CONTENTS..............................................................................................................................................................3
2 CRYPTOGRAPHIC MODULEDEFINITION.....................................................................................................4
3 SECURITY POLICY...............................................................................................................................................6
3.1 AUTHENTICATION POLICY ..........................................................................................................................6
3.2 ACCESS CONTROL POLICY ............................................................................................................................6
3.3 OPERATIONAL ENVIRONMENT ....................................................................................................................9
3.3.1 Level 2 Mode of Operation ..................................................................................................................9
3.3.1.1 Assumptions.........................................................................................................................................9
3.3.1.2 Policy ....................................................................................................................................................9
4 INSTALLATION GUIDANCE............................................................................................................................11
4.1 LEVEL 2 MODE OF OPERATION..................................................................................................................11
5 REFERENCES .......................................................................................................................................................12
Page 4 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
2 Cryptographic Module Definition
This document describes the Entrust Security Kernel 7.0 (Cryptographic Module)
Security Policy submitted for validation, in accordance with the FIPS publication
140-1, level 2.
The module consists of the following generic components:
• A commercially available general-purpose hardware computing platform. A
generic high-level block diagram for such a platform is provided in Figure 1.
• A C2 TCSEC certified commercially available Operating System (OS) that
runs on the above platform.
• A software component, called the Entrust Cryptographic Kernel, that runs on
the above platform and operating system. This component is custom
designed and written by Entrust in the C and C++ computer languages, with
some small performance-critical sections being written in assembly
language. This component is identical, at the source code level, for all
supported hardware platforms and operating systems. It is compiled into
specific executable object code for each identified platform and linked with
an ANSI C library.
The cryptographic module was tested on the following hardware computing platform
and operating system:
1. A Compaq Proliant 7000 Server with:
• 4 Intel Pentium II 400 MHz processors,
• 256 MB system RAM (DIMM),
• 2 serial ports, 1 parallel port and 2 PS/2 ports,
• a 18.2 GB hard drive, and
• a Netelligent Dual 10/100 TX PCI Ethernet card.
2. Windows NT 4.0 service pack 6a operating system.
The hardware computing platform and operating system were installed and
configured to be C2 compliant, as specified at Chapter 4 of Ref [5].
A detailed technical description of the Compaq Proliant 7000 Server platform is
included at Ref [4].
Page 5 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
The Entrust cryptographic kernel 7.0 has been validated on the above platform to
FIPS 140-1 level 2.
Figure 1 Security Kernel block diagram for software (top) and hardware (bottom)
User Interface
Optional Cryptoki
library
Cryptographic
Kernel
Application Software
Kernel Interface
Cryptoki API
Micro-
processor
System
Memory
Disk
Drive
Serial
Interface
Parallel
Interface
Video
Display
Driver
Keyboard
Interface
Network
Interface
Optional
PC/Card
Interface
Power
Supply
Video
Display
Keyboard
Mouse
Mouse
Interface
Cryptographic Boundary
System
Bus
Serial
Port
Parallel
Port
Network
Optional Hardware
Crypto Token
External
Power Source
Unallocated
space and OS
swapped data
Files and
other s/w
components
Page 6 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
3 Security Policy
This section describes the security policy for the module, as defined in FIPS PUB
140-1 and the companion Test Requirements document. The FIPS 140-1
cryptographic module is defined to be the module identified earlier in section 2 of
this document.
3.1 Authentication Policy
The cryptographic module must perform authentication of the operator before it can
deliver any cryptographic services. Authenticated operators are authorized to
assume one or a set of the following supported roles: public user, private user or
cryptographic officer.
Operators authenticate themselves in the public user role by presenting a valid
MAC; the MAC is stored in the entrust.ini file and is the same for all authorized
Entrust users
1
. Authentication to the private user and cryptographic officer roles is
performed by presenting a valid user password; the password is unique to each
individual user. The functions that allow users to login into the private user and
cryptographic officer roles are only available from the public user role; an operator
must be already authenticated in the public user role before he/she can authenticate
in the private user and cryptographic officer roles.
3.2 Access Control Policy
The cryptographic module supports three roles: public user, private user and crypto-
officer. An operator accesses services available from the public user role after
being successfully authenticated with a valid MAC, and accesses services available
from both private user and cryptographic officer roles after being successfully
authenticated with a valid password. An operator performing a service within any
role can read and write security-relevant data items only through the invocation of a
service by means of the cryptographic module API. The type of services
corresponding to each of the supported roles is described in Table 1 Roles and
Services.
1
Under normal operations, Entrust software automatically reads the MAC from the entrust.ini file and
presents it to the cryptographic module on behalf of the user. The cryptographic module will not initialize
unless a valid MAC is provided.
Page 7 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
Table 1 Roles and Services
Role Services
Public User Authentication, symmetric key generation, key
destruction, symmetric encryption/decryption,
hashing, MAC generation/verification, self-test,
login
Private User Key pair generation, asymmetric
encryption/decryption (sign/verify), password
change
Cryptographic Officer Configuration of cryptographic services (e.g.
set/generate initialization vector)
The whole set of cryptographic services is available to operators that are
authenticated into the private user and cryptographic officer roles. Only those
services that do not require access to an operator asymmetric private key, and
services that modify the configuration of the cryptographic module, can be
accessed from the public role.
The following FIPS approved basic services are provided by the cryptographic
module:
1. Cryptographic data hashing using FIPS PUB 180-1 SHA-1 and HMAC-SHA-
1 (and SHA-256, MD2, MD5, RIPEMD-160, HMAC-MD5, and HMAC-
RIPEMD160)
1
.
2. Bulk data encryption, decryption, and MAC calculation using FIPS PUB 46-3
DES and 3-DES, FIPS PUB 197 AES (and CAST, CAST3, CAST5, RC2,
IDEA and cipher stream RC4)
1
.
3. Signing and signature verification using FIPS PUB 186-2 DSA (and
ECDSA)
1
and PKCS#1 for RSA.
The Entrust cryptographic module also provides the following services:
1. Key wrapping and unwrapping using RSA.
2. Key agreement using Diffie-Hellman and Ephemeral-Static Diffie-Hellman
2
.
3. User authentication (as described above).
1
Algorithms in parenthesis have not been FIPS-approved yet; therefore, the kernel is not operating
in accordance with FIPS 140-1 when these algorithms are selected.
2
As specified in RFC 2631
Page 8 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
4. Random number generation using a FIPS 180-2-compliant software-based
algorithm, or a hardware token-based generator.
The FIPS 140-1 related Security Relevant Data Items (SRDI) include DES keys, 3-
DES keys, AES keys, DSA and RSA private keys, and DSA parameters.
3
When
the cryptographic module is initialized into the FIPS 140-1 compliant mode (this is
done by passing TRUE to the initialization function), the following restrictions take
effect:
1. During the generation of random symmetric, asymmetric, and generic keys in
software, the random numbers must come from the software-based random
number generator and not from any hardware token.
2. Asymmetric private and generic keys cannot be input to or output from the
module via the kernel API in plaintext form. They may, however, be input or
output in wrapped (encrypted) or hashed form.
3. Symmetric keys (except for 3-DES keys) cannot be input to the module via
the kernel API in plaintext form. Symmetric keys (including 3-DES keys)
cannot be output from the module in plaintext form. They may, however, be
input or output in wrapped (encrypted) or hashed form.
4. Symmetric, asymmetric private and generic keys cannot be input to or output
from the module via the Cryptoki interface in plaintext form. They may,
however, be input or output in wrapped (encrypted) form.
5. Software authentication must be performed after initialization of the module
and before any cryptographic operation is attempted.
6. User authentication must be performed after initialization of the module and
before any cryptographic operations are attempted, as described above in
section 3.1.
7. In non-FIPS mode, software authentication and user authentication is
optional.
8. Only DES can be used in the X9.17 random number generator.
3
IVs are either loaded externally, in which case the length is verified to be 64 bits (only CBC mode
is used), or are generated internally using the internal RNG, which is FIPS approved.
Page 9 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
3.3 Operational Environment
3.3.1 Level 2 Mode of Operation
3.3.1.1 Assumptions
The following assumptions are made about the operating environment of the
cryptomodule in Level 2 mode of operation:
1. The module is initialized to the FIPS 140-1 mode of operation.
2. Tamper-evident seals are applied as indicated at Figure 2.
To these ends, the following operational rules must be followed by a user or
integrator of the module.
3.3.1.2 Policy
1. The Entrust Cryptographic Module has been validated to be used with:
§ one or more applications, as a shared Windows DLL, or
§ single application, as a statically linked library.
2. The cryptographic module must execute on a C2 or equivalent certified
operating system. The Entrust cryptographic module has been validated for use
on Windows NT 4.0 SP6a, which requires installation and configuration as
specified at Ref [5].
3. The security permissions of the application file that contains the cryptographic
module (e.g. etfile32.dll or etsesn32.dll) must be configured so that:
§ only authorized Entrust users can execute the application;
§ only the cryptographic officer can delete, replace or modify the application.
4. The security permissions of the files that contain user security sensitive data
(e.g. user profile) must be configured so that:
§ only authorized Entrust users have access to their own security sensitive
data.
Page 10 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
5. The security permissions of the file that contains configuration and initialization
information (i.e. entrust.ini) must be configured so that:
§ only authorized Entrust users can read the file;
§ only the cryptographic officer can modify the file.
6. All public keys entered into the module must be verified as being legitimate and
belonging to the correct entity by the software running on the same platform as
the cryptomodule.
7. Virtual memory that exist on the platform where the cryptomodule runs must be
configured to reside on a local, not a networked, drive.
8. The hardware computing platform that hosts the cryptographic module must be
protected via tamper-evident labels. It must not be possible to open covers or
doors without breaking or removing a label, or replacing a label without leaving
detectable signs.
9. The above conditions must be upheld at all times in order to ensure continued
system security after initial setup of the validated configuration. If the module is
removed from the above environment, it is assumed to not be operational in the
level 2 validated mode until such time as it has been returned to the above
environment and re-initialized by the user to the validated condition.
Page 11 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
4 Installation Guidance
4.1 Level 2 Mode of Operation
1. The Entrust cryptographic module must be installed on a C2 evaluated computing
platform. The computing platform described in Section 2 satisfies the FIPS 140-
1 level 2 requirements for Operating System Security.
2. Entrust files shall be configured using access permissions as indicated in Table
1:
Table 2 Entrust Files Access Permissions (Windows NT 4.0)
File User Permission
All Entrust
operators
Execute (X)
Application that
contains the module
.dll (e.g. winnt\system32\etfile32.dll)
.exe (e.g. \etmaster.exe)
Administrator Change (RWXD)
Entrust
operator (own)
Full Control (All)
Entrust
operator
(other’s)
No Access
User Profile .epf file (e.g. \entrust profile\*.epf)
Administrator No Access
All Entrust
operators
Read (R)
Initialization and
operation data
.ini (e.g. \winnt\entrust.ini)
Administrator Change (RWXD)
3. To operate the Entrust cryptographic module in FIPS mode, the FipsMode entry
in the FIPS Mode section of the Entrust initialization (entrust.ini) file must be set
to 1. For example,
[FIPS Mode]
FIPS=1
Etfile32Name=etfile32
Etfile32Auth=DES-MAC,64, F404A ...
Etsesn32Name=etsesn32
Etsesn32Auth=DES-MAC,64, E23B1 ...
Setting FIPS=0 (zero) prevents the module from operating in FIPS mode.
4. Tamper-evident labels must be applied to the computing platform so that it is not
possible to open/remove any removable covers or panels without leaving
detectable signs such as broken label or detection of label residue on the
enclosure. Administrators (or security officers) must apply labels to all openings
and removable covers, as indicated at Figure 2
4
. The storage and distribution of
4
The adhesive must be allowed twenty-four hours to set-up properly.
Page 12 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
the labels should remain under the auspices of an administrator (or security
officer).
Figure 2 Location of Tamper-Evident Seals
5 References
[1] FIPS PUB 140-1: Security Requirements for Cryptographic Modules.
National Institute of Standards and Technology, 11 January 1994.
[2] Derived Test Requirements for FIPS PUB 140-1, Security Requirements
for Cryptographic Modules, National Institute of Standards and Technology,
September 1994.
[3] PKCS #1: RSA Cryptography Specifications, Version 2.0, RSA
Laboratories, September 1998.
[4] Compaq ProLiant 7000 Maintenance and Service Guide - Pentium II Xeon
Processor-based Servers, first edition, July 1998.
SECURITY
LABEL
SECURITY
LABEL
Page 13 of 16
Release 1.1 Entrust Security Kernel 7.0 Validation Security Policy
[5] C2 Administrator’s and User’s Security Guide, Microsoft Windows NT,
version 4.0, December 1999. (see
http://www.microsoft.com/security/issues/deployingc2.asp)