ISO/IEC TR 29149:2012
(Main)Information technology — Security techniques — Best practices for the provision and use of time-stamping services
Information technology — Security techniques — Best practices for the provision and use of time-stamping services
ISO/IEC TR 29149:2012 explains how to provide and use time-stamping services so that time-stamp tokens are effective when used to provide timeliness, data integrity, and non-repudiation services in conjunction with other mechanisms. It defines: how time-stamp requesters should use time-stamp token generation services; how TSAs (time-stamping authorities) should provide a service of guaranteed quality; how TSAs should deserve trust based on good practices; which algorithms and parameters should be used in TST (time-stamp token) generation and TST renewal, so that TSTs resist during the time period during which the TSTs can be verified as being valid; how time-stamp verifiers should use the time-stamp token verification services, both when validating individual TSTs, and when validating sequences of renewal TSTs.
Technologies de l'information — Techniques de sécurité — Meilleures pratiques pour la fourniture et l'utilisation de services d'horodotage
General Information
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
29149
First edition
2012-03-15
Information technology — Security
techniques — Best practices for the
provision and use of time-stamping
services
Technologies de l'information — Techniques de sécurité — Meilleures
pratiques pour la fourniture et l'utilisation de services d'horodotage
Reference number
ISO/IEC TR 29149:2012(E)
©
ISO/IEC 2012
---------------------- Page: 1 ----------------------
ISO/IEC TR 29149:2012(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2012 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 29149:2012(E)
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Terms and definitions . 1
3 Symbols and abbreviated terms . 4
4 Time-stamping services. 5
5 Use cases for non-repudiation . 5
5.1 Introduction . 5
5.2 Use case #1 . 6
5.3 Use case #2 . 6
5.4 Use case #3 . 6
6 Potential issues . 7
6.1 Security requirements for custody of evidences . 7
6.2 Weak cryptography: hash-functions . 8
6.3 Weak cryptography: digital signatures . 10
6.4 Weak cryptography: message authentication codes . 10
6.5 Signature verification . 10
6.6 Time-stamp token renewal . 11
6.7 Time-stamping service availability . 12
6.8 Time-stamping service continuity . 12
7 Recommendations . 12
7.1 Recommendations for requesters of time-stamp tokens . 12
7.2 Recommendations for verifiers of time-stamp tokens . 13
7.3 Recommendations for time-stamp service providers . 13
7.4 Recommendations for signature verification . 16
7.5 Non-repudiation policy . 17
8 Algorithms . 17
8.1 Overview . 17
8.2 Hash functions . 17
8.3 Keyed message authentication algorithms . 18
8.4 Signature algorithms . 18
Bibliography . 19
© ISO/IEC 2012 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 29149:2012(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, when the joint technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may decide to
publish a Technical Report. A Technical Report is entirely informative in nature and shall be subject to review
every five years in the same manner as an International Standard.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 29149 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
iv © ISO/IEC 2012 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 29149:2012(E)
Introduction
This Technical Report explains how to provide and use time-stamping services so that time-stamp tokens are
effective when used to provide
timeliness and data integrity services, or
non-repudiation services (in conjunction with other mechanisms).
ISO/IEC 18014 specifies time-stamping services, explaining how to generate, renew, and verify time-stamp
tokens. The goal of a non-repudiation service is to treat evidence concerning a claimed event or action in
order to resolve disputes about the occurrence or non-occurrence of the event or action. Depending on the
non-repudiation service which is required, the non-repudiation policy in effect for a specific application, and
the legal environment within which the application operates, time-stamp tokens from time-stamping
authorities may be required as components of non-repudiation information.
© ISO/IEC 2012 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 29149:2012(E)
Information technology — Security techniques — Best
practices for the provision and use of time-stamping services
1 Scope
This Technical Report explains how to provide and use time-stamping services so that time-stamp tokens are
effective when used to provide timeliness, data integrity, and non-repudiation services in conjunction with
other mechanisms. It defines:
how time-stamp requesters should use time-stamp token generation services;
how TSAs (time-stamping authorities) should provide a service of guaranteed quality;
how TSAs should deserve trust based on good practices;
which algorithms and parameters should be used in TST (time-stamp token) generation and TST renewal,
so that TSTs resist during the time period during which the TSTs can be verified as being valid;
how time-stamp verifiers should use the time-stamp token verification services, both when validating
individual TSTs, and when validating sequences of renewal TSTs.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
certification authority
CA
authority trusted by one or more users to create and assign public-key certificates
NOTE Optionally, the certification authority may create the users' keys.
[ISO/IEC 9594-8:2005]
2.2
digital signature
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to
prove the source and integrity of the data unit and protect against forgery, e.g. by the recipient
[ISO 7498-2:1989]
2.3
evidence
information which is used, either by itself or in conjunction with other information, to establish proof about an
event or action
NOTE Evidence does not necessarily prove the truth or existence of something, but can contribute to the
establishment of such a proof.
[ISO/IEC 13888-1:2009]
© ISO/IEC 2012 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC TR 29149:2012(E)
2.4
evidence user
entity that uses non-repudiation evidence
[ISO/IEC 13888-1:2009]
2.5
hash-function
function which maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
It is computationally infeasible to find for a given output, an input which maps to this output.
It is computationally infeasible to find for a given input, a second input which maps to the same output.
NOTE Computational feasibility depends on the specific security requirements and environment.
[ISO/IEC 10118-1:2000]
2.6
hash-value
string of bits which is the output of a hash-function
[ISO/IEC 10118-1:2000, modified — The term “hash-code” is used to represent this concept in
ISO/IEC 10118-1:2000.]
2.7
imprint
string of bits, either the hash-value of a data string or the data string itself
[ISO/IEC 13888-1:2009]
2.8
message authentication code
MAC
string of bits which is the output of a MAC algorithm
NOTE A MAC is sometimes called a cryptographic check value (see for example ISO 7498-2).
[ISO/IEC 9797-1:2011]
2.9
non-repudiation
ability to prove an action or event has taken place, so that this event or action cannot be repudiated later
[ISO 7498-2:1989]
2.10
non-repudiation token
special type of security token as defined in ISO/IEC 10181-1, consisting of evidence, and, optionally, of
additional data
[ISO/IEC 13888-1:2009]
2.11
object identifier
OID
globally unique value associated with an object to unambiguously identify it
[ISO/IEC 8824-1:2002│ITU X.680:2002]
2 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 29149:2012(E)
2.12
private key
that key of an entity's asymmetric key pair which should only be used by that entity
[ISO/IEC 9798-1:1997]
2.13
public key
that key of an entity's asymmetric key pair which can be made public
NOTE In the case of an asymmetric signature scheme, the public key defines the verification transformation. In the
case of an asymmetric encipherment system, the public key defines the encipherment transformation. A key that is
'publicly known' is not necessarily globally available. The key may only be available to all members of a pre-specified
group.
[ISO/IEC 11770-3:2008]
2.14
public key certificate
public key information of an entity signed by the certification authority and thereby rendered unforgeable
[ISO/IEC 11770-3:2008]
2.15
signer
entity generating a digital signature
[ISO/IEC 13888-1:2009]
2.16
time stamp
data item which denotes a point in time with respect to a common time reference
[ISO/IEC 11770-1:2010]
2.17
time-stamp token renewal
process of issuing a new time stamp token to extend the validity period of an earlier time-stamp token
[ISO/IEC 18014-1:2008, adapted]
2.18
time-stamp requester
entity which possesses data it wants to be time-stamped
NOTE A requester can also be a trusted third party including a time-stamping authority.
[ISO/IEC 18014-1:2008]
2.19
time-stamp token
TST
data structure containing a verifiable binding between a data items’ representation and a time-value
NOTE A time-stamp token can also include additional data items in the binding.
[ISO/IEC 18014-1:2008]
© ISO/IEC 2012 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC TR 29149:2012(E)
2.20
time-stamp verifier
entity which possesses data and wants to verify that it has a valid time-stamp bound to it
NOTE The verification process may be performed by the verifier itself or by a trusted third party.
[ISO/IEC 18014-1:2008]
2.21
time-stamping authority
TSA
trusted third party trusted to provide a time-stamping service
[ISO/IEC 18014-1:2008]
2.22
time-stamping policy
named set of rules that indicates the applicability of a time-stamp token to a particular community or class of
application with common security requirements
[ISO/IEC 18014-1:2008]
2.23
time-stamping service
TSS
service providing evidence that a data item existed before a certain point in time
[ISO/IEC 18014-1:2008]
2.24
trusted third party
TTP
security authority, or its agent, trusted by other entities with respect to security related activities
[ISO/IEC 10181-1:1996]
3 Symbols and abbreviated terms
In the remainder of this document the following notation will be used:
HMAC Hash Message Authentication Code
H(D) The hash-value of data D, using hash-function H
MAC Message Authentication Code
OID Object Identifier
PKI Public Key Infrastructure
S (y) The signature computed on data y using a signature algorithm and the private key of
X
entity X
TSA Time-Stamping Authority
TSP Time-Stamp Packet: the combination of the TST and the data upon which the TST is
generated
4 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 29149:2012(E)
TSS Time-Stamping Service
TST Time-Stamp Token
TST(D, t) time-stamp token on data D, at point in time t
4 Time-stamping services
Time-stamping services include generation, renewal, and verification of time-stamp tokens, as defined in
ISO/IEC 18014-1.
Time-stamp tokens are associations between data and points in time, and are created in a way that aims to
provide evidence that the data existed before the associated date and time. This evidence may be used by
non-repudiation services.
Time-stamping services involve the following entities (from ISO/IEC 18014-1):
the time-stamp requester, that has some data (e.g. a document) to time-stamp;
the Time-Stamping Authority (TSA), that generates time-stamp tokens (TST);
the time-stamp verifier, that verifies time-stamps bound to data.
Time-stamping services (TSS) provide three specific services:
time-stamp token generation, where the requester submits data items, and receives a time-stamp
token; this service is provided by the TSA;
time-stamp token renewal, a special case of time-stamp token generation, where the requester
submits an existing first time-stamp token and related data items, and receives a new time-stamp
token, such that the validity period of the first time-stamp token is extended by the new time-stamp
token; this service is provided by the TSA;
time-stamp token verification, when the verifier validates the time-stamp token; this service may also
involve the TSA or other trusted third parties.
Users of the time-stamping services handle time-stamp packets (TSP), encompassing the data plus the time-
stamp token (TST).
5 Use cases for non-repudiation
5.1 Introduction
Time-stamping services provide tokens that may be used, in combination with an adequate non-repudiation
policy, to support non-repudiation claims.
Non-repudiation services provide a user B with protection against another user A later denying that an action
or event has taken place. While these services do not prevent A from trying to repudiate B’s claim, they
provide evidence to support the resolution of such disagreement. In general, the evidence needs to be
convincing to a third party arbitrator C.
The following clauses present some use cases.
© ISO/IEC 2012 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC TR 29149:2012(E)
5.2 Use case #1
Non-repudiation services
Data D existed before time t.
Integrity of data D is guaranteed after time t.
Evidence generation
1. User A has some data D.
2. A gets a time-stamp token on D at t: TST(D, t).
Evidence verification
1. User B receives a time-stamp packet TSP(D, TST(D, t)).
2. B checks that the TST corresponds to the data D, and verifies TST(D, t).
5.3 Use case #2
Non-repudiation services
Data D existed before time t.
User A signed D before time t.
Integrity of data D is guaranteed after time t.
Evidence generation
1. User A has some data D.
2. A signs D: S (D).
A
3. A gets a time-stamp token on S (D) at t: TST(S (D), t).
A A
Evidence verification
1. User B receives the data D and a time-stamp packet TSP(S (D), TST(S (D), t)).
A A
2. B checks that the TST corresponds to S (D), and verifies the TST.
A
3. B verifies the signature, using verification data at t.
See "7.5 signature verification" below.
5.4 Use case #3
Non-repudiation services
Data D existed before time t2.
User A signed D after time t1 and before time t2.
Integrity of data D is guaranteed after time t2.
6 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 29149:2012(E)
Evidence generation
1. User A has some data D.
2. A requests a time-stamp token on anything (null included) at t1: TST(any, t1).
3. A prepares a message M, containing .
4. A signs the message M: S (M).
A
5. A requests a time-stamp on the signature S (M) at t2: TST(S (M), t2).
A A
1)
NIST SP 800-102 [36] introduces a special kind of time-stamp token that does not refer to any user’s data .
Here, using “any” as data for the TST is equivalent to those ‘time marks’.
Evidence verification
1. User B receives the message M, and the time-stamp packet TSP(S (M), TST(S (M), t2)).
A A
2. B checks that the second TST at t2 corresponds to the signature S (M), and verifies the second
A
TST at t2.
3. B verifies A's signature on message M at t2.
4. B verifies the first TST on any at t1.
See "7.5 signature verification" below.
6 Potential issues
6.1 Security requirements for custody of evidences
A time-stamp token is an evidence to be used in the future if a dispute arises. As a general rule, the user of
the evidence should look after the evidence in coordination with the TSA.
If the evidence user needs to prove that he has access to the data at the current time, the evidence user
requests a time-stamp token on the data.
The interest of the evidence user is that the token is available for verification. The evidence user is expected
to take the needed measures to guarantee the availability of the time-stamp token, and the verification means,
either by herself, or using some third party to save copies. The copies have to guarantee the integrity and the
2)
availability of the time-stamp packet, and of the verification means .
For some time-stamping mechanisms, the TSA is required for verification of the time-stamp token. The
evidence user may require guarantees that those means are available when needed.
1) These tokens have no message imprint. These tokens just bind the TSA to a point in time. The TSA guarantees that
the token is not available before the stated time t. Therefore, nobody may have such a token before t, and any operation
involving this token is guaranteed to be carried out after t.
2) There may be confidentiality requirements on the data D, but that is out of the scope of this technical report. All the
mechanisms for time-stamping that are described in ISO/IEC 18014 avoid confidentiality requirements on the time-stamp
token because only the hash-value of D is part of the token. When data D is constrained to a small number of options (for
instance in polls), the requester of the time-stamp may add random data to D in order to hide the actual information in
H(D + random).
© ISO/IEC 2012 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC TR 29149:2012(E)
If the time-stamp token may be used long after it is issued, and there is a real risk that the protecting
cryptography might become weak or broken, the evidence user may renew the TST. That implies that new
time-stamp tokens are requested with different hash-functions and/or to different TSA. These new tokens are
aggregated to the information whose integrity and timeliness is to be preserved.
6.2 Weak cryptography: hash-functions
6.2.1 Hash-function properties
Hash-functions need to satisfy the following properties:
1) pre-image resistance—for essentially all pre-specified outputs, it is computationally infeasible to find
any input which hashes to that output, i.e., to find any pre-image x such that h(x ) = y when given
0 0
any y for which a corresponding input is not known.
nd
2) 2 pre-image resistance—it is computationally infeasible to find any second input which has the
nd
same output as any specified input, i.e., given x, to find a 2 pre-image x x such that h(x) = h(x ).
0 0
Also known as "weak collision resistance".
3) collision resistance—it is computationally infeasible to find any two distinct inputs x, x which hash to
0
the same output, i.e., such that h(x) = h(x ). (Note that here there is free choice of both inputs.)
0
Also known as "strong collision resistance".
6.2.2 Attacks on time-stamped data
Time-stamp tokens that only record the hash-value of the data D are subject to attacks if the hash-function
fails to meet any of the conditions listed above.
Theoretically, the weakest property is strong collision resistance. The source of the information may prepare
two documents, whose hash-values collide, and elect to use one or the other in the future.
No pre-image resistance (noPR):
Some data D2 may replace original data D at any moment after producing H(D), having access to H(D).
No weak collision resistance (noWCR):
Some data D2 may replace original data D at any moment after producing H(D), having access to D and
H(D).
No strong collision resistance (noSCR):
Some data D2 may replace original data D. The attacker needs to prepare D and D2 before producing
H(D). Later on, the attacker may argue that the time-stamp corresponds to D2.
These attacks are more difficult if the data, on which the hash-value is calculated, is structured, since the
replacement needs to meet the structure. For instance, when elaborating a false signature, the fake data have
to look like a valid signature. For this countermeasure to be effective, the structure needs to disallow the
injection of arbitrary data without notice.
Table 1 — Consequences for TST that only record H(D)
Attacker No pre-image No weak collision No strong collision
resistance resistance resistance
may replace D2 for D,
originator may replace D2 for D, at any moment
before the generation of
the TST
evidence user may replace D2 for D, may replace D2 for D, not applicable
after reception of the after reception of D and
TST the TST
8 © ISO/IEC 2012 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC TR 29149:2012(E)
The following preventive countermeasures protect against these attacks:
usage of two hash-functions; either (a) requesting two TST using different hash-functions, or (b) by
submitting a time-stamp request that includes multiple hash-values over the same document using
different hash-functions, as described in ISO/IEC 18014-1, or (c) applying renewal operations with a
different hash-function
require a structure on the data subject to the hash-function; this countermeasure assumes that finding
collisions on structured data is harder than finding collisions on raw data where it is easier to insert
bits as needed
Renewal operations protect the evidence beyond the period covered by the previous TST, and may be used
as a reaction to early announcements of potential weaknesses. Renewal is to be performed before
weaknesses are real.
If the hash-function is unexpectedly broken, due to a cryptographic breakthrough, there may be little or no
time left to renew previous time-stamp tokens. Notice that it is extremely unlikely that two hash-functions are
3)
broken on the same date . Using a second function "buys time for renewal".
6.2.3 Attacks on TSTInfo
4)
Time-stamp tokens that use hash-functions to protect the TSTInfo , are subject to the same consequences
when weak hash-functions are employed in the process of generating the TST. See Table 2.
Table 2 — Consequences TSTs that use hash-functions to protect the TSTInfo
Attacker No pre-image No weak collision No strong collision
resistance resistance resistance
originator or evidence may replace Info2 for Info, after reception of the TST not applicable
user
where Info and Info2 are instances of TSTInfo (see
18014-1, Annex I)
There is a straightforward preventive countermeasure protect against these attacks: usage of more than one
hash-function. For linking mechanisms, it is foreseen in ISO/IEC 18014-3 to use more than one hash-function
when it generates the TST. For independent tokens as in ISO/IEC 18014-4 using the digital signature
mechanism, this requirement may be met by requesting TSTs from providers using different hash-functions on
the respective TSTInfo.
3) Attention should be paid to families of algorithms; that is, to algorithms that are based on the same theoretical
concepts, since a whole family may be broken simultaneously.
4) Hash-functions are used, at least, by the digital signature mechanism in ISO/IEC 18014-2, and in linking mechanisms
in ISO/IEC 18014-3.
© ISO/IEC 2012 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/IEC TR 29149:2012(E)
6.3 Weak cryptography: digital signatures
For time-stamp tokens generated using digital signature techniques, the following additional issues apply.
Digital signatures are produced by means of a signature operation using a private key and a signature
algorithm. If a hash-function is involved in the signature algorithm, the weaknesses of hash-functions covered
in Clause 7.2 apply. Additionally, the following attacks are possible:
the disclosure of the private key permits the generation of fake signatures, incorrectly binding the
signer to false data.
o short private keys open an opportunity to discover them by brute force
o poor implementations may be subject to time attacks, power attacks, or even fault attacks that
make it easier to discover the key, and will eventually reveal its value
o weak public key models may allow the discovery of the private part out of the knowledge of
the public part
As soon as any of these components becomes weak, the signatures become weak, and the time-stamp
tokens cannot be trusted any longer.
Renewal deals with signatures that become weaker as a consequence of time. But renewal is to be performed
5)
.
before trust is lost
If the loss of trust is abrupt, it is too late to renew, and the only countermeasure is to retain more than one TST
using different algorithms. Using a second TST "buys time for renewal".
6.4 Weak cryptography: message authentication codes
MACs are produced by means of an operation using a secret key and a MAC algorithm. If a hash-function is
involved in the MAC algorithm, the weaknesses of hash-functions covered in Clause 7.2 apply. Additionally,
the secret key needs to remain secret, and
the secret key needs to be long enough to r
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.