prEN 50764:2026

SLOVENSKI STANDARD
01-marec-2026
Zahteve za kibernetsko varnost za platforme pametnih kartic in podobnih naprav,
vključno z varnostnimi elementi
Cybersecurity requirements for platforms of smartcards and similar devices including
secure elements
Cyber-Resilienz von EUCC-zertifizierten Plattformen für Smartcards und ähnliche
Geräte, einschließlich sicherer Elemente
Cyber-résilience des plates-formes certifiées EUCC de cartes à puce et de dispositifs
similaires incluant des éléments sécurisés
Ta slovenski standard je istoveten z: prEN 50764:2026
ICS:
35.030 Informacijska varnost IT Security
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
prEN 50764
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2026
ICS 35.030; 35.240.15 -
English Version
Cybersecurity requirements for platforms of smartcards and
similar devices including secure elements
Cyber-résilience des plates-formes certifiées EUCC de Cyber-Resilienz von EUCC-zertifizierten Plattformen für
cartes à puce et de dispositifs similaires incluant des Smartcards und ähnliche Geräte, einschließlich sicherer
éléments sécurisés Elemente
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-04-10.

It has been drawn up by CLC/TC 47X.

If this draft becomes a European Standard, CENELEC 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 CENELEC in three official versions (English, French, German).
A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to
the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the 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 Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 80922 Ref. No. prEN 50764:2026 E

Contents Page
10 European foreword . 4
11 Introduction . 5
12 1 Scope . 6
13 2 Normative references . 7
14 3 Terms and definitions . 7
15 4 Symbols and abbreviated terms . 9
16 5 Principles . 9
17 5.1 General . 9
18 5.2 Common Criteria framework . 9
19 5.3 EUCC state-of-the-art documents .10
20 5.4 Rules for the specification of technical requirements .11
21 6 Product context .13
22 6.1 Product types .13
23 6.2 Product’s intended and reasonably foreseeable use .15
24 6.3 Product’s essential functionalities .15
25 6.4 Product’s operational environment .16
26 6.5 Product’s system architecture .16
27 6.6 Product’s user .16
28 6.7 Product’s reasonably foreseeable misuse.17
29 7 Product technical requirements .17
30 7.1 Cybersecurity-enforcing activities .17
31 7.2 Requirements for the platform development and configuration .18
32 7.3 Requirements for the platform .24
33 Annex A (normative) Generic security analysis .64
34 A.1 General .64
35 A.2 Assets .64
36 A.3 Threats .64
37 A.4 Coverage of generic threats .65
38 A.5 Platform-specific security analysis . 66
39 Annex B (normative) PP-based conformance assessment . 67
40 B.1 General . 67
41 B.2 PP0084 . 68
42 B.3 PP0117 . 77
43 B.4 PP0104 . 91
44 B.5 PP TPM . 113
45 Annex C (informative) PP0099-based conformance for type 2 platforms . 127
46 C.1 Reference . 127
47 C.2 Mapping of the security analysis . 127
48 C.3 Mapping of technical requirements for the platform . 129
49 Annex D (informative) Guidance for manufacturers . 138
50 Annex ZZ (informative) Relationship between this European Standard and the essential
51 requirements of Regulation (EU) 2024/2847 aimed to be covered . 139
52 Bibliography . 144
53 European foreword
54 This document (prEN 50764:2026) has been prepared by CLC/TC 47X “Semiconductors and Trusted Chips
55 Implementation”.
56 This document is currently submitted to the Enquiry
57 The following dates are proposed:
• latest date by which the existence of this (doa) dav + 6 months
document has to be announced at national
level
• latest date by which this document has to be (dop) dav + 12 months
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) dav + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)
58 This document has been prepared under a standardization request addressed to CENELEC by the European
59 Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
60 Member States.
61 For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.
62 Introduction
63 This document defines generic threats and technical requirements for platforms of smartcards and similar
64 devices including secure elements in response to the CRA essential cybersecurity requirements for this
65 category of products. The expression and assessment of the technical requirements use the Common Criteria
66 specification and evaluation methodology supplemented by EUCC state-of-the-art documents. For platforms
67 conformant with Protection Profiles (PPs) PP0084, PP0117, PP0099, PP0104 or PP TPM, these PPs provide
68 the CC expressions for the technical requirements they cover.
69 This document is targeted at manufacturers of platforms.
70 1 Scope
71 The products with digital elements in the scope of this document are the platforms of smartcards and similar
72 devices including secure elements, which consist of a tamper-resistant MCU/MPU and optionally an application
73 environment or operating system. Platforms are designed to store and process sensitive data, and to protect it
74 against physical and logical attacks by attackers with significant resources and skills, at AVA_VAN.4 (moderate
75 attack potential) or AVA_VAN.5 (high attack potential) levels. Although platforms do not delegate data
76 processing to remote entities, these can be involved in operations such as software update, configuration or
77 key provisioning. The platform ensures the authentication of the remote entities before receiving/sending
78 sensitive information and ensures this information is protected during the exchange.
79 Platforms are intended for final products including, but not limited to, electronic identity cards, removable UICCs,
80 eUICC, payment cards, physical access cards, digital tachograph cards or wrist bands with integrated payment
81 secure elements, trust anchors in connected digital products and critical IT systems.
82 This document defines technical requirements for platforms, which meet the essential requirements defined in
83 Regulation (EU) 2024/2847 to the extent described in Annex ZZ. It also defines the methods for assessing the
84 technical requirements.
85 The expression of the technical requirements and the assessment methods use the Common Criteria (CC)
86 formalism defined in the EN ISO/IEC 15408 series and EN ISO/IEC 18045:2023 supplemented by the EUCC
87 state-of-the-art documents for the technical domain smart cards and similar devices.
88 This document covers platforms conformant with the Protection Profiles (PPs) PP0084, PP0117, PP0104 and
89 PP TPM, and identifies the gaps of these specifications against the CRA essential requirements. In this
90 document, PP0104 also refers to the PP0104-based PP-Configuration 0107. The evaluation of platforms against
91 PP0084, PP0117, PP0104 or PP TPM plus the applicable additional technical requirements which cover their
92 gaps allow to demonstrate conformance with the CRA essential requirements. The technical requirements and
93 the mappings against PP0084, PP0117, PP0104 and PP TPM are defined in Clause 7 and Annex B,
94 respectively.
95 This document also covers platforms consisting of a hardware layer and either an application environment, e.g.
96 Java Card platform, or firmware/software. Annex C contains an informative mapping of Java Card platforms
97 towards PP0099.
98 Platforms can have discrete, integrated or embedded form factors, and employ technologies such as integrated
99 circuits, programmable macros or system-in-package or system-on-chip. These do not affect the requirements
100 or the assessment methods. Unless specified, clauses apply to all platforms, from pure hardware to platforms
101 consisting of hardware, firmware and/or software.
102 Platforms are accompanied by guidance which contains all the requirements and recommendations for the
103 secure integration of the platform into further intermediate or final products and the secure usage of the platform
104 by the external entities. The guidance covers all the non-platform aspects which can impact the security of the
105 platform assets.
106 The applications stored and/or running on the platforms, which are an integral part of the final products, are
107 outside the scope of this document. prEN 18330:2026 applies to products composed of a platform and a set of
108 applications.
Application of attack potential to smart cards and similar devices, version 2, February 2025.
Minimum Site Security Requirements, version 2, February 2025.
Composite product evaluation and certification for CC:2022, version 1, February 2025.
109 2 Normative references
110 The following documents are referred to in the text in such a way that some or all their content constitutes
111 requirements of this document. For dated references, only the edition cited applies. For undated references, the
112 latest edition of the referenced document (including any amendments) applies.
113 prEN 40000-1-2:2025, Cybersecurity requirements for products with digital elements — Principles for cyber
114 resilience
115 prEN 40000-1-3:2025, Cybersecurity requirements for products with digital elements — Vulnerability handling
116 EN ISO/IEC 15408-1:2023, Information security, cybersecurity and privacy protection — Evaluation criteria for
117 IT security — Part 1: Introduction and general model (ISO/IEC 15408-1:2022)
118 EN ISO/IEC 15408-2:2023, Information security, cybersecurity and privacy protection — Evaluation criteria for
119 IT security — Part 2: Security functional components (ISO/IEC 15408-2:2022)
120 EN ISO/IEC 15408-3:2023, Information security, cybersecurity and privacy protection — Evaluation criteria for
121 IT security — Part 3: Security assurance components (ISO/IEC 15408-3:2022)
122 EN ISO/IEC 15408-5:2023, Information security, cybersecurity and privacy protection — Evaluation criteria for
123 IT security — Part 5: Pre-defined packages of security requirements (ISO/IEC 15408-5:2022)
124 EN ISO/IEC 18045:2023, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
125 security — Methodology for IT security evaluation (ISO/IEC 18045:2022)
126 PP0084, Security IC Platform Protection Profile with Augmentation Packages, Version 1.0, 13 January 2014,
127 Certificate: BSI-CC-PP-0084-2014
128 PP0117, Secure Sub-System in System-on-Chip (3S in SoC) Protection Profile, Version 1.8, 26 October 2023,
129 Certificate: BSI-CC-PP-0117-V2-2023
130 PP0104, Cryptographic Service Provider Protection Profile, Version: 0.9.8, February 2019, Certificate: BSI-CC-
131 PP-0104-2019
132 PP-Configuration CSP Time Stamp Service and Audit, Version 0.9.5, April 2019, Certificate: BSI-CC-PP-0107-
133 2019
134 PP TPM, Protection Profile PC Client Specific TPM, Revision 1.59, 29 September 2021, Version 1.3, Certificate:
135 ANSSI-CC-PP-2021/02
136 EUCC State-of-the-Art document, Application of attack potential to smart cards and similar devices, version 2,
137 February 2025
138 EUCC State-of-the-Art document, Minimum Site Security Requirements, version 2, February 2025
139 EUCC State-of-the-Art document, Composite product evaluation and certification for CC:2022, version 1,
140 February 2025
141 ECCG, Agreed cryptographic mechanisms, version 2, April 2025
142 3 Terms and definitions
143 For the purposes of this document, the terms and definitions given in prEN 40000-1-2:2025,
144 EN ISO/IEC 15408-1:2023, EN ISO/IEC 15408-2:2023, EN ISO/IEC 15408-3:2023,
145 EN ISO/IEC 15408-5:2023, EN ISO/IEC 18045:2023 and the following apply.
146 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
147 — ISO Online browsing platform: available at https://www.iso.org/obp/
148 — IEC Electropedia: available at https://www.electropedia.org/
149 3.1
150 application environment
151 firmware and/or software that provides functionalities to store and execute applications
152 3.2
153 application
154 software that provides service(s) to the user of the final product
155 Note 1 to entry: See IEC 60050 - International Electrotechnical Vocabulary - Details for IEV number 192–01–33:
156 “application software”.
157 Note 2 to entry: If supported, applications are assets of the platform.
158 3.3
159 external entity
160 entity that is not part of the platform, which may interact with the platform
161 Note to entry: The external entities are either hosted by the platform, or belong to the platform embedding product, or reside
162 outside the product. The users (of the final product) are external entities of the platform embedded in the product
163 3.4
164 platform
165 tangible or intangible element (or assembly of elements) composed at a minimum of a tamper-resistant
166 MCU/MPU and possibly including an application environment or operating system, designed to resist to attacks
167 requiring moderate or high attack potential
168 Note 1 to entry: A platform that includes an application environment or operating system is meant to support one or more
169 applications.
170 Note 2 to entry: For the definition of moderate and high attack potential, see Application of attack potential to smart cards
171 and similar devices.
172 3.5
173 platform embedded software
174 software that is not part of the platform but is stored and executed in the platform
175 Note to entry: This term designates the software (code and data) composed of the application environment and/or the
176 applications depending on the nature of the platform (bare IC, Java Card, etc.)
177 3.6
178 security functionality
179 mechanism provided by the platform to external entities for the protection of their assets
180 Note to entry: Mechanisms include without limitation cryptographic operations, cryptographic key generation, (True)
181 random number generation, secure storage, secure update, secure communication
182 3.7
183 user
184 entity interacting with the final product
185 Note to entry: Users interact with the platform either directly or indirectly through the platform embedded software if
186 supported
187 3.8
188 user data
189 data stored and/or processed in the platform on behalf of the user of the final product
190 EXAMPLE 1 A TPM stores and processes user data directly.
191 EXAMPLE 2 A smartcard implementing Java Card specifications stores and processes user data through individual
192 applications.
193 4 Symbols and abbreviated terms
CC Common Criteria
CSP cryptographic service provider
EAL evaluation assurance level
IC integrated circuit
MCU microcontroller
MPU microprocessor
OS operating system
PP Protection Profile
SE secure element
SAR security assurance requirement
SFR security functional requirement
ST Security Target
TOE target of evaluation
TPM trusted platform module
194 5 Principles
195 5.1 General
196 This document uses the security specification approach and evaluation methodology defined in the CC
197 framework for the definition of the technical requirements for platforms and platform development and
198 configuration and their assessment. The target of evaluation (TOE) consists of the platform plus the platform
199 guidance.
200 NOTE The platform guidance contains all the requirements and recommendations for the secure usage of the platform.
201 This covers any aspect of the operational environment of the platform, including the embedding product, that can have an
202 impact on the security of the assets protected by the platform.
203 Subclause 5.2 outlines the CC concepts referred to in this document and 5.3 describes the specificities of the
204 CC evaluation of platforms in the context of the EUCC state-of-the-art documents Application of attack potential
205 to smart cards and similar devices, Minimum Site Security Requirements, and Composite product evaluation
206 and certification for CC:2022.
207 The specification of the technical requirements follows a four-part structure composed of: definition, applicability,
208 CC expression and assessment. Subclause 5.4 defines the specification rules and the role of the PP mappings
209 defined in Annex B.
210 5.2 Common Criteria framework
211 The CC general security model for the evaluation of IT products is defined in EN ISO/IEC 15408-1:2023. The
212 framework includes pre-defined lists of technical, documentary and organizational hierarchical requirements, a
213 requirements’ extension mechanism, and detailed sets of evaluation activities which allow to specify and assess
214 the security of the conception, design, manufacturing and end-usage of an IT product, generally referred to as
215 the target of evaluation (TOE).
216 The catalogues of pre-defined security functional requirements (SFR) and security assurance requirements
217 (SAR) are defined in EN ISO/IEC 15408-2:2023 and EN ISO/IEC 15408-3:2023, respectively. The assurance
218 classes ADV, AGD, ALC and ATE include the assurance requirements for the TOE development, guidance, life
219 cycle and testing, respectively. The assurance class AVA addresses the TOE vulnerability analysis and
220 penetration testing.
221 EN ISO/IEC 15408-5:2023 defines the evaluation assurance levels (EAL) which are pre-defined assurance
222 packages, i.e. sets of SARs, from EAL1 to EAL7.
223 The evaluation requirements of most of the pre-defined SARs are further defined in terms of evaluation activities
224 in EN ISO/IEC 18045:2023 including the conditions for success.
225 Some SFRs and SARs have a dependency on some other. The claim of an SFR/SAR implies the claim of its
226 dependencies unless there is a valid justification. The claim of an SFR, SAR or EAL can be substituted by the
227 claim of a higher SFR, SAR or EAL provided the dependencies are satisfied.
228 The security claims of a TOE are declared in a Security Target (ST), which identifies and describes the TOE,
229 defines the security problem in terms of threats, assumptions and organizational security policies and the
230 security objectives, defines the lists of SFRs and SARs/EAL, describes how the TOE fulfils the SFRs and
231 provides rationales to ensure the accurateness and consistency of all the elements.
232 A Protection Profile (PP) is a document which defines the security problem, security objectives, SFRs and SARs
233 that apply to a TOE type that is representative of a large set of products. PPs are templates for STs.
234 The notions of functional package, assurance packages, PP-Module and PP-Configuration bring some
235 modularity to the definition of PPs and STs.
236 The CC evaluation of a TOE is based on the ST. It consists of the assessment of the evidence by the SARs,
237 including vulnerability analysis and the penetration testing for the attack potential the TOE needs to resist. The
238 CC defines a scale of four attack potential levels, i.e. Basic, Enhanced-basic, Moderate and High, in terms of
239 factors such as time, equipment and expertise. During an evaluation, if the score of a successful attack is lower
240 than the threshold, the TOE is considered not resistant and either the TOE is fixed, or the attack is mitigated by
241 a specific guidance, or the evaluation fails.
242 The composite evaluation approach defined through the _COMP assurance families from EN ISO/IEC 15408-3
243 allows to evaluate a layered TOE incrementally based on the dependency structure of the TOE components.
244 5.3 EUCC state-of-the-art documents
245 The technical requirements defined in this document shall be assessed using the CC evaluation methodology.
246 This supposes the expression of the technical requirements in terms of SFRs and SARs in STs. Two cases are
247 addressed:
248 — platforms with an ST that is conformant to a PP included in Annex B, and
249 — platforms with an ST that is not conformant to any of the PPs listed in Annex B.
250 NOTE In the second case, the platform can be conformant to another PP .

There is a small set of pre-defined SARs which concern formal models of functional specification and design,
which are not further defined in EN ISO/IEC 18045:2023.
PP0084, PP0117, PP0104 or PP TPM.
For example, PP0099 presented in Annex C.
251 STs that claim conformance to a PP listed in Annex B shall rely on the PP for the CC expression of the technical
252 requirements, and shall supplement the PP to cover any gap with the CRA essential requirements.
253 Moreover, the CC evaluation methodology shall be supplemented by the EUCC state-of-the-art documents
254 referenced in Clause 2.
255 The EUCC state-of-the-art document Application of attack potential to smart cards and similar devices defines
256 the attack potential rating system applicable to platforms, which is a specialization of the by-default scale defined
257 in the CC. It distinguishes the attack identification and exploitation phases and defines specific sets of values
258 for the factors and specific ranges for each of the pre-defined attack potential levels Basic, Enhanced-basic,
259 Moderate and High. In this document, two levels of attack potential are considered for the platforms:
260 — Moderate attack potential, which corresponds to AVA_VAN.4 (Methodical vulnerability analysis), and
261 — High attack potential, which corresponds to AVA_VAN.5 (Advanced methodical vulnerability analysis).
262 Platforms shall be evaluated against AVA_VAN.4 or AVA_VAN.5 and their dependencies. Additional assurance
263 components required to cover specific aspects such as the security of the platform development facilities also
264 apply.
265 NOTE The assurance components AVA_VAN.4 and AVA_VAN.5 belong to the assurance level 'high' defined in
266 Regulation (EU) 2019/881 [16].
267 The EUCC state-of-the-art document Minimum Site Security Requirements defines the set minimum security
268 requirements for the sites involved in the development (including production) of the platforms up to the delivery.
269 This document constitutes a supplement of the evaluation methodology defined for ALC_DVS.2 in
270 EN ISO/IEC 18045:2023.
271 The EUCC state-of-the-art document Composite product evaluation and certification for CC:2022 constitutes a
272 supplement to the evaluation methodology defined in EN ISO/IEC 18045:2023 for the assurance components
273 included in the COMP package, i.e. ASE_COMP.1, ADV_COMP.1, ALC_COMP.1, ATE_COMP.1 and
274 AVA_COMP.1.
275 5.4 Rules for the specification of technical requirements
276 5.4.1 Definition
277 The definition of a technical requirement is a concise shall-statement which expresses some specific security
278 functionality or security properties of the platform.
279 The definition of a technical requirement may be followed by explanatory text, notes or examples.
280 5.4.2 Applicability
281 The applicability of a technical requirement is specific to each type of platform. The applicability conditions refer
282 to platform characteristics which either cover specific threats to the platform or are provided in the form of
283 services that can be used to cover the risks identified for the final product.
284 A technical requirement can be applicable, applicable under conditions or not applicable.
285 An applicable technical requirement shall be enforced or implemented by the platform.
286 A technical requirement that is applicable under conditions shall be enforced or implemented by the platform
287 when a specific condition is fulfilled.
288 A technical requirement that is not applicable is not considered and does not lead to any activity.
289 The applicability statement may be followed by explanatory text, notes or examples.
290 5.4.3 CC expression
291 The CC expression of a technical requirement is a statement formulated by means of SFR and/or SAR
292 components. The components shall be as in PP0084, PP0117, PP0104, PP-Configuration 0107, or PP TPM
293 included in Annex B, or as defined in this document.
294 This CC expression shall be included and fully instantiated in the ST of the platform. To meet a technical
295 requirement, the platform shall meet the corresponding CC expression.
296 Annex D provides guidance for defining the CC expression.
297 5.4.4 Assessment of the technical requirements
298 The assessment of a technical requirement shall consist of the evaluation of the minimum set of SARs that are
299 required to assess the CC expression of the requirement on the platform. The evaluation shall follow the CC
300 evaluation methodology defined in EN ISO/IEC 18045:2023 supplemented by the EUCC state-of-the-art
301 documents referenced in Clause 2.
302 For the technical requirements for platform development and configuration defined in 8.2, the assessment shall
303 consist of the evaluation activities from EN ISO/IEC 18045:2023 that are outlined in the assessment section of
304 each requirement.
305 For the technical requirements for the platform defined in 7.3, the assessment shall consist of the evaluation
306 activities defined in EN ISO/IEC 18045:2023 for the following assurance components:
307 — For all platforms:
308 — ASE assurance components:
309 — ASE_INT.1,
310 — ASE_ECD.1,
311 — ASE_CCL.1,
312 — ASE_SPD.1,
313 — ASE_OBJ.2,
314 — ASE_REQ.2,
315 — ASE_TSS.1 or higher,
316 — ADV assurance components:
317 — ADV_ARC.1,
318 — ADV_FSP.4 or higher,
319 — ADV_TDS.3 or higher,
320 — ADV_IMP.1 or higher,
321 — AGD assurance components:
322 — AGD_OPE.1,
323 — AGD_PRE.1,
324 — ATE assurance components:
325 — ATE_COV.2,
326 — ATE_DPT.1 or higher,
327 — ATE_FUN.1 or higher,
328 — ATE_IND.1 or higher,
329 — For platforms intended for high-risk environments:
330 — AVA_VAN.5.
331 — For platforms intended for moderate-risk environments:
332 — AVA_VAN.4.
333 The assessment of a layered hardware and software platform can use the composite evaluation approach
334 defined in the COMP package from EN ISO/IEC 15408-5 and EUCC state-of-the-art document Composite
335 product evaluation and certification for CC:2022. In this approach, the hardware platform is evaluated first, and
336 the results of this evaluation are reused in the evaluation of the platform. The composite evaluation of the
337 platform ensures that the software complies with the hardware guidance and focuses on the functionality and
338 countermeasures provided by the software layer. In this case, the following assurance components are also
339 assessed:
340 — ASE_COMP.1,
341 — ADV_COMP.1,
342 — ALC_COMP.1,
343 — ATE_COMP.1,
344 — AVA_COMP.1.
345 NOTE The composite evaluation approach also applies to the evaluation of the applicative layer on top of a platform,
346 which is out of the scope of this document.
347 6 Product context
348 6.1 Product types
349 Platforms can be of different types depending on two criteria: their layering level and their form factor.
350 Per layering level, platforms can be of type 1, 2 or 3:
351 1) Type 1: Hardware components, potentially with a firmware part, but no application environment. This type
352 of platform is aimed to host an application environment and their applications or a native application.
353 Platforms of type 1 require the conformance with PP0084 or PP0117. These PPs are technology-agnostic,
354 not linked to any specific functional specification, and allow to cover all the identified threats. Type 1
355 platforms are of one of the following sub-types:
356 a) PP0084-conformant,
357 b) PP0117-conformant.
358 2) Type 2: An application environment embedded on a hardware component of type 1. This type of platform
359 is aimed to host and run one or more applications in isolation from each other and from the hardware
360 platform. Platforms of type 2 require a type 1 hardware layer.
361 EXAMPLE Java Card and MULTOS platforms are type 2.
362 NOTE 1 Java Card platforms which conform to PP0099 and PP0084/PP0117 are type 2. Java Card platforms which
363 conform to GlobalPlatform SE PP [6] are type 2.
364 NOTE 2 A type 2 platform can be evaluated in composition by applying the predefined assurance package COMP
365 or in a single evaluation based on an ST conformant to PP0084 or PP0117 which also addresses the application
366 environment.
367 3) Type 3: Hardware components with a firmware / software part, providing a service API but not destined to
368 host any application environment or application. Type 3 platforms are of one of the following sub-types:
369 a) PP0104-conformant: CSP product, which provides cryptographic services and does not support
370 platform embedded software,
371 b) PP-TPM-conformant: TPM product, which provides attestation and cryptographic services and does
372 not support platform embedded software,
373 c) Non-PP-conformant: product which provides cryptographic services and does not support platform
374 embedded software.
375 NOTE 3 Type 3 platforms can rely on any type of hardware provided the conformity with the corresponding PP is
376 fulfilled. That is, conformance with PP0084 or PP0117 is not required for the hardware layer.
377 Per form factor, platforms can be discrete or integrated:
378 — Discrete, i.e. not integrated into a larger system, for example the IC of a smartcard. This applies to
379 — Type 1a,
380 — Type 2,
381 — Type 3.
382 — Integrated into a larger system, for example the secure sub-system within a SoC. This applies to
383 — Type 1a, 1b,
384 — Type 2,
385 — Type 3.
386 NOTE 6 Type 1a platforms can be discrete or integrated. This means that a secure sub-system that is integrated in a
387 SoC can be conformant with the PP0084.
388 NOTE 7 Type 1 and type 2 platforms can implement functionalities for the platform embedded software (the upper layer)
389 which are not present uniformly in all platforms of the type. This stands for services (APIs) such as cryptographic operations
390 and secure communication protocols. For platform types 1a and 1b, the services that are covered by the optional packages
391 or PP-Modules that are defined in the corresponding PPs, i.e. PP0084 and PP0117 are addressed exclusively as in the
392 packages/PP-Modules. That is, PP-conformance applies to the optional packages and PP-Modules as well.
393 In the following, the expression PP-conformant platform designates the platform types 1a, 1b, 3a and 3b.
394 Table 6 summarizes the platform types and the allowed form factors.
395 Table 6 — Platform types
Type Sub-type Discrete Integrated
Type 1 Type 1a PP0084-conformant Yes Yes
Hardware component
Type 1b PP0117-conformant No Yes
Type Sub-type Discrete Integrated
Type 2
Application environment embedded Yes, if hardware Yes
on a type 1 hardware component is type 1a
Type 3 Type 3a PP0104-conformant Yes Yes
Hardware and software component
providing a service API
Type 3b PP TPM-conformant Yes Yes
Type 3c Yes Yes
396 6.2 Product’s intended and reasonably foreseeable use
397 Platforms are intended to be integrated into final products directly serving the user. For some platform types the
398 integration requires the installation of platform embedded software. For platforms which serve as stand-alone
399 components, the integration means assembling them into the final product without installation of software.
400 Platforms are specifically designed to protect final products against physical and logical attacks by attackers
401 with significant resources and skills, i.e. attacks requiring moderate to high attack potential as defined in EUCC
402 state-of-the-art document Application of attack potential to smart cards and similar devices.
403 EXAMPLE Final products include but are not limited to electronic identity cards, payment instruments. Systems
404 requiring trust anchors include but are not limited to connected digital products and critical IT systems.
405 6.3 Product’s essential functionalities
406 The essential functionalities of a platform depend on its type. The following lists are non-exhaustive.
407 For all platforms, essential functionalities include:
408 — secure initialization,
409 — unique identification,
410 — processing capabilities,
411 — persistent storage,
412 — I/O management,
413 — random number generation,
414 — physical tamper protection.
415 For platforms including an application environment, essential functionalities also include:
416 — isolation of the applications’ execution from the platform,
417 — controlled access to application data,
418 — security-enforcing communication channels.
419 Platforms may include other functionalities such as:
420 — cryptographic co-processors,
421 — cryptographic libraries,
422 — key management,
423 — application installation and life cycle management,
424 — application firewall.
425 6.4 Product’s operational environment
426 Platforms are intended as components/parts of final products that can be used safely in uncontrolled and
427 unprotected environments which can lead to specific cybersecurity risks. In this document, risk environments
428 are characterized using the conceptual framework of attack potential defined in Application of attack potential
429 to smart cards and similar devices and are limited to:
430 — Moderate-risk environments, where attackers with up to moderate attack potential can attempt to defeat
431 the cybersecurity of the final product. In this type of environment, the possibility to face attackers with high
432 attack potential should be negligeable or implausible. Moderate attack potential ranges from 24 to 30 points.
433 Platforms addressing moderate-risk environments shall meet AVA_VAN.4 assurance component.
434 — High-risk environments, where attackers with up to high attack potential can attempt to defeat the
435 cybersecurity of the final product. High attack potential is above 30 points. Platforms addressing high-risk
436 environments shall meet AVA_VAN.5 assurance component.
437 Platforms of types 1a, 1b, 2 and 3a address high-risk environments.
438 EXAMPLE 1 A high-risk environment is considered appropriate for ICs to be integrated into electronic passports.
439 Platforms of types 3b and 3c address moderate-risk environments at a minimum.
440 EXAMPLE 2 A moderate-risk environment is considered appropriate for TPMs to be integrated into laptops.
441 6.5 Product’s system architecture
442 A platform consists of a chip layer with/without an embedded software layer and with platform-specific interfaces
443 for the communication with the external entities.
444 For PP-based platforms, the PPs listed in Annex B provide an overview of the platform architecture:
445 — for discrete ICs and integrated ICs, see PP0084 and PP0117, respectively,
446 — for service-oriented ICs, see PP0104 and PP TPM.
447 For platforms of type 2, the architecture consists of a chip and an application environment, which communicates
448 with the users through a set of I/O interfaces. The application environment hosts applications and isolates them
449 from each other and from the platform itself. For Java Card platforms, see PP0099.
450 6.6 Product’s user
451 The external entities interacting with a platform and using its services depend on the type of platform. The users
452 of the final products where the platform is integrated are indirectly users of the platform.
453 A platform is used by integrators to build intermediate or final products, e.g. the integration of a chip with an
454 application environment, or the integration of a secure subsystem in a SoC. Integrators shall comply with the
455 platform guidance.
456 For instance, if the platform is a discrete IC with firmware that provides an API to access its functionalities, the
457 application environment behaves as an external entity that uses the IC’s services, e.g. the memory management
458 unit or cryptographic library. The application environment also uses the I/O interfaces to communicate with
459 users, possibly through an application.
460 If the platform contains an application environment, the external entities are the applications and the users that
461 communicate with the applications.
462 6.7 Product’s reasonably foreseeable misuse
463 Misuse of platforms can arise due to ambiguities and/or inconsistencies in the platform guidance. This may
464 concern, for example, the configuration of memories, interfaces or security protections, the use of certain
465 functionalities outside the expected ranges, the use of functionality that is present in the platform but not
466 evaluated per se, e.g. some legacy cryptographic algorithms, etc. However, the gu
...