Security Target (ST)
Electronic Signature Application
S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Certification ID: BSI-DSZ-CC-0413
OPENLiMiT SignCubes AG
Zuger Str. 76 B
6411 Baar
Switzerland
Version Date Author Comments
1.0 10.11.2006 Armin Lunkeit Created from ST for
S-TRUST Sign-it
base components
2.0, v2.0.4.1
1.1 05.12.2006 Armin Lunkeit Version Number
1.2 06.12.2006 Frank Kanschur Update URL
1.3 06.12.2006 Frank Kanschur Update TOE
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 2
Contents
1 Introduction .......................................................................................................................5
1.1 Identification...............................................................................................................5
1.2 Security Target Overview...........................................................................................5
1.3 CC Conformance Claim.............................................................................................7
1.4 SigG and SigV Conformance Claim...........................................................................8
2 TOE Description..............................................................................................................11
2.1 Architectural Overview.............................................................................................13
2.2 S-TRUST Sign-it Viewer ..........................................................................................15
2.3 S-TRUST Sign-it Security Environment Manager with Job API...............................17
2.4 S-TRUST Sign-it Integrity Tool ................................................................................24
2.5 TOE limitations.........................................................................................................25
2.6 Delivery....................................................................................................................26
3 TOE Security Environment..............................................................................................28
3.1 Secure Usage Assumptions.....................................................................................28
3.2 Threats to Security...................................................................................................31
3.3 Organizational Security Policies ..............................................................................34
4 Security Objectives .........................................................................................................35
4.1 Security Objectives for the TOE...............................................................................35
4.2 Security Objectives for the TOE Environment .........................................................37
5 IT-Security Requirements ...............................................................................................40
5.1 TOE Security Functional Requirements...................................................................40
5.2 TOE Security Assurance Requirements ..................................................................51
5.3 Security Requirements for the IT-Environment........................................................53
6 TOE Summary Specification...........................................................................................54
6.1 TOE Security Functions...........................................................................................54
6.2 Assurance Measures ...............................................................................................70
7 PP Claims .......................................................................................................................70
7.1 PP Reference...........................................................................................................70
7.2 PP Refinements.......................................................................................................70
7.3 PP Additions ............................................................................................................70
8 Rationale.........................................................................................................................71
8.1 Security Objectives Rationale..................................................................................71
8.2 Security Requirements Rationale ............................................................................74
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 3
8.3 Dependency Rationale.............................................................................................76
8.4 Rationale on mutual support....................................................................................80
8.5 Rationale on assurance requirements, EAL4+ and SOF-high.................................82
8.6 Rationale on TOE specification................................................................................83
9 Definition of functional family FDP_SVR.........................................................................84
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 4
Glossar and Abbreviations
BSI Bundesamt für Sicherheit in der Informationstechnik (German Federal
Office for Information Security)
CC Common Criteria
CRL Certificate Revocation List
EAL Evaluation Assurance Level
IT Information Technology
OCSP Online Certificate Status Protocol
PP Protection Profile
SigG German Signature Law
SigV Ordinance to the German Signature Law
SOF Strength of Function
SSCD Secure Signature Creation Device
SSEM S-TRUST Sign-it Security Environment Manager
ST Security Target
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
Tables
Table 1 Documentation Overview ..........................................................................................53
Table 2 License Modes in S-TRUST Sign-it base components 2.1.4.1 .................................67
Table 3 Threats and Assumptions vs. Objectives ..................................................................71
Table 4 Security Objectives vs. Security Requirements.........................................................74
Table 5 Dependencies of security requirements....................................................................78
Table 6 Security Requirements vs. Security Functions..........................................................83
Figures
Figure 1 Architectural Overview .............................................................................................13
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 5
1 Introduction
The following sections contain general information about the TOE1
and other general
information.
1.1 Identification
Title: Security Target (ST) for S-TRUST Sign-it base components 2.1.4.1
Author: Armin Lunkeit, OPENLiMiT SignCubes GmbH, Berlin, Germany
CC-Version: Version 2.3
General Status: Final
TOE: S-TRUST Sign-it base components 2.1, Version 2.1.4.1
In addition to the Common Criteria the supplier of this document used the CCIMB – final
interpretations for CC v2.1 (AIS 32).
The German name of the TOE is S-TRUST Sign-it Basiskomponenten 2.1, Version 2.1.4.1.
This document uses the name S-TRUST Sign-it base components 2.1.4.1. This is a synonym
for the full name S-TRUST Sign-it base components 2.1, Version 2.1.4.1.
AIS-Version2
: 02.07.2001
Publisher: Bundesamt für Informationstechnik in der Bundesrepublik (BSI)
1.2 Security Target Overview
The S-TRUST Sign-it base components 2.1, v2.1.4.1 is an updated version of the following
products:
• S-TRUST Sign-it base components 2.0, v2.0.3.1 (Certification ID: BSI-DSZ-CC-0374-
2006)
• S-TRUST Sign-it base components 2.0, v2.0.4.1 (Certification ID: BSI-DSZ-CC-0374-
2006-MA-01
1
TOE – Target of Evaluation
2
Allgemeines Interpretationsschema – General Interpretation Scheme
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 6
S-TRUST Sign-it base components 2.1.4.1 is an electronic signature application compliant to
the German electronic signature law and ordinance on electronic signatures. The application
itself is a set of executables and programming libraries. This means that S-TRUST Sign-it
base components 2.1.4.1 may be used as a single application but also may be integrated
into third party products.
The S-TRUST Sign-it base components 2.1.4.1 have been developed for the use on the
operating systems from Microsoft since Microsoft Windows NT. In the IT-security
environment a smart card terminal with secure pin entry mode as well as a smart card are
required to run the required cryptographic operations in the process of electronic signature
creation.
The product does provide additional cryptographic functionality like data encryption based on
symmetric encryption algorithms. These product capabilities are not part of the Common
Criteria evaluation of this product.
The TOE itself is limited to the creation of hash values, using the SHA-1, SHA-256, SHA-
384, SHA-512 and RIPE-MD 160 algorithms and is therefore able to check and ensure the
integrity as well as the trustworthiness of signed data based on the components responsible
for CRL-processing, OCSP-processing, timestamp processing and PDF processing.
The TOE provides a legal binding displaying unit (S-TRUST Sign-it Viewer) for the Text, TIFF
and PDF format. The displaying unit of the TOE allows the examination of the files content in
order to ensure that the user is assured about the content to be signed or the content of the
signed file.
This document contains the Security Target (ST) for the product S-TRUST Sign-it base
components 2.1.4.1. The product is intended to be evaluated and certified using assurance
level EAL 4+ in line with Common Criteria 2.1 in order to achieve a CC- based security
certificate and a SigG-confirmation from the German Federal Office for Information Security
(BSI).
S-TRUST Sign-it base components 2.1.4.1 is identified as the TOE. The TOE has the
version number 2.1.4.1.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 7
1.3 CC Conformance Claim
The TOE is compliant to:
• Part 2 extended of Common Criteria 2.1, released August 1999
In order to provide a complete description of the functional requirements addressed by the
TOE, functional components of part 2 of the Common Criteria framework were used. But also
additions to the Common Criteria part 2 were defined, to fulfill the requirement of a complete
and consistent TOE description.
• Part 3 conformant to Common Criteria 2.1, released August 1999
For the description of the requirements due to the trustworthiness of the TOE, only security
assurance requirements of CC part 3 were used. The assurance requirements are compliant
to EAL 4 augmented. The augments are AVA_MSU.3 and AVA_VLA.4.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 8
1.4 SigG and SigV Conformance Claim
The vendor of the product S-TRUST Sign-it base components 2.1.4.1 claims that the product
is compliant to the signature law (SigG) §17 paragraph 2. In addition to that the vendor
claims that the product is also compliant to the ordinance on electronic signatures (SigV) §15
paragraph 2 and paragraph 4.
The following listing demonstrates the compliance of the TOE with the signature law and
ordinance on electronic signatures.
§17 SigG, paragraph 2 defines:
The presentation of data to be signed requires signature-application components that will first
clearly indicate the production of a qualified electronic signature and enable the data to which
the signature refers to be identified. […]
The product implements a security function, namely SF.1, which is intended to meet the
requirements, defined in this sentence.
[…] To check signed data, signature-application components are needed that will show
1. To which data the signature refers (included by SF.1, SF.2, SF.4 and SF.5)
2. Whether the signed data are unchanged (included by SF.2 and SF.4)
3. To which signature-code owner the signature is to be assigned (included by SF.1 and
SF.2)
4. The contents of the qualified certificate on which the signature is based, and of the
appropriate qualified attribute certificates, and (included by SF.1 and SF.2)
5. The results of the subsequent check of certificates under Section 5(1) Sentence 2.
(implicitly included through SF.1 and SF.2)
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 9
Signature-application components shall, if necessary, also make the contents of the data to
be signed or already signed sufficiently evident. The signature-code owners should use
these signature-application components or take other suitable steps to secure qualified
electronic signatures.
These last requirements are fulfilled through the combination of the TOE’s security functions.
The definition of the security functions is given in 6.1 of this document.
§15 SigV, paragraph 2 defines:
Signature application components pursuant to Section 17 (2) of the Signatures Act must
ensure that
1. when producing a qualified electronic signature
a) the identification data are not disclosed and are stored only on the relevant secure
signature creation device,
b) a signature is provided only at the initiation of the authorized signing person,
c) the production of a signature is clearly indicated in advance […]
The product meets the requirements through the combination of security functions and the
requirements defined for the IT-security environment. Namely security function SF.1 ensures,
that the production of a signature is clearly indicated. The use of smart cards together with
smart-card terminals, which support secure-pin entry, conforms to the requirements defined
in 1a) and 1b). Through the use of a smart-card (SSCD) and through the security functions of
those smart cards it is ensured
2. when verifying a qualified electronic signature
a) the correctness of a signature is reliably verified and appropriately displayed and
b) it can be clearly determined whether the verified qualified certificates were present in the
relevant register of certificates at the given time and were not revoked.
The Security function SF.2 conforms to the requirements defined in 2a) and 2b).
§15 SigV, paragraph 4 defines:
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 10
Security-relevant changes in technical components pursuant to subsections (1) to (3) must
be apparent for the user.
Through the combination of several security functions, the IT-security environment
assumptions and the secure usage assumptions, the product ensures the compliance the
requirements defined in §15 SigV, paragraph 4. Moreover, the product contains mechanisms
for manipulation detection, which ensures, that security-relevant changes in the technical
components are apparent to the user. Especially SF.3, SF.5 and SF.6 are intended to ensure
the correctness of the application and of all its relevant components.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 11
2 TOE Description
The TOE is a set of executables and programming libraries. As stated before, the application
may be used as stand-alone signature client but may also be integrated into third party
products.
In a logic model, the application consists of two main components: the S-TRUST Sign-it
Security Environment Manager and the S-TRUST Sign-it Viewer that is responsible for a
legal binding presentation of the data to be signed. Both together are the base application
that is installed on the user computer.
The S-TRUST Sign-it Security Environment Manager does also export an API (Application
Programming Interface) that may be used to interact with the TOE using a programming
language3
. Moreover the S-TRUST Sign-it base components do provide a graphical user
interface that allows the interaction with product using interface devices (e.g. monitors,
keyboards and a computer-mouse).
For partners of the company, OPENLiMiT SignCubes provides a development kit which
consists of the files that are required to use the programming interface of the product as well
as a complete description of the public accessible functionality, required parameters and
return values.4
For the creation of electronic signatures, a secure pin-entry device and a smart card are
required. The S-TRUST Sign-it base components include the capabilities for OCSP, CRL
and timestamp processing. The modules that implement the functionality of how to retrieve
an OCSP response, how to download a CRL and how to retrieve a timestamp are not part of
TOE but the TOE implements mechanisms that ensure that only modules may be used that
have been developed by OPENLiMiT SignCubes. This approach is for example intended to
allow the change of authentication mechanisms against the providers of such information
without a re-evaluation, re-certification and re-confirmation of the product.
3
This API is called “S-TRUST Sign-it Job Interface”
4
This depends on commercial purposes.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 12
The product does only support the German language.
The target of evaluation (TOE) are the S-TRUST Sign-it base components 2.1.4.1 with the S-
TRUST Sign-it Security Environment Manager (SSEM) and the S-TRUST Sign-it Viewer. In
addition the S-TRUST Sign-it Job Interface should be certified together with the provided API
documentation so that third party solutions could integrate the provided functionality of that
API to extend their own set of functionality based on the OPENLiMiT SignCubes
development kit. The use of the S-TRUST Sign-it Job Interface should also be confirmed so
that it becomes possible to build applications that are allowed to create and verify qualified
electronic signatures by using the S-TRUST Sign-it Job Interface in a certified and confirmed
way.
The TOE binary files do all have the file version 2.0.3.1 except the following files: siq2ds2.dll
with version 2.0.4.1, siqSEMk.dll, siqZipLib, siqJob.dll do have the file version 2.1.4.1.
The term product will be used in the further document as a synonym for the S-TRUST Sign-it
base components used as a stand-alone application for electronic signatures.
In addition to the main components, OPENLiMiT SignCubes provides the S-TRUST Sign-it
Integrity Tool that must be used to ensure the integrity of the products installation. The S-
TRUST Sign-it Integrity Tool is a separate application implemented as a Java Applet. So the
TOE consists of the S-TRUST Sign-it Security Environment Manager, the S-TRUST Sign-it
Viewer and the S-TRUST Sign-it Integrity Tool.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 13
2.1 Architectural Overview
The following graphic depicts the architecture of the product with its main components.
S-TRUST Sign-it Viewer
S-TRUST Sign-it Job Interface (API)
S-TRUST Sign-it
Security Environment Manager
S-TRUST Sign-it base
components 2.1
Figure 1 Architectural Overview
The S-TRUST Sign-it Security Environment Manager is the main component of the whole
application and provides all security functionality except the capabilities of the legal binding
viewer component.
The S-TRUST Sign-it Viewer uses the S-TRUST Sign-it Job Interface for any security
relevant operation and does not implement any security functionality except the one that is
required for legal binding viewing of PDF, TIFF and Text files.
As the graphic depicts, it is not possible to interact with the S-TRUST Sign-it Security
Environment Manager directly using a programming interface, the S-TRUST Sign-it Job
Interface must always be used to access any functionality of the SSEM in a programmed
way.
Underneath the S-TRUST Sign-it Security Environment Manager the required security
hardware is located. Required security hardware means a card reader with secure pin entry
mode and a secure signature creation device (SSCD).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 14
OPENLiMiT SignCubes provides the S-TRUST Sign-it Integrity Tool as a separate
application to ensure the integrity of the products installation on the computer of the user.
The description for that tool can be found in the section “S-TRUST Sign-it Integrity Tool”.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 15
2.2 S-TRUST Sign-it Viewer
The S-TRUST Sign-it Viewer component is a software component for displaying signed data
or data to be signed according to the signature law §17 paragraph 2.
In accordance to the German signature law §17, paragraph 2, in the process of signature
creation the S-TRUST Sign-it Viewer component is required to ensure that the data, to which
the signature will refer to, is unambiguously displayed.
In the process of signature verification the S-TRUST Sign-it Viewer ensures, that it is evident,
to which data the electronic signature refers.
The following functionalities are identified for the S-TRUST Sign-it Viewer:
Functionality to obtain information about the document to be displayed
Functionality for displaying PDF, TIFF and Text documents5
The S-TRUST Sign-it Viewer does not provide any API’s that may be used be third party
components. This component makes use of the S-TRUST Sign-it Job Interface to provide a
useful set of functionality in its graphical user interface. This means that the S-TRUST Sign-it
Viewer provides the functionality to start the creation of an electronic signature on the
currently displayed document as well as the start of the verification of an electronic signature
that has been found for a document.
The S-TRUST Sign-it Viewer is able to display TIFF documents following the Adobe TIFF
specification, PDF documents that follow the PDF 1.6 document format as well as
documents that contain ASCII characters. The TIFF document can also be a multipage TIFF.
5
The displayed formats do depend on the license file of the user. The license file may specify that a
file format, e.g. PDF, cannot be displayed. In this case a message is displayed to the user that informs
him that he has not the required license to display that data format.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 16
This component implements a parser that checks the correctness of the document to be
displayed. This means, that the TIFF and/or PDF tags and elements are checked and the
viewer ensures that the document does not contain information that could not be displayed to
the user. If the S-TRUST Sign-it Viewer detects an error in the documents structure, a
warning message is displayed to the user. If the component detects that an ASCII file should
be displayed, the Viewer ensures that the document fits with the rules for ASCII code and
displays a warning message if the documents content does not behave the specified way6
.
The file formats that can opened with the S-TRUST Sign-it Viewer are PDF, TIFF, Text and
PKCS#7 encoded data that contains data that is of the specified type. The PKCS#7 encoded
data may contain one or more electronic signatures that may be verified using the S-TRUST
Sign-it Viewer as an indirect interface to this functionality of the S-TRUST Sign-it Security
Environment Manager.
If the user decides to sign the document that is currently displayed with the S-TRUST Sign-it
Viewer, he can start the process of electronic signature creation using the S-TRUST Sign-it
Viewer as an indirect interface to that functionality provided by the S-TRUST Sign-it Security
Environment Manager.
With the choice of these file formats the user cannot be the target of malicious code or active
code that may be included in the document, because the document formats do not support
active or hidden code or content or the active code is ignored7
by the application.
6
The rules are documented in the TOE’s user guidance.
7
[27] does not allow active code elements, e.g. JavaScript. If JavaScript is included in the document,
a warning message is generated and the code is not executed because the TOE does not contain any
mechanisms to interpret such content. [27] does allow active elements, e.g. embedded multi media
content, but these types of content are ignored by the S-TRUST Sign-it Viewer.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 17
2.3 S-TRUST Sign-it Security Environment Manager with Job API
The S-TRUST Sign-it Security Environment Manager provides the following functionality that
may be accessed in parts or completely through the use of the S-TRUST Sign-it Job API:
• Computation of hash values using the SHA-1, SHA-256, SHA-384, SHA-512 and
RIPE-MD 160 algorithms.
• Creation of electronic signatures using a smart card and a secure pin entry device.
• Timestamp processing during the process of electronic signature creation.
• Support for attribute certificates in the process of electronic signature creation.
• Support for OCSP processing during the electronic signature creation.
• Electronic signature verification including OCSP and CRL processing as well as
timestamp processing. The use of attribute certificates is supported.
• API’s for applications/product parts that want to use the provided functionality.
• Ensuring the integrity and correctness of the SignCubes base components installed
on the users computer.
• Providing graphical interfaces in the process of signature creation, verification and
product configuration.
In the process of signature verification the S-TRUST Sign-it Security Environment Manager
is required to provide information about qualified attribute certificates corresponding to a
qualified certificate that was used for the creation of a qualified electronic signature. The S-
TRUST Sign-it Security Environment Manager includes the capabilities to detect, if an
attribute certificate belongs to a presented certificate and, if the attribute certificate is
accessible, to display the information encoded in the attribute certificate.
The S-TRUST Sign-it base components do work with PKCS#7 encoded data8
. This means,
that the application is compatible with any application that processes data in the same
format.
8
The security functionality of the TOE refers to the decoded PKCS#7 content and not to encrypted
PKCS#7 data.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 18
Depending on the driver implementation for each smart-card terminal, the S-TRUST Sign-it
base components can use the PC/SC or the CT-API for the communication with the smart
card and the smart-card terminal. Some manufacturers deliver separate program libraries for
starting the secure pin entry mode of their smart-card terminals. The S-TRUST Sign-it base
components implement the special requirements of the terminals, if there are any. The list of
supported smart card readers can be found in the chapter “Secure Usage Assumptions”. The
list of supported smart cards can also be found in the chapter “Secure Usage Assumptions”.
Only devices, which have a SigG confirmation, are allowed for the use with the S-TRUST
Sign-it base components. The German Federal Network Agency for Electricity, Gas,
Telecommunications, Post and Railway (Federal Network Agency, formerly known as
RegTP, http://www.bundesnetzagentur.de/) provides a list of these products.
The S-TRUST Sign-it Security Environment Manager can be used by any application. This
facilitates the integration into software products of third parties. Therefore the S-TRUST
Sign-it Job Interface is implemented and appropriate documentation material is delivered.
The S-TRUST Sign-it Job Interface offers a job that allows the creation of electronic
signatures for more than one document. This job is not offered by the graphical user
interface of the TOE. If an external application utilizes this job, the signature creation dialog
is displayed to the user. This signature creation dialog provides a list of the files to be signed
and allows the inspection of each file by the S-TRUST Sign-it Viewer, that is part of the TOE.
The creation of electronic signatures is started when the user confirms the signature creation
process by pressing a button that is part of the signature creation dialog.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 19
During the creation of the electronic signatures by the secure signature creation system,
which consists of a smart card and a card terminal with secure pin entry mode, the user is
required to enter the PIN for each document separately, if a smart card is utilized, which
does not allow to leave the PIN open. If the user utilizes a smart card that allows leaving the
card open, the PIN is only requested one time9
. In any case, the PIN is closed by the S-
TRUST Sign-it base components 2.1.4.1 when the job has finished.
The TOE provides a settings dialog that enables the user to specify the limits for the
generation of electronic signatures. The limit can be set by the time that the card is left open
or by the number of signatures to be created. These options can be utilized to define
breakpoints in the generation of electronic signatures to enter the PIN again. The first
criterion that has been reached during the execution of the job closes the PIN and the user is
required to enter the PIN once again.
The user has the possibility to cancel the process of signature creation. In this case, all
signature files that have been created by this job are removed from the directory.
The job cannot be utilized to implement a signature service that automatically signs a
document. Through the presentation of the signature request dialog and the list of
documents to be signed it is ensured, that the user has the possibility to view all documents
using the S-TRUST Sign-it Viewer before the signature process is started. Furthermore the
user must acknowledge the creation of the signatures by pressing a button in the request
dialog.
Consequently the automating of signature creation of different types of documents is
excluded. The user is required to define a limit for the creation of electronic signatures using
the settings dialog for time and number of electronic signatures that are allowed to be
created without requesting the PIN again. In each case the PIN is closed by the S-TRUST
Sign-it base components 2.1.4.1 when the job has been executed, so the maximum count of
electronic signatures that can be created without requesting the PIN again is defined by the
amount of documents to be signed by the job.
9
Therefore the TOE has to be configured via a settings dialog as described below. If the TOE is not
configured to leave the card open, the PIN is requested for each signature operation.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 20
The job can only be accessed by OPENLiMiT applications and is not permitted for third party
applications because the calling application needs a special signature that identifies the
application as a permitted OPENLiMiT application. If an application, which is not allowed to
utilize this job, tries to execute this job, the S-TRUST Sign-it Security Environment Manager
is deactivated due to suspected manipulation. This means, that no security related
functionality (especially the initiation of creation of electronic signatures), can be accessed
through the S-TRUST Sign-it Job Interface or through the graphical interface of the TOE.
This state is signalled to the user with an error message and a special icon in the system
tray.
The S-TRUST Sign-it base components 2.1.4.1 ensure that the PIN is closed after the
execution of the job. This ensures that the user is required to enter the PIN again, if the
creation of an electronic signature is initiated the next time.
Signature verification is basically done by using the chain model from the user certificate
down to the national root CA in combination with CRL processing. For PKI models, which are
not compliant to the X.509 standard, a configuration file is required10
. After checking the
revocation list, an unambiguous status value is set on the programmable interface. In
addition, an unambiguous text message can be displayed11
. This depends on several
configuration issues. If it is impossible to load the revocation list or another error occurs, an
unambiguous status code is set.
10
The file is digitally signed with same private key that is used for the signatures on the TOE’s binary
files and part of the TOE.
11
The verification of an electronic signature can be done in the modes “verbose” or “silent”. The S-
TRUST Sign-it base components, e.g. the S-TRUST Sign-it Viewer, always use the “verbose” mode
so that the user is always informed about the validity of an electronic signature that he checks. The
use of these modes is configured by the use of the S-TRUST Sign-it Job Interface and is unique for
each operation on the S-TRUST Sign-it Job Interface.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 21
In addition to CRL processing, the S-TRUST Sign-it base components offer the possibility to
use the online certificate status protocol (OCSP) to verify the validity of a given certificate.
This can only be done, if enough information about the OCSP responder is available. That
means, that the certificate must contain a field identifying an OCSP responder for this
certificate or a special configuration file exists, which identifies the OCSP responder for the
CA that issued the certificate under examination. After processing the OCSP response, an
unambiguous status code is set on the programmable interface. If the product is configured
to show dialogs, an unambiguous message will be shown to the user that informs about the
validity of the certificate that has been requested on the OCSP responder.
The scope OCSP, CRL and timestamp processing in this certification does not include the
way of how to obtain that information. The way of how to obtain that information is explicitly
not part of the evaluation. The product implements policies that allow using several modules
to retrieve that requested information. The modules itself must be signed by OPENLiMiT
SignCubes. With this approach OPENLiMiT SignCubes ensures that no malicious modules
may be installed on the computer of the user and may be used by the application without
detection of this state. Even if an attacker does reverse engineering and identifies the
internal API’s that are used to retrieve such data he would not be able to manipulate the
application using that approach. The addition of a new module underlies the update
procedure of the product that is described in the section “Delivery”.
Another capability of the S-TRUST Sign-it Security Environment Manager is the processing
of timestamps. A Timestamp can be requested during the process of signature creation and
that timestamp can be used during the signature verification.
The use of attribute certificates is also supported. The S-TRUST Sign-it Security
Environment Manager includes the capabilities to display attribute certificates and to process
their content. Any information about the attribute certificate under examination may also be
accessed using the S-TRUST Sign-it Job Interface.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 22
The S-TRUST Sign-it Security Environment Manager implements all required capabilities for
the management of the program modules. The S-TRUST Sign-it Security Environment
Manager also manages messages, which may be displayed to the user12
. The default
configuration of the S-TRUST Sign-it Security Environment Manager enforces displaying any
dialogs to the user. The capabilities to display messages and information to the user as well
as the correctness of the status codes that are set on the user interface must be evaluated.
The capabilities of the S-TRUST Sign-it base components to operate PDF documents
depends on the license code of the user. If the user has no license code, the product
disables all capabilities to generate signatures but is still usable for the purpose of signature
verification. The electronic signature initiation and PDF operating modes that depend on the
license are defined as following:
• No signature creation capabilities of the TOE, if the user does not have a license
code. The displaying of PDF documents is not allowed.
• No PDF displaying capabilities of the S-TRUST Sign-it Viewer. No possibilities to
create any kind of signature on PDF documents. The S-TRUST Sign-it Viewer can be
utilized to display Text and TIFF documents and to create PKCS#7 signatures on
these document types.
• PDF displaying but no capabilities to create signatures on PDF documents using the
S-TRUST Sign-it Viewer. PKCS#7 and embedded PDF signatures on PDF
documents can be verified. The S-TRUST Sign-it Viewer can be utilized to display
Text and TIFF documents and to create PKCS#7 signatures on these document
types.
• PDF displaying and the capability to create attached and detached PKCS#7
signatures as well as the verification of these signatures using the S-TRUST Sign-it
Viewer13
. The S-TRUST Sign-it Viewer can be utilized to display Text and TIFF
documents and to create PKCS#7 signatures on these document types. The
capability to create PDF signatures is not enabled.
12
Only, if the S-TRUST Sign-it Security Environment Manager is configured to display messages (this
is the default behaviour). Otherwise, the S-TRUST Sign-it Security Environment Manager does only
provide appropriate status codes on the programmable interface.
13
Embedded PDF signatures can also be verified.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 23
• PDF displaying is enabled, the creation of PKCS#7 encoded and PDF signatures for
PDF documents is enabled as well as the verification of these signature types. The S-
TRUST Sign-it Viewer can be utilized to display Text and TIFF documents and to
create PKCS#7 signatures on these document types.
The license influences the TOE’s behavior on the graphical interfaces, namely the S-TRUST
Sign-it Viewer. If the user utilizes a version that does not allow the creation of electronic
signatures, the TOE cannot be used for the generation of electronic signatures except the
creation of an electronic signature during the licensing process. All other licenses do allow
the generation of PKCS#7 encoded signatures on PDF documents using the S-TRUST Sign-
it Job Interface. The generation of PDF signatures using the S-TRUST Sign-it Job Interface
is not supported for any kind of license.
The S-TRUST Sign-it Job Interface is allowed to utilize the capabilities of the TOE in order to
display PDF documents and to verify signatures on PDF documents, even if these
capabilities are not part of the users license.
The TOE provides the possibility to update the current license without reinstallation of the
product. The configuration on the users computer is managed by the license code that is
provided to the user together with the setup routine for the TOE.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 24
2.4 S-TRUST Sign-it Integrity Tool
The S-TRUST Sign-it Integrity Tool is a Java Applet that is used to allow the user to check
the integrity of the installed product. This Java Applet knows the SHA-1 hash values of each
file that is part of the TOE and checks, if the file’s hash value is identical with the known hash
value.
The Java Applet is also signed, the Java Virtual Machine verifies the signature of the Applet.
To ensure the correct behavior of this tool, the Java Virtual Machine v1.4 or higher is
required. The fingerprint of the signing certificate is published on the OPENLiMiT Website
(www.openlimit.com).
If the Java Applet detects that the hash value of the file under test does not fit with the hash
value that is known to the Applet for this file, an unambiguous message is displayed to the
user. In this case, the user is required to reinstall the product once again and to check the
integrity of the current installation once again.
The S-TRUST Sign-it Integrity Tool does not check the configuration of application because
the user has a wide range of configuration possibilities. The requirements for a secure
product configuration are listed in the user guide for the product and must be checked
manually by the user. After the installation of the product, the S-TRUST Sign-it base
components 2.1.4.1 has a secure configuration that is recommended by the manufacturer.
The S-TRUST Sign-it Integrity Tool itself generates all messages that are displayed to the
user. The text displaying functionality of the S-TRUST Sign-it Security Environment Manager
is not used because the SSEM itself can be manipulated.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 25
2.5 TOE limitations
The TOE cannot assure the correctness of the following functions:
• Private Key material. The secure signature creation device must assure the
correctness and integrity of the private key material.
• Assurance of the operating system integrity. The TOE does not contain any
capabilities for ensuring the integrity of the operating system and its environment. The
user must assure, that sufficient actions are undertaken to avoid, that the operating
system may be compromised.
• Strength and security of cryptographic operations. The TOE uses libraries for hash
value creation and the RSA algorithm for signature validation. Therefore the TOE can
only assure the compliance to given standardization documentation and test vectors
but must not make any statement about the strength of the cryptographic operations.
The capability characteristics of the TOE are limited to the computation of hash values and
the usage of secure signature creation devices for electronic signature creation and the
usage of the RSA algorithm for signature verification. Manipulations on the IT-security
environment cannot be recognized or even prevented by the TOE.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 26
2.6 Delivery
The DSV and its partners are responsible for the delivery of the TOE. The following delivery
procedures are foreseen:
• Delivery on Read-Only Storage Devices
• Online Delivery Procedures
In both cases, the S-TRUST Sign-it Integrity Tool is part of the delivery procedure. The JAR-
Archive containing the S-TRUST Sign-it Integrity Tool is digitally signed with a qualified
electronic signature. When the user received the TOE, he is required to verify the electronic
signature of the JAR-Archive to ensure that the correct S-TRUST Sign-it Integrity Tool has
been delivered to the customer.
After installation of the TOE the user is required to execute the S-TRUST Sign-it Integrity
Tool to verify the integrity of the installed TOE. If the integrity check was successful, the
customer received the TOE that was intended to be delivered.
Another possibility to access the Integrity Tool is the use of the following link:
https://www.s-trust.de/sign-it/sicherheit
This URL leads the customer to the S-TRUST Sign-it Integrity Tool that is located on the
DSV Website.
The TOE contains modules that are intended to be updated if necessary. The update
procedure does not influence the TOE and is intended to update configurable user items,
e.g. authentication modules that are necessary to receive an OCSP response or a
timestamp14
.
14
The product is only being evaluated for the capabilities of processing OCSP responses, timestamps
and CRL’s. This means that the product has standard interfaces that are able to parse and decode the
responses. In order to avoid lifecycle issues if an authentication mechanism changes or the URL for
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 27
If the user wishes to utilize the TOE capabilities, he is required to utilize a license code15
. The
license code is provided by the DSV or its resellers to the customer.
If the TOE is received by download, the OPENLiMiT SignCubes AG may require the DSV
and its resellers to implement a registration procedure that generates evidence for the
license codes that have been delivered to customers.
In case that the user owns a valid installation of the S-TRUST Sign-it base components 2.0,
v2.0.3.1 or S-TRUST Sign-base components 2.0, v2.0.4.1 he can utilize an update setup to
install the TOE. This update setup does only install the updated binary files on the users
computer. In all other cases the user requires a complete installation routine.
retrieving an OCSP response changes, the product uses separate modules to retrieve such
responses. The way of receiving such information is not in the scope of the evaluation.
15
see 2.3
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 28
3 TOE Security Environment
3.1 Secure Usage Assumptions
The following assumptions about the TOE’s security environment are devised.
A.Platform
The user utilizes an Intel 586 compatible computer as hardware platform, which contains at
least 64 MB of RAM and 60 MB of free disk space.
On the computer is one of the following operating systems installed:
• Windows NT 4 SP 6
• Windows 2000 SP 2
• Windows 2003
• Windows XP Home
• Windows XP Professional
• Windows XP Tablet PC Edition
• Windows XP 64 Bit Edition
In addition to these requirements, the Internet Explorer version 5.01 or higher is installed.
Moreover, the Microsoft smart card base components are installed on the computer16
. In
addition to that, a Java Virtual Machine (JVM) is installed on the computer, which complies at
least with the Java Runtime Environment v1.4.
The user ensures, that all components of the operating system are correct. The user ensures
that no malicious or harmful program is installed on the system.
The user utilizes a secure signature creation system, which consists of a smart-card terminal
with secure pin entry capabilities together with a smart card. The user utilizes one of the
following SigG approved smart cards:
16
The manual installation of the Microsoft SmartCard base components is required for Microsoft
Windows NT 4.0 SP 6
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 29
• ZKA Banking signature card, v6.2 NP, Type 3 from Giesecke & Devrient
• ZKA Banking signature card, v6.2b NP and 6.2f NP, Type 3 from Giesecke &
Devrient
• ZKA Banking signature card v6.31 NP, Type 3 from Giesecke & Devrient
• ZKA Banking signature card v6.32, Type 3 from Giesecke & Devrient
• ZKA signature card, version 5.02 from Gemplus-mids GmbH
• S-TRUST signature card release 3 (SPK 2.3 based)17
• ZKA Banking Signature Card, Version 6.4 from Giesecke & Devrient
• ZKA Banking Signature Card, Version 6.51 from Giesecke & Devrient
• ZKA Banking signature card, v6.6 from Giesecke & Devrient
• ZKA signature card, ZKA 680 V5A from Gemplus-mids GmbH
17
Not an approved smart card.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 30
The user utilizes one of the following smart-card terminals:
• Kobil Systems B1 Pro USB
• Kobil Systems KAAN SecOVID Plus
• Kobil Standard Plus
• SCM Microsystems SPRx32
• Reiner SCT cyberJack e-com v2.0
• Reiner SCT cyberJack pinpad v2.0
• Reiner SCT cyberJack pinpad v3.0
• Omnikey Cardman 3621
• Omnikey Cardman 3821
• Cherry ST-2000
The used components are approved components according to the German signature law.
The certificates can be obtained from the Bundesnetzagentur (www.bundesnetzagentur.de).
A.Personnel
The user, the administrator and the maintenance staff are trustworthy and follow the user
guide of the TOE. Especially the user verifies the integrity of the TOE as described in the
user documentation.
A.Network
The computer, where the TOE is installed, may have Internet access. In this case a firewall is
used to ensure, that no system services or components are compromised through Internet
attacks. In addition to this, the user utilizes a virus scanner, which is able to detect virus
programs as well as backdoor programs and root kits. At least the virus scanner is able to
inform the user about attacks or detected malicious programs.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 31
A.Access
The computer, on which the TOE is installed, is located in an environment, where the user
has full control about inserted storage devices and shared network storage places. The TOE
is protected in such way, that it is not possible to access parts of the TOE or the TOE as a
whole through existing network connections.
3.2 Threats to Security
The analysis of security threats to the TOE and to objects, which should be protected by the
TOE were supplemented using the document “Maßnahmenkatalog für technische
Komponenten nach dem Signaturgesetz”. It must be said, that this catalogue refers to the
“old” signature law (from 22.07.1997). The usage of this catalogue is tolerable, because the
arrangements can be implied to the current signature law.
In addition to that the CEN Workshop Agreement CWA 14170 “Security Requirements for
Signature Creation Applications” has been used for the analysis of security threats.
All security threats assume an adversary with high attack potential. For the protection against
the threats identified in this section the kind of exploited vulnerability is irrelevant because the
identified threats should be prevented in general.
Objects that must be protected by the TOE are: the document that the user wants to sign
(“user file”), a signed file and the TOE with its own data and files.
User File
A user file is a file that user decided to sign with the TOE and that is currently processed by
the TOE. Currently processed means that the TOE holds a kind of reference to that file
expressed by the directory and the name of the file.
Signed File
A Signed File is a file with an electronic signature.
TOE’s data and files
This term means all binary and configuration files of the TOE. The term data refers to files
that are required to operate the TOE correctly, e.g. certificates.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 32
T.DAT
Manipulation of a user file
The adversary manipulates a user file using any instrument and the manipulation is not
detected.
This security threat is very general, because several scenarios are covered through this. The
term user file has been defined in the section above. The adversary may manipulate the file
using an appropriate file editor, a network tool or any other applicable mechanism. A
manipulation covers random manipulations as well as systematic changes to the file.
T.SIG_DAT
Manipulation of a signed file
The adversary manipulates a signed file using any instrument and the manipulation is not
detected.
This security threat is very general, because several scenarios are covered through this. The
definition of the term signed file has been given in the section above. The adversary may
manipulate the file using an appropriate file editor, a network tool or any other applicable
mechanism. A manipulation covers random manipulations as well as systematic changes to
the file.
T.TOE
Manipulation of the TOE and of its files
The adversary manipulates or replaces parts (modules) or data of the TOE on the computer
and the manipulation is not detected.
The manipulation of TOE files or modules is a direct attack against the product. The
adversary manipulates or changes parts of the TOE with the scope, to change some of the
security functionality or even to deactivate this functionality of the TOE.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 33
T.PRE_SIG
Manipulation of a file before the users decision to sign the file
The adversary changes the file using any mechanisms, before the user decides to sign the
file and the manipulation are not detected.
The file is a file that the user wants to sign. The security threat implies an adversary who is
able to change files in the time between the selection of the file18
and the beginning of the
signing process.
T.POST_SIG
Creation of a falsified electronic signature
The adversary manipulates the computed hash value of the document before the hash value
is transmitted to the secure signature creation device and the manipulation is not detected.
The adversary is able to manipulate the hash value of the data to be signed in the time slice
between the start of the signature process triggered by the user and the transmission to the
smart card. It may be possible, to change the hash value of the data during transmission to
the secure signature creation device.
T.LIC
Downgrading of TOE’s manageable capabilities
The adversary utilizes a license code or license file that disables parts of the TOE’s
manageable capabilities and this downgrading is not detected.
The adversary owns a license code or a license file for the TOE that enables a smaller set of
capabilities of the TOE that are managed through the license code and enters this license
code. The TOE would not provide the full set of functionality the user has licensed.
18
This is a user file as defined in the section above. The TOE holds a reference to file but the file is
still not signed.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 34
3.3 Organizational Security Policies
There are no organizational security policies defined for the TOE.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 35
4 Security Objectives
4.1 Security Objectives for the TOE
OT.DAT
Protection of a user file
The TOE must offer the possibility of manipulation protection through the computation of
hash values over the data of a file.
OT.SIG_DAT
Protection of a signed file
The TOE must offer the possibility to determinate, that it is unambiguous, whether a signed
file has been manipulated or not.
OT.TOE
Protection of the TOE
The TOE must offer the possibility, to identify manipulations of TOE components or of TOE
data.
OT.PRE_SIG
Protection of a file before the users decision, to sign the file
The TOE must offer the possibility to display the file and the data to be signed in an
unambiguous way.
OT.POST_SIG
Protection against hash value falsification
The TOE must offer the possibility to identify, if the hash value of the data to be signed was
manipulated after signature creation.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 36
OT.LIC
Prevention of Downgrading of manageable TOE capabilities
The TOE must protect the integrity of the license through hash value computation and
electronic signatures. The TOE must prevent a downgrade of the users license.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 37
4.2 Security Objectives for the TOE Environment
The security objectives for the TOE environment are based on the secure usage
assumptions and from security threat T.DAT.
OE.Platform
The user must utilize an Intel 586 compatible computer as hardware platform, which has at
least 64 MB of RAM and 60 MB of free disk space.
On the computer one of the following operating systems has to be installed:
• Windows NT 4 SP 6
• Windows 2000 SP 2
• Windows 2003
• Windows XP Home
• Windows XP Professional
• Windows XP Tablet PC Edition
• Windows XP 64 Bit Edition
In addition to these requirements, the Internet Explorer version 5.01 or higher must be
installed. Moreover, the Microsoft smart-card base components must be installed on the
computer. In addition to that, a Java Virtual Machine (JVM) must be installed on the
computer, which complies at least with the Java Runtime Environment v1.4.
The user must ensure, that all components of the operating system are correct. The user
must ensure that no harmful or malicious software is installed on the system.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 38
The user must utilize a secure signature creation system, which consists of a smart-card
terminal with secure pin entry capabilities together with a smart card. The user must utilize
one of the following SigG approved smart cards:
• ZKA Banking signature card, v6.2 NP, Type 3 from Giesecke & Devrient
• ZKA Banking signature card, v6.2b NP and 6.2f NP, Type 3 from Giesecke &
Devrient
• ZKA Banking signature card v6.31 NP, Type 3 from Giesecke & Devrient
• ZKA Banking signature card v6.32, Type 3 from Giesecke & Devrient
• ZKA signature card, version 5.02 from Gemplus-mids GmbH
• S-TRUST signature card release 3 (SPK 2.3 based)19
• ZKA Banking Signature Card, Version 6.4 from Giesecke & Devrient
• ZKA Banking Signature Card, Version 6.51 from Giesecke & Devrient
• ZKA Banking signature card, v6.6 from Giesecke & Devrient
• ZKA signature card, ZKA 680 V5A from Gemplus-mids GmbH
The user must utilize one of the following smart-card terminals:
• Kobil Systems B1 Pro USB
• Kobil Systems KAAN SecOVID Plus
• Kobil Standard Plus
• SCM Microsystems SPRx32
• Reiner SCT cyberJack e-com v2.0
• Reiner SCT cyberJack pinpad v2.0
• Reiner SCT cyberJack pinpad v3.0
• Omnikey Cardman 3621
• Omnikey Cardman 3821
• Cherry ST-2000
The used components are approved components according to the German signature law.
The certificates can be obtained from the Bundesnetzagentur (www.bundesnetzagentur.de).
19
Not an approved smart card.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 39
OE.Personnel
The user, the administrator and the maintenance staff must be trustworthy and must follow
the user guide of the TOE. Especially the user must verify the integrity of the TOE as
described in the user documentation.
OE.Network
The computer, where the TOE is installed, may have Internet access. In this case a firewall
must be used to ensure, that no system services or components are compromised through
Internet attacks. In addition to this, the user must utilize a virus scanner, which is able to
detect virus programs as well as backdoor programs and root kits. At least the virus scanner
must be able to inform the user about attacks or detected malicious programs.
OE.Access
The computer, on which the TOE is installed, must be located in an environment, where the
user has full control of inserted storage devices and shared network storage places. The
TOE must be protected in such way, that it is not possible to access parts of the TOE or the
TOE as a whole through existing network connections.
OE.SIG_DAT
Through the use of appropriate organizational measurements it must be ensured that the IT-
environment offers the functionality to compute an electronic signature from a hash value.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 40
5 IT-Security Requirements
5.1 TOE Security Functional Requirements
The specified functional requirements are compliant with Common Criteria v2.1 part 2 and
are corresponding with the given functional components except the component FDP_SVR.1,
which is defined in this security target.
FCS_COP.1 (SHA-1)20
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of hash values] in accordance with
specified cryptographic algorithm [assignment: SHA-1] and cryptographic key sizes
[assignment: none] that meet the following: [assignment: standard FIPS 180-2].
FCS_COP.1 (SHA-256)21
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of hash values] in accordance with
specified cryptographic algorithm [assignment: SHA-256] and cryptographic key sizes
[assignment: none] that meet the following: [assignment: standard FIPS 180-2].
20
Iteration
21
Iteration
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 41
FCS_COP.1 (SHA-384)22
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of hash values] in accordance with
specified cryptographic algorithm [assignment: SHA-384] and cryptographic key sizes
[assignment: none] that meet the following: [assignment: standard FIPS 180-2].
FCS_COP.1 (SHA-512)23
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of hash values] in accordance with
specified cryptographic algorithm [assignment: SHA-512] and cryptographic key sizes
[assignment: none] that meet the following: [assignment: standard FIPS 180-2].
FCS_COP.1 (160)24
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of hash values] in accordance with
specified cryptographic algorithm [assignment: RIPE-MD 160] and cryptographic key sizes
[assignment: none] that meet the following: [standard: RIPEMD-160: A Strengthened Version
of RIPEMD].
22
Iteration
23
Iteration
24
Iteration
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 42
FCS_COP.1 (RSA1-1024 to 2048)25
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: verification of electronic signatures] in accordance with
specified cryptographic algorithm [assignment: RSA] and cryptographic key sizes
[assignment: 1024 to 2048 bit] that meet the following: [assignment: standard PKCS#1].
FCS_COP.1 (RSA2-1024 to 2048)26
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: verification of electronic signatures] in accordance with
specified cryptographic algorithm [assignment: RSA] and cryptographic key sizes
[assignment: 1024 to 2048 bit] that meet the following: [assignment: standard PKCS#1].
Refinement for FCS_COP.1 (RSA2-1024 to 2048)
Part 1:
The TSF must validate the certificate chain using the chain model, if the validation model for
the CA is based on the chain model. Therefore the standard ISIS-MTT Common ISIS MTT
Mailtrust Specifications for Interoperable PKI Applications Version 1.02 in conjunction with
the ISIS-MTT Optional Profile: SigG-Profile must be used.
Part 2:
The TSF must validate the certificate chain using the standard RFC 3280, if the validation
model for the CA is not based on the chain model.
25
Iteration
26
Iteration
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 43
FDP_DAU.2
Data Authentication with identity of guarantor
FDP_DAU.2.1
The TSF shall provide a capability to generate evidence that can be used as a guarantee of
the validity of [assignment: a file chosen by the user].
FDP_DAU.2.2
The TSF shall provide [assignment: the user] with the ability to verify evidence of the validity
of the indicated information and the identity of the user that generated the evidence.
FDP_ITC.1(1)27
Import of user data without security attributes
FDP_ITC.1.1
The TSF shall enforce the [assignment: none] when importing user data, controlled under the
SFP, from outside of the TSC.
FDP_ITC.1.2
The TSF shall ignore any security attributes associated with user data when imported from
outside the TSC.
27
Iteration
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 44
FDP_ITC.1.3
The TSF shall enforce the following rules when importing user data controlled under the SFP
from outside the TSC: [assignment: Rules for the usage of a certificate for verification after
signature creation].
Rules for the usage of a certificate for verification after signature creation
After the creation of an electronic signature, the TSF must decrypt the electronic signature
using the public key of the user certificate and compare the operation result with the
cryptographic checksum (hash value), which was used as the initial value for signature
creation (comparison for mathematical correctness of the electronic signature).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 45
FDP_ITC.1 (2)
Import of user data without security attributes
FDP_ITC.1.1
The TSF shall enforce the [assignment: none] when importing user data, controlled under the
SFP, from outside of the TSC.
FDP_ITC.1.2
The TSF shall ignore any security attributes associated with user data when imported from
outside the TSC.
FDP_ITC.1.3
The TSF shall enforce the following rules when importing user data controlled under the SFP
from outside the TSC: [assignment: Rules for the usage of actual certificates from the
network].
Rules for the usage of actual certificates from the network
During the process of signature verification the TSF must use the available certificate
revocation lists to verify the validity of a given certificate at the time of signature creation.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 46
FDP_ITC.2 (1)
Import of user data with security attributes
FDP_ITC.2.1
The TSF shall enforce the [assignment: none] when importing user data, controlled under the
SFP, from outside of the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with user data when imported from
outside the TSC.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous association
between the security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the imported user data is
as intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data controlled under the SFP
from outside the TSC: [assignment: Rules for the Import of OCSP responses].
Rules for the Import of OCSP responses
The TSF must verify the validity of the signature on the OCSP response mathematically
before importing the OCSP response.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 47
FDP_ITC.2 (2)
Import of user data with security attributes
FDP_ITC.2.1
The TSF shall enforce the [assignment: none] when importing user data, controlled under the
SFP, from outside of the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with user data when imported from
outside the TSC.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous association
between the security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the imported user data is
as intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data controlled under the SFP
from outside the TSC: [assignment: Rules for the Import of timestamps].
Rules for the Import of timestamps
The TSF must verify the validity of the signature on the timestamp mathematically before
importing the timestamp.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 48
FTP_ITC.1
Inter-TSF trusted channel
FTP_ITC.1.1
The TSF shall provide a communication channel between itself and a remote trusted IT
product that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2
The TSF shall permit [selection: the TSF] to initiate communication via the trusted channel.
FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for [assignment: creation of an
electronic signature].
FMT_MOF.1(1)
Management of Security Functions Behaviour
FMT_MOF.1.1
The TSF shall restrict the ability to [selection: modify the behaviour of] the functions
[assignment: PDF displaying capabilities, signature creation capabilities] to [assignment:
none].
FMT_SMF.1(1)
Specification of Management Functions
FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions [
assignment: enabling of initiation of electronic signature creation, enabling of PDF displaying,
enabling PDF PKCS#7 formatted signing, enabling of PDF signing using PDF signatures].
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 49
FMT_MOF.1(2)
Management of Security Functions Behaviour
FMT_MOF.1.1
The TSF shall restrict the ability to [selection: modify the behaviour of] the functions
[assignment: changing the TOE’s licensed capabilities] to [assignment: user].
FMT_SMF.1(2)
Specification of Management Functions
FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions [
assignment: accept only equal or upgraded licensed functionality].
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 50
FDP_SVR.1
Secure Viewer
FDP_SVR.1.1
The TSF shall ensure, that the displayed content of a document is unambiguous according to
[assignment: TIFF Revision 6.0 final draft June 3, 1992, Adobe Developers Association, User
Guidance S-TRUST Sign-it base components 2.0, subset of PDF reference fifth edition
(Adobe Portable Document Format Version 1.6) ].
FDP_SVR.1.2
The TSF shall ensure, that the displayed content of a document is free of hidden and active
content. The TSF shall ensure, that the user is informed about hidden or active content.
FDP_SVR.1.3
The TSF shall ensure, that the user is informed about content that cannot be displayed.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 51
5.2 TOE Security Assurance Requirements
The following table offers an overview of the documents, which describe, how the
requirements are fulfilled. The assurance requirements are defined according to EAL4
augmented (Common Criteria part 3). All assurance requirements were taken from Common
Criteria part 3.
Class Family Document
ACM_CAP.4
ACM_SCP.2
Configuration Management
ACM_AUT.1
A configuration management system
is used to manage all versions of all
TOE parts. In addition to that task, the
configuration management system is
used to ensure, that no unauthorized
modifications on the TOE take place.
The configuration control system is
used to ensure, that each version of
the implementation, design, test and
documentation is logged.
Details are described in the document
“Configuration Management”, which is
part of the manufacturer
documentation for the evaluation.
ADO_DEL.2 This aspect is handled in the
document “Delivery Procedures”.
Delivery and Operation
ADO_IGS.1 These aspects are documented in the
user guide.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 52
ADV_FSP.2 This aspect is handled in the
document “Informal functional
specification” provided by the
manufacturer for the evaluation.
ADV_HLD.2 This aspect is handled in the
document “High Level Design”
provided by the manufacturer for the
evaluation.
ADV_IMP.1 The relevant source code is available
for the evaluation.
ADV_LLD.1
ADV_RCR.1
This aspect is handled in the
document “Low Level Design”
provided by the manufacturer for the
evaluation.
Development
ADV_SPM.1 This aspect is handled in the
document “Security Policy Model”
AGD_ADM.1
Guidance documents
AGD_USR.1
The user and developer guide for the
product is very detailed and provides
all required information for secure
installation, management and use.
ALC_DVS.1 The security of the development
environment is ensured through
physical and personnel activities.
ALC_LCD.1 This aspect is handled in the
document “Life Cycle Support”
Life Cycle Support
ALC_TAT.1 Well-defined tools (compilers etc.) are
used for the development of the TOE.
Details are documented in
“Configuration Management”, which is
part of the manufacturer
documentation for evaluation.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 53
ATE_COV.2
ATE_DPT.1
ATE_FUN.1
Well defined test procedures are used:
• Tests according to the
functional specification
• Tests on subsystem level
• Tests of all security functions
Tests
ATE_IND.2 This is the task of the evaluator.
AVA_MSU.3 An internal review process ensures,
that the documentation is clear,
consistent and reasonable.
AVA_VLA.4 For every mechanism, that has an
SOF postulation, an appropriate
analysis is done and documented.
Vulnerability assessment
AVA_SOF.1 An analysis with the scope to identify
vulnerabilities is done and
documented.
Table 1 Documentation Overview
5.3 Security Requirements for the IT-Environment
FCS_COP.1 (ES-1024 to 2048)28
Cryptographic Operation
FCS_COP.1.1
The TSF shall perform [assignment: computation of electronic signatures] in accordance with
specified cryptographic algorithm [assignment: RSA] and cryptographic key sizes
[assignment: 1024 to 2048 bits] that meet the following: [Standard: PKCS#1].
28
Iteration
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 54
6 TOE Summary Specification
6.1 TOE Security Functions
SF.1
Hash value computation and initiation of the electronic signature creation process using
certificates, smart-card terminals and secure signature creation devices.
The TOE computes hash values of any file or data buffer using the SHA algorithm family29
(as required by FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384),
FCS_COP.1(SHA-512), FCS_COP.1(160), standards are listed in SFR’s). After the hash
value computation, the TOE uses the PC/SC or CT API or a card terminal vendor specific
module to initiate the electronic signature creation by a secure signature creation system,
which consists of a smart-card terminal and a smart card. The electronic signature is
computed using the RSA algorithm, which is implemented as a part of the SSCD’s
functionality30
. The TOE adds the signer certificate to the resulting documents. Through the
electronic signature, the data authentication is ensured. Through the addition of the signer
certificate, the possibility of data verification is offered.
Before the computation of the hash value starts, the TOE displays an unambiguous
message, that electronic signatures should be created. It is unambiguous, to which data
each electronic signature refers. Through the combination of a secure pin entry device and a
smart card it is guaranteed that authorized persons only perform the electronic signature
creation and identification data is not abandoned.
The user has the possibility to include an OCSP response for the user certificate that is used
for the creation of the electronic signature into the resulting PKCS#7 encoded file or data
buffer.
29
The concrete SHA algorithm to be used can be set using the S-TRUST Sign-it Job Interface API. If
no algorithm identifier is set, SF.1 uses the SHA-1 hash algorithm as the default algorithm.
30
The encryption of the hash value is part of the security requirements for the IT-environment.
Algorithm and key size is specified in FCS_COP.1(ES-1024 to 2048).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 55
The TOE offers the possibility to add a timestamp into the PKCS#7 encoded file or data
buffer that is the output of this TSF.
The TOE offers the capability to create more than one electronic signature by the execution
of a special job via the OPENLiMiT® SignCubes Job Interface. This capability is not
accessible via the graphical interface of the TOE.
If the user configures the TOE to leave the card open, he is only one time requested to enter
PIN for the execution of that job. The configuration of the TOE is performed via a
configuration dialog offered by the S-TRUST Sign-it Security Environment Manager. This
dialog allows the differentiation between the time that the PIN is left open and the number of
electronic signatures to be created. The first criterion that is reached closes the PIN and the
user is required to enter the PIN again. The S-TRUST Sign-it Security Environment Manager
ensures that exactly the files presented by the signature creation dialog are signed. If the
creation of signatures is canceled by the user, all signature files created by this job are
deleted. In any case, it is ensured by the S-TRUST Sign-it base components 2.0 that the PIN
is closed when the job has been executed.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in conjunction with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 56
SF.2
Verification of hash values and electronic signatures using certificate revocation lists, OCSP
responses (optional) and timestamps (optional)
The TOE is able to verify electronic signatures that are based on a SHA-1, SHA-256, SHA-
384, SHA-512 or RIPE-MD 160 hash value. In this process it is unambiguous, to which data
the electronic signature refers. For the purpose of electronic signature verification, the hash
value of the signed data is computed, using the SHA algorithm family or the RIPE-MD 160
algorithm (FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384),
FCS_COP.1 (SHA-512) and FCS_COP.1(160)) and the original hash value extracted from
the signature using the RSA algorithm31
(FCS_COP.1 (RSA2-1024 to 2048)) and the public
key of the given signer certificate. In addition to this operation, the certificate chain is
checked, using the chain model or RFC 3280 (iteration of FCS_COP.1 (RSA2-1024 to
2048)).
The TOE displays an unambiguous message, whether the hash values were identical or not.
(FDP_DAU.2 with focus on FDP_DAU.2.2). Because of this, it is unambiguous, whether the
original data has changed or not. The correctness of the electronic signature is reliably
checked and displayed. Through the use of the S-TRUST Sign-it Viewer component it is
ensured, that the content of the signed data is unambiguously displayed.
The TOE offers the possibility to identify the user that has generated the electronic signature
based on the certificate that has been used. The user, who verifies the validity of the
electronic signature by using the TOE, has the possibility to view the certificate that has been
used for the generation of the electronic signature in an unambiguous way. This covers the
requirements defined by FDP_DAU.2, especially FDP_DAU.2.2.
31
In this process, the whole PKCS#1 block v.1.5 with padding type 02 is checked
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 57
During the verification process, the issuer of the signers certificate is determined and a
corresponding certificate revocation list is loaded. This revocation list is checked, if a
revocation entry for the signers certificate exists. If this is the case, this information is taken
(FDP_ITC.1 (2)). If the certificate was already revoked during the signature creation, this
information is displayed to the user.
In addition to the checking of the revocation list the user has the possibility to use an OCSP
response to verify the validity of a certificate under examination32
. The OCSP response may
be encoded in the PKCS#7 data under examination or is requested from an OCSP
responder using software modules that are not part of the evaluation.
Also the user has the possibility to use a given time stamp that is encoded in the PKCS#7
data as the point of time where the signature has been created. The time stamp may be part
of the PKCS#7 encoded data under examination or is presented to the TOE as a separate
file33
. The timestamp can be used by the TOE to provide validity information for the signature
under examination at the point of time that is specified by the timestamp.
The basic validity checking is always done using the time that is encoded in the PKCS#7
data block. This time is normally the system time when the signature has been created. If no
time of signature creation is available, the current system time is used as the point of time of
signature creation.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in alliance with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
32
SF.7 provides more information.
33
SF.8 provides more information.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 58
SF.3
Program module manipulation detection
The TOE is delivered with electronic signed libraries, files and executables. In order to
implement the required functionality of manipulation detection, a separate program module is
implemented as dynamic linked library (dll). All subsystems of the product know the SHA-512
hash value of this check module. The check module knows the public key, whose
counterpart (the private key) was used to sign the program libraries, files and executables.
If the S-TRUST Sign-it base components are started, the S-TRUST Sign-it Security
Environment Manager checks its environment using the check module. In step 1, the
Security Environment Managers validates the hash value of the check module (FCS_COP.1
(SHA-512)). In step 2, the check module verifies the application, which loads the check
module, by verifying the electronic signature of the loading application mathematically.
(FCS_COP.1 (SHA-512) and FCS_COP.1(RSA1-1024 to 2048)).
If a dynamic module should be loaded by the application, the check module is always used to
verify the integrity of the module to be loaded. Therefore the check module computes the
hash value of the module to be loaded and verifies the electronic signature of the module to
be loaded mathematically (FCS_COP.1 (SHA-512) and FCS_COP.1(RSA1-1024 to 2048)). If
the verification fails, the check module sends a signal to all program modules, which are now
deactivated. Using this mechanism, no security related operation could be performed using
the product.
All modules of the application know the hash value of the check module. If the hash value of
the check module cannot be validated (FCS_COP.1(SHA-512)), the modules can not longer
be used.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in alliance with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 59
SF.4
Unambiguous presentation of the data to be signed
The TOE ensures that the content of displayed document is unambiguous as required by
FDP_SVR.1.1. In addition to this, the user is informed, if the data contains hidden or active
content or content that cannot be displayed. (FDP_SVR.1.2 and FDP_SVR.1.3).
The file that should be signed must be a Text, Tiff or PDF34
formatted file. An appropriate
parser explores the type of the data. If the parser is unable to determine the type of the data
an appropriate error message is displayed that contains a hint that the data could not be
displayed as required by FDP_SVR.1. After this first operation the data is checked for hidden
and active content. If the file contains unknown tags, elements or control characters the user
is informed that the file may contain unintended content as required by FDP_SVR.1.2. If the
parser detects active or hidden content an appropriate message is displayed to the user that
informs him about this state as required by FDP_SVR.1.2 and FDP_SVR.1.3. If the user
wants to display the file and the file contains hidden content or content, that cannot be
displayed, a warning message is generated and displayed to the user.
Security function SF.4 does not contain permutational or probalistic mechanisms. Therefore
no strength of function is postulated.
34
The TOE does implement a subset of the PDF reference fifth edition. Not all requirements of this
reference have been implemented in order to fulfill the requirements of FDP_SVR.1. More information
is provided by the user guidance.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 60
SF.5
Protection against hash value manipulation
Before the process of electronic signature creation starts, the hash value using the SHA
algorithm family is used35
(FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-
384), FCS_COP.1(SHA-512)). Alternatively the RIPE-MD 160 algorithm may be used
(FCS_COP.1(160)). After the electronic signature creation process, the TOE verifies the
electronic signature using the public key of the given signer certificate (FDP_ITC.1(1) and
FCS_COP.1(RSA1-1024 to 2048)36
). If the original hash value and the hash value encoded
in the electronic signature are not identical, the hash value was corrupted during the
transmission to the secure signature creation device. After this operation, an unambiguous
message is displayed, if the correct data has been signed.
Through the comparison of the hash value that was meant to be used for the creation of the
electronic signature and the of the hash value that was used by the SSCD for the generation
of the electronic signature the requirements of FTP_ITC.1 are fulfilled.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in alliance with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
35
The hash algorithm to be used can be set using the S-TRUST Sign-it Job Interface API. If no hash
algorithm is set, the SHA-1 algorithm will be used by default.
36
The key size depends on the key size of the certificate that has been used for the creation of the
electronic signature.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 61
SF.6
Assurance of the TOE’s integrity
The integrity of the S-TRUST Sign-it base components 2.1 can be ensured by the user using
the check utility, which could be accessed online. This check utility is a Java Applet, which
ensures the integrity of the application by checking and comparing the SHA-1 hash values of
the program modules (FCS_COP.1 (SHA-1)). Therefore the hash values are known to the
Applet.
The Java Applet is a signed Java Archive (with the extension JAR), the integrity of the Applet
itself is ensured by the mechanisms of the Java Virtual Machine (JVM). Therefore the user is
required to install a Java Virtual Machine. The JVM must be at least compatible with the Java
Runtime Environment 1.4 from Sun.
The user must use a dialog to point to the current installation path of the product or uses the
installation directory detected by the S-TRUST Sign-it Integrity Tool from the registry. The
integrity check does not verify any registry entries.
The integrity check utility is aware of the root certificates contained in the certificate trust list,
which has initially been installed.
If the computed hash values and the expected hash values of the program modules are not
identical, an error message is generated and displayed to user in an unambiguous way. If no
differences in the configuration were detected, the check utility displays an unambiguous
dialog with an appropriate summary.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in alliance with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 62
SF.7
Processing of OCSP information for certificate validation
The TOE offers the possibility to process OCSP information in order to verify the validity of a
certificate. This certificate is called ‘certificate under examination’. In order to use the validity
information that is provided for the certificate under examination through the OCSP
response, the TOE is required to verify the electronic signature of that response.
The OCSP response might be part of a PKCS#7 encoded signature block, a plain file or is
received through an appropriate OCSP handler. In the process of OCSP response import the
TOE verifies the validity of the OCSP response through the mathematical verification of the
electronic signature that belongs to the OCSP response37
(FDP_ITC.2 (1)). Mathematical
verification means that the OCSP response must contain a signature from the certificate that
is included in the OCSP response as the OCSP response signing certificate and the
signature must be valid. During the import the TOE does not check the complete certificate
chain. The signature might be based on the same algorithms as specified in the next section
(FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-
512) and FCS_COP.1(160)) and (FCS_COP.1 (RSA1-1024 to 2048)). If the TOE is not able
to verify the signature, the OCSP response is not imported and an appropriate message is
displayed to the user. After the import process the TOE is also able to store the OCSP
response in a PKCS#7 encoded file or in a separate file.
37
The SFR’s that define the algorithms and key sizes are defined in the section below.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 63
When the TOE uses the OCSP information for certificate validation a complete verification of
the OCSP signature based on certificate revocation lists is required. The signature might be
based on a SHA-1, SHA-256, SHA-384, SHA-512 or RIPE-MD 160 hash value. For the
purpose of electronic signature verification, the hash value of the signed data is computed,
using the SHA algorithm family or the RIPE-MD 160 algorithm (FCS_COP.1 (SHA-1),
FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-512) and
FCS_COP.1(160)) and the original hash value extracted from the signature using the RSA
algorithm38
(FCS_COP.1 (RSA2-1024 to 2048)) and the public key of the OCSP response
signing certificate. In addition to this operation, the certificate chain for that OCSP signing
certificate is checked, using the chain model or RFC 3280 (iteration of FCS_COP.1 (RSA2-
1024 to 2048)) All certificates in the chain are checked for revocation information that is
provided by appropriate CRL’s (FDP_ITC.1(2)).
After the validation of the electronic signature the TOE displays an unambiguous dialog to
the user that informs him about the validity of the OCSP response and the validity
information for the certificate under examination extracted from that OCSP response. In
addition to that the TOE provides a second dialog that provides detailed information about
the content of the OCSP response, including the certificate that has signed the response
(FDP_DAU.2 with focus on FDP_DAU.2.2).
The validity information that is based on the OCSP response for the certificate under
examination might be used in the process of signature verification (SF.2) to determine the
validity of a certificate under examination.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in conjunction with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
38
In this process, the whole PKCS#1 block v.1.5 with padding type 02 is checked
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 64
SF.8
Application of Timestamps
The TOE offers the possibility to apply timestamps to files. Therefore an external timestamp
handler is used in order to receive the timestamp, the correctness of the timestamp itself is
ensured by the TOE.
In the process of timestamp import the TOE verifies the electronic signature of the timestamp
using the public key of the certificate that has signed the timestamp39
(FDP_ITC.2(2)). The
certificate must be known to the TOE in order to verify the signature, otherwise the TOE
would not import the timestamp40
.
The signature might be based on a SHA-1, SHA-256, SHA-384, SHA-512 or RIPE-MD 160
hash value. For the purpose of the mathematical validation, the hash value of the signed
data is computed, using the SHA algorithm family or the RIPE-MD 160 algorithm
(FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-
512) and FCS_COP.1(160)) and compared with the original hash value extracted from the
signature using the RSA algorithm41
(FCS_COP.1 (RSA1-1024 to 2048)) and the public key
of the timestamp signing certificate.
After importing the timestamp, the timestamp is applied42
to the file that has been chosen by
the user. Application means the encoding of the timestamp into an existing PKCS#7 encoded
file or the storage of the timestamp in a separate file.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in conjunction with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
39
Mathematical verification of the signature.
40
The certificate must be part of the PKD files that are located in the installation directory of the TOE
or must be located in the Operating Systems Certificate Store.
41
In this process, the whole PKCS#1 block v.1.5 with padding type 02 is checked
42
The timestamp can then be part of a PKCS#7 signature block or be a separate file that contains the
timestamp that has been received.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 65
SF.9
Validation of Timestamps
In the process of timestamp validation the TOE verifies the electronic signature of the
timestamp with the public key that has signed the timestamp. The certificate must be known
to the TOE in order to verify the signature, otherwise the TOE is unable to validate the
timestamp43
. The signature might be based on a SHA-1, SHA-256, SHA-384, SHA-512 or
RIPE-MD 160 hash value. For the purpose of the mathematical validation, the hash value of
the signed data is computed, using the SHA algorithm family or the RIPE-MD 160 algorithm
(FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-
512) and FCS_COP.1(160)) and compared with the original hash value extracted from the
signature using the RSA algorithm44
(FCS_COP.1 (RSA2-1024 to 2048)) and the public key
of the timestamp signing certificate. In addition to this operation, the certificate chain for that
timestamp signing certificate is checked, using the chain model or RFC 3280 (iteration of
FCS_COP.1 (RSA2-1024 to 2048)). All certificates in the certificate chain are checked for
revocation information provided by appropriate CRL’s (FDP_ITC.1(2)).
The result of the timestamp validation is displayed to user through a dialog that is provided
by the TOE. This dialog provides the information that is encoded in the timestamp and does
also provide the capability to display the certificate that signed the timestamp (FDP_DAU.2
with focus on FDP_DAU.2.2).
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in conjunction with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
43
The validation operation would be not be executed.
44
In this process, the whole PKCS#1 block v.1.5 with padding type 02 is checked
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 66
SF.10
Management of Security Functions depending on licenses
The TOE implements a licensing mechanism that allows the management of security
functionality in the product. (FMT_SMF.1(1))
Each time the TOE is started it validates its license. If no license file is found, the TOE
displays a dialog and requests the user to enter a license number that he received together
with the TOE’s setup routine. The license number encodes information about the product
capabilities under the aspect of PDF displaying and the ability to initiate the computation of
an electronic signature. The electronic signature initiation and PDF operating modes45
that
depend on the license are defined as following:
• Mode 1: No signature creation capabilities of the TOE, if the user does not have a
license code. The displaying of PDF documents is not allowed.
• Mode 2: No PDF displaying capabilities of the S-TRUST Sign-it Viewer. No
possibilities to create any kind of signature on PDF documents. The S-TRUST Sign-it
Viewer can be utilized to display Text and TIFF documents and to create PKCS#7
signatures on these document types.
• Mode 3: PDF displaying but no capabilities to create signatures on PDF documents
using the S-TRUST Sign-it Viewer. PKCS#7 and embedded PDF signatures on PDF
documents can be verified. The S-TRUST Sign-it Viewer can be utilized to display
Text and TIFF documents and to create PKCS#7 signatures on these document
types.
• Mode 4: PDF displaying and the capability to create attached and detached PKCS#7
signatures as well as the verification of these signatures using the S-TRUST Sign-it
Viewer46
. The S-TRUST Sign-it Viewer can be utilized to display Text and TIFF
documents and to create PKCS#7 signatures on these document types. The
capability to create PDF signatures is no enabled
45
The verification of a PDF signature is also an PDF operating mode.
46
Embedded PDF signatures can also be verified
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 67
• Mode 5: PDF displaying is enabled, the creation of PKCS#7 encoded and PDF
signatures for PDF documents is enabled as well as the verification of these
signature types. The S-TRUST Sign-it Viewer can be utilized to display Text and TIFF
documents and to create PKCS#7 signatures on these document types.
The following table provides a clear overview for the different license modes.
Mode Electronic Signature
Initiation via S-TRUST
Sign-it Viewer
Displayed
Document
Format
Possible Signature
Format to be
verified
Electronic Signature
Initiation via S-
TRUST Sign-it Job
Interface
1 No TIFF, Text PKCS#7 No
2 Yes (PKCS#7 encoded
only)
TIFF, Text PKCS#7 Yes
3 Yes (only PKCS#7
encoded for TIFF and
Text)
TIFF, Text,
PDF
PKCS#7 and PDF Yes
4 Yes (PKCS#7 encoded
only)
TIFF, Text,
PDF
PKCS#7 and PDF Yes
5 Yes, PDF and PKCS#7
signatures supported
TIFF, Text,
PDF
PKCS#7 and PDF Yes
Table 2 License Modes in S-TRUST Sign-it base components 2.1.4.1
The process of generating a license file is handled as following: If the user has entered the
license code, the TOE uses unambiguous hardware information47
and generates an SHA-1
hash value of this data (FCS_COP.1 (SHA-1)). After this operation the license code is taken
and encoded into an XML encoded file together with the hash value that has been computed.
This step is the generation of the license file. After the generation of the license file the TOE
displays an unambiguous dialog that informs the user that he is now required to create an
electronic signature on the license file. In the case of an already existing license file, the TOE
will only accept the license information that is equal or upgraded functionality
(FMT_MOF.1(2), FMT_SMF.1(2)).
47
The hard disks serial number connected to a logical drive.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 68
If the user has not entered a license code, the TOE extracts a license file that enables Mode
1. In this case the generation of an electronic signature is not required. This license file is
signed by OPENLiMiT SignCubes and uses no hardware binding, because for Mode 1 this
binding is not required48
.
After the hash value computation over the resulting license file, the TOE uses the PC/SC or
CT API or a card terminal vendor specific module to initiate the electronic signature creation
by a secure signature creation system, which consists of a smart-card terminal and a smart
card. The electronic signature is computed using the RSA algorithm, which is implemented
as a part of the SSCD’s functionality49
. The TOE adds the signer certificate to the resulting
document. Through the electronic signature, the data authentication is ensured. Through the
addition of the signer certificate, the possibility of data verification is offered and the evidence
of the user who has signed the license file is added (FDP_DAU.2 with focus on
FDP_DAU.2.2).
When the TOE is started the next time it verifies the licensing information together with the
binding on the hardware. Therefore the TOE verifies the electronic signature on the license
file with the public key that has been used for the generation of the electronic signature.
(FCS_COP.1(SHA-1) and FCS_COP.1(RSA1-1024 to 2048)). In conjunction with this
operation the TOE sets up the certificate chain up to a trusted certificate that must be located
in a certificate trust list file50
that contains all root and CA certificates that are trusted as
certificates for issuing user certificates to be accepted by the TOE. (FCS_COP.1(SHA-1),
FCS_COP.1(SHA-256), FCS_COP.1(SHA-384), FCS_COP.1(SHA-512), FCS_COP.1(160)
and FCS_COP.1(RSA1-1024 to 2048)).
After this operation the found licensing information is used to enable the capabilities that
have been defined to be manageable in the TOE (FMT_MOF.1(1)).
48
Otherwise the TOE would be required to generate a license file using private key material in a
PKCS#12 file.
49
The encryption of the hash value is part of the security requirements for the IT-environment.
Algorithm and key size is specified in FCS_COP.1(ES-1024 to 2048).
50
This certificate trust list file is also electronically signed with a key that is known to the TOE. This
key is an OPENLiMiT internal key and is only used for that purpose.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 69
The TOE offers an appropriate dialog that informs the user about:
• The licensed functionality
• The serial number
• The certificate that has been used to enable the license on the users computer
The same dialog provides the functionality to update the license by repeating the licensing
procedure of the TOE. In the case that the user has utilized license mode 1 and the user
repeats the licensing process or generates the license for the first time, the TOE allows the
creation of an electronic signature for that purpose.
The certificate that has been used for the creation of the electronic signature provides the
evidence of the user that has enabled the product features (FDP_DAU.2 with focus on
FDP_DAU.2.2).
The S-TRUST Sign-it Job Interface is allowed to utilize the TSF of the TOE, even if these
capabilities are not part of the users license. Therefore the TOE contains a certificate in its
resources51
that is used in this case to verify the electronic signature of that external module
(FCS_COP.1(SHA-1) in conjunction with FCS_COP.1(RSA1-1024 to 2048)). This external
module is not signed with the same key as the TOE.
All used mechanisms are of cryptographic nature. Therefore, no comment about the strength
of the mechanisms can be given. The used cryptographic mechanisms are identified as
usable according to §17 paragraph 1 to 3 SigG 22.05.2001 in conjunction with annex 1,
paragraph 1 no. 2 SigV 22.11.2001.
51
The certificate does only contain the public part. The private key material is located on an SSCD.
Through the electronic signature on the TOE’s binaries that also protects the TOE’s resource files it is
not possible to change this certificate without detection by the TOE.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 70
6.2 Assurance Measures
The chapter 5.2 contains a table, which lists all documents that describe the assurance
measures.
7 PP Claims
No PP Claim is given for the TOE.
7.1 PP Reference
N/A
7.2 PP Refinements
N/A
7.3 PP Additions
N/A
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 71
8 Rationale
8.1 Security Objectives Rationale
Threats, .
Assumptions
vs. Security
Objectives
OT.DAT
OT.SIG_DAT
OT.TOE
OT.PRE_SIG
OT.POST_SIG
OT.LIC
OE.Platform
OE.Personnel
OE.Network
OE.Access
OE.SIG_DAT
T.DAT x x x
T.SIG_DAT x
T.TOE x
T.PRE_SIG x
T.POST_SIG x
T.LIC x
A.Platform x
A.Personnel x
A.Network x
A.Access x
Table 3 Threats and Assumptions vs. Objectives
A.Personnel ensures, that the user and administration staff is reliable and trustworthy. In
addition, this assumption ensures, that the user validates the TOE’s integrity. The security
objective OE.Personnel defines the same requirements. Therefore it accomplishes the
requirement.
A.Platform ensures, that the operating system meets the requirements and all components
and installed software is trustworthy. The security objective OE.Platform defines the same
requirements. Therefore it accomplishes the requirement.
A.Network ensures, that no system services or components are compromised through
access from the Internet. This ensures the trustworthiness of the environment. OE.Network
defines the same requirements. Therefore it accomplishes the requirement.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 72
A.Access ensures, that the user has full control about data carriers and shared network
places. OE.Access defines the same requirements. Therefore it accomplishes the
requirements.
T.DAT defines the security threat, that an adversary manipulates a user file using any
mechanisms and the manipulation keeps undetected. OT.DAT defines as a security
objective, the hash value computation corresponding to a given file or data buffer.
OE.SIG_DAT ensures, that an electronic signature is computed on the basis of the
previously computed hash value. OT.SIG_DAT defines the security objective, that the TOE
shall offer the possibility, to detect the manipulation of the content of a file or data buffer. All
mechanisms together ensure that user is able to detect the manipulation of the content of a
file or data buffer. The combination of this three security objectives repel the security threat
completely.
T.SIG_DAT defines the security threat, that an adversary might manipulate a signed file and
manipulation might keep undetected. OT.SIG_DAT defines the security objective, that the
TOE shall detect the manipulation of a signed file. The security threat is repelled.
T.TOE defines the security threat, that an adversary might manipulate parts of the TOE and
the manipulations might keep undetected. OT.SIG_DAT defines the security objective, that
the TOE shall offer the possibility, to inform the user about corrupted TOE modules or data.
The security threat is repelled.
T.PRE_SIG defines the security threat, that an adversary might manipulate the content of a
file or data buffer, before the user decides to sign the file. OT.PRE_SIG ensures, that the file
or data buffer is displayed in a manner, that the user can identify the content of the given
data in an unambiguous way. The security threat is repelled.
T.POST_SIG defines the security threat, that an adversary might manipulate the hash value
after the users decision to sign the file. OT.POST_SIG ensures, that the user has the
possibility, to detect the manipulation of the hash value of a file or data buffer to be signed
after his decision to sign. The security threat is repelled.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 73
T.LIC defines the security threat that an adversary might manipulate the currently used
license and this manipulation is not detected. OT.LIC ensures the integrity of the license file
through hash values and electronic signatures. OT.LIC does also ensure that the TOE’s
capabilities can not be downgraded through the insertion of a license code that offers less
capabilities than the license code already entered by the user.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 74
8.2 Security Requirements Rationale
Security Objectives vs. Security
Requirements
OT.DAT
OT.SIG_DAT
OT.TOE
OT.PRE_SIG
OT.POST_SIG
OT.LIC
OE.SIG_DAT
FCS_COP.1 (SHA-1) x x x x
FCS_COP.1 (SHA-256) x x x x
FCS_COP.1 (SHA-384) x x x x
FCS_COP.1 (SHA-512) x x x x x
FCS_COP.1 (160) x x
FCS_COP.1 (RSA1-1024 to 2048) x x x
FCS_COP.1 (RSA2-1024 to 2048) x
FDP_DAU.2 x x x
FDP_ITC.1(1) x
FDP_ITC.1(2) x
FDP_ITC.2(1) x
FDP_ITC.2(2) x
FDP_SVR.1 x
FTP_ITC.1 x
FCS_COP.1 (ES-1024 to 2048) x x
FMT_MOF.1(1) x
FMT_SMF.1(1) x
FMT_MOF.1(2) x
FMT_SMF.1(2) x
Table 4 Security Objectives vs. Security Requirements
OE.SIG_DAT ensures, that the IT-environment provides functionalities for the encryption of
cryptographic check sums (hash values). The required encryption algorithm and key size is
specified by FCS_COP.1(ES-1024 to 2048).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 75
OT.DAT ensures, that the TOE provides functionalities to protect a user file against
manipulation through hash value computation. FDP_DAU.2, FCS_COP.1(SHA-1),
FCS_COP.1(SHA-256), FCS_COP.1(SHA-384) and FCS_COP.1(SHA-512 ) define the
required protection and the requirement of additional cryptographic functions: The file
protection is implemented through hash value computation.
OT.SIG_DAT ensures, that the user has the possibility to detect the manipulation of a signed
file. This is defined through security requirement FDP_DAU.2, especially FDP_DAU.2.2.
FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384), FCS_COP.1(SHA-
512), FCS_COP.1(160), FCS_COP.1(RSA2-1024 to 2048), FDP_ITC.1(2), FDP_ITC.2(1)
and FDP_ITC.2(2) define the requirement of additional cryptographic functions:
Implementation through hash value computation and decryption with imported key.
OT.TOE ensures, that the user has the possibility to detect manipulations of TOE
components or data. This is fulfilled by the security requirements FCS_COP.1(SHA-512) and
FCS_COP.1(RSA1-1024 to 2048).
OT.PRE_SIG ensures the unambiguous identification of the data to be signed by the user.
This requirement is fulfilled through FDP_SVR.1.
OT.POST_SIG ensures, that user has the possibility to identify, whether the hash value of
the data to be signed was manipulated or not after the electronic signature creation. This is
ensured by the security requirement FTP_ITC.1(1). FCS_COP.1(SHA-1), FCS_COP.1(SHA-
256), FCS_COP.1(SHA-384), FCS_COP.1(SHA-512), FCS_COP.1(RSA1-1024 to 2048) and
FDP_ITC.1(1) define the requirements of the additional cryptographic operations.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 76
OT.LIC ensures protection of the license files integrity through the use of has values and
electronic signatures (FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384),
FCS_COP.1(SHA-512), FCS_COP.1(160) in conjunction with FCS_COP.1(RSA1-1024 to
2048) and FCS_COP.1(ES-1024 to 2048) provide the cryptographic support that is required
to generate the signed license file. FCS_COP.1(SHA-1), FCS_COP.1(SHA-256),
FCS_COP.1(SHA-384), FCS_COP.1(SHA-512), FCS_COP.1(160) in conjunction with
FCS_COP.1(RSA1-1024 to 2048) are required to set up the certificate chain in the signature
verification process of the license file and are used to verify the integrity of the license file
before the license information is used (FMT_MOF.1(1) and FMT_SMF.1(1)).
FCS_COP.1(SHA-1) in conjunction with FCS_COP.1(RSA1-1024 to 2048) are used to
ensure the integrity of the resource file that contains the trusted root and CA certificates to be
used for setting up the certificate chain. FDP_DAU.2 provides the capability to inspect the
certificate that has been used to generate the signature on the license file. If a license file
does already exist and the process of license file generation is repeated, the TOE does only
accept license code that enable capabilities equal or upgraded to the current licensed
capabilities (FMT_MOF.1(2) and FMT_SMF.1(2)).
8.3 Dependency Rationale
The assurance requirements for the TOE were defined using EAL 4 augmented. The
augmentations are AVA_MSU.3 and AVA_VLA.4.
The dependencies of AVA_MSU.3 are resolved by ADO_IGS.1, ADV_FSP.1, AGD_ADM.1
and AGD_USR.1. The dependencies of AVA_VLA.4 are resolved by ADV_FSP.1,
ADV_HLD.2, ADV_IMP.1, ADV_LLD.1 and AGD_ADM.1. The dependencies of ADV_IMP.1
are resolved by ALC_TAT.1.
The dependencies of the security requirements cannot be resolved completely. The following
table gives an overview about the dependencies.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 77
Requirement Dependency Fulfilled
FCS_COP.1 (SHA-1)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FCS_COP.1 (SHA-
256)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FCS_COP.1 (SHA-
384)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FCS_COP.1 (SHA-
512)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FCS_COP.1(160)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FCS_COP.1(RSA1-
1024 to 2048)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
Yes, see explanation
below
FCS_COP.1(RSA2-
1024 to 2048)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
Yes, see explanation
below
FCS_COP.1(ES-
1024 to 2048)
[FDP_ITC.1 or FCS_CKM.1],
FCS_CKM.4 and FMT_MSA.2
No, see explanation below
FDP_DAU.2 FIA_UID.1 No, see explanation below
FDP_ITC.1(1)
[FDP_ACC.1 or FDP_IFC.1],
FMT_MSA.3
No, see explanation below
FDP_ITC.1(2)
[FDP_ACC.1 or FDP_IFC.1],
FMT_MSA.3
No, see explanation below
FDP_ITC.2(1)
[FDP_ACC.1 or FDP_IFC.1],
[FTP_ITC.1 or FTP_TRP.1],
FPT_TDC.1
No, see explanation below
FDP_ITC.2(2)
[FDP_ACC.1 or FDP_IFC.1],
[FTP_ITC.1 or FTP_TRP.1],
FPT_TDC.1
No, see explanation below
FDP_SVR.1 None Yes, implicit
FTP_ITC.1 None Yes, implicit
FMT_MOF.1(1) FMT_SMR.1 and FMT_SMF.1 In parts, not full
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 78
Requirement Dependency Fulfilled
FMT_SMF.1(1)
No dependencies Yes, because no
dependencies are defined
for that SFR.
FMT_MOF.1(2) FMT_SMR.1 and FMT_SMF.1 In parts, not full
FMT_SMF.1(2)
No dependencies Yes, because no
dependencies are defined
for that SFR.
Table 5 Dependencies of security requirements
FCS_COP.1 (SHA-1), FCS_COP.1 (SHA-256), FCS_COP.1 (SHA-384), FCS_COP.1 (SHA-
512) and FCS_COP.1 (160) require cryptographic operation of keyless hash algorithms.
Therefore FCS_CKM.1, FCS_CKM.4 and FMT_MSA.2 are not applicable.
FCS_COP.1(RSA1-1024 to 2048) and FCS_COP.1(RSA2-1024 to 2048) refer to
cryptographic operation with imported public keys. The dependency to import (FDP_ITC.1) is
resolved by FDP_ITC.1(1) and FDP_ITC.1(2). FCS_CKM.4 and FDP_MSA.2 are in the
context of the TOE not applicable.
FCS_COP.1 (ES-1024 to 2048) refer to the RSA algorithm, that is applied in the IT-
environment. The implementation of the dependencies is part of the environment and
therefore not specified in this document.
FDP_DAU.2 refers to data authentication. The identity of the user is recognized on the basis
of the certificates content. The certificate is provided by appropriate components (see
A.Platform). The component FIA_UID.1 is not applicable in the context of the TOE.
FDP_ITC.1(1) and FDP_ITC.1(2) refer to the use of public keys for electronic signature
verification (FCS_COP.1(RSA1-1024 to 2048) and FCS_COP.1(RSA2-1024 to 2048)). The
TOE must not protect the public keys. Therefore FDP_ACC.1 and FDP_IFC.1 are not
required to fulfil the TOE security requirements. The import is done without any attributes and
after the import no security attributes are initialised (FMT_MSA.3).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 79
FDP_ITC.2(1) refers to the import of an OCSP response to verify the validity of a user
certificate under examination. The OCSP response itself must not be protected by the TOE,
because the integrity of an OCSP response is protected by hash values and electronic
signatures that offer the required level of protection. Therefore FDP_ACC.1 and FDP_IFC.1
are not required to fulfil the TOE security requirements. FTP_ITC.1 and FTP_TRP.1 are not
required, because the TOE verifies the complete certificate chain using CRL’s before using
the OCSP information and the root certificate is a trusted certificate for the TOE. Through this
mechanism the manipulation of data’s integrity is prevented. FPT_TDC.1 refers to TSF data
exchange in a distributed or composite system environment where the TOE exchanges such
data with another trusted IT product. This is not applicable in the context of the TOE.
FDP_ITC.2(2) refers to the import of timestamps. The timestamp itself must not be protected
by the TOE, because timestamps are protected by hash values and electronic signatures
that offer the required level of protection. Therefore FDP_ACC.1 and FDP_IFC.1 are not
required to fulfil the TOE security requirements. FTP_ITC.1 and FTP_TRP.1 are not
required, because the TOE verifies the complete certificate chain using CRL’s before using
the timestamp information and the root certificate is a trusted certificate for the TOE. Through
this mechanism the manipulation of data’s integrity is prevented. FPT_TDC.1 refers to TSF
data exchange in a distributed or composite system environment where the TOE exchanges
such data with another trusted IT product. This is not applicable in the context of the TOE.
FMT_MOF.1(1) and FMT_MOF.1(2) do refer to the management of security functions
behaviour in the TOE. The mechanisms that are implemented by the TOE in order to
manage the behaviour do depend on the licensing mechanism of the TOE and are
independent from any security roles. The TOE does not assign different roles to users,
therefore FMT_SMR.1 is not applicable in the context of the TOE. FMT_SMF.1(1) and
FMT_SMF.1(2) are explicit SFR’s of the TOE, the dependency is therefore fulfilled.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 80
8.4 Rationale on mutual support
FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384), FCS_COP.1(SHA-
512), FCS_COP.1(160) and FCS_COP.1(ES-1024 to 2048) support each other during the
process of signature creation. FCS_COP.1(SHA-XXX)52
as well as FCS_COP.1(160)
compute the hash value and FCS_COP.1(ES-1024 to 2048) applies the required RSA
algorithm. Those security requirements support the fulfilment of FDP_DAU.2. FDP_SVR.1 is
responsible for the unambiguous display of the data. FTP_ITC.1 ensures the correctness of
the hash value to be encrypted with the previously computed hash value (FCS_COP.1(SHA-
1)).
FCS_COP.1(160), FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384),
FCS_COP.1(SHA-512) and FCS_COP.1(RSA1-1024 to 2048) support each other in the
process of signature verification. Those requirements support the fulfilment of FDP_DAU.2,
especially FDP_DAU.2.2. FCS_COP.1(160), FCS_COP.1(SHA-XXX)53
do the hash value
computation and FCS_COP.1(RSA.1-1024 to 2048) decrypts the hash value for the hash
value comparison. The key is provided by FDP_ITC.1(1). Additional OCSP information is
provided by FDP_ITC.2(1) and a timestamp is provided by FDP_ITC.2(2). The content of the
document, which refers to the electronic signature, is displayed by FDP_SVR.1.
FCS_COP.1(SHA-1), FCS_COP.1(SHA-256), FCS_COP.1(SHA-384), FCS_COP.1(SHA-
512), FCS_COP(160) and FCS_COP.1(RSA2-1024 to 2048) support each other in the
process of signature verification. FCS_COP.1(SHA-XXX)54
, alternatively FCS_COP.1(160)
computes the hash value and FCS_COP.1(RSA2-1024 to 2048) decrypts the hash value
from the original electronic signature for comparison. The key is provided by FDP_ITC.1(2),
an OCSP response is provided by FDP_ITC.2(1) and a timestamp is provided by
FDP_ITC.2(2).
52
FCS_COP.1(SHA-1) or FCS_COP.1(SHA-256) or FCS_COP.1(SHA-384) or FCS_COP.1(SHA-512)
53
FCS_COP.1(SHA-1) or FCS_COP.1(SHA-256) or FCS_COP.1(SHA-384) or FCS_COP.1(SHA-512)
54
FCS_COP.1(SHA-1) or FCS_COP.1(SHA-256) or FCS_COP.1(SHA-384) or FCS_COP.1(SHA-512)
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 81
FCS_COP.1(SHA-1), FDP_ITC.1(1) and FCS_COP.1(RSA1-1024 to 2048) support each
other in the implementation of the licensing mechanism of the TOE and do therefore support
FMT_MOF.1(1), FMT_MOF.1(2), FMT_SMF(1) and FMT_SMF.1(2). FCS_COP.1(SHA-1) is
used to compute hash values, FCS_COP.1(RSA1-1024 to 2048) is required to verify the
mathematical correctness of the electronic signature on the license file. The key is provided
by FDP_TC.1(1).
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 82
8.5 Rationale on assurance requirements, EAL4+ and SOF-high
The discussed application is a signature application component in the sense of §17
paragraph 2 of the German signature law. For the process of evaluation with Common
Criteria the evaluation assurance level EAL 3 with augmentations is required for such
components. The ordinance on the signature law (SigV) requires AVA_VLA.4, which requires
SOF-high.
The vendor of the product S-TRUST Sign-it base components 2.1.4.1 has chosen the
evaluation assurance level EAL 4 with augmentations. This ensures, that the requirements
defined by the signature law and the ordinance on electronic signatures are met by the
product.
In addition to those facts, the SigV requires a complete misuse analysis, which explains the
choice of AVA_MSU.3.
The manufacturer did not identify any additional dependencies according to the chosen
evaluation level.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 83
8.6 Rationale on TOE specification
The specification of the TOE security functions refers directly to the TOE security
requirements. The following table displays the correlation between security requirements and
security functions.
Security Requirements vs. Security
Functions
SF.1
SF.2
SF.3
SF.4
SF.5
SF.6
SF.7
SF.8
SF.9
SF.10
FCS_COP.1 (SHA-1) x x x x x x x x
FCS_COP.1 (SHA-256) x x x x x x x
FCS_COP.1 (SHA-384) x x x x x x x
FCS_COP.1 (SHA-512) x x x x x x x x
FCS_COP.1 (160) x x x x x x x
FCS_COP.1 (RSA1-1024 to 2048) x x x x x
FCS_COP.1 (RSA2-1024 to 2048) x x x
FDP_DAU.2 x x x x
FDP_ITC.1(1) x
FDP_ITC.1(2) x x x
FDP_ITC.2(1) x
FDP_ITC.2(2) x
FDP_SVR.1 x
FTP_ITC.1 x
FMT_MOF.1(1) x
FMT_SMF.1(1) x
FMT_MOF.1(2) x
FMT_SMF.1(2) x
Table 6 Security Requirements vs. Security Functions
The security requirement FCS_COP.1(ES-1024 to 2048) is part of the IT-Environment of the
TOE and therefore not listed here.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 84
9 Definition of functional family FDP_SVR
On order to define the IT-security requirements of the TOE completely, an additional
functional family (FDP_SVR) of class FDP (user data protection) is defined. This family
describes the functional requirements for a secure viewer component of a signature
application component.
Due to the complexity of a legal binding viewer component as required by the signature law
this component could not be modelled from the components that are provided by the
Common Criteria framework. Therefore the introduction of a separate functional family is
necessary that covers the requirements to describe the TOE consistently as needed for a
confirmation that is based on the results of the Common Criteria evaluation.
FDP_SVR Secure Viewer
Family behaviour
This family defines the functional requirements to a secure viewer component for electronic
signature applications. Electronic signature applications require a viewer component, which
ensures, that the displayed data is unambiguous. The user must be informed about content,
that may not be displayed but the electronic signature will refer to.
Component levelling
1
FDP_SVR Secure Viewer
FDP_SVR.1 Secure Viewer requires the TSF to offer the ability to display the documents
content in an unambiguous way, that is free of hidden content. In addition, the ability to
inform the user about hidden content is required.
Management : FDP_SVR.1
For this component no management activities are foreseen.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 85
Audit: FDP_SVR.1
No actions are identified, that should be logged, if FAU_GEN is part of the PP/ST.
FDP_SVR.1 Secure Viewer
Hierarchical to: No other components
FDP_SVR.1.1 The TSF shall ensure, that the displayed content of a document is
unambiguous according to [assignment: norms for displaying content].
FDP_SVR.1.2 The TSF shall ensure, that the displayed content of a document is free
of active or hidden content. The TSF shall ensure that the user is
informed about hidden content.
FDP_SVR.1.3 The TSF shall ensure, that the user is informed about content, that
cannot be displayed.
Dependencies: No dependencies identified.
The assurance requirements that have been defined by the Common Criteria v2.1 Part 3 are
applicable to the functional family FDP_SVR. This functional family has been defined to meet
the requirements of the a secure viewer component in a signature application component.
Because this component is a software component with a well defined behaviour on its
external interfaces, the assurance requirements that have been defined in part 3 of Common
Criteria are applicable to this functional family.
Through its nature as a software component the assurance classes ACM, ADO, ADV, AGD,
ALC, ATE and AVA are applicable in the evaluation process. It is not required to define a
new assurance class or assurance family for a consistent and complete description to cover
this SFR. This SFR does not define any behaviour that might require an extension of Part 3
of the Common Criteria Evaluation Framework.
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 86
Documents
[1] Acrobat Digital Signature API Reference, Technical Note #5192, Adobe Systems
Incorporated
[2] Gesetz über die Rahmenbedingungen für elektronische Signaturen,
Fundstelle: BGBI I 2001, 876, 16.05.2001
[3] Verordnung zur elektronischen Signatur, Fundstelle: BGBI 2001, 3074, 16.11.2001
[4] Law Governing Framework Conditions for Electronic Signatures and Amending Other
Regulations, unofficial version for industry consultation
[5] Ordinance on Electronic Signatures, unofficial working translation
[6] Directive 1999/93/EC of the European Parliament and of the Council of 13 December
1999 on a Community framework for electronic signatures
[7] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction
and general model, August 1999, Version 2.1, CCIMB-99-031
[8] Common Criteria for Information Technology Security Evaluation, Part 2: Security
functional requirements, August 1999, Version 2.1, CCIMB-99-032
[9] Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance requirements, August 1999, Version 2.1, CCIMB-99-033
[10] IT Sicherheit auf Basis der Common Criteria – ein Leitfaden, Hrsg: Bundesamt für
Sicherheit in der Informationstechnik der Bundesrepublik Deutschland
[11] Secure Hash Standard, Federal Information Processing Standards Publication
180 – 2, announced 2002 August 1 (FIPS PUB 180-2)
[12] RIPEMD-160: A Strengthened Version of RIPMD, published by German Information
Security Agency and Katholieke Universiteit Leuven, announced 18 April 1996
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 87
[13] Maßnahmenkatalog für technische Komponenten nach dem Signaturgesetz,
announced 15.07.1998 by German RegTP
[14] Einheitliche Spezifizierung der Einsatzbedingungen für
Signaturanwendungskomponenten Version 1.0, announced 30.01.2002
[15] RFC 3447 – Public Key Cryptography Standards (PKCS) #1, RSA Cryptography
Specifications Version 2.1, announced by The Internet Society
[16] User documentation S-TRUST Sign-it base components 2.0.4.1
[17] Geeignete Algorithmen zur Erfüllung der Anforderungen nach §17 Abs.1 bis 3 SigG
vom 22.Mai 2001 in Verbindung mit Anlage 1 Abschnitt 1 Nr. 2 SigV vom 22.11.2001
Mainz, 2003
[18] RFC 3161 – Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),
announced by The Internet Society
[19] RFC 2560 – X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol (OCSP), announced by The Internet Society
[20] RFC 3280 – Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, announced by The Internet Society
[21] RFC 2315 – PKCS#7: Cryptographic Message Syntax Version 1.5, announced in
March 1998 by The Internet Society
[22] RFC 3778 – The application/pdf media type, announced May 2004 by The Internet
Society
[23] Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der
Signaturverordnung, announced by the German Regulierungsbehörde für
Telekommunikation und Post, 02.01.2004
Security Target (ST) S-TRUST Sign-it base components 2.1, Version 2.1.4.1
Page 88
[24] Developer documentation S-TRUST Sign-it base components 2.0.4.1
[25] CWA 14170:2004 CEN Workshop Agreement, Security requirements for signature
creation applications
[26] PKCS#1 v2.1: RSA Cryptography Standard, published by RSA Laboratories June 14,
2002
[27] PDF Reference fifth edition, Adobe Portable Document Format Version 1.6, Adobe
Systems Incorporated