1. Technical Field
Embodiments of the present invention relate generally to message transmission and authenticated encryption and more particularly to a method and system for generating ciphertext and message authentication codes utilizing shared hardware.
2. Description of the Related Art
An authenticated encryption (or authenticated encryption and associated data) system is one that employs various hardware and software elements, cryptographic keys, algorithms, and/or techniques to simultaneously protect the confidentiality and the authenticity or “integrity” of communications. More specifically, authenticated encryption attempts to make it computationally infeasible for a party to fraudulently represent themselves as an authentic message source by encoding a message, to fraudulently decode messages received from such a source, or to otherwise gain information about the manner in which message data is encrypted, decrypted, or authenticated. While a number of conventional authenticated encryption (AE) systems or modes are provided utilizing symmetric block ciphers (e.g., Electronic Code Book, Cipher Block Chaining, Cipher Feedback, Output Feedback, Counter Mode, or the like), AE functionality may be provided generally by combining any encryption technique (e.g., symmetric or asymmetric) and authentication technique via the generation of a message authentication code (MAC) or “tag” under appropriate constraints. Where authenticated encryption systems implement encoding (or decoding) via the encryption (or decryption) of message data and MAC generation (or verification) such operations may be performed in any order or substantially simultaneously.
Although the goals of message data confidentiality and authenticity or integrity have long been studied, only relatively recently have a number of systems been developed due to the complexity of implementing both operations in a single application. Exemplary authenticated encryption systems or modes include Counter with CBC-MAC (CCM), One-Key CBC-MAC (OMAC), Cipher-State (CS), Carter Wegman with Counter (CWC), Encrypt then Authenticate then Translate Mode (EAX), Galois/Counter Mode (GCM), Integrity Aware Cipher Block Chaining (IACBC), Integrity Aware Parallelizable Mode (IAPM), Offset Codebook (OCB), Propagating Cipher Feedback (PCFB), and eXtended Cipher Block Chaining Encryption (XCBC).
FIG. 3 illustrates a block diagram representation of a first authenticated encryption mode authenticated encryption unit according to the prior art. More specifically, FIG. 3 depicts a block diagram of an authenticated encryption unit configured to perform GCM authenticated encryption. GCM or “Galois/Counter Mode” is a block cipher mode of operation that uses universal hashing over a binary Galois field to provide authenticated encryption. GCM uses mechanisms that are supported by a well-understood theoretical foundation, and its security follows from a single reasonable assumption about the security of the block cipher.
GCM has two operations, authenticated encryption and authenticated decryption. For purposes of illustration herein, only authenticated encryption functionality will be described in detail. In the prior art embodiment which will be described with respect to FIG. 3, GCM authenticated encryption has three inputs, each of which is a bit string including, a secret key “K” (not shown), whose length is appropriate for the underlying block cipher, an initialization vector “IV”, that can have any number of bits between 1 and 264, and plaintext message data. For a fixed value of the key (K), each initialization vector value must be distinct, but need not have equal lengths. Additional authenticated data may also be provided which is authenticated although not encrypted.
Utilizing the described inputs, two outputs are generated, ciphertext message data whose length is exactly that of the plaintext message data, and a message authentication code “MAC”, whose length can be any value between 64 and 128. Each input and output in the illustrated prior art embodiment is embodied within a data bit string. The primary purpose of the initialization vector is to server as a nonce, that is, to be distinct for each invocation of the encryption operation for a fixed key.
In operation, the initialization vector “IV” is applied to an increment function hardware module 302 which outputs successive counter values that are applied to a block cipher encryption hardware module 304. In the prior art embodiment of FIG. 3, block cipher encryption hardware module 304 implements an Advanced Encryption Standard (AES) block cipher. A multiplexer 306 or other switching element is then utilized to output data specifying the first encrypted IV/counter for use in generating a MAC value as indicated by dashed line 308. Multiplexer 306 is then switched or actuated such that data specifying subsequent encrypted IV/counter values are combined, via a logical exclusive OR operation, using XOR hardware module 310 with plaintext message data to generate ciphertext message data as shown.
The described ciphertext message data is applied to another XOR hardware module 312 to be logically combined with feedback data generated by Galois Field (GF) multiplier hardware module 314 (e.g., initially GF multiplied additional authenticated data or other seed or initialization data) and the resultant logically combined data is applied to GF multiplier hardware module 314 as shown. Following GF multiplication, the generated output of GF multiplier hardware module 314 is fed back to XOR hardware module 312 and simultaneously applied to a final XOR hardware module 316. The applied GF multiplier hardware module output is logically combined using XOR hardware module 316 with the previously-described first encrypted IV/counter data to generate a MAC as shown.
FIG. 4 illustrates a block diagram representation of a second authenticated encryption mode authenticated encryption unit according to the prior art. More specifically, FIG. 4 depicts a block diagram of an authenticated encryption unit configured to perform Cipher-Block Chaining (CBC)-MAC (CCM) authenticated encryption. CCM mode combines counter mode encryption with a CBC-MAC mode of authentication. Utilizing CCM, a single encryption key (not shown) can be used for both encryption and authentication, provided that the counter values used in the encryption do not collide with the (pre-) initialization vector used in authentication. CCM is a generic authenticate-and-encrypt block cipher mode. Traditionally, CCM is defined for use with 128-bit block ciphers such as AES.
CCM has two operations, authenticated encryption and authenticated decryption. For purposes of illustration herein, only authenticated encryption functionality will be described in detail. In the prior art embodiment of FIG. 4, CCM authenticated encryption utilizes three bit string inputs including a secret key “K” (not shown), a nonce (e.g., an initialization vector “IV”), and plaintext message data. As described herein with respect to GCM, additional authenticated data may also be provided for authentication without encryption. Utilizing the described inputs, two bit string outputs are generated, a ciphertext message data whose length is exactly that of the plaintext message data and a message authentication code “MAC”.
In operation, the initialization vector “IV” is applied to an increment function hardware module 302 which outputs successive counter values that are applied to a block cipher (e.g., AES) encryption hardware module 404. A multiplexer 406 or other switching element is then utilized to output data specifying the first encrypted IV/counter for use in generating a MAC value as indicated by dashed line 408. Multiplexer 406 is then switched or actuated such that data specifying subsequent encrypted IV/counter values are combined, via a logical exclusive OR operation, using XOR hardware module 410 with plaintext message data to generate ciphertext message data as shown.
The described plaintext message data is also simultaneously applied to another XOR hardware module 412 to be logically combined with feedback data generated by another (e.g., AES) block cipher encryption hardware module 414 (e.g., encrypted additional authenticated data or other seed or initialization data) and the resultant logically combined data is applied to block cipher encryption hardware module 414 as shown. Following encryption, the generated output of block cipher encryption hardware module 414 is fed back to XOR hardware module 412 and simultaneously applied to a final XOR hardware module 416. The applied block cipher encryption hardware module output is logically combined using XOR hardware module 416 with the previously-described first encrypted IV/counter data to generate a MAC as shown.
While any of the described AE techniques or modes may be implemented in software or a combination of software and hardware, authenticated encryption is typically implemented solely in hardware such that inter or intra-system buffering of message data is not required.
Because of the monetary cost of application or mode-specific AE solutions, conventional systems typically implement a single authenticated encryption mode of operation. Consequently, such conventional AE systems suffer from number of drawbacks. More specifically, any change or supplement in the AE mode of operation to be performed (e.g., when an existing mode of operation is compromised from an encryption or authentication standpoint, when a particular user or implementation requires a different mode of authenticated encryption operation than that already provided, when greater flexibility or centralization of a system including authenticated encryption functionality is desired, or the like) requires the provision of additional, specifically configured hardware. Such additional hardware may be cost or space-prohibitive in some systems.
USPTO Backgrounds
USPTO Backgrounds