© 2010 Mobile Armor, Inc. – All Rights Reserved.
MOBILE ARMOR DATAARMOR & POLICYSERVER V3.1
SECURITY TARGET
VERSION: 1.72
DATE: 4/2/2010
© Mobile Armor, Inc. 2010 Version 1.72 Table of Contents
- (ii) -
Mobile Armor® DataArmor & PolicyServer v3.1 Security Target
This document is for informational purposes only. Mobile Armor makes no warranties, express or implied, as to the information
in this document.
Mobile Armor may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Mobile Armor, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual
property.
MOBILE ARMOR®, POLICYSERVER™, DATAARMOR™, MOBILESENTINEL™, MOBILEFIREWALL™, VIRUSDEFENSE™, REMOTENETWORK™, FILEARMOR™,
KEYARMOR™, AND COLORCODE® ARE TRADEMARKS OR REGISTERED TRADEMARKS OF MOBILE ARMOR, INC.
All other trademarks and registered trademarks shown are the property of, and are used by permission of, their respective
owners, including, but not limited to: IBM Corporation, Microsoft Corporation, Red Hat, Inc., Novell, Inc., and RSA Security Inc..
Copyright © Mobile Armor, Inc. All rights reserved.
Mobile Armor Contact Information:
Mobile Armor, Inc
400 South Woods Mill Road
Suite 300
St. Louis, MO, 63017 USA
Telephone: +1 (314) 590-0900
Fax: +1 (314) 590-0995
Website:
http://www.mobilearmor.com
Customer Support:
support@mobilearmor.com
© Mobile Armor, Inc. 2010 Version 1.72 Table of Contents
- (iii) -
Table of Contents
1. Security Target Introduction..........................................................................................................1
1.1 Security Target, TOE and Common Criteria Identification............................................................1
1.2 Conformance Claims.....................................................................................................................2
1.3 Conventions ..................................................................................................................................2
1.4 Terminology...................................................................................................................................3
1.4.1 Acronyms ..............................................................................................................................3
1.4.2 Definitions..............................................................................................................................3
2. TOE Description............................................................................................................................5
2.1 TOE Overview...............................................................................................................................5
2.2 TOE Architecture...........................................................................................................................7
2.2.1 Physical Boundaries..............................................................................................................9
2.2.2 Logical Boundaries..............................................................................................................10
2.3 TOE Documentation....................................................................................................................12
3. TOE Security Environment..........................................................................................................13
3.1 Threats ........................................................................................................................................13
3.2 Assumptions................................................................................................................................13
4. Security Objectives .....................................................................................................................14
4.1 Security Objectives for the TOE..................................................................................................14
4.2 Security Objectives for the TOE Environment ............................................................................14
5. IT Security Requirements............................................................................................................16
5.1 Extended Components Definition................................................................................................16
5.2 TOE Security Functional Requirements......................................................................................16
5.2.1 Security audit (FAU)............................................................................................................17
5.2.2 Cryptographic support (FCS) ..............................................................................................20
5.2.3 User data protection (FDP) .................................................................................................21
5.2.4 Identification and authentication (FIA) ................................................................................21
5.2.5 Security management (FMT) ..............................................................................................24
5.2.6 Protection of the TSF (FPT) ................................................................................................26
5.2.7 Resource Utilization (FRU) .................................................................................................27
5.2.8 TOE Access (FTA) ..............................................................................................................27
5.2.9 Trusted Path/Channels (FTP) .............................................................................................27
5.3 TOE Security Assurance Requirements .....................................................................................28
5.3.1 Development (ADV) ............................................................................................................28
5.3.2 Guidance documents (AGD) ...............................................................................................30
© Mobile Armor, Inc. 2010 Version 1.72 Table of Contents
- (iv) -
5.3.3 Life-cycle support (ALC)......................................................................................................31
5.3.4 Tests (ATE) .........................................................................................................................34
5.3.5 Vulnerability assessment (AVA)..........................................................................................35
6. TOE Summary Specification.......................................................................................................36
6.1 Security audit...............................................................................................................................36
6.2 Cryptographic support.................................................................................................................38
6.3 User data protection....................................................................................................................40
6.4 Identification and authentication .................................................................................................40
6.5 Security management .................................................................................................................43
6.6 Protection of the TSF ..................................................................................................................46
6.7 Resource Utilization ....................................................................................................................48
6.8 TOE Access ................................................................................................................................48
6.9 Trusted Path/Channels ...............................................................................................................48
7. Protection Profile Claims.............................................................................................................49
8. Rationale .....................................................................................................................................50
8.1 Security Objectives Rationale .....................................................................................................50
8.1.1 Security Objectives Rationale for the TOE and Environment .............................................50
8.2 Security Requirements Rationale................................................................................................53
8.3 Security Assurance Requirements Rationale .............................................................................58
8.4 Requirement Dependency Rationale ..........................................................................................58
8.5 TOE Summary Specification Rationale.......................................................................................60
List of Figures
Figure 1 - Mobile Armor Solution Architecture...........................................................................................8
List of Tables
Table 1 - Acronyms....................................................................................................................................3
Table 2 - TOE Security Functional Components .....................................................................................17
Table 3 - EAL 4 Assurance Components ................................................................................................28
Table 4 - Cryptographic Module Algorithm Certificates ...........................................................................39
Table 5 - Cryptographic Module Certificates ...........................................................................................39
Table 6 - Environment to Objective Correspondence..............................................................................50
Table 7 - Objective to Requirement Correspondence .............................................................................54
Table 8 - Requirements Dependency Analysis .......................................................................................60
Table 9 - Security Functions vs. Requirements Mapping........................................................................62
© Mobile Armor, Inc. 2010 Version 1.72 Security Target Introduction
- (1) -
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST
conventions, ST conformance claims, and the ST organization. The TOE is Mobile Armor, Inc.
DataArmor and PolicyServer provided by Mobile Armor, Inc. The TOE type is an encryption
application. DataArmor can be used to encrypt all data at rest on any supported device without any
user intervention to do so. DataArmor requires users to authenticate to it before access to the device,
including both the operating system and any data, is granted. PolicyServer is a server application
that can be used to manage one or more instances of DataArmor applications from a centralized
location in the TOE environment.
The Security Target contains the following additional sections:
 Section 2 – Target of Evaluation (TOE) Description
This section gives an overview of the TOE, describes the TOE in terms of its physical and
logical boundaries, and states the scope of the TOE.
 Section 3 – TOE Security Environment
This section details the expectations of the environment, the threats that are countered
by the TOE and TOE environment.
 Section 4 – TOE Security Objectives
This section details the security objectives of the TOE and TOE environment.
 Section 5 – IT Security Requirements
The section presents the security functional requirements (SFR) for the TOE, and details
the assurance requirements for EAL4.
 Section 6 – TOE Summary Specification
The section describes the security functions represented in the TOE that satisfy the
security requirements.
 Section 7 – Protection Profile Claims
This section presents any protection profile claims.
 Section 8 – Rationale
This section closes the ST with the justifications of the security objectives, requirements
and TOE summary specifications as to their consistency, completeness, and suitability.
1.1 Security Target, TOE and Common Criteria Identification
ST Title – Mobile Armor DataArmor and PolicyServer Security Target
ST Version – Version 1.72
ST Date – 4/2/2010
TOE Identification – Mobile Armor PolicyServer 3.1 and DataArmor 3.1 (Version 3.1.0.8 for Mobile
Device and Version 3.1.0.788 for the Mac)
TOE Developer – Mobile Armor, Inc.
Evaluation Sponsor – Mobile Armor, Inc.
© Mobile Armor, Inc. 2010 Version 1.72 Security Target Introduction
- (2) -
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1,
Revision 2, September 2007
1.2 Conformance Claims
This TOE is conformant to the following CC specifications:
 Common Criteria for Information Technology Security Evaluation Part 2: Security Functional
Requirements, Version 3.1, Revision 2, September 2007.
o Part 2 Conformant
 Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance
Requirements, Version 3.1, Revision 2, September 2007.
o Part 3 Conformant
o Assurance Level: EAL 4 augmented with ALC_FLR.3
1.3 Conventions
The following conventions have been applied in this document:
 Security Functional Requirements – Part 2 of the CC defines the approved set of operations
that may be applied to functional requirements: iteration, assignment, selection, and
refinement.
o Iteration: allows a component to be used more than once with varying operations. In
the ST, iteration is indicated by a letter placed at the end of the component. For
example FDP_ACC.1a and FDP_ACC.1b indicate that the ST includes two iterations
of the FDP_ACC.1 requirement, a and b.
o Assignment: allows the specification of an identified parameter. Assignments are
indicated using bold and are surrounded by brackets (e.g., [assignment]). Note that
an assignment within a selection would be identified in italics and with embedded
bold brackets (e.g., [[selected-assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are
indicated using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for
additions, and strike-through, for deletions (e.g., “… all objects …” or “… some big
things …”).
 Other sections of the ST – Other sections of the ST use bolding to highlight text of special
interest, such as captions.
© Mobile Armor, Inc. 2010 Version 1.72 Security Target Introduction
- (3) -
1.4 Terminology
1.4.1 Acronyms
Acronym Meaning
DADB DataArmor Database
DAOS DataArmor Operating System
DEK Disk Encryption Key
MBR Master Boot Record
OCSP Online Certificate Status Protocol
OS Operating System
SSO Single Sign-on
Table 1 - Acronyms
1.4.2 Definitions
 Authentication Credentials: This term is used generically to refer to a user‟s username and
authentication data entered at login (i.e. username and password).
 Authentication Data: This term is used generically to refer to the data entered at login, such
as a fixed password.
 Authentication Mechanisms: There are several authentication mechanisms available and they
are noted under this heading. These mechanisms are further classified into two categories,
normal and help.
o Normal Password Mechanisms: These mechanisms are designed for use in
“everyday” authentication.
 Fixed Password Mechanism: This mechanism is the common method of
authentication using letters, numbers and symbols. This method is available
on DataArmor for PC, DataArmor for WM and the PolicyServer.
 Note that Single Sign-on is a Fixed Password Mechanism that will
also pass the entered password automatically to the installed OS
login.
 PIN Mechanism: This mechanism is a numeric password, like that used for
accessing an ATM. This method is only available on DataArmor for PC and
DataArmor for WM.
 Smart Card Mechanism: This mechanism uses smart cards for
authentication. This method is available on both DataArmor for PC and the
PolicyServer.
o Help Password Mechanisms: This mechanism is designed for use in situations where
the user is unable to login normally. For example, the user has forgotten their
password, or lost/misplaced a smart card, or has a locked account.
 Remote Authentication Mechanism: This mechanism uses a challenge and
response sequence passed verbally (such as by phone) from the DataArmor
user to an Authorized Administrator in the PolicyServer Console and back to
provide authentication to the client. This method is only available on
DataArmor for PC and DataArmor for WM.
 Authenticators: A term used to refer to both Enterprise and Group Authenticators
© Mobile Armor, Inc. 2010 Version 1.72 Security Target Introduction
- (4) -
 Authorized Administrators: A term used to specify administrators and authenticators in
general, but with the understanding that an administrator or authenticator is authorized to
provide administration to users at or below their position in the user directory hierarchy. For
example, Enterprise Administrators can perform administration at all levels of the hierarchy,
but Group Administrators can only perform administration at groups that are at or below their
group in the hierarchy. When this term is used, it is to be understood that the administrator or
authenticator in question is not able to exceed their hierarchical authority.
 Authorized user: A term used within SFR assignment operations to refer to authenticated
users of the TOE.
 DADB: This term is defined to mean the protected internal storage area on a DataArmor-
protected client and is stored as part of and protected by DataArmor.
 DAOS: This is term is used to mean the authentication component of DataArmor when
installed on a PC.
 Device: this term is used generically to mean any system where DataArmor can be installed,
PCs, laptops, PDAs and smartphones.
 MD User: this is defined as any user assigned to a Mobile Device. The PolicyServer has a
role of “Users” for any account which can access a client device. MD Users is defined here
specifically as the role of User as assigned from the PolicyServer, on a Mobile Device.
 Mobile Device: this term is used generically to mean PDAs or smartphones which run
Microsoft Windows Mobile.
 OCSP Responder: An OCSP Responder is a server which can respond to OCSP requests
from a client to verify the status of a certificate, in this case the certificate on a smart card.
OCSP responders are defined by the RFC 2560.
 Persistent storage: A term used to specify the media or data that is encrypted by the
DataArmor client. The specific meaning of the term is defined by the context in which it is
used. When used in the following contexts, it will mean:
o DataArmor on Windows, RHEL, SUSE or Mac: persistent storage refers to the
internal hard disks of the computer,
o DataArmor for Windows Mobile: persistent storage refers to the internal Mail,
Calendar, Contacts and Tasks databases. It should be noted that the file encryption
services offered by DataArmor on this platform are not included as part of the
evaluation.
 Policy Administrators: A term used to specify Enterprise and Group Administrators in general,
excluding Authenticators, but with the understanding that an administrator is authorized to
provide policy administration at or below their position in the user directory hierarchy. When
this term is used, it is to be understood that the administrator in question is not able to exceed
their hierarchical authority.
 PolicyServer database: This term is used to talk generically about the two databases (log and
policy) that the PolicyServer maintains. The PolicyServer databases are stored in SQL
Server.
o Log database: This term is used to specifically talk about the log database. All
PolicyServer logs are stored here directly, and all DataArmor logs are eventually
stored here once they have been uploaded to the PolicyServer.
o Policy database: This term is used to specifically talk about the policy database which
stores everything for the management and configuration of PolicyServer and
DataArmor except the logs.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (5) -
2. TOE Description
The Target of Evaluation (TOE) is Mobile Armor DataArmor 3.1 (Version 3.1.0.8 for Mobile Device
and Version 3.1.0.788 For the Mac) a client, and PolicyServer 3.1, the management server.
DataArmor is a client application that is used to encrypt the persistent storage on the device where it
is installed without any user intervention. The client can be installed on computers running Microsoft
Windows operating systems, Mac OS X, Red Hat Linux and SUSE Linux as well as mobile phones
running Microsoft Windows Mobile. The client required user to authenticate to it before access to the
device, including both the operating system and any data, is granted.
The PolicyServer is a server application that can be used to manage one or more instances of
DataArmor applications from a centralized location in the TOE environment. The PolicyServer
provides policy, user and device management of the DataArmor clients as well as centralized audit
storage.
The purpose of the TOE is to provide encryption of data-at-rest on supported devices, not to provide
active protection of the data while the protected device is in use, nor is it designed to provide access
control to the stored data inside the OS once the user has successfully authenticated to the TOE. The
protection offered is to ensure data is not accessible to unauthorized users after an authorized user
has logged out of DataArmor or turned off the device.
The remainder of this section summarizes the TOE architecture.
2.1 TOE Overview
The protection of the TOE is provided through the DataArmor client, as configured and managed
through the PolicyServer as a combination of authentication and encryption. DataArmor is designed
to provide automatic encryption of all data stored in persistent storage, traditionally called “data-at-
rest” using a FIPS 140-2-validated cryptographic module. The automatic encryption of all data
provides an environment where a user does not need to actively protect their data, minimizing the
impact of the protection on the user‟s everyday experience.
DataArmor is designed to insert itself into the startup sequence of the installed operating system on
any device where it is installed. This allows DataArmor to interrupt the normal startup sequence of the
device operating system and prompt the user for authentication before access to the protected data is
granted. The method of interruption is specific to the targeted platform. For example, on a PC,
DataArmor takes control of the Master Boot Record (or similar) on the hard disk, and instead of
booting to the installed OS, boots to itself. On a mobile device, DataArmor hooks into the startup
sequence of the Windows Mobile OS and enforces authentication before granting access to the user
interface and stored data.
The authentication credentials are controlled by the PolicyServer administrators (for example, the
type of credential to be used, and restrictions about the credentials, such as a fixed password of at
least 8 characters with a mix of letters, numbers and symbols, or the use of a smart card). Successful
authentication will allow the OS to continue starting and allow access to protected data from inside
the installed OS.
To enforce the controls provided by the authentication, the client encrypts all the data on the device‟s
internal storage media (referred to as persistent storage). For example, on a PC this would mean
encrypting the entire hard disk, while on a mobile device this would mean encrypting the application
databases on the device (referred to as persistent storage). Once the encryption is complete, a user
will not be able to see any data without successful authentication as no clear text data is left beyond
that necessary to begin the device startup (such as the MBR).
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (6) -
The user‟s authentication credentials are used to protect the Disk Encryption Key (DEK), the 256-bit
AES key which is used to encrypt the data on the persistent storage. Each user with permission to
access the client will have an encrypted copy of the DEK. The encrypted DEK for a user is only
changed when the user‟s authentication credentials changes (i.e. the user changes their password),
such that the new credentials will unlock the DEK. In most cases the authentication credentials are
hashed to generate a key which can decrypt the DEK, though when smart cards are used, the
cryptographic functions of the card are used to protect the DEK, which is never written in clear text to
the persistent storage. The DEK is generated by the PolicyServer as part of the installation process,
with a unique DEK generated for each instance of DataArmor. For recovery purposes, a copy of the
key is encrypted and stored on the PolicyServer.
Once the DEK has been decrypted (by performing a successful authentication), it is loaded into a
filter driver designed for the installed OS. This filter driver allows the installed OS to boot and to
continue operating normally after the authentication. The drivers execute in the kernel space of the
OS and are available for subsequent read and write operations to automatically encrypt and decrypt
the contents of the persistent storage without user intervention. When the user (or operating system)
attempts to access data that has been encrypted, the filter driver will automatically decrypt the data.
Further, when the user (or operating system) attempts to save data to the persistent storage, the filter
driver will automatically encrypt the data.
The DAOS is protected according to the device. On a PC this is protected uniquely on each disk with
a disk-specific key. The entire component is encrypted with this key during the installation process,
including the DADB for policies, logs and user data, such as the user‟s encrypted DEK. This key is
able to be generated from device-specific parameters as part of the boot process, decrypting the
component into memory (but not on the disk). All data written by the DAOS is encrypted in the DADB,
nothing is written in clear text. On a mobile device the DAOS is protected by a digital signature that
ensures it has not been tampered with. The DADB is protected in the same way on both types of
devices.
The PolicyServer is the administration component of the TOE, providing authorized administrators
with the ability to configure the policies which control the DataArmor clients. The PolicyServer
functionality can be generally divided into four areas: policy management, user management, device
management and audit review. Additionally, some authentication mechanisms communicate with the
PolicyServer for authorization of the user.
Management on the PolicyServer is hierarchical. The administrators can create groups and sub-
groups to form an administrative structure for managing users, devices and their associated policies.
Management authority flows down the hierarchy, allowing for the creation of higher and lower level
administrators with full or limited access as necessary.
Installed DataArmor clients connect to the PolicyServer on regular intervals, including during all
authentication sequences and periodically once the OS has been started. During these connection
events, DataArmor will download the current set of policies for the device and upload any new log
events to the PolicyServer.
Policy management controls the configuration of the DataArmor clients. An administrator can create a
set of policies, from authentication credential settings to the amount of time a client can go without
connecting to the PolicyServer before the device becomes locked. In addition to the management of
client policies, there are policies related to accessing the PolicyServer via the management console,
such as a login banner and console locking conditions (i.e. inactivity timeouts and failed login
attempts).
User and device management provides a means for assigning users to devices (this is done in the
above mentioned groups). Once created, users can also be assigned administrative authority, which
provides access to the administration console and possibly the ability to manage policies (depending
on the level of authority assigned). Device management can control locking and unlocking of the
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (7) -
devices as well as remote wiping of the device (such as when the device may have been reported
lost).
The PolicyServer provides an interface for reviewing all logs generated in the system. This includes
logs generated on the server related to administrative activity as well as all logs uploaded from clients
to the PolicyServer. The records can be reviewed both on a group-by-group basis as well as a
system-wide basis. Additionally, alerts can be triggered based on incoming client audit records,
notifying administrators of potential problems, such as multiple failed logins.
There are situations where DataArmor PC clients will be offline from the PolicyServer (i.e. out of
contact) and need some level of basic management. The DAOS provides the recovery console for
this purpose. The recovery console provides basic user administration and log review, but does not
provide any means for editing policy settings. The console also provides recovery capabilities, such
as decrypting the hard disk when the system can no longer be started. All user changes made
through the recovery console will be overwritten by the PolicyServer if DataArmor connects to the
server and the changes have not also been made there.
2.2 TOE Architecture
The TOE can be described in terms of the following components:
 Mobile Armor DataArmor client – Provides encryption and enforcement of authentication
decisions implemented within the TOE. Includes pre-operating system DAOS and data
encryption components.
 Mobile Armor PolicyServer – Provides administrative interfaces that can be used to manage
DataArmor encryption and authentication policy functions. The administrative PolicyServer
interface implemented as a Microsoft Management Console (MMC) “snap-in”, which displays
PolicyServer GUI components within a MMC GUI window pane called a “console”.
Figure 1 below illustrates the TOE as it can be deployed in a customer environment. The pieces in
the configuration are color coded to illustrate the different components and how they relate to the
TOE. The red box indicates DataArmor clients. The blue box indicates PolicyServer components,
including both the server pieces and the management client. The orange box indicates external
services which are required for the evaluated configuration, in this case an Email server. The green
boxes indicate optional services which can be connected to the system, but which are not required.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (8) -
DataArmor, DriveArmor, FileArmor & KeyArmor
Client PCs
PolicyServer Configuration
Internet
`
Encrypted XML
(SOAP)
Encrypted XML
(HTTP)
External Authentication Services
Microsoft
Active Directory
DataArmor, DriveArmor, FileArmor &
KeyArmor Client PCs
`
External
Authentication
Services
OCSP
Responder
PolicyServer
Management
Clients
PolicyServer
Management Clients
`
`
Email Server
DataArmor Client Mobile Devices
Optional
Load
Balancer
DataArmor, DriveArmor, FileArmor & KeyArmor Clients
PolicyServer Components
Optional External Services
Required External Services
PolicyServer
Database
PolicyServer
Service
Color Key
The TOE components here rely on the IT
Environment. For example, the PolicyServer
Database relies on SQL Server (and by
extension, Windows Server 2003).
Figure 1 - Mobile Armor Solution Architecture
The intended environment of the TOE is dependent on the piece of the TOE being described.
The DataArmor portion of the intended environment can be described in terms of the following
components:
 Operating systems – Provides runtime environment for DataArmor application components.
 OCSP Responder Server – Provides optional external authentication services for DataArmor
for direct verification of smart card certificate status.
The PolicyServer portion of the intended environment can be described in terms of the following
components:
 Operating systems – Provides runtime environment PolicyServer application components.
Provides operating system GUI interfaces for PolicyServer. Provides web server for interface
between PolicyServer and clients.
 Database – Provides storage for PolicyServer policy and log databases.
 Mail Server – Provides SMTP server for use in email alert configuration.
 Authentication servers – Provides optional external authentication services for DataArmor
users by proxy through the PolicyServer.
 Load Balancer – Provides optional scalability by allowing multiple PolicyServers to be
configured together as one.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (9) -
2.2.1 Physical Boundaries
The TOE is a software product, and as such the physical boundary of the TOE is defined as the files
and information stored on the device where it is installed. The TOE functions are implemented
uniformly across all supported OS platforms.
The following software packages are considered to be the TOE:
 PolicyServer Service
 PolicyServer Database (the database created in SQL Server)
 PolicyServer Management Console
 Active Directory Plug-in
 DataArmor for PC on the platforms listed below
 DataArmor for Windows Mobile on the platforms listed below
Any other products which may be attached to this configuration are not considered part of the
evaluated configuration.
The operational environment of TOE depends on the following:
 PolicyServer
o Operating systems
 For the PolicyServer Service
 Microsoft Windows Server 2003 SP1+, Standard or Enterprise
Editions
 For the PolicyServer Management console
 Microsoft Windows 2000 Professional SP4
 Microsoft Windows XP or XP Tablet Edition SP3
 Microsoft Windows Vista SP1
 Microsoft Report Viewer 2005
o Database
 Microsoft SQL Server 2005 with Service Pack 2+
o External Mail Server
 DataArmor PC platforms
o Microsoft Windows 2000 Professional SP4
o Microsoft Windows XP or XP Tablet Edition SP3
o Microsoft Windows Vista SP1
o Red Hat Enterprise Linux 5 (kernel 2.6.18-92)
o SUSE Linux Enterprise Desktop 10 (kernel 2.6.16.60-0.21)
o Intel-based Mac OS X 10.5
 DataArmor mobile device platforms
o Microsoft Windows Mobile 6.0
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (10) -
 Optionally - Authentication servers (for external authentication integration):
o Microsoft Active Directory
o OCSP Responder Server (such as Tumbleweed Valicert Validation Authority or
Windows Server 2008)
2.2.2 Logical Boundaries
This section summarizes the security functions provided by the TOE:
 Security audit
 Cryptographic support
 User data protection
 Identification and authentication
 Security management
 Protection of the TSF
 Resource Utilization
 TOE Access
 Trusted Path/Channels
2.2.2.1 Security audit
The TOE generates audit records for actions taken in DataArmor and the PolicyServer. The
management console provides a way to restrict access to the audit records to authorized
administrators. The OS is relied on to provide reliable time stamps for use in audit records. On PC
clients it is expected that the OS will properly set the BIOS hardware clock and utilize that time as
accurate since the OS is not available before authentication.
The audit records that are taken can be divided into three broad categories: authentication actions,
management actions and status messages. Authentication logs cover all attempts to login to the
client or server, and record success and failure, as well as conditions such as locking the device or
user. Management actions cover all actions taken on the PolicyServer (managing users, policies, etc)
as well as those actions taken through the DataArmor recovery console. Status messages cover
events such as the startup and shutdown of functions which can provide audit records, failure
messages related to TOE functions (such as a client not being able to contact the server), and
encryption status.
Audit records recorded on the client are stored there until a connection is made with the PolicyServer
at which time they are sent to the PolicyServer for central storage (they will be stored in the
PolicyServer log database). While stored on the client, the audit records are stored in a secure DADB
and protected against tampering. The clients are capable of storing at least 4000 log messages
before wrapping will occur and the oldest messages will be lost (a first in-first out system). Audit
records generated on the PolicyServer are stored directly into the PolicyServer log database.
The PolicyServer provides tamper detection for audit records once they have been stored in the
PolicyServer log database, but relies on the TOE environment to prevent the actual tampering.
The PolicyServer provides an alert notification system via email to notify administrators of potential
security violations. The DataArmor login will notify authenticated users of potential security violations
on systems where they login.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (11) -
2.2.2.2 Cryptographic support
The TOE provides its own FIPS-validated cryptographic module which performs symmetric encryption
and decryption operations on cryptographic keys, storage media, and data or commands sent over a
network. AES algorithm is used for this encryption. Additional algorithms are also supported for
random number generation and various hashing functions. All algorithms are FIPS-validated.
2.2.2.3 User data protection
The TOE provides the ability to restrict access to any data and the services that may be provided by
that data (such as an OS) on a supported device. All users are subject to the Data Access Control
Policy where data access is controlled by the TOE.
2.2.2.4 Identification and authentication
The TOE requires users to be identified and authenticated before access is allowed to protected data.
Administrators can choose from several different authentication mechanisms based on the needs of
the organization, including the ability to link to external authentication services.
2.2.2.5 Security management
The TOE provides the ability to manage users and groups, encryption settings, and authentication
server settings. The TOE provides five levels of authority: Enterprise Administrator, Enterprise
Authenticator, Group Administrator, Group Authenticator and User. Administrators and Authenticators
have access to the management console and the DAOS recovery console, with their access being
determined by where their authority is granted in the hierarchy. Users only have the ability to login to
DataArmor clients.
2.2.2.6 Protection of the TSF
For the DataArmor component, the TOE provides pre-access authentication components (DAOS) and
filter driver components. Configuring bootstrap information ensures that TOE interfaces cannot be
bypassed. When the TOE starts, it performs several tests to ensure it is properly functioning and that
security has not been compromised. Once the OS has started, DataArmor relies on the secure
execution environment of the OS to provide protection for the filter driver.
For the PolicyServer component, the TOE relies on the operating system to restrict access to its
software as well as the database where the TOE information is stored.
The TOE encrypts its communication between DataArmor and the PolicyServer by encrypting and
decrypting SOAP messages sent and received using HTTP. Commands sent by the PolicyServer to
mobile devices using SMS or email are encrypted uniquely for the device receiving the command.
2.2.2.7 Resource Utilization
The TOE client, DataArmor is able to maintain and ensure the proper application of its existing
policies even when communications are unavailable.
2.2.2.8 TOE Access
The TOE can provide a login banner to all users accessing DataArmor as well as all authorized
administrators accessing the management console.
2.2.2.9 Trusted Path/Channels
The TOE provides a method of establishing a trusted session with the user for authentication through
a restart of the DataArmor-protected device.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Description
- (12) -
2.3 TOE Documentation
Mobile Armor offers a series of documents that describe the installation process for the TOE as well
as guidance for subsequent use and administration of the applicable security features.
The documentation for the TOE is:
 PolicyServer™ v3.1 Administration Guide
 PolicyServer™ v3.1 Installation Guide
 PolicyServer™ v3.1 Administration Appendices
 DataArmor™ v3.1 PC Installation Guide
 DataArmor™ v3.1 PC User Guide
 DataArmor™ v3.1 PC Administration Guide
 DataArmor™ v3.1 Windows Mobile Installation Guide
 DataArmor™ v3.1 Windows Mobile User Guide
 Mobile Armor™ v3.1 Certification Guide
© Mobile Armor, Inc. 2010 Version 1.721 TOE Security Environment
- (13) -
3. TOE Security Environment
This section summarizes the threats addressed by the TOE and assumptions about the intended
environment of the TOE. Note that while the identified threats are mitigated by the security functions
implemented in the TOE, the overall assurance level (EAL 4) also serves as an indicator of whether
the TOE would be suitable for a given environment.
3.1 Threats
T.ACCOUNTABILITY A user may not be held accountable for their actions.
T.ADMIN_ERROR An authorized administrator may incorrectly install or configure the
TOE resulting in ineffective security mechanisms.
T.MASQUERADE An unauthorized user, process, or external IT entity may
masquerade as an authorized entity to gain access to data or TOE
resources.
T.SUBVERT A malicious user may cause non-configuration data at rest to be
inappropriately accessed (viewed, modified or deleted).
T.TSF_COMPROMISE A malicious user may cause configuration data to be inappropriately
accessed (viewed, modified or deleted).
T.UNAUTH_ACCESS A user may gain unauthorized access (view, modify, delete) to
configuration data.
3.2 Assumptions
A.LOCATE The server portion of the TOE will be located within controlled
access facilities, which will prevent unauthorized physical access.
A.NO_EVIL The TOE will be installed, configured, managed and maintained in
accordance with its guidance documentation.
A.NO_EVIL_USER Users of the TOE are properly trained in the use of the TOE and will
cooperate with those responsible for administration in maintaining
TOE security.
A.DEVICE_USE Users of the TOE will follow policies to prevent unauthorized physical
access to a TOE-protected device.
A.REPORTS Administrators who need to generate print or export the audit trail, or
view generated reports, will have the proper environment.
© Mobile Armor, Inc. 2010 Version 1.721 Security Objectives
- (14) -
4. Security Objectives
This section summarizes the security objectives for the TOE and its environment.
4.1 Security Objectives for the TOE
O.ACCESS The TOE will ensure that users gain only authorized access to the
TOE and to the resources that the TOE controls.
O.ADMIN_ROLE The TOE will provide authorized administrator roles to isolate
administrative actions.
O.ALERT The TOE will provide the capability to alert authorized users of
potential security violations.
O.AUDIT_GENERATION The TOE will provide the capability to create records of security
relevant events associated with users.
O.AUDIT_REVIEW The TOE will provide the capability to view audit information.
O.CRYPTO_OPS The TOE will ensure that all cryptographic operations are compliant
with FIPS 140-2 Level 1 & 2 based on installed OS (cryptographic
module), FIPS 197 (AES), FIPS 46-3 (3DES), FIPS 180-2 (SHS),
FIPS 198 (HMAC) and ANSI X9.31 (RNG) and that the keys for
those operations are managed accordingly.
O.DATA_TRANSFER The TOE will protect system data in transmission between the client
and server.
O.FAULT_TOLERANCE The TOE must continue to enforce access control policies if
communications with the server are not available or if the server has
detected violations of policy integrity.
O.MANAGE The TOE will allow administrators to effectively manage the TOE and
its security functions, and must ensure that only authorized
administrators are able to access such functionality.
O.TOE_PROTECTION The client portion of the TOE will protect itself and its assets from
external interference or tampering.
O.USER_AUTHENTICATION The TOE will ensure that users are reliably identified and are
authenticated before any access to TOE-protected assets is granted.
4.2 Security Objectives for the TOE Environment
OE.AUDIT_PROTECTION The TOE Environment will be configured to protect audit information
on the server portion of the TOE.
OE.CONFIG The TOE will be installed, configured, managed and maintained in
accordance with its guidance documentation.
OE.USER_GUIDANCE Users of the TOE will be properly trained in the secure usage and
protection of the TOE and the devices where it is installed.
OE.PHYCAL The server portion of the TOE will be located within controlled
access facilities, which will prevent unauthorized physical access.
© Mobile Armor, Inc. 2010 Version 1.721 Security Objectives
- (15) -
OE.TIME The TOE Environment will provide reliable time stamps for use in
audit records.
OE.TOE_PROTECTION The TOE Environment will protect the server portion of the TOE and
the assets under its control from external interference or tampering.
OE.REPORT_ENV The TOE Environment will provide the necessary external software
to print, export and review generated reports on systems where the
management client is installed.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (16) -
5. IT Security Requirements
5.1 Extended Components Definition
There are no extended security requirements defined within this Security Target.
5.2 TOE Security Functional Requirements
The security functional requirements for the TOE are drawn from Part 2 of the Common Criteria, as
represented below.
Requirement Class Requirement Component
FAU: Security audit
FAU_ARP.1a: Security Alarms
FAU_ARP.1b: Security Alarms
FAU_GEN.1: Audit data generation
FAU_GEN.2: User identity association
FAU_SAA.1a: Potential Violation Analysis
FAU_SAA.1b: Potential Violation Analysis
FAU_SAR.1: Audit review
FAU_SAR.2: Restricted audit review
FAU_SAR.3a: Selectable audit review
FAU_SAR.3b: Selectable audit review
FAU_STG.1a: Protected audit trail storage
FAU_STG.1b: Protected audit trail storage
FAU_STG.3: Action in case of possible audit data loss
FCS: Cryptographic support
FCS_CKM.1: Cryptographic key generation
FCS_CKM.3: Cryptographic key access
FCS_CKM.4: Cryptographic key destruction
FCS_COP.1a: Cryptographic operation
FCS_COP.1b: Cryptographic operation
FCS_COP.1c: Cryptographic operation
FDP: User data protection
FDP_ACC.2: Complete access control
FDP_ACF.1: Security attribute based access control
FIA: Identification and
authentication
FIA_AFL.1: Authentication failure handling
FIA_ATD.1: User attribute definition
FIA_UAU.1: Timing of authentication
FIA_UAU.2: User authentication before any action
FIA_UAU.5: Multiple authentication mechanisms
FIA_UAU.6: Re-authenticating
FIA_UAU.7: Protected authentication feedback
FIA_UID.1: Timing of identification
FIA_UID.2: User identification before any action
FMT: Security management
FMT_MSA.1: Management of security attributes
FMT_MSA.2: Secure security attributes
FMT_MSA.3: Static attribute initialization
FMT_MTD.1a: Management of TSF data
FMT_MTD.1b: Management of TSF data
FMT_MTD.1c: Management of TSF data
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (17) -
Requirement Class Requirement Component
FMT_MTD.1d: Management of TSF data
FMT_MTD.1e: Management of TSF data
FMT_MTD.1f: Management of TSF data
FMT_MTD.1g: Management of TSF data
FMT_MTD.2: Management of limits on TSF data
FMT_REV.1: Revocation
FMT_SAE.1: Time-limited authorization
FMT_SMF.1: Specification of Management Functions
FMT_SMR.1: Security roles
FPT: Protection of the TSF
FPT_FLS.1a: Failure with preservation of secure state
FPT_FLS.1b: Failure with preservation of secure state
FPT_ITT.1: Basic internal TSF data transfer protection
FPT_TST.1: TSF Testing
FRU: Resource Utilization FRU_FLT.1: Degraded fault tolerance
FTA: TOE Access FTA_TAB.1:Default TOE Access Banner
FTP: Trusted Path/Channels FTP_TRP.1: Trusted Path
Table 2 - TOE Security Functional Components
5.2.1 Security audit (FAU)
5.2.1.1 Security alarms (FAU_ARP.1a)
FAU_ARP.1a.1 The TSF shall take [action to notify the user on the next successful login after
the potential client violation] upon detection of a potential security violation.
Application note: This requirement is specifically focused on the client portion of the TOE and an end
user login to the TOE after the potential violation has been detected.
5.2.1.2 Security alarms (FAU_ARP.1b)
FAU_ARP.1b.1 The TSF shall take [action to notify the specified Administrators by email] upon
detection of a potential security violation.
Application note: This requirement is specifically focused on alert notification of administrators as
events are uploaded and recorded into the central PolicyServer audit database.
5.2.1.3 Audit data generation (FAU_GEN.1)
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions; b) All auditable events for the [not
specified] level of audit; and c) [see the table below].
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a)
Date and time of the event, type of event, subject identity, and the outcome (success
or failure) of the event; and b) For each audit event type, based on the auditable
event definitions of the functional components included in the PP/ST, [no additional
information].
Application note: The use of the management functions auditable event corresponding to
FMT_SMF.1 is defined as functions to manage user, and group security attributes, policy settings,
and authentication server policy settings.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (18) -
Security Functional
Requirement
Auditable Event(s)
FAU_ARP.1 None
FAU_GEN.1 Start-up and shutdown
FAU_GEN.2 None
FAU_SAA.1 None
FAU_SAR.1-3 None
FAU_STG.1 None
FAU_STG.3 Any action in case of possible audit data loss
FCS_CKM.1 Success and failure of cryptographic operations
FCS_CKM.3 Success and failure of cryptographic operations
FCS_CKM.4 Success and failure of cryptographic operations
FCS_COP.1a-c Success and failure of cryptographic operations
FDP_ACC.2 None
FDP_ACF.1 None
FIA_AFL.1 The reaching of the threshold for the unsuccessful authentication attempts
and the actions (e.g. disabling of a terminal) taken and the subsequent, if
appropriate, restoration to the normal state (e.g. re-enabling of a terminal).
FIA_ATD.1 None
FIA_UAU.1 All use of the authentication mechanism
FIA_UAU.2 All use of the authentication mechanism
FIA_UAU.5 All use of the authentication mechanism and which authentication
mechanism was chosen.
FIA_UAU.6 Failure of reauthentication
FIA_UAU.7 None
FIA_UID.1 All use of the user identification mechanism, including the user identity
provided.
FIA_UID.2 All use of the user identification mechanism, including the user identity
provided.
FMT_MSA.1 All modifications of the values of user and group security attributes.
FMT_MSA.2 All offered and rejected values for a security attribute (password)
FMT_MSA.3 None
FMT_MTD.1a-g None
FMT_MTD.2 None
FMT_REV.1 Unsuccessful revocation of security attributes
FMT_SAE.1 None
FMT_SMF.1 Use of the management functions.
FMT_SMR.1 Modifications to the group of users that are part of a role
FPT_FLS.1 None
FPT_ITT.1 None
FPT_TST.1 None
FRU_FLT.1 Any failure detected by the TSF
FTA_TAB.1 None
FTP_TRP.1 Failures of the trusted path functions
5.2.1.4 User identity association (FAU_GEN.2)
FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the identity of the user
that caused the event.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (19) -
5.2.1.5 Potential violation analysis (FAU_SAA.1a)
FAU_SAA.1a.1 The TSF shall be able to apply a set of rules in monitoring the audited events and
based upon these rules indicate a potential violation of the enforcement of the SFRs.
FAU_SAA.1a.2 The TSF shall enforce the following rules for monitoring audited events:
a.) Accumulation or combination of [ Any failed login attempt on a mobile
device client, or two or more consecutive failed login attempts on a PC
client]
known to indicate a potential security violation;
b.) [no other rules].
Application note: This requirement is specifically focused on the client portion of the TOE and an end
user login to the TOE after the potential violation has been detected.
5.2.1.6 Potential violation analysis (FAU_SAA.1b)
FAU_SAA.1b.1 The TSF shall be able to apply a set of rules in monitoring the audited events and
based upon these rules indicate a potential violation of the enforcement of the SFRs.
FAU_SAA.1b.2 The TSF shall enforce the following rules for monitoring audited events:
a.) Accumulation or combination of [
 Multiple failed login attempts on the client that reach the threshold
defined by the administrator
 Policy value tampering events identified through invalid policy
HMAC values in the PolicyServer policy database
 Log tampering events identified through invalid policy HMAC
values in the PolicyServer log database]
known to indicate a potential security violation;
b.) [no other rules].
Application note: This requirement is specifically focused on alert notification of administrators as
events are uploaded and recorded into the central PolicyServer audit database.
5.2.1.7 Audit Review (FAU_SAR.1)
FAU_SAR.1.1 The TSF shall provide [Authorized Administrators and MD Users] with the
capability to read [all audit information according to the user’s authority] from
the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret
the information.
5.2.1.8 Restricted audit review (FAU_SAR.2)
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users
that have been granted explicit read-access.
5.2.1.9 Selectable audit review (FAU_SAR.3a)
FAU_SAR.3a.1 The TSF shall provide the ability to perform [searches] of audit data based on [any
field].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (20) -
Application note: This requirement is specifically focused on the client portion of the TOE.
5.2.1.10 Selectable audit review (FAU_SAR.3b)
FAU_SAR.3b.1 The TSF shall provide the ability to perform [searches] of audit data based on [user
identity, device name, message ID and date range].
Application note: This requirement is specifically focused on the server portion of the TOE.
5.2.1.11 Protected audit trail storage (FAU_STG.1a)
FAU_STG.1a.1 The TSF shall protect the stored audit records in the audit trail from unauthorized
deletion.
FAU_STG.1a.2 The TSF shall be able to [prevent] unauthorized modifications to the stored audit
records in the audit trail.
Application note: This requirement is specifically focused on the client portion of the TOE.
5.2.1.12 Protected audit trail storage (FAU_STG.1b)
FAU_STG.1b.1 The TSF shall protect the stored audit records in the audit trail from unauthorized
deletion.
FAU_STG.1b.2 The TSF shall be able to [detect] unauthorized modifications to the stored audit
records in the audit trail.
Application note: This requirement is specifically focused on the server portion of the TOE, and the
term “audit trail” here is defined as the PolicyServer log database.
5.2.1.13 Action in case of possible audit data loss (FAU_STG.3)
FAU_STG.3.1 The TSF shall [the action of overwriting the oldest audit records first] if the audit
trail exceeds [4000 recorded events that have not been transferred to the
PolicyServer].
5.2.2 Cryptographic support (FCS)
5.2.2.1 Cryptographic key generation (FCS_CKM.1)
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [ANSI X9.31 RNG] and specified
cryptographic key sizes [AES 256 bits] that meet the following: [FIPS 140-2, Section
4.7.2 Key Generation].
5.2.2.2 Cryptographic key access (FCS_CKM.3)
FCS_CKM.3.1 The TSF shall perform [cryptographic key escrow] in accordance with a specified
cryptographic key access method [duplication] that meets the following: [no
standard].
5.2.2.3 Cryptographic key destruction (FCS_CKM.4)
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a [zeroization] that
meets the following: [FIPS PUB 140-2 Section 4.7.6 Key Zeroization].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (21) -
5.2.2.4 Cryptographic operation (FCS_COP.1a)
FCS_COP.1a.1 The TSF shall perform [symmetric encryption and decryption] in accordance with
a specified cryptographic algorithm [AES] and cryptographic key sizes [OFB, CBC
and ECB modes with 256 bit keys] that meet the following: [FIPS 197].
5.2.2.5 Cryptographic operation (FCS_COP.1b)
FCS_COP.1b.1 The TSF shall perform [secure hashing] in accordance with a specified
cryptographic algorithm [SHA-1, SHA-224, SHA-256, SHA-384, SHA-512] and
cryptographic key sizes [not applicable] that meet the following: [FIPS 180-2].
5.2.2.6 Cryptographic operation (FCS_COP.1c)
FCS_COP.1c.1 The TSF shall perform [message authentication] in accordance with a specified
cryptographic algorithm [HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-
SHA384, HMAC-SHA512] and cryptographic key sizes [KS<BS, KS=BS, KS>BS]
that meet the following: [FIPS 198].
5.2.3 User data protection (FDP)
5.2.3.1 Complete access control (FDP_ACC.2)
FDP_ACC.2.1 The TSF shall enforce the [Data Access Control Policy] on [subjects: all users;
objects: all data stored on persistent storage] and all operations among subjects
and objects covered by the SFP.
FDP_ACC.2.2 The TSF shall ensure that all operations between any subject controlled by the TSF
and any object controlled by the TSF are covered by an access control SFP.
5.2.3.2 Security attribute based access control (FDP_ACF.1)
FDP_ACF.1.1 The TSF shall enforce the [Data Access Control Policy] to objects based on the
following: [security attributes: subject: user identity and authentication data;
object: storage encryption keys].
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [Successfully authenticated
users (and administrators) have their storage encryption keys decrypted by the
provided authentication credentials and used to access the encrypted
persistent storage data. If authentication is unsuccessful, access to the
encrypted persistent storage data is denied.].
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: [there are no additional authorization rules].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the: [there are
no additional denial rules].
5.2.4 Identification and authentication (FIA)
5.2.4.1 Authentication failure handling (FIA_AFL.1)
FIA_AFL.1.1 The TSF shall detect when [an administrator configurable positive integer within
[1-10]] unsuccessful authentication attempts occur related to [any logon].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (22) -
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or
surpassed, the TSF shall [perform one of the following actions based on the
configured policy:
 On DataArmor, one of the following:
o Lock the user account until unlocked with Remote
Authentication,
o Erase the device
o Specify a Time Delay before further login attempts
 On PolicyServer Management Console
o Lock the user account until unlocked by a Policy
Administrator].
5.2.4.2 User attribute definition (FIA_ATD.1)
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual
users: [
 On DataArmor:
o user identity,
o group membership,
o role,
o User’s encrypted Disk Encryption Keys (DEKs)
 On the PolicyServer
o user identity,
o authentication data as related to PolicyServer
administration roles,
o group membership,
o role].
5.2.4.3 Timing of authentication (FIA_UAU.1)
FIA_UAU.1.1 The TSF shall allow [the following actions based on the device type:
 On PC clients:
o Manual policy download
o View Support Info text
o View If Found text
o Set mark to change password after successful
authentication
 On Mobile Device clients:
o users to receive and accept incoming phone calls and make
outgoing phone calls on devices which have built-in cellular
voice telephone hardware
o View Support Info text
o View If Found text
o View Device Info]
on behalf of that user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
Application note: This requirement is specifically focused on the client portion of the TOE.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (23) -
5.2.4.4 User authentication before any action (FIA_UAU.2)
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
Application note: This requirement is specifically focused on the server portion of the TOE.
5.2.4.5 Multiple authentication mechanisms (FIA_UAU.5)
FIA_UAU.5.1 The TSF shall provide [
 Fixed Password Mechanism
 Smart Card Mechanism
 PIN Mechanism
 Remote Authentication Mechanism]
to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the [following
rules:
 The Fixed Password, Smart Card, or PIN mechanism must be used
for normal login of all users to DataArmor
 The Fixed Password or Smart Card mechanism must be used for
any login to the PolicyServer management console
 The Remote Authentication Mechanism may be used in cases
where normal login to DataArmor is not possible (such as a
forgotten password or lost smart card)
 The Remote Authentication mechanism may be required when a
DataArmor user account or DataArmor-protected device has
become locked based on policies set by the administrator].
5.2.4.6 Re-authenticating (FIA_UAU.6)
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [the PolicyServer
management interface has been inactive for an administrator specified time].
Application note: This requirement is specifically focused on the server portion of the TOE.
5.2.4.7 Protected authentication feedback (FIA_UAU.7)
FIA_UAU.7.1 The TSF shall provide only [obscured feedback] to the user while the authentication
is in progress.
5.2.4.8 Timing of identification (FIA_UID.1)
FIA_UID.1.1 The TSF shall allow [the following actions based on the device type:
 On PC clients:
o Manual policy download
o View Support Info text
o View If Found text
o Set mark to change password after successful
authentication
 On Mobile Device clients:
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (24) -
o users to receive and accept incoming phone calls and make
outgoing phone calls on devices which have built-in cellular
voice telephone hardware
o View Support Info text
o View If Found text
o View Device Info]
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
Application note: This requirement is specifically focused on the client portion of the TOE.
5.2.4.9 User identification before any action (FIA_UID.2)
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
Application note: This requirement is specifically focused on the server portion of the TOE.
5.2.5 Security management (FMT)
5.2.5.1 Management of security attributes (FMT_MSA.1)
FMT_MSA.1.1 The TSF shall enforce the [Data Access Control Policy] to restrict the ability to
[manage] the security attributes [of users] to [Authorized Administrators].
Application note: The term „manage‟ in the SFR above is intended to ensure that ANY means of
manipulation of the applicable security attributes is appropriately controlled, rather than limiting the
protection to a discrete set of possible management operations.
5.2.5.2 Secure security attributes (FMT_MSA.2)
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security attributes.
5.2.5.3 Static attribute initialization (FMT_MSA.3)
FMT_MSA.3.1 The TSF shall enforce the [Data Access Control Policy] to provide [restrictive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [no role] to specify alternative initial values to override the
default values when an object or information is created.
5.2.5.4 Management of TSF data (FMT_MTD.1a)
FMT_MTD.1a.1 The TSF shall restrict the ability to [[search]] the [audit trail] to [Authorized
Administrators].
5.2.5.5 Management of TSF data (FMT_MTD.1b)
FMT_MTD.1b.1The TSF shall restrict the ability to [[create], delete, modify] the [Enterprise Alert
configuration] to [Enterprise Administrators].
5.2.5.6 Management of TSF data (FMT_MTD.1c)
FMT_MTD.1c.1 The TSF shall restrict the ability to [query, modify] the [security-relevant roles] to [
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (25) -
 Policy Administrators from the PolicyServer management console
 Authorized Administrators from the DataArmor recovery console].
5.2.5.7 Management of TSF data (FMT_MTD.1d)
FMT_MTD.1d.1The TSF shall restrict the ability to [[initialize], delete] the [encryption keys] to
[Authorized Administrators].
5.2.5.8 Management of TSF data (FMT_MTD.1e)
FMT_MTD.1e.1 The TSF shall restrict the ability to [modify] the [authentication data] to
[Authorized Administrators, and users (for their own authentication data)].
5.2.5.9 Management of TSF data (FMT_MTD.1f)
FMT_MTD.1f.1 The TSF shall restrict the ability to [query, modify] the [authentication data policy
settings (such as the type of mechanism used, and the requirements for the
method)] to [Policy Administrators].
5.2.5.10 Management of TSF data (FMT_MTD.1g)
FMT_MTD.1g.1The TSF shall restrict the ability to [query, modify] the [Authentication failure
settings] to [Policy Administrators].
5.2.5.11 Management of limits on TSF data (FMT_MTD.2)
FMT_MTD.2.1 The TSF shall restrict the specification of the limits for [Authentication failure
settings] to [Policy Administrators].
FMT_MTD.2.2 The TSF shall take the following actions, if the TSF data are at, or exceed, the
indicated limits: [
 On DataArmor, one of the following:
o Lock the user account until unlocked by an Authorized
Administrator with Remote Authentication
o Erase the contents of the device
o Specify a Time Delay before further login attempts
 On PolicyServer Management console
o Lock the user account until unlocked by a Policy
Administrator].
5.2.5.12 Revocation (FMT_REV.1)
FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributes associated with the
[users] under the control of the TSF to [
 Policy Administrators from the PolicyServer Management Console
 Authorized Administrators from the DataArmor Recovery Console].
FMT_REV.1.2 The TSF shall enforce the rules [
 Immediately if performed through the DataArmor Recovery
Console, or
 Revocation will take place at the current login on a device in
contact with the PolicyServer, or
 At the next login after connection to the PolicyServer if the device is
not in contact at the time of the login].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (26) -
5.2.5.13 Time-limited authorization (FMT_SAE.1)
FMT_SAE.1.1 The TSF shall restrict the capability to specify an expiration time for [fixed password
and PIN authentication data for the User role used for DataArmor logins] to [
 Policy Administrators from the PolicyServer management console
 Authorized Administrators from the DataArmor recovery console].
FMT_SAE.1.2 For each of these security attributes, the TSF shall be able to [prevent user login
until the authentication data is successfully changed] after the expiration time for
the indicated security attribute has passed.
Application note: On the recovery console, an expiration date can only be set for the fixed password
mechanism.
5.2.5.14 Specification of Management Functions (FMT_SMF.1)
FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions:
[
 query the audit trail
 management of Enterprise Alerts
 manage user security attributes
 manage device policy settings and security attributes
 manage authentication policy settings].
5.2.5.15 Security roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the roles [
 On PolicyServer
o Enterprise Administrator
o Group Administrator
o Enterprise Authenticator
o Group Authenticator
o User
 In DAOS recovery console
o Administrator
o Authenticator
o User
 On Windows Mobile devices
o MD User].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application note: The roles specified in the management requirements, Policy Administrators and
Authorized Administrators, are combinations of the specific roles listed above used to simplify the
statement of requirements. Policy Administrators is defined to mean Enterprise and Group
Administrators, while Authorized Administrators is defined to mean any Administrator or
Authenticator.
5.2.6 Protection of the TSF (FPT)
5.2.6.1 Failure with preservation of secure state (FPT_FLS.1a)
FPT_FLS.1a.1 The TSF shall preserve a secure state when the following types of failures occur:
[communications with the PolicyServer are not available].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (27) -
5.2.6.2 Failure with preservation of secure state (FPT_FLS.1b)
FPT_FLS.1b.1 The TSF shall preserve a secure state when the following types of failures occur:
[policies are found to not have the proper HMAC value].
5.2.6.3 Basic internal TSF data transfer protection (FPT_ITT.1)
FPT_ITT.1.1 The TSF shall protect TSF data from [disclosure, modification] when it is
transmitted between separate parts of the TOE.
Application note: The PolicyServer component encrypts its communication with DataArmor by
encrypting and decrypting SOAP messages sent and received using HTTP and by encrypting
commands sent by SMS or email to mobile devices.
5.2.6.4 TSF testing (FPT_TST.1)
FPT_TST.1.1 The TSF shall run a suite of self tests [during initial start-up] to demonstrate the
correct operation of [the TSF].
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the integrity of
[[Mobile Armor Cryptographic Module]].
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the integrity of
stored TSF executable code.
5.2.7 Resource Utilization (FRU)
5.2.7.1 Degraded fault tolerance (FRU_FLT.1)
FRU_FLT.1.1 The TSF shall ensure the operation of [normal user functionality and device
access] when the following failures occur: [communications with the PolicyServer
are not available].
5.2.8 TOE Access (FTA)
5.2.8.1 Default TOE access banner (FTA_TAB.1)
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorized use of the TOE.
5.2.9 Trusted Path/Channels (FTP)
5.2.9.1 Trusted path (FTP_TRP.1)
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [local] users that is
logically distinct from other communication paths and provides assured identification
of its end points and protection of the communicated data from modification or
disclosure.
FTP_TRP.1.2 The TSF shall permit [the TSF] to initiate communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [initial user authentication].
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (28) -
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the EAL 4 components as specified in Part 3 of
the Common Criteria. No operations are applied to the assurance components.
Requirement Class Requirement Component
ADV: Development
ADV_ARC.1: Security architecture description
ADV_FSP.4: Complete functional specification
ADV_IMP.1: Implementation representation of the TSF
ADV_TDS.3: Basic modular design
AGD: Guidance documents
AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-cycle support
ALC_CMC.4: Production support, acceptance
procedures and automation
ALC_CMS.4: Problem tracking CM coverage
ALC_DEL.1: Delivery procedures
ALC_DVS.1: Identification of security measures
ALC_FLR.3: Systematic flaw remediation
ALC_LCD.1: Developer defined life-cycle model
ALC_TAT.1: Well-defined development tools
ATE: Tests
ATE_COV.2: Analysis of coverage
ATE_DPT.2: Testing: security enforcing modules
ATE_FUN.1: Functional testing
ATE_IND.2: Independent testing - sample
AVA: Vulnerability
assessment
AVA_VAN.3: Focused vulnerability analysis
Table 3 - EAL 4 Assurance Components
5.3.1 Development (ADV)
5.3.1.1 Security architecture description (ADV_ARC.1)
ADV_ARC.1.1d The developer shall design and implement the TOE so that the security features
of the TSF cannot be bypassed.
ADV_ARC.1.2d The developer shall design and implement the TSF so that it is able to protect
itself from tampering by untrusted active entities.
ADV_ARC.1.3d The developer shall provide a security architecture description of the TSF.
ADV_ARC.1.1c The security architecture description shall be at a level of detail commensurate
with the description of the SFR-enforcing abstractions described in the TOE
design document.
ADV_ARC.1.2c The security architecture description shall describe the security domains
maintained by the TSF consistently with the SFRs.
ADV_ARC.1.3c The security architecture description shall describe how the TSF initialisation
process is secure.
ADV_ARC.1.4c The security architecture description shall demonstrate that the TSF protects
itself from tampering.
ADV_ARC.1.5c The security architecture description shall demonstrate that the TSF prevents
bypass of the SFR-enforcing functionality.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (29) -
ADV_ARC.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.1.2 Complete functional specification (ADV_FSP.4)
ADV_FSP.4.1d The developer shall provide a functional specification.
ADV_FSP.4.2d The developer shall provide a tracing from the functional specification to the
SFRs.
ADV_FSP.4.1c The functional specification shall completely represent the TSF.
ADV_FSP.4.2c The functional specification shall describe the purpose and method of use for all
TSFI.
ADV_FSP.4.3c The functional specification shall identify and describe all parameters associated
with each TSFI.
ADV_FSP.4.4c The functional specification shall describe all actions associated with each TSFI.
ADV_FSP.4.5c The functional specification shall describe all direct error messages that may
result from security enforcing effects and exceptions associated with an
invocation of each TSFI.
ADV_FSP.4.6c The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
specification.
ADV_FSP.4.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
ADV_FSP.4.2e The evaluator shall determine that the functional specification is an accurate and
complete instantiation of the SFRs.
5.3.1.3 Implementation representation of the TSF (ADV_IMP.1)
ADV_IMP.1.1d The developer shall make available the implementation representation for the
entire TSF.
ADV_IMP.1.2d The developer shall provide a mapping between the TOE design description and
the sample of the implementation representation.
ADV_IMP.1.1c The implementation representation shall define the TSF to a level of detail such
that the TSF can be generated without further design decisions.
ADV_IMP.1.2c The implementation representation shall be in the form used by the development
personnel.
ADV_IMP.1.3c The mapping between the TOE design description and the sample of the
implementation representation shall demonstrate their correspondence.
ADV_IMP.1.1e The evaluator shall confirm that, for the selected sample of the implementation
representation, the information provided meets all requirements for content and
presentation of evidence.
5.3.1.4 Basic modular design (ADV_TDS.3)
ADV_TDS.3.1d The developer shall provide the design of the TOE.
ADV_TDS.3.2d The developer shall provide a mapping from the TSFI of the functional
specification to the lowest level of decomposition available in the TOE design.
ADV_TDS.3.1c The design shall describe the structure of the TOE in terms of subsystems.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (30) -
ADV_TDS.3.2c The design shall describe the TSF in terms of modules.
ADV_TDS.3.3c The design shall identify all subsystems of the TSF.
ADV_TDS.3.4c The design shall provide a description of each subsystem of the TSF.
ADV_TDS.3.5c The design shall provide a description of the interactions among all subsystems
of the TSF.
ADV_TDS.3.6c The design shall provide a mapping from the subsystems of the TSF to the
modules of the TSF.
ADV_TDS.3.7c The design shall describe each SFR-enforcing module in terms of its purpose.
ADV_TDS.3.8c The design shall describe each SFR-enforcing module in terms of its SFR-related
interfaces, return values from those interfaces, and called interfaces to other
modules.
ADV_TDS.3.9c The design shall describe each SFR-supporting or SFR-non-interfering module in
terms of its purpose and interaction with other modules.
ADV_TDS.3.10c The mapping shall demonstrate that all behaviour described in the TOE design is
mapped to the TSFIs that invoke it.
ADV_TDS.3.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
ADV_TDS.3.2e The evaluator shall determine that the design is an accurate and complete
instantiation of all security functional requirements.
5.3.2 Guidance documents (AGD)
5.3.2.1 Operational user guidance (AGD_OPE.1)
AGD_OPE.1.1d The developer shall provide operational user guidance.
AGD_OPE.1.1c The operational user guidance shall describe, for each user role, the user-
accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
AGD_OPE.1.2c The operational user guidance shall describe, for each user role, how to use the
available interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3c The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.
AGD_OPE.1.4c The operational user guidance shall, for each user role, clearly present each type
of security-relevant event relative to the user-accessible functions that need to be
performed, including changing the security characteristics of entities under the
control of the TSF.
AGD_OPE.1.5c The operational user guidance shall identify all possible modes of operation of
the TOE (including operation following failure or operational error), their
consequences and implications for maintaining secure operation.
AGD_OPE.1.6c The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfil the security objectives for the
operational environment as described in the ST.
AGD_OPE.1.7c The operational user guidance shall be clear and reasonable.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (31) -
AGD_OPE.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.2.2 Preparative procedures (AGD_PRE.1)
AGD_PRE.1.1d The developer shall provide the TOE including its preparative procedures.
AGD_PRE.1.1c The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's delivery
procedures.
AGD_PRE.1.2c The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the operational
environment in accordance with the security objectives for the operational
environment as described in the ST.
AGD_PRE.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
AGD_PRE.1.2e The evaluator shall apply the preparative procedures to confirm that the TOE can
be prepared securely for operation.
5.3.3 Life-cycle support (ALC)
5.3.3.1 Production support, acceptance procedures and automation (ALC_CMC.4)
ALC_CMC.4.1d The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.4.2d The developer shall provide the CM documentation.
ALC_CMC.4.1c The TOE shall be labelled with its unique reference.
ALC_CMC.4.2c The CM documentation shall describe the method used to uniquely identify the
configuration items.
ALC_CMC.4.3c The CM system shall uniquely identify all configuration items.
ALC_CMC.4.4c The CM system shall provide automated measures such that only authorised
changes are made to the configuration items.
ALC_CMC.4.5c The CM system shall support the production of the TOE by automated means.
ALC_CMC.4.6c The CM documentation shall include a CM plan.
ALC_CMC.4.7c The CM plan shall describe how the CM system is used for the development of
the TOE.
ALC_CMC.4.8c The CM plan shall describe the procedures used to accept modified or newly
created configuration items as part of the TOE.
ALC_CMC.4.9c The evidence shall demonstrate that all configuration items are being maintained
under the CM system.
ALC_CMC.4.10c The evidence shall demonstrate that the CM system is being operated in
accordance with the CM plan.
ALC_CMC.4.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.3.2 Problem tracking CM coverage (ALC_CMS.4)
ALC_CMS.4.1d The developer shall provide a configuration list for the TOE.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (32) -
ALC_CMS.4.1c The configuration list shall include the following: the TOE itself; the evaluation
evidence required by the SARs; the parts that comprise the TOE; the
implementation representation; and security flaw reports and resolution status.
ALC_CMS.4.2c The configuration list shall uniquely identify the configuration items.
ALC_CMS.4.3c For each TSF relevant configuration item, the configuration list shall indicate the
developer of the item.
ALC_CMS.4.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.3.3 Delivery procedures (ALC_DEL.1)
ALC_DEL.1.1d The developer shall document procedures for delivery of the TOE or parts of it to
the consumer.
ALC_DEL.1.2d The developer shall use the delivery procedures.
ALC_DEL.1.1c The delivery documentation shall describe all procedures that are necessary to
maintain security when distributing versions of the TOE to the consumer.
ALC_DEL.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.3.4 Identification of security measures (ALC_DVS.1)
ALC_DVS.1.1d The developer shall produce development security documentation.
ALC_DVS.1.1c The development security documentation shall describe all the physical,
procedural, personnel, and other security measures that are necessary to protect
the confidentiality and integrity of the TOE design and implementation in its
development environment.
ALC_DVS.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
ALC_DVS.1.2e The evaluator shall confirm that the security measures are being applied.
5.3.3.5 Systematic flaw remediation (ALC_FLR.3)
ALC_FLR.3.1d The developer shall document flaw remediation procedures addressed to TOE
developers.
ALC_FLR.3.2d The developer shall establish a procedure for accepting and acting upon all
reports of security flaws and requests for corrections to those flaws.
ALC_FLR.3.3d The developer shall provide flaw remediation guidance addressed to TOE users.
ALC_FLR.3.1c The flaw remediation procedures documentation shall describe the procedures
used to track all reported security flaws in each release of the TOE.
ALC_FLR.3.2c The flaw remediation procedures shall require that a description of the nature
and effect of each security flaw be provided, as well as the status of finding a
correction to that flaw.
ALC_FLR.3.3c The flaw remediation procedures shall require that corrective actions be identified
for each of the security flaws.
ALC_FLR.3.4c The flaw remediation procedures documentation shall describe the methods
used to provide flaw information, corrections and guidance on corrective actions
to TOE users.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (33) -
ALC_FLR.3.5c The flaw remediation procedures shall describe a means by which the developer
receives from TOE users reports and enquiries of suspected security flaws in the
TOE.
ALC_FLR.3.6c The flaw remediation procedures shall include a procedure requiring timely
response and the automatic distribution of security flaw reports and the
associated corrections to registered users who might be affected by the security
flaw.
ALC_FLR.3.7c The procedures for processing reported security flaws shall ensure that any
reported flaws are remediated and the remediation procedures issued to TOE
users.
ALC_FLR.3.8c The procedures for processing reported security flaws shall provide safeguards
that any corrections to these security flaws do not introduce any new flaws.
ALC_FLR.3.9c The flaw remediation guidance shall describe a means by which TOE users
report to the developer any suspected security flaws in the TOE.
ALC_FLR.3.10c The flaw remediation guidance shall describe a means by which TOE users may
register with the developer, to be eligible to receive security flaw reports and
corrections.
ALC_FLR.3.11c The flaw remediation guidance shall identify the specific points of contact for all
reports and enquiries about security issues involving the TOE.
ALC_FLR.3.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.3.6 Developer defined life-cycle model (ALC_LCD.1)
ALC_LCD.1.1d The developer shall establish a life-cycle model to be used in the development
and maintenance of the TOE.
ALC_LCD.1.2d The developer shall provide life-cycle definition documentation.
ALC_LCD.1.1c The life-cycle definition documentation shall describe the model used to develop
and maintain the TOE.
ALC_LCD.1.2c The life-cycle model shall provide for the necessary control over the development
and maintenance of the TOE.
ALC_LCD.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.3.7 Well-defined development tools (ALC_TAT.1)
ALC_TAT.1.1d The developer shall identify each development tool being used for the TOE.
ALC_TAT.1.2d The developer shall document the selected implementation-dependent options of
each development tool.
ALC_TAT.1.1c Each development tool used for implementation shall be well-defined.
ALC_TAT.1.2c The documentation of each development tool shall unambiguously define the
meaning of all statements as well as all conventions and directives used in the
implementation.
ALC_TAT.1.3c The documentation of each development tool shall unambiguously define the
meaning of all implementation-dependent options.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (34) -
ALC_TAT.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.4 Tests (ATE)
5.3.4.1 Analysis of coverage (ATE_COV.2)
ATE_COV.2.1d The developer shall provide an analysis of the test coverage.
ATE_COV.2.1c The analysis of the test coverage shall demonstrate the correspondence
between the tests in the test documentation and the TSFIs in the functional
specification.
ATE_COV.2.2c The analysis of the test coverage shall demonstrate that all TSFIs in the
functional specification have been tested.
ATE_COV.2.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.4.2 Testing: security enforcing modules (ATE_DPT.2)
ATE_DPT.2.1d The developer shall provide the analysis of the depth of testing.
ATE_DPT.2.1c The analysis of the depth of testing shall demonstrate the correspondence
between the tests in the test documentation and the TSF subsystems and
modules in the TOE design.
ATE_DPT.2.2c The analysis of the depth of testing shall demonstrate that all TSF subsystems in
the TOE design have been tested.
ATE_DPT.2.3c The analysis of the depth of testing shall demonstrate that the SFR-enforcing
modules in the TOE design have been tested.
ATE_DPT.2.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.4.3 Functional testing (ATE_FUN.1)
ATE_FUN.1.1d The developer shall test the TSF and document the results.
ATE_FUN.1.2d The developer shall provide test documentation.
ATE_FUN.1.1c The test documentation shall consist of test plans, expected test results and
actual test results.
ATE_FUN.1.2c The test plans shall identify the tests to be performed and describe the scenarios
for performing each test.
ATE_FUN.1.3c The expected test results shall show the anticipated outputs from a successful
execution of the tests.
ATE_FUN.1.4c The actual test results shall be consistent with the expected test results.
ATE_FUN.1.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
5.3.4.4 Independent testing - sample (ATE_IND.2)
ATE_IND.2.1d The developer shall provide the TOE for testing.
ATE_IND.2.1c The TOE shall be suitable for testing.
© Mobile Armor, Inc. 2010 Version 1.72 IT Security Requirements
- (35) -
ATE_IND.2.2c The developer shall provide an equivalent set of resources to those that were
used in the developer's functional testing of the TSF.
ATE_IND.2.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
ATE_IND.2.2e The evaluator shall execute a sample of tests in the test documentation to verify
the developer test results.
ATE_IND.2.3e The evaluator shall test a subset of the TSF interfaces to confirm that the TSF
operates as specified.
5.3.5 Vulnerability assessment (AVA)
5.3.5.1 Focused vulnerability analysis (AVA_VAN.3)
AVA_VAN.3.1d The developer shall provide the TOE for testing.
AVA_VAN.3.1c The TOE shall be suitable for testing.
AVA_VAN.3.1e The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
AVA_VAN.3.2e The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the TOE.
AVA_VAN.3.3e The evaluator shall perform an independent vulnerability analysis of the TOE
using the guidance documentation, functional specification, TOE design, security
architecture description and implementation representation to identify potential
vulnerabilities in the TOE.
AVA_VAN.3.4e The evaluator shall conduct penetration testing, based on the identified potential
vulnerabilities, to determine that the TOE is resistant to attacks performed by an
attacker possessing Enhanced-Basic attack potential.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (36) -
6. TOE Summary Specification
This chapter describes the security functions and associated assurance measures.
6.1 Security audit
The TOE generates audit records for start-up and shutdown of the TOE components which generate
audit records, as well as the minimal level of audit as defined in the Common Criteria. Audit records
are generated on DataArmor and the PolicyServer. All audit events generated by the TOE use the
TOE user accounts when associating user identity to the event. While the OS user and the TOE user
may be the same (such as when SSO is enabled on the client), the username used to login to the
TOE will be associated with all generated events, and not any username that may exist in the
protected OS.
The auditable events recorded by DataArmor include:
 Start-up and shutdown of DataArmor (pre-OS and inside the OS)
 Audit log size max is reached
 Success or failure of cryptographic operations;
 Successful requests to perform an operation on an object covered by the SFP;
o Use of the management functions, specifically, manage user security attributes
through the recovery console
 Identification and authentication attempts including threshold attempts exceeded;
 Rejection of unacceptable password changes;
 Failure to contact or successfully communicate with the PolicyServer.
The auditable events recorded by PolicyServer include:
 Start-up and shutdown of the PolicyServer
 Successful requests to perform an operation on an object covered by the SFP;
o Use of the management functions, specifically, manage user security attributes
through the PolicyServer Management Console
 Use of the management functions, specifically,
o manage user and group security attributes,
o manage policy settings, and
o manage authentication server policy settings;
 Modifications to the group of users that are part of a role;
 Identification and authentication attempts including threshold attempts exceeded;
 Rejection of unacceptable password changes;
DataArmor generates all audit events associated with its own users (e.g., attempts to login and
decrypt protected data) on the client. Those audit records are created (using the specific event type,
time/date from the local operating system (and by extension the device BIOS clock), the user identity,
and success or failure of the event), stored in the DADB, and then sent in encrypted SOAP messages
(see section 6.6) to the PolicyServer, which then records the logs into the PolicyServer log database.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (37) -
While these records are stored on the client, the client is able to prevent modifications to the log by
the same protections the client uses to protect itself (see section 6.6). The client is able to store up to
4000 events in local storage without connecting to the PolicyServer before events will be lost. The
client audit store uses a first-in-first-out technique, such that the oldest events will be the ones lost
when client audit storage becomes full.
The PolicyServer generates all audit events associated with security management of the TOE as well
as authentication attempts. At a minimum, each record identifies the event, time/date from the local
operating system, the user identity, and success or failure of the event.
The PolicyServer component of the TOE provides a management console that can be used to read
from the PolicyServer log database used to store audit records and to generate reports. The
management console requires identification and authentication of the administrators, restricting the
number of users able to review the audit log. The PolicyServer management console provides these
administrators with the ability to fully search the collected audit records. The TOE also provides
several built-in reports which can be used to gather information about the health of the system. It is
possible to export query results and reports for use outside the TOE with the support of tools readily
available in the IT Environment.
The DataArmor recovery console also provides a capability to free-form search the audit records that
have not yet been uploaded to the PolicyServer log database. The search will return matching results
from any field (i.e. typing in “xyz” would return any event with “xyz” in it, regardless of the field
containing the match). This interface is only available to Authorized Administrators. On mobile
devices, MD Users are able to read local audit records which have not yet been uploaded to the
PolicyServer log database. These consoles are only able to show the records generated by the local
device, and once the device has connected to the PolicyServer, the logs will be uploaded to the
PolicyServer log database and removed from the local device.
While the IT Environment should protect the audit trail from tampering one they have been uploaded
to the PolicyServer, a mechanism is provided for detecting if changes have occurred in the audit
records once they have been stored. As each record is recorded in the PolicyServer log database
(whether uploaded from DataArmor or directly entered from the PolicyServer) an HMAC value is
generated and stored in the log database. This value also contains entry information, allowing the
sequence of events entered into the log database to be determined. Enterprise Administrators can
define a scheduled process be set to run to verify the records and detect potential changes to the log
database. This process, managed by the TOE (and not reliant on OS task scheduling) will verify the
HMAC values to check for the integrity of the audit records as well as completeness (that none have
been deleted or false entries added).
DataArmor and PolicyServer are able to report on potential audit violations based on reviews of the
audit records. DataArmor reports potential violations to the next user to successfully authenticate,
ensuring a local user knows that potential violations have been noted.
On the PolicyServer, Enterprise Administrators are able to schedule and run alerts on all uploaded
logs, and inform administrators via email when potential violation events have been reported. The
PolicyServer maintains a scheduling system for running the alerts. The Policy server scans the log
every 60 seconds to trigger the scheduled alerts. Each scheduled alert can have the email addresses
set uniquely for specific administrators to allow customized notifications. Any time an alert generates
results (i.e. does not return an empty query from the log database) a PDF is generated and sent in an
email to the specified addresses.
These alerts are used to track potential violations on the client and server. In addition the
PolicyServer monitors the integrity of all the policy configuration values in the policy database and
generates audit events for each value that fails the integrity check.
The following potential violations are reported by DataArmor after the next successful authentication:
 Any failed login attempts on a mobile device client
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (38) -
 Multiple failed login attempts (more than two consecutive attempts) on a PC client
The following potential violations are reported by PolicyServer by email from a scheduled alert
notification:
 Multiple failed login attempts on DataArmor that reach the threshold defined by the
administrator for the alert
 Policy value tampering events identified through invalid policy HMAC values in the
PolicyServer policy database
 Log tampering events identified through invalid policy HMAC values in the PolicyServer log
database
The Security audit function is designed to satisfy the following security functional requirements:
 FAU_ARP.1ab and FAU_SAA.1ab: The TOE detects several potential security violations
and provides reports about them. On DataArmor, the violation is reported to the next
authenticated user, while on the PolicyServer it is reported to the administrator by email.
 FAU_GEN.1: The TOE generates audit records for the minimum level of audit. The operating
system (and by extension, the device BIOS clock) is relied on to provide reliable time stamps
for use in audit records. Audit records are stored in a database in the IT environment. The
operating system and database server in the IT environment is relied on to protect audit data
from tampering.
 FAU_GEN.2: The TOE generates audit records that include the identity of the user that
caused the event.
 FAU_SAR.1: The TOE provides administrative interfaces that can be used to read generated
audit events..
 FAU_SAR.2: The TOE provides restricted access to the audit records by requiring the user to
be an assigned to a role which can read the audit records.
 FAU_SAR.3ab: The TOE provides the ability to search the audit records which have been
uploaded to the PolicyServer log database as well as records on clients which have not yet
been uploaded.
 FAU_STG.1a: The TOE provides the ability to prevent modifications to the audit trail while it
is stored on the clients.
 FAU_STG.1b: The TOE provides the ability to detect modifications to the audit trail while it is
stored in the log database.
 FAU_STG.3: The TOE will protect up to 4000 audit records on the client before overwriting
the oldest record in the audit store.
6.2 Cryptographic support
Both the DataArmor and PolicyServer applications use instances of the same FIPS-evaluated Mobile
Armor cryptomodules to perform all cryptographic operations. The cryptomodules only operate in
FIPS mode.
DataArmor comes with two versions of the Mobile Armor Cryptographic Module, v3.0 and v3.5.
Version 3.5 is built from 3.0 with no changes to the 3.0 core code, but adds enhancements to support
FIPS 140-2 Level 2 validation (version 3.0 supports only FIPS 140-2 Level 1 validation). This allows
the DataArmor client to operate in the highest FIPS 140-2 Level available on the installed operating
system. The PolicyServer only uses v3.5 of the module. The following tables list the algorithm and
module certificates for these modules.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (39) -
Algorithm v3.0 Certificate v3.5 Certificate
AES 820 920
Triple-DES (3DES) 692 740
SHS (all SHA) 818 907
ANSI X9.31 PRNG 472 528
HMAC 453 514
Table 4 - Cryptographic Module Algorithm Certificates
Module Version Certificate
v3.0 1134
v3.5 1123
Table 5 - Cryptographic Module Certificates
Note that while Triple-DES (3DES) is listed as a validated algorithm, it is not claimed directly in the
TOE. This algorithm is included indirectly as the basis for the ANSI X9.31 PRNG.
When the PolicyServer is installed, its cryptomodule is used to generate data that is used to create a
256-bit company-unique AES encryption key. The data necessary to generate this key is stored in the
PolicyServer policy database and is used for encrypting DataArmor Disk Encryption Keys (DEKs) for
escrow purposes to support any necessary DataArmor recovery operations. The key itself is not
stored on disk.
The PolicyServer uses its cryptomodule to create 256-bit DEKs for each applicable DataArmor
instance for use with AES.
Each DataArmor instance includes its own cryptomodule and, when installed, receives its DEK from
the associated PolicyServer. The keys are encrypted using a 256-bit key (derived from a hash of the
current user‟s identity and authentication data) with AES and stored on the protected device. After the
software installation is complete, the persistent storage is encrypted using the AES DEK (for usability
this is usually done “on the fly” while the user is using the OS).
Once the DataArmor client is installed, each time the device is started the DataArmor application will
start and present the user a login dialog. The user must identify and authenticate to DataArmor. The
user identity and authentication data is hashed to create a 256-bit AES key. This key is used to
decrypt the DEK and if the key cannot be decrypted the authentication will fail. Once the DEK is
decrypted, the persistent storage can be decrypted using the DEK and the operating system can start
and the user can subsequently access the device contents via the operating system where the DEK
is maintained in the memory of the device driver in the operating system kernel. The DEK is protected
in memory by the secure execution environment provided by the OS. All read and write operations to
persistent storage are then automatically decrypted and encrypted using the DEK.
Furthermore, once the DataArmor product is installed, two-way communications between the
PolicyServer and DataArmor instance are implemented using SOAP messages sent over the HTTP
protocol. The DataArmor client uses its cryptomodule to generate unique 256-bit AES Communication
Encryption Keys (CEK) for each client session for the purpose of protecting communication between
the PolicyServer and the DataArmor instance. Unlike the DEK, a new CEK is generated each time a
client connects to the PolicyServer, with a unique CEK for each client connected at the time. Once
the communications channel between the client and server is closed, the CEK is securely deleted
from memory on both sides and not used again. The Body of each SOAP message is encrypted
using the 256-bit CEK with AES. One-way communications from the PolicyServer to mobile device
clients is encrypted on the server using the appropriate device‟s DEK.
The Cryptographic support function is designed to satisfy the following security functional
requirements:
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (40) -
 FCS_CKM.1: The TOE generates keys for encryption and decryption of data using a FIPS-
validated RNG.
 FCS_CKM.3: The TOE escrows the generated DEK keys on the server in accordance with
FIPS 140-2.
 FCS_CKM.4: The TOE destroys keys stored temporarily in filter drivers by overwriting them
in memory. The TOE will also destroy the keys from memory as well as from the disk for
users when the user is deleted from the device.
 FCS_COP.1abc: The TOE provides its own FIPS-evaluated cryptographic module which
performs symmetric encryption and decryption operations using AES. Additionally algorithms
HMAC, RNG, and SHS are provided for additional security related to those functions.
6.3 User data protection
The TOE implements an access control policy called the Data Access Control Policy. The TOE object
subject to this policy is all data stored on the persistent storage of the device where the TOE is
installed. Access control decisions to determine access to persistent storage are based on user
identities and authentication credentials which are used to decrypt the symmetric keys used to
encrypt the contents of the device‟s persistent storage. Simply, if the user identity and authentication
credentials can be successfully used to decrypt the symmetric key that decrypts the persistent
storage, the user may access the encrypted data on the device.
The User data protection function is designed to satisfy the following security functional requirements:
 FDP_ACC.2 and FDP_ACF.1: The TOE provides the ability to restrict access to data stored
on the device‟s persistent storage. All users are subject to the Data Access Control Policy for
all available operations devices by a combination of authentication and encryption.
6.4 Identification and authentication
The TOE defines the following user security attributes:
 User identity (username)
 Authentication data
 Group membership
 Role
 Disk encryption keys (DEKs).
These attributes are stored, as appropriate, in different parts of the TOE as follows:
 On DataArmor:
o User identity (username)
o Group membership
o Role
o User‟s encrypted Disk Encryption Keys (DEKs)
 On the PolicyServer
o User identity (username)
o Authentication data as related to PolicyServer administration roles
o Group membership
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (41) -
o Role
To access the encrypted persistent storage, the TOE requires that users use DataArmor login dialogs
to authenticate. DataArmor authentication data (such as a fixed password) for any user, regardless of
role, is not stored directly in the DADB. DataArmor user authentication credentials (such as the
username and a fixed password) are hashed to generate a key which is used to encrypt (and on
successful authentication, decrypt) the DEK. The device encryption key (DEK) is stored in an
encrypted form in the device password authentication file (PAF). The DEK is base64 encoded AES-
256 encrypted data. The key to the DEK is a secure hash (SHA-256) of the user‟s password and
username or in the case of certificate based authentication (PKI) it is the DEK encrypted via the
public key of the user‟s authentication certificate and stored as a base64 encoded string.This
encrypted form of the DEK is what is stored in the DADB with the user‟s other information. Each user
authorized to access the client will have a unique copy of the DEK encrypted with their specific user
credentials.
All authentication attempts are attempts to decrypt the DEK associated with the user identity specified
in the entered authentication credentials. Successful authentication in DataArmor will generate the
proper hash value (from the authentication credentials) to decrypt the DEK stored in the DADB. The
exception to this is when smart cards are used for authentication where a private key from the smart
card is used to encrypt the DEK. Successful smart card authentication unlocks the smart card private
key which then decrypts the encrypted DEK. To ensure the decrypted DEK is correct, it is tested by
decrypting a known value which has been encrypted with the DEK.
DataArmor always attempts to authenticate via the PolicyServer (using encrypted SOAP messages,
see section 6.6) to have the latest data in the DADB. In this sense, the DADB authentication data
stored on the client could be considered a secondary copy to be used when the primary copy (the
PolicyServer copy) is not available. By contacting the PolicyServer during authentication it is possible
to enforce conditions such as user locking or removal. If the user is configured to use an external
authentication server, the PolicyServer will act as a proxy for the authentication to the external server
and then pass that information back to the DADB, ensuring the user must authenticate with the
proper credentials. When the PolicyServer is not available, such as when DataArmor is offline (i.e.
using a laptop on an airplane), the current data in the DADB, the secondary copy, will be used for
authentication instead. When a user‟s credentials are changed, the DEK will be re-encrypted with the
new credentials.
DataArmor supports multiple users on a protected device. In the DataArmor PC, all users in a group
can login to any PC device in the same group. This list would include all accounts with the User role,
all Group Administrators and Group Authenticators in the group, as well as all Enterprise
Administrators and Enterprise Authenticators. On a mobile device, only a single account of the User
role is supported (as the device itself is designed for only a single user), though all the Authenticator
and Administrator accounts would be able to login to the device as on a PC.
Authorized Administrators who authenticate to the DataArmor PC client will be able to access the
recovery console after successful authentication by clicking the Access Recovery Console button
which will appear after the login. This button is shown based on the authenticating user‟s role. If the
user does not click the button, the system will continue to boot into the OS normally.
The TOE requires administrators to use PolicyServer management console logon interfaces to
identify and authenticate themselves. The PolicyServer authenticates administrators directly using
credentials stored in the policy database. The PolicyServer will enforce the authentication decision so
that only authentic administrators can access corresponding security functions. Users logging into the
PolicyServer management console can be locked out based on failed attempt settings. Once locked
out, the account must be unlocked by an Authorized Administrator.
In all login attempts, the user password credentials are obscured from display on the screen.
Before users can read from and write to the contents of persistent storage, users must first log into
DataArmor login interfaces. When a user attempts to start the OS, DataArmor prompts the user using
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (42) -
its dialogs before the OS has started for credentials such as username and password for the
authentication as summarized above.
DataArmor authentication is designed to be the first thing that a user has access to when a protected
device is turned on. Under most circumstances no access is granted to any functionality of the device
(since the OS is protected by DataArmor) until the user has successfully authenticated. There is a
limited set of functions which can be accessed without authentication, and these are further
dependent on the type of device protected. DataArmor provides the ability to view information
specifically set by policy (and hence not required) related to Support Info (generally used to provide
information about how to contact technical support), and a field called “If Found” which can provide
information about where to return the device if it is lost. On PCs, a user can also manually download
policy updates from the PolicyServer (this is generally only used when directed by a technical support
person), and a choice to reset their password after a successful login.
On a mobile device, the primary exception (in addition to those noted above) granted is to allow
incoming phone calls to be answered and to make outgoing calls (though not with the normal call
interface) before an authentication sequence has been completed. No other access is allowed, such
as to Contacts data that may be stored on the phone, without successful authentication. While
incoming calls can always be answered, the ability to make outgoing calls is controlled by policy (so it
can be disabled). If the mobile device does not have cellular phone hardware, this is not supported
(for example, a VOIP application on a non-cellular device would not be allowed to be used).
To increase user acceptance, it is possible to configure DataArmor to automatically authenticate to
the installed OS using the TOE authentication credentials entered into the DataArmor login. This
Single Sign-on function is an optional extension of the Fixed Password Mechanism where the
PolicyServer is configured to act as a proxy to Active Directory to enable the usage of Active
Directory authentication credentials at the DataArmor login. When this is enabled, the effect is to
maintain a single login for the user to access the installed OS, with the credentials entered into the
TOE are automatically entered into the OS after successful TOE authentication, instead of requiring
two separate logins, one to the TOE (which is always required) and a second one into the installed
OS.
On the PolicyServer, no access to any management functions is allowed until after successful
authentication via the PolicyServer management console.
When configured, authentication servers in the IT environment are relied on to maintain user
identities and authentication data for DataArmor users. The TOE maintains user identities as well as
information that identifies the authentication mechanism that the user must use, and TOE-defined
group information in the DADB. DataArmor provides many different authentication mechanisms, from
strong fixed passwords and PINs to smart cards, and Remote Authentication logins for situations
where normal authentication is not possible (such as a forgotten password or a lost smart card).
The Remote Authentication Mechanism is designed as a one-time use method of authentication
requiring the verbal assistance of an Authorized Administrator. When a user initiates this mechanism
it generates a unique X9.9-based challenge and displays it to the user. This is read to the Authorized
Administrator and input into the PolicyServer management console where a response is generated.
This is read back to the user and entered into the login. This process will unlock the DEK and force
the user to immediately enter new authentication data to re-encrypt the DEK for the user. A new X9.9
key is then generated to re-encrypt the DEK for the next use, preventing the re-use of the same
challenge and response.
In addition to configuring the authentication mechanisms available for a user, the administrator can
configure the action to be taken after a specified number of failed login attempts. DataArmor supports
locking of the user account (Remote Authentication can be used to unlock the account), setting a time
delay before more attempts can be made and device erasure, which securely deletes all keys on the
client, effectively deleting all the device data.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (43) -
The User role does not have any administrative authority in the TOE, but is assigned access to
DataArmor-protected persistent storage through group membership. The TOE uses groups as a way
to apply configuration settings (for example the authentication mechanism that must be used) to more
than one user at a time, both to the PolicyServer and to DataArmor. Permissions inside the
management console are determined by a combination of assigned role and group membership.
Roles are described in the Security management description below. Similarly this combination is used
to determine access to DataArmor clients, and on the client itself, possible access to the recovery
console.
DataArmor associates a TOE user with all DataArmor processes that are started after authentication.
For example, the cryptographic module is started as a process for that TOE user, and all actions that
are taken are specifically tied to that TOE user. PolicyServer associates a TOE user with all actions
taken inside the PolicyServer management console. This ensures that all audit records are properly
associated with the TOE user responsible for the process. Note that the TOE user identity is not
necessarily the same as the OS user identity, though when SSO is enabled, this is always the case.
The TOE administrators configure an inactivity policy for the management console which will cause
the administration console to become closed after a specified period of inactivity. When this happens,
the user must authenticate to the TOE by restarting the management console before regaining
access.
The Identification and authentication function is designed to satisfy the following security functional
requirements:
 FIA_AFL.1, FIA_ATD.1 and FIA_UAU.5: The TOE maintains security attributes belonging to
individual users and administrators including user identity and authentication mechanism
identification information to accomplish this. The TOE also maintains a policy to control the
actions to be taken if a number of unsuccessful login attempts occur in succession.
 FIA_UAU.1 and FIA_UID.1: The TOE authenticates all users prior to any access of
DataArmor protected persistent storage except a specified list of functions.
 FIA_UAU.2 and FIA_UID.2: The TOE authenticates all users prior to access of the
PolicyServer management console.
 FIA_UAU.6: The TOE provides a re-authentication mechanism to ensure that inactive
administration consoles are closed to prevent unauthorized access.
 FIA_UAU.7: The TOE prevents the display of the password portion of a user‟s credentials on
the screen.
6.5 Security management
The TOE defines the following roles:
 In PolicyServer
o Enterprise Administrator
o Group Administrator
o Enterprise Authenticator
o Group Authenticator
o User
 In the DAOS recovery console
o Administrator
o Authenticator
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (44) -
o User
 On Windows Mobile devices
o MD User
On the PolicyServer, a user that possesses the Enterprise Administrator role can access all
PolicyServer management interfaces. A user that possess the Group Administrator role can manage
user information (including roles, groups, and permissions) for one or more user groups that the user
possessing this role has been assigned to. Similar access is given to Enterprise and Group
Authenticators, respectively, though an Authenticator is not allowed to access the policies.
The specific management functions available to an Authenticator through the PolicyServer
Management console are (subject to their position in the hierarchy):
 Review and search the audit trail
 Modify authentication data by forcing a password change of Users with a onetime password
 Unlock DataArmor user accounts with Remote Authentication
Through the PolicyServer Management console, an Authenticator explicitly cannot modify the role of
another user (preventing improper elevation of authority).
Permission information maintained by the PolicyServer identifies which groups a user that possesses
the Group Administrator role has been assigned to. A user that possesses the User role is simply a
user of the DataArmor application, i.e. a user who uses DataArmor, and provides no access to login
to the PolicyServer.
In the DAOS recovery console, roles are translated specifically to the local system meaning any
Authorized Administrator will have access according to the following:
 Enterprise or Group Administrator -> Administrator
 Enterprise or Group Authenticator -> Authenticator
 User -> User
No distinction is made, on the local system, about Enterprise or Group since the management
capabilities are only on the local system.
There is a policy that determines the user access to the DAOS recovery console. This can be set to
yes or no (Default is No). The default policy does not allow the user to access the recovery console
and this cannot be changed by user. An administrator or Authenticator can perform the same
functions once in the recovery console.
From inside the recovery console no policy configuration can be performed, only user administration
and audit review.
The specific management functions available to an Authorized Administrator (either Administrator or
Authenticator) through the DataArmor recovery console are:
 Search the locally stored audit trail
 Manage users (including all aspects of managing users, including adding, modifying and
deleting)
 Modify authentication data
 Set explicit password expiration date (by calendar date) for fixed passwords or PINs
This is primarily used in situations where the device is offline and not connecting to the PolicyServer.
Any user changes made in the recovery console will be overwritten by the PolicyServer user
configuration for the device automatically, the next time the device connects to the server.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (45) -
Users assigned to a mobile device are given the MD User role automatically. In the PolicyServer
management console these are both shown as Users, but the authority of a User on the mobile
device is different that a User on a PC. On the mobile device, the MD User is able to review the audit
trail of events generated on the mobile device but not yet uploaded to the PolicyServer log database.
Authority is assigned to the user account (a user account must exist to be given authority) within the
group (or Enterprise) where the user needs to have the authority. When this user logs into the
management console, they will only see what which they have access to from the authority granted.
When a user account is assigned the Administrator or Authenticator role, the account is also assigned
a separate, administrator credentials (fixed password or smart card). Without both the role and
administrator credentials, it is not possible to login to the management console.
The TOE provides administrator console interfaces to perform the following:
 search the audit trail
 management of Enterprise Alerts
 manage user security attributes
 manage device policy settings and security attributes
 manage authentication server policy settings
The initialization of encryption keys (DEKs) is handled during the installation of a new client device. A
new DEK is created any time a new device is installed (which requires a user with a proper login),
and that DEK is assigned specifically to that device. The user who logged in to install the device must
be a member of a Group; a user who only exists in the Enterprise but not any group cannot
successfully install DataArmor on any device. The initialized key is associated with the user who
logged in (though the DEK is really associated with the device, not the user). The act of creating
Groups and assigning users provides the ability to initialize and associate DEKs to users. DEKs can
be deleted for all users or a specific user. The DEK associated with an individual user on a device
can be deleted specifically by removing the user from the device‟s Group, which will revoke the user‟s
access on the device the next time the device is connected to the PolicyServer.
The TOE provides a password expiration policy for accounts logging into the DataArmor clients with
the User role. As a policy set in the PolicyServer Management console by Policy Administrators, it is
possible to set a period of days before a password will expire. From the DataArmor Recovery
Console it is possible for Authorized Administrators to set an explicit expiration date since no policy
settings are available through that interface. When setting an explicit date, once that date has been
reached and the password changed, the next expiration time will be determined by the policy value.
Authorized Administrators can force a password change by using the “Assign One Time Password”
function. This allows the Authorized Administrator to set a new password for the next login (the client
must be able to connect to the PolicyServer for this to take effect) which will automatically force the
user to choose a new password.
There is an application-based administrative interface to the PolicyServer providing a GUI-based
interface. TOE settings are configured using sets of rules that are grouped into policies. For example,
“Password Policies” policy settings include “AllowedAuthenticationMethods” which specify which
authentication methods are available to a user for login.
The Security management function is designed to satisfy the following security functional
requirements:
 FMT_MSA.1: The ability to manage user security attributes is restricted to Authorized
Administrators.
 FMT_MSA.2 and FMT_MSA.3: By default, all protected devices require authentication and all
content is encrypted and hence protected by default.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (46) -
 FMT_MTD.1a: Authorized Administrators are able to search the audit trail.
 FMT_MTD.1b: Enterprise Administrators are able to manage the alert configuration for
potential violation notifications.
 FMT_MTD.1d: Authorized Administrators are able to access and as appropriate, manage the
encryption keys on the PolicyServer.
 FMT_MTD.1e: Authorized Administrators are able to access and as appropriate, manage
authentication data. Users are able to manage their own authentication data within the
restrictions set by Policy Administrators (FMT_MTF.1f).
 FMT_MTD.1f: Policy Administrators are able to access and as appropriate, manage, the data
on the PolicyServer including authentication policies.
 FMT_MTD.1g and FMT_MTD.2: The TOE provides the ability to determine the results of
successive failed DataArmor login attempts, to lock the user account, erase the device or
specify a time delay before further login attempts and to lock Authorized Administrators who
successively fail to login to the PolicyServer Management console until unlocked by a Policy
Administrator. Control of these settings is limited to Policy Administrators.
 FMT_REV.1: The TOE provides the ability to revoke DataArmor user access to Policy
Administrators through the management console and Authorized Administrators through the
DataArmor recovery console.
 FMT_SAE.1: The ability to manage fixed authentication data for DataArmor User role logins
by requiring it to expire periodically is restricted to Policy Administrators in the PolicyServer
Management Console and Authorized Administrators in the DataArmor Recovery Console.
 FMT_SMF.1: The TOE provides the ability to query audit records, manage Enterprise alerts,
manage user security attributes, and disk policy settings and security attributes, and
authentication server policy settings.
 FMT_MTD.1c and FMT_SMR.1: The TOE provides administrator, authenticator and user
roles. The PolicyServer provides Enterprise Administrators and Authenticators as well as
Group Administrators and Authenticators with separate hierarchical rights. The DAOS
recovery console provides administrators and authenticators with rights to perform
management on the local device. The User role corresponds to users who access TOE-
protected PCs. The MD User role corresponds specifically to users on mobile devices. The
ability to manage user security attributes, including role and group assignments, is restricted
to Policy Administrators in the PolicyServer, and any authenticator or administrator inside the
DAOS recovery console.
6.6 Protection of the TSF
DataArmor components cannot be easily bypassed since during DataArmor installation, the
underlying bootstrap of the particular device is configured to point to the DAOS and then the
persistent storage is encrypted. DataArmor implements a series of tests on itself to ensure it is
functioning properly. The first test is the verification of the kernel signature of the DAOS. The
remaining portion of the DAOS is compressed and the encrypted. The compressed data is validated
with a checksum once it is decrypted using the disk-unique key. After the DAOS is decrypted and
uncompressed, DataArmor login interfaces are subsequently displayed. Inside the OS, the filter
drivers that use the DEK are digitally signed and verified as they are loaded by the OS.
DataArmor contains pre-data access authentication components (DAOS) and filter driver
components. Before users can read from and write to the persistent storage or access the installed
operating system and its functions, users must first log into DataArmor login interfaces. When a user
attempts to start the operating system, DataArmor prompts the user using its dialogs before granting
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (47) -
access to the operating system for credentials such as username and password for the authentication
service that has been configured for use according to administrator configuration. After the DEK has
been decrypted using the authenticated credentials, it is loaded into a filter driver DataArmor
component where it is available to encrypt and decrypt encrypted contents automatically as the user
attempts to write and read information to/from the persistent storage.
DataArmor attempts to contact the PolicyServer on a regular basis. This is done both from the DAOS
as well as the OS component, to provide ongoing and up to date information from the PolicyServer. In
cases where DataArmor is unable to contact the PolicyServer it will continue to function using its last
loaded configuration and policies to maintain the security of the TOE. When communications are re-
established, any updated policies will be downloaded and all logs will be uploaded to the PolicyServer
at that time.
The PolicyServer relies largely on the TOE environment for protection, but has been carefully
designed to restrict access to its own functions in accordance with the TOE security policies by
ensuring that users are authentic and that they are authorized to perform the functions they attempt.
The PolicyServer further ensures that invalid policies cannot be sent to the clients by validating the
HMAC values for all policy values before they are sent to the client. Any invalid value will prevent the
policy update from being sent to the client until the policy has been updated (this will generate a new
HMAC value along with ensuring the current value itself). When invalid policy values are discovered,
a log entry is created specifying the invalid policy. In addition to protecting the policy values, the
server can be scheduled to verify the integrity of the log entries that have been stored on the
PolicyServer (see section 6.1).
There are two types of communications between the DataArmor clients and the PolicyServer: one-
way and two-way. One-way communications are only used on mobile device clients for three specific
commands: sync to the PolicyServer immediately, lock the device immediately, and erase the device
immediately. These commands are sent via SMS or email messages directly to a specific device, and
are initiated based on administrator actions in the PolicyServer. These one-way messages are
encrypted with the device DEK to ensure security and that they can only be read on the appropriate
device.
All two-way communications between the PolicyServer and DataArmor use SOAP messages sent
over HTTP and are always initiated by the client (though as noted above, a command to a mobile
device can force two-way communications to start immediately). DataArmor connects from both the
DAOS (without any dependencies or interactions from the OS) and from the OS component (relying
on the OS to provide access to the network, but nothing else). The Body of each SOAP message is
encrypted using a 256-bit AES CEK that was generated uniquely for each communications
sessionfrom each device. As such, all policy information, audit records, authentication data, etc. that
passes among the TOE components are protected from modification and disclosure and are all
acknowledged by both client and server.Once the session has ended, both the client and server will
securely delete the CEK from memory. The next time the client connects to the server, a new CEK is
generated.
The Protection of the TSF function is designed to satisfy the following security functional
requirements:
 FPT_TST.1: The TOE client ensures that the security is functioning properly when the device
is initialized by running a series of checks on the integrity of the software.
 FPT_FLS.1a: The ability to maintain a secure configuration in the advent of a non-connected
state with the PolicyServer is provided.
 FPT_FLS.1b: The ability to maintain a secure configuration in the advent invalid policy values
are found.
© Mobile Armor, Inc. 2010 Version 1.72 TOE Summary Specification
- (48) -
 FPT_ITT.1: The PolicyServer component encrypts its communication with DataArmor by
encrypting and decrypting SOAP messages sent and received using HTTP and by encrypting
all SMS or email commands sent to mobile devices.
6.7 Resource Utilization
DataArmor attempts to contact the PolicyServer on a regular basis. This is done both from the DAOS
as well as the OS component, to provide ongoing and up to date information from the PolicyServer. In
cases where DataArmor is unable to contact the PolicyServer it will continue to function using its last
loaded configuration and policies to maintain the security of the TOE. When communications are re-
established, any updated policies will be downloaded and all logs will be uploaded to the PolicyServer
at that time.
The Resource Utilization function is designed to satisfy the following security functional requirements:
 FRU_FLT.1: The ability to maintain a secure configuration in the advent of a non-connected
state with the PolicyServer is provided.
6.8 TOE Access
DataArmor provides a login banner that can be configured by Policy Administrators. This banner is
stored in the protected database area and can contain any pertinent information as determined by the
organization about the use of the protected device or console.
The PolicyServer management console provides a login banner that can be configured by Policy
Administrators. This banner can contain any pertinent information as determined by the organization
about the use of the console.
The TOE Access function is designed to satisfy the following security functional requirements:
 FTA_TAB.1: Policy Administrators have the ability to create and manage login banners on
both the DataArmor client and PolicyServer console.
6.9 Trusted Path/Channels
During installation, DataArmor is inserted into the startup sequence of the device, interrupting the
normal startup of the protected device. This is used to establish a trusted path between the TOE and
local users as DataArmor will take control of the device before other services are available.
Authentication at that stage immediately involves TSP enforcing functions and maintains the following
operation in secure manner.
The Trusted Path/Channels function is designed to satisfy the following security functional
requirements:
 FTP_TRP.1: The TOE shall provide control of user‟s session on the client.
© Mobile Armor, Inc. 2010 Version 1.72 Protection Profile Claims
- (49) -
7. Protection Profile Claims
There is no Protection Profile claim in this Security Target.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (50) -
8. Rationale
This section provides the rationale for completeness and consistency of the Security Target. The
rationale addresses the following areas:
 Security Objectives;
 Security Functional Requirements;
 Security Assurance Requirements;
 Requirement Dependencies; and
 TOE Summary Specification.
8.1 Security Objectives Rationale
This section shows that all secure usage assumptions, organizational security policies, and threats
are completely covered by security objectives. In addition, each objective counters or addresses at
least one assumption, organizational security policy, or threat.
8.1.1 Security Objectives Rationale for the TOE and Environment
This section provides evidence demonstrating the coverage of organizational policies and usage
assumptions by the security objectives.
O.ACCESS
O.ADMIN_ROLE
O.ALERT
O.AUDIT_GNEERATION
O.AUDIT_REVIEW
O.CRYPTO_OPS
O.DATA_TRANSFER
O.FAULT_TOLERANCE
O.MANAGE
O.TOE_PROTECTION
O.USER_AUTHENTICATION
OE.AUDIT_PROTECTION
OE.TIME
OE.TOE_PROTECTION
OE.CONFIG
OE.PHYCAL
OE.USER_GUIDANCE
OE.REPORT_ENV
T.ACCOUNTABILITY X X X X X
T.ADMIN_ERROR X X
T.MASQERADE X
T.SUBVERT X
T.TSF_COMPROMISE X X X X
T.UNAUTH_ACCESS X
A.LOCATE X
A.NO_EVIL X
A.NO_EVIL_USER X
A.DEVICE_USE X
A.REPORTS X
Table 6 - Environment to Objective Correspondence
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (51) -
8.1.1.1 T.ACCOUNTABILITY
A user may not be held accountable for their actions.
This Threat is countered by ensuring that:
 O.ALERT: The TOE will provide the capability to alert authorized users of potential security
violations.
 O.AUDIT_GENERATION: The TOE will provide the capability to create records of security
relevant events associated with users.
 OE.AUDIT_PROTECTION: The TOE Environment will provide the capability to protect audit
information on the server portion of the TOE.
 O.AUDIT_REVIEW: The TOE will provide the capability to view audit information.
 OE.TIME: The TOE Environment will provide reliable time stamps for use in audit records so
that audit records are associated with when the events occurred.
8.1.1.2 T.ADMIN_ERROR
An authorized administrator may incorrectly install or configure the TOE resulting in ineffective
security mechanisms.
This Threat is countered by ensuring that:
 O.ADMIN_ROLE: The TOE will provide authorized administrator roles to isolate
administrative actions.
 O.MANAGE: The TOE will allow administrators to effectively manage the TOE and its
security functions, and must ensure that only authorized administrators are able to access
such functionality.
8.1.1.3 T.MASQUERADE
An unauthorized user, process, or external IT entity may masquerade as an authorized entity to
gain access to data or TOE resources.
This Threat is countered by ensuring that:
 O.USER_AUTHENTICATION: The TOE will ensure either by itself or using services of the
TOE environment that user identities are authentic prior to allowing access to its functions.
8.1.1.4 T.SUBVERT
A malicious user may cause non-configuration data at rest to be inappropriately accessed
(viewed, modified or deleted).
This Threat is countered by ensuring that:
 O.CRYPTO_OPS: All data at rest on a TOE-protected persistent storage is encrypted using
FIPS-validated algorithms and modules.
8.1.1.5 T.TSF_COMPROMISE
A malicious user may cause configuration data to be inappropriately accessed (viewed, modified
or deleted).
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (52) -
This Threat is countered by ensuring that:
 O.DATA_TRANSFER: The TOE encrypts all data transferred between the client and server
and acknowledges the receipt of the transfers.
 O.FAULT_TOLERANCE: The TOE must continue to enforce access control policies if
communications with the server are not available or if the server has detected violations of
policy integrity.
 O.TOE_PROTECTION: The client portion of the TOE will protect itself and its assets from
external interference or tampering.
 OE.TOE_PROTECTION: The TOE Environment will protect the server portion of the TOE
and its assets from external interference or tampering.
8.1.1.6 T.UNAUTH_ACCESS
A user may gain unauthorized access (view, modify, delete) to configuration data.
This Threat is countered by ensuring that:
 O.ACCESS: The TOE will ensure that users gain only authorized access to the TOE and to
the resources that the TOE controls.
8.1.1.7 A.LOCATE
The server portion of the TOE will be located within controlled access facilities, which will prevent
unauthorized physical access.
This Assumption is satisfied by ensuring that:
 OE.PHYCAL: The server portion of the TOE will be located within controlled access facilities,
which will prevent unauthorized physical access.
8.1.1.8 A. NO_EVIL
The TOE will be installed, configured, managed and maintained in accordance with its guidance
documentation.
This Assumption is satisfied by ensuring that:
 OE.CONFIG: The TOE will be installed, configured, managed and maintained in accordance
with its guidance documentation.
8.1.1.9 A. NO_EVIL_USER
Users of the TOE are properly trained in the use of the TOE and will cooperate with those
responsible for administration in maintaining TOE security.
This Assumption is satisfied by ensuring that:
 OE.USER_GUIDANCE: Users of the TOE will be properly trained in the secure usage and
protection of the TOE and the devices where it is installed.
8.1.1.10 A. DEVICE_USE
Users of the TOE will follow policies to prevent unauthorized physical access to a TOE-protected
device.
This Assumption is satisfied by ensuring that:
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (53) -
 OE.USER_GUIDANCE: Users of the TOE will be properly trained in the secure usage and
protection of the TOE and the devices where it is installed.
8.1.1.11 A.REPORTS
Administrators who need to generate print or export the audit trail, or view generated reports, will
have the proper environment.
This Assumption is satisfied by ensuring that:
 OE.REPORT_ENV: The TOE Environment will provide the necessary external software to
print, export and review generated reports on systems where the management client is
installed.
8.2 Security Requirements Rationale
All Security Functional Requirements (SFR) identified in this Security Target are fully addressed in
this section and each SFR is mapped to the objective for which it is intended to satisfy.
Security
Functional
Requirements
O.ACCESS
O.ADMIN_ROLE
O.ALERT
O.AUDIT_GNEERATION
O.AUDIT_REVIEW
O.CRYPTO_OPS
O.DATA_TRANSFER
O.TAULT_TOLERANCE
O.MANAGE
O.TOE_PROTECTION
O.USER_AUTHENTICATION
FAU_ARP.1a X
FAU_ARP.1b X
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAA.1a X
FAU_SAA.1b X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_SAR.3a X
FAU_SAR.3b X
FAU_STG.1a X
FAU_STG.1b X
FAU_STG.3 X
FCS_CKM.1 X
FCS_CKM.3 X
FCS_CKM.4 X
FCS_COP.1a X X
FCS_COP.1b X
FCS_COP.1c X
FDP_ACC.2 X
FDP_ACF.1 X
FIA_AFL.1 X
FIA_ATD.1 X X
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (54) -
Security
Functional
Requirements
O.ACCESS
O.ADMIN_ROLE
O.ALERT
O.AUDIT_GNEERATION
O.AUDIT_REVIEW
O.CRYPTO_OPS
O.DATA_TRANSFER
O.TAULT_TOLERANCE
O.MANAGE
O.TOE_PROTECTION
O.USER_AUTHENTICATION
FIA_UAU.1 X
FIA_UAU.2 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_UAU.7 X
FIA_UID.1 X
FIA_UID.2 X
FMT_MSA.1 X
FMT_MSA.2 X
FMT_MSA.3 X
FMT_MTD.1a X
FMT_MTD.1b X
FMT_MTD.1c X X
FMT_MTD.1d X
FMT_MTD.1e X
FMT_MTD.1f X
FMT_MTD.1g X
FMT_MTD.2 X
FMT_REV.1 X
FMT_SAE.1 X
FMT_SMF.1 X
FMT_SMR.1 X X
FPT_FLS.1a X
FPT_FLS.1b X
FPT_ITT.1 X X
FPT_TST.1 X
FRU_FLT.1 X
FTA_TAB.1 X
FTP_TRP.1 X
Table 7 - Objective to Requirement Correspondence
8.2.1.1 O.ACCESS
The TOE will ensure that users gain only authorized access to the TOE and to the resources that
the TOE controls.
This TOE Security Objective is satisfied by ensuring that:
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (55) -
 FDP_ACC.2 and FDP_ACF.1: The TOE provides the ability to restrict access to data stored
on the device‟s persistent storage. All users are subject to the Data Access Control Policy for
all available operations devices by a combination of authentication and encryption.
 FCS_CKM.1, FCS_CKM.4 and FCS_COP.1abc: The TOE provides its own FIPS-evaluated
cryptographic module with applicable FIPS-validated algorithms which performs symmetric
encryption and decryption operations, as well as key generation and destruction. These are
used to control access to data at rest and secure communications between DataArmor and
PolicyServer.
 FTA_TAB.1: The TOE provides a means for providing a warning or appropriate use message
when the user is attempting to gain access to the persistent storage and the management
console.
8.2.1.2 O.ADMIN_ROLE
The TOE will provide authorized administrator roles to isolate administrative actions.
This TOE Security Objective is satisfied by ensuring that:
 FMT_MTD.1c and FMT_SMR.1: The TOE provides administrative, authenticator and user
authority. These are further divided by the level of the hierarchy where the role is assigned to
the user. This creates the roles of Enterprise Administrator, Enterprise Authenticator, Group
Administrator, Group Authenticator and User. The user role corresponds to users who access
TOE-protected client devices.
8.2.1.3 O.ALERT
The TOE will provide the capability to alert authorized users of potential security violations.
This TOE Security Objective is satisfied by ensuring that:
 FAU_ARP.1ab and FAU_SAA.1ab: The TOE has rules which analyze the audit records and
provides alerts when specific events, or sequences of events, have been detected.
8.2.1.4 O.AUDIT_GENERATION
The TOE will provide the capability to create records of security relevant events associated with
users.
This TOE Security Objective is satisfied by ensuring that:
 FAU_GEN.1: The TOE generates audit records for the minimum level of audit that. The
operating system is relied on to provide reliable time stamps for use in audit records. Audit
records are stored in audit trail files in the TOE environment. The operating system in the
TOE environment is relied on to protect audit trail files.
 FAU_GEN.2: The TOE generates audit records that include the identity of the user that
caused the event.
8.2.1.5 O.AUDIT_REVIEW
The TOE will provide the capability to view audit information.
This TOE Security Objective is satisfied by ensuring that:
 FAU_SAR.1 and FAU_SAR.2: The TOE provides authorized users an interface that can be
used to read from log files generated by the TOE.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (56) -
 FAU_SAR.3ab: The TOE provides administrators with the ability to search through the audit
records and then to further sort that data based on the results. From the PolicyServer
Management console, the administrator can then generate reports from this information that
can be presented outside the administrative interface. Records on the client can be reviewed
before they have been uploaded to the log database.
 FAU_STG.1a: Records stored in the client audit trail will be protected against modification to
ensure availability for review until uploaded to the server.
 FAU_STG.1b: Records stored in the server audit trail will be protected such that it is possible
to detect modification of the records to ensure integrity for review.
 FAU_STG.3: In order to maintain the most current information in the audit trail, the most
recent records will be maintained, overwriting the oldest records, should the log become full
without server communications.
8.2.1.6 O.CRYPTO_OPS
The TOE will ensure that all cryptographic operations are compliant with FIPS 140-2 Level 1 & 2
based on installed OS (cryptographic module), FIPS 197 (AES), FIPS 46-3 (3DES), FIPS 180-2
(SHS), FIPS 198 (HMAC) and ANSI X9.31 (RNG) and that the keys for those operations are
managed accordingly.
This TOE Security Objective is satisfied by ensuring that:
 FCS_CKM.1 and FCS_COP.1abc: The TOE utilizes only FIPS-validated cryptographic
modules and algorithms for encryption and decryption operations. These functions are
provided transparently to the user.
 FCS_CKM.3: The cryptographic keys used by the TOE to enforce the Data Access Policy are
escrowed for recovery purposes in accordance with best practices.
 FCS_CKM.4: The TOE ensures that all keys used for cryptographic operations are properly
deleted and cannot be recovered once they are deleted in accordance with FIPS 140-2
requirements.
8.2.1.7 O.DATA_TRANSFER
The TOE will protect system data in transmission between the client and server.
This TOE Security Objective is satisfied by ensuring that:
 FPT_ITT.1: The TOE ensures that all communications between the client and server portions
of the TOE are protected from disclosure through the use of encrypted communications.
8.2.1.8 O.FAULT_TOLERANCE
The TOE must continue to enforce access control policies if communications with the server are
not available.
This TOE Security Objective is satisfied by ensuring that:
 FPT_FLS.1a and FRU_FLT.1: The client portion of the TOE ensures that the Data Access
Control Policy remains in effect at all times, even when communications with the server
portion of the TOE are not available.
 FPT_FLS.1b: The PolicyServer portion of the TOE ensures that the Data Access Control
Policy remains in effect at all times, even when invalid policy values are found on the server,
but not allowing invalid values to be passed to the client.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (57) -
8.2.1.9 O.MANAGE
The TOE will allow administrators to effectively manage the TOE and its security functions, and
must ensure that only authorized administrators are able to access such functionality.
This TOE Security Objective is satisfied by ensuring that:
 FIA_AFL.1, FMT_MTD.1g and FMT_MTD.2: The TOE provides an administrator with the
ability to configure the consequences of failed user authentication to the TOE.
 FIA_ATD.1: The TOE maintains security attributes belonging to individual users and
administrators including user identity and authentication mechanism identification information
to accomplish this.
 FMT_MTD.1ef and FMT_SAE.1: The TOE provides an administrator with the ability to
manage the user authentication requirements. The administrator can choose the types of
mechanisms are available to the user as well as conditions on the user of the mechanisms.
 FMT_MTD.1d: The ability to manage initialize and delete encryption keys is restricted to
Authorized Administrators.
 FMT_MTD.1a: Authorized Administrators are able to search the audit trail.
 FMT_MTD.1b: Enterprise Administrators are able to manage the alert configuration for
potential violation notifications.
 FMT_MSA.1: The ability to manage user security attributes, most importantly those used for
access control decisions is restricted to Authorized Administrators.
 FMT_MSA.2: The TOE utilizes FIPS-validated cryptographic modules which ensure that all
cryptographic functions utilize secure values.
 FMT_MSA.3: By default, access to a protected device is minimal and all data at rest is
encrypted.
 FMT_REV.1: The TOE provides the ability to revoke DataArmor user access to Policy
Administrators through the management console and Authorized Administrators through the
DataArmor recovery console.
 FMT_SMF.1: The TOE provides the ability to manage user and group security attributes, and
disk key policy settings, and authentication server policy settings.
 FMT_MTD.1c and FMT_SMR.1: The TOE provides administrator, authenticator and user
roles. The PolicyServer provides Enterprise Administrators and Authenticators as well as
Group Administrators and Authenticators with separate hierarchical rights. The DAOS
recovery console provides administrators and authenticators with rights to perform
management on the local device. The user role corresponds to users who access TOE-
protected PCs. The MD User role corresponds specifically to users on mobile devices. The
ability to manage user security attributes, including role and group assignments, is restricted
to Policy Administrators in the PolicyServer, and any authenticator or administrator inside the
DAOS recovery console.
8.2.1.10 O.TOE_PROTECTION
The TOE will protect the TOE and its assets from external interference or tampering.
This TOE Security Objective is satisfied by ensuring that:
 FPT_TST.1: The TOE client ensures that the security is functioning properly when the device
is initialized by running a series of checks on the integrity of the software.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (58) -
 FPT_ITT.1: The TOE ensures that all communications between the client and server portions
of the TOE are protected from disclosure through the use of encrypted communications.
8.2.1.11 O.USER_AUTHENTICATION
The TOE will ensure that users are reliably identified and are authenticated before any access to
TOE-protected assets is granted.
This TOE Security Objective is satisfied by ensuring that:
 FIA_AFL.1: Users authenticating to the TOE are subject to restrictions on the number of
times the login attempts can fail before the TOE initiates a corrective action determined by an
administrator.
 FIA_ATD.1: The TOE will either authenticate users directly or invoke services of the TOE
environment to ensure that users are authenticated properly.
 FIA_UAU.1 and FIA_UID.1: The TOE will require that users be authenticated before any
access is granted to DataArmor protected persistent storage except for a specified list of
functions.
 FIA_UAU.2 and FIA_UID.2: The TOE authenticates all users prior to access of the
PolicyServer management console.
 FIA_UAU.5: Users of the TOE are able to utilize one of many different types of authentication
mechanisms. Some of these mechanisms may be used in combination under specific
circumstances.
 FIA_UAU.6: After a specified period of inactivity, users will be forced to re-authenticate to the
administration console.
 FIA_UAU.7: Entered authentication data will be obscured from view on the device.
 FTP_TRP.1: At the initial startup of a TOE-protected device, the TOE establishes a trusted
communication path with the user.
8.3 Security Assurance Requirements Rationale
EAL4 was selected as the assurance level because the TOE is a commercial product whose users
require a moderate to high level of independently assured security. The TOE is targeted at a relatively
benign environment with good physical access security and competent administrators. Within such
environments it is assumed that attackers will have little attack potential. As such, EAL4 is
appropriate to provide the assurance necessary to counter the limited potential for attack.
As such, EAL4 is appropriate to provide the assurance necessary to counter the potential for attack.
This ST contains the assurance requirements from the CC EAL4 assurance package augmented with
ALC_FLR.3. The CC allows assurance packages to be augmented, which allows the addition of
assurance components from the CC not already included in the EAL. Augmentation was chosen to
provide the added assurance that is provided by defining flaw remediation procedures and correcting
security flaws (ALC_FLR.3). This ST is based on good rigorous commercial development practices
and has been developed for a generalized environment for a TOE that is generally available and does
not require modification to meet the security needs of the environment specified in this ST.
8.4 Requirement Dependency Rationale
The following table demonstrates that all dependencies among the claimed security requirements are
satisfied, except as explicitly noted below, and therefore the requirements work together to
accomplish the overall objectives defined for the TOE.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (59) -
ST
Requirement
CC Dependencies ST Dependencies
FAU_ARP.1 FAU_SAA.1 FAU_SAA.1
FAU_GEN.1 FPT_STM.1
FPT_STM.1 is not satisfied by the TOE.
Rather, the TOE is dependent upon its
environment to provide time stamps in
support of audit record generation.
FAU_GEN.2 FAU_GEN.1 and FIA_UID.1 FAU_GEN.1 and FIA_UID.1
FAU_SAA.1 FAU_GEN.1 FAU_GEN.1
FAU_SAR.1 FAU_GEN.1 FAU_GEN.1
FAU_SAR.2 FAU_SAR.1 FAU_SAR.1
FAU_SAR.3 FAU_SAR.1 FAU_SAR.1
FAU_STG.1 FAU_GEN.1 FAU_GEN.1
FAU_STG.3 FAU_STG.1 FAU_STG.1
FCS_CKM.1
(FCS_CKM.2 or FCS_COP.1) and
FCS_CKM.4 and FMT_MSA.2
FCS_COP.1, FCS_CKM.4 and
FMT_MSA.2
FCS_CKM.3
(FDP_ITC.1, FDP_ITC.2 or
FCS_CKM.1), FCS_CKM.4 and
FMT_MSA.2
FCS_CKM.1, FCS_CKM.4 and
FMT_MSA.2
FCS_CKM.4
(FDP_ITC.1, FDP_ITC.2 or
FCS_CKM.1) and FMT_MSA.2
FCS_CKM.1 and FMT_MSA.2
FCS_COP.1
(FDP_ITC.1, FDP_ITC.2 or
FCS_CKM.1) and FCS_CKM.4 and
FMT_MSA.2
FCS_CKM.1, FCS_CKM.4 and
FMT_MSA.2
FDP_ACC.2 FDP_ACF.1 FDP_ACF.1
FDP_ACF.1 FDP_ACC.1 and FMT_MSA.3 FDP_ACC.2 and FMT_MSA.3
FIA_AFL.1 FIA_UAU.1 FIA_UAU.1
FIA_ATD.1 none none
FIA_UAU.1 FIA_UID.1 FIA_UID.1
FIA_UAU.2 FIA_UID.2 FIA_UID.2
FIA_UAU.5 none none
FIA_UAU.6 none none
FIA_UAU.7 FIA_UAU.1 FIA_UAU.1
FIA_UID.1 none none
FIA_UID.2 none none
FMT_MSA.1
FMT_SMR.1 and FMT_SMF.1 and
(FDP_ACC.1 or FDP_IFC.1)
FMT_SMR.1 and FMT_SMF.1 and
FDP_ACC.2
FMT_MSA.2
FMT_SMR.1 and FMT_SMF.1 and
(FDP_ACC.1 or FDP_IFC.1)
FMT_SMR.1 and FMT_SMF.1 and
FDP_ACC.2
FMT_MSA.3 FMT_MSA.1 and FMT_SMR.1 FMT_MSA.1 and FMT_SMR.1
FMT_MTD.1 FMT_SMR.1 and FMT_SMF.1 FMT_SMR.1 and FMT_SMF.1
FMT_MTD.2 FMT_MTD.1 and FMT_SMR.1 FMT_MTD.1 and FMT_SMR.1
FMT_REV.1 FMT_SMR.1 FMT_SMR.1
FMT_SAE.1 FMT_SMR.1 and FPT_STM.1
FMT_SMR.1
FPT_STM.1 is not satisfied by the TOE.
Rather, the TOE is dependent upon its
environment to provide time stamps in
support of audit record generation.
FMT_SMF.1 none none
FMT_SMR.1 FIA_UID.1 FIA_UID.1
FPT_FLS.1 none none
FPT_ITT.1 none none
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (60) -
ST
Requirement
CC Dependencies ST Dependencies
FPT_TST.1 none none
FRU_FLT.1 FPT_FLS.1 FPT_FLS.1
FTA_TAB.1 none none
FTP_TRP.1 none none
ADV_ARC.1 ADV_FSP.1 and ADV_TDS.1 ADV_FSP.4 and ADV_TDS.3
ADV_FSP.4 ADV_TDS.1 ADV_TDS.3
ADV_IMP.1 ADV_TDS.3 and ALC_TAT.1 ADV_TDS.3 and ALC_TAT.1
ADV_TDS.3 ADV_FSP.4 ADV_FSP.4
AGD_OPE.1 ADV_FSP.1 ADV_FSP.4
AGD_PRE.1 none none
ALC_CMC.4
ALC_CMS.1 and ALC_DVS.1 and
ALC_LCD.1
ALC_CMS.4 and ALC_DVS.1 and
ALC_LCD.1
ALC_CMS.4 none none
ALC_DEL.1 none none
ALC_DVS.1 none none
ALC_FLR.3 None none
ALC_LCD.1 none none
ALC_TAT.1 ADV_IMP.1 ADV_IMP.1
ATE_COV.2 ADV_FSP.2 and ATE_FUN.1 ADV_FSP.4 and ATE_FUN.1
ATE_DPT.2
ADV_ARC.1 and ADV_TDS.3 and
ATE_FUN.1
ADV_ARC.1 and ADV_TDS.3 and
ATE_FUN.1
ATE_FUN.1 ATE_COV.1 ATE_COV.2
ATE_IND.2
ADV_FSP.2 and AGD_OPE.1 and
AGD_PRE.1 and ATE_COV.1 and
ATE_FUN.1
ADV_FSP.4 and AGD_OPE.1 and
AGD_PRE.1 and ATE_COV.2 and
ATE_FUN.1
AVA_VAN.3
ADV_ARC.1 and ADV_FSP.2 and
ADV_TDS.3 and ADV_IMP.1 and
AGD_OPE.1 and AGD_PRE.1
ADV_ARC.1 and ADV_FSP.4 and
ADV_TDS.3 and ADV_IMP.1 and
AGD_OPE.1 and AGD_PRE.1
Table 8 - Requirements Dependency Analysis
The TOE provides cryptography as a service in that it allows users to arbitrarily encrypt and decrypt
disk contents using operating system and TOE environment application interfaces. Cryptographic
operations in support of web browsers and communication between components are not offered as a
service and are not reflected in the FCS SFRs in this Security Target, rather in the FPT_ITT.1
iterations. During TOE operation, when operating system and TOE environment application interfaces
are invoked to encrypt and decrypt disk content, the cryptographic operations are transparent to the
user, for example no algorithm parameters are passed. Cryptographic operations are transparent
given the implementation of a disk filter driver as described in section 2.1.
8.5 TOE Summary Specification Rationale
Each subsection in Section 6 the TOE Summary Specification, describes a security function of the
TOE. Each description is followed with rationale that indicates which requirements are satisfied by
aspects of the corresponding security function. The set of security functions work together to satisfy
all of the security functions and assurance requirements. Furthermore, all of the security functions are
necessary in order for the TSF to provide the required security functionality.
This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that
the security functions are suitable to meet the TOE security requirements. The collection of security
functions work together to provide all of the security requirements. The security functions described
in the TOE summary specification are all necessary for the required security functionality in the TSF.
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (61) -
Table 9 - Security Functions vs. Requirements Mapping demonstrates the relationship between
security requirements and security functions.
Security
audit
Cryptographic
support
User
data
protection
Identification
and
authentication
Security
management
Protection
of
the
TSF
Resource
Utilization
TOE
Access
Trusted
Path/channels
FAU_ARP.1a X
FAU_ARP.1b X
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAA.1a X
FAU_SAA.1b X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_SAR.3 X
FAU_STG.1a X
FAU_STG.1b X
FAU_STG.3a X
FAU_STG.3b X
FCS_CKM.1 X
FCS_CKM.3 X
FCS_CKM.4 X
FCS_COP.1a X
FCS_COP.1b X
FCS_COP.1c X
FDP_ACC.2 X
FDP_ACF.1 X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_UAU.1 X
FIA_UAU.2 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_UAU.7 X
FIA_UID.1 X
FIA_UID.2 X
FMT_MSA.1 X
FMT_MSA.2 X
FMT_MSA.3 X
FMT_MTD.1a X
FMT_MTD.1b X
FMT_MTD.1c X
© Mobile Armor, Inc. 2010 Version 1.72 Rationale
- (62) -
Security
audit
Cryptographic
support
User
data
protection
Identification
and
authentication
Security
management
Protection
of
the
TSF
Resource
Utilization
TOE
Access
Trusted
Path/channels
FMT_MTD.1d X
FMT_MTD.1e X
FMT_MTD.1f X
FMT_MTD.1g X
FMT_MTD.2 X
FMT_REV.1 X
FMT_SAE.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_FLS.1a X
FPT_FLS.1b X
FPT_ITT.1 X
FPT_TST.1 X
FRU_FLT.1 X
FTA_TAB.1 X
FTP_TRP.1 X
Table 9 - Security Functions vs. Requirements Mapping