prEN 419111-4

Protection profiles for signature creation and verification application - Signature verification application - Part 4: Core PP

This document is a Protection Profile that defines the security requirements for a Signature Verification Application.

Schutzprofile zur Signatur Kreation Anwendung - Signatur Verifikation Anwendung - Teil 4: Core PP

Profils de protection pour application de création et de vérification de signature - Application de vérification de signature - Partie 4: Profils PP de base

Le présent document est un profil de protection qui définit les exigences de sécurité applicables à une application de création de signature.

Zaščitni profili za uporabo pri oblikovanju in preverjanju podpisov - Aplikacija preverjanja podpisa - 4. del: Jedrni PP

General Information

• Status: Not Published
• Publication Date: 07-Dec-2014
• Withdrawal Date: 07-Jun-2015
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: CEN/TC 224 - Machine-readable cards, related device interfaces and operations
• Drafting Committee: CEN/TC 224/WG 17 - Protection Profiles in the context of SSCD
• Current Stage: 4098 - Decision to abandon - Enquiry
• Start Date: 24-Jan-2018
• Completion Date: 14-Apr-2025
• Mandate: M/460 - Standardisation Mandate to the European Standardisation Organizations CEN, CENELEC and ETSI in the field of Information and Communication Technologies applied to Electronic Signatures
• Ref Project: oSIST prEN 419111-4:2013 - Protection profiles for signature creation and verification application - Signature verification application - Part 4: Core PP

Standards Content (Sample)

SLOVENSKI STANDARD
01-april-2013
=DãþLWQLSURILOL]DXSRUDERSULREOLNRYDQMXLQSUHYHUMDQMXSRGSLVRY$SOLNDFLMD
SUHYHUMDQMDSRGSLVDGHO-HGUQL33
Protection profiles for signature creation and verification application - Signature
verification application - Part 4: Core PP
Schutzprofile zur Signatur Kreation Anwendung - Signatur Verifikation Anwendung - Teil
4: Core PP
Profils de protection pour application de création et de vérification de signature -
Application de vérification de signature - Partie 4: Profils PP de base
Ta slovenski standard je istoveten z: prEN 419111-4
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 14171:2004
English Version
Protection profiles for signature creation and verification
application - Signature verification application - Part 4: Core PP
Profils de protection pour application de création et de Schutzprofile zur Signatur Kreation Anwendung - Signatur
vérification de signature - Application de vérification de Verifikation Anwendung - Teil 4: Core PP
signature - Partie 4: Profils PP de base
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-4: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 .6
5.1 TOE Type .6
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-validation operations .8
5.4.3 Validation operations .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 Validation status . 10
7.1.2 Document . 10
7.1.3 Signing certificate . 10
7.1.4 Root certificate . 10
7.1.5 Certification path . 10
7.1.6 Signature policy . 10
7.1.7 Signature attribute . 10
7.2 Threats . 11
7.2.1 T.Document . 11
7.2.2 T.SignaturePolicy. 11
7.2.3 T.Certificate . 11
7.2.4 T.RootCertificate . 11
7.3 Organisational security policies . 11
7.4 Assumptions . 11
7.4.1 A.Platform . 11
7.4.2 A.Verifier . 12
8 Security objectives . 12
8.1 Security objectives for the TOE . 12
8.1.1 OT.Certificate . 12
8.1.2 OT.Certification_Path_Validation . 12
8.1.3 OT.Crypto . 12
8.1.4 OT.Document . 12
8.1.5 OT.Root_Certificate . 12
8.1.6 OT.Signature_Policy . 12
8.2 Security objectives for the operational environment . 13
8.2.1 OE.Checker . 13
8.2.2 OE.Output_Device . 13
8.2.3 OE.Platform . 13
8.2.4 OE.Root_Certificate . 13
8.2.5 OE.Verifier . 13
8.3 Rationale for Security objectives . 14
9 Extended component definition . 15
10 Security requirements . 15
10.1 Introduction . 15
10.1.1 Subjects Objects and security attributes . 15
10.1.2 Operations . 17
10.2 Security functional requirements . 20
10.2.1 Security functional requirements for the TOE . 20
10.3 Security assurance requirements . 31
10.4 Requirement rationales . 32
10.4.1 SFR / Security objectives. 32
10.4.2 SFR Dependencies . 33
10.4.3 Rationale for the Assurance Requirements. 35
10.4.4 SAR Dependencies . 35
Bibliography . 37
Index . 38

Figures
Figure 1 — Core SVA environment . 7

Tables
Table 1 — Rationale for security objectives . 14
Table 2 — Subject security attributes . 15
Table 3 — Object security attributes . 16
Table 4 — Operations — attributes conditions and modifications . 17
Table 5 — protection of sensitive data . 20
Table 6 — Validation SFP – Objects and Operations . 21
Table 7 — Validation SFP – Objects and Attributes . 22
Table 8 — Verification operation rules . 23
Table 9 — Checker IFF Operations . 24
Table 10 — Driving application IFF Operations . 24
Table 11 — Input device IFF Operations . 24
Table 12 — Output device IFF Operations . 24
Table 13 — Driving application IFF Operations & attributes . 25
Table 14 . 25
Table 15 — Checker IFF Operations & attributes . 25
Table 16 — Checker IO rules . 26
Table 17 — Input device Operations & attributes . 26
Table 18 — Input device IO rules . 26
Table 19 — Output device Operations & attributes . 27
Table 20 — Output device operation rules . 27
Table 21 — TOE SAR . 31
Table 22 — SFR vs Objectives on the TOE . 32
Table 23 — SFR Dependencies . 33
Table 24 — SAR dependencies . 35

Foreword
This document (prEN 419111-4: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-5:2013, will supersede CWA 14171: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 Verification
Application.
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
[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 SVA 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 enables the verifier
to verify an electronic signature.
This TOE is the minimum configuration for an SVA. 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 enables to verify electronic signatures.
Verifying an electronic signature means checking an SDO and the corresponding document in order to
determine if the signature is
1) valid,
2) invalid,
3) indeterminate: the SVA is unable to issue a valid or invalid status.
5.3 TOE Environment
5.3.1 Overview
Figure 1 — Core SVA environment

Figure 1 — Core SVA environment is an illustration of what the environment of the SVA looks like. Its is
provided as a help to understand this environment. It is not a mandated configuration.
5.3.2 External entities
The following entities are external entities of the TOE. They are connected to the TOE.
 driving application
 OS
 input device
 output device
A brief description of these external entities is given in prEN 419111-1:2013, 6.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
 Attribute Authority
A brief description of these entities is given in prEN 419111-1:2013, 6.6.3.
5.4 TOE operations
5.4.1 Introduction
This section describes operations that are performed in the TOE or in its environment.
5.4.2 Pre-validation operations
These operations include:
 SDO (& SD) Selection and import
 Invoking SD checker
 Certificate Selection and import
 Signature policy selection and import
They are described in prEN 419111-1:2013, 6.7.2.2.
5.4.3 Validation operations
These operations include
 Extraction of data items from SDO (see prEN 419111-1:2013, 6.7.2.3),
 Certification path validation, (see prEN 419111-1:2013, 6.7.2.4),
 Cryptographic signature verification, (see prEN 419111-1:2013, 6.7.2.5),
 Verify other validation constraints, (see prEN 419111-1:2013, 6.7.2.6),
 Add Time stamp attribute, (see prEN 419111-1:2013, 6.7.2.7).
5.5 TOE-environment operations
These operations include:
 Checker
 Certificate management
 Signature Policy management
They are described in prEN 419111-1:2013, 6.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, 6.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 Validation status
The validation status, and its determination according to the SP selected by the verifier is the main asset of
this PP.
The validation status and the process to determine it shall be protected in integrity.
7.1.2 Document
The document whose signature is to be verified is one asset that has to be protected in integrity. It is present
in the TOE under the following forms:
 SDO Signed Data Object
 SD Signer’s Document
 DTBSR Data To Be Signed Representation
 DTBSR_DS DTBSR Digital Signature
7.1.3 Signing certificate
The signing certificate needs to be protected in integrity. This can be achieved using the signature that it
contains.
7.1.4 Root certificate
The root certificate is a certificate trusted by the SVA. It contains the root public key for the validation of the
certification chain.
There may be more than one root certificate.
It shall be protected in integrity.
7.1.5 Certification path
The certification path is the set of certificates or certificate identifiers, signing one another, starting from a root
certificate and ending with the signing certificate.
It needs to be protected in integrity.
7.1.6 Signature policy
The signature policy needs to be protected in integrity.
7.1.7 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 verified are modified by an attacker after they are under
TOE control. This manipulation can be done on the document under different forms: SDO, SD, DTBS,
DTBSR.
7.2.2 T.SignaturePolicy
The Signature Policy can be modified by an attacker, e.g. by removing or modifying a signature attribute.
The verifier can mistakenly select a security policy after being fooled by an attacker.
7.2.3 T.Certificate
The Certificate can be modified by an attacker.
The signing certificate may have been provided by an untrusted provider.
7.2.4 T.RootCertificate
The root certificate can be modified by an attacker.
The root certificate may become obsolete.
All the above threats can lead to wrong the validation data.
7.3 Organisational security policies
OSP.Crypto
The cryptographic algorithms used on the TOE shall conform to the rules established by the relevant
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 verifier or under the control of the organisation to which the verifier 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:
 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 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.Verifier
It is assumed that Verifiers, the end-users of the TOE are trustworthy and follow the instructions of the
guidance delivered with the TOE.
8 Security objectives
8.1 Security objectives for the TOE
8.1.1 OT.Certificate
The TOE shall check that the signing certificate selected by the verifier is compliant with the applied signature
policy.
The TOE shall control that the certificate selected by the verifier was used during its validity period.
8.1.2 OT.Certification_Path_Validation
The TSF shall provide means to verify the certification path from the signing certificate to a root certificate.
8.1.3 OT.Crypto
The TOE shall implement cryptographic algorithms having that conform to the relevant Certification Body
cryptography requirements.
8.1.4 OT.Document
The TOE shall protect user data from undetected manipulation as long as these data are under control of the
TOE itself.
8.1.5 OT.Root_Certificate
The TSF shall protect the integrity of the root certificate.
8.1.6 OT.Signature_Policy
The TOE shall present to the verifier an exact representation of the signature attributes.
The TOE shall control the presence and the compliance of the signature attributes with the signature policy.
8.2 Security objectives for the operational environment
8.2.1 OE.Checker
The environment of the TOE shall provide a module able to determine if the semantics of the document,
whose SDO to be verified, is conformant to the rules defined for the determined format.
8.2.2 OE.Output_Device
The host platform on which the TOE is installed shall have viewer applications which:
 either accurately display the document to be signed,
 or warn the verifier of possible problems of incompatibilities between the viewer application and the
characteristics of the document.
8.2.3 OE.Platform
The host platform on which the TOE is installed shall be protected against known security attacks.
Its administrator shall be competent.
It shall ensure that only the Verifier has access to the SVA.
It shall provide secure cryptographic and communication support to the SVA.
8.2.4 OE.Root_Certificate
The Verifier or the Administrator shall make sure that there is always at least one valid root certificate.
8.2.5 OE.Verifier
The Verifiers, the end-users of the TOE shall be trustworthy and follow the instructions of the guidance
delivered with the TOE.
8.3 Rationale for Security objectives
Table 1 — Rationale for security objectives

T.Certificate X X  X  X X
T.Document  X X  X X X
T.Signature_Policy  X  X X X
T. Root_Certificate   X
OSP.Crypto  X
A.Platform     X
A.Verifier      X
T.Certificate is countered by:
• OT.Certificate, OT.Root_Certificate, and OT.Certification_Path_Validation that ensure the
integrity and the validity of the certificate,
• OE.Root_Certificate that ensures the presence of at least one root 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.Document is countered by the following objectives:
The modification of the document is countered by
• OT.Document that ensures the integrity of the document,
• OE.Platform that ensures the integrity of data and applications stored on the SVP and that provide
cryptographic algorithms to support this integrity protection.
Ambiguous interpretations and hidden information in the SDO to be verified are countered by
• OE.Checker and OE.Output_Device, that check the semantic of SDO and displays the result to the
verifier and
• OT.Signature_Policy and OT.Crypto that prevent an attacker from generating a document that
would accept the same signature.

T.Signature_Policy is countered by:
The modification of the SP is countered by
• OT.Signature_Policy that ensures the integrity of the SP,
• 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 verifier wants to use is countered by OE.Output_Device.

T. Root_Certificate is countered by:
• OT.Root_Certificate that ensures the integrity and the validity of the certificate,

OT.Certificate
OT.Certification_Path_Validation
OT.Crypto
OT.Document
OT.Root_Certificate
OT.Signature_Policy
OE.Checker
OE.Ourput_Device
OE.Platform
OE.Root_Certificate
OE.Verifier
OSP.Crypto is enforced by:
• OT.Crypto that requires the use cryptographic algorithms that resist high potential attacks

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

A.Verifier is covered by:
• OE.Verifier that fully covers this assumption.
9 Extended component definition
There is none.
10 Security requirements
10.1 Introduction
10.1.1 Subjects Objects and security attributes
Table 2 — Subject security attributes
Subject Security attribute Possible Values Initial Value
S.Verifier AT.Authenticated Yes, No No

Table 3 — Object security attributes
Objects Attribute Possible values Initial
value
AT.Status, Null, Imported, VerifierDecided, Split, Verified Null
AT.VerifierDecision Null, Approved, Rejected Null
O.SDO AT.Verification Null, Valid, other status Null
AT.Digest Null, Computed Null
AT.DigestValue Null, value Null
AT.Status Null, Extracted, Checked Null
O.SD AT.CheckerOptional Boolean No
AT.Value Null, value Null
O.SVD AT.Status Null, Extracted Null
AT.Status Null, Imported, Verified, VerifierDecided, ExportedCRL, Null
AT.VerifierDecision Null, Approved, Rejected Null
AT.Validity Null, OutOfDate, Revocated Null
AT.CompatibleSP Null, Compatible, Incompatible Null
O.Certificate AT.Identifier Null, IdentifierValue Null
AT.Signing Boolean No
AT.Root Boolean No
AT.CertificateValue Null, value Null
AT.RevocationData Null, value Null
AT.Status Null, UnderConstruction, Constructed Null
AT.Validity Null, Valid, Invalid, Inconclusive Null
O.CertificationPath
AT.CertificateValue Null, value Null
AT.RevocationData Null, value Null
O.Signature Policy AT.Status Null, Imported, Approved, Verified, Incompatible Null
O.DTBS AT.Status Null, Extracted Null
O.DTBSR AT.Status Null, Computed Null
AT.Status Null, Extracted, VerifiedOK, VerifiedKO Null
O.DTBSR_DS
AT.Value Null, value Null
AT.Value Null, Date&Time Null
O.ValidationTime
10.1.2 Operations
10.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.Verifier] Import Credential from Input AT.Authenticated[S.Verifier] == No AND AT.Crediential [S.Verifier] = CredentialValue
device
AT.Crediential[S.Verifier] == Null
2. AT.Crediential[S.Verifier] Check Credential AT.Authenticated[S.Verifier] == No AND AT.Authenticated[S.Verifier] = Yes/No
AT.Crediential[S.Verifier] == CredentialValue AT.Crediential[S.Verifier] = Null
3. O.Certificate Import from Driving AT.Authenticated[S.Verifier] == Yes AT.Status[O.Certificate] = Imported
application
AT.Validity[O.Certificate] = Null
AT.CompatibleSP[O.Certificate] = Null
AT.Identifier[O.Certificate] = Null
AT.VerifierDecision[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/Revocated
AT.Root[O.Certificate] = Yes/No
5. O.Certificate Verify compatibility AT.Status[O.Certificate] == Verified AND AT.CompatibleSP[O.Certificate] =
O.Certificate vs. O.SP Compatible/Incompatible
AT.Status[O.SP] == Imported
6. O.Certificate Export to Output device AT.Status[O.Certificate] == Verified AND AT.Status[O.Certificate] = VerifierDecided
AT.Signing[O.Certificate] == Yes AT.VerifierDecision[O.Certificate] =
Approved/Rejected
7. O.Certificate Import Approval from Input AT.Status[O.Certificate] == Displayed AT.Status[O.Certificate] = Approved
device
Object/ Operations Conditions Attribute modification
Row
Information
8. O.Certificate Export to CRL AT.Status[O.Certificate] == Approved AT.Status[O.Certificate] = VerifierDecided
AT.VerifierDecision[O.Certificate] =
Approved/Rejected
9. O.Certificate Import revocation data AT.Status[O.Certificate] == ExportedCRL AT.Validity [O.Certificate] = Recocated
AT.Validity [O.CertificatePath] =
Valid/Invalid/Inconclusive
10. O.Certificate Compute identifier AT.Status[O.Certificate] == Imported AT.Identifier[O.Certificate] = value
11. O.Certificate Extract SVD AT.Status[O.Certificate] == VerifierDecided AND AT.Status[O.SVD] = Extracted
AT.VerifierDecision[O.Certificate] = Approved
12. O.CertificationPath Add Certificate AT.Status[O.Certificate] == Verified AT.CertificationValue[O.CertificationPath]+=
AT.CertificationValue [O.Certificate] |
AT.Identifier[O.Certificate]
AT.RevocationData[O.CertificationPath]+=
AT.RevocationData[O.Certificate]
If AT.Root[O.Certificate] == Yes then
AT.Status[O.CertificationPath] = Constructed
13. O.CertificationPath Export to Output device AT.Status[O.CertificationPath] == Verified AT.Status[O.CertificationPath] = Displayed
14. O.CertificationPath Import Approval from Input AT.Status[O.CertificationPath] == Displayed
device
15. O.SP Import from Driving AT.Authenticated[S.Verifier] == Yes AT.Status[O.SP] = Imported
application
AT.Validity[O.SP] = Null
16. O.SP Verify validity AT.Status[O.SP] == Imported AT.Status[O.SP] = Verified
AT.Validity[O.SP] = Valid/Invalid
17. O.SP Export to Output device AT.Status[O.SP] == Verified AT.Status[O.SP] = Displayed
18. O.SP Import Approval from Input AT.Status[O.SP] == Displayed AT.Status[O.SP] = VerifierDecided
device
AT.VerifierDecision[O.SP] = Approved/Rejected
19. O.SDO Import from Driving AT.Authenticated[S.Verifier] == Yes AT.Status[O.SDO] = Imported
application
AT.VerifierDecision[O.SDO] = Null
20. O.SDO Export to Output device AT.Status[O.SDO] == Imported AT.Status[O.SDO] = Displayed
21. O.SDO Import Approval from Input AT.Status[O.SDO] == Displayed AT.Status[O.SDO] = VerifierDecided
device
AT.VerifierDecision[O.SDO] = Approved/Rejected
Object/ Operations Conditions Attribute modification
Row
Information
22. O.SDO Extract components AT.Status[O.SDO] == VerifierDecided AND AT.Status[O.SDO] = Split
AT.VerifierDecision[O.SDO] = Approved AT.Identifier[O.Certificate] = signing certificate
identifier
AT.Status[O.SD] = Extracted
AT.Status[O.DTBS] = Extracted
AT.Status[O.DTBSR_DS] = Extracted
AT.Digest[O.SD] = value
23. O.SD Export to checker AT.Status[O.SD] == Extracted AND AT.Status[O.SD] = OnCheck
AT.CheckerOptional[O.SD] == No
24. AT.CheckerStatus[O.SD] Import status from Checker AT.Status[O.SD] == OnCheck AT.Status[O.SD] = Checked
AT.CheckerStatus[O.SD] = OK/NOK
25. O.SD Export to Output device AT.Status[O.SD] == Checked OR AT.Status[O.SD] = Displayed
AT.CheckerOptional[O.SD] == Yes
26. O.SD Import Approval from Input AT.Status[O.SD] == Displayed AT.Status[O.SD] = VerifierDecided
device
AT.VerifierDecision[O.SD] = Approved/Rejected
27. O.ValidationTime Import validation time from AT.Value[O.ValidationTime] == Null AT.Value[O.ValidationTime] = Date&Time
Input device
28. O.DTBSR Compute AT.Status[O.DTBS] == Extracted AT.Status[O.DTBSR] = Computed
29. O.DTBSR_DS Extract from SDO AT.Status[O.DTBSR] == Extracted AT.Status[O.DTBSR_DS] = Extracted
30. O.DTBSR_DS Verify cryptographically AT.Status[O.DTBSR] == Extracted AND AT.Status[O.SDO] = Verified
AT.Status[O.DTBSR_DS] == Extracted AND AT.VerifyOK[O.DTBSR_DS] = Yes or No
AT.Status[O.SVD] = Extracted
31. AT.Verification[O.SDO] Export to Output device AT.Status[O.SDO] == Verified AT.Status[O.SDO] = Displayed
32. AT.VerifyOK[O.DTBSR_DS] Export to Output device AT.Status[O.SDO] == Verified AT.Status[O.SDO] = Displayed

10.1.2.2 IO operations
The following sensitive data have to be protected against disclosure and/or modification when they are
imported and/or exported to and from the TOE. They can be protected either by the TOE or by the
environment.
Table 5 — protection of sensitive data
IT device Data transfer P. Protected by
type
O.Certificate Import I environment
O.SP Import I environment
DA O.SDO Import I environment
O.SD Import I environment
O.CertificationPath Import I environment
Checker O.SD Export I environment
AT.CheckerStatus[O.SD] Import I environment
AT.Credential[S.Verifier] Import I environment
O.SDO approval Import I environment
input device O.SP approval Import I Environment
O.ValidationTime Import I Environment
O.CertificationPath approval Import I Environment
O.SDO Export I environment
O.CertificationPath & status Export I environment
Output device
O.SP & status Export I environment

O.Attributes & status Export I environment
O.SD & status Export I environment

10.1.2.3 Other operations
 Extract SDO components
 Verify signature attributes
 Validate Certification path
 Compute DTBSR
 DTBSR_DS cryptographic verification
10.2 Security functional requirements
10.2.1 Security functional requirements for the TOE
10.2.1.1 Class FCS: Cryptographic Support
Global refinement for crypto operations:
The cryptographic algorithms, modes of operations and protocols including random generation shall be
compliant with the rules and recommendations defined in OSP.CRYPTO.
FCS_COP.1 Cryptographic operation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction

FCS_COP.1.1/Hash The TSF shall perform [DTBS hashing] in accordance with a specified cryptographic
algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of standards].
Application notes:
This SFR deals with the hashing of DTBS to generate DTBSR1.

FCS_COP.1.1/Verification The TSF shall perform [digital signature verification] in accordance with a
specified cryptographic algorithm [assignment: cryptographic al
...