U.S. patent application number 14/715070 was filed with the patent office on 2016-08-25 for security ram block with multiple partitions.
The applicant listed for this patent is Altera Corporation. Invention is credited to Martin Langhammer.
Application Number | 20160248588 14/715070 |
Document ID | / |
Family ID | 56690603 |
Filed Date | 2016-08-25 |
United States Patent
Application |
20160248588 |
Kind Code |
A1 |
Langhammer; Martin |
August 25, 2016 |
SECURITY RAM BLOCK WITH MULTIPLE PARTITIONS
Abstract
Circuits, methods, and apparatus for storing application data,
keys, authorization codes, or other information in a volatile
memory on an FPGA. A field programmable gate array (FPGA) can
include multiple memory blocks and partition those blocks among
multiple independent reconfigurable regions. Access to the memory
blocks can then be restricted so that only authorized regions have
access to particular memory partitions. In addition, each partition
can store multiple message authentication codes (MACs) for further
controlling access to data in each partition.
Inventors: |
Langhammer; Martin;
(Alderbury, GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Altera Corporation |
San Jose |
CA |
US |
|
|
Family ID: |
56690603 |
Appl. No.: |
14/715070 |
Filed: |
May 18, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12830447 |
Jul 6, 2010 |
|
|
|
14715070 |
|
|
|
|
11517689 |
Sep 7, 2006 |
7752407 |
|
|
12830447 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 2212/1052 20130101;
H04L 9/3242 20130101; G09C 1/00 20130101; G06F 12/1416
20130101 |
International
Class: |
H04L 9/32 20060101
H04L009/32; G06F 12/14 20060101 G06F012/14 |
Claims
1. An apparatus for storing data, the apparatus comprising:
programmable circuitry including first and second independently
reconfigurable regions; a memory block configured to store data;
and a configuration controller configured to: partition the memory
block to allocate a first memory partition to the first
independently reconfigurable region and a second memory partition
to the second independently reconfigurable region; receive requests
from the first and second independently reconfigurable regions to
access the memory block; and control access to the memory block to
prevent the first independently reconfigurable region from
accessing the second memory partition and to prevent the second
independently reconfigurable region from accessing the first memory
partition.
2. The apparatus of claim 1, wherein the configuration controller
is further configured to: determine whether to the first
independently reconfigurable region should be granted access to the
second memory partition based on a stored bit; and control access
to the memory block to allow the first independently reconfigurable
region to access the second memory partition in response to
determining that the first independently reconfigurable region
should be granted access to the second memory partition; wherein
the configuration controller is configured to control access to the
memory block to prevent the first independently reconfigurable
region from accessing the second memory partition in response to
determining that the first independently reconfigurable region
should not be granted access to the second memory partition.
3. The apparatus of claim 2, wherein the configuration controller
is further configured to: determine, based on the stored bit,
whether the first independently reconfigurable region should be
granted read access and write access to the second memory
partition; in response to a read-only determination, control access
to the memory block to allow the first independently reconfigurable
region to read data stored in the second memory partition and to
prevent the first independently reconfigurable region writing data
to the second memory partition; in response to a write-only
determination, control access to the memory block to allow the
first independently reconfigurable region to write data to the
second memory partition and to prevent the first independently
reconfigurable region reading data from the second memory
partition; and in response to a read and write determination,
control access to the memory block to allow the first independently
reconfigurable region to both read data from and write data to the
second memory partition.
4. The apparatus of claim 1 further comprising n memory blocks and
m independently reconfigurable regions, where m>n, wherein the
configuration controller is further configured to: partition the n
memory blocks over m independently reconfigurable regions; and
control access to the n memory blocks to prevent any given one of
the m independently reconfigurable regions from accessing memory
partitions allocated to another one of the m independently
reconfigurable regions.
5. The apparatus of claim 4, wherein the memory block is
partitioned at the first configuration.
6. The apparatus of claim 4, wherein each memory partition stores
multiple message authentication codes.
7. The apparatus of claim 6, wherein the configuration controller
is further configured to: generate a message authentication code
for a received configuration stream; compare the generated message
authentication code with each of the stored message authentication
codes; and determine that the received configuration stream is an
authorized configuration stream when any of the stored message
authentication codes match the generated message authentication
code.
8. The apparatus of claim 7, wherein the apparatus further
comprises: a message authentication code (MAC) generator configured
to input the received configuration stream and output the generated
message authentication code, wherein the MAC generator is
implemented as a combination of hard logic and soft logic.
9. The apparatus of claim 8, wherein the MAC generator retrieves
one of a plurality of keys from the memory block for use in
generating message authentication codes.
10. The apparatus of claim 8, wherein a key is embedded in a soft
logic portion of the MAC generator during a first configuration of
the programmable circuitry, and wherein the key is used for
generating message authentication codes.
11. The apparatus of claim 1, wherein the configuration controller
is further configured to overwrite all data stored in the second
memory partition with zero values in response to determining that
the first independently reconfigurable region is attempting to
access the second memory partition.
12. The apparatus of claim 1 further comprising an encryption
circuit, wherein the encryption circuit is configured to decrypt
data stored in a given memory partition in response to the
configuration controller determining an authorized access
request.
13. The apparatus of claim 1, wherein the configuration controller
is automatically authorized to read data from any partition of the
memory block.
14. An apparatus for storing data, the apparatus comprising:
programmable circuitry including m independently reconfigurable
regions; n memory blocks for storing data, where m>n; a message
authentication code (MAC) generator configured to generate a
message authentication code for a received configuration stream;
and a configuration controller configured to: partition the n
memory blocks over m independently reconfigurable regions; store a
plurality of message authentication codes in at least one of the
memory partitions; compare the generated message authentication
code with each of the stored plurality of message authentication
codes; and determine that the received configuration stream is an
authorized configuration stream when any of the stored plurality of
message authentication codes match the generated message
authentication code
15. The apparatus of claim 14, wherein the MAC generator is further
configured to retrieve at least one of a plurality of keys from the
n memory blocks for use in generating message authentication
codes.
16. The apparatus of claim 14, wherein the configuration controller
is further configured to: control access to the n memory blocks to
prevent at least one of the m independently reconfigurable regions
from accessing a memory partition allocated to another one of the m
independently reconfigurable regions.
17. A method of controlling memory access in a field programmable
gate array (FPGA) having n memory blocks and m independently
reconfigurable regions, the method comprising: partitioning the n
memory blocks over the m independently reconfigurable regions;
storing a plurality of message authentication codes in at least one
of the memory partitions; generating a message authentication code
for a received configuration stream; comparing the generated
message authentication code with each of the stored plurality of
message authentication codes; and determining that the received
configuration stream is an authorized configuration stream when any
of the stored plurality of message authentication codes match the
generated message authentication code.
18. The method of claim 17 further comprising: retrieving at least
one of a plurality of keys from the n memory blocks for use in
generating the message authentication code.
19. The method of claim 17 further comprising: controlling access
to the n memory blocks to prevent at least one of the m
independently reconfigurable regions from accessing a memory
partition allocated to another one of the m independently
reconfigurable regions.
20. The method of claim 19 further comprising: controlling access
to the n memory blocks to prevent any of the m independently
reconfigurable regions from accessing a memory partition allocated
to another one of the m independently reconfigurable regions.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 12/830,447, filed Jul. 6, 2010, which is a
divisional of U.S. patent application Ser. No. 11/517,689, filed
Sep. 7, 2006, titled "SECURITY RAM BLOCK," now U.S. Pat. No.
7,752,407, all of which are hereby incorporated by reference herein
in their entireties.
BACKGROUND
[0002] The present invention relates generally to storing data on
an integrated circuit and more particularly to protecting data
stored in a battery powered memory on a field programmable gate
array (FPGA).
[0003] The circuit complexity and the tasks performed by integrated
circuits such as field programmable gate arrays have greatly
increased the last few years. Highly sophisticated software, or
applications, run on programmable logic elements that are
configured to perform intricate user-defined functions.
[0004] Often these applications need to store data in a memory, for
example, an application may store data at different times for later
use. Other important data such as chip identification, license
information, and encryption keys may need to be stored.
Unfortunately, if power is removed from the memory, this data is
lost unless the memory is nonvolatile.
[0005] But nonvolatile memory typically requires processing that is
either not compatible with processing technologies used to
manufacture FPGAs or uses extra processing steps that greatly
increase device costs. Also, in many situations, the security of
the data stored in memory is important, so it is desirable to
quickly erase it if a tamper is detected. Unfortunately, it is
difficult to quickly erase nonvolatile memory. Further, data stored
in a nonvolatile memory can be discovered through reverse
engineering.
[0006] To protect this data, it is important to also limit access
to it, such that the data may not be stolen or copied by a
nefarious user or application. For example, a configuration design
may be protected by encrypting it with a key. If this key is stored
in memory for use during decryption, it is desirable to protect and
limit access to this key.
[0007] Thus, what is needed are circuits, methods, and apparatus
that provide a memory for an FPGA that retains data when power to
the FPGA is removed, but is compatible with conventional FPGA
manufacturing processes and can quickly be erased in the event of a
tamper or other unauthorized event. Also, it is desirable to
provide further protection by limiting access to data stored in the
memory.
SUMMARY
[0008] Accordingly, embodiments of the present invention provide
circuits, methods, and apparatus for storing application data,
keys, authorization codes, or other information in a memory on an
FPGA. An exemplary embodiment of the present invention provides an
FPGA that stores this data in an on-chip volatile memory. A battery
powers the memory to prevent erasure of the stored information when
power to the FPGA is removed. In various embodiments the battery is
always the source of power for the memory, in other embodiments one
or more other power supplies can be switched in to replace the
battery as the source of power to the memory, for example to extend
battery life.
[0009] In various embodiments of the present invention, the power
to the memory may be interrupted in order to erase the contents of
the memory. For example, if a tamper or unauthorized configuration
bitstream is attempted, power to the memory is cut, thereby erasing
the memory. In one exemplary embodiment, a message authentication
code (MAC) is used to verify a configuration bitstream. The MAC
removes power from the memory if the received bitstream is not
verified.
[0010] Various embodiments of the present invention also limit
access to data stored in memory. Typically, read access is limited,
though write access may also be limited, particularly where data is
being overwritten. In a specific embodiment of the present
invention, access is limited by using authorization codes. An
application is only granted access if it provides the correct
authorization code, or an access code and authorization codes
stored in the memory have a predefined function relationship.
Another embodiment of the present invention encrypts data with a
key before it is stored. Only an application with the correct key
can make use of the data. Embodiments of the present invention may
incorporate one or more of these or the other features described
herein.
[0011] In one embodiment, the present invention provides an
apparatus for securely storing data. The apparatus includes a
memory core that contains a secure portion allocated to secure data
storage, and a control circuit configured to control data written
to and read from the secure portion of the memory core, and is
adapted to prevent changes to data stored in the secure portion
during reconfiguration operations of the memory, such as when an
application is configured during a software application
installation process which involves data read from and stored to
the memory core.
[0012] Embodiments of the present invention also provide circuits,
methods, and apparatus for sharing one or more memory blocks among
multiple independently reconfigurable regions of programmable
circuitry, e.g., an FPGA. In various embodiments of the present
invention, a configuration controller is configured to partition
the one or more memory blocks to allocate different memory
partitions to the multiple independently reconfigurable regions.
The configuration controller may also be configured to control
access to the memory block. For instance, the configuration
controller may be configured to prevent all or certain ones of the
independently reconfigurable regions from accessing a memory
partition which has been allocated to another independently
reconfigurable region. This access restriction may apply to read
access, write access, or both, and may vary depending on the
independently reconfigurable region requesting access.
[0013] In one illustrative embodiment, an apparatus includes n
memory blocks and m independently reconfigurable regions, where
m>n, and the configuration controller is configured to partition
the n memory blocks over the m independently reconfigurable
regions. The configuration controller may also be configured to
control access to each of the n memory blocks to prevent any given
one of the m independently reconfigurable regions from accessing
memory partitions allocated to another one of the m independently
reconfigurable regions.
[0014] In some embodiments, each memory partition stores multiple
message authentication codes, e.g., generated using a message
authentication code (MAC) generator. When a configuration stream is
received by the configuration controller, a MAC may be generated
and compared to the stored MACs to determine if the generated MAC
matches any of the stored MACs. If the configuration controller
determines a match, it may grant access to the memory partition
storing the matching MAC. Otherwise, the configuration controller
may deny access.
[0015] In some embodiments, the configuration controller is
configured to overwrite all data stored in a memory partition with
zero values in response to determining that an unauthorized
independently reconfigurable region is attempting to access the
memory partition. In other embodiments, the data is erased by
cutting power to the memory block containing the targeted memory
partition.
[0016] The configuration controller may control access to memory
blocks and partitions thereof using one or more access control
techniques. In one approach, the FPGA is designed so that all
memory accesses must go through the configuration controller; i.e.,
requests to access the memory must be provided to the configuration
controller, and the configuration controller communicates with the
memory on behalf of the requestor (e.g., an independently
reconfigurable region). This can be accomplished, for example, by
ensuring (through fixed design or by programming configurable
interconnects) that the independently configurable regions are not
provided with any direct connections to the memory block(s). The
configuration controller, in such a scenario, would only complete
requests (e.g., by forwarding the request on to the memory or to
the particular memory partition) that it determines to be
authorized.
[0017] In another approach, the independently configurable regions
may be provided with direct connections to the memory blocks, but
the data stored in the memory partitions are encrypted. In such a
scenario, the configuration controller may limit access to memory
partitions by decrypting data only when it determines a memory
request to be authorized.
[0018] Any other suitable approach may be used to control access to
memory blocks and their partitions and, in some embodiments, a
combination of these approaches may be implemented. Additionally,
these access control features may be implemented to control only
read access requests, write access requests, or both. In yet other
embodiments, access control may be achieved without using a
configuration controller, e.g., by encrypting the data and/or
storing MACs with the data as described above and further
below.
[0019] A better understanding of the nature and advantages of the
present invention may be gained with reference to the following
detailed description and the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0020] FIG. 1 is a simplified block diagram of a programmable logic
device that is improved by incorporating embodiments of the present
invention;
[0021] FIG. 2 is a block diagram of an electronic system that is
improved by incorporating embodiments of the present invention;
[0022] FIG. 3A is a block diagram illustrating the storing of an
encrypted configuration bitstream and decryption key according to
an embodiment of the present invention, while FIG. 3B illustrates
the decryption of an encrypted bitstream and configuration of an
FPGA according to an embodiment of the present invention;
[0023] FIG. 4A is a flowchart illustrating a method of encrypting a
configuration bitstream and storing a key and other parameters in a
security RAM according to an embodiment of the present invention,
while FIG. 4B is a flowchart illustrating a method of decrypting an
encrypted configuration bitstream and configuring an FPGA according
to an embodiment of the present invention;
[0024] FIG. 5 illustrates a method of powering a security RAM
according to an embodiment of the present invention;
[0025] FIG. 6 illustrates another method of powering a security RAM
according to an embodiment of the present invention;
[0026] FIG. 7 illustrates a method of powering a security RAM while
utilizing a shutdown switch according to an embodiment of the
present invention;
[0027] FIG. 8 illustrates a method of powering a security RAM while
utilizing a shutdown switch controlled by a message authentication
code according to an embodiment of the present invention;
[0028] FIG. 9 illustrates a method of generating a configuration
bitstream verification signal to control a security RAM shutdown
switch according to an embodiment of the present invention;
[0029] FIG. 10 is a flowchart illustrating a method of generating a
configuration bitstream verification signal to control a security
RAM shutdown switch according to an embodiment of the present
invention;
[0030] FIG. 11 illustrates a circuit that may be used as the
function block in FIG. 9;
[0031] FIG. 12 illustrates exemplary data transfers between a
configuration controller, an access control circuit, and security
SRAM during the configuration of an FPGA;
[0032] FIGS. 13A and 13B are a flowcharts illustrating the
operation of an FPGA where a configuration controller is granted
automatic access to a decryption key stored in a security SRAM;
[0033] FIG. 14 illustrates exemplary transfers of data in an FPGA
where access to data in a memory is limited by requiring an
authorization code;
[0034] FIG. 15 is a flowchart illustrating a method of limiting
read access to data in a security SRAM by requiring an
authorization code;
[0035] FIGS. 16A and 16B are a flowcharts illustrating a method
configuring a device where a decryption key is encrypted using a
second key and both keys are stored in a security SRAM;
[0036] FIG. 17 illustrates an exemplary dataflow in a device where
an application has protected data in a security SRAM through
encryption;
[0037] FIGS. 18A and 18B are a flowcharts illustrating a method of
receiving and decrypting encrypted data stored in a security
SRAM;
[0038] FIG. 19 is a block diagram of an exemplary FPGA including a
configuration controller, an access control circuit, and multiple
security SRAMs each having multiple partitions;
[0039] FIG. 20 is a flowchart illustrating a method of controlling
memory access in an FPGA having multiple memory blocks and
independently reconfigurable regions.
DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0040] FIG. 1 is a simplified partial block diagram of an exemplary
high-density programmable logic device 100 wherein techniques
according to the present invention can be utilized. PLD 100
includes a two-dimensional array of programmable logic array blocks
(or LABs) 102 that are interconnected by a network of column and
row interconnections of varying length and speed. LABs 102 include
multiple (e.g., 10) logic elements (or LEs), an LE being a small
unit of logic that provides for efficient implementation of user
defined logic functions.
[0041] PLD 100 also includes a distributed memory structure
including RAM blocks of varying sizes provided throughout the
array. The RAM blocks include, for example, 512 bit blocks 104, 4K
blocks 106, and an M-Block 108 providing 512K bits of RAM. These
memory blocks may also include shift registers and FIFO buffers.
PLD 100 further includes digital signal processing (DSP) blocks 110
that can implement, for example, multipliers with add or subtract
features.
[0042] It is to be understood that PLD 100 is described herein for
illustrative purposes only and that the present invention can be
implemented in many different types of PLDs, FPGAs, and the other
types of digital integrated circuits.
[0043] While PLDs of the type shown in FIG. 1 provide many of the
resources required to implement system level solutions, the present
invention can also benefit systems wherein a PLD is one of several
components. FIG. 2 shows a block diagram of an exemplary digital
system 200, within which the present invention may be embodied.
System 200 can be a programmed digital computer system, digital
signal processing system, specialized digital switching network, or
other processing system. Moreover, such systems may be designed for
a wide variety of applications such as telecommunications systems,
automotive systems, control systems, consumer electronics, personal
computers, Internet communications and networking, and others.
Further, system 200 may be provided on a single board, on multiple
boards, or within multiple enclosures.
[0044] System 200 includes a processing unit 202, a memory unit 204
and an I/O unit 206 interconnected together by one or more buses.
According to this exemplary embodiment, a programmable logic device
(PLD) 208 is embedded in processing unit 202. PLD 208 may serve
many different purposes within the system in FIG. 2. PLD 208 can,
for example, be a logical building block of processing unit 202,
supporting its internal and external operations. PLD 208 is
programmed to implement the logical functions necessary to carry on
its particular role in system operation. PLD 208 may be specially
coupled to memory 204 through connection 210 and to I/O unit 206
through connection 212.
[0045] Processing unit 202 may direct data to an appropriate system
component for processing or storage, execute a program stored in
memory 204 or receive and transmit data via I/O unit 206, or other
similar function. Processing unit 202 can be a central processing
unit (CPU), microprocessor, floating point coprocessor, graphics
coprocessor, hardware controller, microcontroller, programmable
logic device programmed for use as a controller, network
controller, and the like. Furthermore, in many embodiments, there
is often no need for a CPU.
[0046] For example, instead of a CPU, one or more PLD 208 can
control the logical operations of the system. In an embodiment, PLD
208 acts as a reconfigurable processor, which can be reprogrammed
as needed to handle a particular computing task. Alternately,
programmable logic device 208 may itself include an embedded
microprocessor. Memory unit 204 may be a random access memory
(RAM), read only memory (ROM), fixed or flexible disk media, PC
Card flash disk memory, tape, or any other storage means, or any
combination of these storage means.
[0047] FIG. 3A is a block diagram illustrating a method of storing
of an encrypted configuration bitstream and decryption key
according to an embodiment of the present invention. This figure
includes software modules and hardware interface 320, configuration
device 330, FPGA 340, and battery 350. In various embodiments of
the present invention, the configuration device 330 may be included
as part of the FPGA 340. For example, the configuration device 330
may be a memory on the FPGA 340. This figure, as with the other
included figures, is shown for illustrative purposes and does not
limit either the possible embodiments of the present invention or
the claims.
[0048] The software modules and hardware interface 320 include an
encryption software module 322, key software module 324, and
decryption circuit data module 326. These software modules use one
or more hardware interfaces for transferring data to the FPGA 340
and optional configuration device 330. The FPGA 340 includes a
security SRAM 342, decryption circuitry 344, and other programmable
circuitry 346.
[0049] A key 312 is received or otherwise generated by the key
software module 324, which provides it as key 322 to the security
SRAM 342 on the FPGA 340 and to the encryption software module 322.
A configuration bitstream 310 is received by encryption software
module 322, which uses the key 324 to generate an encrypted
configuration bitstream or encrypted program object file, EPOF 320,
which is provided to the configuration device 330. Decryption
circuit configuration data 314 may be optionally received by
decryption circuit data software module 326, which provides data
for storage in the security SRAM 342. This decryption circuit
configuration data may include a decryption circuit configuration
bitstream, decryption circuit parameters, such as the number of
rounds, substitution box entries, and other parameters, or
both.
[0050] The decryption circuitry 344 may be a fixed decryption
circuit, that is, a hard logic or hardwired circuit. The decryption
circuitry 344 may alternately be configured from programmable logic
or other configurable circuits, or it may include a combination of
these techniques. These logic elements can be configured by a
decryption circuit configuration bitstream that is part of the
decryption circuit configuration data 326. When a decryption
circuit 344 is to be configured, decryption circuit configuration
data 326 is provided and stored in the security SRAM 342.
[0051] In various embodiments, standard or conventional encryption
methods and circuits such as triple-DES (3-DES) or AES may be used.
Alternately, proprietary encryption circuits may be used. Both
conventional and proprietary algorithms may be defined by various
encryption algorithm parameters, which may also be part of the
decryption circuit configuration data 324 stored on the FPGA 340.
For example, when using otherwise standard encryption methods,
variations such as the number of rounds may be defined by
encryption algorithm parameters. In various embodiments of the
present invention where the decryption circuit is fixed or
hardwired, these encryption parameters may also be fixed such that
encryption algorithm parameters are not needed.
[0052] In a typical embodiment of the present invention, the
security SRAM 342 is a volatile memory. In various embodiments of
the present invention, the key 322, and optionally the decryption
circuit configuration data 326, is retained in the volatile memory
342.
[0053] In one embodiment, the security SRAM 342 may include other
circuits, such as an access control circuit, described further
below with respect to FIG. 12, that may be employed to prevent
unauthorized access to the security SRAM 342, and may utilize keys
or other security measures such as passwords to provide a secure
communication interface. Such access control circuits allow data to
be loaded into or retrieved from, or not loaded into or retrieved
from circuits and applications disposed outside the PLD 208, or
resident in the PLD 208. For example, such access control circuits
can control data being loaded (i) directly into security SRAM 342
from outside the PLD 208, (ii) from the application running in the
PLD 208, generate the data and load it onto the security SRAM 342,
or (iii) employ an external process to work with the application in
the PLD 208 to load data onto security SRAM 342 (i.e. public key
exchange). Such control circuits could operate in a power loss
situation or during application loading and/or configuration. In
other embodiments, such control circuit may control data retention
using (i) a hard switch, such as a fuse, (ii) a soft switch, such
as a RAM bit on the PLD 208, and/or (iii) by a memory location
inside the security SRAM 342, as described herein.
[0054] To ensure that this data is not lost when device power is
removed, a backup battery 350 may be used. In this specific
example, a battery 350 powers the memory or security SRAM 342 by
supplying a voltage VSRB on line 352 with respect to ground on line
354. This battery 350 may be separate from the FPGA 340, or it may
be included with the FPGA 340 as part of its packaging. For
example, the FPGA 340 may be packaged in a ball grid array package
that also includes the battery 350. Alternately, the FPGA 340 and
battery may be placed on a common substrate that is then
packaged.
[0055] The previous activities typically take place at a
manufacturing facility, such as an integrated circuit or an
original equipment manufacturer's facility. The following
activities typically occur once the FPGA 340 is deployed in the
field or otherwise used in an application. These activities often
take place following a power-up or a power recycle.
[0056] FIG. 3B illustrates the decryption of an encrypted bitstream
and configuration of an FPGA according to an embodiment of the
present invention. This block diagram includes a configuration
device 330, FPGA 340, and battery 350. Again, the configuration
device 330 may be part of the FPGA 340. The battery 350 powers the
security SRAM 342, such that its contents are not lost when the
other power supply voltages connected to the FPGA 340 are
removed.
[0057] Again, the decryption circuitry 344 is typically fixed or
hard logic. Optionally, the decryption circuit 344 may be to some
degree configurable. For example, the decryption circuitry 344 may
include hard logic with additional programmable logic elements, or
it may be completely programmable. If the decryption circuitry 344
needs to be configured to some extent, a decryption circuit
configuration bitstream is received from the security SRAM 342 as
part of the configuration data and parameters 348. If the various
parameters of the decryption circuitry 344 are to be programmed,
these parameters are received by the decryption circuitry 344 by
the security SRAM 342. This information may include the number of
rounds of decryption to be used, S-Box entries, permutation
settings, and other information. Note that the decryption circuitry
344 needs to be configured before the encrypted configuration
bitstream for the rest of the device can be decrypted.
[0058] Once the decryption circuitry 344 is configured and any
required parameters are received, the key 347 is received from the
security SRAM 342. The configuration data for the rest of the
circuitry, specifically the EPOF 334, is received by the decryption
circuitry 344. The decryption circuitry 344 decrypts the encrypted
program object file 334 and generates a decrypted program object
file 349, which is then used to configure the other programmable
circuitry 346 on the FPGA 340.
[0059] FIG. 4A is a flowchart illustrating a method of encrypting a
configuration bitstream and storing a key and other parameters in a
security RAM according to an embodiment of the present invention.
In step 400, a configuration bitstream is generated, for example by
using a hardware design program. In step 405, a key is received.
Optionally, parameters and configuration information for the
decryption circuitry, to the extent they are used, are received in
step 410. In step 415, the configuration bitstream is encrypted
using the key. This encrypted configuration bitstream can be
stored, either on a configuration device or FPGA in step 420.
[0060] In step 425, a security RAM is powered with the battery to
protect the contents of the security RAM that about to be loaded.
In step 430, the key and optional decryption circuit parameters are
stored in the security SRAM. At this point, the FPGA, and
configuration device if used, can be shipped in step 435 in order
be placed into service.
[0061] The steps shown in FIG. 4A are typically done at an
integrated circuit or original equipment manufacturer's location.
The steps in FIG. 4B are typically carried out later, for instance
during testing, or once the device is deployed in a user's
application.
[0062] FIG. 4B is a flowchart illustrating a method of decrypting
an encrypted configuration bitstream and configuring an FPGA
according to an embodiment of the present invention. Following a
power up or other appropriate event, the decryption circuitry
parameters and configuration data is received (when used) from the
security RAM in step 450. The decryption circuit is configured
using the configuration bitstream and parameters received from the
security RAM in step 455. In step 460, a key is received from the
security RAM by the decryption circuit.
[0063] The configuration bitstream, which was previously encrypted,
is received from the configuration device or memory locations on
the FPGA, in step 465. In step 470, the configuration bitstream is
decrypted using the key. In step 475, the FPGA is configured using
the newly decrypted configuration bitstream.
[0064] FIG. 5 illustrates a method of powering a security RAM
according to an embodiment of the present invention. In this
particular example, the FPGA 510 is broken into input/output
circuitry forming a ring 520, and a core 530, which includes a
security SRAM 532, decryption circuitry 534, and other programmable
circuitry 536.
[0065] In this particular example, the input output circuitry 520,
core 530, and security SRAM 532 are powered individually.
Specifically, VCCio 540 and GNDio 542 power the I/O ring 520, the
FPGA core 530 is powered by VCCint 550 and GNDint 552, while the
security SRAM 530 is powered by VCCsrb 560 and GNDsrb 562. It will
to be appreciated by one skilled in the art that the more or fewer
power supplies connected to different circuitry portions may be
used.
[0066] FIG. 6 illustrates another method of powering a security RAM
according to an embodiment of the present invention. In this
figure, as compared to FIG. 5, a power supply switch has been
added. Specifically, this figure includes an FPGA 610, which
includes an input/output ring, I/O ring 620, and an FPGA core
including a security SRAM 632, decryption circuitry 634, other
programmable circuitry 636, and the power supply switch 670. In
this example, the power supply switch 670 is included on the FPGA
610. In other embodiments of the present invention, the power
supply switch 670 may be separate and not included on the FPGA
610.
[0067] As before, the I/O ring 620, FPGA core 630, and security
SRAM 632 receive separate power supplies. Specifically, the VCCio
640 and GNDio 642 power the I/O ring 620, while the FPGA VCCint
650, and GNDint 662 power core 630.
[0068] The security SRAM is powered by the output of the power
supply switch 670, which provides VCCsrb 670, and GNDsrb 662. The
power supply switch 670, in this example, receives VCCio 640,
VCCint 650, and VCCbat 670. VCCbat 660 may be provided by a
battery, such as the battery 350 in FIG. 3. The power supply switch
670 selects one of the voltages at its input and provides VCCsrb
672 to the security SRAM 632.
[0069] In various embodiments of the present invention, the power
supply switch 670 may receive these or other power supplies. In
various embodiments, the power supply switch 670 may use different
algorithms for selecting which of these power supplies is provided
as VCCsrb 672 to the security SRAM 632. Also, the power supplies
switch 670 may perform additional functions such as power supply
regulation or filtering. That is, the power supply switch 670 may
use one or more of the applied input voltages to generate VCCsrb
672, rather than simply connecting a selected applied voltage to
the security SRAM 632.
[0070] In a specific embodiment, when VCCbat 660 is the only active
power supply received by the power supply switch 670, that voltage
is used to generate VCCsrb 672. However, if one of the other power
supplies received by the power supply switch 670 is active, that
is, above a certain voltage threshold, VCCbat 660 is not used such
that actual battery life is extended. If more than one other power
supply is active, for example both VCCio 640 and VCCint 650
areactive, the quieter of the two supplies, typically VCCint 650,
is used to generate VCCsrb 672, though in other embodiments, the
noisier supply is used. In another embodiment, if VCCbat 660 is
active, that power supply is used by the power supply switch 670 to
generate VCCsrb 672.
[0071] Again, the security SRAM 632 is typically a volatile memory.
Thus, if its power supplies are removed, the contents of the memory
are lost. This is useful in applications where the contents of the
security SRAM 632 need to be erased quickly due to a tampering or
other unauthorized event. When the security SRAM 632 is formed
using a volatile memory, such erasure can occur by interrupting the
power supply connection to the security SRAM 632.
[0072] FIG. 7 illustrates a method of powering a security RAM while
utilizing a shutdown switch according to an embodiment of the
present invention. This figure includes an FPGA 710 divided into an
input/output ring 720 and FPGA core 730. The FPGA core 730 includes
a security SRAM 732, decryption circuitry 734, and other
programmable circuitry 736. VCCio 740 and GNDio 742 power the I/O
ring 720, while VCCint 750 and GNDint 752 power the FPGA core
730
[0073] VCCsrb 760 and GNDsrb 762 power the security SRAM. The
VCCsrb 760 power supply can be disconnected from the security SRAM
732 by shutdown switch 770. The shutdown switch 770 may be formed
on the FPGA 710. Alternately, the shutdown switch 770 may be
off-chip. The shutdown switch 770 may be controlled by circuitry
that detects a tamper or other unauthorized event.
[0074] One such unauthorized event is the loading of an
unauthorized configuration bitstream. Accordingly, the
configuration bitstream that is used may be verified. If the
configuration bitstream is invalid, the power supply to the
security SRAM 72 is interrupted and its contents are lost.
[0075] The power supply switch 670 in FIG. 6 and the shutdown
switch 770 in FIG. 7 may be incorporated into a single unit, shown
in FIG. 8 as the power supplies switch 870. The power supply switch
870 selects among different input voltages to provide VCCsrb 872,
and also interrupts that power supply when instructed by message
authentication code 832.
[0076] FIG. 8 illustrates a method of powering a security RAM while
utilizing a shutdown switch controlled by a method authentication
code according to an embodiment of the present invention. This
figure includes an FPGA 810, which includes an I/O ring 820 and
FPGA core 830. The FPGA core 830 includes a security SRAM 832,
decryption circuitry 834, message authentication code 836, other
programmable circuitry 838, and a power supply switch 870.
[0077] In this example, VCCio 840 and GNDio 842 power the I/O ring
820, the FPGA core 830 is powered by VCCint 850 and GNDint 852,
while VCCsrb 872 and GNDsrb 872 power the security SRAM 832. The
power supply switch 870 generates VCCsrb 872. The power supply
switch 870, in this example, receives VCCio 840, VCCint 850, and
VCCbat 860 as inputs. In embodiments of the present invention, the
power supply switch 870 may receive these or other voltages. The
power supply switch 870 may select among the received voltages as
described above with regards to power supply switch 670.
[0078] After the decryption circuitry 834 decrypts the
configuration bitstream, the configuration bitstream may be
processed by a message authentication code 836, which verifies the
configuration bitstream. If the configuration bitstream is invalid,
the power supply switch 870 is instructed to remove power from the
security SRAM 832. In this way, when an unauthorized configuration
bitstream is used, the contents of the security SRAM 832 are lost.
On-chip circuitry can track the loss of the contents of the
security SRAM and disable the FPGA 810 appropriately.
[0079] FIG. 9 illustrates a method of generating a configuration
bitstream verification signal to control a power supply shutdown
switch according to an embodiment of the present invention. Message
authentication code 836 in FIG. 8 may use this method. This
configuration bitstream includes a header portion and configuration
data. The configuration data is encrypted, while the header portion
is not encrypted. Under some circumstances, portions of the header
may be well known, or able to be determined. If the header were
encoded, this information could lead to discovery of the encryption
key. Accordingly, the header is not encrypted. The header portion
includes an expected value 906 and a remainder 904. In this
example, the portion of the header that is not the expected value
906 is not used.
[0080] The encrypted configuration data is received by a function
block 910, which performs a function on it. The output 920 is
provided to a comparison circuit 930. The comparison circuit
compares the expected value 906 to the output on line 922 and makes
a determination of validity 940. If the configuration bitstream is
invalid, a power supply can be removed from a security RAM, thus
erasing its contents.
[0081] FIG. 10 is a flowchart illustrating a method of generating a
configuration bitstream verification signal to control a security
RAM shutdown switch according to an embodiment of the present
invention. In step 1010, a header including an expected value is
received. In step 1020, encrypted configuration data is received.
The header and encrypted configuration data form an encrypted
configuration bitstream.
[0082] In step 1030, a function is performed on the encrypted
configuration data by a function block in order to generate an
output. This output is compared to an expected value in step 1040.
In step 1050, it is determined whether the expected value received
as part of the header matches the output provided by the function
block. If there is a match, the bitstream is valid 1060. If there
is not a match, the bitstream is invalid 1070.
[0083] FIG. 11 illustrates a circuit that may be used as the
function block in FIG. 9. The received configuration data is broken
up into plaintext portions 1102, 1104, and 1106. The concatenation
of these portions results in reassembling the configuration data.
The first portion of the configuration data 1102 is encrypted using
a key 1112, thus generating an output on line 1114. The output on
line 1114 is exclusive-ORed with the second portion of the
configuration data 114 by exclusive-OR circuit 1122. The result on
line 1124 passes through a number of similar blocks until a final
stage is reached. At this point, the cumulative result on line 1126
is exclusive-ORed with configuration data 1106 by exclusive-OR
circuit 1122. The output is encrypted by encryption block 1130 and
the result is provided to a final encryption stage 1140. Encryption
block 1140 provides an output that may be compared to an expected
value that is provided as part of a configuration bitstream header.
While the encryption functions 1110, 1120, 1130, and 1140 are shown
as separate circuits, in practical integrated circuits, these are
one circuit.
[0084] In various embodiments of the present invention, data may be
stored in a security SRAM as encrypted or unencrypted data, or as a
combination thereof. The data may be encrypted using AES, DES, or
3-DES. Alternately, other standard or proprietary encryption
algorithms may be used.
[0085] Again, the data stored in this security SRAM may include
keys used for decryption of encrypted configuration bitstreams or
other data encrypted data. Other information, such as chip
identification data, and other cryptographic data may be
stored.
[0086] Also, applications running on an FPGA may use a security
SRAM to store data in order to protect it from being lost when
power is removed or during an application
configuration/reconfiguration process. For example, an application
may store data in the security SRAM and protect it with an
authentication code that is also stored in the security SRAM and
protected from erasure when power is removed. Later, when that
application needs to recover its data, for example after a power
recycle (that is, where power is removed and then restored, or more
particularly, where power drops below a threshold before rising
above it), the application can access the data using the
authentication code. Data stored in this way is typically stored as
unencrypted data, since it is only accessible by an application
that knows the authorization code, though this data may be stored
as encrypted data as well.
[0087] Instead of relying on an authorization code, an application
may encrypt data before storing it in the security SRAM. This
protects the data since an application that accesses this encrypted
data without having the correct decryption key cannot properly
decrypt the data.
[0088] In the above and other embodiments of the present invention,
read and write access to the security SRAM may be controlled by an
access control circuit. The access control circuit is typically a
hard logic circuit, that is, it is pre-wired, though it various
embodiments it may be formed by a number of programmable logic
elements. Alternately, some of the access control circuit may be
hard logic, while portions may be formed using programmable logic
elements. For example, in some embodiments a simple version of the
access control circuits may be hard logic, while optional
additional circuitry, such as an encoder/decoder circuit, may be
formed using programmable logic elements.
[0089] Typically, read access is limited, while write accesses are
not, though write access may also be limited in various embodiments
of the present invention. Read access is typically limited to a
lesser degree since the power to the security SRAM can be removed,
thereby erasing its contents.
[0090] The access control circuit can be used to limit access to
data in the security SRAM by applications running in the
programmable logic elements or by outside users or applications.
Typically however, the access control circuit is either bypassed or
automatically allows access by an on-chip configuration controller,
though access by this circuit may also be limited. Examples of
configuration controllers accessing data in a security SRAM,
specifically a decryption key used to decrypt an encrypted
bitstream, are shown in the following three figures.
[0091] FIG. 12 illustrates exemplary data transfers between a
configuration controller, an access control circuit, and security
SRAM during the configuration of an FPGA. In this example, the key
to be used to decrypt the encrypted bitstream, key 1242, is stored
as unencrypted data. This figure includes an FPGA 1210 that further
includes an I/O ring 1220 and an FPGA core 1230. The FPGA core 1230
includes a security SRAM 1240, programmable logic elements 1250,
configuration controller 1260, and access control circuit 1270.
[0092] In this example, the configuration controller 1260 requests
the key 1242 from the access control circuit. Since the
configuration controller 1260 is a known hard logic circuit, the
access control circuit 1270 does not require specific authorization
from the configuration controller 1260, though in other embodiments
of the present invention, such authorization may be required.
Accordingly, the access control circuit 1270 reads the key 1242
from the security of SRAM 1240. The access control circuit 1270
then provides the key to the configuration controller 1260. The
configuration controller 1260 receives the encrypted configuration
bitstream and decrypts the encrypted configuration bitstream. The
FPGA is then configured using the decrypted configuration
bitstream.
[0093] Again, in various embodiments of the present invention, the
access control circuit 1270 may limit access to the security SRAM
1240 by the configuration controller 1260. Typically this is not
done since the configuration controller 1260 is a hard logic
circuit that is pre-wired on the FPGA and not subject to
surreptitious reconfiguration. Accordingly, the configuration
controller 1260 may either be granted automatic access by the
access control circuit 1270, or it may be connected directly to the
security SRAM 1240. Flowcharts illustrating these last two methods
are shown in the following two figures.
[0094] FIG. 13A is a flowchart illustrating the operation of an
FPGA where a configuration controller is granted automatic access
by an access control circuit to a decryption key stored in a
security SRAM.
[0095] Specifically, in step 1310, a configuration controller
requests a key from an access control circuit. The access control
circuit reads the key from a security SRAM in step 1320. The access
control circuit provides the key to the configuration controller in
step 1330. In step 1340, the configuration controller receives an
encrypted bitstream. The configuration controller then decrypts the
encrypted bitstream using the key and configures the FPGA.
[0096] FIG. 13B is a flowchart illustrating the operation of an
FPGA where are a configuration controller is directly connected or
can bypass the access control circuit. In step 1360, the
configuration controller receives a key from the security SRAM. The
configuration controller receives an encrypted bitstream in step
1370, and decrypts the bitstream and configures the FPGA in step
1380.
[0097] Again, applications running and/or upon
configuration/reconfiguration or installation, in the programmable
logic circuitry can protect data from erasure by storing it in the
battery backed-up security SRAM. The stored data is protected and
isolated from external conditions affecting the programmable logic
circuitry. For example, if power is removed from the FPGA, the
application can recover the data once power is restored. An
application may protect this data by encrypting it before storing
it in the security SRAM. Alternately, it may store an authorization
code in memory along with the data. When the application attempts
to recover the data, it provides the location of the data and the
authorization code to the access control circuit. If the correct
authorization code is given, the access control circuit provides
the data to the application. Examples of how this can be
implemented are shown in the following two figures.
[0098] FIG. 14 illustrates exemplary transfers of data in an FPGA
where access to data in a memory is limited by requiring an
authorization code. This figure includes an FPGA 1410, including an
I/O ring 1420 and an FPGA core 1430. The FPGA core 1430 includes a
security SRAM 1440, programmable logic elements 1450, configuration
controller 1460, and access control circuit 1470.
[0099] In this example, an FPGA running in the programmable logic
1450 has previously stored data and a corresponding authorization
code 1442 in the security SRAM 1440. To recover this data, any
number of methods may be employed to validate access, for example,
passwords, etc. In one embodiment, the application provides the
address of the data and authorization code to the access control
circuit. The access control circuit verifies the authorization code
provided by the application. For example, the access control
circuit may do a bit-by-bit match, or employ a function associated
with the authorization code provided by the application with the
authorization code 1442 stored in the security SRAM 1440. If the
codes match or function relationship established, the access
control circuit allows access to the data by the application. If
there is a mismatch, access is denied which may be indicated using
a variety of techniques without necessarily returning incorrect
data.
[0100] FIG. 15 is a flowchart illustrating a method of limiting
read access to data in a security SRAM by requiring an
authorization code. In this example, the application has previously
stored data and an authorization code in the security SRAM. Again,
this write access is typically not limited, though in various
embodiments of the present invention this access may be limited as
well. For example, the access control circuit may require the
authorization code to overwrite data that has been previously
protected with the code.
[0101] Specifically, in step 1510, an application provides an
address for data and an authorization code to an access circuit. In
step 1520, the access circuit compares the authorization code with
an authorization code stored in the security SRAM. Typically, the
authorization code stored in a security SRAM was stored by the
application, though other circuits, such as the access control
circuit, may generate an authorization code, which is then stored
in a security SRAM and given to the application for future use. In
step 1530, if the codes match, the access control circuit grants
access to the data, otherwise access is denied.
[0102] In the above examples, data is typically stored as
unencrypted data. However, as discussed above, data may also be
stored as encrypted data. For example, a decryption key used to
decrypt an encrypted bitstream may itself be encrypted using a
second key. This second key may be stored as unencrypted data, or
it may be encrypted using yet another key. In the following
example, a decryption key is encrypted using a second key, which is
stored as unencrypted data.
[0103] FIG. 16A is a flowchart illustrating a method of storing
decryption keys where a decryption key is encrypted using a second
key and both keys are stored in a security SRAM. In this example,
an access control circuit is responsible for decrypting the
decryption key. This has the advantage as not requiring the
configuration controller to know how the decryption key is stored
in memory, that is, the configuration controller does not need to
know whether the decryption key is stored as encrypted or
unencrypted data.
[0104] Specifically, in step 1610, a configuration controller
requests a decryption key stored in a security SRAM. An access
control circuit reads an encrypted decryption key and a second,
unencrypted key from the security SRAM in step 1615. In step 1620,
the access control circuit decrypts the encrypted decryption key
using the second key and provides the decryption key to the
configuration controller. In step 1625, the configuration
controller receives an encrypted bitstream, and in step 1630, the
configuration controller decrypts the encrypted configuration
bitstream and configures the FPGA using the decrypted configuration
bitstream.
[0105] FIG. 16B is another flowchart illustrating a method of
storing decryption keys where a decryption key is encrypted using a
second key, and both keys are stored in a security SRAM. In this
example, the configuration controller is responsible for decrypting
the decryption key.
[0106] Specifically, in step 1650, the configuration controller
requests the decryption key. In step 1655, the access control
circuit reads the encrypted decryption key and unencrypted second
key from memory and provides them to the configuration controller.
The configuration controller decrypts the encrypted decryption key
using the second key in step 1660. In step 1665, the configuration
controller receives an encrypted configuration bitstream. The
encrypted configuration bitstream is decrypted using the decryption
key, and in step 1670, the FPGA is configured.
[0107] Again, applications may also store encrypted data in the
security SRAM. While an authorization code may be required to
access this encrypted data, such authorization is typically not
required since only an application having the correct decryption
key can utilize the data. (Again however, various embodiments of
the present invention may require some sort of authorization to
overwrite previously written data.) Examples illustrating
applications storing encrypted data in a security SRAM are shown in
the following three figures.
[0108] FIG. 17 illustrates an exemplary dataflow in a device where
an application has protected data in a security SRAM through
encryption. This figure includes an FPGA 1710 that further includes
an I/O ring 1720 and an FPGA core 1730. The FPGA core 1730 includes
a security SRAM 1740, programmable logic elements 1750,
configuration controller 1760, and access control circuit 1770. In
this example, an application running in the programmable logic 1750
has previously stored encrypted data 1742 in the security SRAM
1740, for example before a power recycle, and now the application
needs to recover the stored data. The data may have been encrypted
by the application itself or by they access control circuit
1770.
[0109] The application provides an address for the encrypted data
1742 to the access control circuit 1770. The access control circuit
reads the encrypted data 1742 and provides it to the application.
The application then decrypts the data using its key. Only an
application having the correct key can make use of the encrypted
data, otherwise the data is useless.
[0110] While in this embodiment the decryption is done by the
application itself, in other embodiments the decryption may be done
by the access control circuit. For example, this may be useful
where the access control circuit encrypts data using a key, and
then provides the key to the application for further use. Examples
are shown in the following flowcharts.
[0111] FIG. 18A is a flowchart illustrating a method of receiving
encrypted data stored in a security SRAM. In this example, an
access control circuit decrypts data for an application. The
encrypted data may have been originally encrypted by either the
application or the access control circuit, depending on the exact
implementation.
[0112] Specifically, in step 1810, an application provides an
address of encrypted data and the key to the access control
circuit. In step 1820, the access control circuit reads the
encrypted data from the security SRAM. In step 1830, the access
control circuit decrypts the encrypted data and provides the
decrypted data to the application. Again, this data is useful only
if the correct key was given to the access control circuit by the
application.
[0113] FIG. 18B is another flowchart illustrating a method of
receiving encrypted in data stored in a security SRAM. In this
example, the application itself is responsible for decrypting
data.
[0114] Specifically, in step 1850, the application gives an address
for the encrypted data to the access control circuit. In step 1860,
the access control circuit reads the encrypted data from a security
SRAM. In step 1870, the access control circuit provides the
encrypted data to the application. The application decrypts the
data using its key in step 1880. Again, this data is only useful if
the application uses the correct decryption key.
[0115] In one embodiment, for flexible use the security SRAM may be
partitioned with no access control, partitioned to include an
access control area plus a data storage area where the data storage
area may be further partitioned into protected areas. To further
protect the data stored in security SRAM, is by write protecting
the access control section. There are a plurality of write
protection schemes that may be employed such as one-time write
where once a memory location has been written to it cannot be
overwritten.
[0116] FIG. 19 is a block diagram of an exemplary FPGA 1910 in
accordance with some embodiments. FPGA 1910 includes I/O Ring 1920
and FPGA Core 1930. FPGA Core 1930 includes programmable circuitry
1950 with multiple independently reconfigurable regions 1952 and
1954, a configuration controller 1960, an access control circuit
1970, and multiple security SRAMs 1940, 1944 and 1946. The
description below describes certain functionality of configuration
controller 1960, but it should be understood that some or all of
this functionality may be implemented in access control 1970.
Indeed, in some embodiments, configuration controller 1960 and
access control 1970 may be the same module. In other embodiments,
each of SRAMs 1940, 1944 and 1946 has its own dedicated access
controller.
[0117] In various embodiments, the configuration controller 1960 is
configured to partition the one or more memory blocks 1940, 1944,
1946 to allocate different memory partitions to the multiple
independently reconfigurable regions (e.g., regions 1952 and 1954).
FIG. 19 shows partitions 1941 and 1942 as examples. It should be
understood, however, that any number of partitions may be
allocated, and that the memory locations allocated to each
partition may vary in terms of physical location in the memory. In
some embodiments, the configuration controller is also configured
to control access to the memory block, e.g., through access
controller 1970. For instance, the configuration controller may be
configured to prevent all or certain ones of the independently
reconfigurable regions from accessing a memory partition which has
been allocated to another independently reconfigurable region. This
access restriction may apply to read access, write access, or both,
and may vary depending on the independently reconfigurable region
requesting access.
[0118] In one illustrative embodiment, FPGA 1910 includes n memory
blocks (e.g., memories 1940, 1944, and 1946) and m independently
reconfigurable regions (e.g., including regions 1952 and 1954),
where m>n. The configuration controller 1960 may be configured
to partition the n memory blocks over the m independently
reconfigurable regions, e.g., so that each of the m independently
reconfigurable regions is allocated a memory partition on one or
more of the n memory blocks. The partitions may be of any suitable
size. The configuration controller 1960 may also be configured to
control access to each of the n memory blocks (e.g., alone or in
combination with access controller 1970) to prevent any given one
of the m independently reconfigurable regions from accessing memory
partitions allocated to another one of the m independently
reconfigurable regions.
[0119] In some embodiments, the partitioning is fixed; in others,
the partitioning can be set on first configuration of the FPGA.
There may also be default partitioning, which could optionally be
overwritten by the first configuration. Partition information
including a start and stop address, and/or memory size, for each
configurable region may be stored, e.g., as part of the start up
data, first configuration data, or default data. In one approach,
each configurable region may be allocated a contiguous memory space
that sequentially follows the memory space allocated to the
immediately preceding configurable region, thereby obviating the
need for storing start and stop addresses (memory size may be a
fixed or default value and/or memory size may be stored after
allocation).
[0120] In various embodiments, the configuration controller 1960 is
configured to determine whether a independently reconfigurable
region should be granted access to a memory partition allocated to
a different region. This determination may be made, for example,
based on a bit set on first configuration. In response to the
determination, the configuration controller 1960 may then control
access to the memory block to allow the first independently
reconfigurable region to access the memory partition, or to deny
the request. The configuration controller 1960 may also determine,
based on the stored bit, whether the independently reconfigurable
region should be granted read access and write access to the memory
partition. In response to a read-only determination, the
configuration controller 1960 may control access to the memory
block to allow the independently reconfigurable region to read data
stored in the memory partition and to prevent the region writing
data to the memory partition. In response to a write-only
determination, the configuration controller 1960 may control access
to the memory block to allow the independently reconfigurable
region to write data to the memory partition and to prevent the
region reading data from the memory partition. Finally, in response
to a read and write determination, the configuration controller
1960 may control access to the memory block to allow the
independently reconfigurable region to both read data from and
write data to the memory partition. Of course, it should be
understood that different configurable regions may have different
privileges to access memory partitions, and that those privileges
may vary on a partition to partition basis.
[0121] The configuration controller 1960 may control access to
memory blocks and their partitions using one or more access control
techniques. In one approach, FPGA 1910 is designed so that all
memory accesses must go through configuration controller 1960. That
is, FPGA 1910 may be designed in a manner that requires requests to
access the memory be provided to the configuration controller, and
the configuration controller communicates with the memory on behalf
of the requestor (e.g., an independently reconfigurable region).
This can be accomplished, for example, by ensuring (through fixed
design or by programming configurable interconnects) that the
independently configurable regions are not provided with any direct
connections to the memory block(s). The configuration controller,
in such a scenario, would only complete requests (e.g., by
forwarding the request on to the memory or to the particular memory
partition) that it determines to be authorized. The configuration
controller may be automatically authorized to read and/or write
data from any partition of the memory block(s).
[0122] In another approach, the independently configurable regions
may be provided with direct connections to the memory blocks (e.g.,
through communication path 1972 and, optionally, access control
1970), but the data stored in the memory partitions are encrypted.
In such a scenario, the configuration controller may limit access
to memory partitions by decrypting data only when it determines a
memory request to be authorized.
[0123] Any other suitable approach may be used to control access to
memory blocks and their partitions and, in some embodiments, a
combination of these approaches may be implemented. Additionally,
these access control features may be implemented to control only
read access requests, write access requests, or both. In yet other
embodiments, access control may be achieved without using a
configuration controller, e.g., by encrypting the data and/or
storing MACs with the data as described above and further
below.
[0124] In some embodiments, each memory partition stores multiple
message authentication codes, e.g., generated using a message
authentication code (MAC) generator (e.g., as shown in FIG. 11).
When a configuration stream is received by the configuration
controller 1960, a MAC may be generated and compared to the stored
MACs to determine if the generated MAC matches any of the stored
MACs. If configuration controller 1960 determines a match, it may
grant access to the memory partition storing the matching MAC.
Otherwise, configuration controller 1960 may deny access.
[0125] In some embodiments, configuration controller 1960 is
configured to overwrite all data stored in a memory partition with
zero values in response to determining that an unauthorized
independently reconfigurable region is attempting to access the
memory partition. In other embodiments, the data is erased by
cutting power to the memory block containing the targeted memory
partition, as described above.
[0126] In some embodiments, once the first configuration allocates
the memory partitions and MAC codes, they cannot be changed through
any authorized function. If the controller detects that the memory
partitions or MAC codes have changed, then it will erase all data
on the device. This will prevent an attacker from trying to gain
control of the device using the configuration block. Alternately, a
first configuration may include setting of some fuse bits or other
non-volatile memory which can define partition access or MAC
codes.
[0127] In various embodiments, a message authentication code (MAC)
generator is configured to input a received configuration stream
and output a generated message authentication code. The MAC
generator may be implemented as hard logic, soft logic, or a
combination of hard logic and soft logic. In one approach, the MAC
generator may include a Galois field (GF) multiplier implemented in
soft logic (e.g., the FPGA fabric). For example, modified soft
logic DSP blocks can be used to implement these GF multipliers. The
DSP blocks can support, for instance, a finite field reduction of a
GF expansion, as discussed in U.S. patent application Ser. No.
14/524,526, filed Oct. 27, 2014, hereby incorporated by reference
herein in its entirety.
[0128] The MAC generator may retrieve one of a plurality of keys
from one or more of the memory blocks for use in generating message
authentication codes. Alternatively, a key may be embedded in a
soft logic portion of the MAC generator during a first
configuration of the programmable circuitry.
[0129] In some embodiments, a single reconfigurable region may be
allocated partitions on multiple memory blocks. For example, one
partition may store encryption keys and MACs and another may store
backed up data. Multiple memory blocks may be used to securely back
up data. As another example, a memory block may not be sufficient
to store all data required by a reconfigurable region, and so it
may be allocated one or more partitions on one or more other memory
blocks.
[0130] FIG. 20 is a flowchart illustrating a method of controlling
memory access in an FPGA having multiple memory blocks and
independently reconfigurable regions in accordance with some
embodiments. In step 2002, n memory blocks are partitioned over m
independently reconfigurable regions, e.g., at first configuration.
At step 2004, a plurality of MACs may be stored in one or more of
the memory partitions, e.g., at first configuration or when data is
later stored in a memory block by an authorized region. At step
2006, a MAC is generated for a received configuration stream, e.g.,
by another region. At step 2008, the generated MAC is compared with
each of the stored MACs and, at step 2010, the process determines
whether the generated MAC matched any of the stored MACs. If so,
memory access is granted at step 2012. If there are no matches,
memory access is denied at step 2014.
[0131] The above description of exemplary embodiments of the
invention has been presented for the purposes of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the precise form described, and many modifications and
variations are possible in light of the teaching above. The
embodiments were chosen and described in order to best explain the
principles of the invention and its practical applications to
thereby enable others skilled in the art to best utilize the
invention in various embodiments and with various modifications as
are suited to the particular use contemplated.
* * * * *