IAS2. Electronic signatures & electronic seals Up-dates - feedbacks from :

Transcription

1 IAS2 Study to support the implementation of a pan-european framework on electronic identification and trust services for electronic transactions in the internal market Electronic signatures & electronic seals Up-dates - feedbacks from : - previous workshop - ETSI plug-tests and CEN/ETSI progresses - stakeholders: EC and markets reactions SMART 2012/0001 Workshop 29 January 2015

2 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 / 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 electronic signatures/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 qualified electronic signatures/seals

3 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 or that advanced signatures cannot be created through other means it is likely that the act will focus principally on security features of advanced electronic signatures (security aspects of the signature, crypto algorithms, security requirements on the computing environment, etc.). IA relates to advanced electronic signatures recognition at least for certain formats 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 needs to 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)

4 IA 27/37 4 Electronic signatures in public services

5 IA 27/37 4 Electronic signatures in public services XAdES, CAdES, PAdES PKI based signatures; IA 27/37.4: what AdES is Built on existing or under edition RFCs, CEN/ETSI/ISO standards Electronic data IA 27/37.5: how AdES shall be built Built on Decision 2011/130/EC amended by 2014/148/EU to insure a smooth transition from the Directive toward the Regulation requirements Built on ETSI formats

6 QSCD a SCDev first SCDev: -signature creation data container, -signature creation application, the SCA, i.e. amongst other the application triggering the use of the signature creation data («trusted path») -user authentication toward signature creation data container Environment: to be secured by signatory and / or TSP Driving Application Signature Creation Application (e.g. hash compt.) Creation data container Device QSCD: CERTIFIED Auth. Module! SCDev can be a product or a service (Q)TSP can be entrusted to manage the signature creation (data) on behalf of the signatory, provided signatory has sole control, (key backups allowed) SCDev (Art 3 22 / 3 31) SCDev for AdES (Art 27 / 37 4) QSCD (Annex II - Art 29 2 / 39 1) Certified components (Art 30 / 39)

7 (Q)SCD products and / or services

8 QSCD harmonised secondary legislation Mandatory Optional Member State 0. Designates (art 30 1 / 39 2) According to DA 30 4 / Notifies DB s address, name (art 30.2 / 39 2) 2. Notifies certified devices & certification changes (art 31 1 / 39 3), EU Formats (IA 31 / 39 3) Commission Publishes List of DBs List of certified devices DBs (C(A)B) in MS Labs, Auditors Certifies (art 30 1 / 39 2) According to IA 30 3 / 39 2 Devices Reqs. For certified components (art 30/39) Wh. 56 Reqs. SCDev for AdES (Art 27/37 4) Reqs. QSCD (Annex II - Art 29 2 / 39 1) Scope of QSCD wider than the scope of certification of QSCD: (Q)SCD means more than keeping the electronic signature creation data (i.e. it is a SCDev). Annex II (QSCD) adds reqs. (not limited to SCD container) whereas 56: scope of certification obligation should exclude signature creation applications QTSP entrusted for the care of qualified electronic signature creation device: supervision and audit Different scenarii wider scope than for certification: timing? standards should enable to isolate requirements for QSCD components subject to certification from the other requirements on other QSCD s components and/or its environment.

9 QSCD harmonised secondary legislation Assumptions: standards referred to in art (a) are standards for the security assessment of information technology products (e.g. CC). Such standards should support the definition of security levels (e.g. EAL 3, 4, ). security evaluation process refers to a process, described in the standards for the security assessment of information technology products, that enables to certify or evaluate 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 additionally refer to the method of evaluation of the QSCD based on the so defined underlying standards. underlying standards used to certify the QSCD are the criteria, security requirements in particular, 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 scope of certification only and/or that may exist beyond the framework of the standards for the security assessment of information technology products listed under IA 30 3, in quality of standards against 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 assessment of information technology products which is the heart of IA 30 3.

10 QSCD harmonised secondary legislation Issue: the activation of 30 3 (b) in the case of an on-going security evaluation process for a particular underlying standard or when there is no available underlying standards for the QSCD 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 of any available allowed underlying standards, a member state or its designated body should be allowed to propose an alternative standard with security requirements adapted to the QSCD solution en question. E.g. if underlying standards only cover the cases of smart-cards, and a signing server QSCD needs to be evaluated, the activation of 30 3 (b) is possible.

11 QSCD harmonised secondary legislation Member State DBs (C(A)B) in MS Designates (DA 30 4 / 39 2) Accreditation track Labs, Auditors REG. (EU) No 765/2008 may be Accredits accredited by as skilled for IT products certification (ISO 17065) Requires a sectorial certification scheme EA 2 WAYS CD. No EC/2000/709 Does not require a part. cert. scheme Cert.Body: by law or ISO accredited by NAB or conform to CC Annex lists conform (licenced) labs (e.g , impartial, skilled, etc.) SOGIS MRA - CCRA Common Criteria signs Certifies (IA 30 3 / 39 2) Certification track Guidance CEM & Guidance (ex CWA 14172) Devices Reqs. for certified components (art 30/39) - PP for QSCD (e.g. based on SSCD PP) and/or new PPs tbd, OR - National rules (e.g. for Signing Server), OR - Annex II REG. 910/2014 limited to scope of certification - CC Certified PP for SSCD - New CC Certified PP for QSCD (e.g. based on SSCD PP, for signing server, ) Supervised if TSP managed. Not CC only 11

12 QSCD harmonised secondary legislation Pros & cons of proposed tracks: Common Criteria: Very complete / structured framework Existing frameword for SSCD quasi plug and play Might not cover all solutions: CC does not contain security evaluation criteria pertaining to administrative security measures not related directly to the IT security functionality. However, it is recognised that significant security can often be achieved through or supported by administrative measures such as organisational, personnel, physical, and procedural controls Difficulties to activate Art 30 3 (b); requires to show that no PP is suitable BUT the device to be evaluated is a QSCD candidate Cost of evaluations Mutual recognition through agreements not necessarily signed by all MS Regu 765/2008: Applicable to all MS Suitable for security trough administrative measures such as organisational, personnel, physical, and procedural controls Cost of evaluation? Difficulties to activate Art 30 3 (b); requires to show that no underlying standard is suitable BUT the device to be evaluated is a QSCD candidate and what about proving the levels equivalence?

13 QSCD harmonised secondary legislation In both cases: Positionning of underlying standards wrt requirements for SCD, QSCD (annex II) and QSCD certification (in onion form?) Could solve the supervision / certification timing by allowing first the certification and then the supervision on how the certified device is implemented withn a QTSP specific environment 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?

14 IA 32 3 / 40 Validation of QES - Key point: confirmation of diverse features or qualities of the signature at the time of signing is intrinsically linked to different elements and proofs associated with the signature and to the way they have been preserved - Perfectly legally valid QES may never be technically verifiable in the absence of certain signature information (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 the signature market as this may avoid blind rejection of QES that would have actually deserve acceptation 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 each point). It shall identify all necessary inputs (in particular, depending on the position of the date of validation with regard to the QES milestones)

15 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 the validation algorithm (i.e. ETSI ) and the signature validation policy (i.e. ETSI ) to be customised according to business cases. Need to limit indeterminations : shift as far as possible from algorithm to policy Important to consider in the algorithm ONLY these elements for compliance with Article 32

16 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 (and in the same vein, to a certain extend, on the guarantee given by the CA that a certain certificate is valid for a certain period) The validation that a certificate was valid at the time of signing requires the validation that the 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 like)?

17 Preservation of QES Key points in extending the trustworthiness of the QES beyond its technological validity 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 validation as 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 objective without the assurance that the signed data is preserved (by whoever does it) and can be retrieved (by whoever does it) so that what is done by the TSP will indeed lead to effective & verifiable trustworthiness 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 with differences in duration of the period.

18 Preservation of QES Ideal preservation service: should be possible to call a preservation service far before the end of the technological 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 IA 27.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), or certain traces of the act of signing (procedures ). The signature preservation alone means nothing. QES preservation provider must be able to establish the link QES / signed data in an unambiguous way value added service responsibility in converting supporting media when technologies used to read, validate and display 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

19 Preservation of QES Proofs that needs to be gathered; two candidates ETSI advanced form of XAdES, PAdES and CAdES provide solution for preserving signature using a sequence of time stamps. Evidence Record (ERS) syntax (IETF RFCs 4998 and 6283), that uses Merkle Hash Trees (only one time stamp is required for a complete re-signing cycle). Note: There is no contradiction between these documents, efforts are ongoing to make them 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 2 providers, etc. Protection of the preserved data ETSI : security requirements for TSP. Cover the protection of data against loss, disaster etc. and privacy. A specific policy (or profile from the above mentioned QTSP policy) shall also be proposed for qualified preservation service for QES. This policy shall address the specific requirements and measures to be taken against technology obsolescence (at least as recommendations).