Apparatuses for encoding, decoding, and authenticating data in cipher block chaining messaging authentication code

[0001] The present invention relates to apparatuses for encoding data using the counter with cipher block chaining messaging authentication code (CCM) protocol, and to apparatuses for decoding and authenticating such data.

[0002] Counter with cipher block chaining messaging authentication code (CCM) is a known protocol for encrypting data and enabling the encrypted data to be authenticated. The CCM algorithm uses a symmetric key block cipher algorithm as a component building block; the CCM algorithm can therefore be viewed as a mode of operation of the symmetric key block cipher. Examples of symmetric key block ciphers include the advanced encryption standard (AES) and the data encryption standard (DES).

[0003] More and more data traffic over the Internet is being encrypted by a number of cipher algorithms, with some data transmission standards, such as the IEEE 802.16 wireless standard, specifying the use of the CCM algorithm. As part of making their inventions, the inventors recognize that the CCM algorithm and the underlying block cipher would dramatically increase the computational demands on the central processing units of network servers, particularly the central processing units that implement the network protocol layer and the media-access control layer.

[0004] Broadly stated, the present invention encompasses apparatus and methods of processing data blocks according to the counter with cipher block chaining messaging authentication code (CCM) protocol. An exemplary apparatus comprises a first cipher circuit, a second cipher circuit, a controller that sequences data blocks through the cipher circuits, a first input to receive headers and payloads of messages in block form, a second input to receive a cipher key, a third input to receive a counter block, and a first output to provide a data block processes according to a cipher block chaining messaging authentication code (CCM) protocol. The controller processes a first sequence of data blocks through the first cipher circuit to generate a message integrity code and a second sequence of data blocks through the second cipher circuit to generate a set of ciphered data blocks. Further preferred embodiments comprise a fourth input to receive an indication that a data block is ready to be received at the processor's first input, and a second output (TDRY) to provide signal requesting the provision of a data block at the processor's first input.

[0005] Exemplary methods according to the present invention comprise the sets of processing two sequences of data blocks through two ciphering machines, such that the ciphering machines can process their respective sequences of block at common instances of time.

[0006] Accordingly, it is an object of the present invention to increase the rate at which data can be encrypted and/or decrypted according to the CCM protocol.

[0007] It is another object of the present invention to enable the application of the CCM protocol on data blocks conveyed in messages on communications networks.

[0008] These and other objects of the present invention will become apparent to those skilled in the art from the following detailed description of the invention, the accompanying drawings, and the appended claims.

[0014] In the following description, numerous specific details are set forth to provide a more thorough description of the specific embodiments of the inventions. It is apparent, however, that the inventions may be practiced without all the specific details given below. In other instances, well known features have not been described in detail so as not to obscure the inventions.

[0015] To better understand the present inventions, we first provide a general overview of the CCM encryption method as implemented on the specific organization of data that is often found in packet communications, and as further implemented according to our invention. (A more general description of the CCM encryption method can be found in (NIST) Special Publication 800-38C, entitled “DRAFT Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality,” September 2003, by Morris Dworkin). In data communication environments, data is transmitted in blocks called payload blocks (P_i, i=1, 2, . . . , NP), which are preceded by one or more header blocks (H_j, j=1, 2, . . . , NH) that convey information as to the number of payload blocks in the transmission and an indication of where the payload blocks are to be conveyed on the network. For the purposes of this illustration, each header block (H_j) and each payload block (P_i) will be assumed to have 128 bits, or 16 bytes. In the transmission, the one or more header blocks are not encrypted, but the payload blocks are encrypted. It is often important that the transmission also include a message-integrity code (MIC), also called a message-authentication code (MAC), that can be used by the receiver to verify that the message was in fact sent by the sender specified in the header, and/or to verify that the data within the encrypted message has not been corrupted during transmission. The CCM method is able to do both of these functions (encryption of the payload and the generation of a message-integrity code that verifies both the authenticity and integrity of the message). To encrypt the payload blocks, a sequence of counter blocks (Ctr_i, i=1, 2, . . . ) is created at both the transmission and reception ends for a given communication connection. Each counter block (Ctr_i) has the same number of bytes as the payload block, and each counter block is associated with a particular payload block to be encrypted. The counter blocks are distinct from one another during the use of a particular cipher key (K) within a particular communication connection. The counter blocks (Ctr_i) need not be secret, and may be generated by incrementing a selected number of bits within the counter blocks. For example, one may start with an initial value for the first counter block, and increment this value by one for each subsequent counter block. Each counter block (Ctr_i) is then encrypted by a cipher algorithm using a secret key (K) to provide an encrypted counter block (S_i), which is associated with the same payload block (P_i) that the unencrypted counter block is associated with. Next, the encrypted counter block (S_i) is XORed with its associated payload block (P_i) to generate the encrypted payload block C_i (C_i=P_i⊕S_i). The XOR operation, which is denoted by the symbol “⊕”, is well known to the art, and comprises the application of the exclusive OR operation on a bit-by-bit basis of the inputs P_i and S_i. If “a” and “b” are the corresponding bits of input blocks A and B, respectively, then the exclusive OR operation outputs a binary “1” value if and only if one of “a” and “b” has a binary “1” value (not both), and outputs a binary “0” value when “a” and “b” have the same binary value.

[0016] Because of the properties of the XOR operation, the original payload block P_i can be obtained by XORing the encrypted payload block C_i with the encrypted counter block (S_i) that was initially used to encrypt the payload block. That is to say: P_i=S_i⊕C_i=S_i⊕(P_i⊕S_i). Thus, if the receiver generates the encrypted counter blocks in the same manner as the sender did, it can decrypt the encrypted payload blocks. This is readily accomplished by having the sender and receiver agree on how the counter blocks for a communication channel will be generated (which may be non-secret), and by having both the sender and receiver use the same secret key K to encrypt the counter blocks. Methods of secretly communicating a key K from a sender to a receiver (or vice versa) are well known to the art and do not form a part of the present invention. The operations involved in encrypting and decrypting the payload blocks for a transmission that has one header block (H) and three payload blocks P₁, P₂, P₃ are given in Table I below, where “CIPH (Ctr₁, K)” denotes the selected cipher algorithm applied to the counter block with secret key K:

[0017]

TABLE I
Payload Encryption
Sender side
Receive H, P1, P2, and P3 to encrypt.
Obtain or generate counter blocks Ctr1, Ctr2, and Ctr3, and compute:
S1 = CIPH (Ctr1, K);
C1 = (P1 ⊕ S1);
S2 = CIPH (Ctr2, K);
C2 = (P2 ⊕ S2);
S3 = CIPH (Ct3, K);
C3 = (P3 ⊕ S3).
Send H, C1, C2, C3, and message integrity code (discussed below) to
the Receiver.
Payload Decryption
Receiver side
Receive H, C1, C2, and C3 to decrypt, and the message integrity
code to authenticate (discussed below).
Obtain or generate counter blocks Ctr1, Ctr2, and Ctr3, and compute:
S1 = CIPH (Ctr1, K);
P1 = (C1 ⊕ S1);
S2 = CIPH (Ctr2, K);
P2 = (C2 ⊕ S2);
S3 = CIPH (Ct3, K);
P3 = (C3 ⊕ S3);
Provide H, P1, P2, and P3 to the destination application if the
message integrity code can be authenticated.

[0018] The goal of generating the message integrity code (MIC) is to provide a group of encrypted bytes whose values depend upon the header and payload blocks and the encryption key K in a deterministic way that can be reproduced at the receiver side, yet whose values cannot be reproduced by outside parties. A recursive computation is used in the CCM encryption method to generate the MIC at the sender side, and the MIC is sent to the receiver. The receiver duplicates the recursive computation at its side, and determines if it comes up with the same MIC as that sent by the sender. If so, the message is authenticated. If not, the message is either not authentic or has lost its integrity. At each side (sender and receiver), the recursive computation begins by encrypting the first header block of the message with the key K to generate a first intermediate block Y₀ (Y₀=CIPH (H₁, K)). Then, if there is a second header block, it is XORed with intermediate block Y₀, and the result is encrypted with the key K to generate a second intermediate block Y₁ (Y₁=CIPH ((H₂⊕Y₀,), K)). This recursion continues for the remaining header blocks in the same manner, and is then applied in the same manner to the blocks of the payload, ending with a final intermediate block Y_n. Thus, in the case that there were only two header blocks, then the next intermediate block Y₂ would be Y₂=CIPH ((P₁⊕Y₁,), K)), and the next following intermediate block Y₃ would be Y₃=CIPH ((P₂⊕Y₂,), K)). Thus, the final intermediate block Y_n is a function of the original header and payload (which serves to authenticate the message), and a function of the key (which serves to authenticate the sender). However, three additional steps are performed to arrive at the MIC, the additional steps serving to effectively encrypt the final intermediate block Y_n. First, another counter block (we call it Ctr₀ here) is encrypted with the key K to produce an encrypted counter block S₀ (S₀=CIPH (Ctr₀, K)). Next, the final intermediate block Y_n is XORed with encrypted counter block S₀ to produce the product block T. Finally, the MIC is generated by taking the most significant 64 bits of T (MIC=MSB_—64 (T)). The steps generating the MIC at the sender and the steps of authenticating the MIC at the receiver are listed below in Table II for the common case of a message having one header block (H₁) and three payload blocks (P₁, P₂, P₃), where the subscript “S” has been added to the block names to indicate the generation of the blocks at the sender side, and the subscript “R” has been added to the block names to indicate the generation of the blocks at the receiver side.

[0019]

	TABLE II
	Generation of MIC
	Sender side
	Receive H1, P1, P2, and P3 to generate an associated MIC.
	Obtain or generate a counter block Ctr0, and compute:
	Y0, S = CIPH (H1, K);
	Y1, S = CIPH ((P1 ⊕ Y0, S), K);
	Y2, S = CIPH ((P2 ⊕ Y1, S), K);
	Y3, S = CIPH ((P3 ⊕ Y2, S), K);
	S0 = CIPH (Ctr0, K);
	TS = (Y3, S ⊕ S0);
	MICS = MSB_64 (TS).
	Send MICS along with H, C1, C2, C3, to the Receiver.
	Authentication of MIC
	Receiver side
	Receive H1, C1, C2, C3, and MICS.
	Decrypt C1, C2, and C3, to produce P1, P2, P3, as discussed above.
	Obtain or generate counter block Ctr0, and compute:
	Y0, R = CIPH (H1, K);
	Y1, R = CIPH ((P1 ⊕ Y0, R), K);
	Y2, R = CIPH ((P2 ⊕ Y1, R), K);
	Y3, R = CIPH ((P3 ⊕ Y2, R), K);
	S0 = CIPH (Ctr0, K);
	TR = (Y3, R ⊕ S0);
	MICR = MSB_64 (TR).
	Test to see if MICR = MICS. If yes, the transmission is
	authenticated and verified as having its original integrity. If not,
	the message is either not authentic or has lost its integrity.

[0020] General Overview. FIG. 1 is a block diagram of an exemplary CCM processor 100 according to the present invention using the AES encryption standard as the cipher function CIPH. CCM processor 100 comprises a first AES core 110, a second AES core 120, and a controller 130. AES 110 and 120 are identical in construction and, as explained below in greater detail, carry out an AES cipher on a block of data (BLOCKIN) using key K to provide a result BLOCKOUT=AES (BLOCKIN, K), wherein AES( ) can be used for CIPH( ) in the above description of our implementation of the CCM encryption method. Instead of AES cores, DES cores may be used, and cores implementing other encryptions may be used. Regardless of which encryption cores are used, it is preferred that cores 110 and 120 encrypt the data (BLOCKIN) in the same way, and produce the same result for the same input text and key. As explained in greater detail below, AES core 110 is used in processes that generate or authenticate the MIC code, and AES core 120 is used in processes that encrypt or decrypt the payload blocks.

[0021] CCM processor 100 further comprises two “directional” modes of operation that indicate whether the data is being encrypted (such as at the sender side) or decrypted (such as at the receiver side). The first directional mode is simply called encryption mode, and the second directional mode is called decryption mode. The indication of which mode for processor 100 to use may be conveyed to it on a single digital line, which may convey a value of “1” for the encryption mode and a value of “0” for the decryption mode. That signal line is shown in FIG. 1 as signal ENCDECB, which goes to controller 130.

[0022] CCM processor 100 further comprises three processing modes of operation, which may be simply designated as Mode 0 or “Automatic Mode,” Mode 1 or “Manual Mode,” and Mode 2 or “Plain Mode.” In Automatic Mode, the counter blocks are generated automatically from an initial counter block, as described below in greater detail. In Manual Mode, all of the counter blocks used for a particular CCM encryption are provided to CCM processor 100, and are not generated automatically. In Plain Mode, CCM encryption is not performed on the input data and no counter blocks are used; instead, an AES cipher using key K is performed on the input data block. The processing mode of operation may be conveyed to processor 100 on two signal lines, which can encode up to four different digital values: 0, 1, 2, and 3. These signal lines are shown in FIG. 1 as signal lines PMode[1:0], where the digital values of 0, 1, and 2 thereon are used to indicate Mode 0, Mode 1, and Mode 2, respectively.

[0023] Thus, there are a total of six possible operating modes, depending upon the encryption direction and the processing method. It is noted that the need to perform plain AES decryption (corresponding to the combination of decryption mode and plain mode) is generally not needed in networking applications. Therefore, it is not described herein, but nonetheless it would be within the ability of one of ordinary skill in the art to implement in view of the teachings of the present specification. Thus, for the remaining description, it will be assumed that the User of processor 100 sets the ENCDECB signal to value “1” whenever the plain mode of processing is selected. Signals PMode[1:0], ENCDECB, and the other inputs provided to processor 100 are provided by the User of processor 100. The User of processor 100 is another circuit that employs processor 100 as a co-processor or encryption engine. As explained below in greater detail, the User will coordinate the provision of data to and from processor 100 through several load signals and ready signals.

[0024] In preferred embodiments, processor 100 is clocked by a clock signal CLK in the conventional way that digital circuits are clocked, and can be placed in a starting state by the assertion on a reset signal RST. Also in preferred embodiments, the User of processor 100 first places processor 100 in the starting state, and then provides the key K, the initial counter block, and the first block of data (a header block) to processor 100 for processing. After processor 100 has processed the first block, it stores some intermediate results, and sends an indication to the User that it is ready to receive the next block of data for processing. For the second block and remaining blocks to be processed, processor 100 processes the block, stores intermediate results, outputs any encrypted or decrypted payload blocks that are generated during the processing cycle, and thereafter sends an indication to the User that it is ready to receive the next block of data for processing. Then, the MIC code is generated and, in the case of the decryption processing mode, verified against the MIC received from the sender. For this, the User may load the received MIC into processor 100 in the last processing cycle. The time to process a block (i.e., the process cycle time) usually spans several clock cycles, such as 10 to 15 cycles. In each process cycle, one or both of cores 110 and 120 are active, and controller 130 directs the flow of data to and from cores 110 and 120, performs XORing operations as needed, stores intermediate results, and informs the User of the need to provide another block of input data. As will be explained below, the number of header blocks and payload blocks to be processed are either provided directly or indirectly to processor 100.

[0025] AES cores 110 and 120 are identical in construction. Each core has a first input port for receiving the key signals KEY[127:0], second and third input ports to receive the CLK and RST signals, a fourth input port to receive a data block from controller 130 on signal lines BLOCKIN[127:0] to be encrypted, and a fifth input port to receive a load signal from controller 130 to load the data block on lines BLOCKIN[127:0] and thereafter process it. The processing takes 10 clock cycles (CLK). When each of cores 110 and 120 is done processing, it outputs a ciphered output block at an output port BLOCKOUT[127:0], and generates a Done signal on a second output port. These outputs are provided to controller 130, which collects the ciphered output from BLOCKOUT[127:0] when it detects the Done signal from the core. Designs for cores 110 and 120 are known to the art, and are made available at many resource sites on the Internet. One such site is www.opencores.com. It is well within the ability of one of ordinary skill in the art to find such designs and use them in implementing the present inventions.

[0026] Input and Output Signals. Next, we describe the input and output signals of processor 100. Clock signal CLK is a standard clock signal, and it is provided to each of components 110, 120, and 130. Reset signal RST is provided to each of components 110, 120, and 130 to place each of the components in a starting state when the signal is activated. Signal RST may have an active-low orientation or an active high orientation, and its timing may be asynchronous with respect to clock signal CLK. Signal lines KEY[127:0] convey a 128-bit key needed for the encryption process. These signals lines may go directly to AES cores 110 and 120 and, in preferred embodiments, are held in valid states by the User until processor 100 provides its output results. As another approach, processor 100 may comprise latches to hold these values in response to a load signal (which may be signal LD_HEADER described below). Signal lines TEXTIN[127:0] convey 128 bits (a block of 16 bytes) of data input (called a “data block”), which may be a header block or payload block, depending upon the block's position in the input sequence. The header and payload blocks provided are in sequential order over signal lines TEXTIN[127:0], each block being conveyed by the User during a respective processing cycle. The header blocks are conveyed first, followed by the payload blocks. If the data within the last header block or last payload block is less than 128 bits, it should be aligned to the most significant bit of TEXTIN[127:0], and the least significant bits thereof padded with zero values. Input TEXT_LD is asserted by the User to indicate to processor 100 that a block of data is ready to be loaded in from signal lines TEXTIN[127:0]. Processor 100 provides two output ready signals. First is signal line TRDY, which is asserted to indicate to the User that processed payload text is available at output signals CIPHTEXTOUT [127:0]. In encryption mode, the processed text at CIPHTEXTOUT [127:0] is an encrypted payload block; in decryption mode, the processed text at CIPHTEXTOUT [127:0] is a decrypted payload block. The second ready output from the processor is signal MRDY, which is asserted when the MIC is available on CIPHMICOUT [127:0]. Signal line TRDY will also be used to inform the User to provide the next data block in the sequence on signal lines TEXTIN[127:0] and cause processor 100 to load it by asserting signal TEXT_LD. Signal TEXT_LD may be asserted the very next clock cycle of clock signal CLK after processor 100 asserts signal line TRDY. In addition, for decryption mode, processor 100 has a status signal line MICFAIL that, when asserted, indicates the received MIC was not authenticated.

[0027] Signal lines NUM_HEADER[2:0] convey a digital value indicating the number of header blocks that will be sent over signal lines TEXTIN[127:0] in the sequence that will provide the header and payload blocks. Signal lines CTR_FINAL[127:0] are used only in the Automatic and Manual processing modes, and convey the final counter block value Ctr_NP for the payload. The last two bytes of the value provided on CTR_FINAL[127:0] have the number NP of payload blocks that will be conveyed in the sequence of data blocks, and are copied to a countdown register by controller 130. In Automatic Mode, the sequence of counter blocks is generated from Ctr_NP as follows: each of the counter blocks Ctr₁ through Ctr_NP-1 has the same first fourteen bytes as the final counter block Ctr_NP. The last two bytes of the first counter block Ctr₁ are set to a digital value of 1 (i.e., 00000000 00000001), with the last two bytes of each subsequent counter block in the sequence being incremented by one with respect to the last two bytes of the previous block. That is to say that the last two bytes in counter block Ctr₂ hold a digital value of 2, the last two bytes in counter block Ctr₃ hold a digital value of 3, etc. The counter block used for the MIC processing, counter block Ctr₀, has the same first fourteen bytes as the final counter block Ctr_NP, but has a digital value of zero in its last two bytes. An input signal LD_HEADER is asserted by the User to inform processor 100 that the values on signal lines NUM_HEADER[2:0] and CTR_FINAL[127:0] are valid and ready to be loaded into processor 100.

[0028] In manual processing mode, signal lines CTRIN[127:0] convey the counter blocks of the sequence. Each counter block is loaded automatically when processor 100 asserts the ready line TRDY after the header blocks have been processed. In manual mode, the User has to wait for the header blocks to be processed before presenting the sequence of counter blocks. Since the User knows the number of header blocks (signal NUM_HEADER), it can count the number of assertions of signal TRDY after the process has been started to determine when to start sequencing the counter blocks.

[0029] As indicated above, processor 100 processes input data blocks and output resulting ciphered or decrypted blocks (if ready) in processing cycles. In each process cycle, one or both of cores 110 and 120 are active, and controller 130 directs the flow of data to and from cores 110 and 120, performs XORing operations as needed, stores intermediate results to a plurality of registers, including two 128-bit registers Y and S, and informs the User of the need to provide another block of input data. Register Y is used to store intermediate results of the recursion computation for the MIC generation and MIC authentication; and Register S is used to store the ciphered counter blocks. Each processing cycle takes several clock cycles of clock CLK. Controller 130 may comprise a finite state machine that cycles through a main state for each processing block, with there being several sub-states for each main processing state.

[0030] Below, we give a detailed example implementation of the main states that can be used by controller 130. However, before doing that, we note that the steps outlined in Tables I and II above may be condensed and streamlined in processing cycles according to our invention and can use just two registers Y and S to store intermediate results. First, we present the processing flow for encryption under both automatic and manual modes. Four processing cycles are shown A-D, and the actions detailed therein are self-explanatory. The reader can also readily verify that they duplicate the steps given in Tables I and II for encryption at the sender side.

Encryption Processing Flow for Both Automatic and Manual Modes

A. Set register Y=0 and register S=0;

B. Receive header block H_j, j=1 to j=NH, and do this group of actions during a processing cycle:

[0031] {generate (H_j⊕Y);

• • [0032] send (H_j⊕Y) to core 110 to be ciphered with Key K;
  • [0033] store the ciphered result from core 110 in register Y;

[0034] }.

C. Receive payload block P_i, i=1 to i=NP, and do this group of actions during a processing cycle:

[0035] {generate (P_i⊕Y);

• • [0036] send (P_i⊕Y) to core 110 to be ciphered with key K;
  • [0037] store the ciphered result from core 110 in Y;
  • [0038] generate or receive counter block Ctr_i;
  • [0039] send counter block Ctr_i to core 120 to be ciphered with key K;
  • [0040] store the ciphered result from core 120 in register S;
  • [0041] generate (P_i⊕S) and output it as ciphered payload block C_i=(P_i⊕S);

[0042] }.

D. Do this group of actions during a processing cycle:

[0043] {Send counter block Ctr₀ to core 120 to be ciphered with key K;

• • [0044] Store the ciphered result from core 120 in register S;
  • [0045] Output MIC as MSB_—64 (Y⊕S);

[0046] }.

[0047] Next, we present the processing flow for decryption under both automatic and manual modes. Five processing cycles are shown A-E, and the actions detailed therein are self-explanatory. The reader can also readily verify that they duplicate the steps given in Tables I and II for decryption at the receiver side. We note that the actions in processing Cycle “C” can be done at the same time as the last iteration of processing cycle “B” is done.

Decryption Processing Flow for Both Automatic and Manual Modes

A. Set register Y=0 and register S=0.

B. Receive header block H_j, j=1 to j=NH, and do this group of actions during a processing cycle:

[0048] {generate (H_i⊕Y);

• • [0049] send (H_i⊕Y) to core 110 to be ciphered with Key K;
  • [0050] store the ciphered result from core 110 in register Y.

[0051] }.

C. Do this group of actions during a processing cycle:

[0052] {generate or receive the first counter block Ctr₁;

• • [0053] Receive first encrypted payload block C₁;
  • [0054] send first counter block Ctr₁ to core 120 to be ciphered with key K;
  • [0055] store the ciphered result from core 120 in register S.
  • [0056] generate (C₁⊕S) and output it as decrypted payload block P₁=(C₁⊕S);
  • [0057] store P₁=(C₁⊕S) in a temporary register P_SAVE;

[0058] }.

D. Receive each remaining encrypted payload block C_i, i=2 to i=NP, and do this group of actions during a processing cycle:

[0059] {generate (P_SAVE⊕Y);

• • [0060] send (P_SAVE⊕Y) to core 110 to be ciphered with key K;
  • [0061] store the ciphered result from core 110 in Y;
  • [0062] send counter block Ctr_i to core 120 to be ciphered with key K;
  • [0063] store the ciphered result from core 120 in register S;
  • [0064] output i-th decrypted payload block as P_i=(C_i⊕S);
  • [0065] store P_i=(C_i⊕S) in temporary register P_SAVE;

[0066] }.

E. Do this group of actions during a processing cycle:

[0067] {generate (P_SAVE⊕Y);

• • [0068] send (P_SAVE⊕Y) to core 110 to be ciphered with key K, and send counter block Ctr₀ to core 120 to be ciphered with key K;
  • [0069] store the ciphered result from core 110 in Y, and store the ciphered result from core 120 in register S;
  • [0070] generate MSBL_—64 (Y⊕S) and output;
  • [0071] if MSB_—64 (Y⊕S) is not the same as the received MIC, assert signal MICFAIL;
  • [0072] assert signal MRDY;

[0073] }.

[0074] The astute observer will recognize that registers P_SAVE and S can be shared since the usage of the data held therein does not overlap. Nonetheless, in order to reduce confusion, we have used two registers here and below.

[0075] We now provide below a detailed example implementation of the main states that can be used by controller 130 to implement the actions according to the above processing cycles. The flow through the main states is illustrated in FIG. 2. We have included additional actions to implement the plain encryption mode, which simply entails receiving a data block, sending it to an encryption core, and then outputting the result. The below example gives detailed references to where information is taken in from the input lines by processor 100, and where it is outputted to the output lines. Each main state is implemented with one or more cycles of clock signal CLK, and multiple actions may take place at the same time (e.g., those actions which do not depend upon each other's results may be done at the same time). In fact, because each ciphering operation with cores 110 and 120 takes several cycles, it is preferred that cores 110 and 120 be loaded with data so as to operate concurrently. The description of the main states is self-explanatory. In view of the description, it is within the ability of one of ordinary skill in the art to construct a state machine or microprocessor to implement controller 130 with the main states detailed below.

• [0076] State #1 (initialization). Set registers Y=0 and S=0 in response to the assertion of reset signal RST by the User. If Pmode[1:0] indicates Plain mode, then go to State #2, otherwise go to State #3.
• [0077] State #2 (Plain Mode handling).
  • [0078] {2a. receive a data block P_i provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0079] 2b. send P_i to core 120 to be ciphered with key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to core 120);
  • [0080] 2c. in response to Done signal from core 120, store the ciphered result from core 120 in register S;
  • [0081] 2d. output value of register S on CIPHERTEXTOUT[127:0] and assert signal line TRDY to let the User know that cipher data is present on CIPHERTEXTOUT[127:0];
  • [0082] 2e. go back to State #1.}.
• [0083] State #3. In response to the assertion of the signal LD_HEADER by the User, receive mode indications on signal lines ENCDECB and Pmode[1:0], the number of header blocks NH over signal lines NUM_HEADER[2:0], and the final counter block Ctr_NP over signal lines CTR_FINAL[127:0]. Ascertain the number of payload blocks NP from last two bytes of CTR_FINAL[127:0] and load into a register. Go to State #4.
• [0084] State #4. If signal ENCDECB indicates encryption mode, then go through States #5-#7 below in sequence, with any iterations of a state as indicated; if signal ENCDECB indicates decryption mode, then go through states #8-#11 below, with any iterations of a state as indicated.
• [0085] State #5 (Start of Encryption Processing, header processing). For each header block H_j, j=1 to j=NH, do this group of actions:
  • [0086] {5a. receive a data block H_j provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0087] 5b. generate (H_j⊕Y);
  • [0088] 5c. send (H_j⊕Y) to core 110 to be ciphered with Key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to core 110);
  • [0089] 5d. In response to a Done signal from core 110, store the ciphered result from core 110 in Y;
  • [0090] 5e. assert signal line TRDY to let the User know to provide the next block of data on signal lines TEXTIN[127:0];}.
• [0091] State #6 (Payload processing). For each payload block P_i, i=1 to i=NP, do this group of actions:
  • [0092] {6a. receive a data block P_i provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0093] 6b. if mode signal Pmode[1:0] indicates manual mode, then load counter block Ctr_i from input lines CTRIN[127:0]; if mode signal Pmode[1:0] indicates automatic mode, then generate counter block Ctr_i with the first 14 bytes from final counter block Ctr_NP and last two bytes equal to the value of the iteration index “i”; counter block Ctr_i can be temporarily stored in register S;
  • [0094] 6c. generate (P_i⊕Y);
  • [0095] 6d. send (P_i⊕Y) to core 110 to be ciphered with key K, and send counter block Ctr_i to core 120 to be ciphered with key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to cores 110 and 120);
  • [0096] 6e. In response to Done signals from cores and 110 and 120, store the ciphered result from core 110 in Y, and store the ciphered result from core 120 in register S;
  • [0097] 6f. generate (P_i⊕S), output (P_i⊕S) on CIPHERTEXTOUT[127:0], and assert signal line TRDY to let the User know that cipher data is present on CIPHERTEXTOUT[127:0], and to let the User know to provide the next block of data on signal lines TEXTIN[127:0];}.
• [0098] State #7 (MIC finalization). Do these actions in a processing cycle:
  • [0099] {7a. send final counter block Ctr₀ to core 120 to be ciphered with key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to core 120);
  • [0100] 7b. in response to a Done signal from core 120, store the ciphered result from core 120 in register S;
  • [0101] 7c. output MIC as (Y⊕S) on signal lines CIPHERMICOUT[127:0] and assert signal line MRDY to let the User know that the MIC is ready; the User may then take only the 64 most significant bits on signal lines CIPHERMICOUT[127:0] to effect the MSB_—64(*) operation;
  • [0102] 7d. go back to State #1 above;}.
• [0103] State #8 (Start of decryption processing, header processing). For each header block H_j, j=1 to j=NH, do this group of actions:
  • [0104] {8a. receive a data block H_j provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0105] 8b. generate (H_j⊕Y);
  • [0106] 8c. send (H_j⊕Y) to core 110 to be ciphered with Key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to core 110);
  • [0107] 8d. in response to Done signal from core 110, store the ciphered result from core 110 in Y;
  • [0108] 8e. assert signal line TRDY to let the User know to provide the next block of data on signal lines TEXTIN[127:0];}.
• [0109] State #9 (Processing of first encrypted payload block C₁). Do these actions in a processing cycle:
  • [0110] {9a. receive first encrypted data block C₁ provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0111] 9b. if mode signal Pmode[1:0] indicates manual mode, then load counter block Ctr₁ from input lines CTRIN[127:0], if mode signal Pmode[1:0] indicates automatic mode, then generate counter block Ctr₁ with first 14 bytes from and last two bytes equal to the value “1”; counter block Ctr₁ can be temporarily stored in register S;
  • [0112] 9c. send counter block Ctr₁ to core 120 to be ciphered with key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD line to core 120);
  • [0113] 9d. In response to Done signal from core 120, store the ciphered result from core 120 in register S;
  • [0114] 6e. generate (C₁⊕S) and store it in a temporary register P_SAVE;
  • [0115] 6f. output (C₁⊕S) on CIPHERTEXTOUT[127:0] as decrypted payload block P₁, and assert signal line TRDY to let the User know that decrypted data is present on CIPHERTEXTOUT[127:0], and to let the User know to provide the next block of data on signal lines TEXTIN[127:0];}.
• [0116] State #10 (Process remaining encrypted payload blocks and continue MIC generation.) For each remaining encrypted payload block C_i, i=1 to i=NP, do the following actions:
  • [0117] {10a. receive next encrypted data block C_i provided on signal lines TEXTIN[127:0] in response to the User asserting signal TEXT_LD;
  • [0118] 10b. if mode signal Pmode[1:0] indicates manual mode, then load counter block Ctr_i from input lines CTRIN[127:0]; if mode signal Pmode[10] indicates automatic mode, then generate counter block Ctr_i with the first 14 bytes from final counter block Ctr_NP and last two bytes equal to the value “i”; counter block Ctr_i can be temporarily stored in register S;
  • [0119] 10c. generate (P_SAVE⊕Y);
  • [0120] 10d. send (P_SAVE⊕Y) to core 110 to be ciphered with key K, and send counter block Ctr_i to core 120 to be ciphered with key K (place data on the appropriate BLOCKIN lines and activate the appropriate LD lines to cores 110 and 120);
  • [0121] 10e. In response to Done signals from core 110 and 120, store the ciphered result from core 110 in register Y; store the ciphered result from core 120 in register S;
  • [0122] 10f. generate (C_i⊕S) and store it in temporary register P_SAVE;
  • [0123] 10e. output (C_i⊕S) on CIPHERTEXTOUT[127:0] as decrypted payload block P₁, and assert signal line TRDY to let the User know that decrypted data is present on CIPHERTEXTOUT[127:0], and to let the User know to provide the next block of data on signal lines TEXTIN[127:0];}.
• [0124] State #11 (MIC authentication).
  • [0125] {11a. Receive MIC to be authenticated on signal lines TEXTIN[127:0];
  • [0126] 11b. generate (P_SAVE⊕Y);
  • [0127] 11c. send (P_SAVE⊕Y) to core 110 to be ciphered with key K, and send final counter block Ctr₀ to core 120 to be ciphered with key K (place data on the gappropriate BLOCKIN lines and activate the appropriate LD lines to cores 110 and 120);
  • [0128] 11d. in response to Done signals from cores 110 and 120, store the ciphered result from core 110 in Y, and store the ciphered result from core 120 in register S;
  • [0129] 11e. output (Y⊕S) on signal lines CIPHERMICOUT[127:0].
  • [0130] 11f. test the received MIC against MSB_—64(Y⊕S); if not the same, assert signal MICFAIL;
  • [0131] 11g. assert signal line MRDY to let the User know that the status of the MICFAIL is ready to be read and the value of the computed text MIC is ready as the 64 most significant bits on signal lines CIPHERMICOUT[127:0];
  • [0132] 11h. go back to State #1 above;}.

[0133] As can be seen above, States 5 through 7 process encryption for both the automatic and manual modes. It may be appreciated that the implementation in each of these states could be simplified if the states handled only one of manual or automatic mode. A simple way to effect this create duplicate states 5′ through 7′ that perform their actions for automatic mode, and then have original states perform their actions for manual mode. Then, state 4 can place controller 130 in state 5 if manual mode have been selected, or state 5′ if automatic mode had been selected. Then same arrangement can be made for states 8-11, with new states 8′-11′ configured to perform their actions for automatic mode and original states 8-11 configured to perform their actions for manual mode. Then, state 4 can place controller 130 in state 8 if manual mode have been selected, or state 8′ if automatic mode had been selected.

[0134] Some examples are now provided for the Automatic Encryption, Automatic Decryption, and Plain modes. FIG. 3 shows the timing diagrams of selected signals for automatic encryption on one block of header and two payload blocks. Num_header is forced to 1, as there is only one header block. CTRFINAL is loaded with a final counter block value. Note that the last two bytes is 0002 indicating that there are two blocks of data in payload. When LD_HEADER is asserted the CTRFINAL and NUM_HEADER is loaded internally. The first TEXT_LD loads the single header block of data. After the MIC AES engine processes this single header block it asserts TRDY. The next Clock cycle the first block of payload data is forced. This block runs through MIC AES engine and CIPHER AES engine. The first Ciphertext is available on TRDY. The last block of payload is then forced. At TRDY the Ciphertext is available. At this point AES core 120 automatically encrypts the MIC generated by AES core 110 and output its on Ciphertext. MIC Ciphertext should be taken when MRDY is asserted. The Immediate TRDY after MRDY indicates that processor 100 is ready for the next set of data.

[0135] FIG. 4 shows the timing diagrams of selected signals for automatic decryption on one block of header and two payload blocks. The process is very much the same as for encryption. In this case the AES core 120 and AES core 110 run back to back, since the Ciphertext is decrypted before processing it through AES core 110 for generating the test MIC. The header portion of the payload is processed in the same way as it was done in encryption. During the phases that process the encrypted payload blocks, the Ciphertext is forced in TEXTIN at each TRDY assertion. After the last Ciphertext data is forced. the MIC Ciphertext to be authenticated should be forced after the assertion of TRDY so that processor 100 can compare the test MIC (the locally generated one) with the MIC Ciphertext received for authentication, and can assert MICFAIL in case the two MICs do not match. MICFAIL is a combinatorial output should be registered at the interface. Alternatively, the user could ignore the MICFAIL input and compare the locally generated MIC Ciphertext and the received MIC. Processor 100 compares only the lower 8 bytes of the MIC Ciphertext.

[0136] FIG. 5 shows the timing diagrams of selected signals for plain mode encryption on one data block. In this Mode, the processor 100 loads the TEXT_IN and gives the Ciphertext on CIPHTEXTOUT output. ENCDECB should be tied high. LD_HEADER should be low. TRDY indicates that the Ciphertext is available on the CIPHTEXTOUT.

[0137] While the present inventions have been particularly described with respect to the illustrated embodiments, it will be appreciated that various alterations, modifications and adaptions may be made based on the present disclosure, and are intended to be within the scope present inventions. While the inventions has been described in connection with what are presently considered to be the most practical and preferred embodiments, it is to be understood that the present inventions are not limited to the disclosed embodiments but, on the contrary, are intended to cover various modifications and equivalent arrangements included within the scope of the appended claims.