Professional Documents
Culture Documents
EPC342-08 Guidelines On Algorithms and Key Management PDF
EPC342-08 Guidelines On Algorithms and Key Management PDF
Version 3.0
Date issued: 10 October 2013
Abstract This document defines the guidelines on algorithms usage and key
management.
Document Reference EPC342-08
Issue Version 3.0 Approved
Date of Issue 10 October 2013
Reason for Issue Approved by EPC Plenary
Reviewed by EPC
Produced by EPC
Authorised by EPC
Circulation Publicly available
Document History
This document was first produced by ECBS as TR 406, with its latest ECBS version published in
September 2005. Maintenance of this document has now passed to EPC.
DISCLAIMER:
Whilst the European Payments Council (EPC) has used its best endeavours to make sure that all the
information, data, documentation (including references) and other material in the present document are
accurate and complete, it does not accept liability for any errors or omissions.
EPC will not be liable for any claims or losses of any nature arising directly or indirectly from use of the
information, data, documentation or other material in the present document.
Conseil Européen des Paiements AISBL– Cours Saint-Michel 30A – B 1040 Brussels
Tel: +32 2 733 35 33 – Fax: +32 2 736 49 88
Enterprise N° 0873.268.927 – www.epc-cep.eu – secretariat@epc-cep.eu
TABLE OF CONTENTS
1 INTRODUCTION............................................................................................ 6
1.1 Scope of the document ............................................................................. 6
1.2 Document layout ...................................................................................... 6
2 REFERENCES AND BIBLIOGRAPHY....................................................... 7
3 DEFINITIONS AND ACRONYMS ............................................................. 15
3.1 Definitions .............................................................................................. 15
3.2 Acronyms ............................................................................................... 16
4 ALGORITHM TAXONOMY ....................................................................... 18
4.1 Technical characteristics......................................................................... 18
4.1.1 Primitives................................................................................................ 19
4.1.2 Elementary Constructions ...................................................................... 20
4.2 Typical Usage ......................................................................................... 22
4.2.1 Confidentiality Protection ...................................................................... 23
4.2.2 Integrity Protection ................................................................................ 23
4.3 Legal or commercial status ..................................................................... 24
5 ALGORITHM RELATED DESIGN ISSUES ............................................ 25
5.1 Primitives ................................................................................................ 25
5.1.1 Unkeyed .................................................................................................. 25
5.1.2 Symmetric Key ........................................................................................ 26
5.1.3 Asymmetric key ....................................................................................... 27
5.1.4 Security levels ......................................................................................... 31
5.1.5 Patents on cryptographic techniques ..................................................... 33
5.2 Constructions .......................................................................................... 34
5.2.1 Symmetric Key Encryption ..................................................................... 34
5.2.2 Asymmetric Encryption .......................................................................... 35
5.2.3 Hybrid Encryption .................................................................................. 35
5.2.4 MACs ...................................................................................................... 36
5.2.5 Digital Signatures................................................................................... 36
5.2.6 Authenticated Encryption ....................................................................... 39
5.3 Domain of Application ........................................................................... 40
5.4 Implementation and interoperability issues ............................................ 40
5.4.1 Security protocols ................................................................................... 40
5.4.2 Data formatting issues............................................................................ 41
5.4.3 Implementation rules .............................................................................. 41
5.4.4 Key management impact on interoperability.......................................... 42
5.4.5 Implementation quality and side-channel attacks .................................. 42
5.4.6 Algorithm OIDs ...................................................................................... 43
6 KEY MANAGEMENT ISSUES ................................................................... 44
6.1 Symmetric algorithms ............................................................................ 44
1
E.g., integrity of data may be assured by protecting the hash of the data.
Since the publication of version 2.0 of this Technical Report in June 2012, there have been a number of
newsworthy developments in cryptography that should be noted:
• The selection of Keccak as winner of the SHA-3 hash function competition.
• Recent evolutions of so-called "padding oracle attacks".
• The impact of poor random number generation.
The relevant sections in this document have been updated to reflect these developments.
Annex A contains information on random number generation and Annex B provides some information
about algorithm breaking.
EPC342-08 Guidelines on algorithms usage and key management v3.0 clean.doc 6
2 REFERENCES AND BIBLIOGRAPHY
ISO Standards
ISO standards are available from ISO at http://www.iso.org, or from the national standardisation bodies
(such as AFNOR, BSI, DIN,...).
ETSI Standards
ETSI standards available from http://www.etsi.org
[58] ETSI TS 101 733, "Electronic Signature Formats"
[59] ETSI TS 101 903, " XML Advanced Signatures (XAdES)”
[60] ETSI TR 102 176-1, "Electronic Signatures and Infrastructures (ESI); Algorithms and
Parameters for Secure Electronic Signatures – Part 1: Hash functions and asymmetric
algorithms"
[61] ETSI TR 102 176-2, "Electronic Signatures and Infrastructures (ESI); Algorithms and
Parameters for Secure Electronic Signatures – Part 2: Symmetric algorithms and protocols for
secure channels"
ANSI Standards
ANSI standards are available from: http://web.ansi.org
ANSI X 9 standards are available from: http://www.x9.org
[62] ANSI X3.106, "American National Standard for Information Systems- Data Encryption
Algorithm - Modes of Operation", 1983
[63] ANSI X9.24-1, "American National Standard - Financial Industry Standards – Retail Financial
Services Symmetric Key Management - Part 1: Using Symmetric Techniques"
[64] ANSI X9.24-2, "American National Standard - Financial Industry Standards – Retail Financial
Services Symmetric Key Management - Part 2: Using Asymmetric Techniques for the
Distribution of Symmetric Keys"
[65] ANSI X9.42, "American National Standard - Financial Industry Standards - Public Key
Cryptography for the Financial Services Industry: Agreement of symmetric keys using Discrete
Logarithm Cryptography"
[66] ANSI X9.44, "Key Establishment Using Integer Factorization Cryptography"
[67] ANSI X9.62, "American National Standard - Financial Industry Standards - Public Key
Cryptography For The Financial Services Industry - The Elliptic Curve Digital Signature
Algorithm (ECDSA)"
[68] ANSI X9.63, "American National Standard - Financial Industry Standards - Public Key
EPC342-08 Guidelines on algorithms usage and key management v3.0 clean.doc 9
Cryptography For The Financial Services Industry – Key Agreement and Key Transport Using
Elliptic Curve Cryptography"
[69] ANSI X9.80 , "American National Standard - Financial Industry Standards - Prime Number
Generation Primality Testing, and Primality Certificates"
[70] ANSI X9.82-1, "Random Number Generation, Part 1: Overview and Basic Principles"
[71] ANSI X9.102, "Symmetric Key Cryptography For the Financial Services Industry - Wrapping
of Keys and Associated Data"
W3C Recommendations
[94] XML Signature Syntax and Processing (Second Edition), W3C recommendation 2008:
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/http://www.w3.org/TR/2008/PER-xmldsig-
core-20080326/.
[95] XML Encryption Syntax and Processing Version 1.1, W3C Candidate Recommendation 2011:
http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/.
PKCS "standards"
PKCS standards are available from http://www.rsa.com
Note that PKCS #1 is now instead maintained as RFC 3447 [87].
[96] PKCS #1, "The Public key cryptography standards - Part 1: RSA encryption standard", version
1.5, 1993.
[97] PKCS #1, "The Public key cryptography standards - Part 1: RSA cryptography standard",
version 2.1, 2002.
[98] PKCS #3, "The Public key cryptography standards - Part 3: Diffie-Hellman key-agreement
standard", version 1.4, 1993.
[99] PKCS #6, "The Public key cryptography standards - Part 6: Extended-Certificate Syntax
Standard", version 1.5, 1993 (superseded by x.509 v3).
[100] PKCS #7, "The Public key cryptography standards - Part 7: Cryptographic message syntax
standard", version 1.5, 1993 (see S/MIME RFC 5652).
[101] PKCS #9, "The Public key cryptography standards - Part 9: Selected Object Classes and
Attribute Types", version 2.0, 2000 (now maintained as RFC 2985).
[102] PKCS #10, "The Public key cryptography standards – Part 10: Cryptographic request syntax
standard", version 1.7, 2000 (now maintained as RFC 2986).
[103] PKCS #11, "The Public key cryptography standards – Part 11: Cryptographic token interface
standard", version 2.30, 2009.
[104] PKCS #13, "The Public key cryptography standards – Part 13: Elliptic Curve Cryptography
standard", under development.
[105] PKCS #15, "The Public key cryptography standards – Part 15: Cryptographic Token
Information Format Standard", version 1.1, 2000 (see ISO/IEC 7816-15).
EMV specifications
EMV specifications are available from EMVCo, www.emvco.com:
[106] EMV 4.3, "Integrated Circuit Card Specifications for Payment Systems: Book 1 Application
Independent ICC to Terminal Interface Requirements, Book 2 Security and Key Management,
Book 3 Application Specification, Book 4 Cardholder, Attendant and Acquirer Interface
EPC342-08 Guidelines on algorithms usage and key management v3.0 clean.doc 11
Requirements", Version 4.3, EMVCo, 2011.
Other references
[116] R. RIVEST, A. SHAMIR and L. ADLEMAN, "A Method for obtaining Digital Signatures and
Public Key Cryptosystems". Communications of the ACM, Vol.21(2), pp 120-126 (1978).
[117] J. DAEMEN and V. RIJMEN, "AES proposal: Rijndael", AES Algorithm Submission,
September 3 1999, http://www.nist.gov/aes/.
[118] J.L. MASSEY "SAFER K-64: A byte-oriented block-ciphering algorithm". In "Fast Software
Encryption", R. Anderson, editor, Lecture Notes in Computer Science No. 809, p.1-17. Springer,
1994.
[119] H. DOBBERTIN, A. BOSSELAERS and B. PRENEEL, "RIPEMD-160: A strengthened
version of RIPEMD" In "Fast Software Encryption, Proc. third International Workshop,
Cambridge, UK February 21 – 23, 1996, pp. 71-82, D. Gollman editor", Lecture Notes in
Computer Science No. 1039. Springer-Verlag, Berlin 1996.
[120] D.W. DAVIES and W.L. PRICE, "Security for computer networks", John Wiley & Sons, New
York, 2nd edition 1989.
[121] B. SCHNEIER, "Applied cryptography: Protocols, Algorithms and Source code in C", John
Wiley & Sons, New York, 2nd edition, 1996.
[122] A. J. MENEZES, P.C. VAN OORSCHOT and S. A. VANSTONE, "Handbook of applied
cryptography", CRC Press, Boca Raton 1997, http://cacr.math.uwaterloo.ca/hac/.
[123] D.E. DENNING and D.K. BRANSTAD, "A taxonomy for key escrow encryption systems",
Communications of the ACM, 39 (February 1996), 34-40.
[124] IEEE 1363-2000: Standard Specifications For Public Key Cryptography.
[125] L. GUILLOU, J.J. QUISQUATER, M. WALKER, P. LANDROCK and C. SHAER
"Precautions taken against various potential attacks in ISO/IEC DIS 9796 Digital Signature
Scheme giving Message Recovery", Proceedings of Eurocrypt'90, Springer-Verlag, 1991.
[126] R. ANDERSON and R. NEEDHAM "Robustness principles for public key pr,otocols",
Cambridge University Computer Laboratory, (rja14@cl.cam.ac.uk).
[127] D. BONEH, "Twenty years of attacks on the RSA cryptosystem", (dabo@cs.stanford.edu).
[128] M. BELLARE and P. ROGAWAY, "The exact security of digital signatures: How to sign with
RSA and Rabin". In: U.M. Maurer (editor), Advances in Cryptology – Eurocrypt ’96, Lecture
3.1 DEFINITIONS
Whenever a definition is copied without alteration from an International Standard, the reference of the
standard is given.
Asymmetric algorithm: A cryptographic algorithm employing a public key and a private key. Together
these form an asymmetric key set.
Block cipher: A cryptographic algorithm, which maps n-bit plaintext blocks to n-bit ciphertext blocks. n
is called the block length or block size (both terms are used here).
Confidentiality: The property that information is not made available or disclosed to unauthorised
individuals, entities or processes. (ISO 7498-2 [14])
Cryptography: The discipline, which embodies principles, means, and methods for the transformation
of data in order to hide its information content, prevent its undetected modification and/or prevent
its unauthorised use. (ISO 7498-2 [14])
Cryptoperiod: See key cryptoperiod.
Data integrity: The property that data has not been altered or destroyed in an unauthorised manner. (ISO
7498-2 [14])
Data origin authentication: The corroboration that the source of data received is as claimed. (ISO 7498-
2 [14])
Decipherment: The reversal of a corresponding reversible encipherment. (ISO 7498-2 [14])
Decryption: See decipherment. (ISO 7498-2 [14])
Digital signature: Data appended to, or a cryptographic transformation (see cryptography) 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 [14])
Encipherment: The cryptographic transformation of data (see cryptography) to produce ciphertext. (ISO
7498-2 [14])
Encryption: See encipherment. (ISO 7498-2 [14])
Hash function: A (mathematical) function, which maps values from a large (possibly very large) domain
into a smaller range. A 'good' hash function is such that the results of applying the function to a
(large) set of values in the domain will be evenly distributed (and apparently at random) over the
range. (ISO 9594-8 [21])
Key: A sequence of symbols that controls the operations of encipherment and decipherment. (ISO 7498-
2 [14])
Key cryptoperiod: The time period over which a key is valid for use by legitimate parties.
Key encapsulation: a class of encryption techniques designed to secure symmetric cryptographic key
material for transmission using asymmetric (public-key) algorithms.
Key establishment: A process whereby a shared secret key becomes available to two or more parties, for
subsequent cryptographic use.
Message Authentication Code: A keyed hash function whose specific purpose is data integrity and
message origin authentication.
Modification Detection Code: An unkeyed hash function whose specific purpose is message integrity.
Private key: (In a public key cryptosystem) that key of a user's key pair which is known only by that
user. (ISO 9594-8 [21])
Public key: (In a public key cryptosystem) that key of a user's key pair which is publicly known. (ISO
9594-8 [21])
Repudiation: Denial by one of the entities involved in a communication of having participated in all or
part of the communication. (ISO 7498-2 [14])
Secret key: A key used with symmetric cryptographic techniques and usable only by a set of specified
entities. (ISO/IEC 11770-1 [39])
3.2 ACRONYMS
2TDES Two-key Triple DES
3TDES Three-key Triple DES
AES Advanced Encryption Standard
ANSI American National Standards Institute
ATM Automated Teller Machine
CA Certification Authority
CBC Cipher Block Chaining
CFB Cipher Feedback
CRL Certificate Revocation List
CRT Chinese Remainder Theorem
CV Control Vector
DEA Data Encryption Algorithm
DES Data Encryption Standard
DSA Digital Signature Algorithm
DSS Digital Signature Standard
DUKPT Derived Unique Key Per Transaction
ECB Electronic Code Book
ECBS European Committee for Banking Standards
ECC Elliptic Curve Cryptosystem
ECDSA Elliptic Curve Digital Signature Algorithm
EESSI European Electronic Signature Standardisation Initiative
EMV Europay Mastercard Visa
EPC European Payments Council
ETSI European Telecommunication Standards Institute
FIPS Federal Information Processing Standards
GCM Galois/Counter Mode
HMAC Keyed-Hash Message Authentication Code
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
IFES Integer Factorization Encryption Scheme
ISO International Organisation for Standardisation
ISSG Information Security Support Group
ITSEC Information Technology Security Evaluation Criteria
IV Initialisation Vector
KEK Key Encrypting Key
MAC Message Authentication Code
MDC Modification Detection Code
MDn Message Digest n
MQV Menezes Qu Vanstone
NESSIE New European Schemes for Signatures, Integrity, and Encryption
NIST National Institute of Standards and Technology
OAEP Optimal Asymmetric Encryption Padding
OCB Offset Codebook Mode
OCSP On-line Certificate Status Protocol
The choice of an algorithm may be done according to functional, technical, legal, or commercial
concerns. Thus it may be useful to propose an algorithm taxonomy based upon different criteria. In this
section we propose to sort algorithms according to their:
• Technical characteristics
• Typical usage
• Legal or commercial status
Figure 1 proposes a taxonomy of cryptographic primitives and mechanisms based on their technical
characteristics. Commonly used algorithms sorted according to this taxonomy are given as examples.
It should be noted that agreement of which algorithms to use is a necessary, but not sufficient condition
for interoperability. A scheme implementing a cryptographic service must also ensure consistent
understanding of encoding, padding, compression and filtering of data. These methods are not a main
part of this document, but discussed briefly in section 5.3.
UNKEYED RIPEMD-160
PRIMITIVES SHA families
Hash functions
Whirlpool
CMAC
CBC-MAC
Message Authentication HMAC
Codes (MACs) Stream
ciphers RC4
SYMMETRIC KEY Symmetric key
PRIMITIVES ciphers TDES
Block AES
ciphers IDEA
2
E.g., integrity protection of the hash of a message can provide integrity protection of the message itself.
4.1.2.4 MAC
Message authentication codes (MACs) are used to guarantee message authenticity and integrity.
Communication partners must hold the same (symmetric) key. Then upon transmitting a message over a
public channel the sender using the key computes a MAC, which is attached to the message, and can be
verified by the recipient using his key, ensuring authenticity and integrity of the received message.
MACs are generally constructed from hash functions or block ciphers using cipher-block chaining.
Examples: HMAC (ISO/IEC 9797-2, mechanism 2), CMAC and CBC-MAC (ISO/IEC 9797-1)
The following matrix shows which kind of elementary construction is considered suitable for a given
usage:
Construction Symmetric Asymmetric Hybrid MAC Signature
Encryption Encryption Encryption
Usage
Data Yes No(1) Yes (2) No No
confidentiality (one to one) (many to one)
Key Yes Yes Yes (2) No No
encapsulation (one to one) (many to one)
Key No Yes No No No
establishment
Data origin No No No Yes Yes
authentication (one to one) (one to many)
Entity No No No Yes Yes
authentication (one to one) (one to many)
Non-repudiation No No No No Yes
4.2.2.2 Non-Repudiation
Non-repudiation means transferable (e.g. to a judge) assurance about the originator of a data item. Digital
signatures are used to provide non-repudiation. Only the originator of the data holds the private key and
can generate signatures. The public key can be freely distributed to receivers and third parties, allowing
Cryptographic functions such as unkeyed hash functions, symmetric algorithms and asymmetric
algorithms can be combined in many ways to achieve a variety of objectives. Often the cryptographic
'primitives' come as a standard toolbox, which can be used flexibly by many applications. Care must be
taken when developing the compound functions from the primitive functions so as to ensure
interoperability, security and efficiency.
This section describes the main primitives and ways in which they are combined.
5.1 PRIMITIVES
5.1.1 Unkeyed
5.1.1.1 Hashes
Primitive hash functions are unkeyed and designed to create a short 'digest' of a long string of input data.
These functions are designed to be one-way (i.e. difficult to find a pre-image of a given hash) and
collision resistant (i.e. difficult to find two inputs that hash to the same digest). Most signature functions
depend on the use of hash functions as do some asymmetric encryption functions (see section 0).
SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 are algorithms defined by NIST (FIPS 180-3 [73])
and that produce 160, 224, 256, 384 and 512-bit hash results, respectively. The longer result algorithms
tend to be known collectively as the SHA-2 family. Together with Whirlpool (which produces a 512-bit
hash result) and RIPEMD-160 [136] (which produces a 160-bit hash result) they are now also
standardised in ISO/IEC 10118-3 [37] (the ISO standard does not include SHA-224). SHA-224 is based
on SHA-256. Computation of a SHA-224 hash value involves two steps. First, the SHA-256 hash value
is computed, except that a different initial value is used. Second, the resulting 256-bit hash value is
truncated to 224 bits.
MD5 is an old algorithm producing only a 128-bit hash result (see section 5.1.3.4). MD5 has been so
extensively attacked that its use is no longer recommended. There are a few collision search attacks on
SHA-1 [150]. However, there is a new method developed by Marc Stevens [166] that allows to discover
an attack attempt, given a message. The false positive rate of this method is negligible. If it is necessary
for some reason (e.g., backward compatibility) to still support MD5, it is recommended to apply such a
method.
In consequence, for message signing, MD5 should no longer be used and legacy message signing
systems that rely on the collision-resistance of SHA-1 should be migrated to a member of the SHA-2
family or to SHA-3.
Next to the SHA-2 family, NIST has recently completed the SHA-3 hash function competition and
announced on October 2nd 2012 the selection of a hash function called Keccak (see [115], [164] and
[163]) as the winner. FIPS standardisation of this new algorithm is expected in Q1-Q2 2014. Systems
requiring interoperability should await the final publication of the standard before adoption.
5.1.2.3 Efficiency
In software implementations, the computation of an AES encryption takes about as much as one or two
DES encryptions. This implies that encryption of a file or a data stream by AES will be much faster than
Triple DES, since Triple DES takes six encryptions per 128 bits.
In the special case of PIN block encryption, both DES and AES encryptions are just one block of data,
but AES encryption will still be faster.
However, for PIN block encryption, there is an issue with the block size. At the time of this writing, the
standard PIN block length (by ISO 9564 [1]) is 64 bits, which is smaller than the AES block length of
128 bits. There is urgent need for an agreed encryption mode for encrypting PIN blocks with a 128-bit
block cipher, so that standards can be developed for payment systems of the future.
3
For example, if the collision-resistant property of SHA-1 is not relied on.
Note that 2TDES may have an effective key length of less than 112 bits if the volume of data enciphered
under a key is large. See section 5.1.4 for more details on security levels of Triple DES.
The RSA public key operation (the basis for encryption and signature verification) applied to data X is
e
X mod N
The RSA private key operation (the basis for decryption and signature generation) applied to data Y is
d
Y mod N.
Reblocking problem
It may be necessary to sign a message (by RSA with the sender's private key) and then encrypt the
resulting signature (by RSA with the receiver's public key). One must be concerned about the relative
sizes of the moduli involved when implementing this procedure. If the sender's modulus is greater than
the receiver's there is a chance that the receiver cannot recover the signature.
There are different ways of solving this issue some of which are discussed in [122], for instance.
When requiring authenticity and confidentiality there are pros and cons as to whether messages should
first be signed and then encrypted or vice versa. See section 5.4.3 for a discussion on this.
4
In this case the attacker cannot utilise the faster algorithms which exploit the field structure of the group and so
cryptographic keys can be shorter.
Computational Enhancements
RSA computation can be made significantly quicker for the owner of the private key if the
implementation takes advantage of the Chinese Remainder Theorem (CRT). Using the CRT the signer
(or decryptor) performs calculations modulo each prime factor of the RSA modulus N, instead of
performing the calculations modulo N. Because the factors of N are half the length of N, the CRT
method is much faster. The CRT method requires that the prime factors of the modulus are kept and used
for the computation involving the private key. These prime factors must be stored with the same level of
security as the private key.
Using CRT when signing (or decrypting) is purely a local decision, and has no impact on the signature
verification process (or encryption process). CRT can make signing and decrypting 3 to 4 times quicker.
Some attacks on RSA implementations using CRT have been published. These attacks involve the
controlled introduction of errors into the signature or decryption computation. They may be prevented by
a sound design (e.g. verify generated signatures before releasing them).
5
This point is not RSA specific and may be pertinent for any encryption algorithm
112 Keccak
(r=1152,
c=448),
truncated to
224 bits
128 Keccak
(r=1088,
c=512),
truncated to
256 bits
192 Keccak
(r=832,
c=768),
truncated to
384 bits
256 Keccak
(r=576,
c=1024),
For many practical applications this degradability of the effective key-length is not necessarily a
problem as access to 240 plaintext/ciphertext pairs encrypted under a single key is quite unlikely.
However, conservative system security design will not encrypt a too huge amount of data under the
same key before re-keying."
The ECRYPT report on Algorithms and Keysizes [156] assesses that 2TDES restricted to a million
plaintext/ciphertext pairs might provide 10 years protection at a 96-bit legacy standard security level.
5.2 CONSTRUCTIONS
6
For messages shorter than the block size, one block is built using a suitable padding technique.
5.2.5.3 Efficiency
This sub-section provides a comparison between three digital signature schemes: RSA [25], DSA [71]
and a digital signature scheme based on Elliptic Curves [74].
7
OCB patent status can be found at http://www.cs.ucdavis.edu/~rogaway/ocb/
The following rationale should be considered in conjunction with the recommendations given below:
• Sending encrypted data that is not integrity protected enables attacks on encryption keys and
plaintext through error analysis: it is better to encrypt first and then sign or MAC, so that the
receiver can first verify the integrity of the ciphertext. But note: some signature algorithms are
weaker when signing unintelligible data.
• Signing the data in plain text format is necessary for legal signature, but not for other purposes.
• Performance of encryption is better if there is less data to encrypt.
• Data compression of encrypted data has no effect.
8
A new version of FIPS 140-3 is currently under development and should be officially published in 2009.
This section focuses on issues related to key management. Section 6.1 addresses the management of keys
used with symmetric algorithms (i.e. symmetric keys) and Section 6.2 addresses the management of keys
used with asymmetric algorithms (i.e. asymmetric keys).
More information on this topic may be found, for instance in: HAC [122], ISO 11568-1 [7], ISO/IEC
11770-1 [39] , ISO/IEC 9594-8 [21], Davies and Price [120].
These Guidelines do not address any particular commercial products for key management. Specific key
management techniques may be imposed by the device being used and in this case the device vendor’s
instructions should be followed.
9
A PIN usually protects usage of smart cards, thus access control based on smart cards requires both possession
of the smart card and knowledge of the PIN.
EPC recommendation 7
If a master key needs to be backed-up outside of a TRSM then it should be split into key components in a secure and
resilient manner. Secret sharing techniques should be used to allow recovery of the master key from all or a fixed
number (threshold) of the master key components. The security level of the storage of the master key components
should be commensurate with the protection afforded the operational master key itself.
EPC recommendation 9
TRSMs that control the key usage (e.g., making use of control vectors) and that bind the key to the key control
information in a secure way (key wrapping) should be preferred.
Master key
Certificate Certificate
Figure 3: A hybrid key hierarchy with asymmetric and symmetric keys (for data
confidentiality)
A third party called a Certification Authority (CA) must sign certificates. Certificate Management and
Certification Authorities are complex subjects warranting separate discussion outside of this Technical
Report.
For certificate management ISO TC 68 published two standards: 15782 [3] and 21188 [13] .
Some PKCS specifications cover certificate management: certificate format in PKCS #7 [100] and
certificate requests in PKCS #10 [102].
The widely used standard format for certificates is the X.509 [21].
EPC recommendation 13
Usage of X 509, version 3, format certificates is recommended.
Often there is confusion between public key certificate and attribute certificates. A public key certificate
binds the identity of a person or an organisation to a specific public key. In an attribute certificate
EPC342-08 Guidelines on algorithms usage and key management v3.0 clean.doc 51
different privileges of a particular user are bound to the identity of the user or the serial number of their
public key certificate. The lifetime of an attribute certificate is foreseen to be shorter than the lifetime of
a public key certificate.
If certificates are not distributed along with the signed message, then users should either have online
access to up-to-date certificates or they should keep track of certificates in local databases and update the
database when new certificates are issued.
A timestamp may be included in the signed message so that the signer can attest to the time the signature
was created. An agreed time source may be sufficient for some implementations, however, there are
certified time sources being developed, i.e. Time Stamping and Notary Services, that are being supplied
by trusted third parties. Trusted timestamps allow the user to be sure of when the message was signed (in
case they do not trust the signing entity for such things).
Similarly a user must have access to a trusted time source when verifying signatures and certificates
containing dates and times.
EPC recommendation 15
Whenever possible, trusted time sources should be used, in order to allow reliable verification of certificate
validity.
The production of high quality random numbers is critical for cryptographic applications, and indeed
some implementations of cryptosystems have been broken on account of an inadequate source of
randomness or "pseudo-randomness".
The importance of good random number generation has recently received wide attention, especially in
the area of prime selection for RSA key generation where some internet research (see [167]) has revealed
that a significant proportion (e.g. thousands) of TLS/PGP public keys shared common factors (and so
could be broken). The cause of this is bad RSA key generation probably resulting from the use of bad
random number generators or poorly seeded random number generators.
Random numbers can be generated using true hardware RNGs or using deterministic algorithmic
methods, preferably both. Recommendations and requirements for generating random numbers can be
found in the following standards:
ISO/IEC 18031: Information Technology – Security Techniques – Random bit generation [51];
ANSI X9.82: Financial Services – Random Number Generation [70];
Part 1: Overview
Part 2: Entropy Sources
Part 3: Deterministic Random Bit Generators
Part 4: Random Bit Generator Construction
NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit
Generators [112];
NIST SP 800-22, A Statistical Test Suite for Random and Pseudorandom Number Generators for
Cryptographic Applications [107].
This informative annex presents some news collected on the Internet about cracking DES keys and
factorising RSA keys.
The information on breaking DES is presented as found (except for some commercial references that
were suppressed) and the fact that it is published in this EPC Technical Report does not mean that the
EPC Information Security Support Group approves the statements therein or wishes to endorse any
responsibility about their content.