6 IAS Workshop 29 January - eSeals eSignatures.pptblogs.dlapiper.com/iasproject/files/2015/02/6-IAS-Workshop-29... · QSCD – harmonised secondary legislation Assumptions: standards

Workshop

29 January 2015

IAS2

Study to support the implementation of a pan-Europeanframework on electronic identification and trust servicesfor electronic transactions in the internal market

Electronic signatures & electronic sealsUp-dates - feedbacks from :

- previous workshop

- ETSI plug-tests and CEN/ETSI progresses- stakeholders: EC and markets reactions

SMART 2012/0001

eSeals and eSignature: secondary legislation

GENERAL (note: ‘S’ for seal and signature)

IA – 27/37 4 Electronic signatures/seals in public services

EC may establish ref. sdts for presumption of conformity

IA – 27/37 5 Format for AdES

by 2015/09/18 EC shall define reference formats

QUALIFIED DEVICES (QSCD)

IA – 29 2 /39 1 Reference numbers of standards for QSCD

EC may establish… for presumption of conformity Annex II

IA – 30 3/39 2 Stds for security assessment of QSCD

EC shall establish list of standards for

DA – 30 4 /39 2 - Specific criteria to be met by the designated bodies

EC shall be empowered to define criteria

IA – 31 3 / 39 3 Format and procedure for the notification of certified QSCDs by MS to EC

EC may define formats & procedures

VALIDATION & PRESERVATION

EC may establish ref. sdts for presumption of conformity

IA – 32 3 / 40 Reference numbers of standards for the validation of qualified electronicsignatures/seals

IA – 33 3 /40 Reference numbers of standards for qualified validation service for QES

IA – 34 3 / 40 Reference numbers of standards for the qualified preservation service for qualifiedelectronic signatures/seals

IA – 27/37 4 Electronic signatures in public services

Reference numbers of standards for advanced electronic signatures

does not imply that compliance with these standards is in any way mandatory orthat advanced signatures cannot be created through other means

it is likely that the act will focus principally on security features of advancedelectronic signatures (security aspects of the signature, crypto algorithms, securityrequirements on the computing environment, etc.).

IA relates to advanced electronic signatures recognition “at least for certainformats” will also need to conform to the IA 27.5

focus on three specific types of AdES (all can be “remote”):

AdES (further denoted AdES)

without certificate (cannot be excluded) or

with non-qualified certificate (it cannot be presumed that the concept of ‘certificates’ in the future needsto be restricted to PKI-certificates only)

AdES based on a QC, (further denoted AdES/QC) and

QES.

created by signature creation data, with a signature creation device

(challenge for validation): suspension without obliteration

should also offer a way of assessing the security level of a submitted AdES(link LoA’s eID)



PKI based signatures;

Electronic data

XAdES, CAdES, PAdES

IA 27/37.4: whatAdES is

Built on existing orunder edition RFCs,CEN/ETSI/ISOstandards

IA 27/37.5: how AdES shall be built

Built on Decision 2011/130/ECamended by 2014/148/EU to insurea smooth transition from theDirective toward the Regulationrequirements

Built on ETSI formats

QSCD – a SCDev first

Environment: to be secured by signatory and / or TSP

SignatureCreation

Application(e.g. hash compt.)

Creation datacontainer

Device

Auth. Module

QSCD:CERTIFIED

DrivingApplication

SCDev:

-signature creation datacontainer,

-signature creation application,the SCA, i.e. amongst otherthe application triggering theuse of the signature creationdata (« trusted path »)

-user authentication towardsignature creation datacontainer

! SCDev can be a “product” ora “service”

(Q)TSP can be entrusted tomanage the signature creation(data) on behalf of thesignatory, provided signatoryhas sole control, (key backupsallowed)

SCDev (Art 3 22 / 3 31)

SCDev for AdES (Art 27 / 37 4)

QSCD (Annex II - Art 29 2 / 39 1)

Certifiedcomponents(Art 30 / 39)

(Q)SCD – products and / or services

QSCD – harmonised secondary legislation

DBs(C(A)B)

in MS

Labs, Auditors

MemberState

EUCommission

List of DBs

List of certified devices

Publishes

2. Notifies certified devices &certification changes

(art 31 1 / 39 3),

Formats (IA 31 / 39 3)

1. Notifies DB’s address, name

(art 30.2 / 39 2)

Mandatory

Optional

0. Designates

(art 30 1 / 39 2)

According to DA 30 4 / 39 2

Certifies (art 30 1 / 39 2)

According to IA 30 3 / 39 2

Scope of QSCD wider than the scope of certification ofQSCD:

(Q)SCD means more than keeping the electronic signaturecreation data (i.e. it is a SCDev).

Annex II (QSCD) adds reqs. (not limited to SCD container)

whereas 56: “scope of certification obligation shouldexclude signature creation applications”

QTSP entrusted for the care of qualified electronicsignature creation device: supervision and audit

Different scenarii – wider scope than for certification:timing?

standards should enable to isolate requirements for QSCDcomponents subject to certification from the otherrequirements on other QSCD’s components and/or itsenvironment.

Reqs. QSCD (Annex II - Art 29 2 / 39 1)

Reqs. Forcertifiedcomponents(art 30/39)

Reqs. SCDevfor AdES (Art 27/37 4)

Wh. 56

Devices


Assumptions:

standards referred to in art. 30 3 (a) are standards for the security assessment ofinformation technology products (e.g. CC). Such standards should support the definitionof “security levels” (e.g. EAL 3, 4, …).

security evaluation process refers to a process, described in the standards for thesecurity assessment of information technology products, that enables to certify orevaluate an underlying standard (or security requirements) used to certify the QSCD(e.g. a CC certified PP). This process is not under the hand of the DB. It may additionallyrefer to the method of evaluation of the QSCD based on the so defined underlyingstandards.

underlying standards used to certify the QSCD are the criteria, security requirements inparticular, against which the QSCD will be certified by the DB to be listed:

either in the list referred to in IA2 29 2, together with other standards that go beyond the scopeof certification only and/or that may exist beyond the framework of the standards for the securityassessment of information technology products listed under IA 30 3, in quality of standardsagainst which one can presume conformance to (a part of) Annex II and/or

in IA 30 3 (a) as the reference standards “allowed” by the standards for the security assess-ment of information technology products which is the heart of IA 30 3.


Issue:

the activation of 30 3 (b) in the case of an on-going security evaluation process for aparticular underlying standard or when there is no available underlying standards for theQSCD to be evaluated should, not be “impeded” by the standard(s) referred to in 30 3(a):

It should be clear that when a QSCD cannot be mapped as the target of evaluation ofany available “allowed” underlying standards, a member state or its designated bodyshould be allowed to propose an alternative standard with security requirements adaptedto the QSCD solution en question. E.g. if underlying standards only cover the cases ofsmart-cards, and a signing server QSCD needs to be evaluated, the activation of 30 3 (b)is possible.


11

Accredits

as skilled for

IT products certification(ISO 17065)

REG. (EU) No 765/2008

EA

Common Criteria

- CC Certified PP for SSCD

- New CC Certified PP for QSCD

(e.g. based on SSCD PP, forsigning server, …)

SOGIS MRA - CCRA

Guidance 419 203

- PP for QSCD (e.g. based on SSCDPP) and/or new PPs tbd, OR

- National rules (e.g. for Signing Server),OR

- Annex II REG. 910/2014 – limited toscope of certification

Not CC “only”

CEM

& Guidance 419 203

(ex CWA 14172)

CD. No EC/2000/709

Does not require a part. cert. scheme

Cert.Body: by law or ISO 17065accredited by NAB or conform to CCAnnex

signslists conform (licenced) labs

(e.g. 17025, impartial,skilled, etc.)

Requires a sectorial certification scheme

2 WAYS

may be

accredited by

DBs(C(A)B)

in MS

Labs, Auditors

MemberState

Designates (DA 30 4 / 39 2)

Certifies (IA 30 3 / 39 2)

Reqs. forcertifiedcomponents(art 30/39)

Accreditation track

Certification track

Devices

Supervised if TSP managed ….


Pros & cons of proposed tracks:

Common Criteria:

Very complete / structured framework

Existing frameword for SSCD – quasi plug andplay

Might not cover all solutions: CC does notcontain security evaluation criteria pertaining toadministrative security measures not relateddirectly to the IT security functionality. However,it is recognised that significant security canoften be achieved through or supported byadministrative measures such asorganisational, personnel, physical, andprocedural controls

Difficulties to activate Art 30 3 (b); requires toshow that no PP is suitable BUT the device tobe evaluated is a QSCD candidate

Cost of evaluations

Mutual recognition through agreements notnecessarily signed by all MS

Regu 765/2008:

Applicable to all MS

Suitable for security trough administrativemeasures such as organisational, personnel,physical, and procedural controls

Cost of evaluation?

Difficulties to activate Art 30 3 (b); requires toshow that no underlying standard is suitableBUT the device to be evaluated is a QSCDcandidate and what about proving the “levels”equivalence?


In both cases:

Positionning of underlying standards wrt requirements for SCD, QSCD (annex II) andQSCD certification (in “onion” form?)

Could solve the supervision / certification timing by allowing first the certification and thenthe supervision on “how” the certified device is implemented withn a QTSP specificenvironment …

Are these track ‘standard(s)’ as required by Art 30 3 ?

Time to market (certified PP, sectoral scheme)

Can the IA go beyong listing standard(s) and cares for the activation for Art 30 3 (b)?How?

IA 32 3 / 40 Validation of QES

- Key point: confirmation of diverse features or qualities of the signature “at the time of signing” isintrinsically linked to different elements and proofs associated with the signature and to the way theyhave been preserved

- Perfectly legally valid QES may never be technically verifiable in the absence of certain signatureinformation (proofs of existence, etc.); the more the validation report can be clear to this regard (e.g.explaining or weighting the actual risk according to the missing information), the better for thesignature market as this may avoid “blind” rejection of QES that would have actually deserveacceptation in many business cases.

- Ideally need to refer to a standard detailing how to process a QES in order to verify the points (a) to(h) in article 32.1 (relying on a detailed algorithm describing all the steps to be performed for eachpoint). It shall identify all necessary inputs (in particular, depending on the position of the date ofvalidation with regard to the QES milestones)

Validation of QES – open points

Risk of rejection of valid signatures – acceptation of invalid signatures

an algorithm is deterministic … some elements are at the border of thevalidation algorithm (i.e. ETSI 319 102) and the signature validation policy (i.e.ETSI 319 172) – to be customised according to business cases.

Need to limit “indeterminations”: shift as far as possible from algorithm topolicy

Important to consider in the algorithm ONLY these elements for compliancewith Article 32

Validation of QES – open points

Elements to position:

weak cryptographic suites

a « personnal » choice OR

a non-conformity to Art 26?

the certificate chain or path validity

all path valid (RFC 5280 like) OR

only the signatory certificate valid, under certain conditions?

proof of the signing time with regard to expiration/revocation

digital signatures rely heavily on the revocation services for ensuring trust in the system (andin the same vein, to a certain extend, on the guarantee given by the CA that a certaincertificate is valid for a certain period)

The validation that a certificate was valid at the time of signing requires the validation thatthe certificate was not expired of revoked at the time of signing.

However, one can discuss the type of proofs related to this time of signing:

self-claim versus trusted (qualified?) timestamp: a matter of policy?

time of the proof of existence: creation (as per Regulation – always possible?) or (first)validation (ETSI 319 102 like)?

Preservation of QES

Key points in “extending the trustworthiness of the QES beyond its technologicalvalidity period”

“Extending the trustworthiness”

Supposes a certain continuum in time -> requires a validation (whoever does it)

the definition of “end of the technological validity period”

Strictly speaking, refers to underlying technology, not to the technical validity (i.e. not to validationas per Art 32)

Recital 61: guarantee that [QES] can be validated irrespective of future technological changes :may also cover obsolescence of current display techniques etc.

the consideration of the signed data

Essence of any ES lies in link with signed data; cannot meet Art. 34.1 objective without theassurance that the signed data is preserved (by whoever does it) and can be retrieved (bywhoever does it) so that what is done by the TSP will indeed lead to effective & verifiabletrustworthiness of the QES.

the consideration of ancillary services and the business perspective

Market of QPS: only do preservation of QES versus ‘full service archiving’, and also withdifferences in duration of the period.

Preservation of QES

Ideal preservation service:

should be possible to call a preservation service far before the “end of thetechnological validity period” of a QES.

check that the QES is trustworthy requires a validation of the QES, then:

completion of the received signature into a more resilient form (i.e. maximal resilience level described in IA27.4, -A – “zero risk approach”), and/or

preservation within a hash tree, or any other type of preservation.

assurance that the signed data is being preserved

link between QES & signed data can be a hash (with all limitations on the techniques), orcertain traces of the act of signing (procedures …). The signature preservation alone meansnothing.

QES preservation provider must be able to establish the link QES / signed data in anunambiguous way

value added service

responsibility in converting supporting media when technologies used to read, validate anddisplay QES and related proofs are becoming obsolete?

duration of service (long, very long terms)

TSP to clearly indicate the boundaries between the service it offers and ancillary services

Preservation of QES

Proofs that needs to be gathered; two candidates

ETSI advanced form of XAdES, PAdES and CAdES provide solution for preserving signatureusing a sequence of time stamps.

Evidence Record (ERS) syntax (IETF RFCs 4998 and 6283), that uses Merkle Hash Trees (onlyone time stamp is required for a complete re-signing cycle).

Note: There is no contradiction between these documents, efforts are ongoing to makethem converge.

Both methods rely on time stamps and hash functions and shall consider risks:

on hash functions

that might arise from the attack on asymmetric algorithms (e.g. quantum computing)

monitoring crypto, use of two timestamps based on distinct hash functions, from 2providers, etc.

Protection of the preserved data

ETSI 319 401: security requirements for TSP. Cover the protection of data against loss, disasteretc. and privacy.

A specific policy (or profile from the above mentioned QTSP policy) shall also be proposed forqualified preservation service for QES. This policy shall address the specific requirements andmeasures to be taken against technology obsolescence (at least as recommendations).

6 IAS Workshop 29 January - eSeals eSignatures.pptblogs.dlapiper.com/iasproject/files/2015/02/6-IAS-Workshop-29... · QSCD – harmonised secondary legislation Assumptions: standards

Documents