To: IEEE P1619.1 Workgroup
From: Matt Ball, Quantum
Shai Halevi, IBM
Larry Hofer, McDATA
Charles Martin, Sun Microsystems
Subject: Proposed changes to Clause 6 (and related sections)
Date: 11/29/06
Summary:
This proposal provides suggested changes to Clause 6 and other related sections to clarify
the existing text.
Proposed Changes to P1619.1/D12a
3.2 Definitions
3.2.x encryption session: An interval in which a cryptographic unit generates unique
initialization vectors for encryption operations.
NOTE – See 6.2.
3.2.y brute-force security level: The log2 of an estimation of the number of operations
required to deduce a cipher key or otherwise compromise a cryptographic system.
3.2.z collision security level: The log2 of the probability that two independent encrypted
records used the same key stream.
3.3.a IV value: A bit string used as an initialization vector for a particular encryption
operation. See also: initialization vector.
6. Security level
[Editor’s Note: correct the following numbering in P1619.1:]
6.0 Overview
This clause defines two metrics for quantifying the security level of an implementation
that complies with this standard. The first metric is the brute-force security level that
quantifies the expected number of operations that an attacker must use to perform an
exhaustive search on the cipher key. The second metric is the collision security level,
which relates to the unique risks with streaming ciphers, where reusing the same key
stream more than once enables the attacker to detect plaintext patterns from the encrypted
data. In the context of this standard, this happens when an IV is reused with the same
cipher key, and the risk associated with such events is quantified in the collision security
level.
6.1 Brute-force security level
The brute-force security level is the log2 of an estimate of the number of operations
required by an attacker to compromise the key, measured in bits. For example, a 256-bit
brute-force security level means that the attacker needs to perform roughly 2256
operations to compromise the key. A 256-bit key that is derived entirely from a
cryptographically sound random bit generator has 256-bits of brute-force security.
NOTE – On average, a brute-force attack will succeed in half of the maximum number of
operations. For a 256-bit key, an attack will on average succeed after 2255 operations.
If the key-manager resides within the assurance boundary, documentation shall specify
the brute-force security level of these keys. Implementations should specify a brute-force
security level of at least 128 bits.
6.2 Collision security level
6.2.1 Definition of collision security level
In the context of this standard, an IV collision occurs when the same cipher key and IV
encrypt two or more blocks of data. This event leaks information about the plaintext data.
See C.3 for a discussion of the consequences of an IV collision.
The collision security level of an implementation is an upper bound on the log2 of the
probability of an IV collision per unit of data and is expressed in bits. For example, a
collision security level of 64 bits per record means that any two records have at most a 1
in 264 chance of causing an IV collision (and thus leaking plaintext information).
Note – The collision security level as defined in this subclause is the level of security that
the cryptographic unit provides under a worst-case usage scenario; at least this level of
protection is provided regardless of how the cryptographic unit is used.
6.2.2 Avoiding IV collisions
The cryptographic unit shall take steps to reduce the probability of IV collisions, as
specified below. These steps may be in conjunction with the key manager, if the latter
resides within the assurance boundary.
The cryptographic unit shall encrypt records in encryption sessions, where each
encryption session is used to encrypt one or more records. The cryptographic unit shall
maintain a consistent state within each encryption session to ensure that no IV collisions
occur between records that are encrypted in the same encryption session. An encryption
session shall start when the key manager loads a new key into the cryptographic unit. An
encryption session shall end either when the cryptographic unit loses the encryption
session state, including the cipher key and IV, or when a new encryption session begins.
For example, the cryptographic unit may maintain a counter that is incremented with each
new record, and set the IV value to the current contents of the counter to ensure that no
IV collisions occur between records in the same encryption session.
In addition, the cryptographic unit shall use at least one of the following two methods to
minimize the probability of IV collisions between records that are encrypted in different
encryption sessions:
a) Use different cipher keys for different encryption sessions (see 6.2.3).
b) Either begin an encryption session with a random IV or continue from the last IV
of the previous encryption session. (see 6.2.4).
The cryptographic unit shall force the beginning of a new encryption session whenever
the state that is associated with the encryption session (i.e. the values of the IV and cipher
key) is not available for any reason. For example, a new encryption session begins if the
state was lost due to a power failure.
Documentation shall specify the collision-avoidance method used, and shall include an
estimate of the resulting collision security level, as follows:
The collision security level shall be computed as the sum of the key-collisionsecurity level as specified in 6.2.3 and the IV collision security level as specified
in 6.2.4. See examples in C.5.
6.2.3 Using different cipher keys for different encryption sessions
When using a new cipher key for each encryption session, the cryptographic unit shall
use one of the following two methods:
a) A new cipher key is generated for every new encryption session. The value of the
new cipher key is set to the output of an RBG. This method shall only be used
either when the cryptographic unit generates its own cipher keys, or when the
cipher key is generated by a key manager that resides within the assurance
boundary.
When using this method, the collision security level of the cipher key equals 256
bits (i.e. the number of random bits in the cipher key).
b) In each new encryption session, the cryptographic unit applies the key-transform
procedure from D.2 to the user key, and the output is taken as the cipher key for
that encryption session.
In this case, the collision security level of the cipher key equals the number of
random bits within the random nonce input of the key transform function, but not
more than 256 bits (i.e. the output size of the key transform function). For the
purpose of computing key collision security, information received from any
component outside the assurance boundary is considered as having zero random
bits.
If neither a) nor b) are used, then documentation shall indicate that the collision security
level of the cipher key equals zero bits.
6.2.4 Randomizing the IV values
If the cryptographic unit does not enforce a different cipher key per encryption session as
described in 6.2.3, then the cryptographic unit shall randomize the IV values. In this
case, the value of any IV shall depend on state information that was taken from the output
of an RBG.
Example:
a) The cryptographic unit takes a 96-bit random string from the output of the RBG,
uses it as the first IV in the encryption session, and obtains subsequent IV values
by incrementing the previous value modulo 296.
b) The cryptographic unit obtains a 64-bit value as the output of an RBG, sets the
most significant 64 bits of all the IVs in the encryption session to this one value,
and set the least-significant 32 bits of every IV to a counter value that is
initialized with zero and incremented with every record, making sure that no more
than 232 records are encrypted in each encryption session.
The IV collision security level is determined by the most likely value that any IV can
assume. Specifically, the IV collision security level equals n bits if no IV can assume any
single value with probability more than 1 in 2n, where the probability is measured over all
the possible RBG outputs that were used in the computation of the IV value. The first
example from above has 96 bits of collision security level and the second example has 64
bits of collision security.
When the IVs are not randomized, the IV collision security level equals zero bits. If the
IV collision level is more than zero bits, then it shall be at least 64 bits.
Annex C
(Informative)
Security Concerns
C.3 Initialization vector collision avoidance
Both CCM and GCM are based on counter-mode encryption (i.e. a block cipher turned
into a stream cipher), thus re-use of the same IV under the same key poses the same risk
as re-use of the key stream in a stream cipher. When an IV collision occurs, the XOR of
the two ciphertext records equals to the XOR of the two plaintext records, allowing an
attacker to learn information about the plaintext records by observing the ciphertext.
Under some circumstances an IV collision in GCM may reveal information about the
authentication key to an attacker, thus allowing the attacker to forge authentication tags
(see [B2]). It is therefore important that steps be taken to proactively avoid IV collisions.
When considering the probability of IV collisions, it is possible that the same user key is
loaded into cryptographic units from different manufacturers, and that these
cryptographic units may use very different strategies for IV collision avoidance.
Therefore, it is required that each cryptographic unit guarantees some level of IV
collision security, regardless of the behavior of any other cryptographic units that may be
given the same user key.
C.5 Examples of IV collision avoidance strategies
C.5.1 Example summary
The following examples illustrate four different strategies for IV collision avoidance and
explain how to compute the collision security level in each case. All the following
examples use cryptographic units (e.g. tape drives) that identify encryption sessions with
write pass counters.
C.5.2 Example 1: Randomizing only the IV
In this example the tape drive receives a user key from the key manager and loads this
user key into the cryptographic unit at the beginning of the write-pass. The cryptographic
unit uses the user key directly as the cipher key.
The cryptographic unit then extracts 96 bits from its RBG and stores these bits in a state
register. With each record that is encrypted, the cryptographic unit uses the current
contents of the state register as the IV value and then increments the state register by one
modulo 296.
In this case, the IV collision security is 96 bits, and because the drive does not implement
any of the methods from 6.2.3, the collision security level is zero bits. Hence, the
collision security level in this example is 96 bits. It is easy to check that two records in
the same write-pass never use the same IV value, and two records from two different
write-passes have at most 1 in 296 chance of IV collision.)
C.5.3 Example 2: Randomizing only the key
In this example, the cryptographic unit chooses a fresh 256-bit cipher key for every write
pass, and uses the integer I as the IV value for the I’th record in a write-pass. Hence, the
key collision security level is 256 bits and the IV collision security level is zero bits, for a
total security level of 256 bits.
C.5.4 Example 3: Transforming the key and randomizing the IV
The cryptographic unit obtains a user key from the key manager, and for each encryption
session it uses the key transform procedure from D.2 with a 128-bit random nonce (taken
from its RBG). In addition, at the beginning of every encryption session the drive extracts
a 64-bit value R from its RBG and sets the IV value for the I’th record in a write-pass as
(R || I). If more than 232 records need to be encrypted in the same write-pass, the drive
forces a new encryption session.
Here, the key collision security level is 128 bits and the IV collision security level is 64
bits, for a total security level of 192 bits.
C.5.5 Example 4: Transforming the key with unique identifiers
Consider a cryptographic unit without an RBG, but that can provide unique identifiers
with each write pass. The cryptographic unit then uses in each encryption session the key
transform procedure from D.2 with unique identifiers in lieu of a random nonce, and uses
the integer I as the IV value for the I’th record in a write-pass.
In this example, the key-collision-security level is zero bits (since there is no randomness
in the key transform) and the IV-security level is also zero bits (since the IVs are not
randomized). Hence the total collision security level in this example is zero bits.
Note that this does not mean that the security of this solution is necessarily inadequate.
What it does reflect, however, is that the security relies on the cryptographic unit to
ensure that “unique identifiers” are indeed unique, and that a badly configured
cryptographic unit can cause IV collisions (and hence potential leakage of plaintext).
C.6 Interpreting the collision security level
IV collision security is related to the amount of plaintext that can be encrypted under the
same cipher key without leaking information. For a given level of IV collision security,
the more records that are encrypted under the same cipher key, the higher the probability
that an IV collision occurs, and thus the higher the probability of information leakage. In
the worst case, the probability of an IV collision increases quadratically with the number
of records that are encrypted under the same cipher key. Specifically, when encrypting c
records under the same cipher key with IV collision security level of n bits, the
probability of an IV collision is upper-bounded by Equation (1).
p  c2/2n+1
(1)
For example, when using an IV collision security level of 64 bits and encrypting 220
(about one million) records under the same cipher key, then an upper bound on the
probability of collision is given by Equation (2).
p  2(4065)) = 225
(2)
which is about 1 in 32 million.
Generally, the cryptographic unit and key manager should change the cipher key
frequently to reduce the chance of IV collisions. The acceptable tradeoff between the rate
of key change and the probability of IV collisions should be determined by the user's
security policy.
The expression from equation (1) is only an upper bound, and the actual collision
probability is sometimes much lower. Consider the example from C.6.1, where the
cryptographic unit is using the user key as a cipher key, chooses a random 96-bit IV for
every encryption session, and increments it with each record in that encryption session.
Assume further that the same user key is used in 220 encryption sessions, and that each
encryption session encrypts 220 different records.
In this case we have a 96-bit IV collision security level and 2^{40} records, so Equation
(1) yields a bound of 280/297 = 217, which is about 1 in 130,000. A more careful analysis,
however, reveals that the actual collision probability in this case is only 236 (which is
about 1 in 64 billion). To see that, notice that for any two encryption sessions, the
probability of an IV collision between any IVs in these two encryption sessions is
roughly 221/296=275 (since the initial nonces in these two encryption sessions must be
within 220 of each other for any collision to occur). As there are 220 encryption sessions,
the probability that any of two of them give rise to collisions is therefore at most
p  (220)2 / 275+1 = 236
Getting the lower collision probability relies on a specific use of the cryptographic unit
from the example in C.6.1, whereas the higher probability from equation (1) refers to the
guarantee that we get even under worst-case usage scenario. (In this case, the worst-case
usage scenario is when the same user key is used for very many encryption sessions, each
consisting of only a handful of records.)