U.S. patent application number 16/387286 was filed with the patent office on 2020-07-30 for differential power analysis resistant encryption and decryption functions.
The applicant listed for this patent is Altera Corporation. Invention is credited to Bruce B. Pedersen.
Application Number | 20200244434 16/387286 |
Document ID | 20200244434 / US20200244434 |
Family ID | 1000004765316 |
Filed Date | 2020-07-30 |
Patent Application | download [pdf] |
![](/patent/app/20200244434/US20200244434A1-20200730-D00000.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00001.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00002.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00003.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00004.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00005.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00006.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00007.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00008.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00009.png)
![](/patent/app/20200244434/US20200244434A1-20200730-D00010.png)
View All Diagrams
United States Patent
Application |
20200244434 |
Kind Code |
A1 |
Pedersen; Bruce B. |
July 30, 2020 |
DIFFERENTIAL POWER ANALYSIS RESISTANT ENCRYPTION AND DECRYPTION
FUNCTIONS
Abstract
Circuits, methods, and systems are provided for securing an
integrated circuit device against Differential Power Analysis (DPA)
attacks. Plaintext (e.g., configuration data for a programmable
device) may be encrypted in an encryption system using a
cryptographic algorithm. Ciphertext may be decrypted in a
decryption system using the cryptographic algorithm. The encryption
and/or decryption systems may obfuscate the plaintext, the
ciphertext, and/or the substitution tables used by the
cryptographic algorithm. The encryption and/or decryption systems
may also generate cryptographic key schedules by using different
keys for encrypting/decrypting different blocks and/or by expanding
round keys between encryption/decryption blocks. These techniques
may help mitigate or altogether eliminate the vulnerability of
cryptographic elements revealing power consumption information to
learn the value of secret information, e.g., through DPA.
Inventors: |
Pedersen; Bruce B.;
(Sunnyvale, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Altera Corporation |
San Jose |
CA |
US |
|
|
Family ID: |
1000004765316 |
Appl. No.: |
16/387286 |
Filed: |
April 17, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15139071 |
Apr 26, 2016 |
10320554 |
|
|
16387286 |
|
|
|
|
13098315 |
Apr 29, 2011 |
9331848 |
|
|
15139071 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 9/003 20130101;
H04L 9/0631 20130101; G09C 1/00 20130101; H04L 2209/24 20130101;
H04L 9/0637 20130101; H04L 2209/16 20130101; H04L 2209/04
20130101 |
International
Class: |
H04L 9/00 20060101
H04L009/00; H04L 9/06 20060101 H04L009/06; G09C 1/00 20060101
G09C001/00 |
Claims
1-20. (canceled)
21. A system, comprising: an electronic device to generate an
encrypted bitstream to configure a field programmable gate array
(FPGA), wherein the electronic device is operable to: encrypt a
first block of an unencrypted bitstream based on a first key to
generate a first encrypted block of the encrypted bitstream;
encrypt a second block of the unencrypted bitstream based on a
second key to generate a second encrypted block of the encrypted
bitstream; and encrypt a third block of the unencrypted bitstream
based on a third key to generate a third encrypted block of the
encrypted bitstream; and the FPGA, wherein the FPGA is operable to
receive the encrypted bitstream and use an internal decryption
engine to: decrypt the first encrypted block based on the first
key; obtain the second key based on the decryption of the first
encrypted block; decrypt the second encrypted block based on the
second key; obtain the third key based on the decryption of the
second encrypted block; and decrypt the third encrypted block based
on the third key.
22. The system of claim 21, wherein the encrypted bitstream is
stored in an off-chip memory prior to sending the encrypted
bitstream to the FPGA.
23. The system of claim 21, wherein the FPGA stores the first key
in an on-chip memory of the FPGA.
24. The system of claim 21, wherein the internal decryption engine
decrypts using an Advanced Encryption Standard (AES) algorithm.
25. The system of claim 21, wherein the first key, the second key,
and the third key are different from one another.
26. The system of claim 21, wherein the encrypted bitstream results
in a disabled readback of configuration.
27. The system of claim 21, wherein the first key comprises a
user-supplied key.
28. The system of claim 21, wherein the first key is
obfuscated.
29. The system of claim 21, wherein the decrypted first block, the
decrypted second block, the decrypted third block, or a combination
thereof, are stored as configuration data in configuration memory
of the FPGA.
30. The system of claim 29, wherein the configuration data is used
to configure the FPGA.
31. The system of claim 21, wherein the first key is a symmetric
key enabling access to the encrypted bitstream.
32. A field programmable gate array (FPGA) configured to receive a
plurality of blocks of an encrypted bitstream, the FPGA comprising:
a plurality of configurable logic blocks; a decryption engine
configured to: decrypt a first block of the plurality of blocks,
wherein decrypting the first block is based on a first key; and
decrypt successive blocks of the plurality of blocks using
successive keys, wherein the successive keys are determined based
on a previously decrypted block of the plurality of blocks; and
configuration memory configured to store at least part of the
decrypted first block, the decrypted successive blocks, or some
combination thereof, as configuration data, wherein the
configuration data configures the plurality of configurable logic
blocks of the FPGA.
33. The FPGA of claim 32, wherein the plurality of blocks are
stored in an external memory device separate from the FPGA before
decryption by the decryption engine.
34. The FPGA of claim 32, wherein the first key is stored on an
on-chip memory of the FPGA.
35. The FPGA of claim 32, wherein the decrypting comprises using an
Advanced Encryption Standard (AES) algorithm.
36. The FPGA of claim 32, wherein the successive keys are unique
keys.
37. A method for configuring a field programmable gate array (FPGA)
with an encrypted bitstream, comprising: partitioning an
unencrypted bitstream into a plurality of blocks; encrypting a
first block of the plurality of blocks based on a first key;
encrypting successive blocks of the plurality of blocks based on
successive keys; transmitting the encrypted plurality of blocks to
a decryption engine to decrypt the encrypted plurality of blocks;
direct a decryption of the first block based on the first key; and
direct a decryption of the successive blocks based on the
successive keys, wherein the successive keys are determined based
on a decryption of a previously encrypted block of the successive
blocks.
38. The method of claim 37, wherein the first key is stored in an
on-chip memory of the FPGA.
39. The method of claim 37, wherein the decrypted first block, the
decrypted successive blocks, or a combination thereof, are stored
as configuration data in configuration memory of the FPGA.
40. The method of claim 39, wherein the configuration data is used
to configure the FPGA.
Description
FIELD OF THE INVENTION
[0001] This invention relates to methods and systems for securing
the programming data of a programmable device--e.g., a
field-programmable gate array (FPGA) or other programmable logic
device (PLD)--against power analysis attacks, and to a programmable
device so secured.
BACKGROUND OF THE INVENTION
[0002] Programmable devices are well known. In one class of known
PLDs, each device has a large number of logic gates, and a user
programs the device to assume a particular configuration of those
logic gates, typically by receiving configuration data from a
configuration device. Configuration data has become increasingly
complex in modern PLDs. As such, proprietary configuration data for
various commonly-used functions (frequently referred to as
"intellectual property cores") have been sold either by device
manufacturers or third parties, freeing the original customer from
having to program those functions on its own. If a party provides
such proprietary configuration data, it may want to protect this
data from being read, as well as any internal data that may reveal
the configuration data.
[0003] Commonly-assigned U.S. Pat. Nos. 5,768,372, and 5,915,017,
each of which is hereby incorporated by reference herein in its
respective entirety, describe the encryption of the configuration
data and its decryption upon loading into the programmable device,
including provision of an indicator to signal to the decryption
circuit which of several possible encryption/decryption schemes was
used to encrypt the configuration data and therefore should be used
to decrypt the configuration data. Commonly-assigned U.S. Pat. No.
7,479,798, which is hereby incorporated by reference herein in its
entirety, describes a disabling element that can be used to
selectively disable a reading of a data from a device.
[0004] Cryptographic algorithms may provide one or more classes of
encryption/decryption schemes for securing the configuration data.
However, these cryptographic algorithms may be vulnerable to
specific kinds of attacks. One type of attack on an
encryption/decryption cryptographic system in a device is known as
a power analysis attack. This approach involves observing the power
consumption of the device while it is executing a cryptographic
algorithm. An attacker can combine the data derived from observing
the power consumption of the device with the knowledge of the
specific operations that are executed during the cryptographic
algorithm, and thereby deduce information about keys and other
secret data of the cryptographic algorithm.
[0005] One type of power analysis attack is known as a Differential
Power Analysis ("DPA") (see, for example, "Introduction to
Differential Power Analysis and Related Attacks", by Paul Kocher et
al., of Cryptography Research, San Francisco, Calif., copyright
1998, reprinted at web site: www.cryptography.com). DPA involves
observing the power consumption of a device while it executes
cryptographic operations for a large number of varying inputs. By
collecting and statistically correlating data from these multiple
observations, an attacker can derive secret information for the
cryptographic operations carried out by the device.
[0006] Different elements of a cryptographic algorithm may be
particularly vulnerable to DPA attacks. For example, key scheduling
routines, used for generating multiple sub-keys for multiple
cryptographic rounds from a secret cipher key may be especially
vulnerable in this regard, given that these routines manipulate the
cipher key in a known way. In addition, substitution tables (also
referred to as substitution boxes or "S-boxs"), which are common in
cryptographic algorithms and often implemented as look up tables,
may also be vulnerable to DPA attacks. Also, the initial round of
encryption or final round of decryption of some cryptographic
algorithms may be particularly vulnerable to DPA attacks, because
they may only involve key manipulation without modification of
plaintext or ciphertext.
SUMMARY OF THE INVENTION
[0007] The present invention relates to systems and methods for
protecting a programmable device against Differential Power
Analysis attacks.
[0008] Therefore, in accordance with embodiments of the present
invention, an encryption or decryption system may generate
cryptographic key schedules by using different cipher keys for each
block. In some implementations, a first cipher key may be derived
as a function of a second cipher key and of one of a previous block
of plaintext, a previous block of ciphertext, or an output of a
linear feedback shift register (LFSR) associated with the previous
block of plaintext. In some implementations, the encryption or
decryption system may expand (i.e., evolve) round keys between
encryption and/or decryption blocks. A key expansion block may
generate from a cipher key a first sequence of round keys for
decrypting a first block of ciphertext such that each round key is
generated based on at least one preceding round key in the first
sequence. The key expansion block may generate from at least one of
the round keys of the first sequence a second sequence of round
keys for decrypting a second block of ciphertext. In some
implementations, the initial round key for decrypting a second
block of plaintext is set to the final round key used for
decrypting a first block of ciphertext. The sequence of decryption
round keys may be inverted to generate a sequence of encryption
round keys.
[0009] In some embodiments, the encryption or decryption
cryptographic system that implements the cryptographic algorithm,
e.g., on a programmable device, is configurable to use obfuscated
substitution S-boxes. S-boxes may be obfuscated by interleaving
data to be encrypted (or decrypted) with random data. In some
implementations, the random data may be true random (e.g.,
generated by a True Random Number Generator). In some
implementations, the random data may be pseudo-random (e.g.,
generated by a linear feedback shift register). In some
implementations, the random data may be related to another
cryptographic operation for an unrelated block of data.
[0010] In some embodiments, plaintext may be obfuscated, e.g.,
through whitening using an LFSR. Blocks of plaintext may be
obfuscated before encryption using chained encryption blocks. In
some implementations, a block of obfuscated plaintext may be
further obfuscated with a block of ciphertext output from the
encryption of a preceding block of plaintext. In some
implementations, blocks of ciphertext may be further obfuscated
with blocks of obfuscated plaintext.
[0011] In some embodiments, blocks of ciphertext may be obfuscated
with blocks of obfuscated plaintext before decryption using chained
decryption blocks. Blocks of decrypted data may be combined with
blocks of ciphertext to generate blocks of obfuscated plaintext. In
some implementations, blocks of obfuscated plaintext may be
processed with an LFSR to output corresponding blocks of
plaintext.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] 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:
[0013] FIG. 1 is an exemplary block diagram of a programmable
device in which embodiments of the present invention may be
implemented;
[0014] FIG. 2A is an exemplary block diagram of a whitening system
for obfuscating blocks of plaintext according to an embodiment of
the present invention;
[0015] FIG. 2B is an exemplary block diagram of an unwhitening
system for unwhitening blocks of obfuscated plaintext according to
an embodiment of the present invention;
[0016] FIG. 3A is an exemplary block diagram for an encryption
system implementing AES with continuously evolving cryptographic
keys according to some embodiments;
[0017] FIG. 3B is an exemplary block diagram representing the
continuous evolution of cryptographic keys in a decryption system
according to some embodiments;
[0018] FIG. 3C is an exemplary block diagram representing the
continuous evolution of cryptographic keys in an encryption system
according to some embodiments;
[0019] FIG. 4 is an exemplary block diagram of a system for
obfuscating a cryptographic substitution box according to some
embodiments;
[0020] FIG. 5A is an exemplary block diagram of an encryption
system for encrypting data according to some embodiments;
[0021] FIG. 5B is an exemplary block diagram of a decryption system
for decrypting data according to some embodiments;
[0022] FIG. 6 is an exemplary block diagram of an illustrative
decryption system for decrypting data employing a programmable
logic device according to some embodiments;
[0023] FIG. 7A is an exemplary block diagram of an encryption
system for encrypting data according to some embodiments;
[0024] FIG. 7B is an exemplary block diagram of a decryption system
for decrypting data according to some embodiments;
[0025] FIG. 8 is an exemplary block diagram of an illustrative
decryption system for decrypting data employing a programmable
logic device according to some embodiments;
[0026] FIG. 9 shows an exemplary flowchart of a process for
encrypting data according to some embodiments; and
[0027] FIG. 10 shows an exemplary flowchart of a process for
decrypting data according to some embodiments.
DETAILED DESCRIPTION OF THE INVENTION
[0028] FIG. 1 shows an exemplary block diagram of a programmable
logic device 100 as an example of a programmable device in which
embodiments of the present invention may be implemented. The
external memory 120 contains configuration data, typically
containing proprietary designs, that is used to configure the
functionality of the logic device 100. The configuration of logic
device 100 may occur upon powering up the device, rebooting, or at
some other re-programming time. For example, upon powering up, the
configuration data will be sent from the external memory 120 to the
logic device 100. The configuration data may be encrypted in order
to prevent copying when the data is in transit, e.g., using an
encryption system (not shown).
[0029] The encrypted data is sent to the logic device 100 where it
is decrypted by a decoder 102. The decrypted data is then stored in
configuration data memory 104. The configuration data is used to
configure the functionality of logic blocks 106. After
configuration, the logic blocks may start operating on input data.
When in operation, the logic 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.
Additionally, in non-programmable devices, the internal data may
reflect proprietary aspects of the circuit design which may be
desired to be kept secret.
[0030] In some embodiments, the configuration data (which will be
referred to herein as plaintext) may be encrypted using an
encryption cryptographic system that implements a cryptographic
algorithm. The decoder 102 may then decrypt the encrypted data
(i.e., ciphertext) using a corresponding decryption cryptographic
system that implements the cryptographic algorithm.
[0031] One common cryptographic algorithm is a symmetric key block
cipher algorithm adopted by the Department of Commerce, National
Institute of Standards and Technology (NIST) as its Advanced
Encryption Standard (AES). (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,
AES192 uses 12 rounds and AES256 uses 14 rounds to complete an
encryption or decryption operation.
[0032] 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
exemplary and not intended to limit the scope of the present
invention.
[0033] In some embodiments, plaintext (e.g., configuration data
received in a configuration device for configuring programmable
logic device 100 of FIG. 1) may be processed prior to encryption
with a cryptographic algorithm. This may increase the security of
the cryptographic algorithm. For instance, blocks of plaintext may
be obfuscated prior to encrypting these blocks with AES. FIG. 2A
shows an exemplary block diagram of whitening system 200 that could
be used to carry out plaintext obfuscation according to an
embodiment of the present invention. Whitening system 200 may
include a linear feedback shift register (LFSR) 204 coupled to
combining circuitry 208.
[0034] In some implementations, combining circuitry 208 may be
implemented as an exclusive-OR gate. In some implementations,
combining circuitry 208 may include multiplicative and/or inversion
elements. Although the remainder of the patent specification will
refer to the exclusive-OR gate implementation of combining
circuitry 208, it should be understood that the invention described
herein is applicable to other combining functions as well. As such,
discussing the embodiments with respect to the exclusive-OR is
exemplary and not intended to limit the scope of the present
invention.
[0035] Plaintext data P (e.g., configuration data) may be
partitioned into N blocks of M bits each, e.g., P.sub.1, P.sub.2,
P.sub.3, . . . , and P.sub.N. For example, according to AES, P may
be partitioned into blocks of M=128 bits. Each block of plaintext
P.sub.i (i=1, . . . , N) may be fed into input 202 of combining
circuitry 208.
[0036] Combining circuitry 208 is coupled to LFSR 204. In some
embodiments, LFSR 204 may be implemented as an M-cell shift
register. During each cycle of data transfer, an input bit, e.g., a
bit from combining circuitry 208, may be fed into a first cell of
LFSR 204, and each bit in LFSR 204 may shift down one cell. The bit
in the last cell of LFSR 204 may be shifted out at output 206 as an
output bit. The bits output at output 206 will be referred to as
output bitstream L. These bits may be fed back to the LFSR through
feedback lines 211, 212, and/or 213, such that they are combined
with one or more of bits in predetermined cells of the LFSR (called
taps). This feedback causes the bits output by LFSR 204 at output
206 to cycle through a set of unique values that may appear random,
i.e., a set of pseudo-random values.
[0037] In some embodiments, the arrangement of taps for feedback in
the LFSR (i.e., the bits in the LFSR cells that influence the
output as described above) can be expressed as a feedback
polynomial, where the powers of the terms represent the tapped
bits. In an illustrative implementation, LFSR 204 may be
implemented as a 128-bit register with a characteristic feedback
polynomial POLY=X.sup.128+X.sup.99+X.sup.62+X.sup.33+1. According
to this implementation, bits in cells 99, 62, and 33 may be
combined to produce the output bit in the next stage. The output of
the LFSR may be viewed as a division by the characteristic
polynomial POLY.
[0038] Because the operation of an LFSR is deterministic, the
initial value with which the LFSR is initialized determines the
operation of the register and may be viewed as a random seed that
initializes the LFSR pseudo-random generation. In the embodiment
illustrated in FIG. 2A, and referring to the i.sup.th value
contained in the LFSR as R.sub.i, a first block
R.sub.0=E.sup.-1.sub.K0(0) may be used to initialize LFSR 204.
Because a secret key K.sub.0 is used to generate R.sub.0, the
random seed that initializes the LFSR pseudo-random generation is
still unknown to the attacker.
[0039] Blocks of plaintext P.sub.i (i=1, . . . , N) may be input
into the initialized LFSR through combining circuitry 208.
Combining circuitry 208 may combine the output of the LFSR with the
block of plaintext P.sub.i to generate a block of obfuscated
plaintext P'.sub.i at output 210. For example, the block of
plaintext P.sub.i may be XORed with the output of the LFSR to
generate the block of obfuscated plaintext P'.sub.i. Such an
operation is referred to as whitening the block of plaintext
P.sub.i.
[0040] Overall, the operation of whitening system 200 of FIG. 2A
may be expressed as follows:
(L.sub.1.parallel. . . .
.parallel.L.sub.N)=(E.sup.-1.sub.K0(0).parallel.P.sub.1.parallel. .
. . .parallel.P.sub.N)DIV POLY,
where POLY represents the feedback polynomial of LFSR 204,
P.sub.1.parallel. . . . .parallel.P.sub.N represents a
concatenation (e.g., using the concatenation symbol II) of the
blocks of plaintext P.sub.i input at 202, E.sup.-1.sub.K0(0)
represents the value used to initialize LFSR 204, and
L.sub.1.parallel. . . . .parallel.L.sub.N represents a
concatenation of the blocks of output bits in output bitstream L.
Output bitstream L and plaintext P may be combined to generate
obfuscated or whitened plaintext P' as follows:
(P'.sub.1.parallel. . . . .parallel.P'.sub.N)=(P.sub.1.parallel. .
. . .parallel.P.sub.N)XOR(L.sub.1.parallel. . . .
.parallel.L.sub.N).
[0041] The operation of LFSR 204 may be described using the
following incremental equations:
L.sub.0=0, (EQ. 1a)
R.sub.0=E.sup.-1.sub.K0(0), (EQ. 1b)
L.sub.i=(R.sub.i-1.parallel.0)DIV POLY, (EQ. 1c)
R.sub.i=(R.sub.i-1.parallel.P.sub.i)MOD POLY, (EQ. 1d)
where i=1, . . . , N.
[0042] The first two equations (EQS. 1a and 1b) correspond to
initializing the LFSR by setting the initial value contained in the
LFSR R.sub.0 and the first block of output bits L.sub.0. As
explained above, R.sub.0 may be set to a block of mask values
generated from decrypting a vector of predetermine values (e.g.,
all zeros) using cipher key K.sub.0. In this way, even if the
vector of predetermined values is predictable, the value obtained
by decrypting the vector of predetermined values using cipher key
K.sub.0 is still unknown to the attacker. In some implementations,
L.sub.0 may be set to a vector of all zeros. It should be
understood that these initialization values of R.sub.0 and L.sub.0
are merely exemplary and that R.sub.0 and L.sub.0 may be
initialized to any other suitable value.
[0043] The latter two equations (EQS. 1c and 1d) describe the
operation of the LFSR, and in particular, how the output bitstream
L.sub.i and the LFSR state R.sub.i are updated. As explained above,
the operation of the LFSR may be viewed as performing division of
the value contained in the LFSR R.sub.i-1 by the feedback
polynomial POLY to generate output bitstream block L.sub.i. As
blocks of plaintext P.sub.i are input into the LFSR 204, the value
contained in the LFSR R.sub.i may be expressed as the result of
concatenating the previous LFSR block (or state) R.sub.i-1 with a
current block of plaintext P.sub.i and taking the modulo polynomial
POLY to generate the current LFSR state R.sub.i.
[0044] FIG. 2B is an exemplary block diagram of an unwhitening
system for unwhitening blocks of obfuscated plaintext according to
an embodiment of the present invention. This system may be viewed
as the counterpart of FIG. 2A and comprises LFSR 254 and combining
circuitry 258. Blocks of obfuscated plaintext P' are input into the
LFSR 254 and combining circuitry 258. Combining circuitry 258
combines obfuscated plaintext P' and the output bitstream L to
generate unwhitened plaintext P.
[0045] Blocks of obfuscated plaintext P'.sub.1, . . . , P'.sub.N
may be input into LFSR 254 and combining circuitry 258. LFSR 254
may operate similarly to LFSR 204 of FIG. 2A above. The operation
of unwhitening system 250 of FIG. 2B may be expressed as
follows:
R.sub.0=E.sup.-1.sub.K0(0),
L.sub.i=(R.sub.i-1.parallel.0)DIV POLY,
R.sub.i=(R.sub.i-1.parallel.P.sub.i)MOD POLY, and
P.sub.i=L.sub.iXORP'.sub.i,
where i=1, . . . , N. The first three equations are similar to EQS.
1b, 1c, and 1d above, and describe the initialization and operation
of LFSR 258. The last equation describes the operation of combining
circuitry 258 to generate unwhitened plaintext P from XORing output
bitstream block L.sub.i and obfuscated plaintext block
P'.sub.i.
[0046] Whitening (or unwhitening) the plaintext, as illustrated in
FIGS. 2A and 2B above, may increase security against DPA by masking
the first round of AES encryption (or the last round of the AES
block decryption). Given that these rounds are particularly
vulnerable to DPA attacks, and given that they operate on the key
without modification of plaintext or ciphertext, the plaintext
obfuscation discussed above may increase the security of the device
against DPA attacks.
[0047] In some embodiments, blocks of plaintext, P.sub.i, or blocks
of obfuscated plaintext, P'.sub.i, e.g., as output by whitening
system 200 of FIG. 2A, may be input to an AES encryption system.
FIG. 3A is an exemplary block diagram of an encryption system 300
for encrypting plaintext (obfuscated or not) using AES with a
cipher key K. This cipher key K 306 may be uploaded into the engine
system and/or stored in the engine system. Encryption system 300
may include a block 302 for receiving and/or storing plaintext, a
block 380 for receiving and/or storing corresponding ciphertext,
and an encryption block 304 that implements encryption function
E.sub.K( ). Encryption block 304 may receive a block of plaintext
(P.sub.i or P'.sub.i) and generate a corresponding block of
ciphertext based on cipher key K.
[0048] A block of plaintext P.sub.i or obfuscated plaintext
P'.sub.i may be input into block 302. An initial key mix operation
330 may be performed in which the plaintext block is XORed with an
initial round key 310. In normal AES, this initial key is generated
from a first portion of the cipher key K. This initial key mix
operation provides the starting data for the first round 340. In
some embodiments, instead of generating the first round key
R.sup.i.sub.l from the cipher key K (e.g., by expanding the initial
key 310 R.sup.i.sub.0 that is based on the first portion of the
cipher key K), a round key for one block may be used to generate a
round key of another block. This will be described in more detail
below.
[0049] During the first round 340, the following operations occur:
(a) a data block is transformed using S-box substitution 342, row
shifting 344, and column mixing 346, (b) round key 312 is generated
in key expansion block 308, and (c) the transformed data block and
round key 312 are added together using an XOR operation in the
AddRoundKey 348 operation to provide the starting data block for
the next round. Similar operations are repeated for each l.sup.th
round 350 of AES (i.e., for each of the 14 rounds for AES256) with
the exception that the column mixing operation is omitted in the
final round 360. The details of the S-box substitution, row
shifting, and column mixing operations for the rounds are described
in the above-mentioned NIST document.
[0050] A sequence of round keys for each encryption round (or key
schedule) is generated from the initial cipher key K using a key
expansion routine, e.g., implemented by block 308. In AES, the
length of the round keys is the same as the block size (128 bits=4
words) regardless of the length (128, 192, or 256 bits) of the
original cipher key. The words of the cipher key are used as is for
generating the first round keys, then each successive round key
word is a function of one or more of the preceding round key words.
This generating of each successive round key word based on at least
one of the preceding round key words will be referred to herein as
the evolution of round keys. In AES256, encryption and decryption
for a particular block evolve the round keys in reverse order. If
the fourteen decryption round keys for block 1 are R.sup.1.sub.l
through R.sup.l.sub.14, then the encryption round keys for block 1
will be R.sup.1.sub.14 through R.sup.1.sub.1.
[0051] According to some embodiments, the cipher key used for
encrypting subsequent blocks of plaintext or obfuscated plaintext
is different with every block. This is different from normal AES
where the same key schedule based on the same cipher key K is used
for every block and the initial round key (i.e., round key 310)
used in the first round of AES for every block is filled from the
first words of the cipher key K. In some embodiments, encrypting a
first block of plaintext P.sub.1 (or P'.sub.1) may use the same
sequence of 14 round keys (or key schedule) as normal AES based on
the original cipher key K. However, encrypting a second block of
plaintext P.sub.2 (or P'.sub.2) may use a different key schedule.
For example, a sequence of round keys for encrypting P.sub.2 may be
based on expanding an initial round key that is different from the
one used for P.sub.1.
[0052] In some embodiments, every block may be encrypted using a
different key such that the keys for encrypting subsequent blocks
of plaintext are related. In some implementations, the round keys
for encrypting different blocks of plaintext may continue to evolve
between blocks. For example, the key used for encrypting a block of
plaintext or obfuscated plaintext may be derived based on a
function of the previous plaintext, the previous ciphertext, the
previous key used to encrypt the previous plaintext or decrypt the
previous ciphertext, and/or the previous LFSR value used to whiten
the previous plaintext or unwhiten the previous ciphertext.
[0053] FIG. 3B is an exemplary block diagram representing the
continuous evolution of cryptographic keys in a decryption system
according to some embodiments. In the example illustrated in FIG.
3B, each row may correspond to one cryptographic round and each
column may correspond to one block of ciphertext. In the particular
example of FIG. 3B, 14 decryption rounds and three blocks are
illustrated. Each box depicts a decryption round key R.sup.n.sub.l
that may be used to decrypt block n during round l. The decryption
keys of each column form a sequence of keys associated with one
block of ciphertext. As explained above in connection with key
expansion block 308 of FIG. 3A, a decryption round key
R.sup.n.sub.l+1 may be derived from a decryption round key of a
previous round, e.g., R.sup.n.sub.l. The relationship between the
decryption round keys associated with one block may be expressed
using a function f.sub.l( ) where l refers to the decryption round.
This function f.sub.l( ) may describe the intra-block round key
evolution used from decryption round key R.sup.n1 to decryption
round key R.sup.n.sub.l+1. For AES128, the round key for block n
and round l+1 can be derived as a function f( ) of the previous
round key (i.e., R.sup.n.sub.l+1=f(R.sup.n.sub.l) because f.sub.l(
) is the same, regardless of round l). For AES256, the even and odd
rounds have different functions because the even and odd round keys
are a function of the upper and lower 128 bits of the cipher key K.
Other types of block ciphers may have different functions for each
round.
[0054] According to some embodiments of the present disclosure, the
decryption round key for a block n may depend on the value of a
decryption round key for a previous block n-1. For example, the
first round decryption key for block n may be derived from the last
round decryption key used for block n-1. An intra-block function
f.sub.l( ) may be defined to extend the inter-block function
f.sub.l( ) described above and describe the evolution of decryption
round keys between blocks, i.e., such that R.sup.n+1.sub.l,
=f.sub.l(R.sup.n.sub.l). For example, and as shown by the arrow
from the first to the second column labeled f.sub.14( ), the
decryption round key R.sup.2.sub.1 may be obtained from the
decryption round key of the previous block, R.sup.1.sub.14, by
applying inter-block function f.sub.14( ) (i.e.,
R.sup.2.sub.1=f.sub.14(R.sup.1.sub.14)). This means that the key
evolution of decryption round keys may continue between blocks. In
standard AES256, f.sub.14( ) is not strictly defined (as the key is
evolved, i.e., expanded, only 13 times to get 14 round keys, and
the key of the first round key for the second block is regenerated
from cipher key K, i.e., similarly to the first round key for the
first block). In some embodiments that employ intra-block key
evolution with an AES engine, f.sub.14( ) may be defined to be
equal to the decryption key evolution function of the last even
round, i.e., f.sub.12( ).
[0055] The relationship between the decryption round keys
illustrated in FIG. 3B may also define the relationship between
encryption round keys R.sup.n.sub.14, . . . , R.sup.n.sub.1 used
for encryption. FIG. 3C is an exemplary block diagram representing
the continuous evolution of cryptographic keys in an encryption
system with 14 encryption rounds and three blocks. Letting
f.sup.-1.sub.l( ) correspond to the inverse of the decryption key
evolution function f.sub.l( ) described above (both within and
between blocks, i.e., inter and intra-block), the evolution of
encryption round keys within each block n may be defined as
R.sup.n.sub.l=f.sup.-11.sub.l(R.sup.n.sub.l+1). The evolution of
encryption round keys between blocks n+1 and n may be defined by
R.sup.n.sub.14=f.sup.-1.sub.l(R.sup.n+1.sub.l). This evolution of
encryption round keys may be viewed as the inverse of the evolution
of the decryption keys of FIG. 3B.
[0056] In some embodiments, it may not be practical to evolve the
encryption keys from the last block to the first block in order to
starting encrypting the first block. For example, it may not be
practical to start from R.sup.3.sub.14 to compute R.sup.1.sub.1 by
sequentially applying f.sup.-1.sub.l( ), per the order illustrated
in FIG. 3. Instead of computing the encryption round keys backwards
from the last block to the first block, the 14 encryption round
keys R.sup.n.sub.14, . . . , R.sup.n.sub.1 may be obtained by first
expanding the 14 decryption round keys R.sup.n.sub.1, . . . ,
R.sup.n.sub.14. In other words, each sequence of encryption round
keys associated with block n (i.e., R.sup.n.sub.14, . . . ,
R.sup.n.sub.1) may be computed by generating the corresponding
sequence of decryption round keys (i.e., R.sup.n.sub.1, . . . ,
R.sup.n.sub.14, as described in FIG. 3B above), and then inverting
the order of the generated sequence of decryption round keys.
[0057] As discussed above, key schedule routines are specifically
vulnerable to DPA attacks. According to one approach, an attacker
may generate two large sets of ciphertext blocks and monitor the
power consumption of a device while the device decrypts both sets
of ciphertexts. Statistical analysis of the difference in power
consumption between both sets may help derive information about the
cipher key. The techniques described above of letting the round
keys continue to evolve between block encryptions may increase the
security of the device against these types of attacks because the
keys used to decrypt the ciphertexts may vary with each block.
[0058] In some embodiments, the intra-block key evolution approach
described in FIGS. 3A-3C above may be applied to cipher block modes
of operation e.g. Counter Mode (CTR) or Cipher-Block-Chaining mode
(CBC). In some embodiments, the evolving key approach may be
combined with any other DPA resistant methods and systems such as
the ones described herein.
[0059] In some embodiments, the security of the device against DPA
may further be enhanced by obfuscating the substitution blocks used
in a cryptographic algorithm, e.g., the S-box used in the S-box
substitution operation 342 of FIG. 3A. FIG. 4 is an exemplary block
diagram of system 400 for obfuscating a cryptographic substitution
box according to an embodiment of the present invention. System 400
includes S-box 206, which may be implemented in hardware or
software on an encryption device, e.g., on a PLD or an encryption
system in configuration device. An S-box is a typical component of
symmetric key cryptographic algorithms that is used to obscure the
relationship between the key and the data to be encrypted or
decrypted. The S-box may be implemented as a table lookup that is
indexed by a combination of key bits and plaintext. For example,
each byte of input text 202 may be replaced with another byte 208
according to the look up table and using the cipher key K.
[0060] S-boxes may be vulnerable to DPA attacks. An attacker may
control the plaintext values and make guesses at the key bits.
Based on these guesses, computations are performed on the monitored
power consumption to form a set of DPA data. The DPA data is
analyzed to determine with of the key bit guesses was likely
correct. These types of attacks may be mitigated by obfuscating
S-boxes used, for example, during AES.
[0061] In some embodiments, S-box 206 may be obfuscated by
interleaving input data 202 with random data 204. This random data
may not be part of the plaintext or ciphertext. In some
implementations, random data 204 may be true random, e.g.,
generated by a true random number generator (TRNG) implemented in
an FPGA. In some implementations, random data 204 may be
pseudo-random, e.g., generated with an LFSR similar to LFSR 204
from FIG. 2. In some implementations, random data 204 may be
generated from a separate cryptographic method operating on an
unrelated block of data.
[0062] In addition to or instead of the techniques described above
for obfuscating plaintext, continuously evolving cryptographic
round keys, and/or obfuscating substitution tables, security of a
device may be enhanced by obfuscating ciphertext as illustrated in
FIGS. 5-8 below.
[0063] FIG. 5A shows an exemplary block diagram of encryption
system 500 for encrypting data according to some embodiments.
Encryption system 500 may include encryption blocks 506, 516, 526,
and 536. These encryption blocks may be implemented as encryption
block 300 of FIG. 3A, using normal AES or AES modified to use
continuously evolving keys. System 500 may also include combining
circuitries 502, 512, 522, 532, 504, 514, 524, 534, 508, 518, 528,
and 538. Each one of these combining circuitries may be implemented
similarly to combining circuitry 208 of FIG. 2A. It should be noted
that the number of encryption blocks and the number of combining
circuitries are exemplary and not intended to limit the scope of
the present invention.
[0064] Blocks of plaintext P.sub.1, P.sub.2, P.sub.3, and P.sub.4
are whitened using whitening bistream blocks L.sub.1, L.sub.2,
L.sub.3, and L.sub.4. These whitening bistream blocks may be
generated using an LFSR as described in FIG. 2A above. The
plaintext blocks and whitening bistream blocks are combined using
combining circuitries 502, 512, 522, and 532 to output blocks of
obfuscated plaintext P'.sub.1, P'.sub.2, P'.sub.3, and P'.sub.4.
The first block of plaintext P.sub.1 may be set to an
initialization vector (IV). An IV is a fixed-size seed input to a
cryptographic mode that is typically random or pseudorandom. For
block ciphers, the use of an IV randomizes the encryption and hence
produces distinct ciphertexts even if the same plaintext (P.sub.2,
P.sub.3, . . . ) is encrypted multiple times.
[0065] The blocks of obfuscated plaintext P'.sub.1, P'.sub.2,
P'.sub.3, and P'.sub.4 are further obfuscated by combining them,
respectively, with blocks of ciphertext C.sub.0, C.sub.1, C.sub.2,
and C.sub.3 using combining circuitries 504, 514, 524, and 534. In
some embodiments, ciphertext block C.sub.0 may be initialized to
zero, or to any other suitable value. Ciphertext blocks C.sub.1,
C.sub.2, and C.sub.3 are output from encryption blocks 506, 516,
and 526, respectively, as will be discussed below. The blocks
resulting from combining the blocks of obfuscated plaintext and the
blocks of ciphertext are referred to as blocks of further
obfuscated plaintext H.sub.1, H.sub.2, H.sub.3, and H.sub.4.
[0066] Blocks H.sub.1, H.sub.2, H.sub.3, and H.sub.4 are encrypted
using encryption blocks 506, 516, 526, and 536 to generate
ciphertext blocks C.sub.1, C.sub.2, C.sub.3, and C.sub.4. In some
embodiments, encryption blocks 506, 516, 526, and 536 may use
different cipher keys K.sub.1, K.sub.2, K.sub.3, and K.sub.4. For
example, the keys K.sub.1, K.sub.2, K.sub.3, and K.sub.4 may be
obtained using the evolving key approach described in FIGS. 3A-C
above. In some embodiments, encryption blocks 506, 516, 526, and
536 may use the same cipher key, e.g., as defined in normal AES
(K.sub.1=K.sub.2=K.sub.3=K.sub.4).
[0067] The first obfuscated block H.sub.1 is fed into the first
encryption block 506 to generate a block of ciphertext
C.sub.1=E.sub.K1(H.sub.1), i.e., the result of encrypting H.sub.1
with cipher key K.sub.1. Combining circuitry 508 combines the
output of the first encryption block 506 with a block of mask
values H.sub.0=E.sup.-1.sub.K0(0) to generate a first block of
obfuscated ciphertext C'.sub.1. This block of mask values may be
generated by decrypting a vector of all zeros using cipher key
K.sub.0. This first block of obfuscated ciphertext C'.sub.1 may
thus be expressed as C.sub.1 XOR H.sub.0.
[0068] The block of ciphertext C.sub.1 is combined with the second
block of obfuscated plaintext P'.sub.2 using combining circuitry
514. The output of combining circuitry 514, H.sub.2, is fed into
the second encryption block 516. Second encryption block 516
encrypts H.sub.2 to generate a second block of ciphertext
C.sub.2=E.sub.K2(H.sub.2). Combining circuitry 518 combines the
first block of further obfuscated plaintext H.sub.1 with the second
block of ciphertext C.sub.2 to generate a second block of
obfuscated ciphertext C'.sub.2. The operation of combining
circuitry 518 may be viewed as whitening the block of ciphertext
C.sub.2 with the prior block of further obfuscated plaintext
H.sub.1 to output the block of obfuscated ciphertext C'.sub.2.
[0069] Similar operations may be repeated to generate a third block
and fourth block of ciphertext C.sub.3 and C.sub.4 and a third
block and fourth block of obfuscated ciphertext C'.sub.3 and
C'.sub.4.
[0070] In general, the blocks of obfuscated plaintext, further
obfuscated plaintext, ciphertext, and obfuscated ciphertext that
are output by encryption system 500 may be expressed using the
following equations:
L.sub.0=0, (EQ. 1a)
R.sub.0=E.sup.-1.sub.K0(0), (EQ. 1b)
L.sub.i=(R.sub.i-1.parallel.0)DIV POLY, (EQ. 1c)
R.sub.i=(R.sub.i-1.parallel.P.sub.1)MOD POLY, (EQ. 1d)
H.sub.0=E.sup.-1.sub.K0(0), (EQ. 2a)
C.sub.0=0, (EQ. 2b)
P.sub.1=IV, (EQ. 2c)
P'.sub.i=L.sub.iXORP.sub.i, (EQ. 3a)
H.sub.i=P'.sub.iXORC.sub.i-1, (EQ. 3b)
C.sub.i=E.sub.Ki(H.sub.i), (EQ. 3c)
C'.sub.i=C.sub.iXORH.sub.i-1, (EQ. 3d)
where i=1, . . . , N. The first set of equations, EQS. 1a, 1b, 1c,
and 1d, is the same as the incremental LFSR equations of FIG. 2A
and corresponds to the generation of bitstream blocks L.sub.1,
L.sub.2, L.sub.3, and L.sub.4. The second set of equations, EQS.
2a, 2b, and 2c, corresponds to initialization values for the inputs
of combining circuitries 504, 508, and 502, respectively. The third
set of equations, EQS. 3a, 3b, 3c, and 3d, represents the relation
between blocks of plaintext P.sub.i, blocks of obfuscated plaintext
P'.sub.i, blocks of further obfuscated plaintext H.sub.i, blocks of
ciphertext C.sub.i, and blocks of obfuscated ciphertext C'.sub.i,
as described above. It should be noted that the initialization
values are merely illustrative, and that any suitable value may be
used to initialize L.sub.0, R.sub.0, H.sub.0, C.sub.0 and
P.sub.1.
[0071] The blocks of obfuscated ciphertext output by encryption
system 500 may be decrypted using decryption system 550 illustrated
in FIG. 5B. Decryption system 550 may include decryption blocks
554, 564, 574, and 584, and combining circuitries 552, 562, 572,
582, 556, 566, 576, 586, 558, 568, 578, and 588. These combining
circuitries may be implemented similarly to combining circuitry 208
of FIG. 2A. It should be noted that the number of decryption blocks
and the number of combining circuitries are exemplary and not
intended to limit the scope of the present invention.
[0072] Blocks of obfuscated ciphertext C'.sub.1, C'.sub.2,
C'.sub.3, and C'.sub.4 are fed into decryption system 550. These
blocks of obfuscated ciphertext may for example have been output
from encryption system 500 of FIG. 5A. Combining circuitry 552 may
combine a first block of obfuscated ciphertext C'1 with a block of
mask values H.sub.0=E.sup.-1.sub.K0(0). In some implementations,
the block of mask values may be generated similarly to FIG. 5A,
i.e., by decrypting a vector of all zeros using cipher key K.sub.0.
Combining circuitry 552 may output a ciphertext block
C.sub.1=C'.sub.1 XOR H.sub.0, which is fed into the first
decryption block 554. First decryption block 554 decrypts
ciphertext block C.sub.1 with cipher key K.sub.1 to produce a first
block of further obfuscated plaintext H.sub.1.
[0073] The first block of further obfuscated plaintext H.sub.1 may
be combined with a block of ciphertext C.sub.0 using combining
circuitry 556. The output of the combining circuitry 556
corresponds to obfuscated plaintext block P'.sub.1. This block of
obfuscated plaintext P'.sub.1 may be unwhitened with bistream block
L.sub.1 to generate a block of plaintext P.sub.1. The bistream
block L.sub.1 may be generated by an LFSR such as the one depicted
in FIG. 2B.
[0074] The block of further obfuscated plaintext H.sub.1 is
combined with obfuscated ciphertext block C'.sub.2 using combining
circuitry 562 to generate a block of ciphertext C.sub.2. This block
of ciphertext C.sub.2 is decrypted using decryption block 564 to
generate H.sub.2. Block H.sub.2 is combined with ciphertext block
C.sub.1 to generate obfuscated plaintext block P'.sub.2. This block
of obfuscated plaintext P'.sub.2 may be unwhitened similarly to
P'.sub.1 in order to generate plaintext block P.sub.2.
[0075] Similar operations may be repeated to generate a third and
fourth block of obfuscated plaintext P'.sub.3 and P'.sub.4, and a
third and fourth block of plaintext P.sub.3 and P.sub.4. The
operation of decryption system 550 may be summarized using the
following equations:
R.sub.0=E.sup.-1.sub.K0(0), (EQ. 4a)
L.sub.i=(R.sub.i-1.parallel.0)DIV POLY, (EQ. 4b)
R.sub.i=(R.sub.i-1.parallel.P.sub.i)MOD POLY, (EQ. 4c)
H.sub.0=E.sup.-1.sub.K0(0), (EQ. 5a)
C.sub.0=0, (EQ. 5b)
C.sub.i=C'.sub.iXORH.sub.i-1, (EQ. 6a)
H.sub.i=E.sup.-1.sub.Ki(C.sub.i), (EQ. 6b)
P'.sub.i=H.sub.iXORC.sub.i-1, (EQ. 6c)
P.sub.i=L.sub.iXORP'.sub.i, (EQ. 6d)
where i=1, . . . , N. The first set of equations, EQS. 4a, 4b, and
4c, is the same as the incremental LFSR equations of FIG. 2B and
corresponds to the generation of bitstream blocks L.sub.1, L.sub.2,
L.sub.3, and L.sub.4. The second set of equations, EQS. 5a and 5b,
corresponds to initialization values for the inputs of combining
circuitries 552 and 556, respectively. The third set of equations,
EQS. 6a, 6b, 6c, and 6d, represents the relation between blocks of
obfuscated ciphertext C'.sub.i, blocks of ciphertext C.sub.1,
blocks of further obfuscated plaintext H.sub.1, blocks of
obfuscated plaintext P'.sub.i, and blocks of plaintext P.sub.i, as
described above. These equations are the reverse of the encryption
equations 3a, 3b, 3c, and 3d above. It should be noted that the
initialization values are merely illustrative, and that any
suitable value may be used to initialize R.sub.0, H.sub.0, and
C.sub.0.
[0076] Although the encryption and decryption blocks and operations
illustrated in FIGS. 5A and 5B above use cipher keys with different
indices K.sub.1, K.sub.2, K.sub.3, and K.sub.4, it should be
understood that these cipher keys may be the same or different. In
some implementations, these keys may be set to one value K, e.g.,
for normal AES (K.sub.1=K.sub.2=K.sub.3=K.sub.4). In some
implementations, these keys may be different and may be generated
using the evolving key approach described in FIGS. 3A-C above.
[0077] An illustrative implementation of the decryption system of
FIG. 5B is shown in FIG. 6. Decryption system 600 of FIG. 6 may
include M-bit shift registers 604 and 618, M-bit linear feedback
shift register (LFSR) 640, decryption engine 614, registers 608 and
609, and combining circuitries 610, 616, and 644. LFSR 640 may be
implemented similarly to LFSR 204 of FIG. 2B. Combining circuitries
610, 616, and 644 may be implemented similarly to combining
circuitry 208 of FIG. 2A.
[0078] Input shift register 604 may receive blocks of obfuscated
ciphertext C'.sub.i (i=1, . . . , N). These blocks may be output,
for example, from encryption system 500 of FIG. 5A. In some
embodiments, the blocks of obfuscated ciphertext may be received
sequentially by shift register 604, such that, as input shift
register 604 is receiving C'.sub.i+2, input shift register 604 is
outputting C'.sub.i+1, register 608 is outputting C'.sub.i, and
register 609 is outputting C'.sub.i-1. This arrangement is merely
illustrative, and any number of registers 608 or 609 or
configurations of input shift register 604 may be used as
appropriate.
[0079] Combining circuitry 610 may receive a first block of
obfuscated ciphertext C'.sub.i+1 from shift register 604 and
combine it with an output of decryption engine 614 to generate a
corresponding block of ciphertext C.sub.i+1. The output of
combining circuitry 610 is coupled to the decryption engine 614.
Decryption engine 614 may decrypt the first block of ciphertext
C.sub.i+1 to output a first block of further obfuscated plaintext
H.sub.i, e.g., as specified in EQ. 6a above. The block of further
obfuscated plaintext H.sub.i may be fed back to combining circuitry
610 to generate the corresponding block of ciphertext C.sub.i+1,
e.g., as specified in EQ. 6b above.
[0080] The output of combining circuitry 610 may also be coupled to
serially connected registers 608 and 609, for storing the previous
two generated ciphertext blocks C.sub.i and C.sub.i+1,
respectively. Combining circuitry 616 may combine the block of
ciphertext output by register 609 (e.g., C.sub.i-1) with the block
of further obfuscated plaintext H.sub.i to output a block of
obfuscated plaintext P'.sub.i, as specified in EQ. 6c above.
[0081] The block of obfuscated plaintext P'.sub.i (i=1, . . . , N)
may be input into shift register 618, which is coupled to combing
circuitry 644 and LFSR 640. Combining circuitry 644 and LFSR 640
are arranged similarly to system 250 of FIG. 2B above, and are
configurable to unwhiten the block of obfuscated plaintext P'.sub.i
to generate a block of plaintext P.sub.i, e.g., as described in EQ.
6d above.
[0082] In some embodiments, the feedback line 620 from the output
of decryption engine 614 to the input of combining circuitry 610
may be selectively disabled. By disabling this feedback line,
decryption engine 614 may implement decryption algorithm using
normal CBC mode (i.e., without whitening obfuscated ciphertext
blocks with prior plaintext blocks H.sub.i.)
[0083] The techniques of obfuscating plaintext and ciphertext
described above may help make a device more secure against DPA.
First, by masking both the input and output of the AES engine, DPA
attacks may be prevented on the first and last round of a single
block decryption, which are typically the most vulnerable rounds.
Second, the attacker may be prevented from injecting multiple known
ciphertext blocks with varying different bits, because all
subsequent ciphertext blocks would be cryptographically corrupted.
For example, an attacker may toggle bits of only one ciphertext
block, C'.sub.1, in a known fashion, and analyze the power profiles
of the device while the device decrypts a large number of
ciphertexts differing in this one ciphertext block C'.sub.i. Using
the techniques for whitening or obfuscating ciphertext blocks
described above, changing one ciphertext block would propagate
across all following ciphertext blocks, which would make this type
of attack substantially more difficult.
[0084] In some embodiments, decryption engine 614 may decrypt each
block C.sub.i using the same cipher key K. In some embodiments,
decryption engine 614 may implement continuously evolving key as
described in FIGS. 3A-C above. For example, decryption engine 614
may expand cipher key K from one block to the next. For instance,
the first round key in decrypting ciphertext block C.sub.2 may be
initialized to the value of the final round key used in decrypting
ciphertext block C.sub.1.
[0085] In some embodiments, AES decryption engine 614 may implement
the S-box obfuscation described in FIG. 4 above. In some
implementations, decryption engine 614 may implement the AES
algorithm using 4 S-boxes that are obfuscated as described in FIG.
4 above, e.g., using true random or pseudo-random data.
[0086] FIGS. 7A, 7B, and 8 are variants of the encryption and
decryption systems illustrated in FIGS. 5A, 5B, and 6,
respectively.
[0087] FIG. 7A is an exemplary block diagram of an encryption
system 700 for encrypting data according to some embodiments.
System 700 may operate similar to system 500 of FIG. 5A, except
that ciphertext blocks C.sub.i are obfuscated with blocks of
obfuscated plaintext P'.sub.i-1, instead of with blocks of further
obfuscated plaintext H.sub.i-1 as is the case in system 500. For
example, combining circuitry 718 is coupled to an output of
combining circuitry 702 through line 710. In contrast, in FIG. 5A,
combining circuitry 518 is coupled to an output of combining
circuitry 504 through line 510.
[0088] The operation of system 700 may be described using equations
similar to system 500, with EQS. 2a and 3d modified as follows:
P'.sub.0=E.sup.-1.sub.K0(0), (EQ. 2a')
C'.sub.1=C.sub.iXOR P'.sub.i-1. (EQ. 3d')
The value P'.sub.0 of EQ. 2a' corresponds to the initialization
value for the input of combining circuitry 708. It should be noted
that this initialization value is merely illustrative, and that any
suitable value may be used to initialize P'.sub.0. The obfuscation
of ciphertext blocks using previous obfuscated plaintext blocks is
shown in EQ. 3d'.
[0089] FIG. 7B is an exemplary block diagram of a decryption system
750 for decrypting data according to some embodiments. System 750
may operate similar to system 550 of FIG. 5B, except that
obfuscated ciphertext blocks C'.sub.i are unwhitened with blocks of
obfuscated plaintext P'.sub.i-1, instead of with blocks of further
obfuscated plaintext H.sub.i-1 as is the case in system 550. For
example, combining circuitry 762 is coupled to an output of
combining circuitry 756 through line 760. In contrast, in FIG. 5B,
combining circuitry 562 is coupled to an output of decryption block
554 through line 560.
[0090] The operation of system 750 may be described using equations
similar to system 550, with EQS. 5a and 6a modified as follows:
P'.sub.0=E.sup.-1.sub.K0(0), (EQ. 5a')
C.sub.i=C'.sub.iXORP'.sub.i-1, (EQ. 6a')
The value P'.sub.0 of EQ. 5a' corresponds to the 2a' corresponds to
the initialization value for the input of combining circuitry 756.
It should be noted that this initialization value is merely
illustrative, and that any suitable value may be used to initialize
P'.sub.0. The unwhitening of obfuscated ciphertext blocks using
previous obfuscated plaintext blocks is shown in EQ. 6a'.
[0091] An illustrative implementation of the decryption system of
FIG. 7B is shown in FIG. 8. System 800 of FIG. 8 may operate
similar to system 600 of FIG. 6, except that feedback line 820
connects an output of combining circuitry 818 to combining
circuitry 810. In contrast, in FIG. 6, feedback line 620 connects
the output of the decryption engine to combining circuitry 610.
This modification reflects EQ. 6a' above, such that blocks of
obfuscated ciphertext are unwhitened using previous blocks of
obfuscated plaintext P'.sub.i, rather than previous blocks of
further obfuscated plaintext H.sub.i.
[0092] FIG. 9 shows an exemplary flowchart of process 900 for
encrypting data in accordance with some embodiments. Process 900
may be executed, for example, in a system for encrypting
configuration data that may be external or internal to a
programmable device.
[0093] At 902, plaintext is received, for example, configuration
data for configuring PLD 100 of FIG. 1 is received at the
encryption system.
[0094] At 904, it is determined whether plaintext obfuscation is
enabled. For example, a bit register in the configuration device
may be set to enable or disable this feature. In some embodiments,
plaintext obfuscation may always be enabled. If plaintext
obfuscation is enabled, then plaintext is whitened at step 906, for
example, as described in FIG. 2A above. Step 908 may then be
performed. Alternatively, if plaintext obfuscation is disabled,
then 908 may be immediately performed.
[0095] At 908, it is determined whether continuous key evolution is
enabled. For example, a bit register in the configuration device
may be set to enable or disable allowing the key to continue to
evolve in between blocks. This may be useful for users who want to
implement AES strictly according to the NIST standard, i.e., by
generating round keys for each block encryption starting from the
cipher key. If continuous key evolution is not enabled, then 912
may be performed. Alternatively, if at 908 key evolution mode is
enabled, then 910 may be performed.
[0096] At 910, plaintext (or obfuscated plaintext from 906 if
plaintext whitening is enabled) is encrypted with such that
different blocks are encrypted with different keys, as described in
connection with FIGS. 3A-C above. Otherwise, at 912, plaintext (or
obfuscated plaintext from 906 if plaintext whitening is enabled) is
encrypted using normal AES, i.e., using the original cipher key for
generating the sequence of round keys (key schedule).
[0097] At 914, it is determined whether S-box obfuscation is
enabled. For example, a bit register in the configuration device
may be set to enable or disable this feature. Given that
obfuscating cryptographic S-boxes may add computational overhead, a
user may wish to disable this feature in some implementations.
[0098] If S-box obfuscation is enabled, plaintext is encrypted at
916 using obfuscated S-boxes as described in connection with FIG. 4
above, where plaintext is input into the obfuscated S-box. If S-box
obfuscation is disabled, plaintext is encrypted at 918 using
non-obfuscated S-boxes, such as the normal AES S-boxes.
[0099] At 920, it is determined whether ciphertext obfuscation is
enabled. If it is, 922 may be performed. Otherwise, 924 may be
performed.
[0100] At 922, encryption is carried out by whitening output blocks
of ciphertext with blocks of plaintext (that may have been whitened
or not at 906). This may be implemented using encryption system 500
of FIG. 5A or encryption 700 of FIG. 7A.
[0101] Alternatively, if ciphertext obfuscation is not enabled,
then the normal cryptographic method (e.g., AES encryption) may be
implemented using normal CBC mode.
[0102] Finally, at 930, ciphertext corresponding to the plaintext
received at 902 is output.
[0103] FIG. 10 shows an exemplary flowchart of process 1000 for
decrypting data in accordance with some embodiments. Process 1000
may be executed, for example, in a system for decrypting
configuration data in a programmable device, e.g., decoder 102 of
programmable logic device 100 of FIG. 1.
[0104] At step 1002, ciphertext is received, for example, encrypted
configuration data for configuring PLD 100 of FIG. 1 is received at
the decryption system, or ciphertext output by encryption process
900 of FIG. 9.
[0105] At 1004, it is determined whether ciphertext obfuscation is
enabled. For example, feedback lines 620 of FIG. 6 or 820 of FIG. 8
may be enabled in this case. If ciphertext obfuscation is enabled,
1006 may be performed. Otherwise, 1008 may be performed.
[0106] At 1006, decryption is carried out by whitening ciphertext
with blocks of plaintext. This may be implemented using decryption
systems 550 of FIG. 5B, 600 of FIG. 6, 750 of FIG. 7B, or 800 of
FIG. 8. Alternatively, at 1008, if ciphertext obfuscation is not
enabled, then the normal cryptographic method (e.g., AES
decryption) may be implemented using normal CBC mode. For example,
feedback lines 620 of FIG. 6 or 820 of FIG. 8 may be disabled in
this case.
[0107] At 1010, it is determined whether S-box obfuscation is
enabled. If S-box obfuscation is enabled, ciphertext is decrypted
at 1012 using obfuscated S-boxes as described in connection with
FIG. 4 above, where ciphertext is input into the obfuscated S-box.
Otherwise, if S-box obfuscation is disabled, ciphertext is
decrypted using non-obfuscated S-boxes at 1014, such as the normal
AES S-boxes.
[0108] At 1016, it is determined whether continuous key evolution
is enabled. If continuous key evolution is disabled, then
ciphertext may be decrypted using normal AES decryption at 1020.
Alternatively, if the key evolution mode is enabled, then 1018 may
be performed.
[0109] At 1018, ciphertext is decrypted with a continuously
evolving key, as described in connection with FIGS. 3A-B. In some
implementations, different cipher keys may be used to decrypt
different blocks. In some implementations, while running the AES
decryption based on cipher key K, decryption of a subsequent block
may use round keys that have been expanded from the key schedule of
a previous block decryption.
[0110] At 1022, it is determined whether plaintext obfuscation is
enabled. If plaintext obfuscation is enabled, then whitened
plaintext is whitened at step 1024, for example, as described in
FIG. 2B above. In particular, whitening blocks of whitened
plaintext using LFSR 254 and combining circuitry 258 of FIG. 2B may
generate corresponding blocks of plaintext.
[0111] Finally, at 1026, plaintext (e.g., corresponding to
configuration data) that corresponds to ciphertext received at 1002
is output.
[0112] It will be understood that the above steps of processes 900
and 1000 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 process 900 and 1000 may
be executed or performed substantially simultaneously where
appropriate or in parallel to reduce latency and processing
times.
[0113] 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 PLD 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.
* * * * *
References