Secure bitstream authentication

Abstract

Methods and systems are provided for securely authenticating data of an integrated circuit. By authenticating data having keystream blocks inserted between ciphertext portions, it becomes more difficult to mount successful authentication-based attacks.

Claims

1. A method of authenticating data, the method comprising: interleaving, using interleaving circuitry, a plurality of ciphertext frames with a plurality of keystream portions, to generate a plurality of interleaved frames, wherein each interleaved frame from among the plurality of interleaved frames comprises a respective ciphertext frame from among the ciphertext frames combined with a respective keystream portion from among the plurality of keystream portions; and performing, using authentication circuitry, an authentication operation on the plurality of generated interleaved frames to generate an authentication value, wherein the authentication value authenticates the plurality of ciphertext frames; wherein the method is performed in a programmable device, and wherein the data being authenticated comprises configuration data that configures one or more programmable devices.

2. The method of claim 1, wherein the authentication value comprises a stream authentication tag that authenticates a stream comprising the plurality of ciphertext frames.

3. The method of claim 1, comprising generating, for at least one interleaved frame, a frame authentication tag, wherein the frame authentication tag is generated based on a combination of the ciphertext portion of the interleaved frame and the ciphertext portion of another interleaved frame.

4. The method of claim 2, wherein the plurality of ciphertext frames is authenticated in response to validating the stream authentication tag and validating each frame authentication tag of a plurality of frame authentication tags corresponding to a respective one of the ciphertext frames.

5. The method of claim 3, wherein the frame authentication tag is used one-element-at-a-time to scramble a key value used to authenticate a subsequent ciphertext frame.

6. The method of claim 1, wherein decrypting one ciphertext frame of the plurality of ciphertext frames is delayed until a frame authentication tag for another one of the ciphertext frames has been validated.

7. A system for authenticating data, the system comprising: interleaving circuitry that interleaves a plurality of ciphertext frames with a plurality of keystream portions, to generate a plurality of interleaved frames, wherein each interleaved frame from among the plurality of interleaved frames comprises a respective ciphertext frame from among the plurality of ciphertext frames combined with a respective keystream portion from among the plurality of keystream portions; authentication circuitry that performs an authentication operation on the plurality of generated interleaved frames to generate an authentication value, wherein the authentication value authenticates the plurality of ciphertext frames; and a programmable portion, wherein the data being authenticated comprises a configuration bitstream that programs the programmable portion of one or more programmable devices.

8. The system of claim 7, wherein the authentication value comprises a stream authentication tag that authenticates a stream comprising the plurality of ciphertext frames.

9. The system of claim 7, wherein the interleaving circuitry generates, for at least one interleaved frame, a frame authentication tag, wherein the frame authentication tag is generated based on a combination of the ciphertext portion of the interleaved frame and the ciphertext portion of another interleaved frame.

10. The system of claim 8, wherein the plurality of ciphertext frames is authenticated in response to validating the stream authentication tag and validating each frame authentication tag of a plurality of frame authentication tags corresponding to a respective one of the ciphertext frames.

11. The system of claim 9, wherein the frame authentication tag is used one-element-at-a-time to scramble a key value used to authenticate a subsequent ciphertext frame.

12. The system of claim 7, wherein decrypting one ciphertext frame of the plurality of ciphertext frames is delayed until a frame authentication tag for another one of the ciphertext frames has been validated.

13. The system of claim 7, comprising a programmable portion, wherein the data being authenticated comprises a configuration bitstream programs the programmable portion.

14. A method for authenticating data, the method comprising: de-interleaving a plurality of ciphertext frames to extract an authentication tag; interleaving, using interleaving circuitry, the de-interleaved plurality of ciphertext frames with a plurality of keystream portions, to generate a plurality of interleaved frames, wherein each interleaved frame from among the plurality of interleaved frames comprises a respective ciphertext frame from among the plurality of ciphertext frames combined with a respective keystream portion from among the plurality of keystream portion; authenticating, using authentication circuitry, the interleaved frames to generate a signature tag; comparing the signature tag with the extracted authentication tag; and in response to the signature tag matching the extracted tag, decrypting the ciphertext frames; wherein the method is performed in a programmable device, and wherein the data being authenticated comprises configuration data that configures one or more programmable devices.

15. The method of claim 14, wherein authenticating the interleaved frames to generate the signature tag comprises generating, for at least one interleaved frame of the plurality of interleaved frames, a frame authentication tag, wherein the frame authentication tag is generated based on a combination of the ciphertext portion of the interleaved frame of the plurality of interleaved frames and the ciphertext portion of another interleaved frame of the plurality of interleaved frames.

16. The method of claim 14, wherein the keystream portions are generated based on a constant value.

17. The method of claim 14, wherein the keystream portions are generated based on a previous signature tag.

18. The method of claim 14, wherein decrypting one ciphertext frame of the plurality of ciphertext frames is delayed until a frame authentication tag for another one of the ciphertext frames has been validated.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Further features of the invention, its nature and various advantages will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

(2) FIG. 1 shows an exemplary block diagram of a programmable device as an example of an integrated circuit device in which embodiments of the present invention may be implemented;

(3) FIG. 2 is an exemplary block diagram representing a known authentication operation;

(4) FIG. 3 is an exemplary block diagram representing stream authentication operations according to some embodiments;

(5) FIG. 4 is an exemplary block diagram representing frame authentication operations according to some embodiments;

(6) FIG. 5 shows an exemplary interleaving/de-interleaving process for processing data according to some embodiments;

(7) FIG. 6 shows another exemplary interleaving/de-interleaving process for processing data according to some embodiments;

(8) FIG. 7 shows another exemplary interleaving/de-interleaving process for processing data according to some embodiments;

(9) FIG. 8 shows another exemplary interleaving/de-interleaving process for processing data according to some embodiments; and

(10) FIG. 9 shows another exemplary interleaving/de-interleaving process for processing data according to some embodiments.

DETAILED DESCRIPTION OF THE INVENTION

(11) FIG. 1 shows an exemplary block diagram of a programmable device 100 as an example of an integrated circuit device in which embodiments of the present invention may be implemented. An external memory 120 contains configuration data, typically including proprietary designs, that is used to configure the functionality of the device 100. The configuration data is merely one example of data which an owner desires to secure. The configuration of device 100 may occur upon powering up the device, rebooting the device, reconfiguring the device during its operation, or at some other re-programming time. For example, upon powering up, the configuration data may be sent from the external memory 120 to the device 100. The configuration data may be stored in external memory 120 in encrypted and/or authenticated form. For example, the configuration data may be encrypted in order to prevent copying when the data is in storage and/or in transit, e.g., using an encryption/authentication system 122. The configuration data may be authenticated in order to verify that data has not been tampered with, using encryption/authentication system 122.

(12) Encryption/authentication system 122 is merely one example of a system that may be used for carrying out encryption and/or authentication operations disclosed herein, and it should be understood that other configurations are possible without departing from the scope of this disclosure. For example, encryption/authentication system 122 may be implemented in software and/or hardware, using any suitable configuration. In some implementations, encryption/authentication system 122 may be implemented as a standalone encryption system and/or a standalone authentication system that may or may not be coupled. Also, although encryption/authentication system 122 is shown as external to both the memory 120 and device 100, at least parts of encryption/authentication system 122 may be internal to or implemented on either one of the memory 120 and device 100, or may be placed between external memory 120 and device 100 without departing from the scope of this disclosure.

(13) The encrypted/authenticated data stored in external memory 122 is sent to device 100 where it is decrypted/authenticated by a decryption/authentication system 102. The decrypted/authenticated data may then be optionally stored, e.g., in configuration data memory 104. Like encryption/authentication system 122, decryption/authentication system 102 may be implemented in software and/or hardware.

(14) The configuration data is used to configure the functionality of programmable blocks 106. After configuration, the blocks may start operating on input data according to the configuration bitstream. When in operation, the configurable blocks may store internal data, e.g., in data registers, RAM, or other suitable storage. This internal data may reflect specific aspects of the configuration data. For example, in some devices, the internal data may reflect proprietary aspects of the circuit design that the designer may desire to keep secret.

(15) In some embodiments, the security of authentication operations may be increased using various types of interleaving functions and/or de-interleaving functions. These functions may be carried out in interleaver 124 of encryption/authentication system 122 and/or de-interleaver 108 in decryption/authentication system 102. Details of these operations will be disclosed further below.

(16) In some embodiments, the configuration data (in plaintext form) may be encrypted using an encryption cryptographic system that applies a cryptographic algorithm, similar to encryption/authentication system 122. The decryption/authentication system 102 may then decrypt the encrypted data (i.e., ciphertext) using a corresponding decryption cryptographic system that applies the same cryptographic algorithm.

(17) FIG. 2 illustrates a known authentication technique using a commonly known cryptographic algorithm AES and a commonly known authentication algorithm HMAC. This technique may be implemented, for example, in encryption/authentication system 122 of FIG. 1.

(18) The common cryptographic algorithm of FIG. 2, AES, is a symmetric key block cipher algorithm adopted by the Department of Commerce, National Institute of Standards and Technology (NIST). (See detailed specification in Federal Information Processing Standards Publication 197 (FIPS 197), of Nov. 26, 2001.) The AES algorithm uses cryptographic keys of 128, 192 and 256 bits to encrypt and decrypt data in blocks of 128 bits. The algorithm iterates a number of nearly identical rounds depending on key length and block size. AES128 uses 10 rounds (N=10), AES192 uses 12 rounds (N=12) and AES256 uses 14 rounds (N=14) to complete an encryption or decryption operation.

(19) FIG. 2 illustrates three illustrative encryption operations 210, 211, and 213 for a first, second, and last plaintext blocks, respectively. According to these operations of FIG. 2, plaintext blocks {P.sub.0, P.sub.1, . . . , P.sub.N-1} are respectively combined (e.g., XOR-ed) with round keys {K.sub.0, K.sub.1, . . . , K.sub.N-1} to generate ciphertext blocks {C.sub.0, C.sub.1, . . . , C.sub.N-1}. N may refer to the number of rounds of the particular AES implementation.

(20) The common authentication algorithm of FIG. 2, NIST HMAC, is based on a hash function such as a NIST SHA2. The HMAC algorithm may be used to authenticate data such as ciphertext blocks {C.sub.0, C.sub.1, . . . , C.sub.N-1}, by generating a tag 250 that may be added to the end of the ciphertext blocks {C.sub.0, C.sub.1, . . . , C.sub.N-1} as authentication block C.sub.N. The authentication tag 250 may be based on a private authentication key 260 that, in some cases, is programmed into the device 100. The device 100 may then use its programmed private authentication key to verify that the authentication tag 250 is valid for the ciphertext blocks {C.sub.0, C.sub.1, . . . , C.sub.N-1}, and thereby confirm that these blocks {C.sub.0, C.sub.1, . . . , C.sub.N-1} have not been tampered with. For example, device 100 may generate its own authenticating tag C.sub.N.sup.DECRYPT and decrypt data only in response to C.sub.N.sup.DECRYPT matching C.sub.N. Such a matching tag is referred to as a valid authentication tag.

(21) Although the remainder of this specification will mainly discuss the HMAC embodiment, it should be understood that embodiments of the invention described herein are applicable to other authentication algorithms as well as to other cryptographic algorithms and modes of operation. As such, discussing the embodiments with respect to HMAC is meant for the purposes of illustration not limitation. Furthermore, although the remainder of this specification will mainly discuss the AES embodiment, it should be understood that embodiments of the invention described herein are applicable to other key lengths and block sizes as well as to other cryptographic algorithms and modes of operation. As such, discussing the embodiments with respect to AES cryptographic algorithm is meant for the purposes of illustration not limitation.

(22) Systems and methods discussed herein may prevent or increase the difficulty for an attacker to spoof authentication tags, e.g., to append a valid authentication block E.sub.N to an unauthorized ciphertext stream {E.sub.1, E.sub.2, . . . , E.sub.N-1}. A valid authentication block E.sub.N will be referred to as a valid spoofed authentication tag, and the combination of the unauthorized ciphertext stream with the tag {E.sub.1, E.sub.2, . . . , E.sub.N-1, E.sub.N} will be referred to as a spoofed frame.

(23) In one aspect, embodiments of the present disclosure may increase the number of side-channel attacks required by an attacker to generate a valid spoofed authentication tag or a valid spoofed frame. Instead of simply authenticating ciphertext blocks as shown in FIG. 2, systems and methods described herein may interleave keystream blocks at one or more positions of a ciphertext stream. A keystream as used herein is a stream of elements, in general random or pseudo-random, that may be combined (e.g., XORed) with a plaintext block to produce a ciphertext block. These elements may be represented by bits, bytes, numbers, letters, characters, or any suitable symbol depending on the implementation. A keystream block is any suitable group of such elements.

(24) By interleaving keystream blocks, systems and methods described herein may effectively change the authentication key (i.e., rekey) the authentication algorithm after processing each portion of the data to be authenticated. In this way, mounting successful attacks may require the attacker to trigger each of multiple portions of the data to be authenticated, and not just a single authentication tag. Furthermore, attacks such as spoofing a ciphertext frame may require the attacker to trigger the authentication tag for every spoofed frame. Thus, even if the attacker is able to mount a successful attack against one ciphertext frame, he or she may still fail to create multiple spoofed frames.

(25) FIG. 3 is an exemplary block diagram representing stream authentication operation 300 according to some embodiments. The authentication operation 300 may be used to protect a stream of ciphertext blocks C.sub.i,j (i=0, . . . , f; j=0, . . . , N1) against an authentication-based attack. Authentication operation 300 may be performed by an authentication system similar to encryption/authentication system 122 of FIG. 1.

(26) Blocks of data may be grouped to form one or more frames. For the purposes of illustration, the rest of this disclosure will mainly discuss frames having the same number of blocks per frame, e.g., ciphertext frames having N ciphertext blocks per frame and interleaved frames having N ciphertext blocks and 1 keystream block per frame. However, it should be understood that these frames may be of different length and/or contain data portions of any suitable size or type without departing from the scope of this disclosure.

(27) FIG. 3 depicts two illustrative interleaved frames of interleaved stream 390: Interleaved Frame 0 (labeled 301-0) and Interleaved Frame F (labeled 301-F). Illustrative Interleaved Frame 0 has N ciphertext blocks C.sub.0,0 through C.sub.0,N-1 (corresponding to Ciphertext Frame 0) combined with keystream block K.sub.0,N. Similarly, Interleaved Frame F has N ciphertext blocks C.sub.f,0 through C.sub.f,N-1 (corresponding to Ciphertext Frame 1) combined with keystream block K.sub.f,N. The ciphertext frames (e.g., Ciphertext Frame 0 and Ciphertext Frame 1) may have been generated from plaintext as described above, or in any suitable way.

(28) Although each interleaved frame has one keystream block appended at the end of the frame, it should be understood that different numbers and different positions of the keystream block relative to the ciphertext frame may be used without departing from the scope of the disclosure.

(29) As illustrated in FIG. 3, keystream blocks K.sub.i,N (i=0, . . . , f) are inserted among the ciphertext blocks. In some implementations, the keystream blocks K.sub.i,N are internal to device 100, and are not part of the bitstream. For example, the keystream blocks K.sub.i,N may be completely independent of the plaintext stream or of its corresponding ciphertext stream.

(30) According to some embodiments, an authentication algorithm, e.g., HMAC, is run on the interleaved stream 390, which includes the combination of ciphertext blocks C.sub.i,j (i.e., the ciphertext stream 392) interleaved with keystream blocks K.sub.i,N. The authentication algorithm may use an internal authentication key 360 to run the authentication operations. By processing the interleaved stream 390, the authentication algorithm generates a stream authentication tag 350. A stream tag herein refers to an authentication value corresponding to multiple frames. In the illustrative case of FIG. 3, stream authentication tag 350 is a stream-level authentication value that authenticates interleaved stream 390. For example, the input to the authentication algorithm may include all the blocks of each frame i (i=0, . . . , f), including all ciphertext and all keystream blocks up to that frame. By interleaving keystream blocks with ciphertext blocks in this manner, the authentication algorithm is effectively rekeyed after processing every frame using the hidden keystream block as an authentication key.

(31) FIG. 4 is an exemplary block diagram representing frame authentication operations 400 according to some embodiments. FIG. 4 illustrates such operations on one exemplary data frame i. In some implementations, frame authentication operations 400 may be performed as part of, instead of, or in addition to stream authentication operations 300 of FIG. 3. It should be understood that the operations described with reference to FIG. 4 may apply to any number of frames i (i0) without departing from the scope of this disclosure. Authentication operation 400 may be performed by authentication circuitry similar to encryption/authentication system 122 of FIG. 1.

(32) In FIG. 4, ciphertext blocks C.sub.i,0, C.sub.i,1, . . . , C.sub.i,N-1 are generated by encrypting plaintext blocks P.sub.i,0, P.sub.i,1, P.sub.i,N-1, respectively, using keystream blocks K.sub.i,0, K.sub.1,N-1. These operations are illustrated as 410, 411, and 413, respectively.

(33) Keystream block K.sub.i,N is inserted at the end of the ciphertext frame 421 to create an interleaved frame 423, e.g., as described with reference to FIG. 3 above. In some embodiments, an encrypted intermediate frame authentication tag C.sub.i,N (labeled 470) is generated and may be added at the end of interleaved frame 423 to generate an authenticated interleaved frame 425. This operation may be done for each of multiple frames i of a ciphertext stream similar to ciphertext stream 392 of FIG. 3. In this way, authenticating a ciphertext stream may involve confirming not only that the stream authentication tag is valid, but also that each frame authentication tag C.sub.i,N for each frame i is valid.

(34) As illustrated in FIG. 4, the frame authentication tag C.sub.i,N is generated by encrypting the value of frame authentication tag 450, as shown by operation 414. The frame authentication tag 450 may be computed based on ciphertext blocks included not only in frame i, but also in one or more previously authenticated frames i (i<i). For example, the frame authentication tag 450 may be computed based on ciphertext blocks of the ciphertext stream up to the end of frame i. An exemplary computation of frame authentication tag 450 is discussed below.

(35) In the implementation illustrated in FIG. 4, frame authentication tag 450 is generated from computing a hash value H.sub.i (labeled 402) as follows,
H.sub.i=HASH(H.sub.i-1,C.sub.i,0,C.sub.i,1, . . . ,C.sub.i,N-1,K.sub.i,N).
Because the computation of involves the hash H.sub.i-1 of the previous frame i1, the value of the frame authentication tag 450 (and its encrypted value 470) may depend not only on the interleaved frame 423, but also on one or more previous frames, e.g., frame i1. In one implementation, in order for a ciphertext stream {C.sub.0,0, C.sub.0,1, C.sub.0,N-1, . . . , C.sub.f,0, C.sub.f,1, . . . , C.sub.f,N-1} to be authenticated, each of the individual frame tags C.sub.i,N (i=0, f) must be valid, as well as the stream-level authentication tag, e.g., HMAC(C.sub.0,0, C.sub.0,1, . . . , C.sub.0,N-1, K.sub.0,N . . . , C.sub.f,0, C.sub.f,1, . . . , C.sub.f,N-1, K.sub.f,N).

(36) In some embodiments, the encrypted frame authentication tag may be used one-bit-at-a-time to scramble the keys used to encrypt or authenticate subsequent frames. One-bit-at-a-time scrambling operations are described in U.S. application Ser. No. 14/025,697, filed Sep. 12, 2013, entitled SECURE VARIABLE SCRAMBLING, the content of which is incorporated by reference in its entirety.

(37) In some embodiments, decrypting a ciphertext portion of a frame may be delayed until a subsequent frame has been authenticated. For example, combining the ciphertext portion and the keystream portion for a frame i for the purpose of determining the corresponding plaintext of that frame i may be delayed until the frame authentication tag for a subsequent frame i+1 has been validated.

(38) Systems and methods using frame authentication described herein may increase security of integrated circuits against authentication-based attacks. Because spoofing the frame authentication tag for a frame i will generally scramble the key used to encrypt the frame authentication tag of the subsequent frame (e.g., by affecting hash value H.sub.i), spoofing a frame may require mounting two successful attacks against two authentication tags, the frame tag for the spoofed frame and the encrypted tag for the subsequent frame.

(39) Even if an attacker successfully spoofs a single pair of authentication tags, systems and methods using frame authentication described herein may prevent him or her from creating multiple, other spoofed frames from the spoofed pair of authentication tags. This is because each spoofed frame may now require making other separate, successful attacks on the frame authentication tag of the subsequent frame in order to generate additional spoofed frames.

(40) Several aspects of interleaving/de-interleaving are envisioned in this disclosure. In one aspect, interleaving of data occurs when data is encrypted, e.g., before the configuration data of FIG. 1 is ever stored in external memory 120. Such interleaving is usually performed by a software tool, though it may also be implemented, at least in part, in hardware.

(41) According to this aspect of interleaving, the interleaving process includes encrypting the plaintext to create ciphertext, interleaving the ciphertext with keystream data, authenticating the interleaved ciphertext and keystream data to compute an encrypted authentication tag, and then interleaving the ciphertext with the resulting encrypted authentication tag (which may replace the previously interlaced keystream data). Embodiments of this process are shown in FIGS. 5 and 8, described in detail below.

(42) FIG. 5 shows an exemplary interleaving process 500 for processing data according to some embodiments. In some embodiments, process 500 may be implemented by software, such as the one represented by interleaver block 124 and encryption/authentication system 122 of FIG. 1. In some embodiments, process 500 may also or in addition be implemented by hardware.

(43) Process 500 processes and generates data, similar to plaintext blocks, ciphertext blocks and/or keystream blocks of FIGS. 3 and/or 4. Process 500 may be performed in a programmable logic device such an FPGA and/or PLD, for encrypting/authenticating data comprising configuration bitstream. Process 500 may also be implemented in any integrated circuit including ASSP, an ASIC, a full-custom chip, and/or a dedicated chip.

(44) Plaintext 502 is encrypted at 504 to generate ciphertext data 505. For example, plaintext blocks P.sub.i,j=0 . . . N-1, such as those of FIG. 4, are encrypted at 504 to generate corresponding ciphertext blocks C.sub.i,j=0 . . . N-1. The encrypt operation block 504 (and other encryption operations described herein) could use any suitable encryption operation and any mode of encryption, such as but not limited to, NIST Counter Mode or a cipher block chaining (CBC) Mode. For example, although FIGS. 1 and 2 discuss Counter Mode, this is for the purpose of illustration not limitation, and any suitable mode of encryption, implemented in software and/or hardware, may be used without departing from the scope of this disclosure.

(45) A constant value 506 is encrypted at 508 to generate keystream data 509. For example, the constant value may be a random or pseudo-random seed value, or may be provided by the user. Keystream data 509 may include keystream block K.sub.i,N, which may be similar to keystream block K.sub.i,N of FIG. 4.

(46) The ciphertext data 505 and keystream data 509 are interleaved at 510. The interleaving operation block 510 may be implemented in software and/or hardware, and may be implemented using any suitable circuitry, such as multiplexors, logic gates, buffers, shifters, etc. This first interleaving generates interleaved ciphertext and keystream data, e.g., similar to interleaved ciphertext frame 423 of FIG. 4.

(47) The interleaved ciphertext and keystream data is authenticated at 512 to generate an authentication frame tag T.sub.i, e.g., similar to frame authentication tag 450 of FIG. 4.

(48) The frame authentication tag T.sub.i is optionally encrypted at 514 to generate an encrypted authentication tag, e.g., similar to encrypted frame authentication tag C.sub.i,N 470 of FIG. 4.

(49) The ciphertext data 505 output from encryption operation block 504 and the (optionally encrypted) authentication tag output from authentication operation block 512 are interleaved at 516. This second interleaving may be implemented similarly to the first interleaving. This second interleaving generates authenticated interleaved ciphertext data C.sub.i,j=0 . . . N, e.g., similar to authenticated interleaved ciphertext frame 425 of FIG. 4. As a result, the second interleaving at 516 replaces the keystream data that was previously interlaced by the first interleaving at 510. Finally, the second interleaving generates authenticated interleaved data that corresponds to the authenticated encrypted form of plaintext 502, in the form of ciphertext 518.

(50) According to another interleaving/de-interleaving aspect, interleaving of data occurs when data is decrypted, e.g., by decryption/authentication system 102 of FIG. 1. According to some embodiments of this aspect, an authentication tag is extracted (or de-interleaved) from an authenticated interleaved ciphertext and replaced with keystream data. The combined ciphertext and keystream data is then authenticated by generating an authentication signature. The resulting authentication signature is compared with the decrypted authentication tag. If the authentication signature matches the authentication tag (i.e., the ciphertext is determined to be authentic), then the ciphertext is de-interleaved from the keystream data and decrypted into plaintext. Embodiments of this aspect are illustrated in FIGS. 6, 7, and 9, described in detail below.

(51) Operations related to this aspect of interleaving/de-interleaving are generally implemented in hardware such as the one represented by decryption/authentication system 102 of FIG. 1, though they may also be implemented at least in part in software without departing from the scope of this disclosure.

(52) FIG. 6 shows an exemplary interleaving process 600 for processing data according to some embodiments. Process 600 may be implemented in an encryption/decryption system (software and/or hardware) similar to de-interleaver 108 and/or decryption/authentication system 102 of FIG. 1.

(53) Process 600 processes and generates blocks data, similar to plaintext blocks, ciphertext blocks and/or keystream blocks of FIGS. 3 and/or 4. Process 600 may be performed in a programmable logic device such an FPGA and/or PLD, for decrypting/authenticating data comprising configuration bitstream. Process 600 may also be implemented in any integrated circuit including ASSP, an ASIC, a full-custom chip, and/or a dedicated chip.

(54) Ciphertext 602 is de-interleaved at 604 to extract authentication data C.sub.i,N and ciphertext data C.sub.i,j=0 . . . N-1. For example, an authenticated interleaved frame similar to frame 425 of FIG. 4 is de-interleaved at 604 to extract ciphertext blocks C.sub.i,j=0 . . . N-1 and an authentication tag. The authentication tag may be similar to stream authentication tag 350 of FIG. 3, encrypted frame authentication tag C.sub.i,N 470 of FIG. 4, or frame authentication tag T.sub.i,N 450 of FIG. 4.

(55) If the implementation of process 600 generates an encrypted authentication tag 605, then an optional decryption operation block 612 decrypts the authentication tag 605 to generate an unencrypted authentication tag T.sub.i,N 613.

(56) The ciphertext blocks C.sub.i,j=0 . . . N-1 are interleaved at 614 with keystream blocks 607 to generate combined ciphertext and keystream data. The keystream data may be generated similarly to process 500 of FIG. 5, e.g., by encrypting (at 610) a constant value 608 to generate keystream data 607. Keystream data 509 may include keystream block K.sub.i,N, which may be similar to keystream block K.sub.i,N of FIG. 4.

(57) The interleaved combination of ciphertext and keystream data is authenticated at 616 by generating a ciphertext signature tag 617, using, e.g., HMAC or any suitable authentication function.

(58) Comparison operation block 618 validates the signature tag, based on comparing:

(59) (1) the decrypted authentication tag 613, extracted from the ciphertext based on the de-interleaving operation at 604; and

(60) (2) the ciphertext signature tag 617, generated based on the interleaving operation at 614.

(61) If the ciphertext signature tag 617 matches the decrypted authentication tag 613, then the ciphertext is determined to be authentic and is decrypted at 620 to generate plaintext 622. If the ciphertext signature tag 617 does not match the decrypted authentication tag 613, then no decryption may be performed.

(62) In some embodiments, rather than comparing the decrypted authentication tag 613 and the ciphertext signature tag 617, the encrypted authentication tag and an encrypted version of the ciphertext signature tag may be compared. FIG. 7 illustrates such a variant. In particular, FIG. 7 illustrates process 700, which is similar to process 600 of FIG. 6, but the (optional) decryption block 612 of FIG. 6 is replaced with an (optional) decryption block 712 in FIG. 7. In this way, the comparison operation block 718 of process 700 validates the signature tag, based on comparing:

(63) (1) the encrypted authentication tag 705, extracted from the ciphertext based on de-interleaving at 704; and

(64) (2) the encrypted ciphertext signature tag 713, generated based on encrypting (at 712) the result of interleaving (at 714) the ciphertext data 706 with the keystream data 707.

(65) In some embodiments, keystream data may be generated using a variable instead of a constant (e.g., such as constants 506 of FIG. 5, 608 of FIG. 6, and 708 of FIG. 7). The variable may be a value generated by the process in a previous round, during an encryption, decryption, authentication, interleaving, de-interleaving, or any other suitable operation. FIGS. 8 and 9 illustrate such a case.

(66) In particular, FIG. 8 depicts a process 800 which is similar to process 500 of FIG. 5, but generates keystream data in a different way. Rather than using constant 506 to generate the keystream data 509 as in process 500 of FIG. 5, process 800 uses a variable which may have been generated as an output from encrypting or authentication a previous frame or a previous block. In the example of FIG. 8, the unencrypted authentication tag T.sub.i-1 for frame i1, output at 813, is fed back as input variable 815 to the encryption block 808 when computing the keystream data for frame i.

(67) FIG. 9 depicts a process 900 which is similar to processes 600 and 700 of FIGS. 6 and 7, respectively (omitting the optional decryption block 612 and encryption block 712 for clarity). One difference between process 900 and processes 600/700 is that process 900 generates keystream data from encrypting an authentication signature, such as the unencrypted authentication signature T.sub.i-1 919, which may have been generated as output 917 from encrypting or authenticating a previous frame or a previous block.

(68) It will be understood that the above steps of processes 500, 600, 700, 800, and 900 of FIGS. 5, 6, 7, 8, and 9, respectively, may be executed or performed in any order or sequence not limited to the order and sequence shown and described in the figure. Also, some of the above steps of these processes may be executed or performed substantially simultaneously where appropriate or in parallel to reduce latency and processing times.

(69) Although embodiments of this disclosure discuss a software implementation of a first aspect of interleaving (that generates authenticated interleaved encrypted data) and a hardware implementation of a second aspect of interleaving (that checks the authenticity of interleaved data), this is for the purpose of limitation not limitation and any suitable hardware and/or software implementation may be used without departing from the scope of this disclosure.

(70) The encryption/authentication operation implementations described herein may belong to a single processing device or a plurality of processing devices. Such an implementation may have a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on hard coding of the circuitry and/or operational instructions.

(71) It will be understood that the foregoing is only illustrative of the principles of the invention, and that various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention. For example, the various elements of this invention can be provided on a device in any desired number and/or arrangement. One skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration and not of limitation, and the present invention is limited only by the claims that follow.