Internet Engineering Task Force D.Au Internet Draft P.Balke Category: Informational H.Fruehauf Expires: December, 2002 C.Helbig,K.Helbig Zyfer June, 2002 Zyfer's StealthKey Management for frequent rekeying Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026 except that the right to produce derivative works is not granted. This memo provides information for the internet community. This memo does not specify an Internet standard of any kind and does not represent a consensus by an IETF working group. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a key management, designated as StealthKey Management. StealthKey Management establishes short-term keys which are derived from a common long-term key in two entities, referred to as sender and receiver, for symmetric encryption algorithms and cryptographic authentication protocols based on a common secret. Stealthkey Management covers two main parts: - Independent generation of the short-term keys by the sender and receiver from either the common long-term key and the time, or from the common long-term key and a sequence number. - Synchronization of the short-term keys between both entities. Helbig Informational [Page 1] Internet Draft StealthKey Management June 2002 The important advantages of using StealthKey Management for message encryption and authentication are the ability to change the short- term keys frequently, without exchanges between sender and receiver and the independence of other applications for the key change process (in band). A commonly used term for key change is rekeying. The required long-term key can be established remotely through the use of known symmetric or asymmetric key protocols, or locally via manual setup. StealthKey Management improves the performance of any of today's key management protocols, by extending the protocol with the frequent changing of keys. Table of Contents 1. Introduction....................................................3 1.1 Key Management Basics.......................................3 2. Terminology.....................................................3 3. StealthKey Management Basics....................................4 4. Pseudo Random Bit Generator.....................................4 4.1 Linear Generator............................................5 4.1.1 Length................................................5 4.1.2 Seed..................................................5 4.1.3 Starting Time.........................................6 4.1.4 Increment.............................................6 4.1.5 States................................................6 4.1.6 Output................................................7 4.2 AES-256.....................................................7 4.2.1 Input and Output......................................7 4.3 Output of the PRBG..........................................7 4.4 Cryptoperiod of the Short-term Keys.........................7 5. Generation and Synchronization of Short-term Keys by H-realization...................................................8 5.1 Generation..................................................8 5.2 Synchronization.............................................9 6. Generation and Synchronization of Short-term Keys by T-realization..................................................10 6.1 Generation.................................................10 6.2 Synchronization............................................10 7. Generation and Synchronization of Short-term Keys by N-realization..................................................11 7.1 Generation.................................................11 7.2 Synchronization............................................12 8. Long-term Keys.................................................13 9. Security Considerations........................................13 Intellectual Property Statement...................................15 References........................................................15 Authors' Addresses................................................15 Full Copyright Statement..........................................16 Expiration........................................................17 Helbig Informational [Page 2] Internet Draft StealthKey Management June 2002 1. Introduction The first sections of this document provides a detailed description of StealthKey Management, while the final sections contain security considerations and references. 1.1 Key Management Basics All of the following key management definitions are given in the reference [MENZ]. "A key management is the set of techniques and procedures supporting the establishment and maintenance of keying relationships between authorized parties." "The cryptoperiod of a key is the time period over which it is valid for use by legitimate parties." Keys for encryption of data traffic may be classified on the basis of the cryptoperiod as long-term keys or short-term keys. For encryption of stored data this classification is not applicable. These keys must be available over the lifetime of the encrypted data. Again, in the reference [MENZ], the key establishment is subdivided generally into key transport and key agreement. "Key transport is a key establishment technique where one party creates or otherwise obtains a secret value, and securely transfers it to other parties. Key agreement is a key establishment technique in which a shared secret is derived by two (or more) parties as a function of information contributed by, or associated with, each of these, (ideally) such that no party can predetermine the result value." Additional variations of key establishment exist; e.g., key derivation, whereby a key is computed per session from a parameter provided in a single message by one party (e.g., timestamp) and a long-term key stored in all participating parties. 2. Terminology The following operators are used to describe algorithms: - "x^i" denotes "x to the i-th power" - "x_i" denotes "x sub i" - If the subscript (or the exponentiation) is an expression, we surround it in braces, as in "x_{i+1}". - "X||Y" denotes the result of the concatenation of the items X and Y in that order - "/" yields the quotient of integers, - "+" the addition of integers, - "-" the subtraction of integers - "*" indicates multiplication of integers. Helbig Informational [Page 3] Internet Draft StealthKey Management June 2002 3. StealthKey Management Basics The StealthKey Management does not transport encrypted short-term keys across the media, nor does it perform key agreement or key derivation functions like described in paragraph 1. Sender and receiver build short-term keys independently from each other. The synchronization is time based (H- and T-realization) or event based (N-realization). Synchronization means that for each ciphertext, the receiver determines from two, three or more short-term keys, which short-term key the sender used. The receiver may utilize various criteria for the process of determining the correct short-term key (what presupposes different protocol steps by the sender): - Criteria 1: 32 bit additional information in the plaintext (Synchronization Header, SynH) - Criteria 2: Timestamp (equal or less than 32 bits) relating to the ciphertext - Criteria 3: Sequence number of the ciphertxt (e.g., ESP sequence number [RFC 2406]) In addition to the above, other criteria are possible. This Internet draft describes the above three realizations of StealthKey Management, named as H(eader)-realization, T(ime)-realization and N(umber)-realization. In all three realizations, StealthKey Management generates short- term keys from a long-term key of 256 bits with help of a cryptographic pseudo random bit generator (PRBG). The cryptoperiod sets the PRBG clock for the generation of the short-term keys. The cryptoperiod is specified in whole seconds (H- and T-realization) or numbers of events (positive integers) by the N- realization. The time period over which the events happen is not relevant. Short-term keys are generated independently by sender and receiver. The sender uses only one short-term key at a time and the receiver uses two, three or more. For use in open networks we recommend three (two) short-term keys by the receiver in the case of H- and T-realization (N-realization), and the applications with three and two short-term keys will be the focus of this document. However, it is possible to use more than three short-term keys for H- and T-realization, if the sender and receiver generally have large time differences or large delays in the data run time in the network. 4. Pseudo Random Bit Generator The short-term keys are generated with the help of a cryptographic Helbig Informational [Page 4] Internet Draft StealthKey Management June 2002 pseudo random bit generator (PRBG), which consists of a linear congruential generator (LG) and the Advanced Encryption Standard AES-256 of block size 256 [FIPS 197]. The 256 bit key for the AES-256 is defined as the long-term key of StealthKey Management. 4.1 Linear Generator The LG is determined by fixed, open parameters for the use in open networks. In closed networks these parameters can be used as additional long-term keys. 4.1.1 Length Assume that a short-term key has m bits, where m is a positive integer. - H-realization: The length of the LG is the integer n, where n is the smallest multiple of 256 and n is greater or equal to m+32. - T- and N-realization: The length of the LG is the integer n, where n is the smallest multiple of 256 and n is greater or equal to m. 4.1.2 Seed For all realizations the seed of the LG is a randomly chosen, but fixed bit sequence s0_{n-1}...s0_1 s0_0 of the length n. Let S[0] be the positive integer what is represented by this bit sequence. For the use in open networks S[0] is the positive integer what is represented by the n/256 multiple concatenation of following hexadecimal value in big endian format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x7A | 0x1C | 0xAC | 0xA7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x71 | 0xC1 | 0xA1 | 0xCA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xCC | 0xC1 | 0xA1 | 0x1A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAC | 0xCA | 0xC1 | 0xCA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xC7 | 0x77 | 0xA7 | 0xC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xC1 | 0xCC | 0xA1 | 0x7C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xA1 | 0x11 | 0x77 | 0x1A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x11 | 0x11 | 0xC7 | 0x1C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Helbig Informational [Page 5] Internet Draft StealthKey Management June 2002 4.1.3 Starting Time By H- and T-realization the LG is defined with a starting time t_0. At the time t_0 the content of the LG is the seed (refer to paragraph 4.1.2). In open networks we recommend as t_0 the value (00:00:00), January 1, 1970, Universal Coordinated Time (UTC). By N-realization the LG is defined without time. 4.1.4 Increment For all realizations the increment X is a randomly chosen, but fixed positive integer that is represented by the bit sequence x_{n-1}...x_1 x_0 of the length n, where x_0 = 1. For the use in open networks X is represented by the n/256 multiple concatenation of following hexadecimal value in big endian format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xA7 | 0xAA | 0xCC | 0xAA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xCA | 0xCC | 0x1C | 0x11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x1A | 0xCA | 0x71 | 0x7A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAA | 0x17 | 0xCC | 0xCC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAA | 0xC1 | 0xAA | 0xA1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xAC | 0x1A | 0xCC | 0x71 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xA1 | 0x77 | 0xCC | 0xCA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xCC | 0xA1 | 0xAA | 0x11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.5 States The LG contains in the state 0, for all realizations, the seed s0_{n-1}...s0_1 s0_0 of the length n. Assume, that i is a positive integer. The LG contains in the state i, for all realizations, the bit sequence si_{n-1}...si_1 si_0 of the length n. Let S[i] denote the positive integer what is represented by this bit sequence in a big endian format. S[i] is to be generated from S[i-1]as follows: S[i] = (S[i-1]+X) mod 2^n Helbig Informational [Page 6] Internet Draft StealthKey Management June 2002 4.1.6 Output For all realizations the output of the LG in the state i is the bit sequence si_{n-1}...si_1 si_0 of the length n. Consider the output fragmented in d = n/256 non-overlapping bit subsequences each of length 256. Let S(i,j) be the symbol for the subsequence j of the bit sequence si_{n-1}...si_1 si_0, then: si_{n-1}...si_1 si_0 = S(i,d-1)||...||S(i,1)||S(i,0) 4.2 AES-256 The AES-256 is in the Electronic Codebook Mode (ECB). Let K be, for all realizations, a randomly chosen long-term key of the length 256 bits (big endian) for the AES-256. 4.2.1 Input and Output In the state i of the LG every subsequence S(i,j) is an input of the AES-256 encryption algorithm, along with the key K. Let the bit sequence O(i,j) of length 256 be the output of the AES-256 encryption algorithm with the key K, when S(i,j) is the input. 4.3 Output of the PRBG The output of the PRBG in the state i is, for all realizations, the bit sequence of the length n, which is the concatenation of following outputs of the AES-256 algorithm with the key K: O(i,d-1)||...||O(i,1)||O(i,0) Consider the output of the PRBG as sequence of bits: oi_{n-1}...oi_1 Oi_0 The subsequence oi_{m-1}...oi_1 oi_0 of the output of the PRBG is, for all realizations, the short-term key of the length m in the state i. Let O(i) denote the short-term key in a big endian format. For the H-realization the subsequence oi_{m+31}...oi_{m+1} oi_m of the output of the PRBG is the SynH of the length 32 in the state i. 4.4 Cryptoperiod of the Short-term Keys For the cryptoperiod r exist technical (refer paragraph 5.2 and 6.2) and cryptographic restrictions (refer paragraph 9). For H- and T- realization the following values are proposed in consideration of these restrictions and the different communication speeds: Helbig Informational [Page 7] Internet Draft StealthKey Management June 2002 - r = 200s (<=1Gbps) - r = 50s (<=5Gbps) - r = 25s (<=10Gbps) - r = 12s (<=20Gbps) For the N-realization r = 2^17 (nearly 10^5) is recommended for open networks regardless of the communication speed. 5. Generation and Synchronization of Short-term Keys by H-realization 5.1 Generation After loading the long-term key by means described in paragraph 8, short-term keys are generated independently by sender and receiver. The sender uses only one short-term key in at a time. This is the short-term key that the PRBG has generated in the state that corresponds to the actual time of the sender and the cryptoperiod. A more detailed description follows: The generation of short-term keys starts at the beginning of the encrypted connection. For the sender, the beginning of an encrypted connection is defined as the state in which the long-term key for the connection is established by the sender. The sender defines an initial time. This is the largest time value ts_0 in seconds, with A = (ts_0-t_0)/r an integer and ts_0 smaller or equal to the actual time of the sender at the beginning of the encrypted connection. The generation of the short-term keys takes place every time the actual time of the sender is equal to ts_0 increased by a multiple of cryptoperiod r. The sender has in place at the time between ts_0+i*r and ts_0+(i+1)*r the short-term key O(A+i), where i is an integer i >= 0. The receiver generates three short-term keys based on the common long-term key and the receiver time. These short-term keys are valid in the prior, present and next cryptoperiod around the receiver time. Again, for details: The generation of short-term keys starts at the beginning of the encrypted connection. For the receiver the beginning of an encrypted connection is defined as the state in which the long-term key for the connection is established by the receiver. The receiver defines an initial time. This is the largest time value tr_0 in seconds, with B = (tr_0-t_0)/r an positive integer and tr_0 smaller or equal to the actual time of the receiver at the beginning of the encrypted Helbig Informational [Page 8] Internet Draft StealthKey Management June 2002 connection. The generation of short-term keys takes place every time the actual time of the receiver is equal to tr_0 increased by a multiple of cryptoperiod r. The receiver has in place at the time between tr_0+i*r and tr_0+(i+1)*r the three short-term keys O(B+i-1), O(B+i), and O(B+i+1), where i is an integer i >= 0. In addition to every short-term key, both parties generate the SynH of 32 bits (refer to paragraph 4.3). One SynH is valid over a cryptoperiod and represents the cryptoperiod. The sender adds the current SynH to the top of each plaintext and encrypts this new plaintext with the current short-term key. 5.2 Synchronization Synchronization for the H-realization depends on time synchronization between sender and receiver. The internal clock of the sender and receiver must be periodically synchronized to Universal Coordinated Time (UTC), which can be obtained from a variety of timing sources (e.g., from NTP or other time sources, including free-running precision oscillators.) Because the sender and receiver clocks will not be perfectly synchronized and the run time of data can be different for different ciphertexts, the receiver uses the SynH, located in the plaintext, to determine the correct short-term key to be used. The receiver makes this choice for each ciphertext. The receiver decrypts at least the first 32 bits of the ciphertext with each of the actual three short-term keys and uses that key giving the right SynH as the properly valid key to decrypt the rest of the ciphertext. Let t_s be the internal time of the sender when it encrypts and sends an arbitrary plaintext. Let t_r be the internal time of the receiver when it receives and decrypts the related ciphertext. Assume t_s = UTC+d_s and d_s is the difference of the internal time to UTC. Assume t_r = UTC+d_r and d_r is the difference of the internal time to UTC. Let d_t be the absolute time necessary for the transmission of the ciphertext. A premise for decryption is that |t_r-t_s| = |d_r-d_s-d_t| < 2*r We recommend to choose an r what suffices the condition that each of the expected values for d_s, d_r and d_t is smaller than 2/3*r. Helbig Informational [Page 9] Internet Draft StealthKey Management June 2002 6. Generation and Synchronization of Short-term Keys by T-realization 6.1 Generation The generation of the short-term keys by sender and receiver happens in the same manner as by the H-realization, described in paragraph 5.1, except that SynH is generated by any of the parties. Instead, the sender adds a timestamp (time of encryption) to the top of each ciphertext. 6.2 Synchronization This synchronization, like the synchronization in 5.2, depends on time synchronization between sender and receiver. The internal clock of the sender and receiver must be periodically synchronized to Universal Coordinated Time (UTC). Because the sender and receiver clocks will not be perfectly synchronized and the run time of data can be different for different ciphertexts, the receiver uses the timestamp of the ciphertext to determine the correct short-term key to be used. The receiver makes this choice for each ciphertext. Before the decryption of the ciphertext with one of the three possible short-term keys, the receiver compares the timestamp of the ciphertext with its internal three time intervals corresponding with three cryptoperiods. The receiver determines which period the timestamp fits in and uses the related short-term key to decrypt the ciphertext. To detect ciphertext an adversary sent, the timestamp and the ciphertext must be secured with a cryptographic hash-function. The short-term key for the cryptographic hash- function is generated like the short-term key for the encryption and enlarges the length of the PRBG. A more detailed description follows: Assume that the time of the receiver is between tr_0+i*r and tr_0+(i+1)*r-1, which means that the receiver has generated and has in place three short-term keys O(B+i-1), O(B+i), and O(B+i+1), where i is an integer i>=0 (refer to paragraph 5.1). When a ciphertext with the timestamp T is received, the receiver decides which of the following relations is true and selects the corresponding short- term key: t_0+(B+i-1)*r <= T < t_0+(B+i)*r t_0+(B+i)*r <= T < t_0+(B+i+1)*r t_0+(B+i+1)*r <= T < t_0+(B+i+2)*r For r we recommend the same restrictions like in paragraph 5.2. Helbig Informational [Page 10] Internet Draft StealthKey Management June 2002 7. Generation and Synchronization of Short-term Keys by N-realization 7.1 Generation The generation of the short-term keys by sender and receiver is different from the H- and T-realizations. For the sender and receiver an internal sequence number is defined as follows: The sender counts in an internal sequence number counter C, the ciphertexts for the receiver, and attaches the lower 32 bits of the counter as the external sequence number to the ciphertext. When used in open networks, C runs from 1 to 2^64. The receiver has an internal sequence number counter C for the sender defined as C = C1*2^32+C2, with 0 <= C1 and 0 < C2 < 2^32. The counter C starts with 1. When receiving a ciphertext with attached external sequence number S the receiver adjusts its internal sequence number using the following algorithm: C = C1*2^32+S, if C2+w > S > C2 C = (C1+1)*2^32+S, if C2 > S and C2+w >= 2^32+S C = C1*2^32+C2 else The positiv integer w is designated as acceptance window for the incoming external sequence. For open networks we recommend to use w = 64. After loading the long-term key by the means described in paragraph 8, short-term keys are generated independently by sender and receiver. The sender has only one short-term key in use at a time. This is the short-term key generated by the PRBG in the state that corresponds to the actual internal sequence number of the sender and the cryptoperiod. A more detailed description follows: The sender generates the short-term key O(i*r+1) for encryption of the plaintext with the internal sequence number C = i*r+1, where i is an integer i >= 0. This short-term key is then used for all plaintexts with the internal sequence number from C = i*r+1 to C=i*r+r. The receiver generates two short-term keys based on the common long-term key and its internal sequence number. These short-term keys are valid in the prior and present cryptoperiod around the internal sequence number. Helbig Informational [Page 11] Internet Draft StealthKey Management June 2002 Again, a more detailed description: After establishing the encrypted connection with the sender, the receiver immediately generates two short-term keys O(1) and O(r+1). Assume the receiver has stored the two short-term keys O(j*r+1) and O((j+1)*r+1), with j>=0 is an integer and it receives a ciphertext with the external sequence number S. The receiver first adjusts its internal sequence number like described above. Assume the internal sequence number after adjusting is C = i*r+q, with i and q integers and i >= 0 and 0 < q <=r. The algorithm for generating short-term keys is as follows: - If i = j then no new key will be generated. - If i = j+1 then the new short-term key O((j+2)*r+1) will be built and the oldest short-term key O(j*r+1)will be erased. For the receiver, the beginning of an encrypted connection is defined as the state in which the long-term key for the connection is established by the receiver. 7.2 Synchronization Synchronization for the N-realization does not depend on time. Instead, it depends on the external sequence number of each ciphertext, as described in paragraph 7.1. The receiver determines one short-term key for a ciphertext based on the external sequence number of the ciphertext and its internal sequence number. Before the ciphertext can be decrypted with one of the two possible short-term keys, the receiver derivates its current internal sequence number from the external sequence number of the ciphertext, as described above. If the external sequence number is outside of the acceptance window as defined in paragraph 7.1, the receiver discard the ciphertext. Otherwise, the receiver determines which of the two cryptoperiods the external sequence number corresponds to and uses the related short-term key for decryption of the ciphertext. To detect ciphertext an adversary sent, the external sequence number and the ciphertext must be secured with a cryptographic hash-function like described in paragraph 6.2. A more detailed description follows: Assume that the ciphertext with the external sequence number S arrives and the corresponding internal sequence number is C, with C = C1*2^32+C2 and C = i*r+q, where C1, C2, i and q are integers with i >=0 and 0 < q <= r. The receiver decides which of the Helbig Informational [Page 12] Internet Draft StealthKey Management June 2002 following two relations is true and selects the corresponding short-term key: - i*r+1 <= S+C1*2^32 < (i+1)*r - (i+1)*r+1 <= S+C1*2^32 < (i+2)*r 8. Long-term Keys All of the values S[0], X, t_0, K, and the cryptoperiod can be considered as long-term keys. It is recommended, that only K is used as the long-term key to differentiate between pairs of parties (sender and receiver). In other words, K is the variable and the other values are fixed known parameters for all pairs of parties. This document contains specifications for the parameters S[0], X, t_0, and the cryptoperiod for the use in open networks. In closed networks the values S[0], X, t_0,and the cryptoperiod can be considered as long-term keys. The long-term key K of StealthKey Management can be established through off-line manual key management or transported encrypted over a communication channel, as well as being the result of a key agreement. For many applications the off-line manual key management is the most practical approach and can be imbedded when the components are added to the network. However, if there is a need for distribution or agreement of long- term keys over the network, then standard protocols can be used. The protocol has to perform transaction authentication (refer [MENZ]). This ensures that the origin of the data is authentic, data integrity is proven and the established long-term keys are fresh. The lifetime of the long-term key is restricted by the condition that no more short-term keys than 2^m are built, whereby m is the length of the short-term key. For the N-realization, the process of building the short-term keys must not be repeated from the seed of the LG without changing the long-term key. 9. Security Considerations The security of short-term key generation from a long-term key K with StealthKey Management relies on: - the security of the AES - the fact that K is only used for this generation - the fact that the LG has the maximum period. The AES has no known weakness; AES is especially resistant to known- plaintext attacks and AES has good statistical properties of ciphertexts even with plaintext patterns. As a result, it is not possible to make a prediction about a long-term key or about short- term keys, as derived from one or various long-term keys. Helbig Informational [Page 13] Internet Draft StealthKey Management June 2002 The generation of short-term keys from a long-term key assumes that the long-term key is secret. If the long-term key is disclosed, all short-term keys generated from this long-term key and all encrypted messages using these short-term keys are compromised. Therefore, the generation of short-term keys from a long-term key has by definition no perfect forward secrecy. A protocol is said to have perfect forward secrecy [MENZ] if compromise of a long-term key does not compromise past short-term keys. The protection of stored secrets is an important issue of the system security and not part of the StealthKey Management. The lifetime of the long-term key can be restricted to short values. The cryptoperiod r of the short-term keys is dependant on the encryption algorithm using the short-term keys and in the case of using sequence numbers also from the size of the number space. Usual sequence numbers are for replay detection and so the cryptoperiod must be smaller than the size of the number space; e.g., by ESP 2^32. For 3DES in CBC mode, the numbers for the cryptoperiod in paragraph 4.4 are calculated to avoid collisions, operating with packet length equal or greater than 64 bytes. For 3DES and AES in CTR mode these numbers are sufficient to avoid a reset of the counter. For AES in CBC mode, these numbers are sufficient to avoid collisions. The StealthKey Management by H- and T-realizations depends on time synchronization, thus attacks must be considered to the internal clock of the sender and receiver and to the synchronization against an external time. Objectives of attacks may involve the desynchronization of the sender and receiver or the prevention of the use of a new short-term key. A StealthKey Management implementation should recognize time attacks by proving the differences between the internal and external time providing an error notification, if: - the difference is bigger than a special value - the external time has not been changed over a period of elapsed time - over a longer period the accumulated differences are bigger than a special value. Alternative measures to protect the time synchronization are: - use of NTP-server, which deliver authenticated ntp-response - voting algorithms for external NTP time inputs as measured against a well characterized internal clock - dedicational GPS receiver Helbig Informational [Page 14] Internet Draft StealthKey Management June 2002 - high quality precision quartz or atomic clocks on board - physical protection. The N-realization of the StealthKey Management is vulnerable against attacks, which attempt to slowly de-synchronize the sender and receiver. This may be accomplished by spoofing the receiver with external sequence numbers that are on the border of the acceptance window of the length w. A measure to detect this attack is described above. The proof of the cryptographic hash-value including the external sequence number allowing the receiver to reject such ciphertexts before a new internal sequence number is derived. Another attack with the objective of de-synchronization is to repress all ciphertext generated with the same short-term key. Intellectual Property Statement The StealthKey Management is patent-pending. However, the StealthKey Management is freely available for academic (non-profit) use and for software implementations. For commercial hardware implementations, the inventor will license StealthKey Management under non-exclusive license, on a non-discriminatory basis, based on reasonable terms and conditions. Please contact Zyfer Inc. at hxf@zyfer.com. References [MENZ] Menezes, A., van Oorschot, P.C., Vanstone, S.A., "Handbook of Applied Cryptography", 1997. [RFC 2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [FIPS 197] Federal Information Processing Standards Publication 197, "Specification for the Advanced Encryption Standard (AES)", November 2001. Authors' Adresses Derek Au Zyfer Inc. 1585 South Manchester Avenue Anaheim, CA 92802 Phone: +1 714-780-7637 Fax: +1 714-780-7649 EMail: dca2@zyfer.com Helbig Informational [Page 15] Internet Draft StealthKey Management May 2002 Peter Balke Zyfer Inc. 1585 South Manchester Avenue Anaheim, CA 92802 Phone: +1 714-780-7643 Fax: +1 714-780-7649 EMail: phb@zyfer.com Hugo Fruehauf Zyfer Inc. 1585 South Manchester Avenue Anaheim, CA 92802 Phone: +1 714-780-7960 Fax: +1 714-780-7649 EMail: hxf@zyfer.com Christina Helbig Zyfer Inc. 1585 South Manchester Avenue Anaheim, CA 92802 Phone: +1 714-780-7618 Fax: +1 714-780-7649 EMail: cbh@zyfer.com Klaus Helbig Zyfer Inc. 1585 South Manchester Avenue Anaheim, CA 92802 Phone: +1 714-780-7134 Fax: +1 714-780-7649 EMail: kfh@zyfer.com Please send comments to Christina Helbig (cbh@zyfer.com). Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Helbig Informational [Page 16] Internet Draft StealthKey Management June 2002 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expiration This document expires December 2002. Helbig Informational [Page 17]