Evidence Record Syntax <draft-ietf-ltans-ers-00.txt> Brian Hunter brian.hunter@sit.fhg.de

Archiving electronic documents Long-term Problems algorithms weaken, certificates expire verification data no longer available changes of formats and media ArchiSig-Project 2001 - 2003 requirements, concepts, implementation, evaluation clinical trial in Heidelberg simulation study (mock trial) influence on ERS Digital signatures offer the possibility to secure integrity and authenticity of data and documents. Data + signature, the eletronic form, shall substitute paperbased form, paper + handwritten signature In many fields of application, documents need to be archived for 30 years or more in a secure and conclusive way. In Civil Procedure Code Verjährungsfrist is 30 Years Some Documents, e.g. those, which are needed to proove properties, need to be archived for ever One problem is, that additional verification data, e.g. actual used public keys of certification instances may be not available in future. We do not deal with that problem here. Another problem, the topic of this lecture, is, that the hash- or public key-algorithms used can loose their security suitability in the course of time. The reason is, that computers will get faster or new algorithms will be found, so it is possible to find other documents to the same hash value or to find signature keys So there is a need to conserve value of evidence of signed documents over long times actively. Aim of the archisig-project ist to develope technical concepts and solutions which have to be practical, cost-effective and in accordance to legislation.

Goals of data structure Standard structure containing complete proof of existence, which can be exchanged between parties EvidenceRecord external format, without forcing a particular architecture to be used by Archive Provider No restriction on type of data Support of encrypted data

Requirements from LTANS include all timestamps necessary to verify existence data structure can efficiently provide evidence for many archived data objects possible to provide evidence for data groups even within groups, non-rep proof for single object still possible deletion possible without affecting proofs of other data objects time-stamping possible without accessing data objects; only access data when hash alg becomes weak single location of all hash algorithms applied possible to include evidence and data within one structure or separately possible to archive encrypted data and allow integration of encryption info within evidence record possible to integrate additional info within the evidence record Digital signatures offer the possibility to secure integrity and authenticity of data and documents. Data + signature, the eletronic form, shall substitute paperbased form, paper + handwritten signature In many fields of application, documents need to be archived for 30 years or more in a secure and conclusive way. In Civil Procedure Code Verjährungsfrist is 30 Years Some Documents, e.g. those, which are needed to proove properties, need to be archived for ever One problem is, that additional verification data, e.g. actual used public keys of certification instances may be not available in future. We do not deal with that problem here. Another problem, the topic of this lecture, is, that the hash- or public key-algorithms used can loose their security suitability in the course of time. The reason is, that computers will get faster or new algorithms will be found, so it is possible to find other documents to the same hash value or to find signature keys So there is a need to conserve value of evidence of signed documents over long times actively. Aim of the archisig-project ist to develope technical concepts and solutions which have to be practical, cost-effective and in accordance to legislation.

ERS Overview Syntax and Processing (particularly verification) of an Archive Time Stamp Element to verify existance of any data objects over an undetermined period of time, useable for signature renewal optimized (but not restricted to) centralized Archive Time Stamping by Trusted Archive Authority including optional encryption addendum: integration into signed documents Not specified here: Service protocol: possible but not necessary for internal use Architectures of archive systems

Archive Time-Stamp Archive Time Stamp Initial Stamp hash-tree (Merkle) time-stamp containing digital signature single time-stamp for many data objects Initial Stamp event: after document is archived collect hash values of many documents and build tree, request time-stamp store archive time-stamp renew if necessary Reduction to Archive Time-Stamp necessary hash values for verification + time-stamp {SEQUENCE of SEQUENCE of OCTET STRING time-stamp} Hint: each Sequence Of Octet String is one layer of the tree SEQ2[1] SEQ1[2]

Time-Stamp Renewal Event: Any algorithm in time-stamp becomes weak (or time-stamp certificate expires) Method hash time-stamp with old hash algorithm and include it in new archive time-stamp Properties no access to data objects only few (at minimum 1) time-stamp for a whole archive Reduction: ArchiveTimeStampChain SEQUENCE of ArchiveTimeStamp

Hashtree Renewal Event: Hash Algorithm of chain becomes weak Method (for each data object) build Archive Time-Stamp chain include hash of (hash of chain + hash of data object) in new Archive Time-Stamp Properties need to access data objects avoidable via redundant hash trees Reduction: ArchiveTimeStampSequence SEQUENCE of ArchiveTimeStampChain

ERS Approach Client - Submission Select data objects (document, ..) Optional: Encrypt data objects Trusted Archive Authority – Reception and maintenance Initial Archive Time-Stamp Renewal: Time-Stamp Renewal, Hashtree Renewal Reduce hashtrees, generate Archive Timestamps Elements Client - Retrieval Optional: Decrypt data objects Optional: Add encryption info to record Optional: Integrate as an attribute if wanted Verify Archive Time-Stamps Element and document

ERS Approach Client Trusted Archive Authority Judge Doc Storage .. eDocn Doc Storage Evidence Record1 Time ERinit= rHT(Doc1 wrt Doc1-j) TSa (Root of rHT) Today eDoc1 rHT(TSa wrt other TS) TStsr (Root of rHT) ERtsr1= Expiry of TS-cert or sig alg weakens rHT(TSa wrt other TS) TStsr (Root of rHT) ERtsr2= Expiry of TS-cert or sig alg weakens rHT(Prev ERs|Hash(Doc1)..) TStsr (Root of rHT) ERhtr= Hash alg weak ER1 EvidenceRecord1 EncryptionMethod cek or private key rHT = reduced hash-tree TS = Time-stamp eDoc1 Judge

Evidence Record Structure EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) }, digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryption [1] EncryptionMethod OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence} Req.7 digestAlgorithms Req.10 cryptoInfos Req.9 encryption Req.1-6 archiveTimeStampSequence

Archive Time-Stamp ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] SEQUENCE OF {SEQUENCE OF OCTET STRING} OPTIONAL, timeStamp ContentInfo} ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain R.2-6 reducedHashtree R.1 timeStamp

Optional Encryption Caution: Encryption must be unambigious! Method: CMS-Encryption before archiving (Algorithms: RSA, DES-CBC) Archive Service time-stamps data as always add CMS-cover to CMS-encryption-params, store content seperately verification: reconstruction of archive time-stamped data object by decryption of content-encryption key, reencrypt content, insert content CMS_encryption_params::= SEQUENCE { encryptionCover ContentInfo, publicKey BIT STRING OPTIONAL, params CHOICE { [0] privateKey BIT STRING, [1] encryptionKeyRan EncryptionKeyRandom}} EncryptionKeyRandom::= SEQUENCE { encryptionKey OCTET STRING, randomValue BIT STRING}}

Appendices Optional Integration CMS: signed data Archive Time-Stamps-Element as an unsigned signature attribute for signature

Summary Syntax + Processing of ArchiveTimeStamp Element optimized for centralized time-stamping effective for large document volumes applicable for any data objects and groups of data objects normally no need to access data redundancy easy to realize compatible with existing services