© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
Secured User, Inc.
SUSK Security Module
(Software Version: 1.0)
FIPS 140-2
Non-Proprietary Security Policy
Level 1 Validation
Document Version 0.6
Prepared for: Prepared by:
Secured User, Inc. Corsec Security, Inc.
11490 Commerce Park Drive
Suite 240
Reston, Virginia 20191
10340 Democracy Lane, Suite 201
Fairfax, VA 22030
Phone: (866) 419-3900 Phone: (703) 267-6050
Fax: (703) 935-1383 Fax: (703) 267-6810
http://www.secured-services.com http://www.corsec.com
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 2 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
Revision History
Version Modification Date Modified By Description of Changes
0.1 2006-08-09 Rumman Mahmud Draft created.
0.2 2006-08-24 Rumman Mahmud Updated section two and three.
0.3 2006-09-01 Rumman Mahmud Incorporated quality review feedback.
0.4 2006-09-12 Rumman Mahmud Updated Company name and logo.
0.5 2006-12-15 Rumman Mahmud Inserted algorithm certificate numbers
0.6 2007-6-13 Darryl H. Johnson Modified Module Specification section; clarified the
generation/input of AES symmetric keys; added
references for single user mode configuration
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 3 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
Table of Contents
1 INTRODUCTION ...............................................................................................................................................4
1.1 PURPOSE.........................................................................................................................................................4
1.2 REFERENCES...................................................................................................................................................4
1.3 DOCUMENT ORGANIZATION ...........................................................................................................................4
2 SUSK SECURITY MODULE ............................................................................................................................5
2.1 PRODUCT OVERVIEW......................................................................................................................................5
2.2 MODULE SPECIFICATION ................................................................................................................................5
2.3 MODULE INTERFACES ....................................................................................................................................7
2.4 ROLES AND SERVICES.....................................................................................................................................8
2.4.1 Crypto Officer Role................................................................................................................................8
2.4.2 User Role ...............................................................................................................................................8
2.5 PHYSICAL SECURITY ......................................................................................................................................9
2.6 OPERATIONAL ENVIRONMENT......................................................................................................................10
2.7 CRYPTOGRAPHIC KEY MANAGEMENT..........................................................................................................10
2.8 SELF-TESTS ..................................................................................................................................................12
2.9 DESIGN ASSURANCE.....................................................................................................................................12
2.10 MITIGATION OF OTHER ATTACKS.................................................................................................................12
3 SECURE OPERATION....................................................................................................................................13
3.1 CRYPTO-OFFICER GUIDANCE .......................................................................................................................13
3.1.1 Initial Setup..........................................................................................................................................13
3.1.2 Management ........................................................................................................................................13
3.2 USER GUIDANCE ..........................................................................................................................................13
4 ACRONYMS......................................................................................................................................................14
Table of Figures
FIGURE 1 – SECURED USER’S APPLICATION DEPLOYMENT ............................................................................................5
FIGURE 2 - STANDARD SERVER PHYSICAL BLOCK DIAGRAM.........................................................................................6
FIGURE 3 - LOGICAL CRYPTOGRAPHIC BOUNDARY........................................................................................................7
Table of Tables
TABLE 1 - SECURITY LEVEL PER FIPS 140-2 SECTION ...................................................................................................7
TABLE 2 - FIPS 140-2 LOGICAL INTERFACES .................................................................................................................8
TABLE 3 – MAPPING OF CRYPTO OFFICER ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ........8
TABLE 4 – MAPPING OF USER ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ...........................9
TABLE 5 - LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS .....................................11
TABLE 6 - ACRONYMS ..................................................................................................................................................14
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 4 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
1 Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the SUSK Security Module from Secured User,
Inc. This Security Policy describes how the SUSK Security Module meets the security requirements of FIPS 140-2
and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-
2 validation of the module.
FIPS 140-2 (Federal Information Processing Standards Publication 140-2 – Security Requirements for
Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information
about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and
Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/cryptval/
The SUSK Security Module is also referred to in this document as the cryptographic module, the software module,
or the module.
1.2 References
This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2
cryptographic module security policy. More information is available on the module from the following sources:
• The Secured User website (http://www.secured-services.com) contains information on the full line of
products from Secured User.
• The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or
sales-related questions for the module.
1.3 Document Organization
The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document,
the Submission Package contains:
• Vendor Evidence document
• Finite State Machine
• Other supporting documentation as additional references
This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc.
under contract to Secured User. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2
Validation Documentation is proprietary to Secured User and is releasable only under appropriate non-disclosure
agreements. For access to these documents, please contact Secured User.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 5 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
2 SUSK Security Module
2.1 Product Overview
Secured User provides products for centrally-administered security environments for enterprises running mainframe,
client-server, and web-based applications. The company’s application environment provides:
• Complete Identity Life Cycle Management: Comprehensive identity administration, access control, and
audit management functionality, built on a single, integrated platform. This makes for a unique
cohesiveness in managing the entire life cycle of a digital identity.
• A Single Identity, with True, Enterprise-Wide Reach: The realization of true single sign-on to all
application types, whether Web-based, client/server, or legacy mainframe.
• Ease of Deployment: Overcomes traditional barriers to identity management projects, deploying rapidly,
non-disruptively, without changes to legacy code or directories, and with radically less risk and complexity
than competing approaches.
Secured User’s product performs all of its work by transparently intercepting and transforming the data stream
between entities.
Figure 1 – Secured User’s Application Deployment
2.2 Module Specification
The SUSK Security Module is a software-based cryptographic module. Secured User's product performs all of its
work by transparently intercepting and transforming the data stream between entities. All of the cryptographic
functions of the Secured User product are provided by the central shared library, the SUSK Security Module. The
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 6 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
cryptographic module offers TLS services along with bulk encryption and hashing services exclusively to Secured
User application. This application is considered as the host application to the module.
The SUSK Security Module is being evaluated for use on a standard server running the Windows Server 2003
Operating System (OS) in single-user mode. The server is placed in single-user mode by disabling all remote guest
accounts in order to ensure that only one operator can log into the OS at a time. The services that are disabled are
server services, terminal services, remote registry services, and remote desktop and remote assistance service.
The physical cryptographic boundary of the module is the hard opaque metal and plastic enclosure of the server.
The physical device consists of the motherboard circuits, the central processing unit (CPU), random access memory
(RAM), read-only memory (ROM), server case, expansion cards, and other hardware components included in the
server such as hard disk, floppy disk, CD-ROM drive, power supply, and fans.
The server’s CPU processes the cryptographic module. The CPU is contained within the physical cryptographic
boundary as depicted in Figure 2Error! Reference source not found. Error! Reference source not found.. The
software is stored on the main memory of the server, and while executing it is also stored in the RAM.
Figure 2 - Standard Server Physical Block Diagram
The module’s software is entirely encapsulated by the logical cryptographic boundary as shown in Figure 3 below.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 7 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
Cryptographic Boundary
Plaintext (Data/Control/Status)
Ciphertext (Data)
Operating System
SUSK Security
Module
Host
Application
Figure 3 - Logical Cryptographic Boundary
Per FIPS 140-2 terminology, the SUSK Security Module is a multi-chip standalone module that meets overall level
1 FIPS 140-2 requirements. The SUSK Security Module is validated at the following FIPS 140-2 Section levels:
Table 1 - Security Level per FIPS 140-2 Section
Section Section Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 1
4 Finite State Model 1
5 Physical Security N/A
6 Operational Environment 1
7 Cryptographic Key Management 1
8 EMI/EMC 1
9 Self-tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A
2.3 Module Interfaces
The module’s logical interfaces exist in the software as an Application Programming Interface (API). Physically,
ports and interfaces are considered to be those of the server. Both the API and physical interfaces can be
categorized into following logical interfaces defined by FIPS 140-2:
• Data Input Interface
• Data Out Interface
• Data Control Interface
• Status Output Interface
• Power Interface
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 8 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
All of these logical interfaces are described in the following table:
Table 2 - FIPS 140-2 Logical Interfaces
FIPS 140-2 Logical Interface SUSK Security Module Port/Interface Physical Port/Interface
Data Input Function calls that accept, as their
arguments, data to be used or processed by
the module.
Keyboard, mouse, CD-ROM, floppy
disk, and serial/USB/parallel/network
ports
Data Output Arguments for a function that specify where
the result of the function is stored.
Floppy disk, monitor, and
serial/USB/parallel/network ports
Control Input Function calls utilized to initiate the module
and the function calls used to control the
operation of the module.
Keyboard, CD-ROM, floppy disk,
mouse, and
serial/USB/parallel/network port
Status Output Return values for function calls Floppy disk, monitor, and
serial/USB/parallel/network ports
Power Interface Not applicable Power Interface
2.4 Roles and Services
Two roles are supported by the module (as required by FIPS 140-2) that operators may assume: a Crypto-Officer
(CO) role and a User role. The operator of the module must assume either of the roles based on their operation
without any authentication. Both of the roles and their responsibilities are described below.
2.4.1 Crypto Officer Role
The Crypto-Officer (CO) is expected to install and configure the module in the FIPS mode of operation. The CO is
also responsible for monitoring the module’s configuration and operational status from the Windows event log.
Please see the Secure Operation section for a complete list of the Crypto-Officer’s responsibilities.
Descriptions of the services available to the Crypto-Officer role are provided in the table below.
Table 3 – Mapping of Crypto Officer Role’s Services to Inputs, Outputs, CSPs, and Type of Access
Service Description Input Output
CSP and Type of
Access
Installation Installing the
software module
Command Result of installation None
Uninstall Uninstall the
software module
Command Module uninstalled None
SUSK_SSL_library_init Enables the FIPS
mode of operation.
API call The module executes
in FIPS mode of
operation
None
SUSK_selftest Performs power-up
self-tests
API call Self-tests performed None
2.4.2 User Role
The User role accesses the module’s cryptographic services that include TLS operation, encryption/decryption, and
hashing. The following table lists the services available to the User role.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 9 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
Table 4 – Mapping of User Role’s Services to Inputs, Outputs, CSPs, and Type of Access
Service Description Input Output
CSP and Type of
Access
SUSK_TLS_connect Initiates the TLS
handshake with a
server
API call TLS connection
completed
Diffie-Hellman (DH)
key pair – Read
Session Key – Write
SUSK_TLS_close Terminates a TLS
connection
API call TLS connection
terminated
None
SUSK_get_error Obtains result code
for TLS operation
API call Status of TLS
connection
None
SUSK_TLS_read Reads bytes from a
TLS connection
API call with input
data
Data read from a TLS
session
Session Key – Read
SUSK_TLS_write Writes bytes to a TLS
connection
API call Data sent over a TLS
session
Session Key – Read
SUSK_TLS_accept Accepts TLS
handshake from a
client
API call TLS handshake
initiated
DH key pair – Read
Session Key – Write
SUSK_keygen Generates a random
key
API call Key generated Pseudo Random
Number Generator
(PRNG) seed –
Read/Write
Symmetric Key –
Write
SUSK_encrypt AES cipher operation API call with a
symmetric key and
input data
Data encrypted Symmetric key –
Read
SUSK_hashinit Initiate hashing
mechanism
API call Hashing context
initializes
None
SUSK_hashupdate Updates hashing
digest
API call with input
data
Hash value updated None
SUSK_hashfinal Finalizes hash value API call Returns digest None
Operator spaces on the module are separated by the Operating System. The OS must be configured for single user
mode in FIPS-approved mode of operation.
2.5 Physical Security
The physical security requirements do not apply to this module since it is a software module and does not implement
any physical security mechanisms.
Although the module consists entirely of software, the FIPS 140-2 evaluated platform is a standard server, which has
been tested for and meets applicable Federal Communication Commission (FCC) Electromagnetic Interference
(EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined in Subpart B of FCC Part
15.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 10 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
2.6 Operational Environment
The module runs on the general purpose Windows Server 2003 Operating System (OS). The OS must be configured
for single user mode per NIST CMVP guidance for FIPS 140-2 compliance. Single user mode configuration
instructions for the OS can be found in the Secure Operation section.
2.7 Cryptographic Key Management
The SUSK Security Module implements the following FIPS-approved algorithms:
• AES ECB/CBC mode – FIPS 197 (certificate #474)
• SHA-1 – FIPS 180-2 (certificate #542)
• HMAC SHA-1 – FIPS 198 (vendor affirmed, SHA-1 certificate #231)
• Deterministic Random Number Generator (RNG) – Appendix A.2.4 of ANSI X9.31 (certificate #257)
Additionally, the software module utilizes the following non-FIPS-approved algorithm implementation:
• Diffie-Hellman (key agreement, key establishment methodology provides 80-bits of encryption strength)1
1
In order to operate in an Approved mode of operation compliant to FIPS 140-2, Diffie-Hellman keys of 1024-bits is used.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 11 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
The module supports the following critical security parameters:
Table 5 - List of Cryptographic Keys, Cryptographic Key Components, and CSPs
Key Key Type Generation / Input Output Storage Zeroization Use
Diffie-Hellman Key
pair
Diffie-Hellman key
pair (1024 bits)
Generated for TLS
session establishment
Never exit the
module
Plaintext in volatile
memory
Zeroized after
session is over or by
power cycle
Used by the module
in establishing a
session key during
TLS handshake
Session Key AES key (256 bits) Established during
TLS session
establishment
Never exit the
module
Plaintext in volatile
memory
Zeroized after
session is over or by
power cycle
Used to encrypt the
TLS session.
Symmetric Key AES key (128, 192,
256 bits)
Generated internally
or generated
externally by a host
application and
entered electronically
in plaintext
Exits the module in
plaintext
Plaintext in volatile
memory
Zeroized by power
cycle
Encrypts data
Software Integrity
Test Key
HMAC key (16
bytes)
Hard coded into the
module
Never exit the
module
Stored on hard drive
in plaintext
Uninstalling the
module
Checks integrity of
the software
PRNG Seed 8 bytes of seed value Prearranged value Never exit the
module
Stored on hard drive
in plaintext
Uninstalling the
module
Generate ANSI
X9.31 A.2.4 PRNG
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 12 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
2.8 Self-Tests
In order to prevent any secure data from being released, it is important to test the cryptographic components of a
security module to ensure that all components are functioning correctly. The module performs the following self-
tests:
• Power-Up Self-Tests:
o Software integrity check using HMAC SHA-1
o Known Answer Tests (KATs)
ƒ AES KAT
ƒ SHA-1 KAT
ƒ X9.31 PRNG KAT
The SUSK Security Module performs the following conditional self-tests:
• Continuous RNG for FIPS approved PRNG
Status output of self-tests are logged in the Windows Event log file, unless the Crypto-Officer configures the module
to record the status output into a local file.
2.9 Design Assurance
Configuration management for all of the Secured User’s source code files and user manual is provided by
Subversion. The source code revisions are maintained in a private Subversion repository with write access restricted
to the core development team.
Additionally, Microsoft Visual SourceSafe (VSS) version 6.0 is used to provide configuration management for the
SUSK Security Module’s FIPS documentation. This software provides access control, versioning, and logging.
2.10Mitigation of Other Attacks
This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 level 1
requirements for this validation.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 13 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
3 Secure Operation
The SUSK Security Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to
configure and maintain the module in a FIPS-approved mode of operation. Operating the module without following
this guidance will remove the module from the FIPS-approved mode of operation.
3.1 Crypto-Officer Guidance
3.1.1 Initial Setup
The Crypto-Officer is responsible for installing/uninstalling, configuring, and managing the module. The SUSK
Security Module is available on a Compact Disc (CD) to the Crypto-Officer from Secured User through shipping
using a standard carrier (i.e. FedEx or UPS). The Crypto-Officer is responsible for inspecting the CD and its
packaging upon receipt for signs of tampering. If evidence of tampering is found, the Crypto-Officer should contact
Secured User immediately and should not use the module. The software module will be provided to users by
Secured User for exclusive use in their products only. The module is installed during installation of the host
application, Identiprise SecuredUser. With the delivered software, the Crypto-Officer also receives a complete
documentation library, which includes the Installation Guidance for the host application.
Before installing the module, the CO must configure the Windows server 2003 machine for single user mode as
instructed below. To configure Windows Server 2003 for single user mode, the CO must ensure that all remote
guest accounts are disabled in order to ensure that only one operator can log into the OS at a time. This is
accomplished by performing the following steps:
• Configure the OS to only allow a single authenticated user to login locally.
• Disable all remote logins to the OS.
For more information on configuring Windows Server 2003 for single user mode, refer to the following online
Microsoft resources:
• Microsoft Windows Server TechCenter Windows Server 2003 Technical Library: Remote Administration
Tools
• Locking Down Windows Server 2003 Terminal Server Sessions
3.1.2 Management
The Crypto-Officer should monitor the module’s status by regularly checking the Windows Event log. If any
irregular activity is noticed or the module is consistently reporting errors, then Secured User customer support
should be contacted.
3.2 User Guidance
The User accesses the module’s cryptographic functionalities only. Although the User does not have any ability to
modify the configuration of the module, they should report to the Crypto-Officer if any irregular activity is noticed.
Non-Proprietary Security Policy, Version 0.6 June 12, 2007
Secured User SUSK Security Module Page 14 of 14
© 2007 Secured User, Inc. – This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
4 Acronyms
Table 6 - Acronyms
Acronym Definition
API Application Programming Interface
ANSI American National Standards Institution
CD Compact Disk
CMVP Cryptographic Module Validation Program
CO Crypto-Officer
CPU Central Processing Unit
CRNGT Continuous Random Number Generator Test
CSP Critical Security Parameter
DH Diffie-Hellman
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FCC Federal Communication Commission
FIPS Federal Information Processing Standard
FSM Finite State Machine
HMAC (Keyed-) Hash MAC
KAT Known Answer Test
LED Light Emitting Diode
NIST National Institute of Standards and Technology
NVLAP National Voluntary Laboratory Accreditation Program
OS Operating System
PRNG Pseudo Random Number Generator
RAM Random Access Memory
RNG Random Number Generator
ROM Read Only Memory
SHA Secure Hash Algorithm
SUSK SecuredUser Security Kernel
TLS Transport Layer Security
USB Universal Serial Bus
VSS Visual Source Safe