1、ASD-STAN STANDARD NORME ASD-STAN ASD-STAN NORM prEN 9300-005 Edition P 1 May 2012 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONAvenue de Tervuren, 270 - B-1150 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLI
2、SH VERSION Aerospace series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data Part 005: Authentication and Verification Srie arospatiale LOTAR Archivage Long Terme et rcupration des donnes techniques produits numriques, telles que CAD 3D
3、et PDM Partie 005 : Authentification et Vrification Luft- und Raumfahrt LOTAR Langzeitarchivierung und Bereitstellung digitaler technischer Produktdokumentationen, beispielsweise 3D CAD und PDM Daten Teil 005: Authentifizierung und Verifikation This “Aerospace Series“ Prestandard has been drawn up u
4、nder the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the needs of the European Aerospace Industry. It has been technically approved by the experts of the concerned Domain following member comments. Subsequent to the p
5、ublication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the standard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft
6、European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement the EN at national level by giving the EN the status of a national standard and by withdrawing any national stan
7、dards conflicting with the EN. Edition approved for publication 01 May 2012 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedures and Processes Domain Copyright 2012 by ASD-STAN prEN 9300-005:2012 (E) 2 Foreword This standard was prepared jointly
8、by AIA, ASD-STAN, PDES Inc and the PROSTEP iViP Association. The PROSTEP iViP Association is an international non-profit association in Europe. For establishing leadership in IT-based engineering it offers a moderated platform to its nearly 200 members from leading industries, system vendors and res
9、earch institutions. Its product and process data standardization activities at European and worldwide levels are well known and accepted. The PROSTEP iViP Association sees this standard and the related parts as a milestone of product data technology. PDES Inc is an international non-profit associati
10、on in USA. The mission of PDES Inc is to accelerate the development and implementation of ISO 10303, enabling enterprise integration and PLM interoperability for member companies. PDES Inc gathers members from leading manufacturers, national government agencies, PLM vendors and research organization
11、s. PDES Inc. supports this standard as an industry resource to sustain the interoperability of digital product information, ensuring and maintaining authentic longevity throughout their product lifecycle. Readers of this standard should note that all standards undergo periodic revisions and that any
12、 reference made herein to any other standard implies its latest edition, unless otherwise stated. The Standards will be published under two different standards organizations using different prefixes. ASD-Stan will publish the standard under the number EN 9300xxx. AIA will publish the standard under
13、the number NAS 9300xxx. The content in the EN 9300 and NAS 9300 documents will be the same. The differences will be noted in the reference documentation (i.e. for EN 9300 Geometric Dimensioning the identity of a user; Authentication of an electronic document establishes that the content is unchanged
14、 from to the original information. Information is original if it is demonstrable that the information belongs to the supposed author. Authentication may depend upon one or more authentication factors. Unlike verification and validation, authentication makes no statement about the quality of data in
15、terms of usability in the archiving process chain of e.g. conversion or reuse. 3.2 Asymmetric keys Asymmetric keys are pairs of keys, created in one step. They can be used in both directions. Encryption with the public key can only be decrypted with the private key. If the encryption is done with th
16、e private key, the decryption can only done with the public key. Such a key pair can be used for encryption and for signing. 3.2.1 Public key The public key is the part of the asymmetric key pair that is known to everyone. 3.2.2 Private key The private key is the part of the asymmetric key pair that
17、 is only known by the owner of the asymmetric key pair. prEN 9300-005:2012 (E) 6 3.3 Electronic document (Copied and modified from ISO-IEC 82045) The digital representation of a defined and structured amount of information which can be managed as a unit and be exchanged between users and systems. Ea
18、ch revision of a given document is a new electronic document. 3.4 Electronic signatures An electronic signature is a defined method to sign an object in electronic environments. It provides means to authenticate the signatory and the signed object in an unambiguous and safe way by attaching to or lo
19、gically associating data in electronic form to other electronic objects. In EN 9300 it is defined by an encrypted hash code with additional information such as time of creation and owner of the signature. ASD-STAN LOTAR distinguishes between: engineering signature; time signature. In the context of
20、the EN 9300, an electronic signature shall be: uniquely linked to the signatory; capable of identifying the signatory; created using means that the signatory can maintain under their sole control; linked to the data to which it relates in such a manner that any subsequent change of the data is detec
21、table. NOTE This definition complies with that given by: Directive in 1999/93/EC of the European parliament and the council from the 13th of December, 1999 concerning collective basic conditions of electronic signatures. 3.4.1 Engineering Signature The engineering signature expresses and fixes a vol
22、ition of the signatory it gives evidence of: the process of testifying quality of data against process/quality requirements by linking the signature owner to the data; the identity of the signatory by usage of appropriate methods of authentication; the integrity of the data by using appropriate meth
23、ods protecting the signed object against unauthorized changes. 3.4.2 Time Signature A time signature is created automatically as part of a certified process and requires certified hardware. It provides a legal guarantee for time and owner of the data. prEN 9300-005:2012 (E) 7 3.5 Hash Code A Hash Co
24、de is represented by a number calculated by a One-Way-Hash function. It represents the electronic document in a unique way. 3.6 Signer A signer is an entity that initially creates the electronic signature. When the signer digitally signs data using the prescribed format, this represents a commitment
25、 on behalf of the signing entity about the data being signed. 3.7 Verifier A verifier is an entity that verifies evidence. (ISO/IEC 13888-1). Within the context of this document this is an entity that validates an electronic signature. 3.8 Trust Center A Trust Center is one or more entities that hel
26、p to build trust relationships between the signer and verifier. Use of some specific technical service provider (TSP) services MAY be mandated by signature policy. TSP supporting services may provide the following information: user certificates, cross-certificates, time-stamping tokens. 3.9 Verifica
27、tion levels In the context of EN 9300 Verification Levels indicate a risk assessment. Verification Levels here will indicate the maximum acceptable risk for a specific process. 4 Applicability Refer to applicability of EN 9300-001, paragraph 4. 5 Authentication The necessity of authentication and ve
28、rification of digital information results from the legal requirement of ensuring the authenticity (originality and integrity) of stored data. 5.1 Authentication of User The authentication of the user is necessary to ensure only authorised persons initiate controlled processes. The legal status of an
29、 engineering signature will be enhanced by means of authentication. 5.1.1 Authentication by means of a PKI (Public Key Infrastructure) The application of a PKI is recommended to guarantee the quality of an engineering signature. Advantage: Delivers a higher evidential value. Disadvantages: The need
30、to provide an Infrastructure (PKI) with key ring administration; Each release of a document creates electronic signatures with metadata to manage. NOTE Currently there are different national laws and / or standards defining different security levels for PKI. By applying these levels different legal
31、qualities for documents can be obtained. prEN 9300-005:2012 (E) 8 5.1.2 Authentication by User Key and Password EN 9300 recommends authentication policies based on current business practices for user keys and passwords as the initial user authentication quality level. Advantages: Legal recommendatio
32、ns for documentation of the release process are fulfilled; There is no need for a PKI and no additional hardware for identification is required. Disadvantage: The validity in the context of lawsuits is less than under PKI. 5.2 Authentication of Document and Content Applying authentication to a docum
33、ent and its content will improve its evidential weight in the context of legal proceedings. The authenticity of a digital document can be proved with the document hash code. In case of a change of content, a new electronic document must be created and authenticated. 5.2.1 Requirements to Hash Codes
34、For signing and verification a hash code will be used like a digital finger print. To ensure that no security gaps occur, the hash code must fulfil the following criteria: It should practically be impossible to find a collision (where two or more different digital documents generate an identical has
35、h code); Creating hash codes shall be an one way function. It should not possible to find a file that generates a given hash code. NOTE From a theoretical point of view collisions are inevitable. 5.2.2 Usable Hash Functions It is recommended that the practice applied has the highest security level.
36、Its validity depends on the technical development in hardware, cryptography and networking. It is also recommended that hash codes have the maximum lifetime, in order to avoided renewing the hash code after a short period. NOTE 1 See, for example, the recommendations of the German Federal Network Ag
37、ency (for Electricity, Gas, Telecommunications, Post and Railway) in 2006: NOTE 2 Analysis of hash functions indicates that the following 160 bit functions may be considered as secure up to the end of 2009: RIPEMD-160; SHA-1. NOTE 3 The following hash functions with different hash code length (SHA-2
38、24 is a 224-bit hash function etc.) are expected to be secure for Long Term Archiving: SHA-224, SHA-256, SHA-384, SHA-512 2; FIPS PUB 180-3 “Secure Hash Standard (SHS)“. prEN 9300-005:2012 (E) 9 The actual permission has to be renewed in accordance to the highest applicable requirements in a defined
39、 and appropriate time frame. See figure below. Figure 1 Check and renew signature document 6 Qualification methods Qualification methods provide procedures to indicate the quality of processes, data and or information within the LOTAR framework. Two basic procedures are given: Verification; Validati
40、on; The result of verification and validation shall be kept in the system as status information. The result will distinguish between “passed“, “failed“ or “not performed“. “Not performed“ means that there is no result created in the verification or validation process. 6.1 Verification A verification
41、 of authenticity judges information against rules for legal admissibility, preferably those defined in standards or laws. Verification of the consistency of the information shall be applied throughout the throughout the Long Term Archiving (LTA) process. The initial verification takes place during t
42、he data preparation process. In case of data conversion, the verification is executed on the converted data. The EN 9300 introduces the verification of information on different levels. A verification of processes should guarantee that all parts of the process finished without errors. If required, th
43、e results of the process should be stored and archived into a process protocol (log file). prEN 9300-005:2012 (E) 10 The objectives of Verification in the LOTAR context are: Managing the risk of loss of information after a period of LTA; Re-interpretable information based on a stable data format; Av
44、oiding efforts of quality control and corrective methods (e.g. repair) in following processes of the archive chain. 6.1.1 Specification of Verification Levels In order to manage the risk of data or information loss during the LTA, LOTAR introduces a concept of verification levels. These levels are:
45、Verification Level Method Risk 0 No rules applied Maximum 1 Mandatory rules Calculated risk 2 Mandatory plus optional rules Minimized risk The rules and their categorization into “mandatory” and “optional” will be given within the Data Domain Specific Parts of LOTAR. 6.2 Validation Validation is app
46、lied to guarantee the integrity of the content of a document throughout the entire process of LTA. In the context of LOTAR the validation will be done by calculation and comparison of validation properties. 6.2.1 Validation Properties Validation properties are significant information, calculated wit
47、h the data inside the originator system; after each conversion within the LTA process. A set of Validation Properties is like a fingerprint for the content of the document. Each change of the content changes one or more attributes of the Validation Properties. Validation properties should be indepen
48、dent from the system and representation within given deviations. Validation properties are specific for each document type. They are stored as meta data and optionally in the LOTAR-Format file. For an automatic comparison of validation properties, a predefined matrix can be used. In this matrix valu
49、es for validation properties and accepted deviations from these can be stored to facilitate automated processing. The accepted deviations might differ in accordance to the defined use cases (e.g. product liability or design re-use) and has to be fixed. The detailed information on validation properties will be given in the Data Domain Specific Parts. prEN 9300-005:2012 (E) 11 6.2.2 Specification of Validation Levels In order to manage the integrity of content and the risk of data or information loss during the LTA LOTAR
