close

 Overview About Long-Term Archiving

Download the white paper about long-term archiving with hash trees






    If you contact us via Email or contact form, you are granting us permit to contact you. You need to provide a valid Email address to do so. The Email address is used to assign your request and respond to it. Any additional information you may provide is voluntary. Your data is stored in order to respond to your request, as well as contacting you for follow-up questions. Additional information are available in our privacy policy.

    Legally archive signed files and secure the evidential value by using long-term archiving with hash trees

    Due to the increasing digitization in economy, health care, public authorities, etc. the legal certainty of the documents must also be provided in digital form. Particularly in public health long-term storage times must be considered. This means that digital archiving must be able to secure the evidential value of these documents.

    White Paper Download

     

    Glossar


    ArchiSig Concept
    CA
    ETSI
    Hash tree
    Hash value
    Long-term archiving (LTA)
    OCSP
    RSA
    TR-ESOR
    Superordinate hash value
    Superordinate signature
    Time stamp

    Significance of Long-Term Archiving

    Digital documents must be signed with a qualified or an advanced signature, for example, in order to be accepted as evidence by court. Furthermore, it might be required – depending on document type and legal basis – to store digital documents over decades. This needs an option to prove even some years later that the process of the actual transformation from an analog document to a digital file (scanning and quality assurance) was realized by using a procedure which was valid at the incident. Additionally, it must be possible to prove that also the cryptographic procedures which were used to secure integrity were valid at that time.

    The problem: Timely limited evidential value of digital signatures 

    For the signature algorithms and keys are used which are – at some point of time – regarded as outdated and no longer suitable. Instead, for the existing algorithms stronger algorithms and, for example, longer keys are needed. In former times, these algorithms were published once a year by the German Federal Network Agency (Bundesnetzagentur) (based on suggestions of the German Federal Office for Information Security (BSI)) taking into account the technical regulation TR 03125. Before the publication representatives of the industries were consulted. Nowadays, the European SOG-IS group of experts publishes the appropriate algorithms and parameters for qualified signatures (according to the eIDAS regulation) in an algorithm newsletter. The newsletter also includes a forecast about the assumed validity period of the algorithms and parameters (i.e. how long they might be regarded as safe). The SecPKI-Server acts in accordance with these standards. The SOG-IS algorithm newsletter replaced the previous German algorithm newsletter which was published by the German Federal Network Agency according to German Signature Law on a yearly basis.

    Even signatures which are nowadays regarded as save, like, for example the 2048-bit RSA signature can possibly be falsified within some decades due to the increasing computer performance. A special problem is this for the healthcare sector as well as for public administration as in these fields documents must be stored for a long time.

    The solution: Audit-proof long-term archiving of documents according to ArchiSig

    In order to provide long-term archiving (hash archive) the archived documents and signatures are written into hash trees. For the hash trees it is necessary to retrieve time stamps from trust centers. Our product for long-term archiving, the SecPKI Server by SecCommerce ,   provides an automatic long-term archive by storing hash trees and time stamps in such a tree and by proving a renewal of signatures in regular intervals. For this we use only cryptographic algorithms which meet the requirements of the German Federal Network Agency as well as appropriate international standards (see above).

    All archived files are re-signed before the suitability of the algorithms ends. By this, the files always keep the evidential value. Additionally to all transaction data and their electronic signatures also the results of the online signature verifications of the trust centers as well as the relevant time stamps (if appropriate) are stored in this long-term archive.

    Thus, you maintain the evidential proof of your documents for decades and without any user intervention.

    When Do You Need a Long-Term Archive?

    Even though this question must actually be answered by your data protection office or an attorney it can be said that you will require a hash tree for securing the evidential value of your signatures, if you sign files in order to guarantee the integrity and authenticity of the data and (have to) store the signed data for a longer period of time.

    No matter if HIPAA, FDA, or eIDAS are concerned, the purpose is always long-term protection of the data integrity.

    Signatur-eingesetzt-werden

    What Is Needed For a Long-Term Archive?

    What exactly does long-term protection of data integrity mean? The signature process must use cryptography, and the evidential value of the signatures must be guaranteed for the requested period of time.

    But how can this be realized? Please find below a summary of the key requirements for long-term archiving:

    • Integrity: The electronic files as well as the assigned information must remain intact, i.e. there must be no manipulation of the data after storage in the LTA
    • Authenticity: The electronic data must match the original. It must be possible to assign them clearly to an issuer.
    • Completeness: Apart from the documents also the corresponding data (meta data, protocols of data processing, etc.) must be stored.
    • Transparency: Individual work steps must be documented for a long time period.

    • Availability: It must be possible to access the data “within reasonable time”.
    • Deletabiliy: It must be possible to anonymize the data.
    • Readability: Appropriate hardware and software must guarantee the legibility of the electronic documents.
    • Transferability: It must be possible to transmit the data to another system without affecting any of the above mentioned points.

    Hash Trees

    The hash values of the verified signatures are written into a hash tree and form the individual leaves of the hash tree. A hash tree can have any number of hash values. After a defined number of hash values a superordinate hash value is calculated This superordinate hash value represents all hash values below. In regular intervals (usually on a daily basis) a time stamp is retrieved. The time stamp finalizes the hash tree.

     

    faktor

    What Is The Purpose of a Hash Tree?

    In the course of the years also the time stamp becomes open to attack and must therefore be protected by a new time stamp on a regular basis. You get a string of time stamps which (altogether) provide the proof that the original signature has not been modified. It would, however, cost too much time and effort to generate a string of time stamps for each single signature – especially, as the time stamp must be requested from the trust center which is time consuming and which might be billed by the trust center. Another problem is that the storage requirements would be enormous.

    The solution is a hash tree. SecPKI forms such a hash tree. Its leaves are the hash values of the verified signatures of a document. At the same time the SecPKI-Server   provides you also with the option to add a time stamp into each single verified signature as specified by ETSI.

    Hash Tree Versus Time Stamps For Individual Signatures

    What is the difference between the two options?

    Option A: The use of time stamps for individual signatures

    Individual signatures are always re-signed by using a time stamp (alternatively, or as addition the SecPKI-Server can also add the archive time stamps to the verified signatures as specified by ETSI for CAdES-, PAdES-, and XAdES signatures as level LTA.

    Option B: Construction of a hash tree

    The hash tree only needs one time stamp for x signatures. The SecPKI-Server creates hash trees according to ArchiSig, retrieves time stamps from a trust center for the hash trees, and generates (on demand) relevant documentation according to RFC 4998 by using hash trees and time stamps.

    Advantages and disadvantages of the two options

    In contrast to a system which is supposed to guarantee the evidential value, the customers have the option to change their storage system anytime (e.g. between, SharePoint, OpenText, etc.) without endangering the evidential value. It is also possible for them to merge data from various sources and to transfer them to an archive. The maintenance of the evidential value for individual signatures (Option A), however, is very ineffective as each file must be handled once again for a subordinate signature, i.e. it must be downloaded from the DMS, transferred to the signature processes and re-written into the DMS. Furthermore, this procedure is, of course, much more expensive as every document needs its own time stamp. Another disadvantage is that the file is getting larger and larger during this procedure.

    For a hash tree you only need one time stamp for x files, and the documents do not have to be handled again for the superordinate signature.

    For the audit-proof archiving also WORM systems (Write Once Read Many) are used. In this case data are stored on systems on which you can write just once.  Due to the RAID mirroring of the hard drives the data are available in duplicate form in case of a failure of the hard drives. These systems, however, are too expensive and also more inflexible to use as the data cannot simply be transferred to a new DMS without endangering the integrity, etc. because of the data export and import.

    The Use of a Hash Tree With SecPKI Server

    Before storing the signed file in the DMS the signature should be verified in any case. During this step the SecPKI Server enters the hash into the hash tree. If the SecPKI Server is used for the generation of signatures, it will verify the generated signature before transferring it to the calling program of the signature function. This verification of signatures also automatically leads to an entry in the hash tree. It is the same for a signature which is generated with signature cards which are locally connected to the SecPKI Server  or which are created by using a remote signature service like D-Trust sign-me which is called by the SecPKI Server

    For the signature a hash about the original signature is stored as well as extended signatures for which the SecPKI-Server included time stamps, OCSP replies and CA certificates. When reaching a defined number of signatures a superordinate hash value is created. For the automatic superordinate signature the start of the relevant schedule is required. In a – by the customer defined – interval, e.g. once a week, the SecPKI-Server  retrieves a time stamp and signs the tree with it. After a one-time configuration this process runs completely automated. A time stamp refers to the root of a hash tree and completes it. Afterwards, the SecPKI-Server  starts with a new hash tree.

    Apart from the configuration about the frequency of the retrieval of a time stamp by the SecPKI-Server for the superordinate signature of the hash tree the customer also configures from which provider the time stamps must be retrieved. The customer buys a contingent of time stamps (e.g. 100 time stamps per year). The customer then receives authentication data in order to retrieve the time stamps. These credentials are stored in the the SecPKI-Server  during the configuration. For long-term archiving you require the SecPKI-Server  as well as a DMS.

     

    With SecPKI-Server you get an automated process:

    • Integration in any signature workflow (e.g. substitute scanning, SAP, SharePoint, DMS (interface to Document Management Systems))
    • Verification of signatures (safety assessment of signature algorithms by using a list of appropriate algorithms)
    • Retrieval of time stamps (or generation of your own time stamps)
    • Superordinate signatures
    • Multi-client capability: You can have different clients for different system areas or organizational fields
    • Export and import of signature trees
    • HA (High Availability / Fallback): Parallel operation of several SecPKI Servers
    • Option to issue audit reports
    • Administration tools
    • Verification, e.g. via revision client
    • Independency of platforms

    The Relation Between Hash Tree And Stored Data

    In case of a customer´s DMS (Document Management System) or a normal data base the customer stores only the file as well as the signature or – in case of an integrated PDF signature (PAdES) – only the PDF in the own system. Before storage the signature is verified by using the SecPKI-Server , e.g. by transferring the signed document to the server with API (SOAP, REST, etc.) The SecPKI-Server only enters the hash of the signature into the hash tree.

    This means: Only the hash tree is stored in the data base of the SecPKI-Server Signature and documents are stored in the customer’s DMS as usual. The great benefit is the data’s independency of the system.

    Signatur-eingesetzt-werden

    Signatur-eingesetzt-werden

    Generation of a Hash Tree

    Before storing the signed file in the DMS the signature should be verified in any case. During this step the SecPKI Server enters the hash into the hash tree. In a – by the customer defined – interval, e.g. once a week, the SecPKI-Server  retrieves a time stamp and signs the tree with it. After a one-time configuration this process runs completely automated. A time stamp refers to the root of a hash tree and completes it. After a one-time configuration this process runs completely automated.

    During the installation of the SecPKI Server you configure the frequency for the retrieval of a time stamp for a superordinate signature of the hash tree as well and define the provider from which the time stamp should be retrieved. You buy a contingent of time stamps from the provider (e.g. 100 per year) and get authentication credentials from the provider in order to retrieve the time stamps. During the configuration process the credentials are stored in the SecPKI Server

    Hash Trees For Different Clients Within a Company

    As soon as a hash tree has a time stamp it is complete. It is not possible anymore to add any parts or to separate it. This means if customers add hashes from various departments or different specialized procedures to the same hash tree, they will not be able anymore to separate the hashes later on.

    Usually, this is no problem as everyone can get the documentary for the hashes, which concern him/her. Hashes of other departments might be included in the documentary but this should be no problem either.

    However, it is a problem, as soon as a department does not wish any longer that its hash trees are administered in this “one” SecPKI Server but, for example, by their own SecPKI Server at a different place. In this case it is necessary to provide them with the complete hash trees even if just a minor part of the hashes actually belong to this department.

    So if you think that such a removal of hashes might become relevant for a certain department in future, it would be indeed much better to generate for this department right from the start an own client in the SecPKI Server . Each client in SecPKI has his own hash trees with the own time stamps. However, this also means that you need – in case of a daily superordinate signature – a time stamp for each client which also means extra costs even though the costs for a time stamp are not that high.

    The Use of The Directive TR-RESISCAN

    Digitization is used in more and more business areas. For the digitization process original documents (paper documents) are scanned and archived. From a legal point of view the scan should be able to replace the original. With digitization you can save space (due to the decreasing amount of paper documents which must be archived) and can find the files in electronic form much easier than the physically available documents.

    TR-RESISCAN is a directive which summarizes standardized and legally conform actions for the realization of substitute scanning in order to get closer to the goal paperless office / electronic file without the need to annul the legal certainty paper originals at the same time. The directive provides the user with concrete instructions for the use. You can find an example for TR compliant substitute scanning on https://seccommerce.com/ersetzendes-scannen-und-signieren-e-akten/

    Signatur-eingesetzt-werden

    Frequently Asked Questions

    Please find below a summary of FAQ´s. For the answer please click on the corresponding question. Any further questions? Please contact us Kontaktieren Sie uns.

    How can I check the time stamp retrieval?
    What is entered into the hash tree - the signature file (in case of an embedded PDF signature the complete PDF) or just a hash of it?
    How often do I have to retrieve a time stamp?
    Is the time stamp a signature file?
    Do I need a hash tree for the evidential value, if the actual signature has a time stamp?
    In the company we store various documents at different places. How can we verify the validity for a specific document?
    How can the validity of a signed/archived document be proved, e.g. during legal proceedings?