6 ias workshop 29 january - eseals...
TRANSCRIPT
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)
IA – 27/37 4 Electronic signatures in public services
IA – 27/37 4 Electronic signatures in public services
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
QSCD – harmonised secondary legislation
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.
QSCD – harmonised secondary legislation
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.
QSCD – harmonised secondary legislation
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 ….
QSCD – harmonised secondary legislation
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?
QSCD – harmonised secondary legislation
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).