CA2449524C - Cryptographic method and apparatus - Google Patents
Cryptographic method and apparatus Download PDFInfo
- Publication number
- CA2449524C CA2449524C CA2449524A CA2449524A CA2449524C CA 2449524 C CA2449524 C CA 2449524C CA 2449524 A CA2449524 A CA 2449524A CA 2449524 A CA2449524 A CA 2449524A CA 2449524 C CA2449524 C CA 2449524C
- Authority
- CA
- Canada
- Prior art keywords
- data
- security level
- authenticity
- confidentiality
- nonce
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 34
- 230000005540 biological transmission Effects 0.000 claims 1
- 230000009466 transformation Effects 0.000 description 19
- 230000010365 information processing Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- 101100377706 Escherichia phage T5 A2.2 gene Proteins 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002040 relaxant effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A cryptographic method and apparatus modifies the CCM block cipher mode of operation to provide enhanced applicability and utility.
Description
2 TECHNICAL FIELD
3 The present invention relates to cryptographic methods and apparatus.
4 BACKGROUND
CCM is a block-cipher mode of operation that can be used to protect the privacy and/or 6 authenticity of messages. The CCM mode is a particular mode of operation that operates on 7 block-ciphers with a 128-bit block size and involves a particular combination of the so-called 8 Counter (CTR) mode of operation and the Cipher-Block Chaining (CBC) mode of operation 9 [10], using a single key. The CCM mode of operation has acquired quite some practical relevance, due to the incorporation hereof as the mandatory block-cipher mode of operation in 11 quite a few wireless standards that recently emerged, including the IEEE
802.11 WLAN standard 12 [5] and the IEEE 802.15 High-Rate and Low-Rate WPAN standards [6], [7].
The CCM mode 13 allows for variable-length authentication tags (from 32-bits to 128-bits), thus allowing varying 14 degrees of protection against unauthorized modifications. The CCM mode allows quite efficient implementations, due to the fact that one only needs to implement the encryption transformation 16 of the underlying block-cipher (and not the decryption transformation) and due to its reliance on 17 a single key, rather than multiple keys, to provide confidentiality and authenticity services. This 18 being said, the CCM mode has also some disadvantages.
While the original CCM mode [4] provides for data authentication and, possibly, confidentiality, 21 it does not provide for confidentiality only. This is unfortunate, since not all implementation 22 environments call for data authenticity (e.g., if data authenticity is provided by an external 23 mechanism).
22291667.1 1 The original CCM mode [4] is known to be vulnerable to specific attacks, if used with variable-2 length authentication tags rather than with fixed-length authentication tags only (see, e.g., 3 Section 3.4 of [11]). Thus, the original CCM mode can only be securely used with the same key 4 in settings with fixed-length authentication tags. This is unfortunate, since support for variable-length authentication tags is useful in constrained implementation environments, such as secured 6 wireless sensor networks [7], where applications on a device might have different protection 7 requirements, but would have to share the same key, due to resource constraints.
8 According to the present invention there is provided a variant of the so-called CCM mode [4], 9 referred to as the CCM* mode aimed at broadening the applicability and usefulness hereof. The CCM* mode extends the definition of the original CCM mode, such as to provide for 11 confidentiality-only services, in addition to the other security service options already offered.
12 Moreover, the CCM* mode adapts the original CCM mode such that the resulting mode can be 13 used securely with variable-length authentication tags, rather than fixed-length authentication 14 tags only. Thus, the CCM* mode takes away the disadvantages of the CCM
mode pointed out above.
17 An embodiment of the invention will now be described by way of example only in which:
18 Figure 1 is schematic representation of an apparatus for assembling an encrypted data stream.
The CCM* mode extends the definition of the original CCM mode, such as to provide for 21 confidentiality-only services, in addition to the other security service options already offered.
22 Moreover, the CCM* mode adapts the original CCM mode such that the resulting mode can be 23 used securely with variable-length authentication tags, rather than fixed-length authentication 24 tags only.
At the same time, the specification of the CCM* mode is such that it is compatible with the 26 CCM mode, as specified in the Draft Amendment (as of July 2003) to the IEEE 802.11 WLAN
22291667.1 1 standard [5] and as specified in the IEEE 802.15.3 WPAN standard [6] and coincides with the 2 specification of the default mode in the IEEE 802.15.4 WPAN standard [7].
3 The specification of the CCM* mode of operation imposes a specific choice of the input 4 transformation as described at A2.1.1 below, a specific representation of integers as octet strings, and a specific formatting of the Flags field used for authentication (see A2.1.2) and encryption 6 (see A.2.1.3). Obviously, variations hereof are possible, without necessarily impacting the 7 security properties of the resulting mechanism (e.g., if the cryptographic assumptions discussed 8 in Section A3 below are adhered to). Obviously, other variations, such us relaxing restrictions on 9 the nonce (see A2.1), are possible as well, possibly with an impact on the security properties of the resulting scheme.
11 CCM* is a generic combined encryption and authentication block cipher mode. Although CCM*
12 is only defined below for use with block ciphers with a 128-bit block size, such as AES-128 [2].
13 The CCM* ideas may be extended to other block sizes, with definition.
14 The CCM* mode coincides with the original CCM mode specification [4] for messages that require authentication and, possibly, encryption, but does also offer support for messages that 16 require only encryption. As with the CCM mode, the CCM* mode requires only one key. The 17 security proof for the CCM mode [8], [9] carries over to the CCM* mode described here. The 18 design of the CCM* mode takes into account the results of [11], thus allowing it to be securely 19 used in implementation environments for which the use of variable-length authentication tags, rather than fixed-length authentication tags only, is beneficial.
21 Al Notation and representation 22 (a) A1.1 Strings and string operations 24 A string is a sequence of symbols over a specific set (e.g., the binary alphabet {0,1} or the set of all octets). The length of a string is the number of symbols it contains (over the same alphabet).
26 The right-concatenation of two strings x and y (over the same alphabet) of length m and n 27 respectively (notation: x y), is the string z of length m-Fn that coincides with x on its leftmost m 22291667.1 . .
, 1 symbols and with y on its rightmost n symbols. An octet is a symbol string of length 8. In our 2 context, all octets are strings over the binary alphabet.
3 (b) A1.2 Integers and their representation Throughout this specification, the representation of integers as octet strings and of octets as 6 binary strings shall be fixed. All integers shall be represented as octet strings in most-significant-7 octet first order. This representation conforms to the conventions in Section 4.3 of ANSI X9.63-8 2001 [1].
9 A2 Specification of CCM* mode of operation (in 'ANSI style') 11 Prerequisites: The following are the prerequisites for the operation of the generic CCM* mode:
12 1. A block-cipher encryption function E shall have been chosen, with a 128-bit block size. The 13 length in bits of the keys used by the chosen encryption function is denoted by keylen.
14 2. A fixed representation of octets as binary strings shall have been chosen (e.g., most-significant-bit first order or least-significant-bit-first order).
16 3. The length L of the message length field, in octets, shall have been chosen. Valid values for L
17 are the integers 2, 3, ..., 8 (the value L=1 is reserved).
18 4. The length M of the authentication field, in octets, shall have been chosen. Valid values for 19 Mare the integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value M=0 corresponds to disabling authenticity, since then the authentication field is the empty string.) 22 A2.1 CCM* mode encryption and authentication transformation 24 Input: As shown schematically in figure 1, The CCM* mode forward transformation takes as inputs:
22291667.1 1 1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence 2 that access to this key is restricted to the entity itself and its intended key sharing group 3 member(s).
4 2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall
CCM is a block-cipher mode of operation that can be used to protect the privacy and/or 6 authenticity of messages. The CCM mode is a particular mode of operation that operates on 7 block-ciphers with a 128-bit block size and involves a particular combination of the so-called 8 Counter (CTR) mode of operation and the Cipher-Block Chaining (CBC) mode of operation 9 [10], using a single key. The CCM mode of operation has acquired quite some practical relevance, due to the incorporation hereof as the mandatory block-cipher mode of operation in 11 quite a few wireless standards that recently emerged, including the IEEE
802.11 WLAN standard 12 [5] and the IEEE 802.15 High-Rate and Low-Rate WPAN standards [6], [7].
The CCM mode 13 allows for variable-length authentication tags (from 32-bits to 128-bits), thus allowing varying 14 degrees of protection against unauthorized modifications. The CCM mode allows quite efficient implementations, due to the fact that one only needs to implement the encryption transformation 16 of the underlying block-cipher (and not the decryption transformation) and due to its reliance on 17 a single key, rather than multiple keys, to provide confidentiality and authenticity services. This 18 being said, the CCM mode has also some disadvantages.
While the original CCM mode [4] provides for data authentication and, possibly, confidentiality, 21 it does not provide for confidentiality only. This is unfortunate, since not all implementation 22 environments call for data authenticity (e.g., if data authenticity is provided by an external 23 mechanism).
22291667.1 1 The original CCM mode [4] is known to be vulnerable to specific attacks, if used with variable-2 length authentication tags rather than with fixed-length authentication tags only (see, e.g., 3 Section 3.4 of [11]). Thus, the original CCM mode can only be securely used with the same key 4 in settings with fixed-length authentication tags. This is unfortunate, since support for variable-length authentication tags is useful in constrained implementation environments, such as secured 6 wireless sensor networks [7], where applications on a device might have different protection 7 requirements, but would have to share the same key, due to resource constraints.
8 According to the present invention there is provided a variant of the so-called CCM mode [4], 9 referred to as the CCM* mode aimed at broadening the applicability and usefulness hereof. The CCM* mode extends the definition of the original CCM mode, such as to provide for 11 confidentiality-only services, in addition to the other security service options already offered.
12 Moreover, the CCM* mode adapts the original CCM mode such that the resulting mode can be 13 used securely with variable-length authentication tags, rather than fixed-length authentication 14 tags only. Thus, the CCM* mode takes away the disadvantages of the CCM
mode pointed out above.
17 An embodiment of the invention will now be described by way of example only in which:
18 Figure 1 is schematic representation of an apparatus for assembling an encrypted data stream.
The CCM* mode extends the definition of the original CCM mode, such as to provide for 21 confidentiality-only services, in addition to the other security service options already offered.
22 Moreover, the CCM* mode adapts the original CCM mode such that the resulting mode can be 23 used securely with variable-length authentication tags, rather than fixed-length authentication 24 tags only.
At the same time, the specification of the CCM* mode is such that it is compatible with the 26 CCM mode, as specified in the Draft Amendment (as of July 2003) to the IEEE 802.11 WLAN
22291667.1 1 standard [5] and as specified in the IEEE 802.15.3 WPAN standard [6] and coincides with the 2 specification of the default mode in the IEEE 802.15.4 WPAN standard [7].
3 The specification of the CCM* mode of operation imposes a specific choice of the input 4 transformation as described at A2.1.1 below, a specific representation of integers as octet strings, and a specific formatting of the Flags field used for authentication (see A2.1.2) and encryption 6 (see A.2.1.3). Obviously, variations hereof are possible, without necessarily impacting the 7 security properties of the resulting mechanism (e.g., if the cryptographic assumptions discussed 8 in Section A3 below are adhered to). Obviously, other variations, such us relaxing restrictions on 9 the nonce (see A2.1), are possible as well, possibly with an impact on the security properties of the resulting scheme.
11 CCM* is a generic combined encryption and authentication block cipher mode. Although CCM*
12 is only defined below for use with block ciphers with a 128-bit block size, such as AES-128 [2].
13 The CCM* ideas may be extended to other block sizes, with definition.
14 The CCM* mode coincides with the original CCM mode specification [4] for messages that require authentication and, possibly, encryption, but does also offer support for messages that 16 require only encryption. As with the CCM mode, the CCM* mode requires only one key. The 17 security proof for the CCM mode [8], [9] carries over to the CCM* mode described here. The 18 design of the CCM* mode takes into account the results of [11], thus allowing it to be securely 19 used in implementation environments for which the use of variable-length authentication tags, rather than fixed-length authentication tags only, is beneficial.
21 Al Notation and representation 22 (a) A1.1 Strings and string operations 24 A string is a sequence of symbols over a specific set (e.g., the binary alphabet {0,1} or the set of all octets). The length of a string is the number of symbols it contains (over the same alphabet).
26 The right-concatenation of two strings x and y (over the same alphabet) of length m and n 27 respectively (notation: x y), is the string z of length m-Fn that coincides with x on its leftmost m 22291667.1 . .
, 1 symbols and with y on its rightmost n symbols. An octet is a symbol string of length 8. In our 2 context, all octets are strings over the binary alphabet.
3 (b) A1.2 Integers and their representation Throughout this specification, the representation of integers as octet strings and of octets as 6 binary strings shall be fixed. All integers shall be represented as octet strings in most-significant-7 octet first order. This representation conforms to the conventions in Section 4.3 of ANSI X9.63-8 2001 [1].
9 A2 Specification of CCM* mode of operation (in 'ANSI style') 11 Prerequisites: The following are the prerequisites for the operation of the generic CCM* mode:
12 1. A block-cipher encryption function E shall have been chosen, with a 128-bit block size. The 13 length in bits of the keys used by the chosen encryption function is denoted by keylen.
14 2. A fixed representation of octets as binary strings shall have been chosen (e.g., most-significant-bit first order or least-significant-bit-first order).
16 3. The length L of the message length field, in octets, shall have been chosen. Valid values for L
17 are the integers 2, 3, ..., 8 (the value L=1 is reserved).
18 4. The length M of the authentication field, in octets, shall have been chosen. Valid values for 19 Mare the integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value M=0 corresponds to disabling authenticity, since then the authentication field is the empty string.) 22 A2.1 CCM* mode encryption and authentication transformation 24 Input: As shown schematically in figure 1, The CCM* mode forward transformation takes as inputs:
22291667.1 1 1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence 2 that access to this key is restricted to the entity itself and its intended key sharing group 3 member(s).
4 2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall
5 be unique. In the embodiment of figure 1, the nonce is derived from the source address of
6 the sending party, the frame counter and the protection level field. The frame counter is used
7 only once and the protection level setting may be a fixed security setting as determined on a
8 packet by packet basis.
9 3. An octet string m of length 1(m) octets, where 0 1(m) <28L
4. An octet string a of length 1(a) octets, where 0 1(a) <2. In the embodiment of figure 1, 11 this is header information.
13 The nonce N shall encode the potential values for M such that one can uniquely determine from 14 N the actually used value of M. The exact format of the nonce N shall be determined and fixed by the actual implementation environment of the CCM* mode in accordance with normal 16 considerations.
17 The exact format of the nonce N is left to the application, to allow simplified hardware and 18 software implementations in particular settings. Actual implementations of the CCM* mode may 19 restrict the values of M that are allowed throughout the life-cycle of the encryption key Key to a strict subset of those allowed in the generic CCM* mode. If so, the format of the nonce N shall 21 be such that one can uniquely determine from N the actually used value of M in that particular 22 subset. In particular, if M is fixed and the value M=0 is not allowed, then there are no restrictions 23 on N, in which case the CCM* mode reduces to the CCM mode.
24 The restriction on N limits the freedom in specifying the nonce, which might be undesirable. An alternative would be to incorporate the value of M in the L-octet wide length field in a reversible 26 way, which effectively reduces this to an L-1 octet field for length encoding purposes. The 27 essential cryptographic requirement is as follows: The first authentication block Bo (see A2.1.2, 28 step 2) and the encryption blocks Ai (see step A2.1.3, step 2) shall encode the potential values of 29 M such that this parameter can be uniquely recovered. This allows other options for encoding 22291667.1 1 than the ones presented in this specification. (As an example, in applications such as the IEEE
2 802.15.4 Low-Rate WPAN standard [7], the length of a message to be encrypted is at most 127 3 bytes, so 1(m) could be represented using only 7 bits rather than the 2 octets currently reserved 4 for this. Also, the number of applications of the 128-bit block cipher would be at most 8, so the number of different counter values Ai (see step A2.1.3, step 2) per frame can be represented 6 using only 3 bits, rather than the 2 octets currently reserved for this.) 7 (i) A2.1.1 Input transformation 8 This step involves the transformation of the input strings a and m to the strings AuthData and 9 Plain TextData, to be used by the authentication transformation and the encryption transformation, respectively.
11 This step involves the following steps, in order:
12 1. Form the octet string representation L(a) of the length 1(a) of the octet string a, as follows:
13 a. If 1(a)=0, then L(a) is the empty string.
14 b. If 0 < 1(a) <21628, then L(a) is the 2-octets encoding of 1(a).
c. If 216-28 < 1(a) <232, then L(a) is the right-concatenation of the octet Oxff, the octet Oxfe, 16 and the 4-octets encoding of 1(a).
17 d. If 232 1(a) <264, then L(a) is the right-concatenation of the octet Oxff, the octet Oxff, and 18 the 8-octets encoding of 1(a).
2. Right-concatenate the octet string L(a) with the octet string a itself.
Note that the resulting 21 string contains 1(a) and a encoded in a reversible manner.
23 3. Form the padded message AddAuthData by right-concatenating the resulting string with the 24 smallest non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by 16.
26 4. Form the padded message PlaintextData by right-concatenating the octet string m with the 27 smallest non-negative number of all-zero octets such that the octet string PlaintextData has 28 length divisible by 16.
22291667.1 1 5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
2 AuthData = AddAuthData II Plaint extData.
3 (ii) A2.1.2 Authentication transformation 4 The data AuthData that was established above shall be tagged using the tagging transformation as follows:
6 1. Form the 1-octet Flags field consisting of the 1-bit Reserved field, the 1-bit Adata field, and 7 the 3-bit representations of the integers M and L, as follows:
8 Flags Reserved Adata M II L.
9 Here, the 1-bit Reserved field is reserved for future expansions and shall be set to '0'. The 1-bit Adata field is set to '0' if 1(a)=0, and set to '1' if 1(a)>0. The M field is the 3-bit 11 representation of the integer (M-2)/2 if M>0 and of the integer 0 if M=0, in most-significant-12 bit-first order. The L field is the 3-bit representation of the integer L-1, in most-significant-13 bit-first order.
14 2. Form the 16-octet Bo field consisting of the 1-octet Flags field defined above, the 15-L octet nonce field N, and the L-octet representation of the length field 1(m), as follows:
16 Bo Flags II Nonce N 1(m).
17 3. Parse the message AuthData as B1 II B2 II ... Pt, where each message block B, is a 16-octet 18 string.
19 4. The CBC-MAC value X+1 is defined by Xo := 0128; Xi+1 E(Key, X, 0 .131) for i=0, , t.
21 Here, E(K, x) is the cipher-text that results from encryption of the plaintext x, using the 22 established block-cipher encryption function E with key Key; the string 0)28 is the 16-octet 23 all-zero bit string.
22291667.1 =
1 5. The authentication tag T is the result of omitting all but the leftmost M octets of the CBC-2 MAC value Xt+1 thus computed.
3 (iii) A2.1.3 Encryption transformation 4 The data PlaintextData that was established in clause A2.1.1 (step 4) and the authentication tag T
that was established in clause A2.1.2 (step 5) shall be encrypted using the encryption 6 transformation as follows:
7 1. Form the 1-octet Flags field consisting of two 1-bit Reserved fields, and the 3-bit 8 representations of the integers 0 and L, as follows:
9 Flags = Reserved II Reserved II 0 II L.
Here, the two 1-bit Reserved fields are reserved for future expansions and shall be set to '0'.
11 The '0' field is the 3-bit representation of the integer 0, in most-significant-bit-first order.
12 The L field is the 3-bit representation of the integer L-1, in most-significant-bit-first order.
13 2. Define the 16-octet A, field consisting of the 1-octet Flags field defined above, the 15-L octet 14 nonce field N, and the L-octet representation of the integer i, as follows:
A, = Flags II Nonce N II Counter i, for 1=0, 1,2, ...
16 Note that this definition ensures that all the A1 fields are distinct from the Bo fields that are 17 actually used, as those have a Flags field with a non-zero encoding of M
in the positions 18 where all Ai fields have an all-zero encoding of the integer 0 (see clause A2.1.2, step 2).
19 3. Parse the message PlaintextData as M111 ... 11Mt, where each message block M, is a 16-octet string.
21 4. The ciphertext blocks C1, , Ct are defined by 22 C, := E( Key, i4,) M, for i=1, 2, ... , t.
23 5. The string Ciphertext is the result of omitting all but the leftmost 1(m) octets of the string CI 11 24 ... C1.
22291667.1 1 6. Define the 16-octet encryption block So by 2 So:= E( Key, Ao ).
3 7. The encrypted authentication tag U is the result of XOR-ing the string consisting of the 4 leftmost M octets of So and the authentication tag T.
Output: If any of the above operations has failed, then output 'invalid'.
Otherwise, output the 6 right-concatenation of the encrypted message Ciphertext and the encrypted authentication tag U.
7 A2.2 CCM* mode decryption and authentication checking transformation 8 Input: The CCM* inverse transformation takes as inputs:
9 1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to this key is restricted to the entity itself and its intended key-sharing group 11 member(s).
12 2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall 13 be unique.
14 3. An octet string c of length 1(c) octets, where 0 l(c)-M< 281,.
4. An octet string a of length 1(a) octets, where 0 1(a) < 264 .
16 (iv) A2.2.1 Decryption transformation 17 The decryption transformation involves the following steps, in order:
18 1. Parse the message c as C II U, where the right-most string U is an M-octet string. If this 19 operation fails, output 'invalid' and stop. U is the purported encrypted authentication tag.
Note that the leftmost string C has length /(c)-M octets.
21 2. Form the padded message CiphertextData by right-concatenating the string C with the 22 smallest non-negative number of all-zero octets such that the octet string CiphertextData has 23 length divisible by 16.
22291667.1 =
2 and the tag U.
4 most string T is an M-octet string. T is the purported authentication tag. Note that the leftmost 5 string m has length 1(c)-M octets.
6 (v) A2.2.2 Authentication checking transformation 9 the string a and the octet string m that was established in clause A2.2.1 (step 4).
12 established in clause A2.2.1 (step 4). If MACTag=T, output 'valid':
otherwise, output 13 'invalid' and stop.
22 operations.
22291667.1 6 = The CCM* mode allows the length of the authentication field M to be zero as well (the value 7 M=0 corresponding to disabling authenticity, since then the authentication field is the empty 8 string).
values for M such that one can uniquely determine from N the actually used value of M.
23 one can uniquely determine the input strings a and m (as well as the nonce N). In fact, for any 24 two input strings corresponding to distinct triples (N, m, a), neither one is a prefix string of 25 the other.
22291667.1 1 = All the Ai fields are distinct from the Bo fields that are actually used (over the lifetime of the 2 key), as those have a Flags field with a non-zero encoding of M in the positions where all A;
3 fields have an all-zero encoding of the integer 0.
4 Hence, if M is fixed, then the CCM* mode offers the same security properties as the original CCM mode: confidentiality over the input string m and data authenticity over the input strings a 6 and m, relative to the length of the authentication tag. Obviously, if M=0, then no data 7 authenticity is provided by the CCM* mode itself (but may be provided by an external 8 mechanism).
9 For variable-length authentication tags, the original CCM mode is known to be vulnerable to specific attacks (see, e.g., Section 3.4 of [11]). These attacks may arise with the original CCM
11 mode, since the decryption transformation does not depend on the length of the authentication 12 tag itself. The CCM* mode avoids these attacks altogether, by requiring that one shall be able to 13 uniquely determine the length of the applicable authentication tag from the Ai fields (i.e., from 14 the counters blocks).
A4 Interoperability between CCM mode and CCM* mode of operation 16 The CCM* mode reduces to the CCM mode in all implementation environments where the 17 length of the authentication tag is fixed and where the value M=0 (encryption-only) is not 18 allowed. In particular, the CCM* mode is compatible with the CCM mode, as specified in the 19 Draft Amendment (as of July 2003) to the IEEE 802.11 WLAN standard [5]
and as specified in the IEEE 802.15.3 WPAN standard [6]. The IEEE 802.15.4 WPAN standard [7]
currently 21 incorporates the CCM mode with variable-length authentication tags; the upcoming security 22 amendment is anticipated to involve replacement of the CCM mode by the CCM* mode of 23 operation, to securely support variable-length authentication tags in its target application area ¨
24 low-cost sensor networks.
References referred to in the above text are as follows.
26 [1] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key 27 Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers 28 Association, November 20, 2001. Available from http://www.ansi.org.
22291667.1 1 [2] FIPS Pub 113, Computer Data Authentication, Federal Information Processing Standards 2 Publication 113, US Department of Commerce/N.I.S.T., May 30, 1985.
Available from 3 http://csrc.nist.gov/."
4 [3] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, US Department of Commerce/N.I.S.T, Springfield, Virginia, 6 November 26, 2001. Available from http://csrc.nist.gov/.
7 [4] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM), submitted to 8 N.I.S.T., June 3, 2002. Available from 9 http://csrc.nist.gov/encryption/modes/proposedmodes/.
[5] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.11-1999, IEEE Standard 11 for Telecommunications and Information Exchange Between Systems ¨
LAN/MAN Specific 12 Requirements ¨ Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 13 Specifications, New York: IEEE Press, 1999.
14 [6] Institute of Electrical and Electronics Engineers, Inc., IEEE Std.
802.15.3-2003, IEEE
Standard for Information Technology ¨ Telecommunications and Information Exchange 16 between Systems ¨ Local and Metropolitan Area Networks ¨ Specific Requirements ¨
17 Part 15.3: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 18 Specifications for High Rate Wireless Personal Area Networks (WPAN). New York: IEEE
19 Press. 2003.
[7] Institute of Electrical and Electronics Engineers, Inc., IEEE Std.
802.15.4-2003, IEEE
21 Standard for Information Technology ¨ Telecommunications and Information Exchange 22 between Systems ¨ Local and Metropolitan Area Networks ¨ Specific Requirements ¨
23 Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 24 Specifications for Low Rate Wireless Personal Area Networks (WPAN). New York: IEEE
Press. 2003.
26 [8] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of Selected Areas in 27 Cryptography ¨ SAC 2002, K. Nyberg, H. Heys, Eds., Lecture Notes in Computer Science, 28 Vol. 2595, pp. 76-93, Berlin: Springer, 2002.
22291667.1 1 [9] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of Operation ¨ Additional 2 CCM Documentation. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/.
3 [10] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes of Operation ¨
4 Methods and Techniques, NIST Special Publication 800-38A, 2001 Edition, US Department of Commerce/N.I.S.T., December 2001. Available from http://csrc.nist.gov/.
6 [11] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive 2003-070, April 13, 7 2003.
22291667.1
4. An octet string a of length 1(a) octets, where 0 1(a) <2. In the embodiment of figure 1, 11 this is header information.
13 The nonce N shall encode the potential values for M such that one can uniquely determine from 14 N the actually used value of M. The exact format of the nonce N shall be determined and fixed by the actual implementation environment of the CCM* mode in accordance with normal 16 considerations.
17 The exact format of the nonce N is left to the application, to allow simplified hardware and 18 software implementations in particular settings. Actual implementations of the CCM* mode may 19 restrict the values of M that are allowed throughout the life-cycle of the encryption key Key to a strict subset of those allowed in the generic CCM* mode. If so, the format of the nonce N shall 21 be such that one can uniquely determine from N the actually used value of M in that particular 22 subset. In particular, if M is fixed and the value M=0 is not allowed, then there are no restrictions 23 on N, in which case the CCM* mode reduces to the CCM mode.
24 The restriction on N limits the freedom in specifying the nonce, which might be undesirable. An alternative would be to incorporate the value of M in the L-octet wide length field in a reversible 26 way, which effectively reduces this to an L-1 octet field for length encoding purposes. The 27 essential cryptographic requirement is as follows: The first authentication block Bo (see A2.1.2, 28 step 2) and the encryption blocks Ai (see step A2.1.3, step 2) shall encode the potential values of 29 M such that this parameter can be uniquely recovered. This allows other options for encoding 22291667.1 1 than the ones presented in this specification. (As an example, in applications such as the IEEE
2 802.15.4 Low-Rate WPAN standard [7], the length of a message to be encrypted is at most 127 3 bytes, so 1(m) could be represented using only 7 bits rather than the 2 octets currently reserved 4 for this. Also, the number of applications of the 128-bit block cipher would be at most 8, so the number of different counter values Ai (see step A2.1.3, step 2) per frame can be represented 6 using only 3 bits, rather than the 2 octets currently reserved for this.) 7 (i) A2.1.1 Input transformation 8 This step involves the transformation of the input strings a and m to the strings AuthData and 9 Plain TextData, to be used by the authentication transformation and the encryption transformation, respectively.
11 This step involves the following steps, in order:
12 1. Form the octet string representation L(a) of the length 1(a) of the octet string a, as follows:
13 a. If 1(a)=0, then L(a) is the empty string.
14 b. If 0 < 1(a) <21628, then L(a) is the 2-octets encoding of 1(a).
c. If 216-28 < 1(a) <232, then L(a) is the right-concatenation of the octet Oxff, the octet Oxfe, 16 and the 4-octets encoding of 1(a).
17 d. If 232 1(a) <264, then L(a) is the right-concatenation of the octet Oxff, the octet Oxff, and 18 the 8-octets encoding of 1(a).
2. Right-concatenate the octet string L(a) with the octet string a itself.
Note that the resulting 21 string contains 1(a) and a encoded in a reversible manner.
23 3. Form the padded message AddAuthData by right-concatenating the resulting string with the 24 smallest non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by 16.
26 4. Form the padded message PlaintextData by right-concatenating the octet string m with the 27 smallest non-negative number of all-zero octets such that the octet string PlaintextData has 28 length divisible by 16.
22291667.1 1 5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
2 AuthData = AddAuthData II Plaint extData.
3 (ii) A2.1.2 Authentication transformation 4 The data AuthData that was established above shall be tagged using the tagging transformation as follows:
6 1. Form the 1-octet Flags field consisting of the 1-bit Reserved field, the 1-bit Adata field, and 7 the 3-bit representations of the integers M and L, as follows:
8 Flags Reserved Adata M II L.
9 Here, the 1-bit Reserved field is reserved for future expansions and shall be set to '0'. The 1-bit Adata field is set to '0' if 1(a)=0, and set to '1' if 1(a)>0. The M field is the 3-bit 11 representation of the integer (M-2)/2 if M>0 and of the integer 0 if M=0, in most-significant-12 bit-first order. The L field is the 3-bit representation of the integer L-1, in most-significant-13 bit-first order.
14 2. Form the 16-octet Bo field consisting of the 1-octet Flags field defined above, the 15-L octet nonce field N, and the L-octet representation of the length field 1(m), as follows:
16 Bo Flags II Nonce N 1(m).
17 3. Parse the message AuthData as B1 II B2 II ... Pt, where each message block B, is a 16-octet 18 string.
19 4. The CBC-MAC value X+1 is defined by Xo := 0128; Xi+1 E(Key, X, 0 .131) for i=0, , t.
21 Here, E(K, x) is the cipher-text that results from encryption of the plaintext x, using the 22 established block-cipher encryption function E with key Key; the string 0)28 is the 16-octet 23 all-zero bit string.
22291667.1 =
1 5. The authentication tag T is the result of omitting all but the leftmost M octets of the CBC-2 MAC value Xt+1 thus computed.
3 (iii) A2.1.3 Encryption transformation 4 The data PlaintextData that was established in clause A2.1.1 (step 4) and the authentication tag T
that was established in clause A2.1.2 (step 5) shall be encrypted using the encryption 6 transformation as follows:
7 1. Form the 1-octet Flags field consisting of two 1-bit Reserved fields, and the 3-bit 8 representations of the integers 0 and L, as follows:
9 Flags = Reserved II Reserved II 0 II L.
Here, the two 1-bit Reserved fields are reserved for future expansions and shall be set to '0'.
11 The '0' field is the 3-bit representation of the integer 0, in most-significant-bit-first order.
12 The L field is the 3-bit representation of the integer L-1, in most-significant-bit-first order.
13 2. Define the 16-octet A, field consisting of the 1-octet Flags field defined above, the 15-L octet 14 nonce field N, and the L-octet representation of the integer i, as follows:
A, = Flags II Nonce N II Counter i, for 1=0, 1,2, ...
16 Note that this definition ensures that all the A1 fields are distinct from the Bo fields that are 17 actually used, as those have a Flags field with a non-zero encoding of M
in the positions 18 where all Ai fields have an all-zero encoding of the integer 0 (see clause A2.1.2, step 2).
19 3. Parse the message PlaintextData as M111 ... 11Mt, where each message block M, is a 16-octet string.
21 4. The ciphertext blocks C1, , Ct are defined by 22 C, := E( Key, i4,) M, for i=1, 2, ... , t.
23 5. The string Ciphertext is the result of omitting all but the leftmost 1(m) octets of the string CI 11 24 ... C1.
22291667.1 1 6. Define the 16-octet encryption block So by 2 So:= E( Key, Ao ).
3 7. The encrypted authentication tag U is the result of XOR-ing the string consisting of the 4 leftmost M octets of So and the authentication tag T.
Output: If any of the above operations has failed, then output 'invalid'.
Otherwise, output the 6 right-concatenation of the encrypted message Ciphertext and the encrypted authentication tag U.
7 A2.2 CCM* mode decryption and authentication checking transformation 8 Input: The CCM* inverse transformation takes as inputs:
9 1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to this key is restricted to the entity itself and its intended key-sharing group 11 member(s).
12 2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall 13 be unique.
14 3. An octet string c of length 1(c) octets, where 0 l(c)-M< 281,.
4. An octet string a of length 1(a) octets, where 0 1(a) < 264 .
16 (iv) A2.2.1 Decryption transformation 17 The decryption transformation involves the following steps, in order:
18 1. Parse the message c as C II U, where the right-most string U is an M-octet string. If this 19 operation fails, output 'invalid' and stop. U is the purported encrypted authentication tag.
Note that the leftmost string C has length /(c)-M octets.
21 2. Form the padded message CiphertextData by right-concatenating the string C with the 22 smallest non-negative number of all-zero octets such that the octet string CiphertextData has 23 length divisible by 16.
22291667.1 =
2 and the tag U.
4 most string T is an M-octet string. T is the purported authentication tag. Note that the leftmost 5 string m has length 1(c)-M octets.
6 (v) A2.2.2 Authentication checking transformation 9 the string a and the octet string m that was established in clause A2.2.1 (step 4).
12 established in clause A2.2.1 (step 4). If MACTag=T, output 'valid':
otherwise, output 13 'invalid' and stop.
22 operations.
22291667.1 6 = The CCM* mode allows the length of the authentication field M to be zero as well (the value 7 M=0 corresponding to disabling authenticity, since then the authentication field is the empty 8 string).
values for M such that one can uniquely determine from N the actually used value of M.
23 one can uniquely determine the input strings a and m (as well as the nonce N). In fact, for any 24 two input strings corresponding to distinct triples (N, m, a), neither one is a prefix string of 25 the other.
22291667.1 1 = All the Ai fields are distinct from the Bo fields that are actually used (over the lifetime of the 2 key), as those have a Flags field with a non-zero encoding of M in the positions where all A;
3 fields have an all-zero encoding of the integer 0.
4 Hence, if M is fixed, then the CCM* mode offers the same security properties as the original CCM mode: confidentiality over the input string m and data authenticity over the input strings a 6 and m, relative to the length of the authentication tag. Obviously, if M=0, then no data 7 authenticity is provided by the CCM* mode itself (but may be provided by an external 8 mechanism).
9 For variable-length authentication tags, the original CCM mode is known to be vulnerable to specific attacks (see, e.g., Section 3.4 of [11]). These attacks may arise with the original CCM
11 mode, since the decryption transformation does not depend on the length of the authentication 12 tag itself. The CCM* mode avoids these attacks altogether, by requiring that one shall be able to 13 uniquely determine the length of the applicable authentication tag from the Ai fields (i.e., from 14 the counters blocks).
A4 Interoperability between CCM mode and CCM* mode of operation 16 The CCM* mode reduces to the CCM mode in all implementation environments where the 17 length of the authentication tag is fixed and where the value M=0 (encryption-only) is not 18 allowed. In particular, the CCM* mode is compatible with the CCM mode, as specified in the 19 Draft Amendment (as of July 2003) to the IEEE 802.11 WLAN standard [5]
and as specified in the IEEE 802.15.3 WPAN standard [6]. The IEEE 802.15.4 WPAN standard [7]
currently 21 incorporates the CCM mode with variable-length authentication tags; the upcoming security 22 amendment is anticipated to involve replacement of the CCM mode by the CCM* mode of 23 operation, to securely support variable-length authentication tags in its target application area ¨
24 low-cost sensor networks.
References referred to in the above text are as follows.
26 [1] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key 27 Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers 28 Association, November 20, 2001. Available from http://www.ansi.org.
22291667.1 1 [2] FIPS Pub 113, Computer Data Authentication, Federal Information Processing Standards 2 Publication 113, US Department of Commerce/N.I.S.T., May 30, 1985.
Available from 3 http://csrc.nist.gov/."
4 [3] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, US Department of Commerce/N.I.S.T, Springfield, Virginia, 6 November 26, 2001. Available from http://csrc.nist.gov/.
7 [4] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM), submitted to 8 N.I.S.T., June 3, 2002. Available from 9 http://csrc.nist.gov/encryption/modes/proposedmodes/.
[5] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.11-1999, IEEE Standard 11 for Telecommunications and Information Exchange Between Systems ¨
LAN/MAN Specific 12 Requirements ¨ Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 13 Specifications, New York: IEEE Press, 1999.
14 [6] Institute of Electrical and Electronics Engineers, Inc., IEEE Std.
802.15.3-2003, IEEE
Standard for Information Technology ¨ Telecommunications and Information Exchange 16 between Systems ¨ Local and Metropolitan Area Networks ¨ Specific Requirements ¨
17 Part 15.3: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 18 Specifications for High Rate Wireless Personal Area Networks (WPAN). New York: IEEE
19 Press. 2003.
[7] Institute of Electrical and Electronics Engineers, Inc., IEEE Std.
802.15.4-2003, IEEE
21 Standard for Information Technology ¨ Telecommunications and Information Exchange 22 between Systems ¨ Local and Metropolitan Area Networks ¨ Specific Requirements ¨
23 Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) 24 Specifications for Low Rate Wireless Personal Area Networks (WPAN). New York: IEEE
Press. 2003.
26 [8] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of Selected Areas in 27 Cryptography ¨ SAC 2002, K. Nyberg, H. Heys, Eds., Lecture Notes in Computer Science, 28 Vol. 2595, pp. 76-93, Berlin: Springer, 2002.
22291667.1 1 [9] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of Operation ¨ Additional 2 CCM Documentation. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/.
3 [10] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes of Operation ¨
4 Methods and Techniques, NIST Special Publication 800-38A, 2001 Edition, US Department of Commerce/N.I.S.T., December 2001. Available from http://csrc.nist.gov/.
6 [11] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive 2003-070, April 13, 7 2003.
22291667.1
Claims (28)
1. A computer-implemented method of formatting data at a device capable of providing optional data confidentiality and optional data authenticity, the method comprising:
obtaining message data m and nonce data N, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level inhibits or invokes data confidentiality, and wherein the security level inhibits or invokes data authenticity; and generating, by a cryptographic unit, a block-cipher output based on the message data m and the nonce data N, wherein the output comprises the authentication tag if the security level invokes data authenticity, and wherein the output comprises encrypted data if the security level invokes data confidentiality, wherein generating the output comprises encrypting the authentication tag and the message data m if the security level invokes both data confidentiality and data authenticity.
obtaining message data m and nonce data N, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level inhibits or invokes data confidentiality, and wherein the security level inhibits or invokes data authenticity; and generating, by a cryptographic unit, a block-cipher output based on the message data m and the nonce data N, wherein the output comprises the authentication tag if the security level invokes data authenticity, and wherein the output comprises encrypted data if the security level invokes data confidentiality, wherein generating the output comprises encrypting the authentication tag and the message data m if the security level invokes both data confidentiality and data authenticity.
2. The method of claim 1, wherein generating the output comprises encrypting the message data in if the security level invokes data confidentiality.
3. The method of claim 1, wherein the output comprises message data m and the authentication tag if the security level inhibits data confidentiality and invokes data authenticity, wherein the message data m in the output is unencrypted.
4. The method of claim 1, wherein the authentication tag in the output is unencrypted.
5. The method of claim 1, wherein the output lacks any authentication tag if the security level inhibits data authenticity.
6. The method of claim 1, wherein the output comprises plain text if the security level inhibits data confidentiality.
7. The method of claim 1, wherein the nonce data N is based on a frame identifier for an individual frame of data, wherein the security level inhibits or invokes data confidentiality for the individual frame, and wherein the security level inhibits or invokes data authenticity for the individual frame.
8. The method of claim 1, further comprising obtaining key data.
9. The method of claim 1, wherein the authentication tag comprises a variable-length authentication tag.
10. The method of claim 1, wherein the value M is zero.
11. The method of claim 1, wherein if the value M is zero, then data authenticity is disabled.
12. The method of claim 1, wherein the value M is greater than zero.
13. The method of claim 1, wherein the security level is configured to allow for varying levels of data authenticity.
14. The method of claim 1, wherein the method is performed prior to transmission of data.
15. The method of claim 1, further comprising transmitting a message comprising the output.
16. A computer-implemented method of processing data received at a device, the method comprising:
obtaining nonce data N and block-cipher data c, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level indicates whether data confidentiality is invoked or inhibited, wherein the security level indicates whether data authenticity is invoked or inhibited, wherein the data c comprises encrypted data if the security level indicates data confidentiality is invoked, and wherein the data c comprises the authentication tag if the security level indicates data authenticity is invoked; and determining, by a cryptographic unit, message data m based on the data c and the nonce data N, wherein determining message data m comprises decrypting data c and checking authentication if the security level indicates data confidentiality and data authenticity are both invoked.
obtaining nonce data N and block-cipher data c, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level indicates whether data confidentiality is invoked or inhibited, wherein the security level indicates whether data authenticity is invoked or inhibited, wherein the data c comprises encrypted data if the security level indicates data confidentiality is invoked, and wherein the data c comprises the authentication tag if the security level indicates data authenticity is invoked; and determining, by a cryptographic unit, message data m based on the data c and the nonce data N, wherein determining message data m comprises decrypting data c and checking authentication if the security level indicates data confidentiality and data authenticity are both invoked.
17. The method of claim 16, wherein determining message data m comprises checking authentication if the security level indicates data authenticity is invoked.
18. The method of claim 16, wherein determining message data m comprises decrypting the data c if the security level indicates data confidentiality is invoked.
19. The method of claim 16, wherein determining message data in comprises parsing data c if the security level indicates data confidentiality and data authenticity are both inhibited.
20. The method of claim 16, wherein the nonce data N is based on a frame identifier for an individual frame of data, wherein the security level inhibits or invokes data confidentiality for the individual frame, and wherein the security level inhibits or invokes data authenticity for the individual frame.
21. The method of claim 16, further comprising obtaining key data.
22. The method of claim 16, wherein the authentication tag comprises a variable-length authentication tag.
23. The method of claim 16, wherein the value M is zero.
24. The method of claim 16, wherein if the value M is zero, then data authenticity is disabled.
25. The method of claim 16, wherein the value M is greater than zero.
26. The method of claim 16, wherein the security level is configured to allow for varying levels of data authenticity.
27. A non-transitory machine-readable medium comprising machine-executable instructions for formatting data at a device capable of providing optional data confidentiality and optional data authenticity, the machine-executable instructions operable when executed to perform operations comprising:
obtaining message data m and nonce data N, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level inhibits or invokes data confidentiality, and wherein the security level inhibits or invokes data authenticity; and generating a block cipher output based on the message data m and the nonce data N, wherein the output comprises the authentication tag if the security level invokes data authenticity, and wherein the output comprises encrypted data if the security level invokes data confidentiality, wherein generating the output comprises encrypting the authentication tag and the message data m if the security level invokes both data confidentiality and data authenticity.
obtaining message data m and nonce data N, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level inhibits or invokes data confidentiality, and wherein the security level inhibits or invokes data authenticity; and generating a block cipher output based on the message data m and the nonce data N, wherein the output comprises the authentication tag if the security level invokes data authenticity, and wherein the output comprises encrypted data if the security level invokes data confidentiality, wherein generating the output comprises encrypting the authentication tag and the message data m if the security level invokes both data confidentiality and data authenticity.
28. A non-transitory machine-readable medium comprising machine-executable instructions for processing data received at a device, the machine-executable instructions operable when executed to perform operations comprising obtaining nonce data N and block cipher data c, wherein a value M encoded in the nonce data N indicates a length of an authentication tag, wherein the nonce data N
comprises an identification of a security level, wherein the security level indicates whether data confidentiality is invoked or inhibited, wherein the security level indicates whether data authenticity is invoked or inhibited, wherein the data c comprises encrypted data if the security level indicates data confidentiality is invoked, and wherein the data c comprises the authentication tag if the security level indicates data authenticity is invoked; and determining message data m based on the data c and the nonce data N, wherein determining message data m comprises decrypting data c and checking authentication if the security level indicates data confidentiality and data authenticity are both invoked.
comprises an identification of a security level, wherein the security level indicates whether data confidentiality is invoked or inhibited, wherein the security level indicates whether data authenticity is invoked or inhibited, wherein the data c comprises encrypted data if the security level indicates data confidentiality is invoked, and wherein the data c comprises the authentication tag if the security level indicates data authenticity is invoked; and determining message data m based on the data c and the nonce data N, wherein determining message data m comprises decrypting data c and checking authentication if the security level indicates data confidentiality and data authenticity are both invoked.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2449524A CA2449524C (en) | 2003-11-14 | 2003-11-14 | Cryptographic method and apparatus |
| US10/986,806 US8060743B2 (en) | 2003-11-14 | 2004-11-15 | Cryptographic method and apparatus |
| US13/275,027 US8707036B2 (en) | 2003-11-14 | 2011-10-17 | Cryptographic method and apparatus |
| US14/199,421 US9043876B2 (en) | 2003-11-14 | 2014-03-06 | Cryptographic method and apparatus |
| US14/714,401 US9692591B2 (en) | 2003-11-14 | 2015-05-18 | Cryptographic method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2449524A CA2449524C (en) | 2003-11-14 | 2003-11-14 | Cryptographic method and apparatus |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2449524A1 CA2449524A1 (en) | 2005-05-14 |
| CA2449524C true CA2449524C (en) | 2014-10-28 |
Family
ID=34558351
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2449524A Expired - Lifetime CA2449524C (en) | 2003-11-14 | 2003-11-14 | Cryptographic method and apparatus |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2449524C (en) |
-
2003
- 2003-11-14 CA CA2449524A patent/CA2449524C/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2449524A1 (en) | 2005-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9043876B2 (en) | Cryptographic method and apparatus | |
| Karn et al. | The esp des-cbc transform | |
| US7623656B2 (en) | Stream cipher encryption and message authentication | |
| Xiao et al. | Stream-based cipher feedback mode in wireless error channel | |
| Xiao et al. | Security services and enhancements in the IEEE 802.15. 4 wireless sensor networks | |
| EP0725511A3 (en) | Method for data encryption/decryption using cipher block chaining (CBC) and message authetication codes (MAC) | |
| Rogaway et al. | A critique of CCM | |
| Frankel et al. | The AES-XCBC-MAC-96 algorithm and its use with IPsec | |
| Gueron et al. | Comet: counter mode encryption with authentication tag | |
| Bellare et al. | The secure shell (SSH) transport layer encryption modes | |
| Jindal et al. | Analyzing the security-performance tradeoff in block ciphers | |
| Prajwal et al. | User defined encryption procedure for IDEA algorithm | |
| CN113015157A (en) | Method, device and system for supporting multiple encryption in wireless communication system | |
| CA2449524C (en) | Cryptographic method and apparatus | |
| Huo et al. | Physical layer phase encryption for combating the traffic analysis attack | |
| Qianqian et al. | Security analysis for wireless networks based on ZigBee | |
| Frankel et al. | RFC3566: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec | |
| Adekunle et al. | A resourceful combined block cipher mode of operation for packetised network communication | |
| Padmini et al. | Authenticated Encryption for Wireless Sensor Network | |
| Li et al. | Application and analysis of IEEE 802.14. 5 security services | |
| Huang et al. | Observations on the Message Integrity Code in IEEE802. 11Wireless LANs | |
| Gutmann | Password-based Encryption for CMS | |
| Dworkin | Block cipher modes of operation: The CCM mode for authentication and confidentiality | |
| RadiHamade | Survey: Block cipher Methods | |
| Sachdev et al. | Improving Real-Time Data Streaming Security to Promote Patient and Physician Socialization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20231114 |