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. 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. 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. 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: 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. 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. 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. 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. 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: 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. 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 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. 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/ 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.Significance of Long-Term Archiving
When Do You Need a Long-Term Archive?
What Is Needed For a Long-Term Archive?
Hash Trees
What Is The Purpose of a Hash Tree?
Hash Tree Versus Time Stamps For Individual Signatures
What is the difference between the two options?
Advantages and disadvantages of the two options
The Use of a Hash Tree With SecPKI Server
The Relation Between Hash Tree And Stored Data
Generation of a Hash Tree
Hash Trees For Different Clients Within a Company
The Use of The Directive TR-RESISCAN
Frequently Asked Questions
SecCommerce
Menü
Electronic Signatures
- The Signature Portal
- Signature types
- Signature tools for end users
- FAQ (SecSigner)
- Signatures in web applications
- Substitute scanning and signing (e-records)
- Digital mailroom and digital signature for incoming mail
- Multiple signatures used for workflow
- Verification and creation of mass signatures or individual signatures on server side
- Long term archiving with hash trees
- Remote Qualified Electronic Signature
- Electronic Seal eIDAS
- Identity and Access Management IdM 2FA
Encryption
Private Cloud
High security and easy to use
Client Software
SecSigner
Create electronic signatures
SecCardAdmin
Administration of signature cards
Signatur Workflows
Signature Portal
Complex signature workflows with all signature types
SecArchive
Substitute scanning
SecPKI Server
Central server of several products
SecVerification Server
Verification & decryption
SecSigner Server
encryption & signature creation
Two Factor Authentication
SecRouter
Secures website access
SecAuthenticator
User identification
SecSignID
Two Factor Authentication
SecSignID Server
SecSignID on-premise solution
File storage & sharing
SecSign Portal Server
Secure messaging and file sharing