prEN 419111-2

SLOVENSKI STANDARD
01-julij-2013
=DãþLWQLSURILOL]DXSRUDERSULREOLNRYDQMXLQSUHYHUMDQMXSRGSLVRY$SOLNDFLMD
REOLNRYDQMDSRGSLVDGHO-HGUQL33
Protection profiles for signature creation and verification application - Signature creation
application - Part 2: Core PP
Schutzprofile für eine Anwendung zum Erzeugen und Prüfen von Signaturen - Signatur
Kreation Anwendung - Teil 2: Core PP
Profils de protection pour application de création et de vérification de signature -
Application de création de signature - Partie 2: Profils PP de base
Ta slovenski standard je istoveten z: prEN 419111-2
ICS:
35.240.15 Identifikacijske kartice in Identification cards and
sorodne naprave related devices
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
DRAFT
NORME EUROPÉENNE
EUROPÄISCHE NORM
February 2013
ICS 35.240.15 Will supersede CWA 14170:2004
English Version
Protection profiles for signature creation and verification
application - Signature creation application - Part 2: Core PP
Profils de protection pour application de création et de Schutzprofile für eine Anwendung zum Erzeugen und
vérification de signature - Application de création de Prüfen von Signaturen - Signatur Kreation Anwendung -
signature - Partie 2: Profils PP de base Teil 2: Core PP
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 224.

If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other language
made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2013 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 419111-2:2013: E
worldwide for CEN national Members.

Contents Page
Foreword .5
1 Scope .6
2 Normative references .6
3 Terms and definitions .6
4 Symbols and abbreviations .6
5 TOE overview .7
5.1 TOE Type .7
5.2 TOE Usage .7
5.3 TOE Environment.7
5.3.1 Overview .7
5.3.2 External entities .8
5.3.3 Other Entities .8
5.4 TOE operations .8
5.4.1 Introduction .8
5.4.2 Pre-signature operations .8
5.4.3 Signature computation .8
5.5 TOE-environment operations .9
6 Conformance claims .9
6.1 CC Conformance Claim .9
6.2 PP Claim .9
6.3 Package Claim .9
6.4 Conformance Rationale .9
6.5 Conformance Statement .9
7 Security problem definition . 10
7.1 Assets . 10
7.1.1 Document . 10
7.1.2 Certificate . 10
7.1.3 Certificate path . 10
7.1.4 Signature policy . 10
7.1.5 Signature attribute . 10
7.2 Threats . 10
7.2.1 T.Document . 10
7.2.2 T.Signature_Policy. 10
7.2.3 T.Certificate . 11
7.2.4 T.Signer_consent . 11
7.2.5 T.Digital_Signature . 11
7.3 Organisational security policies . 11
7.4 Assumptions . 11
7.4.1 A.Platform . 11
7.4.2 A.SSCD . 12
7.4.3 A.Signer . 12
7.4.4 A.CSP . 12
8 Security objectives . 12
8.1 Security objectives for the TOE . 12
8.1.1 OT.Signer_Control . 12
8.1.2 OT.Document . 12
8.1.3 OT.Certificate . 12
8.1.4 OT.Signature_Attributes . 13
8.1.5 OT.Signature_Policy . 13
8.1.6 OT.Crypto . 13
8.1.7 OT.Sig_Verify . 13
8.2 Security objectives for the operational environment . 13
8.2.1 OE.Platform . 13
8.2.2 OE.SSCD. 14
8.2.3 OE.SSCD_communication_protected . 14
8.2.4 OE.Signer_Presence . 14
8.2.5 OE.Output_Device . 14
8.2.6 OE.Checker . 14
8.2.7 OE.Signer . 14
8.2.8 OE.CSP . 15
8.3 Rationale for Security objectives . 15
9 Extended component definition . 16
10 Security requirements . 16
10.1 General . 16
10.2 Security requirements for the TOE . 17
10.2.1 Introduction . 17
10.3 Security assurance requirements for the TOE . 35
10.4 Security Requirement rationales . 36
10.4.1 Security Functional Requirement rationale . 36
10.4.2 Rationale for SFR Dependencies . 38
10.4.3 Security Assurance Requirements Rationale . 40
10.4.4 Security requirements – internal consistency . 40
Bibliography . 41
Index . 42

Figures
Figure 1 — TOE environment . 7

Tables
Table 1 — Rationale for security objectives . 15
Table 2 — Subject security attributes . 17
Table 3 — Object security attributes . 17
Table 4 — Operations - attributes conditions and modifications . 18
Table 5 — Protection of sensitive data . 21
Table 6 — Signature SFP – Objects and Operations . 23
Table 7 — Signature SFP – subjects, objects and attributes . 24
Table 8 — Signature operation rules . 24
Table 9 — SSCD IFF Operations . 25
Table 10 — Driving Application IFF Operations . 25
Table 11 — Checker IFF Operations . 26
Table 12 — Input device IFF Operations . 26
Table 13 — Output device IFF Operations . 26
Table 14 — SSCD IFF Operations & attributes . 27
Table 15 — SSCD IFF Operations & conditions . 27
Table 16 — Driving Application IFF Operations & attributes . 27
Table 17 — Driving Application IFF Operations & conditions . 28
Table 18 — Checker IFF Operations & attributes . 28
Table 19 — Checker IFF Operations & conditions . 28
Table 20 — Input device IFF Operations & attributes . 29
Table 21 — Input device IFF Operations & conditions . 29
Table 22 — Output device IFF Operations & attributes . 30
Table 23 — Output device IFF Operations & conditions . 30
Table 24 — TOE SAR . 35
Table 25 — SFR vs Objectives on the TOE . 36
Table 26 — SFR dependencies . 38

Foreword
This document (prEN 419111-2:2013) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat of
which is held by AFNOR.
This document is currently submitted to the CEN Enquiry.
This document, together with prEN 419111-1:2013 and prEN 419111-3:2013, will supersede
CWA 14170:2004.
EN 419111 consists of the following parts under the general title "Protection profiles for signature creation and
verification application":
 Part 1: Introduction.
This part is an introduction to EN 419111;
 Part 2: Signature creation application – Core PP.
This part is a PP for the SCA, specifying only the core security functions;
 Part 3: Signature creation application – Possible extensions.
This part specifies possible additional security functions that can be added to the core SCA PP;
 Part 4: Signature verification application – Core PP.
This part is a PP for the SVA, specifying only the core security functions;
 Part 5: Signature verification application – Possible extensions.
This part specifies possible additional security functions that can be added to the core SVA PP.
1 Scope
This document is a Protection Profile that defines the security requirements for a Signature Creation
Application. This is the core document, which means that only the security functions that are mandatory are
included. The ST writer can include other security functions in his TOE. For this purpose, he can include some
of those described in prEN 419111-3:2013 [2].
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
prEN 419111-1:2013, Protection profiles for signature creation and verification application – Part 1:
Introduction
prEN 14169-1:2011, Protection profiles for secure signature creation device – Part 1: Overview
FprEN 14169-2:2013, Protection profiles for secure signature creation device – Part 2: Device with key
generation
prEN 14169-3:2010, Protection profiles for secure signature creation device – Part 3: Device with key import
prEN 14169-4:2010, Protection profiles for secure signature creation device – Part 4: Extension for device
with key generation and trusted communication with certificate generation application
prEN 14169-5:2010, Protection profiles for secure signature creation device – Part 5: Device with key
generation and trusted communication with signature-creation application
prEN 14169-6:2010, Protection profiles for secure signature creation device – Part 6: Device with key import
and trusted communication with signature-creation application
[NR1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general
model – July 2009 – Version 3.1 Rev. 3 CCMB-2009-07-001
[NR2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional
components – July 2009 – Version 3.1 Rev. 3 CCMB-2009-07-002
[NR3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance
components – July 2009 – Version 3.1 Rev. 3 CCMB-2009-07-003
[NR4] Common Criteria for Information Technology Security Evaluation – Evaluation methodology – July
2009 – Version 3.1 Rev. 3 CCMB-2009-07-004
3 Terms and definitions
For the purposes of this document, the terms and definitions given in prEN 419111-1:2013 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in prEN 419111-1:2013 apply.
5 TOE overview
5.1 TOE Type
This PP aims at defining security requirements that an SCA shall conform to in the perspective of a security
evaluation. The Target of Evaluation (TOE) considered in this PP corresponds to software, running on an
operating system and hardware, the SCP. The TOE, using services provided by the SCP and by an SSCD
allows the signatory to generate an electronic signature.
This TOE is the minimum configuration for an SCA. Many features that belong to the environment in this TOE
could be added inside the TOE as suggested in prEN 419111-1:2013.
5.2 TOE Usage
The TOE, connected to an SSCD, enables to create electronic signature conformant to Directive 1999/93/EC
[1].
5.3 TOE Environment
5.3.1 Overview
Figure 1 — TOE environment
The environment displayed in Figure 1 — TOE environment is given as an example.
5.3.2 External entities
The following entities are external entities of the TOE. They are connected to the TOE.
 SSCD
 Driving Application
 OS
 Input device
 Output device
A brief description of these external entities is given in prEN 419111-1:2013, 5.6.2.
5.3.3 Other Entities
The following entities are not directly external entities of the TOE, because they are not connected to the TOE,
but to external entities of the TOE.
 CSP
 PIN pad or Bio pad
 Interface device
A brief description of these entities is given in prEN 419111-1:2013, 5.6.3.
5.4 TOE operations
5.4.1 Introduction
This section describes operations that are performed in the TOE.
5.4.2 Pre-signature operations
These operations include:
 SD Selection and import
 Invoking SD checker
 Signatory's intent to sign
 Collection of other information
They are described in prEN 419111-1:2013, 5.7.2.2.
5.4.3 Signature computation
Signature computation includes:
 DTBSR Composer
 Management of SSCD interface
 Digital Signature integrity verification
 SDO composer
These operations are described in prEN 419111-1:2013, 5.7.2.3.
5.5 TOE-environment operations
These operations include:
 Checker
 Certificate management
 Signature Policy management
 Sensitive data exchange with SSCD
They are described in prEN 419111-1:2013, 5.7.3.
TOE-environment operations also include:
• Get information/commands from input device
• Send SD / attributes to output device
They are described in prEN 419111-1:2013, 5.7.4.
6 Conformance claims
6.1 CC Conformance Claim
This Protection Profile (PP) is CC Part 2 extended and CC Part 3 conformant and written according to the
Common Criteria version 3.1R3 ([NR1], [NR2], [NR3], and [NR4]).
6.2 PP Claim
This PP does not claim conformance to any other Protection Profile.
6.3 Package Claim
The evaluation assurance level for this PP is EAL4 augmented with the assurance component ALC_FLR.1.
CEN/TC 224 note: Different countries currently use different levels of EAL. So national bodies are requested
to explicitly comment on this choice.
6.4 Conformance Rationale
Since this PP is not claiming conformance to any other protection profile, no rationale is necessary here.
6.5 Conformance Statement
The conformance required by this PP is the demonstrable-PP conformance. This will facilitate conformance
claim to both this PP and other PP for Security Target (ST) authors.
7 Security problem definition
7.1 Assets
7.1.1 Document
The document that is to be signed is one asset that has to be protected in integrity. It is present in the TOE
under the following forms:
 SD Signer’s Document
 DTBS Data To Be Signed
 DTBSR Data To Be Signed Representation
 DTBSR_DS Data To Be Signed Representation Digital Signature
 SDO Signed Data Object, computed according to the SP and other data selected by the signer.
7.1.2 Certificate
The certificate needs to be protected in integrity.
7.1.3 Certificate path
The certificate path needs to be protected in integrity.
7.1.4 Signature policy
The signature policy needs to be protected in integrity.
7.1.5 Signature attribute
The signature attributes need to be protected in integrity.
7.2 Threats
7.2.1 T.Document
Any data originally intended by the End-User to be signed are modified by an attacker after they are under
TOE control. This manipulation can be done on the document under different forms: SD, DTBS, DTBSR, and
DTBSR_DS.
The document may be in a format allowing ambiguous interpretations.
It may contain information that the signer is not aware of.
The document may differ from what the signer expects.
7.2.2 T.Signature_Policy
The Signature Policy can be modified by an attacker, e.g. by removing or modifying a signature attribute.
The signer can mistakenly select a security policy after being fooled by an attacker.
This threatens the SDO as it will be computed according to a wrong SP.
7.2.3 T.Certificate
An attacker may modify the certificate reference selected by the signer, such that the DTBSR does not contain
the right reference.
This threatens the SDO as it will be computed using a wrong certificate.
7.2.4 T.Signer_consent
An attacker may try to bypass the signer’s consent.
This threatens the SDO as it will be computed using data not selected by the legitimate signer.
7.2.5 T.Digital_Signature
An attacker may try to modify the DTBSR_DS, during its import from the SSCD or when it is in the TOE.
This threatens the SDO as it will be computed using data not selected by the legitimate signer.
7.3 Organisational security policies
OSP.Crypto
The cryptographic algorithms used on the TOE shall conform to the rules established by the relevant CC
certification body.
7.4 Assumptions
7.4.1 A.Platform
The TOE is installed on a personal computer located in an admission restricted area ensuring that those
resources the TOE is relying on cannot be manipulated without user notification.
It is assumed that the host platform on which the TOE is installed is either directly under the responsibility of
the signer or under the control of the organisation to which the signer belongs or of which he is the customer.
The operation system of the host platform is supposed to provide low-level communication interface to the
following external interfaces:
 SSCD
 Input device
 Output device.
The operation system of the host platform is supposed to provide separate execution contexts for the various
processes executed.
In addition, it is assumed that the following security measures are implemented:
• the host platform is protected from the viruses;
• the data exchange between the host platform and other IT elements via an open network are controlled by
a firewall;
• the access to the administration functions of the host platform is restricted to the administrators of the
platform (thereinafter the “Host administrator”). The user account is different from the host administrator
account;
• the installation and the update of the software of the host platform is under the control of the host
administrator;
• the operating system of the host platform does not allow the execution of untrusted applications.
7.4.2 A.SSCD
It is assumed that the SSCD is certified as an SSCD according to one PP defined in prEN 14169-1:2011,
FprEN 14169-2:2013, prEN 14169-3:2010, prEN 14169-4:2010, prEN 14169-5:2010 and prEN 14169-6:2010.
7.4.3 A.Signer
It is assumed that Signers, the end-users of the TOE are trustworthy and follow the instructions of the
guidance delivered with the TOE.
7.4.4 A.CSP
It is assumed that the SCA uses only qualified certificates (see Directive 1999/93/EC, Article 2:9 and
Annexes I & II [1]) or non-qualified certificates issued by trustworthy CSP.
8 Security objectives
8.1 Security objectives for the TOE
8.1.1 OT.Signer_Control
The TOE shall provide the signer with means to explicitly express (i.e., in a voluntary and non-ambiguous
way) its agreement to select documents, certificate, signature policy, and to start the process of signature.
The TOE shall provide the signer with means to cancel the signature process at any step until the validation of
the SDO by the signer. If the signer cancels the signature process, the TOE shall provide means to prevent
the use of the DTBSR_DS.
8.1.2 OT.Document
The TOE shall protect user data from undetected manipulation as long as these data are under control of the
TOE itself.
After the signer’s agreement for signature, the TOE shall guarantee that the actually processed documents
correspond exactly to the documents selected to be signed.
8.1.3 OT.Certificate
The TOE shall check that the certificate selected by the signer is compliant with the signature policy to be
applied.
The TOE shall control that the certificate selected by the signer is used during its validity period.
The TOE shall transfer the necessary information to the SSCD so that it can activate the private key
corresponding to the selected certificate.
8.1.4 OT.Signature_Attributes
The TOE shall present to the signer an exact representation of the attributes that will be signed.
The TOE shall control the presence and the compliance of the signature attributes selected by the signer with
the signature policy to be applied.
If the signer gives his agreement for several documents, the signature attributes used for the signature of
each document shall be identical.
8.1.5 OT.Signature_Policy
The TOE shall compute the SDO according to the SP.
The TOE shall protect SP from undetected manipulation as long as it is under control of the TOE itself.
8.1.6 OT.Crypto
The TOE shall implement cryptographic algorithms having the following properties:
The hash algorithms shall not allow the creation of two documents producing the same hash.
The algorithms shall conform to the relevant Certification Body cryptography requirements.
8.1.7 OT.Sig_Verify
The TOE shall be capable to state whether the DTBSR_DS provided by the SSCD is valid or not.
8.2 Security objectives for the operational environment
8.2.1 OE.Platform
The host platform, on which the TOE is installed, shall be located in an admission restricted area ensuring that
those resources the TOE is relying on cannot be manipulated without user notification.
The host platform, on which the TOE is installed, shall be either directly under the responsibility of the signer
or under the control of the organisation to which the signer belongs or of which he is the customer.
The operation system of the host platform shall provide low-level communication interface to the following
external interfaces:
 SSCD
 Input device
 Output device.
The operation system of the host platform shall provide separate execution contexts for the various processes
executed.
In addition, the following security measures shall be implemented:
• the host platform shall be protected from the viruses;
• the data exchange between the host platform and other IT elements via an open network shall be
controlled by a firewall;
• the access to the administration functions of the host platform shall be restricted to the administrators of
the platform (thereinafter the “Host administrator”). The user account shall be different from the host
administrator account;
• the installation and the update of the software of the host platform shall be under the control of the host
administrator;
• the operating system of the host platform shall not allow the execution of untrusted applications.
8.2.2 OE.SSCD
The SSCD shall be a certified SSCD, according to prEN 14169-1:2011, FprEN 14169-2:2013,
prEN 14169-3:2010, prEN 14169-4:2010, prEN 14169-5:2010 and prEN 14169-6:2010.
It shall contain at least one SCD.
If several SCD are available, the SSCD shall provide a means to select one, and to link it to the certificate
selected by the Signer.
8.2.3 OE.SSCD_communication_protected
The environment between the SCA and SSCD shall be protected so that no sensitive data can be leaked or
be corrupted by an attacker during it transfer between SCA and SSCD.
8.2.4 OE.Signer_Presence
The signer shall remain present between the moments when he agrees to sign the documents and when he
enters his authentication data to activate the key of signature.
Application note
If for any reason the signer cannot remain present, he shall start again the process from the beginning:
selection of the documents to be signed, selection of the attributes, etc.
8.2.5 OE.Output_Device
The host platform on which the TOE is installed shall have output device applications which:
 either accurately display the document to be signed,
 or warn the signer of possible problems of incompatibilities between the output device application and the
characteristics of the document.
In case the document to be signed already contains signatures, the signer shall have a means to know the
identity of previous signers and to verify these signatures.
8.2.6 OE.Checker
The environment of the TOE shall provide a module able to determine if the semantics of the document to be
signed is conformant to the rules defined for the determined format.
8.2.7 OE.Signer
The Signers, the end-users of the TOE shall be trustworthy and follow the instructions of the guidance
delivered with the TOE.
8.2.8 OE.CSP
The certificates, whether qualified or non-qualified shall be issued by trustworthy CSP.
8.3 Rationale for Security objectives
Table 1 — Rationale for security objectives

T.Document X X  X X X X
T.Signature_Policy  X X X   X
T.Certificate X     X
T.Digital_Signature    X  X  X X
T.Signer_consent   X X X  X
OSP.Crypto X
A.CSP     X
A.Platform      X
A.Signer      X
A.SSCD       X
T.Document is countered by the following objectives:
The modification of the document is countered by
• OT.Document that ensures the integrity of the document, and
• OE.Platform that ensures the integrity of data and applications stored on the SCP and that provide
cryptographic algorithms support this integrity protection.
Ambiguous interpretations and hidden information are countered by
• OE.Checker that checks the semantic of the SDO, and
• OE.Output_Device that displays the SDO with the result of the checker to the signer.
Signing a different the document than the signer wants to sign is countered by
• OT.Signer_Control that requires approval of selected SP by the signer, and
• OT.Crypto that prevents an attacker from generating a document that would accept the same
signature.
T.Signature_Policy is countered by the following objectives:
The modification of the SP is countered by
• OT.Signature_Policy that ensures the integrity of the SP, and
• OT.Signature_Attributes that ensures the integrity of the attributes,
• OE.Platform that ensures the integrity of data and applications stored on the SCP and that provide
cryptographic algorithms support this integrity protection.
Using a different SP than the signer wants to use is countered by
OT.Certificate
OT.Crypto
OT.Document
OT.Signature_Attributes
OT.Signature_Policy
OT.Signer_Control
OT.Sig_Verify
OE.Checker
OE.CSP
OE.Output_Device
OE.Platform
OE.Signer
OE.Signer_Presence
OE.SSCD
OE.SSCD_communication_protected

• OT.Signer_Control that requires approval of selected SP by the signer.

T.Certificate is countered by:
The modification of the certificate is countered by
• OT.Certificate that ensures the integrity of the certificate,
• OE.Platform that ensures the integrity of data and applications stored on the SCP and that provide
cryptographic algorithms support this integrity protection.

T.Digital_Signature is countered by:
The modification of the DTBSR_DS is countered by
• OT.Sig_Verify that ensures the signature was generated with the private key corresponding to the
signing certificate,
• OE.Platform that ensures the integrity of data and applications stored on the SCP and that provide
cryptographic algorithms support this integrity protection.
• OE.SSCD that ensures that the SSCD is a certified one.
• OE.SSCD_communication_protected that ensures the integrity of data transferred between the
TOE and the SSCD
T.Signer_consent is countered by:
• OT.Signer_Control, OE.Output_Device, and OE.Checker that ensure that the signer can correctly
see what he signs
• OE.Signer_Presence that prevents the signing process without the attendance of the signer

OSP.Crypto is enforced by:
• OT.Crypto that requires the use cryptographic algorithms that resist high potential attacks

A.CSP is covered by:
• OE.CSP that fully covers this assumption.

A.Platform is covered by:
• OE.Platform that fully covers this assumption.

A.Signer is covered by:
• OE.Signer that fully covers this assumption.

A.SSCD is covered by:
• OE.SSCD that fully covers this assumption.

9 Extended component definition
There is none.
10 Security requirements
10.1 General
This section describes the operations and requirements that a TOE shall fulfil in order to be compliant to this
PP.
10.2 Security requirements for the TOE
10.2.1 Introduction
10.2.1.1 Subjects Objects and security attributes
10.2.1.1.1 Subjects
Table 2 — Subject security attributes
Subject Security attribute Possible Values Initial Value
AT.Authenticated Yes, No No
S.Signer
AT.Crediential Null, CredentialValue Null

10.2.1.1.2 Objects / Information
Table 3 — Object security attributes
Objects Attribute Possible Values default
O.SVD AT.Status Null, Extracted Null
AT.Status Null, Imported, OnCheck, Checked, Displayed, Null
SignerDecided
AT.CheckerStatus Null, OK, NOK Null
AT.SignerDecision Null, Approved, Rejected Null
O.SD
AT.CheckerOptional Boolean No
AT.OutputOptional Boolean No
AT.Digest Null, digest value Null
AT.Status Null, Imported, Verified, Displayed, SignerDecided, Null
AT.Validity Null, Valid, OutOfDate, Revocated, Inconclusive Null
AT.CompatibleSP Null, Compatible, Incompatible Null
O.Certificate AT.SignerDecision Null, Approved, Rejected Null
AT.Identifier Null, Identifier value Null
AT.Signing Null, Yes, No Null
AT.Root Null, Yes, No Null
AT.Status Null, Imported, Verified, Displayed, SignerDecided Null
O.SP AT.Validity Null, Valid, Invalid Null
AT.SignerDecision Null, Approved, Rejected Null
O.DTBS AT.Status Null, Computed Null
AT.Status Null, Computed, Displayed, SignerDecided, Exported Null
O.DTBSR
AT.SignerDecision Null, Approved, Rejected Null
AT.Status Null, Imported, Verified Null
O.DTBSR_DS
AT.VerifyStatus Null, OK, NOK Null
AT.Status Null, Computed, Displayed, SignerDecided, Exported Null
O.SDO
AT.SignerDecision Null, Approved, Rejected Null

10.2.1.2 Operations
10.2.1.2.1 Summary
Table 4 — Operations - attributes conditions and modifications summarises the operations performed by the TOE. It gives the pre-conditions and the post
conditions defined with attribute values.
Table 4 — Operations - attributes conditions and modifications
Object/ Operations Conditions Attribute modification
Row
Information
1. AT.Crediential[S.Signer] Import Credential from Input AT.Authenticated[S.Signer] == No AND AT.Crediential [S.Signer] = CredentialValue
device
AT.Crediential[S.Signer] == Null
2. AT.Crediential[S.Signer] Check Credential AT.Authenticated[S.Signer] == No AND AT.Authenticated[S.Signer] = Yes/No
AT.Crediential[S.Signer] == CredentialValue AT.Crediential[S.Signer] = Null
3. O.Certificate Import from Driving Application AT.Authenticated[S.Signer] == true AT.Status[O.Certificate] = Imported
OR AT.Validity[O.Certificate] = Null
Import from SSCD AT.CompatibleSP[O.Certificate] = Null
AT.Identifier[O.Certificate] = Null
AT.SignerDecision[O.Certificate] = Null
AT.Signing[O.Certificate] = Null
AT.Root[O.Certificate] = Null
4. O.Certificate Verify validity AT.Status[O.Certificate] == Imported AT.Status[O.Certificate] = Verified
AT.Validity[O.Certificate] =
Valid/OutOfDate/Inconclusive
AT.Root[O.Certificate] = Yes/No
5. O.Certificate Verify compatibility O.Certificate AT.Status[O.Certificate] == Imported AND AT.CompatibleSP[O.Certificate] =
vs. O.SP Compatible/Incompatible
AT.Status[O.SP] == Imported
6. O.Certificate Export to Output device AT.Status[O.Certificate] == Verified AT.Status[O.Certificate] = Displayed
Object/ Operations Conditions Attribute modification
Row
Information
7. O.Certificate Import Approval from Input device AT.Status[O.Certificate] == Displayed AT.Status[O.
...