]>
Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)Fraunhofer Institute for Secure Information TechnologyRheinstrasse 75DarmstadtD-64295Germanythomas.kunz@sit.fraunhofer.depawisda systems GmbHRobert-Koch-Strasse 9WeiterstadtD-64331Germanysusanne.okunick@pawisda.deFraunhofer GesellschaftRheinstrasse 75DarmstadtD-64295Germanyulrich.pordesch@zv.fraunhofer.de
Security Area
Long-term Archive And Notary Services (LTANS)long term archivesecuritypolicyhash algorithmpublic key algorithm
Since cryptographic algorithms can become weak over the years,
it is necessary to evaluate their security suitability.
When signing or verifying data, or when encrypting or decrypting
data, these evaluations must be considered. This document specifies
a data structure that enables an automated analysis of the security
suitability of a given cryptographic algorithm at a given point of
time which may be in the past, at the present time or in the future.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Digital signatures can provide data integrity and authentication.
They are based on cryptographic algorithms that are required to have certain security
properties. For example, hash algorithms must be resistant to collisions and in
case of public key algorithms computation of the private key that corresponds to a
given public key must be infeasible. If algorithms lack the required properties,
signatures could be forged, unless they are protected by a strong cryptographic algorithm.
Cryptographic algorithms that are used in signatures shall be selected to resist such attacks
during their period of use. For signature keys included in public key certificates, it is the
validity period of the certificate. Cryptographic algorithms that are used for encryption shall
resist during the time during which it is planned to keep the information confidential.
Only very few algorithms satisfy the security requirements. Besides, because of the increasing performance
of computers and progresses in cryptography, algorithms or their parameters
become insecure over the years. The hash algorithm MD5, for example, is unsuitable today for many purposes.
A digital signature using a "weak" algorithm has no probative value, unless the "weak" algorithm has been
protected by a strong algorithm before the time it was considered to be weak.
Many kinds of digital signed data, including signed documents, time stamps,
certificates, and revocation lists, are affected, in particular in the case of long-term archiving.
Over long periods of time, it is assumed that the algorithms
used in signatures become insecure.
For this reason, it is important to periodically evaluate an algorithm's fitness and to consider
the results of these evaluations when creating and verifying signatures, or when maintaining the validity
of signatures made in the past. One result is a projected validity period for the algorithm, i.e.,
a prediction of the period of time during which the algorithm is fit for use. This prediction can
help to detect whether a weak algorithm is used in a signature and whether that signature has been properly
protected in due time by another signature made using an algorithm that is suitable at the present point of time.
Algorithm evaluations are made by expert committees. In Germany the Federal Network Agency annually publishes
evaluations of cryptographic algorithms . Examples of other European and
international evaluations are and .
These evaluations are published in documents intended to be read by humans. Therefore it is necessary to define a
data structure that expresses the content of the evaluations to enable automated processing.
This standardized data structure can be used for publication and can be interpreted by signature generation and verification tools.
Algorithm evaluations are pooled in a security suitability policy.
In this document a data structure for a security suitability policy is specified.
This document does not attempt to catalog the security properties of cryptographic algorithms.
A cryptographic algorithm, i.e. a public key or hash algorithm. For
public key algorithms, this is the algorithm with its parameters, if any.
Furthermore, the term 'algorithm' is used for combinations of public key
and hash algorithms, and actually padding functions (e.g. the signature algorithm SHA-1 with RSA).
Instance which uses and interprets a policy, e.g. a signature verification component.
An abbreviation for security suitability policy.
Instance that publishes the policy containing the evaluation of algorithms.
The evaluation of cryptographic algorithms with regard to their security in a
specific application area, e.g. signing or verifying data.
The evaluation is published in an electronic format.
An algorithm which is evaluated against a policy and determined to be valid,
i.e. resistant against attacks, at a particular point of time.
In the following some use cases for a security suitability policy are presented.
The most important use case is long-term archiving
of signed data. Algorithms or their parameters become insecure over
long time periods. Therefore signatures of archived data and timestamps have to be periodically
renewed.
A policy provides information about suitable and threatened algorithms.
Additionally the policy assists in verifying archived as well as re-signed documents.
Services may provide information about cryptographic algorithms.
On the basis of a policy a service is able to provide the date when an algorithm
became insecure or presumably will become insecure or to provide all algorithms
which are presently valid.
Verification tools or long-term archiving systems can request such services and therefore do not need to deal
with the algorithm security by themselves.
Long-term Archive Services (LTA) as defined in
may use the policy for signature renewal.
When signing documents, or certificates, it must be assured that the algorithms
used for signing or verifying are suitable. Accordingly, when verifying
CMS or XML signatures
, not only the
validity of the certificates may be checked but also the validity of the
algorithms.
A security suitability policy can also be used to decide if encrypted documents
must be re-encrypted because the encryption algorithm is no longer secure.
describes general requirements for a data structure containing
the security suitability of algorithms. In assumptions are specified
concerning both the design and the usage of the data structure.
A policy contains a list of algorithms that have been evaluated by a publisher. An algorithm evaluation is described
by its identifier, security constraints and validity period.
By these constraints the requirements for algorithm properties must be defined,
e.g. a public key algorithm is evaluated on the basis of its parameters.
The data structure of the policy must allow automated evaluation of the security suitability of an algorithm.
The data structure must be flexible enough to support new algorithms.
Future policy publications may include evaluations of algorithms that are currently unknown.
It must be possible to add new algorithms with
the corresponding security constraints in the data structure.
Additionally the data structure must be independent of the intended use,
e.g., encryption, signing, verifying, and signature renewing. Thus,
the data struture is usable in every use case.
Policies may be published by different institutions, e.g. on national or EU level,
whereas one policy needs not to be in agreement with the other one.
Furthermore organizations may undertake their own evaluations for internal purposes.
For this reason a policy must be attributable to its publisher.
It must be possible to assure the integrity and authenticity of a published security suitability policy.
Additionally the date of issue must be identifiable.
It is assumed that a policy contains the evaluations of all currently known algorithms,
including the expired ones.
An algorithm is suitable at a time of interest if it is contained in the current policy and
the time of interest is within the validity period.
Additionally, if the algorithm has any parameters, these parameters must meet the requirements defined in the
security constraints.
If an algorithm appears in a policy for the first time,
it may be assumed that the algorithm has already been suitable in the past.
Generally, algorithms are used in practice prior to evaluation.
To avoid inconsistencies, multiple instances of the same algorithm are prohibited.
The publisher must take care about preventing conflicts within a policy.
Assertions made in the policy are suitable at least until the next policy is published.
Publishers may extend the lifetime of an algorithm prior to reaching the end of the algorithm's
validity period by publishing a revised policy. Publishers should not resurrect algorithms that are
expired at the time a revised policy is published.
This section describes the syntax of a security suitability policy defined as an XML schema.
ASN.1 modules are defined in and .
The schema uses the following namespace:
http://www.sit.fraunhofer.de/dssc
Within this document, the prefix "dssc" is used for this namespace. The schema starts
with the following schema definition:
The SecuritySuitabilityPolicy element is the root element
of a policy. It has an optional id attribute which must be
used as a reference when signing the policy ().
The element is defined by the following schema:
The PolicyName element consists of an arbitrary name
of the policy and an optional Uniform Resource Identifier (URI).
The Publisher element contains information about the
publisher of the policy. It is composed of the name, e.g. name of institution,
an optional address, and an optional URI.
The Address element consists of the street, the locality,
the optional state or province, the postal code, and the country.
The PolicyIssueDate element indicates the point of time when the policy was issued.
The optional NextUpdate element may be used to indicate when the next policy will be issued.
The optional Usage element determines the intended use of the policy
(e.g. certificate validation, signing and verifying documents).
A security suitability policy must contain at least one Algorithm element.
An algorithm is identified by an AlgorithmIdentifier element.
Additionally the Algorithm element contains all evaluations
of the specific cryptographic algorithm. More than one evaluation may be necessary
if the evaluation depends on the parameter constraints.
The Algorithm element is defined by the following schema:
The AlgorithmIdentifier element is used to identify a cryptographic algorithm.
It consists of the algorithm name, at least one object identifer, and optional URIs.
The element is defined as follows:
The evaluation element contains the evaluation of one cryptographic algorithm
in dependence of its parameter contraints. E.g. the suitability of the RSA algorithm depends on
the modulus length (RSA with a modulus length of 1024 may have another suitability period as
RSA with a modulus length of 2048). Current hash algorithms like SHA-1 or RIPEMD-160 do not
have any parameters. Therefore the Parameter element is optional.
The suitability of the algorithm is expressed by a validity period which is
defined by the Validity element.
The Parameter element is used to express constraints on algorithm specific parameters
like the "moduluslength" parameter in case of RSA.
The Parameter element has a name attribute which holds the name of the parameter (e.g.
"moduluslength" for RSA ).
Besides a better readability of the policy, the attribute may be used by implementations for
output messages. In the parameter names of currently
known signature algorithms are defined.
For the actual parameter, an exact value or a range of values may be defined.
These constraints are expressed by the following elements:
The Exact element specifies the exact value of the parameter.
The Min element defines the minimum value of the parameter. That means, also all other values greater
than the given one meet the requirements.
The Max element defines the maximum value the parameter may take.
The Range element is used to define a range of values, consisting of a minimum and a maximum
value. The parameter may have any value within the defined range, including the minimum and maximum values.
For one algorithm it is recommended not to mix these elements in order to avoid inconsistencies.
These constraints are sufficient for all current algorithms. If future algorithms will need constraints
which cannot be expressed by the elements above, an arbitrary XML structure may be inserted which meets the new
constraints. For this reason, the Parameter element contains an "any" element.
The schema for the Parameter element is as follows:
The Validity element is used to define the period of the (predicted) suitability
of the algorithm. It is composed of an optional start date and an optional end date.
Defining no end date means the algorithm has an open-end validity. Of course this may
be restricted by a future policy which sets an end date for the algorithm.
If the end of the validity period is in the past, the algorithm was suitable until
that end date.
The element is defined by the following schema:
The Information element may be used to give additional textual information
about the algorithm or the evaluation, e.g. references on algorithm specifications.
The element is defined as follows:
The optional Signature element may be used to guarantee the integrity and authenticity
of the policy. It is an XML signature specified in .
The signature must relate to the SecuritySuitabilityPolicy element. If the Signature element
is set, the SecuritySuitabilityPolicy element must have the optional id attribute. This attribute
must be used to reference the SecuritySuitabilityPolicy element within the Signature element.
Since it is an enveloped signature, the signature must use the transformation algorithm identified
by the following URI:
http://www.w3.org/2000/09/xmldsig#enveloped-signature
This section defines the parameter names for the currently known public key algorithms.
The signature algorithms RSA and DSA
are generally used in conjunction with a one-way hash algorithm.
Examples of such combined algorithms are SHA-256 with RSA and SHA-1 with DSA.
The following parameters refer to the appropriate combined algorithms as well.
The parameter of RSA should be named "moduluslength".The parameters for DSA should be "plength" and "qlength".
Publishers of policies must use the same parameter names, so that the correct interpretation
is guaranteed.
For future algorithms, it may be necessary to update the information in this section.
We suggest to handle this by the means of the IETF standards action (e.g. an updating RFC,
which defines the parameter names of new algorithms).
Evaluation of an algorithm's security suitability is described in three parts: verification of the policy, determination
of algorithm validity, and evaluation of algorithm parameters, if any.
In the following, a process is described
to determine if an algorithm was suitable at a particular point of timeand to determine until when an algorithm was or will be suitable.
To determine the security suitability of an algorithm, the following information is required:
PolicyCurrent timeAlgorithm identifier and parameter constraints (if associated)Time of interest (optional). Providing no time of interest means determination
of the validity end date of algorithm.
The signature on the policy SHOULD be verified and a certification path from the
policy signer's certificate to a current trust anchor SHOULD be constructed and validated .
The algorithms used to verify the digital signature and validate the certification path MUST be suitable per
the contents of the policy being verified. If signature verification fails, certification path validation
fails or an unsuitable algorithm is required to perform these checks, then the policy MUST be rejected.
The nextUpdate time in the policy MUST be greater than the current time or absent. If the nextUpdate time
is less than the current time, the policy MUST be rejected.
To determine the validity period of an algorithm, locate the Algorithm element
in the policy that corresponds to the algorithm identifier provided as input. The Algorithm element
is located by comparing the object identifier in the element to the object identifier included
in the algorithm identifier provided as input.
If no matching Algorithm element is found, then the algorithm is unknown.
If the time of interest was provided as input, the validity of each Evaluation element MUST be
checked in order to determine if the algorithm was suitable at the time of interest. For each
Evaluation element,
Confirm the Start time is less than the time of interest or absent. Discard the entry
if the Start time is present and greater than the time of interest.Confirm the End time is greater than the time of interest or absent. Discard the entry
if the End time is present and less than the time of interest.
If all Evaluation elements were rejected, the algorithm is not suitable according the policy.
Any entries not rejected will be used for the evaluation of the parameters, if any.
Any necessary parameters of the entries not rejected MUST
be evaluated within the context of the type and usage of the algorithm. Details of parameter evaluation
are defined on a per algorithm basis.
To evaluate the parameters, the Parameter elements of each Evaluation element that has not been rejected
in the process described in must be checked. For each Parameter element,
Confirm that the parameter was provided as input. Discard the Evaluation element if the parameter
does not match to any of the parameters provided as input.
If the Parameter element has an Exact element, confirm that the parameter value exactly complies
with the according parameter provided as input. Discard the Evaluation element if the
parameter value does not comply.
If the Parameter element has a Min element, confirm that the parameter value is less than or equal
to the according parameter provided as input. Discard the Evaluation element if the
parameter value does not meet the constraint.
If the Parameter element has a Max element, confirm that the parameter value is greater than or equal
to the according parameter provided as input. Discard the Evaluation element if the
parameter value does not meet the constraint.
If the Parameter element has a Range element, confirm that the value of the according parameter
provided as input is within the range. Discard the Evaluation element if the
parameter value does not meet the constraint.
If the Parameter has another constraint, confirm that the value of the according parameter
provided as input meets this constraint. If it does not or if the constraint is unrecognized, discard the Evaluation element.
If all Evaluation elements were rejected, the algorithm is not suitable according the policy.
Any entries not rejected will be provided as output.
If the algorithm is not in the policy, return an error "algorithm unknown".
If no time of interest was provided as input, return the maximum End time of the Evaluation elements that were not discarded.
If at least one End time of these Evaluation elements is absent, return "algorithm has an indefinite end time".
Otherwise, if the algorithm is not suitable relative to the time of interest, return an error "algorithm unsuitable".
If the algorithm is suitable relative to the time of interest, return the Evaluation elements that were not discarded.
The policy for algorithm's security suitability has great impact on the quality
of the results of signature generation and verification operations. If an algorithm is incorrectly
evaluated against a policy,
signatures with a low probative force could be created or verification results
could be incorrect. The following security considerations have been identified:
Publishers must ensure unauthorized manipulation of any security suitability is not possible prior to a policy being
signed and published. There is no mechanism provided to revoke a policy after publication.
Since the algorithm evaluations change infrequently, the lifespan of a policy should be carefully considered prior
to publication.
Operators should only accept policies issued by a trusted publisher.
It must not be possible to alter or replace a security suitability once
accepted by the client.
Operators should periodically check to see if a new policy has been published to avoid using obsolete policy information.
For publishers it is suggested not to omit the NextUpdate element in order to give operators a hint, when the next policy
will be published.
When signing a policy, algorithms should be used which are suitable according this policy.
The processing rule described in is about one cryptographic algorithm independently of the use case.
Depending upon the use case, an algorithm that is no more suitable at the time of interest, does not necessarily mean
that the data structure where it is used is no more secure. For example, a signature has been made with an RSA signer's key of 1024 bits.
This signature is time-stamped with a time-stamp token that uses an RSA key of 2048 bits, before an RSA key size of 1024 bits will be broken.
The fact that the signature key of 1024 bits is no more suitable at the time of interest does not mean that the whole data structure
is no more secure, if an RSA key size of 2048 bits is still suitable at the time of interest.
In addition to the key size considerations, other considerations must be applied, like whether a time-stamp token has been
provided by a trusted authority. It means that the simple use of a suitability policy is not the single element to consider
when evaluating the security of a complex data structure using several cryptographic algorithms.
Re-encrypting documents that were originally encrypted using an algorithm that is no more suitable, will not protect the
semantics of the document, if the document has been intercepted. However, for documents stored in an encrypted form,
re-encryption must be considered, unless the document has lost its original value.
This document has no actions for IANA.
Section can be removed prior to publication as an RFC.
&rfc2119;&rfc3275;&rfc3852;&rfc4998;&rfc5280;
&rfc4810;&PKCS1;
XML Advanced Electronic Signatures (XAdES)European Telecommunication Standards Institute (ETSI)Electronic Signatures and Infrastructures (ESI); "Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms"European Telecommunication Standards Institute (ETSI)Digital Signature Standard (DSS)National Institute of Standards and TechnologyRecommendation for Key Management – Part 1: General (Revised)National Institute of Standards and TechnologyBekanntmachung zur elektronischen Signatur nach dem Signaturgesetz
und der Signaturverordnung (Übersicht über geeignete Algorithmen)Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railway
This section describes the verification
of an Evidence Record according to
the Evidence Record Syntax (ERS, ),
using the presented data structure.
An Evidence Record contains a sequence of archiveTimeStampChains which
consist of ArchiveTimeStamps.
For each archiveTimeStamp the hash algorithm used for the hash tree
(digestAlgorithm) and the public key algorithm and hash algorithm in the
timestamp signature have to be examined.
The relevant date is the time information in the timestamp (date of issue).
Starting with the first ArchiveTimestamp it has to be assured that
The timestamp uses public key and hash algorithms
which have been suitable at the date of issue.
The hashtree was build with an hash algorithm that has been suitable
at the date of issue as well.
Algorithms for timestamp and hashtree in the preceding ArchiveTimestamp
must have been suitable at the issuing date of considered ArchiveTimestamp.
Algorithms in the last ArchiveTimstamp have to be suitable now.
If the check of one of these items fails, this will lead to a failure of the
verification.
This section describes how to store a policy in an Evidence Record.
ERS provides
the field cryptoInfos for the storage of additional verification data.
For the integration of a security suitability policy in an Evidence Record the following
content types are defined for both ASN.1 and XML representation:
ASN.1-Module
ASN.1-Module
In the following an example of a policy is presented. It is
generated on the basis of an evaluation of the German
Federal Network Agency (). The policy consists on hash algorithms
as well as public key algorithms. RSA with modulus length of
768 is an example for an expired algorithm.
Combined algorithms should also be part of the policy
since some programs know the object identifiers of combined algorithms
instead of the general public key algorithm. The following excerpt describes a
combined algorithm. The validity end date is given by the end dates
of RSA and RIPEMD-160, in particular it is the former one.
Combined algorithms could replace the public
key algorithms in the policy example. They could also be listed together with
public key algorithms.
This document may contain material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC or to translate it into languages
other than English.