]>
Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC)Fraunhofer Institute for Secure Information TechnologyRheinstrasse 75DarmstadtD-64295Germanythomas.kunz@sit.fraunhofer.deFraunhofer Institute for Secure Information TechnologyRheinstrasse 75DarmstadtD-64295Germanysusanne.okunick@sit.fraunhofer.deFraunhofer GesellschaftRheinstrasse 75DarmstadtD-64295Germanyulrich.pordesch@zv.fraunhofer.de
Security Area
Long-term Archive And Notary Services (LTANS)long term archivesecuritypolicyhash algorithmpublic key algorithm
In many application areas it must be possible to prove the existence
and integrity of digital signed data. This proof depends on the
security suitability of the used cryptographic algorithms.
Because algorithms can become weak over the years, it is necessary
to periodically evaluate these security suitabilities. When signing
or verifying data, these evaluations must be considered.
This document specifies a data structure for security suitabilities
of cryptographic algorithms which may be automatically interpreted.
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 are means to provide data integrity and authentication.
They are based on cryptographic algorithms, which must have certain security
properties. For example, hash algorithms have to be resistant to collisions and in
case of public key algorithms it must not be possible to compute the private key of a
given public key. If algorithms did not have the required properties,
signatures could be forged.
Very few algorithms satisfy the security requirements and
are suitable for usage in signatures. Besides, because of the increasing performance
of computers and progresses in cryptography, algorithms or their parameters
become insecure over the years. E.g. the hash algorithm MD5 is impractical by now.
A digital signature using such "weak" algorithms may lose its probative value.
Every kind of digital signed data like signed documents, time stamps,
certificates, and revocation lists is affected, in particular in the case of long-term archiving.
Over long periods of time, it is realistic to assume that the algorithms
used in signatures become insecure.
For this reason, it is important to periodically reevaluate algorithms regarding
their security properties and to consider these evaluations when creating, verifying
or renewing signatures. Such evaluations will give a prognosis how long an algorithm
will be presumably secure and help to detect, whether insecure algorithms are used in a signature or whether
signatures have been timely renewed.
The evaluation of security suitabilites of algorithms cannot be done by the user itself. They
are made by expert committees after long scientific discussion and published by specific
evaluation institutions. In Germany the Federal Network Agency annually publishes a current
evaluation of cryptografic algorithms . Examples for European and
international evaluations are and
.
These publications evaluate algorithms in a textual form and are not interpretable by
computer programs. Therefore it is necessary to define an
automatically interpretable data structure holding the
algorithm evaluations.
In this way evaluation institutions are able use the standardized form for publication.
Such policies can be interpreted by e.g. signing and verification tools.
In the following, such evaluations are called
security suitability policy.
This document specifies a data structure for security suitability policies.
In the following we present some use cases for security suitability policies.
The most important use case for security suitability policies is the long-term archiving
of signed data. Algorithms or their parameters become insecure over very
long periods of time. Therefore signatures of archived data and timestamps have to be periodically
renewed.
Policies provide informations about suitable and threatened algorithms.
Additionally the policies assist in verifying archived and re-signed documents.
Services may provide information about cryptographic algorithms.
E.g. such services can use these policies to provide the date when an algorithm
became insecure or presumably will become insecure or to provide all algorithms
which are presently valid.
Such services could be used by verification tools or long-term archiving systems
so that they do not need to deal with the algorithm security by themselves.
Long-term Archive Services (LTA) as defined in )
may use the policies for signature renewal. Additionally the policies may be integrated
in Evidence Records (ERS, ) as further validation data.
When signing documents, certificates or attestations, e.g. within an LTAP
transaction (), it has to be assured that the algorithms
which will be used for signing are suitable. Accordingly when verifying
e.g CMS () or XML signatures
(, ), not only the
validity of the certificates may be checked, but also the validity of the used
algorithms.
Security suitability policies can also be used to decide if encrypted documents
must be reencrypted because the encryption algorithm is no longer secure.
In the context of this document, a cryptographic algorithm, i.e. a public key or hash algorithm. For
public key algorithms this is the algorithm with its parameters.
Instance which uses and interprets a policy, e.g. a signature component.
In this document, an abbreviation for security suitability policy.
Instance that publishes the evaluation of algorithms in form of policies.
The evaluation of cryptographic algorithms according 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 in a policy, i.e. is rated to be valid.
This section first describes general requirements for a data structure containing
the securitiy suitabilities of algorithms. Afterwards model assumptions are specified
concerning both the design and the usage of the data structure.
An evaluation of the security suitability of algorithms results in a policy.
It contains a list of the evaluated algorithms. An evaluated algorithm is described
by its identifier, security constraints and predicted 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 parameter.
The data structure of the policy must allow an automatic interpretation in order to
consider the security suitabilities of algorithms when signing, verifying or
renewing signatures.
The data structure must be flexible enough to support new algorithms.
In a future policy publication an algorithm could be included,
that is currently unknown. It must be possible to add new algorithms with
the corresponding security constraints in the data structure.
Besides, the data structure must be independent of the intended purpose,
e.g. signing, verifying, and signature renewing.
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 own evaluations for internal purposes.
For this reason a policy must be attributable to its publisher.
The integrity and authenticity of a published security suitability policy should be assured.
The publisher must be able to sign the policy so that operators may prove
the identity and trustworthiness of a policy.
We assume that a security suitability policy contains the evaluations of all currently known algorithms,
including the expired ones.
The latest policy is significant to decide whether an algorithm is currently suitable.
An algorithm is valid now if it is contained in the current policy and the end of the validity period
is in the future, respectivly open-end.
If an algorithm appears in a policy for the first time,
it will be assumed that the algorithm has already been suitable in the past.
Generally an algorithm is used in practice before it is evaluated.
To avoid inconsistencies, multiple instances of the same algorithm definition as well as validity overlaps
for one algorithm are prohibited. It is up to the publisher to take care about preventing conflicts within
a policy.
Assertions made in the policy are suitable at least until the next policy is published.
An algorithm once expired must not get valid again in a future policy.
There must not be any gaps in the validity periods.
This section describes the syntax of a security suitability policy defined as an XML schema.
The 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 contains the name of the policy.
It consists of an arbitrary name 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.
A security suitability policy must contain at least one Algorithm element.
An Algorithm element describes the evaluation of one cryptographic algorithm.
An algorithm is identified by an AlgorithmIdentifier element.
Additionally specific parameter constraints, e.g. a modulus length, may be specified.
The suitability of the algorithm is expressed by a validity period.
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 and optionally one or more object identifers and URIs.
The element is defined as follows:
By the Parameter element, constraints on algorithm specific parameters
are expressed. E.g. the suitability of the RSA algorithm depends on the "modulus"
parameter (RSA with a modulus length of 1024 may have another suitability period as
RSA with a modulus length of 2048). Note that not all algorithm suitabilities depend on
parameter constraints, e.g. current hash algorithms like SHA-1 or RIPEMD-160 do not
have any parameters.
The Parameter element has a name attribute which holds the name of the parameter (e.g.
"modulus" 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 can 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.
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 is not suitable.
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 always used in conjunction with a one-way hash algorithm. RSA with RIPEMD-160 is such a combined algorithm with
its own object identifier. RSA and DSA may be combined with the suitable hash algorithms SHA-1, SHA-224, SHA-256, SHA-384, SHA-512,
and RIPEMD-160.
The following parameters refer to the appropriate combined algorithms as well.
The parameter of RSA should be named "modulus".The parameters for DSA should be "p" and "q".
Publisher of policies must use the same parameter names, so that the correct interpretation
is guaranteed.
This section describes how to analyze a policy, i.e. how to extract the informations out of the policy
needed by the different use cases.
To get these informations, the latest policy containing all algorithms is relevant.
Is an algorithm currently valid?
Procedure: The wanted algorithm has to be listed in the current policy.
The algorithm is valid, if its
validity end date is in the future or not defined.
Input: algorithm
Response: true or false
Did an algorithm have been valid at a particular date in the past?
Procedure:
The algorithm is valid, if it is listed in the current policy and
the end of the validity period is after the particular date or is not defined.
Input: algorithm and date
Response: true or false
Until which date in the future an algorithm is predicted to be valid?
Procedure:
The wanted algorithm has to be listed in the current policy.
If the end date of the algorithm is in the future, this is the predicted date. If the validity end date
is not defined, the algorithm is valid open-end.
Input: algorithm
Response: date or null (open-end) or
error, if the algorithm does not exist or the
validity end date is in the past
At which date an algorithm became invalid?
Procedure: The wanted algorithm has to be listed in the current policy.
The particular date is the validity end date
of the listed algorithm, which has to be in the past.
Input: algorithm
Response: date or error, if date has never been valid or is valid now
Which algorithms are currently valid?
Procedure: All algorithms included in the current policy are valid
whose validity end date is in the future or is not defined.
Response: list of algorithms
Which algorithms have been valid at a particular date in the past?
Procedure: All algorithms included in the current policy are valid
whose validity end date is after the particular date or is not defined.
Additionally any algorithm newly added in one following policy
has been valid.
Input: date
Response: list of algorithms
To determine the validity of a particular algorithm, first the algorithm definition has to be found in the policy.
Therefore, the algorithm identifier has to match and the parameter constraints have to be fulfilled.
To fulfill means, the exact value is given or
a parameter fulfills the constraint definition if its value matches the exactly defined value
or is in the defined range.
The used policies for security suitabilities have great impact on the quality
of signatures and verification results. If evaluations of algorithms are wrong,
signatures with a low probative force could be created and verification results
could be incorrect. The following security considerations have been identified:
An institution publishing a policy must take care via organizational measures
that unauthorized manipulation of security suitabilities is impossible before a policy is
signed and published.
A client should only accept signed policies issued by a trusted institution.
It must not be possible to unnoticeably manipulate or replace security suitabilities once
accepted by the client.
A threat arises when a client downloads a policy too late
although the policy has already been published. In this case, the client would work
with obsolete security suitabilities. To minimize this risk, the client should
periodically check if new policies are published. This check could be done automatically
by signature and verification components.
When signing a policy, only algorithms should be used which are suitable according this policy.
&rfc2119;&rfc3275;&rfc3280;&rfc3852;&rfc4998;&rfc4810;&I-D-ietf-ltans-ltap;
XML Advanced Electronic Signatures (XAdES)European Telecommunication Standards Institute (ETSI)&DSS;&PKCS1;
Electronic Signatures and Infrastructures (ESI); "Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms"European Telecommunication Standards Institute (ETSI)Recommendation 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
In the following an example of a policy is presented. It is
generated on the basis of the last 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 section describes the verification of an Evidence Record according to
the Evidence Record Syntax
by 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
time stamp signature have to be examined.
The definitive date is the time information in the time stamp (date of issue).
Starting with the first ArchiveTimestamp it has to be assured that
The time stamp 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 time stamp 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 item fails, this will lead to a failure of the
verification.
ASN.1-Module
ASN.1-Module