Analysis of Client-side Security for Long-term Time-stamping Services

. Time-stamping services produce time-stamp tokens as evidences to prove that digital data existed at given points in time. Time-stamp tokens contain verifiable cryptographic bindings between data and time, which are produced using cryptographic algorithms. In the ANSI, ISO/IEC and IETF standards for time-stamping services, cryptographic algorithms are addressed in two aspects: (i) Client-side hash functions used to hash data into digests for nondisclosure. (ii) Server-side algorithms used to bind the time and digests of data. These algorithms are associated with limited lifespans due to their operational life cycles and increasing computational powers of attackers. After the algorithms are compromised, time-stamp tokens using the algorithms are no longer trusted. The ANSI and ISO/IEC standards provide renewal mechanisms for time-stamp tokens. However, the renewal mechanisms for client-side hash functions are specified ambiguously, that may lead to the failure of implementations. Besides, in existing papers, the security analyses of long-term time-stamping schemes only cover the server-side renewal, and the client-side renewal is missing. In this paper, we analyse the necessity of client-side renewal, and propose a comprehensive long-term time-stamping scheme that addresses both client-side renewal and server-side renewal mechanisms. After that, we formally analyse and evaluate the client-side security of our proposed scheme.


Introduction
Digital data is ubiquitous in our modern world. To prove the existence time of digital data, a time-stamping service produces verifiable cryptographic bindings between digital data and time to form time-stamp tokens. Such cryptographic bindings could be digital signatures, hash values, message authentication codes etc. Most of the bindings are generated through cryptographic algorithms. Therefore, time-stamp tokens are valid only when the underlying cryptographic algorithms remain secure.
For time-stamping services specified in the ANSI [1], IETF [2] and ISO/IEC [3][4][5][6] standards, the cryptographic algorithms used to generate time-stamp tokens could be categorized into two sides: (i) Client-side hash functions used to hash data into digests for nondisclosure; (ii) Server-side algorithms used to bind digests of a data item and a given point in time. These algorithms are time-restricted due to their limited operational life cycles and the increasing computational power of attackers [7]. For instance, the upcoming quantum computers are considered to break some broadly-used signature algorithms [8] and to increase the speed of attacking hash functions [9]. Once the algorithms are compromised, the corresponding time-stamp tokens are no longer valid.
However, for many types of digital data, the validity of time-stamp tokens need to be maintained for a long time. For example, the identity information of citizens should be kept permanently; the health records of people follow their lifetimes; mp3 files produced by musicians may last for decades etc. In these cases, the validity periods of time-stamp tokens need to be longer than any individual cryptographic algorithm's lifetime. For the purpose of this paper, if a time-stamping service (or scheme) is able to prove the existence of data at given points in time through valid and secure time-stamp tokens in a long period of time, which is not bounded with the lifetimes of underlying cryptographic algorithms, we say it is a Long-Term Time-Stamping (LTTS) service (or scheme). Clearly, for a long-term time-stamping service, time-stamp tokens should be constantly renewed.
The ANSI [1] and ISO/IEC [3][4][5][6] standards provide time-stamp renewal mechanisms for both client-side and server-side algorithms. For server-side renewal, the standards clearly say that a requester sends a time-stamp request with inputting a new server-side algorithm identifier, hash value(s) of a data item, and a previous timestamp token on this data item to a Time-Stamping Authority (TSA), the TSA then produces a new time-stamp token on the input content using the indicated algorithm.
However, the client-side renewal mechanisms in both standards are specified ambiguously. In the ISO/IEC standard, the renewal of client-side hash functions is not mentioned as a motivation for time-stamp renewal, and how to implement the client-side renewal is not explicitly specified. In the ANSI standard, a list of reasons for time-stamp renewal includes that a requester needs to replace the hash value using a stronger hash function, but when a requester "needs" to replace the hash value is not specified in detail. These ambiguities may cause the failure of client-side renewal implementations and therefore the failure of long-term time-stamping services.
In the existing papers [10] and [11], long-term time-stamping schemes based on signatures and hash functions have been formally analysed respectively (the details will be introduced in Section 2). Nevertheless, the analyses are only related to renewal mechanisms of server-side algorithms, the client-side renewal is not covered. Specifically, in the security model of [10], the client-side renewal is not discussed, and client-side hash functions are treated as random oracles. This security notion does not truly model the case of practical implementations. In [11], the client-side hash functions are not considered.
The motivation of this work is based on the following observation. The security of client-side is as significant as server-side, since the time-stamp tokens are generated on the hash values of data items. If the client-side hash functions are broken and the client-side renewal mechanism is not performed effectively, the time-stamp tokens are no longer valid regardless whether the server-side is secure or not. Even if a client-side renewal mechanism is clearly specified, a formal security analysis of the mechanism is necessary and it does not exist in the literature.
In this paper, we provide following contributions: -We firstly analyse several possible failures of client-side renewal implementations by complying with the ANSI and ISO/IEC standards, and discuss the importance of a well-specified client-side renewal mechanism. -We then propose a comprehensive long-term time-stamping scheme that addresses both client-side and server-side renewal mechanisms.
-After that, we formally analyse the client-side security of our proposed long-term time-stamping scheme, and provide a quantified evaluation to the client-side security level.

Related works
In 1990 [12], Haber and Stornetta introduced the first concept of digital time-stamping with two techniques: linear linking and random witness. In this paper, they also proposed a solution for time-stamp renewal, in which a time-stamp token could be renewed by time-stamping the token with a new implementation before the old implementation is compromised.
In 1993 [13], Bayer, Haber and Stornetta proposed another time-stamping technique: publish linked trees into a widely visible medium (e.g., newspapers). Besides, they spotted that the renewal idea in the 1990 paper [12] is insufficient to time-stamp a digital certificate alone (without the original data being certified). They proposed a corrected renewal solution: time-stamping a (data, signature) pair or a (data, time-stamp) pair to extend the signature or time-stamp's lifetime.
In further years, the ideas of [12,13] have been polished and recorded into various standards: The NIST standard specified several signature-based time-stamping applications for proving time evidences of digital signatures [14]; the IETF standard [2] (an update is [15]) specified signature-based time-stamping protocols; the ISO/IEC and ANSI standards cover various time-stamping mechanisms and renewal mechanisms. Notice that the time-stamping services in both the NIST and IETF are not specified in long-term, the ANSI and ISO/IEC standards contain the specifications for long-term time-stamping services.
Apart from the standards, the ideas of [13] have been extended into several long-term integrity schemes [16][17][18][19][20][21][22], but the security analyses of such schemes were not given until 2016, Geihs et al. formalized this idea separately into a signature-based long-term integrity scheme [10], and a hash-based long-term time-stamping scheme [11] in 2017. These two schemes are related to the security of two types of server-side algorithms: signature schemes and hash functions, and their renewal mechanisms, but the renewal mechanisms for client-side hash functions are not addressed. In [10], the client-side hash functions are ideally modelled as random oracles, and the renewal of client-side hash functions is not discussed; in [11], the client-side hash functions are not considered in the scheme, time-stamp tokens carry out on actual data items.
Similarly, in Geihs' PhD thesis [23] (includes [10,11]), the signature-based timestamping scheme is slightly different with [10]: time-stamp tokens are created on a data item and signature pair, and the consideration of client-side hash functions is removed. For all these analyses [10,11,23], the client-side security is guaranteed with ideal assumptions.
Nevertheless, the papers [10,11,23] provide substantial frameworks for analysing the security of long-term time-stamping schemes. For example, they presented a new computational framework based on [24], and a global time model based on [25] for modelling the computational power of long-lived adversaries; they created "longterm unforgeability" model for the integrity of signature-based time-stamping [10]; they constructed "long-term extraction" model for the integrity of hash-based timestamping [11], which is an integration of "extraction-based" time-stamping proposed in [26] and "preimage awareness" hash functions defined in [27].
In addition, the security of hash functions in time-stamping has been explored [28][29][30][31], and only in [29] Buldas et al. analysed the security of client-side hash functions. They proposed a new notion named "unpredictability preservation" and argued that this property, rather than collision resistance or second preimage resistance (the definitions are in Section 3.1), is necessary and sufficient for client-side hash functions in secure time-stamping. However, their conclusions are not in the case of long-term time-stamping since the time-stamping renewal is not considered in their works.
In this paper, we create a "long-term integrity" model for our long-term timestamping scheme including both client-side and server-side renewal (will be introduced in Section 6.3). In this model, we follow the computational framework of long-lived adversaries, and refer to the analysis results of server-side security in [10,11,23]. In our analysis, we mainly focus on analysing the security at the client-side.

Review the ANSI and ISO/IEC time-stamping services
The ISO/IEC 18014 standard specifies time-stamping services in four parts: the framework in Part 1 [3], mechanisms producing independent tokens in Part 2 [4], mechanisms producing linked tokens in Part 3 [5], and traceability of time sources in Part 4 [6]. The ANSI X9.95 standard [1] specifies both independent and linked tokens, which are similar to the mechanisms specified by the ISO/IEC in [3][4][5].
In this section, we review some common specifications from the first three parts of the ISO/IEC 18014 [3][4][5] and the ANSI X9.95 [1] standards, which includes the definition of hash functions, two types of time-stamp tokens and time-stamp transactions between entities.

Hash functions
A secure hash function [32] maps a string of bits of variable (but usually upper bounded) length to a fixed-length string of bits, satisfying the following three properties: -Preimage Resistance: it is computationally infeasible to find, for a given output, an input which maps to this output. -Second Preimage Resistance: it is computationally infeasible to find a second input which maps to the same output. -Collision Resistance: it is computationally infeasible to find any two distinct inputs which map to the same output.
Note that the hash functions discussed in this paper are compression functions. That means, the collision resistance of a hash function implies preimage resistance [33,34]. In other words, if a hash function is collision resistant, then it is also preimage resistant; if a hash function is not preimage resistant, then it is not collision resistant.

Types of time-stamp tokens
There are two types of time-stamp tokens that can be generated by a time-stamping service: 1. Independent tokens: An independent time-stamp token can be verified without involving other time-stamp tokens. The protection mechanism used to generate this type of tokens can be digital signatures, message authentication codes (MAC), archives or transient keys [1]. For instance, for signature-based time-stamping, a Time-Stamping Authority (TSA) digitally signs a data item and a time value that results a cryptographic binding between the data and time. The data, time and the corresponding signature together form a time-stamp token. 2. Linked tokens: A linked time-stamp token is associated with other time-stamp tokens produced by the same methods. The protection mechanism used to generate this type of tokens can be hash functions and a public repository, therefore a time-stamping service generating this type of tokens is referred to "hash-based time-stamping" or "repository-based time-stamping". In specific, a TSA hashes a data item and a time value together and aggregates the hash output with other data items produced at the same time, (e.g., uses a Merkle Tree [35]). The aggregation result can be linked to other data produced at previous times, (e.g., uses linear chain linking [12]). Eventually, the aggregation or linking result is published at a widely visible media (e.g., newspapers). The data, time record, published information, and group values that are contributed to determine the published result, together form a time-stamp token.

Time-stamp transactions
There are two time-stamp transactions that are performed between a requester and one or more TSAs, or between a requester and a verifier, respectively: 1. Time-stamp request transaction: A requester sends a time-stamp request to a TSA and the TSA returns a time-stamp response to the requester. 2. Time-stamp verification transaction: A requester sends a verification request to a verifier and the verifier returns a verification response to the requester.
The data formats of a time-stamp request and response are shown in Fig. 1. A timestamp request contains a "messageImprint" field, which is comprised of a hash value of a data item and its hash function identifier, an "extensions" field and other information.
More specifically, the "extensions" field contains three types of additional information: ExtHash, ExtMethod and ExtRenewal, which work as follows: 1. ExtHash: In this field, a requester could submit multiple "messageImprint" fields, in which each hash value could be computed from a different hash function so that it prevents the failure of any single hash function. 2. ExtMethod: In this field, a requester could indicate a specific protection mechanism (e.g., a digital signature scheme) to bind the data item and time. After the TSA receives the request, it adds the current time to the request content to form a "TSTInfo" structure, and produces a cryptographic binding on the TSTInfo by using the indicated protection mechanism or a default one if it is not indicated. The TSTInfo and the cryptographic binding together form a time-stamp token, then the TSA returns a time-stamp response with the time-stamp token to the requester.
In order to validate the time-stamp token, the requester could send a verification request that contains the time-stamp token to a verifier at time t v . For a single time-stamp token that has not been renewed, the verifier checks the following: -The token is syntactically well-formed.
-Every hash value of the data item is correctly computed through the corresponding hash function. -At least one of the hash functions that is used to generate digests of the data item is collision resistant at t v . -The protection mechanism of the time-stamp token is not broken at t v .
-The cryptographic binding is correctly computed on the data and time.
If all above conditions are held, the time-stamp token is valid at time t v , so the verifier returns a verification response with a "true" result to the requester. Otherwise, the verifier returns a "false" result to the requester.
For a renewed time-stamp token, the verifier checks the validity of each nested time-stamp token at the time it was generated or renewed, and validity of the latest time-stamp token at t v following the above checking steps. The verifier returns a verification response with a "true" result to the requester if all verifications are successful, or a "false" otherwise.

Discussions on client-side renewal
In Section 3, we have reviewed some common specifications in the ANSI and ISO/IEC time-stamping services. In this section, we observe that the client-side renewal mechanisms in both standards are not explained thoroughly, which may cause some ambiguities for implementations. To make our discussions clear, we analyse several possible scenarios that the client-side hash functions are not renewed correctly by following the standards and their consequences.

The ambiguities in the ANSI and ISO/IEC standards
As specified in Section 3.3, a time-stamp token consists of hash value(s) of a data item, a time value and a cryptographic binding. The cryptographic algorithms used in the token include client-side hash functions and server-side algorithms. However, the lifetimes of these cryptographic algorithms are restricted due to the operational life cycles or advanced computational architectures. Once the algorithms are compromised, the time-stamp token becomes invalid and the existence of the data item could not be proved after that. Thus, time-stamp tokens should be constantly renewed to extend their validity periods.
In both the ANSI and ISO/IEC standards, the server-side renewal could be achieved by using the "ExtMethod" and "ExtRenewal" fields as following: when the server-side algorithm in the time-stamp token is close to the end of its lifecycle, or there is strong evidence that it will be compromised in the near future, the requester associates the time-stamp token in the "ExtRenewal" field, and indicates a new server-side algorithm in the "ExtMethod" field. The TSA then maintains these contents in the "TSTInfo" structure, and generates a new time-stamp token on TSTInfo using the indicated algorithm.
For client-side hash functions, as Section 3.3 shows, the ISO/IEC and ANSI standards both introduce the "ExtHash" field that allows multiple hash values of a data item to be submitted in the time-stamp request, but how to renew the client-side hash functions are not introduced clearly. For example, as the quote from the ISO/IEC 18014-1 [3], Section 5.7, Time-stamp renewal: "Time-stamped data may be time-stamped again at a later time. This process is called time-stamp renewal and may optionally be implemented by the TSA. This may be necessary for example for the following reasons: -The mechanism used to bind the time value to the data is near the end of its operational life cycle (e.g., when using a digital signature and the public key certificate is about to expire). -The cryptographic function used to bind the time value to the data is still trusted; however, there is strong evidence that it will become vulnerable in the near future (e.g., when a hash function is close to begin broken by new attacks or available computing power). -The issuing TSA is about to terminate operations as a service provider." We can see that the "mechanism used to bind the time value and data" and "cryptographic function used to bind the time value to the data" do not include the client-side hash functions, which means that the client-side hash functions are not defined as a motivation for time-stamp renewal. Apart from this, there are no other specifications in the ISO/IEC standard about how to renew client-side hash functions.
In the ANSI standard [1], the client-side renewal is briefly addressed in the definition of the "renewal" term, as the quote from the ANSI X9.95 [1], Section 3.29, Renewal: -"A renewal is the extension of the validity of an existing time stamp token.
Legitimate reasons to renew a TST include: (i) the public key certificate used to verify the TSA digital signature is nearing its expiration date, or (ii) a requestor needs to replace the hash value using a stronger hash algorithm. " We can see that "a requestor could replace the hash value using a stronger hash algorithm" is a statement that allows requesters to replace the client-side hash value, but when to replace the hash value, how many hash values should be replaced are not specified. The ambiguities in both standards may mislead the implementers to ignore or improperly operate client-side renewal.

Possible failed implementations of client-side renewal
Based on the observations in Section 4.1, we further analyse some possible scenarios for implementations that do not effectively renew client-side hash functions. Note that the following three cases are arguably compatible with both the ISO/IEC and ANSI time-stamping standards. Case 1: Let D denote a data item, and the hash value of D is h 0 , which is computed through a client-side hash function H 0 , i.e., h 0 = H 0 (D). The requester sends the pair (h 0 , H 0 ) to a TSA, the TSA generates a time-stamp token T ST 0 at time t 0 . When the server-side algorithm in T ST 0 is nearly compromised, the requester sends (h 0 , H 0 , T ST 0 ) to a TSA, the TSA produces a new time-stamp token T ST 1 on the input at time t 1 . Repeat the server-side renewal in a long-term period, the requester eventually has T ST 0 , ..., T ST n (n∈N ).
Assume the collision resistance of H 0 is broken at time t b0 . After t b0 , the verification condition "at least one client-side hash function is not broken at t v " is failed. Thus, time-stamp tokens generated after t b0 are verified as "false", the time-stamping service could prove the existence time of data item D at most between t 0 and t b0 . After t b0 , any server-side renewal does not extend the validity of time-stamp tokens any more. Assume the collision resistance of H 0 , ..., H m are all broken at time t bm . After t bm , the verification condition "at least one client-side hash function is not broken at t v " is failed. The time-stamp tokens produced after t bm are verified as "false", the time-stamping service could prove the existence time of D at most between t 0 and t bm , not any longer.
Case 3: With the same notation as in Case 2, if the requester replaces one or more hash values in h 0 , ..., h m using stronger hash functions at time t 1 > t bm , for the same reason as Case 1 and Case 2, the new time-stamp token generated at t 1 is valid, but the time-stamp tokens generated before t 1 are verified as "false". The time-stamping service only proves the existence of D at t 1 or after, and certainly can not prove its existence at time t 0 .
Summary: If a requester does not renew client-side hash functions correctly, the time-stamping service is only able to prove the existence of data items with limited time periods, when at least one of the client-side hash functions in the set is collision resistant. Multiple hash values only extend the lifetime of a single hash function, but the overall lifetime of them is still limited. In other words, a time-stamping service without correct client-side renewal does not satisfy the definition of "long-term" in Section 1. In order to achieve a long-term time-stamping service, the client-side renewal is necessary and should be specified clearly.

Proposed long-term time-stamping scheme
In this section, we propose a comprehensive long-term time-stamping scheme that describes how the client-side hash functions and server-side algorithms are used and renewed. Notice that the server-side protection mechanism is not described as a particular one, which could be any of the mechanisms for an independent token or a linked token, as specified in either the ISO/IEC 18014-2 [4], ISO/IEC 18014-3 [5] or the ANSI X9.95 [1].  Our proposed scheme has three functionalities: time-stamp generation, time-stamp renewal and time-stamp verification. Fig. 2 shows the time-stamp generation and renewal together, the notation is listed in Table 1. For simplicity, we assume that each hash value also contains its hash identifier, e.g., we denote (h . Note that some message formats that are not relevant to security analysis are omitted.

Time-stamp generation
As the top row in Fig. 2, at time t 0 (i=0): a requester computes one or more hash values of D and sends them to a TSA. i.e., h * 0 =H * 0 (D). The TSA generates a cryptographic binding C 0 on (h * 0 , t 0 ), and returns the time-stamp token T ST 0 :=(h * 0 , t 0 , C 0 ) to the requester. *Note that the message format of C i depends on the server-side protection mechanisms and their details are not discussed in this paper. We stress that the scheme is applicable for any type of server-side protection mechanism.

Time-stamp verification
At the verification time t v , the verifier receives a time-stamp token T ST i (i∈{0, n}) and checks the following conditions: -The server-side algorithm used in C 0 and C 1 are secure at the time the one for C 0 is renewed, ..., the server-side algorithm used in C i−1 and C i are secure at the time the one for C i−1 is renewed, the server-side algorithm for C i is secure at t v .
-Cryptographic binding C 0 , ..., C i are correctly computed on the corresponding input content.
If all above conditions are satisfied, we say the time-stamp token T ST i is valid at time t v , and the verifier returns "true" to the requester if the verifications are successful. Otherwise, return a "false" to the requester. The valid time-stamp token T ST i indicates that the data item D existed at the time t 0 .

Security notions
In this section, we formalize the syntax of a long-term time-stamping scheme, the security assumptions that are required for analysis, and the security properties that a long-term time-stamping scheme should satisfy.

Syntax of a long-term time-stamping scheme
As defined as follows, a comprehensive long-term time-stamping scheme consists of three algorithms, which are respectively associated with time-stamp generation, time-stamp renewal and time-stamp verification.

Security assumptions
In the following models and proofs, we assume that 1. The verifier correctly performs the verification algorithm. 2. TSAs correctly perform the T SGen and T SRen algorithms. 3. The verification data V D is trusted and cannot be tampered. 4. Each cryptographic algorithm is associated with a validity period and provides correct outputs within their validity periods.

Security models and definitions
A long-term time-stamping (LTTS) scheme should achieve three security properties: correctness, nondisclosure, and long-term integrity. The formal definitions of these properties are given as follows: Correctness. This property means that assuming every entity is honest, a long-term time-stamping scheme is able to prove existence of data items in a long period of time that is not bounded with the lifetimes of underlying cryptographic algorithms. The formal definition of correctness is given below. For a long-term time-stamping scheme to be correct, it must satisfy that if a time-stamp token T ST n is generated for any data item D following the above process, the verification algorithm outputs T SV er(D, T ST n , V D, t v )=1.
Nondisclosure. This property means that the data item to be time-stamped is not exposed to any party except for the requester and verifier. Similar to the definition of a long-term time-stamping scheme, if the nondisclosure could be achieved with limited duration that is bounded by the lifetimes of corresponding cryptographic algorithms, we say it is short-term nondisclosure, otherwise it is long-term nondisclosure. The formal definition of nondisclosure in a long-term time-stamping scheme is as follows.
Definition 3. (Nondisclosure.) A long-term time-stamping service provides nondisclosure for data items to be time-stamped if it is computationally infeasible for any party except the requester and verifier to reveal the data items.
Long-term Integrity. The security notion of long-term integrity is based on the concept of "compromising" a time-stamping scheme. In specific, we say an attacker is able to compromise a time-stamping scheme, if it is able to claim that a data object exists at a point in time that actually it does not exist, or to tamper valid time-stamp tokens without being detected. Thus, we say a time-stamping scheme has "long-term integrity" if an attacker is unable to compromise the time-stamping scheme in a long period of time that is not bounded with the lifetimes of underlying cryptographic algorithms.
The long-term integrity model is defined as a game running between a longlived adversary A, a simulator B and a set of TSAs. As same in [10,11,23], A is modelled as a set of computing machines that have abilities to develop computational power and computing architectures with time increasing, but also being restricted within each time period. B has computational resources comparable to A. Besides, A is able to advance time by calling a global clock oracle Clock(t), and communicate with TSAs through available queries in different time periods. Based on timely manner, the long-term integrity model could be divided into two stages:  We denote the probability that A wins the game as A LT I LT T S . Until time t v , the sum probability that B breaks at least one client-side hash function within its validity period is denoted as B CS tv , and the sum probability that B breaks at least one serverside algorithm within its validity period is denoted as B SS tv . Furthermore, we define the B Cryp

Security analysis
In terms of the security models and definitions in Section 6.3, we now prove our proposed long-term time-stamping scheme holding each security property. Third, since the algorithm T SRen is implemented every time before client-side hash functions in the latest time-stamp tokens are all broken, and also before the server-side algorithm in the latest cryptographic binding is compromised, the validity or client-side hash functions and server-side algorithms are all guaranteed at their renewal times. With the assumption that at t v , at least one client-side hash function in T ST n is still collision resistant, and the server-side algorithm in T ST n is still secure, all verification steps are satisfied. Therefore, the verification algorithm outputs T SV er(D, T ST n , V D, t v )=1 and the theorem follows. Then at time t 0 <t<t pf , if an attacker is able to find a preimage for any of h 0 , ..., h m with non-negligible possibilities, the preimage resistance of at least one of H 0 , ..., H m is broken within its validity period, which contradicts our assumption. After time t pf , the attacker is able to attack at least the hash function H f that determine preimages of h f to D with non-negligible possibilities. Thus, the proposed time-stamping scheme provides short-term nondisclosure in the duration (t 0 , t pf ). Therefore, the theorem follows.

Proof of long-term integrity
Based on the assumptions discussed in Section 6.2, TSAs and the verifier are trusted parties and always perform operations correctly. The integrity of data objects only relies on the security of client-side hash functions and server-side algorithms. In this paper, we do not limit out discussion with a specific server-side protection mechanism. A time-stamp token could be any type as introduced in Section 3.2.
For the security of server-side mechanisms, the existing security analyses from [10] and [11] have proved the security of a signature-based long-term time-stamping scheme as well as a hash-based one. As introduced in Section 2, these two schemes satisfy the long-term integrity property under the condition that client-side security is guaranteed. Thus, their results can be fitted in our analysis. We assume that server-side security is satisfied in our proposed scheme, and focus on the analysis of client-side security. In other words, as defined in Section 6.3, the probability of the adversary breaking the scheme through server-side is reduced to B SS tv . Theorem 3. If the security of server-side is guaranteed, the proposed time-stamping scheme has long-term integrity.
a part of T ST 1 . Now repeating the previous situation, A can submit (H * 2 (x), T ST 1 ) for requesting another time-stamp renewal and obtains T ST 2 (Case 1) or A may submit (H * 2 (x ), T ST 1 ) for requesting another time-stamp renewal and obtains T ST 2 (Case 2). Again, Case 2 allows B to obtain a pair of collisions satisfying H 1j (x)=H 1j (x ) and it contradicts the assumption, and Case 1 leads us to continue our reasoning.
Carrying on our argument as before, only Case 1 for each time-stamp renewal is considered. We assume that H (n−1)j for j ∈ {1, m (n−1) } is collision resistant at both t n−1 and t n , and the hash value H (n−1)j (x) is a part of T ST n−1 . If A finally submits (H * n (x ), T ST n−1 ) and successfully obtains T ST n , then B obtains a pair of collisions (x, x ) satisfying H (n−1)j (x)=H (n−1)j (x ).
In summary, based on the above reasoning, as long as A wins the game, B can break at least one client-side hash function within its validity period. Therefore, the winning probability of A through client-side is reduced to the same level of the probability that B breaks at least one client-side hash function within its validity period. With adding the probability of the failure of server-side algorithms B SS tv , there exists a constant c such that: Thus, we have proved Theorem 3.

Evaluations of client-side security level
In this section, we determine the client-side security level L CS in practical, which represents the probability of a long-lived adversary as defined in Section 6.3 breaks the client-side security of the proposed scheme. In terms of the ISO/IEC and ANSI standards, multiple hash values are allowed in every time-stamp request, and the system is available to set up policies for the number of client-side hash functions in every time-stamp request, and the interval of time-stamp renewal. Therefore, there are two parameters that affect the client-side security level: 1. l set : the security level of a set of client-side hash functions in a time-stamp request, which means the probability that a long-lived adversary as defined in Section 6.3 breaks all collision resistant hash functions in the set within their validity periods. 2. n: the number of sets of client-side hash functions in time-stamp tokens, which means the number of client-side renewal process.
Assume the security level of each set of client hash functions are l set 1 , ..., l set n respectively. The winning probability of the adversary is the aggregated probability of the failure of every set of client-side hash functions: We can see that the more sets of client-side hash functions are used in the scheme, the higher probability that the adversary breaks the client-side security of the proposed scheme. The stronger of each set of client-side hash functions, the lower probability that the adversary breaks the client-side security of the proposed scheme.
Furthermore, the security level of a set of client-side hash functions l set is decided by another two parameters: 1. l: the security level of a specific client-side hash function in the set, which means the probability of a long-lived adversary as defined in Section 6.3 breaks the collision resistance of the specific hash function within its validity period. 2. m: the number of client-side hash functions required in a set.
Assume the security level of each hash function in a set is l 1 , ..., l m respectively. Then the probability of the failure of a whole set of hash functions, is equal to the probability that every hash function in the set fails: Based on the bounded computational resources in each time period, a long-lived adversary has not enough resources to break the collision resistance of whole set of hash functions. That means, the computational resources of the adversary is not enough to break at least one of the hash functions in the set. If the adversary owns computational power to break some of the hash functions, then the security level of these hash functions are equal to 1, the l set is only determined by the security level of the other hash functions.
Summary: The evaluation results show that with more times the client-side renewal happens, the probability of the adversary breaks the scheme increases; for multiple hash values submitted in each time-stamp request, the more collision resistant hash functions are required in each time-stamp request, the lower probability of the adversary breaks the scheme.

Conclusions
In this paper, we have discussed the importance of client-side renewal: it is not enough for a requester to only use the same set of multiple hash values in an initial timestamping request as well as a time-stamp renewal request, new hash values computed through stronger hash functions should be used before the failure of current set of hash functions. This argument is straightforward but is not explicitly addressed in the ISO/IEC and ANSI standards. Then we propose a long-term time-stamping scheme with specifications of both client-side and server-side mechanisms. We have proved that our scheme achieves correctness, short-term nondisclosure and long-term integrity properties. Finally, we have provided a quantified evaluation for the client-side security level of our proposed scheme.
We argue that the short-term nondisclosure of our scheme could be accepted, since the integrity could naturally be required for much longer time than nondisclosure. For instance, intellectual-property data is usually protected in secret for a certain period before it is released but its integrity should be maintained in perpetuity.
As the future work, we will implement the proposed scheme in a time-stamping service environment to measure the timing overhead and to determine the network channel affectation. Besides, our research could be carried on covering other renewable applications that require long-term integrity. The renewal mechanisms in time-stamping services may have other application scenarios and such applications and their security analyses should be explored.