Triple Des
Content
Why Migrating to Triple DES is Not Easy
Abstract Financial institutions are performing large scale migrations of their systems from DES to triple-DES. In this white paper we describe the basic characteristics of DES and triple-DES and look at the security properties that a financial transaction system will want to achieve. We then look at the problems related with a migration from DES to triple-DES, enumerating and discussing several points that we suggest should be considered. Finally, we give some suggestions that will help ease the problems of migration.
Contents
1 2 3 4 Introduction Single DES and triple-DES Security properties wanted Migration issues 4.1 DES is the weakest link . . . 4.2 The algorithm itself . . . . . 4.3 Key blocks . . . . . . . . . 4.4 Hardware update . . . . . . 4.5 Software/Firmware update . 4.6 Payment application database 4.7 Key Management . . . . . . 4.8 Old vulnerabilities . . . . . Easing the migration Conclusion 1 1 3 4 4 5 6 6 7 7 7 8 9 10
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 6
Why Migrating to Triple DES is Not Easy
1
Introduction
DES, the Data Encryption Standard, is a cryptographic algorithm that was standardized in 1977 by the National Institute of Science and Technology (NIST). When the financial industry started to deploy ATMs they opted for DES for securing transactions. This choice was reinforced by the development of X9 standards for financial transactions that were based on DES. DES has stood the test of time, no attack against this encryption algorithm in practice has been better than brute forcing the key space. However, DES uses short keys, with current technology the key space (of size 256 ) can be exhausted in around 56 hours using one single machine worth less than 250 000 US dollars, or in 22 hours with the combined help of a network of about 100 000 personal computers. This means that single DES is no longer secure. On the other hand, triple-DES, as defined in ANSI 9.52, is considered to be secure. Indeed, NIST renewed the DES standard in 1983 and 1988, in 1993 it renewed it with hesitation and controversy and in 1999 DES was to be used only in legacy systems. NIST, in 1999, standardized triple-DES, based on ANSI 9.52. Triple-DES is a secure replacement for single DES, it is not currently feasible to exhaustively search the key space of triple-DES, nor will it be in the near future unless drastic unpredictable technological and/or cryptanalysis advancements occur. In 1993 the financial industry had started replacing DES by triple-DES for the confidentiality of keys residing in cryptographic processors. In 1999, with the concordance of NIST no longer approving single DES, the financial industry started planning a migration, which consists of replacing single DES with tripleDES in all its systems wherever single DES is used. This migration plan however places the industry, which uses single DES widely, in a challenging position. As will be discussed in this document, the process of migrating from single DES to triple-DES is not as simple as just substituting one algorithm for another.
2
Single DES and triple-DES
DES is a block cipher, encryption algorithm, which encrypts messages of block size 64 bits and produces cryptograms of length 64 bits using a 56-bit key (DES keys are actually 64 bits in length but 8 bits act as parity bits so only 56 bits are actually used for encryption).
c Copyright Okiok Data 2002
1
Why Migrating to Triple DES is Not Easy
We say that DES has strength 256 , meaning that the most efficient way to attack DES in practice1 is to search its key space of size 256 . That is, to attack DES in practice one has to try each and every possible key until the correct encryption key is identified, this takes on average 256 /2 = 255 steps. Triple-DES, noted as 3DES from here on, uses 2 keys, chosen independently at random, to DES encrypt a message multiple times. There are also ways to use 3DES with 3 different keys, but these schemes do not give a significant amount of extra security in theory and are not considered in financial systems. The most common technique is to encrypt the initial plaintext message with one key, decrypt the result with a second key and finally encrypt this last result with the first key again. This is known as E-D-E double length key 3DES encryption and is illustrated in the following figure.
other attacks exist in theory, but they demand an unreasonable amount of known or chosen plaintext-ciphertext pairs which renders the attacks unpractical.
1
c Copyright Okiok Data 2002
2
Why Migrating to Triple DES is Not Easy
E-D-E 3DES is compatible with single DES (when KL and KR are identical, E-D-E 3DES produces the same result as single DES). From here on, when we will talk about 3DES we will be referring to double length key E-D-E 3DES. The strength of 3DES is approximately 2112 since using two 56 bit keys in E-D-E 3DES is effectively equal to using one 112-bit key. A brute force search of 3DES 2112 key space is currently not feasible nor will it be in the near future.
3
Security properties wanted
Many security properties are wanted in a financial transaction system. We will not go into details and enumerate all of the security properties wanted but simply mention a couple of them in an informal way so as to motivate some of the discussions in the following sections. SP1 A cryptographic key should not be in cleartext in any single point of the system. This is the basic security property that a financial institution must achieve in order for users to have any sort of trust in the system. This is also an important point when different institutions interchange financial data between themselves, the security of one institution depends on that of others. To achieve this property cryptographic keys must be stored in secure cryptographic processors, if they are ever outside these processors they must be in a form that does not compromise the security of the keys, such as in split knowledge (under the possession of different individuals having certain permissions), or encrypted under another cryptographic key which is protected in a secure cryptographic processor. SP2 Security against known key attacks, if a working key in the system is discovered, this should not enable an attacker to figure out the values of any other keys in the system. Some would say that if a system is secure, no single key will ever be compromised so there is no need to worry about this security property, but as we will see later on this can be a dangerous way of thinking. SP3 The security of any 3DES key should be 2112 . It should not be possible for example to break a 3DES key by breaking one or a couple of single DES keys. If a cryptographic key is to be protected by another one, this last key should be of cryptographic strength equal or greater than the key it is protecting. This implies for example, among other things, that if any
c Copyright Okiok Data 2002
3
Why Migrating to Triple DES is Not Easy
working key is a 3DES key, the key encryption key should be a 3DES key as well. SP4 It should not be possible to combine different key parts in order to trick a secure cryptographic processor into revealing information that can lead to breaking any cryptographic key secured by the processor. This is important to consider for example when deciding how keys protected outside a security processor should be stored. Of course, when analyzing the security of a system, the above security properties must be specified more formally, and others should be enumerated, but the above list is enough for us to be able to discuss about security problems related to migrating from DES to 3DES.
4
Migration issues
It is not sufficient to simply replace single DES with 3DES, security wise and operationally wise. In what follows we discuss about several problems that might arise and issues that should be considered when attempting to migrate from single DES to 3DES.
4.1
DES is the weakest link
A system is just as secure as its weakest link. In a system that is composed of PIN pads, ATMs, acquiring hosts, switches, alternate switches, processors, etc., if a single entity in the system still utilizes single DES there is a possibility that the security of the whole system might be compromised by an attack on single DES. As an extreme example, consider a secure cryptographic processor of an acquiring host that uses a 3DES master file key (MFK), but also uses a single DES key exchange key (KEK); the confidentiality of all keys that are sent to the processor can be compromised, even if the keys stored in the local database are protected by 3DES encryption, so the fact that the MFK key is 3DES does not provide much of a security advantage. Less obvious examples can also lead to extreme security breakage. Consider the attack against the IBM 4758 cryptoprocessors using the CCA software that was found enabling an individual with a certain permission to extract all DES and 3DES keys from the processors ([9]). The attack was made possible by a combination of things that existed because the processors had to
c Copyright Okiok Data 2002
4
Why Migrating to Triple DES is Not Easy
continue to support single DES even though 3DES was used for protecting the keys. Due to the complexity of financial systems, it is not feasible to replace all keys with 3DES keys right away, systems will have to live in a heterogeneous state. It is important however to analyze each situation and to consider how the system satisfies the security properties wanted. Most certainly, until all keys are replaced with 3DES keys, the system will not achieve 2112 security, but the system can be upgraded progressively so as to withstand more and more attacks. Security, as in this case, is often an incremental process.
4.2
The algorithm itself
When using 3DES certain variants of modes of operations are available which are not for single DES. Some of these variants may seem attractive at first glance because of their performance gain properties, unfortunately they are not all secure. For example, for single DES, cipher-block chaining (CBC) is a good mode to use since it is provably secure [3]. However, there are different ways of implementing CBC mode for 3DES, one can use triple-outer-CBC mode (CBC mode applied directly to 3DES) or triple-inner-CBC mode (a variant, a multiple encryption mode of operation where the feedbacks are taken from the single DES operations of which 3DES is composed of). We do not describe these modes in further detail in this document (see [10] if interested), it suffices to know that they are two variants of CBC for 3DES. Although triple-inner-CBC mode can appear to be more appealing since it can be pipelined, thus allowing for more efficient implementations, triple-inner-CBC mode is significantly weaker than outer-inner-CBC mode under certain attack models and is not recommended ([4]). When migrating from single DES to 3DES and designing a new system or looking for existing solutions, it might also be fruitful to consider other encryption algorithms as well, such as the AES, which will become a U.S. government standard may 26th, 2002. If when migrating to 3DES you also make your system ready to accept other encryption algorithms or modes of operations, you will have an advantage and will save time and money in the long run. Flexibility is our friend here.
c Copyright Okiok Data 2002
5
Why Migrating to Triple DES is Not Easy
4.3
Key blocks
Current key blocks2 such as the key block for the keys encrypted in the payment application key databases, and the key blocks for the key exchange keys, are not adequate to support 3DES. Attacks have been presented ([7], [5]) against key blocks currently used by the financial institutions, in which keys can be used for functionalities that they where not intended for, and knowledge of certain working keys can leak knowledge of other keys, violating security property SP2. The attacks work even if the key blocks use encryption with a provably secure mode of operation such as CBC, even when used in combination with variants or control vectors3 . The techniques of the attacks are based on substituting parts of the keys and brute forcing single DES keys twice. This can be done on average in 2 × 255 = 256 steps, which is much smaller than 2112 (the number of steps needed to try each and every double length 3DES key). This clearly violates security properties SP3 and SP4. It is crucial to cryptographically tie the functionality of a key to the key itself, this can be achieved by securely using a MAC or a digital signature scheme for example, or an encryption mode of operation that also provides integrity such as the one described in [8]. A proposal to ANSI X.9F for a new key block format is described in [5]. What is important to remember is that encryption alone does not provide integrity.
4.4 Hardware update
There are obvious problems if hardware, such as PIN pads, ATMs and cryptographic processors, cannot be upgraded in the field. Even if upgrades can be done in the field, migration has to be coordinated with other devices and software. If a PIN pad can only use single DES and a switch has been upgraded to use 3DES, the switch needs to be configured to be backwards compatible with single DES. This backwards compatibility feature could potentially be used to the advantage of an attacker (as was discussed in section 4.1). There is also a question of speed. 3DES encryption and decryption takes approximately three times longer to execute than does single DES encryption and
a key block is a data structure for specifying the value and attributes of a key that is to be stored or exchanged, key blocks for private keys usually use some sort of encryption. 3 variants and control vectors are bitpatterns that are bound to encrypted keys by a XOR operation with the encrypting key. If a naive attacker introduces into a cryptoprocessor a cryptogram of a key bounded by a control vector or variant of the wrong type the cryptoprocessor’s decryption operation should simply produce garble and no useful information about the key would be revealed. This technique does not work when encrypting keys longer then the block size.
2
c Copyright Okiok Data 2002
6
Why Migrating to Triple DES is Not Easy decryption4 . Memory allocation and caching can also affect the speed of execution of 3DES encryption and decryption, especially during the key setup stages. Some custom designed cryptoprocessors also deal poorly with the safeguarding of 3DES keys in memory register, some key parts can get overwritten in their register slots by other 3DES key parts or single DES keys if allocation is not done correctly. This was observed in a PIN pad we once evaluated, the problem had to do more with the architecture of the hardware rather than 3DES itself however, mostly due to the fact that some embedded systems have limited storage space. The lesson to learn is that a cryptoprocessor can work perfectly well when it only does single DES but start showing strange behavior when using 3DES.
4.5
Software/Firmware update
Command sets will undoubtedly be modified if a system is to support 3DES. It is crucial to make certain that there will be no compatibility problems and that security is not affected. For example, one can have software running on a device which will accept to load new software after verifying a MAC. If the new software is needed to use 3DES, but the old software’s MAC is based on single DES, one needs to make sure that this procedure is secure in the given context (for example, it is secure if you still trust single DES). It is highly recommended to analyze any new transaction set, to be convinced of this one simply has to look at the recent API-level attacks on embedded systems described in [2].
4.6
Payment application database
We already talked about the need for a new key block in section 4.3. It is also important to consider the simple fact that 3DES keys are larger than single DES keys and that the format of the key blocks will be different. One should make sure that databases will be able to handle this change.
4.7
Key Management
Key management is probably one of the more complex parts of any cryptosystem. New kinds of cryptographic keys means new kinds of key management. Key exchange methods (manual or automated) for 3DES will differ from those for
4
if no pipelining is done.
c Copyright Okiok Data 2002
7
Why Migrating to Triple DES is Not Easy
single DES. For example, split knowledge schemes for 3DES are different than those for single DES and it is important to make sure that the new schemes that will be used continue to satisfy the security requirements. When one splits a 3DES key between two individuals, a typical scheme will produce four parts, K 1L and K 2L , which when XORed together forms KL (the first part of the 3DES key) as well as K 1R and K 2R which when XORed together forms KR (the other part of the 3DES key). Now, the scheme is secure if the first person is in custody of K 1L and K 1R , and the second person is in custody of K 2L and K 2R . This way, neither individual has any information what so ever about the 3DES key. However, if the first individual is in custody of K 1L and K 2L , and the second of K 1R and K 2R , each individual learns information about the key (notably, one whole part of the key by XORing both of the individual’s parts together). If one of the individuals can have access to the encryption of a message under the key in question (most processors will have a command that will allow them to do so), they simply need to do the equivalent of a brute force attack on a single DES key to compute the whole 3DES key. Thus, there is not 2112 security. Key generation is another important part of key management. It is important to securely generate random 3DES keys, poor randomness if often a weak point in a cryptosystem, (see [6] for a motivational example.) For example, one should not generate a 3DES key by first generating a single DES key, defining it to be KL , and then using a known variant in order to generate KR from KL . Both part of the 3DES key should be generated independently and uniformly at random.
4.8
Old vulnerabilities
Most systems have vulnerabilities, see for example [1]. Some security vulnerabilities are known and they are considered acceptable in certain contexts. It all depends on the outcome of a risk analysis, which is a very important step to take when migrating a system. It is important to fully study the risks that might arise and determine the best way to manage them, to accomplish this one needs to know the security properties that must be achieved and the security state of the system and evaluate the risks. Risk analysis should be done at every phase of the migration plan. When migrating to 3DES, with the goal of achieving 2112 security, it is also important to reconsider old vulnerabilities. It might have been acceptable for a system to be vulnerable to a 256 brute force attack at the time of deployment and accreditation, but it is probably no longer acceptable. When you modify a system that has old vulnerabilities you also risk the danger of creating new ones,
c Copyright Okiok Data 2002
8
Why Migrating to Triple DES is Not Easy
sometimes even worst ones. One should take time to analyze the problem, review the security properties that the system is to respect and make sure that the updated system does not introduce any new security loopholes. It is important to try to solve old security problems and avoid new vulnerabilities.
5
Easing the migration
In this section we give a list of checkpoints useful for easing a migration from single DES to 3DES. This is not intended to be an exhaustive list but simply a bases for reflection on planning the migration. The items are not presented in any particular order. 1. Make sure that implementations of DES can be configured to use 3DES. As mentioned in section 4.4, just because an implementation states that it is 3DES compatible does not necessarily mean that it will work with ease. Before planning a migration to 3DES, make sure that the system is capable of using 3DES. Systems already deployed may require re-certificaton/reaccreditation. 2. Validate that the system satisfies the new algorithm’s memory requirements. Double length 3DES keys are twice as long, and new block formats for encrypting 3DES keys might have some extra overhead. One should verify that databases, processors, etc., can handle this increase in data size. 3. 3DES keys should not be protected using single DES keys. It is important to verify that DES does not become the weakest link in any segment of the system. 4. Planning ahead. One should plan the hardware and software updates, so that everything is coordinated as necessary. Procedures need to be reviewed and most probably updated. 5. If both single DES and 3DES are to be supported, it might be useful to split the system into two parts, one that securely uses 3DES and no single DES encryption and the other that continues to use single DES. For example, instead of having two cryptoprocessors configured to both use single DES and 3DES, have one cryptoprocessor simply use single DES and the other strictly use 3DES. This may require modifications to the transaction dispatcher in order for it to act differently depending on the end point. This enables at least part of the system to attain 3DES security, instead of having
c Copyright Okiok Data 2002
9
Why Migrating to Triple DES is Not Easy
the whole system vulnerable to single DES because it is needed for backwards compatibility or other functionality that is not part of the migration plan. 6. Sending managers on site in order to load new keys can be costly. It might be useful to try to synchronize on site hardware update with on site physical key loading. 7. Certain cryptographic keys will no longer be used, evaluate the key hierarchy and decommission obsolete keys. Managing keys is a challenging task, keeping unused keys around simply adds to the complexity. 8. It might be useful to construct wrappers around existing encryption technology, so that these can be changed and updated more conveniently (DES to 3DES, or DES to AES for example). One has to be careful however so as to not give way to security weaknesses based on backward compatibility of the encryption technology. 9. Risk Analysis. This is probably the most important part of the migration. As discussed in section 4.8, risk analysis should be done at every phase of the migration plan. These are just a few suggestions and points to be considered. Migrating from single DES to 3DES is not easy, but careful planning and adequate analysis and support can ease the process.
6
Conclusion
The Data Encryption Standard (DES) has allowed financial institutions thru out the world to share automated self-service facilities while maintaining open competition on the market. This 1977 based cryptographic standard is no longer considered secure and the general approach (approved by NIST and the financial industry) is to replace DES by 3DES everywhere encryption is done. We have pointed out and discussed many issues concerning migration to 3DES. Banks will need to carefully review their own implementation to take into account these concerns.
c Copyright Okiok Data 2002
10
Why Migrating to Triple DES is Not Easy
References
[1] A NDERSON , R. Why cryptosystems fail, from communications of the ACM, november, 1994. In William Stallings, Practical Cryptography for Data Internetworks, IEEE Computer Society Press, 1996. 1996. [2] A NDERSON , R., AND B OND , M. API level attacks on embedded systems. IEEE Computer 34 (October 2001). [3] B ELLARE , M., K ILIAN , J., AND ROGAWAY, P. The security of the cipher block chaining message authentication code. JCSS: Journal of Computer and System Sciences 61 (2000). [4] B IHAM , E. Cryptanalysis of multiple modes of operation. In Proc. 4th International Advances in Cryptology Conference – ASIACRYPT ’94 (1994), pp. 278–292. [5] C OMPAQ C OMPUTER C ORPORATION. A proposal to ANSI X.9F for a new, standard key block to enable secure storage, transmission and control of cryptographic keys, 2002. [6] G OLDBERG , I., AND WAGNER , D. Randomness and the Netscape browser. Dr. Dobb’s Journal of Software Tools 21, 1 (Jan. 1996), 66, 68–70. [7] H OPKINS , D. Private Communication (2001). [8] J UTLA , C. S. Encryption modes with almost free message integrity. In Advances in Cryptology – EUROCRYPT ’ 2001 (Innsbruck, Austria, 2001), B. Pfitzmann, Ed., vol. 2045 of Lecture Notes in Computer Science, Springer-Verlag, Berlin Germany, pp. 525–542. [9] M. B OND , R. C. Extracting a 3des key from an ibm 4758. http://www.cl.cam.ac.uk/ rnc1/descrack/. [10] M ENEZES , A. J. A. J., VAN O ORSCHOT , P. C., AND VANSTONE , S. A. Handbook of applied cryptography. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL 33431-9868, USA, 1997.
c Copyright Okiok Data 2002
11
Why Migrating to Triple DES is Not Easy
About Okiok Data OKIOK DATA has been at the forefront of the Information Security field since 1983. The new business models born from the use of IT have brought about a number of new business risks. Counting on its many years of experience in IT security, OKIOK DATA proposes a set of services that will help you manage these risks in a manner that is appropriate for your business: Analysis of your requirements, your systems architecture, and the threats linked to your business activities. Diagnostics on the security level of your systems and identification of the areas of weaknesses. Product comparisons and recommendations on security measures and products that will help control your risks. Whether you wish to add specific security expertise in a timely fashion, or to simply complement your team of security professionals, OKIOK DATA’s experts can get involved at any stage of your projects, including at the corporate strategic level. Our clients come from, amongst others, the financial world, telecommunications, health and governments.
3945 St-Martin West Laval (Quebec) Canada, H7T 1B7 Phone: (450) 681-1681 Fax: (450) 681-1682 www.okiok.com
c Copyright Okiok Data 2002
12
Abstract Financial institutions are performing large scale migrations of their systems from DES to triple-DES. In this white paper we describe the basic characteristics of DES and triple-DES and look at the security properties that a financial transaction system will want to achieve. We then look at the problems related with a migration from DES to triple-DES, enumerating and discussing several points that we suggest should be considered. Finally, we give some suggestions that will help ease the problems of migration.
Contents
1 2 3 4 Introduction Single DES and triple-DES Security properties wanted Migration issues 4.1 DES is the weakest link . . . 4.2 The algorithm itself . . . . . 4.3 Key blocks . . . . . . . . . 4.4 Hardware update . . . . . . 4.5 Software/Firmware update . 4.6 Payment application database 4.7 Key Management . . . . . . 4.8 Old vulnerabilities . . . . . Easing the migration Conclusion 1 1 3 4 4 5 6 6 7 7 7 8 9 10
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 6
Why Migrating to Triple DES is Not Easy
1
Introduction
DES, the Data Encryption Standard, is a cryptographic algorithm that was standardized in 1977 by the National Institute of Science and Technology (NIST). When the financial industry started to deploy ATMs they opted for DES for securing transactions. This choice was reinforced by the development of X9 standards for financial transactions that were based on DES. DES has stood the test of time, no attack against this encryption algorithm in practice has been better than brute forcing the key space. However, DES uses short keys, with current technology the key space (of size 256 ) can be exhausted in around 56 hours using one single machine worth less than 250 000 US dollars, or in 22 hours with the combined help of a network of about 100 000 personal computers. This means that single DES is no longer secure. On the other hand, triple-DES, as defined in ANSI 9.52, is considered to be secure. Indeed, NIST renewed the DES standard in 1983 and 1988, in 1993 it renewed it with hesitation and controversy and in 1999 DES was to be used only in legacy systems. NIST, in 1999, standardized triple-DES, based on ANSI 9.52. Triple-DES is a secure replacement for single DES, it is not currently feasible to exhaustively search the key space of triple-DES, nor will it be in the near future unless drastic unpredictable technological and/or cryptanalysis advancements occur. In 1993 the financial industry had started replacing DES by triple-DES for the confidentiality of keys residing in cryptographic processors. In 1999, with the concordance of NIST no longer approving single DES, the financial industry started planning a migration, which consists of replacing single DES with tripleDES in all its systems wherever single DES is used. This migration plan however places the industry, which uses single DES widely, in a challenging position. As will be discussed in this document, the process of migrating from single DES to triple-DES is not as simple as just substituting one algorithm for another.
2
Single DES and triple-DES
DES is a block cipher, encryption algorithm, which encrypts messages of block size 64 bits and produces cryptograms of length 64 bits using a 56-bit key (DES keys are actually 64 bits in length but 8 bits act as parity bits so only 56 bits are actually used for encryption).
c Copyright Okiok Data 2002
1
Why Migrating to Triple DES is Not Easy
We say that DES has strength 256 , meaning that the most efficient way to attack DES in practice1 is to search its key space of size 256 . That is, to attack DES in practice one has to try each and every possible key until the correct encryption key is identified, this takes on average 256 /2 = 255 steps. Triple-DES, noted as 3DES from here on, uses 2 keys, chosen independently at random, to DES encrypt a message multiple times. There are also ways to use 3DES with 3 different keys, but these schemes do not give a significant amount of extra security in theory and are not considered in financial systems. The most common technique is to encrypt the initial plaintext message with one key, decrypt the result with a second key and finally encrypt this last result with the first key again. This is known as E-D-E double length key 3DES encryption and is illustrated in the following figure.
other attacks exist in theory, but they demand an unreasonable amount of known or chosen plaintext-ciphertext pairs which renders the attacks unpractical.
1
c Copyright Okiok Data 2002
2
Why Migrating to Triple DES is Not Easy
E-D-E 3DES is compatible with single DES (when KL and KR are identical, E-D-E 3DES produces the same result as single DES). From here on, when we will talk about 3DES we will be referring to double length key E-D-E 3DES. The strength of 3DES is approximately 2112 since using two 56 bit keys in E-D-E 3DES is effectively equal to using one 112-bit key. A brute force search of 3DES 2112 key space is currently not feasible nor will it be in the near future.
3
Security properties wanted
Many security properties are wanted in a financial transaction system. We will not go into details and enumerate all of the security properties wanted but simply mention a couple of them in an informal way so as to motivate some of the discussions in the following sections. SP1 A cryptographic key should not be in cleartext in any single point of the system. This is the basic security property that a financial institution must achieve in order for users to have any sort of trust in the system. This is also an important point when different institutions interchange financial data between themselves, the security of one institution depends on that of others. To achieve this property cryptographic keys must be stored in secure cryptographic processors, if they are ever outside these processors they must be in a form that does not compromise the security of the keys, such as in split knowledge (under the possession of different individuals having certain permissions), or encrypted under another cryptographic key which is protected in a secure cryptographic processor. SP2 Security against known key attacks, if a working key in the system is discovered, this should not enable an attacker to figure out the values of any other keys in the system. Some would say that if a system is secure, no single key will ever be compromised so there is no need to worry about this security property, but as we will see later on this can be a dangerous way of thinking. SP3 The security of any 3DES key should be 2112 . It should not be possible for example to break a 3DES key by breaking one or a couple of single DES keys. If a cryptographic key is to be protected by another one, this last key should be of cryptographic strength equal or greater than the key it is protecting. This implies for example, among other things, that if any
c Copyright Okiok Data 2002
3
Why Migrating to Triple DES is Not Easy
working key is a 3DES key, the key encryption key should be a 3DES key as well. SP4 It should not be possible to combine different key parts in order to trick a secure cryptographic processor into revealing information that can lead to breaking any cryptographic key secured by the processor. This is important to consider for example when deciding how keys protected outside a security processor should be stored. Of course, when analyzing the security of a system, the above security properties must be specified more formally, and others should be enumerated, but the above list is enough for us to be able to discuss about security problems related to migrating from DES to 3DES.
4
Migration issues
It is not sufficient to simply replace single DES with 3DES, security wise and operationally wise. In what follows we discuss about several problems that might arise and issues that should be considered when attempting to migrate from single DES to 3DES.
4.1
DES is the weakest link
A system is just as secure as its weakest link. In a system that is composed of PIN pads, ATMs, acquiring hosts, switches, alternate switches, processors, etc., if a single entity in the system still utilizes single DES there is a possibility that the security of the whole system might be compromised by an attack on single DES. As an extreme example, consider a secure cryptographic processor of an acquiring host that uses a 3DES master file key (MFK), but also uses a single DES key exchange key (KEK); the confidentiality of all keys that are sent to the processor can be compromised, even if the keys stored in the local database are protected by 3DES encryption, so the fact that the MFK key is 3DES does not provide much of a security advantage. Less obvious examples can also lead to extreme security breakage. Consider the attack against the IBM 4758 cryptoprocessors using the CCA software that was found enabling an individual with a certain permission to extract all DES and 3DES keys from the processors ([9]). The attack was made possible by a combination of things that existed because the processors had to
c Copyright Okiok Data 2002
4
Why Migrating to Triple DES is Not Easy
continue to support single DES even though 3DES was used for protecting the keys. Due to the complexity of financial systems, it is not feasible to replace all keys with 3DES keys right away, systems will have to live in a heterogeneous state. It is important however to analyze each situation and to consider how the system satisfies the security properties wanted. Most certainly, until all keys are replaced with 3DES keys, the system will not achieve 2112 security, but the system can be upgraded progressively so as to withstand more and more attacks. Security, as in this case, is often an incremental process.
4.2
The algorithm itself
When using 3DES certain variants of modes of operations are available which are not for single DES. Some of these variants may seem attractive at first glance because of their performance gain properties, unfortunately they are not all secure. For example, for single DES, cipher-block chaining (CBC) is a good mode to use since it is provably secure [3]. However, there are different ways of implementing CBC mode for 3DES, one can use triple-outer-CBC mode (CBC mode applied directly to 3DES) or triple-inner-CBC mode (a variant, a multiple encryption mode of operation where the feedbacks are taken from the single DES operations of which 3DES is composed of). We do not describe these modes in further detail in this document (see [10] if interested), it suffices to know that they are two variants of CBC for 3DES. Although triple-inner-CBC mode can appear to be more appealing since it can be pipelined, thus allowing for more efficient implementations, triple-inner-CBC mode is significantly weaker than outer-inner-CBC mode under certain attack models and is not recommended ([4]). When migrating from single DES to 3DES and designing a new system or looking for existing solutions, it might also be fruitful to consider other encryption algorithms as well, such as the AES, which will become a U.S. government standard may 26th, 2002. If when migrating to 3DES you also make your system ready to accept other encryption algorithms or modes of operations, you will have an advantage and will save time and money in the long run. Flexibility is our friend here.
c Copyright Okiok Data 2002
5
Why Migrating to Triple DES is Not Easy
4.3
Key blocks
Current key blocks2 such as the key block for the keys encrypted in the payment application key databases, and the key blocks for the key exchange keys, are not adequate to support 3DES. Attacks have been presented ([7], [5]) against key blocks currently used by the financial institutions, in which keys can be used for functionalities that they where not intended for, and knowledge of certain working keys can leak knowledge of other keys, violating security property SP2. The attacks work even if the key blocks use encryption with a provably secure mode of operation such as CBC, even when used in combination with variants or control vectors3 . The techniques of the attacks are based on substituting parts of the keys and brute forcing single DES keys twice. This can be done on average in 2 × 255 = 256 steps, which is much smaller than 2112 (the number of steps needed to try each and every double length 3DES key). This clearly violates security properties SP3 and SP4. It is crucial to cryptographically tie the functionality of a key to the key itself, this can be achieved by securely using a MAC or a digital signature scheme for example, or an encryption mode of operation that also provides integrity such as the one described in [8]. A proposal to ANSI X.9F for a new key block format is described in [5]. What is important to remember is that encryption alone does not provide integrity.
4.4 Hardware update
There are obvious problems if hardware, such as PIN pads, ATMs and cryptographic processors, cannot be upgraded in the field. Even if upgrades can be done in the field, migration has to be coordinated with other devices and software. If a PIN pad can only use single DES and a switch has been upgraded to use 3DES, the switch needs to be configured to be backwards compatible with single DES. This backwards compatibility feature could potentially be used to the advantage of an attacker (as was discussed in section 4.1). There is also a question of speed. 3DES encryption and decryption takes approximately three times longer to execute than does single DES encryption and
a key block is a data structure for specifying the value and attributes of a key that is to be stored or exchanged, key blocks for private keys usually use some sort of encryption. 3 variants and control vectors are bitpatterns that are bound to encrypted keys by a XOR operation with the encrypting key. If a naive attacker introduces into a cryptoprocessor a cryptogram of a key bounded by a control vector or variant of the wrong type the cryptoprocessor’s decryption operation should simply produce garble and no useful information about the key would be revealed. This technique does not work when encrypting keys longer then the block size.
2
c Copyright Okiok Data 2002
6
Why Migrating to Triple DES is Not Easy decryption4 . Memory allocation and caching can also affect the speed of execution of 3DES encryption and decryption, especially during the key setup stages. Some custom designed cryptoprocessors also deal poorly with the safeguarding of 3DES keys in memory register, some key parts can get overwritten in their register slots by other 3DES key parts or single DES keys if allocation is not done correctly. This was observed in a PIN pad we once evaluated, the problem had to do more with the architecture of the hardware rather than 3DES itself however, mostly due to the fact that some embedded systems have limited storage space. The lesson to learn is that a cryptoprocessor can work perfectly well when it only does single DES but start showing strange behavior when using 3DES.
4.5
Software/Firmware update
Command sets will undoubtedly be modified if a system is to support 3DES. It is crucial to make certain that there will be no compatibility problems and that security is not affected. For example, one can have software running on a device which will accept to load new software after verifying a MAC. If the new software is needed to use 3DES, but the old software’s MAC is based on single DES, one needs to make sure that this procedure is secure in the given context (for example, it is secure if you still trust single DES). It is highly recommended to analyze any new transaction set, to be convinced of this one simply has to look at the recent API-level attacks on embedded systems described in [2].
4.6
Payment application database
We already talked about the need for a new key block in section 4.3. It is also important to consider the simple fact that 3DES keys are larger than single DES keys and that the format of the key blocks will be different. One should make sure that databases will be able to handle this change.
4.7
Key Management
Key management is probably one of the more complex parts of any cryptosystem. New kinds of cryptographic keys means new kinds of key management. Key exchange methods (manual or automated) for 3DES will differ from those for
4
if no pipelining is done.
c Copyright Okiok Data 2002
7
Why Migrating to Triple DES is Not Easy
single DES. For example, split knowledge schemes for 3DES are different than those for single DES and it is important to make sure that the new schemes that will be used continue to satisfy the security requirements. When one splits a 3DES key between two individuals, a typical scheme will produce four parts, K 1L and K 2L , which when XORed together forms KL (the first part of the 3DES key) as well as K 1R and K 2R which when XORed together forms KR (the other part of the 3DES key). Now, the scheme is secure if the first person is in custody of K 1L and K 1R , and the second person is in custody of K 2L and K 2R . This way, neither individual has any information what so ever about the 3DES key. However, if the first individual is in custody of K 1L and K 2L , and the second of K 1R and K 2R , each individual learns information about the key (notably, one whole part of the key by XORing both of the individual’s parts together). If one of the individuals can have access to the encryption of a message under the key in question (most processors will have a command that will allow them to do so), they simply need to do the equivalent of a brute force attack on a single DES key to compute the whole 3DES key. Thus, there is not 2112 security. Key generation is another important part of key management. It is important to securely generate random 3DES keys, poor randomness if often a weak point in a cryptosystem, (see [6] for a motivational example.) For example, one should not generate a 3DES key by first generating a single DES key, defining it to be KL , and then using a known variant in order to generate KR from KL . Both part of the 3DES key should be generated independently and uniformly at random.
4.8
Old vulnerabilities
Most systems have vulnerabilities, see for example [1]. Some security vulnerabilities are known and they are considered acceptable in certain contexts. It all depends on the outcome of a risk analysis, which is a very important step to take when migrating a system. It is important to fully study the risks that might arise and determine the best way to manage them, to accomplish this one needs to know the security properties that must be achieved and the security state of the system and evaluate the risks. Risk analysis should be done at every phase of the migration plan. When migrating to 3DES, with the goal of achieving 2112 security, it is also important to reconsider old vulnerabilities. It might have been acceptable for a system to be vulnerable to a 256 brute force attack at the time of deployment and accreditation, but it is probably no longer acceptable. When you modify a system that has old vulnerabilities you also risk the danger of creating new ones,
c Copyright Okiok Data 2002
8
Why Migrating to Triple DES is Not Easy
sometimes even worst ones. One should take time to analyze the problem, review the security properties that the system is to respect and make sure that the updated system does not introduce any new security loopholes. It is important to try to solve old security problems and avoid new vulnerabilities.
5
Easing the migration
In this section we give a list of checkpoints useful for easing a migration from single DES to 3DES. This is not intended to be an exhaustive list but simply a bases for reflection on planning the migration. The items are not presented in any particular order. 1. Make sure that implementations of DES can be configured to use 3DES. As mentioned in section 4.4, just because an implementation states that it is 3DES compatible does not necessarily mean that it will work with ease. Before planning a migration to 3DES, make sure that the system is capable of using 3DES. Systems already deployed may require re-certificaton/reaccreditation. 2. Validate that the system satisfies the new algorithm’s memory requirements. Double length 3DES keys are twice as long, and new block formats for encrypting 3DES keys might have some extra overhead. One should verify that databases, processors, etc., can handle this increase in data size. 3. 3DES keys should not be protected using single DES keys. It is important to verify that DES does not become the weakest link in any segment of the system. 4. Planning ahead. One should plan the hardware and software updates, so that everything is coordinated as necessary. Procedures need to be reviewed and most probably updated. 5. If both single DES and 3DES are to be supported, it might be useful to split the system into two parts, one that securely uses 3DES and no single DES encryption and the other that continues to use single DES. For example, instead of having two cryptoprocessors configured to both use single DES and 3DES, have one cryptoprocessor simply use single DES and the other strictly use 3DES. This may require modifications to the transaction dispatcher in order for it to act differently depending on the end point. This enables at least part of the system to attain 3DES security, instead of having
c Copyright Okiok Data 2002
9
Why Migrating to Triple DES is Not Easy
the whole system vulnerable to single DES because it is needed for backwards compatibility or other functionality that is not part of the migration plan. 6. Sending managers on site in order to load new keys can be costly. It might be useful to try to synchronize on site hardware update with on site physical key loading. 7. Certain cryptographic keys will no longer be used, evaluate the key hierarchy and decommission obsolete keys. Managing keys is a challenging task, keeping unused keys around simply adds to the complexity. 8. It might be useful to construct wrappers around existing encryption technology, so that these can be changed and updated more conveniently (DES to 3DES, or DES to AES for example). One has to be careful however so as to not give way to security weaknesses based on backward compatibility of the encryption technology. 9. Risk Analysis. This is probably the most important part of the migration. As discussed in section 4.8, risk analysis should be done at every phase of the migration plan. These are just a few suggestions and points to be considered. Migrating from single DES to 3DES is not easy, but careful planning and adequate analysis and support can ease the process.
6
Conclusion
The Data Encryption Standard (DES) has allowed financial institutions thru out the world to share automated self-service facilities while maintaining open competition on the market. This 1977 based cryptographic standard is no longer considered secure and the general approach (approved by NIST and the financial industry) is to replace DES by 3DES everywhere encryption is done. We have pointed out and discussed many issues concerning migration to 3DES. Banks will need to carefully review their own implementation to take into account these concerns.
c Copyright Okiok Data 2002
10
Why Migrating to Triple DES is Not Easy
References
[1] A NDERSON , R. Why cryptosystems fail, from communications of the ACM, november, 1994. In William Stallings, Practical Cryptography for Data Internetworks, IEEE Computer Society Press, 1996. 1996. [2] A NDERSON , R., AND B OND , M. API level attacks on embedded systems. IEEE Computer 34 (October 2001). [3] B ELLARE , M., K ILIAN , J., AND ROGAWAY, P. The security of the cipher block chaining message authentication code. JCSS: Journal of Computer and System Sciences 61 (2000). [4] B IHAM , E. Cryptanalysis of multiple modes of operation. In Proc. 4th International Advances in Cryptology Conference – ASIACRYPT ’94 (1994), pp. 278–292. [5] C OMPAQ C OMPUTER C ORPORATION. A proposal to ANSI X.9F for a new, standard key block to enable secure storage, transmission and control of cryptographic keys, 2002. [6] G OLDBERG , I., AND WAGNER , D. Randomness and the Netscape browser. Dr. Dobb’s Journal of Software Tools 21, 1 (Jan. 1996), 66, 68–70. [7] H OPKINS , D. Private Communication (2001). [8] J UTLA , C. S. Encryption modes with almost free message integrity. In Advances in Cryptology – EUROCRYPT ’ 2001 (Innsbruck, Austria, 2001), B. Pfitzmann, Ed., vol. 2045 of Lecture Notes in Computer Science, Springer-Verlag, Berlin Germany, pp. 525–542. [9] M. B OND , R. C. Extracting a 3des key from an ibm 4758. http://www.cl.cam.ac.uk/ rnc1/descrack/. [10] M ENEZES , A. J. A. J., VAN O ORSCHOT , P. C., AND VANSTONE , S. A. Handbook of applied cryptography. The CRC Press series on discrete mathematics and its applications. CRC Press, 2000 N.W. Corporate Blvd., Boca Raton, FL 33431-9868, USA, 1997.
c Copyright Okiok Data 2002
11
Why Migrating to Triple DES is Not Easy
About Okiok Data OKIOK DATA has been at the forefront of the Information Security field since 1983. The new business models born from the use of IT have brought about a number of new business risks. Counting on its many years of experience in IT security, OKIOK DATA proposes a set of services that will help you manage these risks in a manner that is appropriate for your business: Analysis of your requirements, your systems architecture, and the threats linked to your business activities. Diagnostics on the security level of your systems and identification of the areas of weaknesses. Product comparisons and recommendations on security measures and products that will help control your risks. Whether you wish to add specific security expertise in a timely fashion, or to simply complement your team of security professionals, OKIOK DATA’s experts can get involved at any stage of your projects, including at the corporate strategic level. Our clients come from, amongst others, the financial world, telecommunications, health and governments.
3945 St-Martin West Laval (Quebec) Canada, H7T 1B7 Phone: (450) 681-1681 Fax: (450) 681-1682 www.okiok.com
c Copyright Okiok Data 2002
12
