Evidence Record Syntax
The Evidence Record Syntax , ERS for short, is part of the specification of the Long-Term Archiving and Notary Service , LTANS for short. It describes the data format for an evidence file, the Evidence Record, which is used to provide evidence of the integrity of a document stored in a long-term archive. The 2007 released specification of the ERS in RFC 4998 and the specification of ERS in XML format (XMLERS) in RFC 6283 in 2011 are under the leadership of the LTANS Working Group of the Internet Engineering Task Force (IETF).
The ideas for the ERS were developed in the ArchiSig project funded by the German Federal Ministry of Economics and Labor and then passed on to the IETF for standardization. In the project, among other things, the suitability of the preservation of evidence was tested in exemplary court proceedings.
Problem
The verification of the integrity of an electronic document can be ensured by means of a signature. If a qualified time stamp is used, the "When was which content before" is secured. A qualified, personal signature , on the other hand, safeguards the "who signed what", i. H. In addition to the integrity, the authenticity of the author can be proven. With the help of the Signature Act and subsequent changes in many other legal texts such as the Civil Code or the Code of Civil Procedure , the qualified signed, electronic document is equated with the written document in terms of evidential value.
The problem is the aging of the algorithms used to generate an electronic signature. With increasing age, the algorithms are vulnerable, i. H. with enough computing power, someone could pretend to be someone else or create another document using the previous hash value. The responsible Federal Network Agency announces when an algorithm becomes weak (see also the article on the ArchiSig project). From this point on, all documents whose qualified signature have used the algorithm lose their high evidential value.
Legal framework
The Signature Act refers to re-signing in Section 6 (1). In addition, the Signature Ordinance in Section 17 SigV defines that qualified time stamps must be used for re-signing. This means that before an electronic signature becomes invalid due to the hash algorithm and / or the encryption algorithm becoming weak, the data to be signed must be re-signed with a qualified time stamp. This preserves the evidential value of the signature.
solution
In the case of only a few signed documents, manual, personal signing is perhaps still conceivable. In the case of large document stocks, a solution is sought that is standardized, traceable, fast, because it is automated, and cost-effective. And this is exactly where LTANS comes in with the Evidence Record.
In order to understand the basic structure of the evidence record, the type of storage of signed documents for long-term archiving must first be discussed. The re-signing uses qualified time stamps. So-called hash trees are used so that, for reasons of cost (3 to 6 cents per time stamp) and time, each document does not have to be individually provided with a time stamp. For each new document saved in a content repository ( ECM ) (Figure 1: d1 to d4), a hash value is calculated based on the current, strongest hash algorithm and recorded in a hash tree on the first level (in the Graphics: h1,1 to h1,4, the first digit numbers the hash tree, the second the consecutive number of the hash value in the tree).
A hash tree can contain any number of hash values, and the arity of the tree is optional. In practice, a binary or ternary hash tree formed on a daily basis seems to prove its worth. The hash tree is created by first concatenating 2 to n hash values of the 1st level and calculating this byte sequence to a new hash value (child) (example in graphic 1: h1,5 = H ( h1,1 | h1,2)). This process is continued until only one hash value remains in the last level. This hash value is then signed with a qualified time stamp. The entire construct, hash tree and signature is then called the archive time stamp (Figure A1: with the 1 for the first hash tree).
If one of the documents is now required for evidence in court, a copy of the document is fetched from the content repository and its evidence record is created. Since the amount of data in the entire hash tree can be very large, a so-called reduced archive time stamp (Figure 2: rA1) is created and stored in the evidence record along with the verification results of the signatures. The reduced archive time stamp only contains the hash values to be able to recalculate the next child, as well as the time stamp of the hash value of the highest level. The Evidence Record Syntax is structured in the ASN.1 format and is difficult to read for inexperienced eyes and should therefore not be further presented here.
Additional information:
The qualified signing of documents can be done in three variants:
- The document is then accompanied by a signature file (in accordance with RFC 3852 )
- The signature file is embedded in a PDF / A -formatted document
- The document is embedded in the signature file
While in cases 2 and 3 a hash value is contained in the tree for only one object, in the first case two objects, the document and the accompanying signature file, have to be dealt with. Since in case 3 the document must first be extracted from the container to view it, the use of signatures embedded in PDF / A speaks in favor of easier handling.
The above-mentioned time stamp should have the same strength as the signature files for which the corresponding hash values are contained in the tree. Otherwise, interpreting the re-signing becomes more complicated.
Two methods of re-signing
The evidence record becomes more extensive as soon as it has to be re-signed for the first time. A distinction must be made between two methods of re-signing.
When a signature is created, a hash value is calculated for the document using a specific hash algorithm . Hash values based on the same algorithm are the same size and significantly smaller than the document itself; however, it is very unlikely that two documents will have the same hash value. This hash value is then encrypted in the chip on the signature card with the private, unique key "engraved" there and written into the signature file together with the certificate data also on the card .
If the encryption algorithm of the above-mentioned time stamp is classified as weakened soon, only the time stamp of the hash tree needs to be re-signed with a time stamp. The procedure here is that a hash value is calculated for all existing archive time stamps and this is recorded in a new hash tree, for which an archive time stamp is then generated.
The evidence record for a document must now also take into account the data of the reduced archive time stamp of the new hash tree with the hash values of the old archive time stamp, as shown in Figure 4.
If the hash algorithm used is classified as weakened soon, the process becomes more complex, since all documents then have to be fetched again from the content repository and hashed again. The procedure is that the new hash value is concatenated with the newly created hash values of its reduced archive time stamp and a further hash value is calculated for this byte sequence. This is then included in a new hash tree, which is then finally signed again with a time stamp.
It is self-explanatory that the evidence record becomes more extensive after each new signature.
Note: The graphics are images taken from the book Evidence-Based Electronic Archiving by Roßnagel and Schmücker ( ISBN 3-87081-427-6 ).
Interoperability
Since the evidence record is intended to enable proof of the integrity over a long period of time, interoperability between systems that generate such a record is imperative. The operators of long-term archives must expect that the current system will have to be replaced by another. I.e. the data it contains must be exported and re-imported. Since not only the documents and their signature files, but also their evidence records have to be transferred, it is essential to read the records into the internal data structure of the target system.
Implementations
The systems offered on the market (see ArchiSig ) that generate hash trees and evidence records and also carry out the re-signing as described above are described by their manufacturers as ArchiSig-compliant.
criticism
Since the procedure presented here is admittedly not that simple, there are also critical voices in addition to the proponents of the procedure. These demand that the re-signing of documents that are in an electronic archive should not be necessary, see also the article on the ArchiSig project.
Individual evidence
- ↑ IETF LTANS Working Group ( Memento of the original of July 10, 2009 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice.
- ^ LTANS Architecture Draft Specification
